GNU
gettextツールセットは、プログラマーや翻訳者が翻訳のためのファイルを生成、更新、使用する手助けをし、それらのPOファイルは主としてテキスト形式で編集可能なファイルです。このチャプターでは、POファイルのフォーマットについて説明します。
POファイルは多くのエントリーから成り立っており、それぞれのエントリーには翻訳される前の原文の文字列と、それに対応する翻訳された文字列との関連が保持されています。あるPOファイルに含まれるすべてのエントリーは通常、ひとつのプロジェクトに関連し、翻訳されたすべての文字列もひとつの言語を対象に翻訳されたものです。一般的なPOファイルのエントリーは、以下のような構造を持ちます:
white-space # translator-comments #. extracted-comments #: reference… #, flag… #| msgid previous-untranslated-string msgid untranslated-string msgstr translated-string
翻訳者は、POファイルの一般的な構造を十分に理解する必要があります。emacsのPOモードを使用すれば、フォーマットの詳細に関する最小限の知識を理解するだけで、あとはPOモードが彼女にかわって面倒を見てくれます。
以下は簡単なエントリの例です：
#: lib/error.c:116 msgid "Unknown system error" msgstr "Error desconegut del sistema"
エントリーは任意の個数の空白文字から開始することができます。GNU
gettextツールで生成された場合、エントリーとエントリーの間には通常、1つの空行があります。#の文字で始まる行はすべてコメント行として扱われます。コメントには2種類のコメントがあります。1つ目はtranslator
comments(翻訳者コメント)で、#の直後にいくつかの空白文字があり、これらのコメントは翻訳者により保守、保守されます。2つ目のコメントはautomatic
comments(自動コメント)で、これらのコメントはGNU
gettextツールにより自動的に挿入、保守されるもので、#の直後に空白文字以外の文字があります。#.で始まるコメントはプログラマーによる翻訳者に向けたコメントを含んでいます。これらのコメントはxgettextプログラムによりプログラムのソースから抽出(extract)されるため、extracted
comments(抽出コメント)と呼ばれます。#:で始まるコメントには、プログラムのソースコードへの参照(references)が含まれます。#,で始まるコメントにはフラグ(flags)が含まれています。これらのフラグについては以下で説明します。#|で始まるコメントには、以前のバージョンの翻訳済みメッセージに対応する翻訳前の文字列(previous
untranslated string)が含まれています。
すべてのコメントは、オプションです。
空白文字とコメントの後には、2つの文字列を表すための文字列があります。最初の文字列は翻訳前の文字列で、これらの文字列のオリジナルはプログラムのソース中に出現する文字列です。その次の文字列は、この翻訳前の文字列に対応する翻訳後の文字列です。オリジナルの文字列はmsgidというキーワードで識別され、翻訳はmsgstrというキーワードで識別されます。これらの翻訳前と翻訳後の2つの文字列は、POファイル中で"区切りや\エスケープにより、様々な方法で引用されていますが、文字列の引用などについてはPOモードが彼女にかわり面倒をすべて見てくれるので、翻訳者はそれらの正確な引用形式に注意を払う必要がなくなります。
msgidの文字列も自動生成されたコメントと同様、GNU
gettextの他のツールにより生成、管理されるので、POモードは翻訳者がそれらを変更するような操作を提供しません。それらの文字列にたいして彼女にできることは、単にそれを削除することだけで、しかもエントリー全体を削除できるだけです。一方、msgstrの文字列については、実際に翻訳者が編集するための翻訳者コメントなので、POモードは彼女の必要に応じて、完全な制御を提供します。
#,で始まるコメントは、一般的なコメントとは違いプログラムにより完全に無視されるものではないという点で、特別なコメントです。カンマで区切られたflagのリストは、ユーザーのためにより良い診断メッセージを提供するために、msgfmtプログラムにより使用されます。現時点では2つの形式のflagが定義されています:
fuzzyこのフラグはmsgmergeプログラムにより生成されるか、翻訳者自身により挿入され、msgstrの文字列が、(もはや)正しい翻訳ではないことを示します。翻訳をさらに修正する必要があるか、そのまま適用できるかは、翻訳者だけが判断できます。翻訳を完成したら、彼女はfuzzy属性を取り除きます。msgmergeは、あいまい検索(fuzzy
search)によりmsgidとmsgstrエントリーを結びつけた場合のみ、このフラグを挿入します。Fuzzy Entriesを参照してください。
c-formatno-c-formatこれらは人間によって追加されるフラグではなく、xgettextプログラムだけが挿入するフラグです。ここで提案しているようなPOファイルを自動生成するシステムでは、ユーザーが変更を行っても、xgettextプログラムが新しいテンプレートファイルを生成するたびに、変更は上書きされてしまいます。
c-formatフラグは、翻訳前の文字列と翻訳された文字列が、C形式の文字列であることを示します。no-c-formatフラグは逆に、文字列が一見して(‘%’ディレクティブによる)C形式の文字列に見えても、C形式ではないことを示します。
文字列にc-formatフラグが設定されていると、msgfmtプログラムは、翻訳にたいして妥当性チェックのテストを追加で行います。msgfmt Invocation、およびc-format Flagとc-formatを参照してください。
objc-formatno-objc-formatObjective Cの場合も同様です。objc-formatを参照してください。
sh-formatno-sh-formatshellの場合も同様です。sh-formatを参照してください。
python-formatno-python-formatPythonの場合も同様です。python-formatを参照してください。
python-brace-formatno-python-brace-formatPython braceの場合も同様です。python-formatを参照してください。
lisp-formatno-lisp-formatLispの場合も同様です。lisp-formatを参照してください。
elisp-formatno-elisp-formatEmacs Lispの場合も同様です。elisp-formatを参照してください。
librep-formatno-librep-formatlibrepの場合も同様です。librep-formatを参照してください。
scheme-formatno-scheme-formatSchemeの場合も同様です。scheme-formatを参照してください。
smalltalk-formatno-smalltalk-formatSmalltalkの場合も同様です。smalltalk-formatを参照してください。
java-formatno-java-formatJavaの場合も同様です。java-formatを参照してください。
csharp-formatno-csharp-formatC#の場合も同様です。csharp-formatを参照してください。
awk-formatno-awk-formatawkの場合も同様です。awk-formatを参照してください。
object-pascal-formatno-object-pascal-formatObject Pascalの場合も同様です。object-pascal-formatを参照してください。
ycp-formatno-ycp-formatYCPの場合も同様です。ycp-formatを参照してください。
tcl-formatno-tcl-formatTclの場合も同様です。tcl-formatを参照してください。
perl-formatno-perl-formatPerlの場合も同様です。perl-formatを参照してください。
perl-brace-formatno-perl-brace-formatPerl braceの場合も同様です。perl-formatを参照してください。
php-formatno-php-formatPHPの場合も同様です。php-formatを参照してください。
gcc-internal-formatno-gcc-internal-formatGCCソースの場合も同様です。gcc-internal-formatを参照してください。
gfc-internal-formatno-gfc-internal-formatGNU Fortranコンパイラーのソースの場合も同様です。gfc-internal-formatを参照してください。
qt-formatno-qt-formatQtの場合も同様です。qt-formatを参照してください。
qt-plural-formatno-qt-plural-formatQt plural形式の場合も同様です。qt-plural-formatを参照してください。
kde-formatno-kde-formatKDEの場合も同様です。kde-formatを参照してください。
boost-formatno-boost-formatBoostの場合も同様です。boost-formatを参照してください。
lua-formatno-lua-formatLuaの場合も同様です。lua-formatを参照してください。
javascript-formatno-javascript-formatJavaScriptの場合も同様です。javascript-formatを参照してください。
以下のように、context specifier(コンテキスト指定子)をともなうエントリーも使用することができます:
white-space # translator-comments #. extracted-comments #: reference… #, flag… #| msgctxt previous-context #| msgid previous-untranslated-string msgctxt context msgid untranslated-string msgstr translated-string
コンテキスト(context)は、同じuntranslated-stringのあいまいさをなくすために提供されます。これによりPOファイルの中で、異なるcontextで、同じuntranslated-stringを複数もつことが可能になります。contextに空の文字列を指定するのと、msgctxtの行を指定しないのは、同じではないことに注意してください。
他にも、複数形式(plural form)を含む翻訳のために使用されるエントリーがあります。
white-space # translator-comments #. extracted-comments #: reference… #, flag… #| msgid previous-untranslated-string-singular #| msgid_plural previous-untranslated-string-plural msgid untranslated-string-singular msgid_plural untranslated-string-plural msgstr[0] translated-string-case-0 ... msgstr[N] translated-string-case-n
以下はエントリーの例です:
#: src/msgcmp.c:338 src/po-lex.c:699 #, c-format msgid "found %d fatal error" msgid_plural "found %d fatal errors" msgstr[0] "s'ha trobat %d error fatal" msgstr[1] "s'han trobat %d errors fatals"
msgidの前に、前述したmsgctxtコンテキストを指定することもできます。
ここで追加のフラグを使用できます:
range:このフラグは正の数値範囲をともない、range:
minimum-value..maximum-valueという書式で使用します。この範囲には、メッセージが受けとることができる数値を指定します。たとえばある言語では、事前に値が0から10だとわかっていれば、よりよい翻訳を生成できます。
previous-untranslated-stringは、msgmergeがメッセージをfuzzyとしてマークするとき同時にオプションとして挿入されます。これは開発者が、untranslated-stringにたいしてどのような変更を行ったかを、翻訳者が知る助けになります。
これは、POファイルの最後のエントリーに続けて、何らかの行(通常は空白文字やコメント)があるときに発生します。これらの行は、どのエントリーの一部でもなく、POファイルがツールにより処理されるときに捨てられるか、POファイルエディターの動作を妨げるときもあります。
このチャプターの残りの部分は、POファイルの正確な書式にたいしてよいアイデアを持つ人は興味があるかもしれませんが、POファイルエディターを使用する場合はスキップして構いません。しかし、POファイルを手で変更したい場合は、注意して読む必要があります。
空のuntranslated-stringは、メタ情報が含まれたヘッダーエントリー(Header Entryを参照してください)のために予約されています。このヘッダーエントリーはファイルの最初のエントリーにすべきです。空のuntranslated-stringは、この目的のために予約されているので、他の場所で使用することはできません。
untranslated-stringとtranslated-stringはCの文法に従い、それには文字列の括り方やバックスラッシュによるエスケープシーケンスも含まれます。複数行のメッセージを記述するときは、エスケープされた改行文字を使用せずに、改行する行末の最後の文字で引用符を閉じて、POファイルの次の行で再び引用を開始します:
msgid "" "Here is an example of how one might continue a very long string\n" "for the common case the string represents multi-line output.\n"
この例の最初の行には、‘for’のfという文字の上に‘Here’のHを揃えるために、空の文字列が使用されています。また、キーワードmsgidの後ろには3つの文字列があり、それらの文字列は連結して使用されます。空の文字列と連結することにより文字列全体は変更されませんが、msgidの行に連結される文字列を、複数行の表示を維持しつつ左揃え表示して、配置を明確にさせるための方法です。空の文字列は省略できますがその場合、msgidの後ろに記述する最初の行は‘Here’で開始しなければなりません2。それぞれの文字列の括りの終端を改行(‘\n’)の直後にしている理由は、そうしても支障がないからというだけで、任意の文字の後で括りを終端して構いません。
文字列の括りの内側にある、行末を示す‘\n’は文字列の一部で、文字列の括りの外側の改行はPOファイル自身の行末を示し、文字列に影響を与えない点に注意してください。
文字列の外側では、空白文字とコメントを自由に使うことができます。行頭の‘#’から、その行の行末までがコメントとなります。翻訳者が記入するコメントは‘#’の後ろに空白文字をいくつか記述する必要があります。‘#’の後ろに空白文字がない場合、それは特定のGNUツールで生成・管理されるコメントとみなされ、POファイルがmsgmergeで処理されるとき、予期せず削除される可能性があります。