Difference between revisions of "Getting translation strings right/ja"

From Lazarus wiki
Jump to navigationJump to search
(New page: {{Getting translation strings right}} このページは、文字列翻訳における入門的な内容を記載しています。 This page contains some basic notes on getting translat...)
 
m (Fixed syntax highlighting; deleted category included in page template)
 
(27 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
{{Getting translation strings right}}
 
{{Getting translation strings right}}
  
−
このページは、文字列翻訳における入門的な内容を記載しています。
+
このページでは、文字列の作成者（多くはアプリケーション作者と思います）にとっての、'''翻訳文字列を適切に作成する''' ための基礎的な事項を説明しています。
−
This page contains some basic notes on getting translation strings right from the start, from the original writers (e.g. most often programmers) angle.
 
  
−
この文章での "To get it right" とは、文字列が十分に後からの翻訳に簡単な準備がされており、オリジナル言語版にそれらを使用することで、基礎的な要求を満たせるということです。
+
この '''「翻訳文字列を適切に作成する」''' とは、翻訳文字列が簡単に修正できるように準備されており、原版が翻訳文字列を用いる条件に合っていることを意味します。
−
"To get it right" in this context means that the translation strings have been prepared properly for easier further translation, and the original version adapted to the basic requirements for using them.
 
  
 +
（英語版がこの文章のオリジナルなので）このページを書くに当たり、できるだけ言語に中立であろうと勤めていますが、英語を主言語とするものとしての偏りがある可能性もあります。 あなたの状況へ当てはまらないものは、自由に修正してください。(また、[[Getting translation strings right|オリジナル（英語）ページ]] へのフィードバックもお願いします。)
  
−
Although it is tried to be as language neutral as possible, there is in fact a slight bias towards English in particular. Feel free to extend or discard the ones which do not apply to your situation (and maybe add them to this page?).
+
=== 一般的事項 ===
  
−
=== 一般 General ===
+
問題を避けるために、'''元の文字列は正しい''' ことをまず確認してください。 この理由は、
 +
* 翻訳作業が不必要に難しくなります。 「Garbage In, Garbage Out： ゴミを入れると、ゴミが出てくる」原則が完全に当てはまります。
 +
* 一般的に、元の文字列が翻訳の初期値となるため未翻訳箇所では元の文字列が表示されますので、利用者がその間違いを見つけた場合、悪い印象を与えるかも知れません。
  
−
問題を避けるために、単純にはっきりささる。
+
したがって、'''つづり、語句を正確に''' してください。 不確かな文字は辞書で確認しましょう。
−
To avoid problems, simply make sure that the '''original strings are okay''' in the first place - there are several reasons to do so:
 
−
* the original strings are usually used as default translation, making a bad impression to the end user who happens to use the default strings.
 
−
* even worse making the translator's work unnecessarily harder, who is responsible for conveying the original information to another language. Just remember the "Garbage In, Garbage Out" principle which applies perfectly here.
 
−
So try to make sure that your '''spelling is correct''' - use a dictionary if you are unsure.
 
  
−
Use understandable and well-known phrases for a given situation you want to describe, in a '''consistent''' manner. If you are unsure whether something is common, try to put other programs in the same situation and examine their responses. Literature and help files are also often a good resource for the exact special terms or phrases, or style issues.
+
また、動作に対する反応などは、'''一貫した記述''' で分かりやすくよく知られた単語を利用しましょう。 一般的な記述が不確かな場合は、同じようなプログラムが他にあればその動作を参考にすることもよい手段です。 他のアプリケーションのヘルプファイルも、特殊用語や説明の仕方についてのよい資料となります。 （訳注：私はwindows環境ですので、office（日本語版と英語版）を参考に文字列リソースを作成しています。）
−
Try to be consistent in choosing phrases too. For example the questions
 
−
Delete the file?
 
−
Erase the file?
 
−
Remove the file?
 
−
Wipe the file?
 
−
Zap the file?
 
−
all have a somewhat similar meaning, but when used interchangably for no apparent reason the one or other reader may start interpreting weird things into it.
 
−
Especially translators are very prone to this error, since they often do not know the exact context of a particular message (e.g. information about the origin of the message) and may interpret simple word variations as indication of important differences, and will likely be tempted to choose uncommon (bad) translations.
 
  
−
Especially for error messages to the user: try to '''describe the problem''' itself in appropriate words. This is never the state of the program which led to the error message. This is only useful for the person debugging the program, but not for the user. Users will either simply shrug their shoulders and ignore it in the best case, or choose another program in the worst case because without a proper problem description the user will not be able to fix the problem and continue his work - all that only because the program was not able to give a proper problem description.
+
語句の選定についても一貫したやり方をしてください。 例えば、
  
−
Give (easily) '''understandable descriptions'''. Do not try to impress your audience with foreign or very technical words only for telling that the current work has not yet been saved if not really necessary.
+
ファイルを削除（Delete）する？
 +
ファイルを消去（Erase）する？
 +
ファイルを除外（Remove）する？
 +
ファイルを拭い去る（Wipe）？
 +
ファイルを抹殺（Zap）する？
 +
 
 +
意味は似ていますが、特に理由が無いのに表現を変えた場合、読み手は間違った解釈をすることがあります。
 +
翻訳者はこの間違いを犯しやすく、あるメッセージの正確な文脈（例えば、メッセージの呼び出し元についての情報）を知らなかったり、語句のちょっとした違いを重要な差異として捉え、適切ではない翻訳を選びがちになります。
 +
 
 +
エラーメッセージを出すときは、'''問題点''' 自身を適切に記述しましょう。 問題点の記述とは、エラーメッセージが出たプログラムの状態ではありません（ファイルエラー, 不正な入力など）。　これは、プログラムのデバッグには役立ちますが、ユーザには意味不明です。 肩をすくめて無視されるだけならいいですが、あなたの意味不明なアプリケーションを使うのをやめ、他のアプリケーションを探し始めるかもしれません。 問題解決につながるメッセージを表示しましょう。
 +
 
 +
また、簡単な'''分かりやすい書き方'''を行いましょう。 外国語や非常に技術的な用語は、本当の本当に必要なときにのみ使いましょう。
 +
 
 +
 
 +
多重否定は分かりにくいので、使わないようにしましょう。 例えば、
  
−
Especially try to avoid multiple negations within a single sentence in your wordings, they are nearly always harder to read than their non-negated counterparts. An example could be
 
 
  This component can not be dropped on non-TControls.
 
  This component can not be dropped on non-TControls.
−
which, in its non-negated form
+
このコンポーネントは、非Tcontolにドロップできません。
 +
 
 +
これは、否定しない文章で書き換えられます。
 +
 
 
  This component can only be dropped on TControls.
 
  This component can only be dropped on TControls.
−
is certainly easier to read and understand.
+
このコンポーネントは、TControlにのみドロップできます。
 +
 
 +
こちらのほうが分かりやすいですね。
 +
 
 +
=== 技術的項目 ===
 +
 
 +
この節では、既存の翻訳手法などの技術的な項目を説明します。
 +
これは、リソース文字列の構築、GNU gettext と format() 関数を含みます。
  
−
=== 技術的項目 Technical issues ===
+
==== リソース文字列と GNU gettext ====
  
−
In this section a short overview of technical issues, basically an overview of existing possibilites are given. These include the resourcestring construct, GNU gettext() and the format() function.
+
Free Pascalには文字列定数を扱えるようにするいくつかの言語構成体があります。
 +
特に、この目的のために導入された "resourcestring" というユニットがあります。
  
−
==== リソース文字列と GNU gettext Resourcestrings, and GNU gettext ====
+
詳細は、FPC マニュアルの (prog.pdf, pg. 89ff または [http://www.freepascal.org/docs-html/prog/progch9.html#x184-1870009 このリンク]) の適切な箇所を参照して下さい。
  
−
Free Pascal has some built-in language constructs for providing a way of handling constant strings. There is a special section of a unit called "resourcestring" which was specifically introduced for this reason. See the appropriate section of the FPC manual (prog.pdf, pg. 89ff or [http://www.freepascal.org/docs-html/prog/progch9.html#x184-1870009 here]) for the details.
+
GNU gettext は、アプリケーションの翻訳を提供するユーティリティ群です。 詳細は、FPC マニュアルの (prog.pdf, pg. 91ff または [http://www.freepascal.org/docs-html/prog/progse41.html#x210-2130009.4 このリンク]) を参照して下さい。
  
−
GNU gettext is a special set of utilities to provide translations for your programs, see the FPC manual once more (prog.pdf, pg. 91ff or [http://www.freepascal.org/docs-html/prog/progse41.html#x210-2130009.4 here]).
+
<u>注記:</u> GNU gettext の欠点として、単一の元の文字列から多くの翻訳文字列へのマッピングができない点があります。 ご注意下さい。
  
−
<u>Note:</u> GNU gettext has a conceptual flaw which does not allow mapping of a single original string to multiple translated strings, be aware of that.
+
==== IDE内の リソース文字列 ====
  
−
==== IDE内の リソース文字列 ResourceStrings in the IDE ====
+
* Lazarus には、文字列定数からリソース文字列を簡単に作るツールがあります。 [[IDE Window: Make ResourceString/ja|リソース文字列の作成]]を参照してください。
  
−
* Lazarus has a tool to easily create resourcestrings from string constants. See [[IDE Window: Make ResourceString|Make ResourceString]]
+
* FPC は、各リソース文字列の部分に対して .rst ファイルを生成します。 しかし、.rstファイルについての編集ツールはありません。 また、Lazarusは自動的に .rst ファイルの .po ファイルを生成することができます。 .po ファイルについては多くの編集ツールがあります。(例えば、 kbabel）
 +
パッケージ作成に向けての .po ファイルの生成について、下記の作業を行ってください：
  
−
* For each resourcestring section FPC creates a .rst file, but there are no editor for these files. Lazarus can automatically create .po files of the .rst files. There are a lot of tools to edit .po files (e.g. kbabel).
+
   * 'languages' や 'local' といった副ディレクトリを生成してください。
−
To enable creating the .po files for a package do the following:
+
   * パッケージを開き、'''オプション -> i18N'''、"国際化を有効に"をチェック、PO出力ディレクトリを設定
−
   * Create a sub directory 'languages' (or 'locale', or whatever)
 
−
   * Open the package. Then Options -> IDE Integration -> Directory of .po files set to ''languages''
 
−
The next time you compile the package, the IDE will create the .po files. Note: The .rst files must belong to package units. Otherwise the IDE ignores foreign .rst files.
 
  
−
The same works for projects. The directory is set in Project -> Project Options -> IDE Integration -> Directory of .po files.
+
次回にパッケージをコンパイルした時に、 副ディレクトリに .po ファイルが作成されます。 （注: .rst ファイルがパッケージ・ユニットに属する必要があります。 そうでない場合、 .rst ファイルはIDEに無視されます。）
  
−
* To create a german translation: copy the unit1.po file to unit1.de.po. Then use a text editor or a .po Editor to translate all strings.
+
これはプロジェクトについても同様です。
  
−
* The IDE will automatically load .po files for installed packages, if they exists. For example see lazarus/components/projecttemplates/languages/.
+
  * '''プロジェクト -> プロジェクトオプション -> i18N'''、"国際化を有効に"をチェック、PO出力ディレクトリを設定
  
−
* ToDo: Implement and document updating the translated .po files when new resourcestrings are added.
+
* 例：ドイツ語翻訳の作成: まず、 unit1.po ファイルを unit1.de.po ファイルに コピーします。次に、テキストエディターや .po エディターを用いて、文字列をすべて翻訳してください。
  
−
* ToDo: Implement and document collecting all .po files of statically linked packages.
+
* IDEは、インストールされたパッケージ用の .po ファイルがある場合、自動的に読み込みます。 例えば、 lazarus/components/projecttemplates/languages/ を見てください。
  
 +
* ToDo: 新しい resourcestrings の追加時に、翻訳された .po ファイルを更新する機能の実装と文書化。
  
−
==== ResourceStrings in your Application ====
+
* ToDo: 静的にリンクしたパッケージの 全 .po ファイルを集める機能の実装と文書化。
  
−
You can load the .po files at initialization to translate the resourcestrings. Add this to your .lpr file:
+
==== あなたのアプリケーションのリソース文字列 ====
  
−
<Delphi>
+
リソース文字列の翻訳のために .po ファイルを読み込むことができます。 この機能を .lpr ファイルに実装するには:
 +
 
 +
<syntaxhighlight lang=pascal>
 
...
 
...
 
uses
 
uses
Line 91: Line 105:
 
   Translations.TranslateUnitResourceStrings('LCLStrConsts',
 
   Translations.TranslateUnitResourceStrings('LCLStrConsts',
 
                       PODirectory+'lclstrconsts.%s.po',Lang,FallbackLang);
 
                       PODirectory+'lclstrconsts.%s.po',Lang,FallbackLang);
−
   // ... add here a TranslateUnitResourceStrings call for every po file ...
+
   // ... ここに、全ての .po ファイルに対する TranslateUnitResourceStrings 呼び出しを追加する ...
 
end;
 
end;
  
Line 100: Line 114:
 
   Application.Run;
 
   Application.Run;
 
end.
 
end.
−
</Delphi>
+
</syntaxhighlight>
  
−
==== The format() function ====
+
==== format() 関数 ====
  
−
To not only allow completely static strings in translations, you can use the [[doc:rtl/sysutils/format.html|format()]] method of the sysutils unit. It is able to replace placeholders within a given text by their actual value given as secondary parameter in a set. Example:
+
翻訳において、完全な静的文字列以外を許可するために、sysutilsユニットの [[doc:rtl/sysutils/format.html|format()]] メソッドを利用できます。 format() は、テキスト内のプレースホルダーを第2パラメーターで置き換えます。
−
format('Tomorrow on %0:s there will be %1:s.', ['Sunday', 'sunshine']);
 
−
returns
 
−
Tomorrow on Sunday there will be sunshine.
 
−
In this case the %0:s is a placeholder for the first (index 0) argument in the set of actual values (Sunshine), and likewise %1:s.
 
−
For an exact definition of the allowed placeholders and their syntax see the FPC reference manual.
 
  
−
Some guidelines for the usage of the format() function
+
（原文：To not only allow completely static strings in translations, you can use the [[doc:rtl/sysutils/format.html|format()]] method of the sysutils unit. It is able to replace placeholders within a given text by their actual value given as secondary parameter in a set.）
  
−
* Try to use indexed placeholders in the original strings, even if they are optional. When used, they allow the translator to move the arguments easily within the sentence allowing him more natural expressions (and actually sometimes moving sentence parts is required to create proper sentences in that language).
+
例:
  
−
* Never compose a sentence out of more than one string. Always use the format() method from the sysutils unit to construct the correct string using placeholders during runtime. Translators will usually not be able to reconstruct the whole sentence, therefore not able to give a good translation; only consider that there are often hundreds of such strings within a single translation database...
+
format('明日は %0:s で、 %1:s でしょう。', ['日曜日', '晴れ'])
  
−
* Do not format using whitespaces. Simply move your label to the appropriate position in the first place. There may be problems with font changes, and seemingly superfluous spaces will be in danger of being trimmed by the translator.
+
上記関数は、以下を返します。
  
−
<strike><u>Note:</u> Since format() does not interpret escaped control characters (e.g. like C's "\n", "\t", etc) and GNU gettext for any reason being the translation system of choice (and the tools based on it not being able to interpret non-escaped control characters), it is required to programmatically insert linebreaks.</strike>In the current lazarus version, "\n" and "\t" in translated strings are replaced by newline and tab.
+
明日は 日曜日 で、 晴れ でしょう。
  
−
==== Converting the translation into the right character set ====
+
ここでは、 %0:s が文字列配列の始めの（インデックスは0）の引数（日曜日）のプレースホルダー、 %1:s が2番目の引数（晴れ）のプレースホルダーとなります。
  
−
For example: converting a file from ISO-8859-1 to UTF-8:
+
プレースホルダーおよび書式の詳細は、FPCリファレンスマニュアルにあります。
 +
 
 +
format() 関数利用のガイドライン
 +
 
 +
* プレースホルダーにはインデックスを付けましょう。 引数の移動が簡単になり、より自然な翻訳が可能になります。
 +
 
 +
* 2つ以上の文字列から文章を構成しないようにしましょう。 常にformat()関数を用いて、プレースホルダーを利用した正確な文字列を、実行時に構成してください。 翻訳者は常に全ての文を翻訳できるとは限りません。 したがって、良い翻訳を行えないかもしれません。 考えて見てもください。 翻訳データベース内にそのような数百もの文字列があることを...
 +
 
 +
（原文：* Never compose a sentence out of more than one string. Always use the format() method from the sysutils unit to construct the correct string using placeholders during runtime. Translators will usually not be able to reconstruct the whole sentence, therefore not able to give a good translation; only consider that there are often hundreds of such strings within a single translation database...）
 +
 
 +
* 余白を利用した位置あわせはやめましょう。 シンプルに、適切な位置にラベルを移動させてください。フォント変更時に問題となるかもしれませんし、翻訳者によって余白が削除される危険性もあります。
 +
 
 +
<strike><u>注記:</u> format() は、エスケープされた制御文字(例えば、C言語の "\n" , "\t" など)や なんらかの理由でを翻訳システムとしてGNU gettext (それに基づいたツールはエスケープされていない制御文字を解釈できない) を解釈しないため、プログラムによる改行の挿入が必要になります。</strike>
 +
 
 +
現バージョンの lazarus では、翻訳された文字列の「\n」および「\t」は newline と タブ に置き換えられます。
 +
 
 +
==== 正しい文字セット/コードへ翻訳を変換する ====
 +
 
 +
例えば、 ISO-8859-1 から UTF-8 へ変換する場合、
  
 
   iconv --from-code=ISO-8859-1 --to-code=UTF-8 oldfile.po > newfile.po
 
   iconv --from-code=ISO-8859-1 --to-code=UTF-8 oldfile.po > newfile.po
  
−
Do not forget to change the line
+
以下の行を、
 +
 
 
   "Content-Type: text/plain; charset=ISO-8859-1\n"
 
   "Content-Type: text/plain; charset=ISO-8859-1\n"
−
to
+
 
 +
次のように修正することも忘れないで下さい。
 +
 
 
   "Content-Type: text/plain; charset=UTF8\n"
 
   "Content-Type: text/plain; charset=UTF8\n"
  
−
=== English related ===
+
=== 英語に関する項目 ===
 +
 
 +
この節では、特に英語を基本言語とする場合の注意点を説明します。
 +
 
 +
* テキストを出力する場所に十分な広さをとってください。英語は翻訳対象に比較してテキストが短くなりやすい（文字列として）ため、設計時に十分な余白を取るようにしましょう。 経験的に、2,3文字の文字列は2倍の広さを取ることが多くあります。 文字列が長くなるとこの違いは小さくなります。
  
−
This section contains notes which particularly apply when using English as the base language for translations.
+
* 英語の短縮形は避けましょう。 ただでさえ短い文字列がさらに短くなることに加え、例えば、表意文字を利用する場合、短縮形がまったく存在しないなどの問題があります。
  
−
* Make sure to reserve enough space where the text is output: English is a language in which texts are almost always shorter (in characters) than their respective translations, so plan ahead by reserving enough space. Experience shows that very short strings of a few characters length often almost double in size; this difference decreases as the strings get longer.
+
* よく言われることですが、英語の句読法では、記号（full stop（ピリオド）やカンマなど）はその前の語句や、前に語句がない場合（列挙時など）は語句のかたまりの一部になります。 特に、セミコロン（；）の後は、続いて空白があるべきです。
  
−
* Avoid abbreviations in English; in addition to the fact that this shortens the already short strings even more, there are severe problems with e.g. languages that use ideographic characters where these abbreviations simply do not exist at all.
+
There was an error ! Please check file settings , compiler settings,... to fix this issue .
 +
 
 +
上記文章は句読法が適当で、見栄えが悪いし読むのも困難です。 よくある改行アルゴリズムが空白で改行することを考えてください。　次の行が!やカンマ、ピリオドで始まる可能性もあります。
  
−
* Since this is often an issue: In English punctuation marks (full stop, comma, ...) are part of the previous words, or form some sort of words themselves if there is no previous word (in case of an enumeration). Especially after a semicolon there should always be a trailing space.
 
−
There was an error ! Please check file settings , compiler settings,... to fix this issue.
 
−
has horrible punctuation and therefore simply looks bad and is harder to read than usual. Consider that common line break algorithms break the line on whitespaces, possibly resulting in a single stop at the beginning of a line...
 
 
  There was an error! Please check file settings, compiler settings, ... to fix this issue.
 
  There was an error! Please check file settings, compiler settings, ... to fix this issue.
−
would probably be okay only considering punctuation.
+
 
 +
句読法を考慮した場合、上記文章が正しいものとなります。

Latest revision as of 12:26, 16 February 2020

│ Deutsch (de) │ English (en) │ español (es) │ français (fr) │ 日本語 (ja) │ русский (ru) │

このページでは、文字列の作成者（多くはアプリケーション作者と思います）にとっての、翻訳文字列を適切に作成する ための基礎的な事項を説明しています。

この 「翻訳文字列を適切に作成する」 とは、翻訳文字列が簡単に修正できるように準備されており、原版が翻訳文字列を用いる条件に合っていることを意味します。

（英語版がこの文章のオリジナルなので）このページを書くに当たり、できるだけ言語に中立であろうと勤めていますが、英語を主言語とするものとしての偏りがある可能性もあります。 あなたの状況へ当てはまらないものは、自由に修正してください。(また、オリジナル（英語）ページ へのフィードバックもお願いします。)

一般的事項

問題を避けるために、元の文字列は正しい ことをまず確認してください。 この理由は、

  • 翻訳作業が不必要に難しくなります。 「Garbage In, Garbage Out： ゴミを入れると、ゴミが出てくる」原則が完全に当てはまります。
  • 一般的に、元の文字列が翻訳の初期値となるため未翻訳箇所では元の文字列が表示されますので、利用者がその間違いを見つけた場合、悪い印象を与えるかも知れません。

したがって、つづり、語句を正確に してください。 不確かな文字は辞書で確認しましょう。

また、動作に対する反応などは、一貫した記述 で分かりやすくよく知られた単語を利用しましょう。 一般的な記述が不確かな場合は、同じようなプログラムが他にあればその動作を参考にすることもよい手段です。 他のアプリケーションのヘルプファイルも、特殊用語や説明の仕方についてのよい資料となります。 （訳注：私はwindows環境ですので、office（日本語版と英語版）を参考に文字列リソースを作成しています。）

語句の選定についても一貫したやり方をしてください。 例えば、 

ファイルを削除（Delete）する？
ファイルを消去（Erase）する？
ファイルを除外（Remove）する？
ファイルを拭い去る（Wipe）？
ファイルを抹殺（Zap）する？

意味は似ていますが、特に理由が無いのに表現を変えた場合、読み手は間違った解釈をすることがあります。 翻訳者はこの間違いを犯しやすく、あるメッセージの正確な文脈（例えば、メッセージの呼び出し元についての情報）を知らなかったり、語句のちょっとした違いを重要な差異として捉え、適切ではない翻訳を選びがちになります。

エラーメッセージを出すときは、問題点 自身を適切に記述しましょう。 問題点の記述とは、エラーメッセージが出たプログラムの状態ではありません（ファイルエラー, 不正な入力など）。　これは、プログラムのデバッグには役立ちますが、ユーザには意味不明です。 肩をすくめて無視されるだけならいいですが、あなたの意味不明なアプリケーションを使うのをやめ、他のアプリケーションを探し始めるかもしれません。 問題解決につながるメッセージを表示しましょう。

また、簡単な分かりやすい書き方を行いましょう。 外国語や非常に技術的な用語は、本当の本当に必要なときにのみ使いましょう。


多重否定は分かりにくいので、使わないようにしましょう。 例えば、 

This component can not be dropped on non-TControls.
このコンポーネントは、非Tcontolにドロップできません。

これは、否定しない文章で書き換えられます。 

This component can only be dropped on TControls.
このコンポーネントは、TControlにのみドロップできます。

こちらのほうが分かりやすいですね。

技術的項目

この節では、既存の翻訳手法などの技術的な項目を説明します。 これは、リソース文字列の構築、GNU gettext と format() 関数を含みます。

リソース文字列と GNU gettext

Free Pascalには文字列定数を扱えるようにするいくつかの言語構成体があります。 特に、この目的のために導入された "resourcestring" というユニットがあります。

詳細は、FPC マニュアルの (prog.pdf, pg. 89ff または このリンク) の適切な箇所を参照して下さい。

GNU gettext は、アプリケーションの翻訳を提供するユーティリティ群です。 詳細は、FPC マニュアルの (prog.pdf, pg. 91ff または このリンク) を参照して下さい。

注記: GNU gettext の欠点として、単一の元の文字列から多くの翻訳文字列へのマッピングができない点があります。 ご注意下さい。

IDE内の リソース文字列

  • Lazarus には、文字列定数からリソース文字列を簡単に作るツールがあります。 リソース文字列の作成を参照してください。
  • FPC は、各リソース文字列の部分に対して .rst ファイルを生成します。 しかし、.rstファイルについての編集ツールはありません。 また、Lazarusは自動的に .rst ファイルの .po ファイルを生成することができます。 .po ファイルについては多くの編集ツールがあります。(例えば、 kbabel）

パッケージ作成に向けての .po ファイルの生成について、下記の作業を行ってください： 

 * 'languages' や 'local' といった副ディレクトリを生成してください。
 * パッケージを開き、オプション -> i18N、"国際化を有効に"をチェック、PO出力ディレクトリを設定

次回にパッケージをコンパイルした時に、 副ディレクトリに .po ファイルが作成されます。 （注: .rst ファイルがパッケージ・ユニットに属する必要があります。 そうでない場合、 .rst ファイルはIDEに無視されます。）

これはプロジェクトについても同様です。 

 * プロジェクト -> プロジェクトオプション -> i18N、"国際化を有効に"をチェック、PO出力ディレクトリを設定
  • 例：ドイツ語翻訳の作成: まず、 unit1.po ファイルを unit1.de.po ファイルに コピーします。次に、テキストエディターや .po エディターを用いて、文字列をすべて翻訳してください。
  • IDEは、インストールされたパッケージ用の .po ファイルがある場合、自動的に読み込みます。 例えば、 lazarus/components/projecttemplates/languages/ を見てください。
  • ToDo: 新しい resourcestrings の追加時に、翻訳された .po ファイルを更新する機能の実装と文書化。
  • ToDo: 静的にリンクしたパッケージの 全 .po ファイルを集める機能の実装と文書化。

あなたのアプリケーションのリソース文字列

リソース文字列の翻訳のために .po ファイルを読み込むことができます。 この機能を .lpr ファイルに実装するには: 

...
uses
  ...
  Translations, gettext;

procedure TranslateLCL;
var
  PODirectory, Lang, FallbackLang: String;
begin
  PODirectory:='/path/to/lazarus/lcl/languages/';
  Lang:='';
  FallbackLang:='';
  GetLanguageIDs(Lang,FallbackLang); // in unit gettext
  Translations.TranslateUnitResourceStrings('LCLStrConsts',
                      PODirectory+'lclstrconsts.%s.po',Lang,FallbackLang);
  // ... ここに、全ての .po ファイルに対する TranslateUnitResourceStrings 呼び出しを追加する ...
end;

begin
  TranslateLCL;
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

format() 関数

翻訳において、完全な静的文字列以外を許可するために、sysutilsユニットの format() メソッドを利用できます。 format() は、テキスト内のプレースホルダーを第2パラメーターで置き換えます。

（原文：To not only allow completely static strings in translations, you can use the format() method of the sysutils unit. It is able to replace placeholders within a given text by their actual value given as secondary parameter in a set.）

例: 

format('明日は %0:s で、 %1:s でしょう。', ['日曜日', '晴れ'])

上記関数は、以下を返します。 

明日は 日曜日 で、 晴れ でしょう。

ここでは、 %0:s が文字列配列の始めの（インデックスは0）の引数（日曜日）のプレースホルダー、 %1:s が2番目の引数（晴れ）のプレースホルダーとなります。

プレースホルダーおよび書式の詳細は、FPCリファレンスマニュアルにあります。

format() 関数利用のガイドライン

  • プレースホルダーにはインデックスを付けましょう。 引数の移動が簡単になり、より自然な翻訳が可能になります。
  • 2つ以上の文字列から文章を構成しないようにしましょう。 常にformat()関数を用いて、プレースホルダーを利用した正確な文字列を、実行時に構成してください。 翻訳者は常に全ての文を翻訳できるとは限りません。 したがって、良い翻訳を行えないかもしれません。 考えて見てもください。 翻訳データベース内にそのような数百もの文字列があることを...

（原文：* Never compose a sentence out of more than one string. Always use the format() method from the sysutils unit to construct the correct string using placeholders during runtime. Translators will usually not be able to reconstruct the whole sentence, therefore not able to give a good translation; only consider that there are often hundreds of such strings within a single translation database...）

  • 余白を利用した位置あわせはやめましょう。 シンプルに、適切な位置にラベルを移動させてください。フォント変更時に問題となるかもしれませんし、翻訳者によって余白が削除される危険性もあります。

注記: format() は、エスケープされた制御文字(例えば、C言語の "\n" , "\t" など)や なんらかの理由でを翻訳システムとしてGNU gettext (それに基づいたツールはエスケープされていない制御文字を解釈できない) を解釈しないため、プログラムによる改行の挿入が必要になります。

現バージョンの lazarus では、翻訳された文字列の「\n」および「\t」は newline と タブ に置き換えられます。

正しい文字セット/コードへ翻訳を変換する

例えば、 ISO-8859-1 から UTF-8 へ変換する場合、 

 iconv --from-code=ISO-8859-1 --to-code=UTF-8 oldfile.po > newfile.po

以下の行を、 

 "Content-Type: text/plain; charset=ISO-8859-1\n"

次のように修正することも忘れないで下さい。 

 "Content-Type: text/plain; charset=UTF8\n"

英語に関する項目

この節では、特に英語を基本言語とする場合の注意点を説明します。

  • テキストを出力する場所に十分な広さをとってください。英語は翻訳対象に比較してテキストが短くなりやすい（文字列として）ため、設計時に十分な余白を取るようにしましょう。 経験的に、2,3文字の文字列は2倍の広さを取ることが多くあります。 文字列が長くなるとこの違いは小さくなります。
  • 英語の短縮形は避けましょう。 ただでさえ短い文字列がさらに短くなることに加え、例えば、表意文字を利用する場合、短縮形がまったく存在しないなどの問題があります。
  • よく言われることですが、英語の句読法では、記号（full stop（ピリオド）やカンマなど）はその前の語句や、前に語句がない場合（列挙時など）は語句のかたまりの一部になります。 特に、セミコロン（；）の後は、続いて空白があるべきです。
There was an error ! Please check file settings , compiler settings,... to fix this issue .

上記文章は句読法が適当で、見栄えが悪いし読むのも困難です。 よくある改行アルゴリズムが空白で改行することを考えてください。　次の行が!やカンマ、ピリオドで始まる可能性もあります。 

There was an error! Please check file settings, compiler settings, ... to fix this issue.

句読法を考慮した場合、上記文章が正しいものとなります。

Retrieved from "http://wiki.freepascal.org/index.php?title=Getting_translation_strings_right/ja&oldid=132228"