gettext関係今後の課題

Squeak OLPC EToys

gettextランタイムは、プロトタイプ作りが先行していますが、「Linux標準だからそれを使えるようにしよう」というレベルで要件検討が止まっていて、現実の利用シナリオでどう使うのかという話が足りないと思います。
Hilaire Fernandesさんが OLPC EToys用 DrGEO IIを作ったことをアナウンスしていました。http://lists.laptop.org/pipermail/etoys/2007-October/001257.html
これをどう扱うかはよい例題になりそうなので考えてみます。実際考えてみると、誰もやったことがないと思われる非常に興味深い問題であることがわかってきました。

参考：現状のDrGEOIIパッケージはどう作られているか？

  • パッケージのコードは全て DrGEOII-* という新規クラスカテゴリに入っています。
  • 配布されているSARの中身を見てみると、いくつかの言語の翻訳データが PO形式で含められていて、MOとして使うのではなく、preambleでインポートするようになっていました。

課題1: 何を基準にtextdomainを分割するか？

gettextの考え方では、翻訳辞書はtextdomainという単位に分割して管理します。

  • 同じ原語に対して、TextDomainが異なれば別の訳語を使うことができます。
  • textdomainにつき１つPO（翻訳辞書のソースファイル）・MO（翻訳辞書のバイナリファイル）を作成します。

従来のSqueakでは、イメージ全体の中に一つだけ翻訳辞書があり、そこ（NaturalLanguageTranslator）でイメージ内のリテラルに対する訳語が統一的に管理されていました。gettextの概念モデルで言い換えると、イメージ全体で共有されるグローバルなtextDomainがただ１つだけあるという感じでしょう。

（Squeak以外の）普通の環境でgettextを使う時、多くの場合は開発・配布するアプリケーション（EXEファイル、またはその集合体であるパッケージ）やプラグインの名前をtextdomainに使うようです。このようにすると、アプリケーションの配布単位と、PO/MOを分割する単位が一致しますので、管理もやりやすく合理的です。
以降の議論では、Squeakでも同様の考え方をとると仮定します。そうすると課題１は、アプリケーションを配布する単位の問題に変換されます。

課題2：配布される「アプリケーション」の単位

Squeak以外の普通の環境では、実行ファイル（EXE）、あるいはその集合体をまとめてパッケージとして配布しています。そしてそれをターゲット環境にインストールしたとしても、ファイルシステム上の別のファイルとして、明確に境界線を引くことができます。
一方、Squeakの場合、SAR・パッケージなどいくつかの配布方法がありますが、いったんインストールされると、イメージの海の中に渾然一体と融合しますので話がややこしくなります。
現状は、Bertさんのサジェスチョンに従い、Monticelloのパッケージを想定しています。

課題3：実行時のドメイン名の認識方法

Squeak以外の普通の環境の場合、プログラムの明確なメインルーチンとその入口があるので、初期化処理の中で自分自身のtextdomain名を宣言する（bindtextdomain())することができます。
一方、Squeakの場合は、融合されたイメージの中では、明確なメインルーチン構造というのがありません。それに、そもそもイメージ中には複数の「アプリケーション」が融合しているかもしれませんので、「自分自身＝アプリケーションという単位」のアイデンティティすら明確ではありません。

現在考えている基本的な方針では、「クラスカテゴリに対して、それが所属しているMonticelloのパッケージ＝配布アプリケーション→textdomainも一意に決められる」はずだから、#translatedの実行時に senderのクラスカテゴリから動的にドメインを求めようとしています。
さらに、ドメインの宣言は、アプリケーションの実行（の初期化処理）時に動的に行うのではなく、パッケージインストールのpreambleなどである意味静的に行います。その際、クラスカテゴリ→ドメインのマッピングも定義します。

課題4：実際に使用するドメイン名の管理

一つのイメージに複数のパッケージを混ぜてインストールしてもぶつからないよう、textdomain名はユニークにつける必要があります。Monticelloパッケージ名とあわせるとか慣習を決めれば問題なく運用できると思いますが、その慣習の設定が必要です。

課題5：アプリケーションパッケージ用のPOTの切り出し

山宮さんといっしょに作ってきた GetTextExporter2 + TextDomainManager で、基本的な仕組みは実現済みです。パッケージがインストールされ、textdomainが宣言された状態のイメージでエキスポートを実行すると、各ドメイン別に分割して PO/POT を切り出せます。

課題6：翻訳辞書の配布・アップデート方法

普通なら tar ballに MOを入れておいて展開してもらえばいいのですが、Squeakの場合は SARなど従来使われている配布形式で、イメージの外部に置かれるファイルを含めておいてターゲットにインストールする手法を確立する必要があります。こういうのは今でもできるんでしょうか？>識者の皆様
また、MOという外部ファイルで翻訳辞書を持つので、従来のようにアップデートストリームで流してちょこっと訳語を追加というのは簡単にはできなくなります。
もしかしたらSqueakだけで PO→MOの変換ができるといいかもしれません。

課題7：アプリケーションのインストールとSugarのジャーナルとの関係

OLPCのSugar環境では、アプリケーションを終わるとき、ジャーナルという日記帳のようなものに、やりかけのActivityの状態が版管理されて記録されていくという考え方をしています。アプリケーションの中で対応する形式のファイルを保存するという考え方はありません。Squeakに追加インストールされたアプリでも同様のふるまいをする必要があります。しかし今は追加アプリについてこのようなことがうまくいっておらず、技術的な課題を解決する必要があります。（詳細は、http://lists.laptop.org/pipermail/etoys/2007-October/001261.html とそれに続く議論参照）
MOの配布・インストールの仕組みは、この技術的課題の解決手段と整合したものでなくてはなりません。

課題8：既存の翻訳インフラとの棲み分け・整合性

たとえば LanguageEditorはどうなるの、とか。現在一番悩んでいるところです。