GUI 翻訳での POT ファイル利用の検討

[kinichiro]

現状
GUI 翻訳では、各国担当の翻訳者達がバラバラにソースコードから直接 PO ファイルを生成しています。

問題点
ソフトウェアのリリースに対して翻訳すべき対象の文字列群があいまいでバージョン管理されていない。
翻訳済テキストを含むpoファイルの対象が明確になっていない。

• poファイルが適用できるレビジョンは、使用したソースのレビジョンだけとは限らない
• 単にソースから更新した場合、使われなくなった文字列は翻訳対象から外れるので、以前のバージョンのソフトウェアに新しいpoファイルを用いると未翻訳になってしまう

提案
リリースの確定したソースコードから 開発側またはkicad-i18n管理者側で POT ファイルを作成してもらい、翻訳者はその POT ファイルに対して翻訳作業を行うのが良いのではないか。
翻訳者はpotファイルから自国語向けのpoファイルを派生させて翻訳作業を行うのが良いのではないか。

POTファイルとは
POT ファイルは PO ファイルと同じ書式ですが、msgid のみのファイルで、翻訳対象の英文のみが含まれるファイルを指します。
Portable Object Template"のこと。（PO template fileとも。）

• ソースファイルから生成され、全ての翻訳の派生元となるファイル
• msgid 以降に翻訳すべき文字列を""内に含み、msgstr 以降の翻訳文字列部分が""となっている
• 各国語の翻訳者は、このファイルをテンプレートとして、ヘッダ部分に付随情報（翻訳者、言語など）を付加し、自国語向けのpoファイルを作る
• GNU gettext の詳細 : https://www.gnu.org/software/gettext/manual/gettext.html

ご意見よろしくお願いします。

[kinichiro]

#12 (comment) での意見がこのトピックのきっかけです。以下に抜粋しておきます。

POTについては、完全にプログラママターだと思います。
もしプログラマにPOTの必要性を説くなら、下記の２点だと思います。
　１）リリース向けのソースが確定しないと翻訳者がpoファイルを生成できない
　２）コード内文字列のtypoを変更しただけでコードから生成するpoファイルも影響を受けてバージョン互換を失う
これを重大と考えるか、当たり前だと考えるかの違いですが、今のKiCadのプログラマさん達はi18nを重視していなさそうなので、後者だと思います。
ソースレベルで翻訳文字列をどんどん変更してるので、”旧バージョンのpoファイルはリリースに入っているはずだから最新のGUI poファイルは互換性不要、リリース向けのソースが確定してからパッケージ化するまでに翻訳作業してね”ということだと私は理解しています。
もし翻訳者がGUI用poファイルの妥当性も確認したいなら、使ったソースから自前でビルドしなければならないし、なかなか無茶な要求だと思いますが。

[yoneken]

限定されたメンバーがリリース確定のソースコードから一つのPOTファイルを作成し、他のメンバーがPOTファイルを編集するという作業手順に賛成です。
この手順のほうが、翻訳作業者が気にしなければならない部分を少なくできるので、ありがたいです。

このスレッドでまとめられた意見を、KiCadの日本語翻訳グループの統一見解として良いのではないでしょうか。

[starfort-jp]

POTの言い出し元なので、コメントします。

//---
問題点について
・リリース以外のビルドに対してもpoファイルが作成されています（eg. French translation against rev 6980）ので、表記は逆の方が適切です。
eg.”翻訳済テキストを含むpoファイルの対象が明確になっていない。（poファイルが適用できるレビジョンは、使用したソースのレビジョンだけとは限らない）
単にソースから更新した場合、使われなくなった文字列は翻訳対象から外れるので、以前のバージョンのソフトウェアに新しいpoファイルを用いると未翻訳になってしまう。”

提案について
・翻訳者が扱うのは、poファイルです。翻訳対象は、potファイルから派生させたpoファイルと表記すべきです。
eg.”翻訳者はそのpotファイルから自国語向けのpoファイルを派生させて翻訳作業を～”

