gettext実行時サポートの目的とスコープの案
最終的な詰めをする前に、設計判断のためイメージあわせをしましょう ＞誰とはなく
いったんTextDomainのことは忘れます。
開発者にとって何がうれしいか？
OLPCは多くの言語のユーザで使われることを想定しており、翻訳データのメンテナンス作業が発生する可能性は高くなります。従来方式だと、翻訳データが更新される都度イメージを作りなおす必要がありました。（アップデートストリームの話はここでは意図的に割愛します）しかしMOを外出しすれば、MOの入れ替えだけで済むようなり、メンテナンス・ビルドの負荷が軽減します。
翻訳者にとって何がうれしいか？
gettextの使い方を知っている人なら、Squeakの細かい機能を（あまり）知らなくても、またSqueakを入れなおさなくても、翻訳データをメンテナンスしてSqueak上で実際に試してみることができます。
NaturalLanguageTranslatorとの関係
どのようなロケールが存在するかは NaturalLanguageTranslatorがつかさどっているため、このオブジェクトとも統合する必要があります。しかし、単純に #translationFor: が GetTextを使うようになってしまうと、LanguageEditorや GetTextExporter(2)の動作にMOの内容が影響してしまいます。Preferenceで切り替えるのも操作ミスを呼んだり煩雑になりそうなので、入り口を2種類設けて（MOを使う可能性があるバージョンと、常に翻訳辞書を使うバージョン）、呼び出す側で使い分けられるようにします。
そして、今回のバージョンではLanguageEditor/GetTextExporter(2)は、MOの中身が何であれ常に従来どおり翻訳辞書を使うようにしておくのがよいと思います。
