PostgreSQL プログラムは(サーバ、クライアント両方とも)、メッセージが翻訳されていた場合、好みの言語でそのメッセージを発行することができます。翻訳メッセージセットの作成と保守は、その言語を理解し PostgreSQL の成果に貢献したい人間の補助が必要です。この作業にはプログラマである必要は全くありません。この節では補助方法を説明します。
言語の熟練度については判断しません。 この節ではソフトウェアツールについてを説明します。理論的には、テキストエディタのみが必要です。しかし、これは作成した翻訳メッセージを試そうとはしないという、あまりあり得ないような場合のみです。ソースツリーから構築する際に、--enable-nls オプションを使用していることを確認して下さい。これにより、全てのエンドユーザがとにかく必要とする、libintl ライブラリと msgfmt プログラムが検査されます。作業を試す際には、インストール手順の適切な部分に従って下さい。
新規に翻訳作業を始め、(後述の)メッセージカタログのマージを行ないたい場合、GNU 版と互換性を持った実装の xgettext と msgmerge という両方のプログラムが必要です。将来は、パッケージ化されたソース配布物を使用する場合に xgettext が必要にならないように、変更する予定です。(CVS版でも、まだこれが必要です。)今のところ、GNU gettext 0.10.36 以上を推奨します。
使用するマシンの gettext の実装には、その文書がついていると思います。以下のいくつかはおそらく重複していますが、追補すべき詳細についてはその文書を参照して下さい。
元(英語)のメッセージとその(おそらくは)翻訳された等価のものの組み合わせは メッセージカタログ に保持されます。 片方は(関連するプログラムはメッセージカタログを共有していますが)各プログラム用の、もう片方は対象とする言語用のものです。メッセージカタログには 2 つのファイル書式があります。1 つは、"PO" ファイル(移植可能オブジェクト (Portable Object) を意味します) であり、翻訳者が編集する特別な構文をもったプレインテキストファイルです。2 番目は、"MO" ファイル (マシンオブジェクト(Machine Object)を意味します)であり、対応する PO ファイルから生成され、国際化プログラムの実行の際に使用される、バイナリファイルです。翻訳者は、MOファイルを扱いません。 実際に扱うことは困難です。
メッセージカタログファイルの拡張子は想像していたかもしれませんが.po もしくは .mo です。ベース名は、関連するプログラムの名前、もしくは、翻訳目的とする言語名のどちらかで、状況によって変わります。これは少し混乱しています。例えば、psql.po(psql用のPOファイル)、fr.mo (フランス語用の MO ファイル)です。
PO ファイルの書式を以下に示します。
# comment msgid "original string" msgstr "translated string" msgid "more original" msgstr "another translated" "string can be broken up like this" ...
msgid はプログラムのソースから抽出されます。(これは必要はありませんが、最も一般的な方法です。)msgstr 行は初期状態では空であり、翻訳者によって使用される文字列が埋め込まれます。この文字列には、C スタイルのエスケープ文字を含めることも、上に示したように複数行に跨って続けることができます。(継続行は必ず行の先頭から始まらなければなりません。)
# という文字はコメントを示します。# 文字の直後に空白文字があった場合、それは翻訳者によって保守されるコメントとなります。# の直後に非空白文字が付く、自動的に付与されるコメントもあります。これらは、PO ファイルに対する操作を行なう各種ツールによって保守され、翻訳者の補助を意図しています。
#. automatic comment #: filename.c:1023 #, flags, flags
#. スタイルのコメントはそのメッセージが使用される、ソースファイルから抽出されます。おそらくプログラマが、翻訳者のために追加した、想定している位置合わせなどの情報です。 #: コメントは、ソース内でそのメッセージが使用される正確な場所を示します。翻訳者はプログラムソースを参照する必要はありませんが、翻訳の正確さに疑問がある場合にソースを参照することができます。#, コメントは何らかの方法で、メッセージを説明するフラグです。現在、2つのフラグがあります。そのメッセージがプログラムソースの変更によって未使用となった可能性がある場合、fuzzy が設定されます。翻訳者はこれを検証し、fuzzy フラグを消すことができます。fuzzy メッセージはエンドユーザからは利用できないことに注意して下さい。もう一つのフラグは c-format であり、そのメッセージが printf 形式の書式テンプレートを持つことを示します。これは、翻訳側もプレースホルダの数と型に合わせた書式文字列でなければならないことを意味します。これを検証するツールがあります。 そのツールは c-format フラグを解除します。
さて、"空の"メッセージカタログをどうやって作成するのでしょうか。まず、翻訳したいメッセージを持つプログラムが存在するディレクトリに移動しましょう。nls.mk ファイルがあれば、このプログラムは翻訳の準備が整っています。
もし、.po ファイルが数個すでにあれば、誰かがある翻訳作業を行なっています。そのファイルの名前は language.po です。 ここで、language は ISO 639-1 2文字言語コードを(小文字で)表します。 例えば、fr.po はフランス語用です。1 つの言語に複数の翻訳成果が必要である場合は、そのファイルの名前は language_region.poとなります。 ここで、region はISO 3166-1 2 文字国コードを (大文字で)表します。 例えば、pt_BR.po はブラジルでのポルトガル語用を示します。翻訳対象とする言語用のファイルがあれば、それを元に作業を始めることができます。
新規に翻訳成果を始める必要がある場合、以下のコマンドを最初に実行して下さい。
gmake init-po
これは、progname.pot ファイルを作成します。(.pot は "完成状態の" POファイルと区別するためのものです。 T は"テンプレート"を意味します。)このファイルを language.po にコピーして、編集します。新規の言語が利用可能になったことを知らせるために、nls.mk を編集し、言語(もしくは言語と国)コードを以下のように追加して下さい。
AVAIL_LANGUAGES := de fr
(もちろん他の言語を追加することができます。)
元としたプログラムやライブラリの変更にともない、メッセージはプログラマによって変更、追加されます。この場合は始めからやり直す必要はありません。その代わりに以下のコマンドを実行して下さい。
gmake update-po
これにより、新しい空のメッセージカタログファイル(最初に使用した pot ファイル)が作成され、既存の PO ファイルにマージされます。このマージのアルゴリズムが特定のメッセージに関して確実でない場合、それは上述の "fuzzy" となります。何らかの失敗に終った場合、古い PO ファイルは .po.old という拡張子で保存されます。
PO ファイルは普通のテキストエディタで編集することができます。翻訳者は msgstr ディレクティブの後の引用符の間の部分の変更、コメントの追加、fuzzy フラグの変更のみを行なうべきです。Emacs には (予想通り) PO モードがあり、非常に使いやすいものと私は考えています。
PO ファイルを完全に埋めることは必要ありません。 ソフトウェアは、使用できる翻訳がない(もしくは翻訳が空の)場合、自動的に元の文字列に戻します。他の人により作業を引き継ぐことができますので、ソースツリー内に不完全な翻訳を含めることにも問題はありません。しかし、マージの後の fuzzy フラグを削除することを優先に考えることが推奨されています。fuzzy エントリはインストールされないことを忘れないで下さい。 これらは何が正しい翻訳になりえるかを示す参照としてのみ提供されています。
以下に、翻訳の編集を行なう際に注意すべき点を示します。
元の文字列の終端が改行の場合、翻訳も同様になっていることを確認して下さい。tab なども同様です。
元が printf 書式文字列の場合、翻訳も同じでなければなりません。また、翻訳は同じ書式指示子を同じ順番で持たなければなりません。言語固有の規則によっては不可能な場合や扱いづらい場合も起こります。このような場合は、以下の書式を使用することができます。
msgstr "Die Datei %2$s hat %1$u Zeichen."
そして、リストの最初のプレースホルダが実際にはこのリストの 2 番目に使用されます。digits$ は % の後に続く必要があり、他の書式の操作の前に使用する必要があります。(この機能は printf ファミリ関数に本当に存在するものです。メッセージ国際化以外ではほとんど使用されませんので、聞いたことがないかもしれません。)
元の文字列に言語上の間違いがある場合、それを報告(もしくはプログラムソースを直し、)正常に翻訳して下さい。修正された文字列は、プログラムのソースが修正された時にマージ可能になります。元の文字列が事実と異なる場合、それを報告(もしくは直し、)翻訳を行なわないで下さい。その代わりに、PO ファイルのその文字列にコメントを付けて下さい。
元の文字列のスタイルや調子を維持して下さい。特に、(cannot open file %s など)文章になっていないメッセージは、(翻訳する言語が大文字小文字を区別するのであれば)おそらく最初の文字を大文字にしてはなりませんし、(翻訳する言語が句読点として使用しているのであれば)ピリオドを終りに付けてはいけません。
メッセージの意味が分からない時や、曖昧な場合は、開発者用のメーリングリストに問い合わせて下さい。英語を話すエンドユーザも理解できない、または、曖昧であると判断することができる機会となり、メッセージの改良を行なう最善のものです。