POTファイルについて
"Portable Object Template"のこと。（PO template fileとも。）
ソースファイルから生成され、全ての翻訳の派生元となるファイルです。
POファイルと基本的には同じものですが、使用目的によって区別され、別の拡張子が与えられます。
GNU gettext のドキュメントによれば、プログラマが xgettext を用いて作った domainname.po を domainname.pot とリネームして作られます。
これは、msgid 以降に翻訳すべき文字列を""内に含み、msgstr 以降の翻訳文字列部分が""となっているものです。
各国語の翻訳者は、このファイルをテンプレートとして、ヘッダ部分に付随情報（翻訳者、言語など）を付加し、自国語向けのpoファイルを作ります。
詳細については、下記のリンクを参照のこと。
GNU gettext : https://www.gnu.org/software/gettext/manual/gettext.html
//---
冒頭の内容に関しては、以上です。以下、雑感です。

”バージョン管理されていない”というのは全くおっしゃる通りで、そもそも未だリリース向けと開発版向けの分離すら始まったばかりなんですね。
OSSではプログラマ全てにi18n対応を要請するのは困難だと思いますので、kicad-i18n管理者がpotファイルを用意するのが現実的かと思います。
この場合の最大の問題点は、pot ファイルの作成がリリースされるソースコード確定の後になってしまうことです。
翻訳作業にも時間がかかるので、初期リリースは英語のみ、多国語対応は翻訳物がある程度まとまった後で言語パックとして提供するようなことも提案してみては如何ですか。
またリリース間隔が短いなら、各リリース毎の翻訳は難しいと思います。
この場合は、ソースを追加して複数バージョン対応のpotファイルにすべきと考えます。

[kinichiro]

本家-i18n のレポジトリに、update-po-files.sh というスクリプトがあるのに気付きました。
https://github.com/KiCad/kicad-i18n/blob/master/update-po-files.sh

中身を見てみると、.pot ファイルを作ってから　各国語用の .po を更新するようになってます。
4.0リリース前の 2015/11頃に作られてるので、その頃こういうことを検討したのかなと思います。
ただ多分これは活用されてないように思います。
翻訳者がソースコードと.poファイルだけで、それぞれバラバラに作業してるのが現状のはず。

このスクリプトの意図は .pot を元にしようということだと思うので、そこを確認しつつ、
.pot は kicad-i18n管理者 (か 理想的にはソースコード開発側) で生成してもらい、
.po を .pot をベースに更新するのは翻訳者側で行うようにしてはどうか、ということを
手順案や管理案含めて提案すると受け入れてもらえるかもしれません。

このスクリプト自体は、

• {管理者}が .pot をソースコードから生成するためのスクリプト
• {翻訳者}が .pot で 自分用の .po を update するスクリプト

の２つに分離すると使われるものになると思います。

[kinichiro]

またリリース間隔が短いなら、各リリース毎の翻訳は難しいと思います。
この場合は、ソースを追加して複数バージョン対応のpotファイルにすべきと考えます。

POTとPOのどちらで削除された行も保持しておくかというのを考えてみました。

POTで保持する場合
xgettext で -j または --join-existing オプションを使うと、継ぎ足しのPOTファイルが作れるようです。
4.0.0時点で kicad.pot を生成して翻訳して、4.0.1が出た時は xgettext -j で kicad.pot を生成すると 4.0.0 + 4.0.1 の msgid を含んだ POTファイルができるので、翻訳者は自ずと両バージョンに対応した POファイルを作ることになるでしょう。

ただPOTとPOの翻訳すべき行数が増えるのでめげるかもしれませんね。
4.0.3とかから新たに翻訳始めた国の人は、3つのマイナーバージョン分を翻訳することになるので。

POで保持する場合
POTファイルはマイナーバージョン毎できれいに生成し直し、POファイルで過去分の翻訳を持つこともできると思います。
msgmerge は --previous オプションで POTファイルからは消えている msgid も保持してくれると思います。

4.0.0 ～ 4.0.1 ～ 4.0.2 と都度都度翻訳してきた場合は、4.0.2 の PO に全ての翻訳が入っているので、4.0.3 を翻訳する時も、4.0.2.po と 4.0.3.pot で msgmerge することで差分だけを翻訳すればよいことになると思います。

4.0.3 から翻訳始める場合は、4.0.3.POT に含まれる msgid だけ翻訳すればよいでしょう。

