他のバージョンの文書9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

第 44章多国言語サポート

目次
44.1. 翻訳者へ
44.1.1. 必要事項
44.1.2. 概念
44.1.3. メッセージカタログの作成と保守
44.1.4. PO ファイルの編集
44.2. プログラマへ
44.2.1. 技能者
44.2.2. メッセージ記述の指針

44.1. 翻訳者へ

PostgreSQLプログラムは(サーバ、クライアントともに)メッセージが翻訳されていた場合、好みの言語でそのメッセージを出すことができます。 翻訳メッセージセットの作成と保守は、その言語を理解しPostgreSQLの成果に貢献したい人間の手伝いが必要です。 この作業にはプログラマである必要は全くありません。 この節では手伝いのしかたを説明します。

44.1.1. 必要事項

協力者の言語の熟練度については判断しません。 この節ではソフトウェアツールについてを説明します。 理論的には、テキストエディタのみが必要です。 しかし、これは自分で作成した翻訳メッセージを試そうとはしないという、あまりあり得ない場合のみです。 ソースツリーを構築する際に、--enable-nlsオプションを使用していることを確認してください。 これにより、全てのエンドユーザがとにかく必要とする、libintlライブラリとmsgfmtプログラムが検査されます。 作業を試す際には、インストール手順の適切な部分に従ってください。

新規に翻訳作業を始め,(後述の)メッセージカタログのマージを行ないたい場合、GNU版と互換性を持った実装のxgettextmsgmergeという両方のプログラムが必要です。 将来はパッケージ化されたソース配布物を使用する場合にxgettextを必要としないように変更する予定です。 (CVS版ではまだこれが必要です。) 現在GNU Gettext 0.10.36以上を推奨します。

使用するマシンのgettextの実装については、文書がいっしょに付いてくると思います。 以下のいくつかはおそらく重複していますが、追補すべき詳細についてはその文書を参照してください。

44.1.2. 概念

英語による元のメッセージとそれを基に(たしかに)翻訳されたメッセージの組み合わせは メッセージカタログ に保持されます。 片方は(関連するプログラムはメッセージカタログを共有していますが)各プログラム用の、もう片方は対象とする言語用のものです。 メッセージカタログには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フラグを解除します。

44.1.3. メッセージカタログの作成と保守

さて、"空の"メッセージカタログをどうやって作成するのでしょうか。 まず、翻訳したいメッセージを持つプログラムが存在するディレクトリに移動します。 nls.mk ファイルがあればこのプログラムは翻訳の準備が整っています。

もし、.poファイルが数個すでにあれば、誰かがある翻訳作業を行なっています。 そのファイルはlanguage.po と名前が付けれています。 ここで、languageISO 639-1 2文字言語コードを(小文字で)表します。 例えば、fr.poはフランス語用です。 1つの言語に複数の翻訳成果が必要である場合そのファイルの名前は language_region.poのようになります。 ここで、regionISO 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という拡張子が付いて保存されます。

44.1.4. PO ファイルの編集

POファイルは普通のテキストエディタで編集することができます。 翻訳者はmsgstrディレクティブの後の引用符の間の部分の変更、コメントの追加、fuzzyフラグの変更のみを行なえばよいのです。 Emacs には(予想通り)POモードがあり、非常に使いやすいもです。

POファイルを完全に埋めることは必要ありません。 ソフトウェアは使用できる翻訳がない(もしくは翻訳が空の)場合自動的に元の文字列に戻します。 他の人が作業を引き継ぐことができますので、ソースツリー内に不完全な翻訳を含めることにも問題はありません。 しかし、マージの後のfuzzyフラグを削除することを優先に考えることが推奨されています。 fuzzyエントリはインストールされないことを忘れないでください。 これらは何が正しい翻訳になりえるかを示す参照のためのみ提供されています。

以下に、翻訳の編集を行なう際に注意すべき点を示します。

  • 元の文字列の終端が改行の場合、翻訳も同様になっていることを確認してください。 タブなども同様です。

  • 元がprintf書式文字列の場合、翻訳も同じでなければなりません。 また、翻訳は同じ書式識別子を同じ順番で持たなければなりません。 言語固有の規則によっては不可能な場合や扱いづらい場合も起こります。 このような場合は、以下の形式を使用することができます。

    msgstr "Die Datei %2$s hat %1$u Zeichen."

    そして、リストの最初のプレースホルダが実際にはこのリストの 2 番目の引数に使用されます。 digits$は%の直後に続く必要があり、他の書式の操作の前に使用する必要があります。 (この機能はprintf系の関数に本当に存在するものです。 メッセージ国際化以外ではほとんど使用されませんので、聞いたことがないかもしれません。)

  • 元の文字列に言語上の間違いがある場合、それを報告(もしくはプログラムソースを直し、)通常に翻訳してください。 修正された文字列は、プログラムのソースが修正された時にマージ可能になります。 元の文字列が事実と異なる場合、それを報告(もしくは自ら直し)翻訳を行なわないでください。 その代わりに、POファイルのその文字列にコメントを付けてください。

  • 元の文字列のスタイルや調子を維持してください。 特に、(cannot open file %sなど)文章になっていないメッセージは、(翻訳する言語が大文字小文字を区別するのであれば)おそらく最初の文字を大文字にしてはなりませんし、(翻訳する言語が句読点として使用しているのであれば)ピリオドを終わりに付けてはいけません。 項43.3 を読むと参考になります。

  • メッセージの意味が分からない時や、曖昧な場合は、開発者用のメーリングリストに問い合わせてください。 英語を話すエンドユーザも理解できない、または、曖昧であると判断することができる機会となりメッセージの改良を行なう最善のものです。