Translate Toolkitを使ってgettext形式の翻訳データを継続的にメンテナンスする
gettextを使って翻訳データを管理する場合、翻訳データの開発ライフサイクルはおおまかに次のような流れになります。
- プログラムソース中で、翻訳可能な文字列を規定された書式で記述する
- ツールを使って、ソースコードからPOT（翻訳ソースのテンプレート）を切り出す
- POTをもとに、特定の言語向けの翻訳結果を入力したPO（翻訳データのソースファイル）を作成する。これがいわゆる翻訳作業になります。
- 開発したPOをコンパイルしてMO（翻訳データのバイナリ）を作成し、プログラムの一部として配布する
このライフサイクルは実際にはこんなに単純ではありません。実際にはプログラムソースと翻訳データが継続的に、かつ並行してメンテナンスされるため、次のようにプログラムソースと翻訳データの同期がとれていない状態になってしまいます：
- オリジナル文字列の表現がPOT生成時から変更された
- そのオリジナル文字列が使われなくなった
- 新しいオリジナル文字列が出現した。これは追加で翻訳する必要がある。
- ソースコード中でその文字列が出現する場所（これは特殊な書式のコメントとして表現されます）の名前が変わったり、新しい場所で同じ文字列が使われるようになった。
- PO中での出現順が変更した（EToysの場合、文字列の出現場所の情報を使ってソートされています）
そのため、リリース作業の一環として、既存のPOを最新のPOTのないようにあわせて同期する必要があります。
しかしこの作業はソースコードを付き合わせる非常に面倒くさい作業です。そして、OLPCの場合多くの言語のための翻訳を取り扱います。現時点でOLPC EToys用にはすでに12の言語の翻訳データがあり、今後も増えていくでしょう。とても手作業での比較修正ではやってられません。
このような作業は、Translate Toolkitというツールを使うことで大幅に負荷を軽減することができます。このツールは、OLPCで翻訳データの開発に使われているPootleと同じく、WordForgeというプロジェクトの成果物です。
ツールの準備
- このツールは内部でgettextのツールを使うので、あらかじめインストールしておくことが必要です。
- SourceForgeからダウンロードしてインストールします。
- 一部のツールは配布キットにパッケージされておらず、必要なら自分で別途ダウンロードしなくてはなりません。今回は、pomigrate2 というスクリプトをダウンロードしてインストールしておくことが必要です。
pomigrate2の使い方
このツールは次のような命名規約でファイルを用意しておくことが必要です。
from/ドメイン.po : 既存のPO（移行元） template/ドメイン.pot : 移行先（移行の基準となる）POT to/ : マイグレートした結果を保管するディレクトリ
その上で、以下のコマンドを実行します。
pomigrate2 from to template
そうすると、to/ドメイン.poが作成されます。
移行結果のPOファイルのヘッダ情報は、次のようにマージされています。
- PO-Revision-Date : fromファイルの内容が転記される
- POT-Creation-Date : 移行先POTの内容が転記される
- その他の情報は基本的に fromの内容が移される
