実行時のMOアクセス

Squeak OLPC EToys

gettextをエミュレートするコードを書きかけたのですが、立ち止まってすこし調べてみました。

GNU gettextでの実装

  • 使える場合はmmap（メモリマップドファイル）APIを使ってアクセスしている
  • MOファイルの構造はハッシュテーブルを使うことを想定しているが、MO中にハッシュテーブルを持たないことも許している。その場合は単にバイナリサーチする（そのため、文字列テーブルはオリジナル表現でソートされている）。
  • 同時に使えるtextdomainは１つだけ。切り替えるAPIはあるが動的にどんどん切り替えることはあまり考えられていない。

Ruby-GetText Packageでの実装

  • GNU gettextのRubyバインディングではなく、機能拡張されたエミュレーションである
  • 複数のtextdomainを同時に使えるようになっている
  • 初期化の際MOファイルの内容を全部メモリ上のテーブルに読み込んでいる

Squeakでの検討事項

  • 今のOLPC Etoysでは約4000のフレーズが約60個のPOに分割されています。これをそのまま同じ数のMOにするのでしょうか、それとももっと少ない数にまとめるのでしょうか？POを分割した背景は、一つのPOTだとあまりにもたくさんのフレーズが入っていて翻訳者が圧倒されるということで、同じフレーズに対する翻訳を文脈ごとに別にしたいとかの要件はなかったと思います（現実に、今は全てのPOをNaturalLangageTranslatorにインポートしてしまっています）。
  • 初期化時の処理時間と、実行中占有されるリソースとのトレードオフ。GNU gettextのようにMOファイルを開きっぱなしにして処理するとすると、起動時や言語切り替えでの遅延はないでしょうが、60個のMOファイルを開いたままになります。これはXOでは問題にならないのでしょうか？私は古い人間なのでしょうか。逆にRuby-GetTextのような方式だと起動・言語切り替えにすこし待たされるかもしれません。これは実験するつもり。
  • Squeakland OLPCとして配布する場合、従来どおりSecurityPluginはONの状態になるのですよね？そのときMOファイルはSqueakletsフォルダに置くことになり、インストール方法が問題になると思います（言語別にサブフォルダを持つという置き方もやりにくい）。今のSecurityPluginの仕組みは本当に副作用が大きくて困りますね。
  • MOを分割した場合、#translated実行時にtextdomainを確実に決定できるのか？特に#translatedNoopのsenderと#translatedのsenderが同じtextdomainになることは保障できないと思います。本当はコンパイル後のリテラルが自分のtextdomainを覚えておいてくれたら助かるのですがね。