ということで私見では、POで過去に削除されたものは持つのが良いのかなと思いました。

[starfort-jp]

@kinichiro さん
基本的にはPOTはPOの派生元であって翻訳作業で変更されるものではないので、私もPOTをクリーンにしてPOで過去に削除されたものを持つのに賛成です。

一つ考慮しなければならないのは、過去に削除されたものをどうやって保持するかです。
後方互換を持たせた場合、そのままではpoファイルのreferenceセクションが肥大化します。GUIは他のドキュメントに比べ項目数が圧倒的に多く、各レビジョンで項目数がそれほど変化しないので、含んだレビジョンに比例してファイルサイズが増大します。
一方、後方互換を持たせない場合は、ファイルの最後に#~として追加されていくだけなのでサイズの問題はあまりありませんが、繰り返すと内容が変質していきます。
以前、@yoneken さんにやって頂いたように前者のファイルサイズは小さくすることも可能で、私のリポジトリにもソフトがありますが、少々面倒です。

私、個人としては、単にPOTで更新を続けてファイルの最後に付加したままにしておくという運用で良いように思っています。

ご参考までに、6297と6996を多重参照したpoファイルをテストも兼ねて、developへPRしました。1,242,823 Byteとファイルサイズが約1.7倍になっています。

追記です(7/31)：
但し、新しい言語の翻訳を始める時に複数レビジョン対応したい場合は、POTで対応レビジョン全ての非翻訳文字列を持ったほうが余計な手間がかからないので良さそうです。
（レビジョン変更ではそれほど大きな改廃はなさそうなので、翻訳すべき行数の増加量も全体に比べればわずかです。）
またレビジョン毎にPOTを保持しておく必要がなく、常に１バージョンで１つのPOTとできるメリットもあります。
基本はレビジョン毎にPOTを作成だとは思うのですが、悩ましいところですね…

[kinichiro]

@starfort-jp さん

単にPOTで更新を続けてファイルの最後に付加したままにしておくという運用

私も、ファイルの最後に#~ で追加されるだけの方法が良いと思います。
#~ だと MO ファイルにコンパイルした時も含まれないようなので実行時に参照される
ファイルのサイズを小さくできそうだというのが理由です。

追記されたケースについて考えてみました。
新しい言語の翻訳を始める時は、過去のレビジョンに対応しても、バイナリパッケージの
過去レビジョンに含められることはないと思うので、対応優先度は低くすべきでしょう。
それでも過去レビジョンのGUIを翻訳して配布したい場合は、過去レビジョンの POT ファイル
を使って最新のPOファイルと msgmerge すれば良いのかなと思います。
POTで複数レビジョンの全てを持っていれば、新言語で過去分全て翻訳したい人に優しいですが、
レビジョン毎にそのレビジョンの文字列のみのPOTという原則の方が良いと感じてます。
レビジョン毎で翻訳対応すべき範囲が明確になると思ったからです。

難しいですね、こういうこと考えるのは（笑

[starfort-jp]

@kinichiro さん
POTについては管理側の考え方次第で、私はどちらもアリだと思います。
改廃の頻度やソフト規模にあわせて、決めれば良いのではないでしょうか。
あくまで一般論ですが、
・バージョン／サブバージョン変更では個別のPOTを作成
・レビジョン変更ではPOTを統合
という運用が理想的なようです。
これは、モジュール構成変更の有無でPOTの内容が大きく変わることによります。
もっとも、バージョンやレビジョンの違いを理解しないで番号を付けているプロジェクトも多いので、ケースバイケースで判断することが多いようですが…

今の状況を見ると KiCad のリリース頻度はそれほど高くなく、過去レビジョンに拘る必要性も感じないので、上で書かれたように、現状はレビジョン毎に作った方が手間もかからず良さそうですね。

過去のレビジョン対応についても、おっしゃる通りだと思います。
KiCad では常に最新版で問題なさそうなので、対応優先度は低くすべきに同意です。
どうも昔のMS-DOS 3.0やWindows95の悪夢が記憶に残っているせいで、古いレビジョンとの互換性を過度に気にしてしまうのには我ながら困ったものです（笑）