id:squeakerさんのコメントのように、SVNにcondenseされたソースコードが登録されてました。 今日、ちょっと山宮さんにお聞きしたのですが、ビルドする都度 condenseSourceするって本当でしょうか？ソースコードをXO実機にも載せるということは、子供たちが …

皆さんお疲れ様でした。 http://wiki.laptop.org/go/Image:StartOfMP.jpg

アップデート1716〜1719で、先月から開発してきた gettextエミュレーションエンジンがOLPC EToysのイメージに組み込まれました（id:propellaさんに感謝）。 これにより以下のことが可能になります。 イメージの外部に置いたMOファイル形式の翻訳データを実行…

翻訳処理をgettextエミュレーションに切り替えた環境で、言語切り替えのメニューを指示すると、言語の選択肢が表示されるまでに、私のそれなりに早いPCでも一瞬待たされる気がします。 調べてみると、LocaleID>>displayName で、'' という特別なキーワードを…

test2/3ベンチマークのMessageTallyを落ち着いて読んでいて、まだ見直せる余地がありました。一番最後にお知らせしたtest2のロードは0.7秒くらいでしたが、見直し後の手元の環境でのシミュレーションでは 2/3くらいに短縮できました。Squeakだけだと多分これ…

gettextランタイムは、プロトタイプ作りが先行していますが、「Linux標準だからそれを使えるようにしよう」というレベルで要件検討が止まっていて、現実の利用シナリオでどう使うのかという話が足りないと思います。 Hilaire Fernandesさんが OLPC EToys用 D…

最終的な詰めをする前に、設計判断のためイメージあわせをしましょう ＞誰とはなく いったんTextDomainのことは忘れます。 開発者にとって何がうれしいか？ OLPCは多くの言語のユーザで使われることを想定しており、翻訳データのメンテナンス作業が発生する…

OLPC版もベースは Squeakland2005(J)と同じコードベースですから、蜂須賀さんのhttp://www.smalltalk.jp/pipermail/squeak-ja/2006-June/002998.html の方法が適用できるはずです。調べてみると、その他に動的なロケール追加の機能があることがわかりました…

既存のコードを読み直した結果、NaturalLanguageTranslatorを置き換えるのではなく、External Translationの一種としてMOサポートを組み込むのがもっとも座りがよさそうなので、その方向で書き始めました。そのためにはNaturalLanguageTranslatorのインター…

Squeakland-OLPCでもこれが使われるのでしょうか？ XOのでかい画面なら問題ないのでしょうが、普通のXGAのPCで使っている人にとっては大きすぎて邪魔です。 Sugar上であればJournal経由で既存のプロジェクトを開くのでこれでいいのだと思いますが、普通のPC…

※注意：以下はWin32用VMのソースコードを読んで得られた情報です。他のアーキテクチャは調べていません。 Squeakland(.jp)で配布されている非開発者向けのキット（俗称プラグイン版）は、SecurityPluginが有効になっています。SecurityPluginが有効な場合、…

gettextをエミュレートするコードを書きかけたのですが、立ち止まってすこし調べてみました。 GNU gettextでの実装 使える場合はmmap（メモリマップドファイル）APIを使ってアクセスしている MOファイルの構造はハッシュテーブルを使うことを想定しているが…

gettextの位置づけ 実のところ私は、PO経由で翻訳を与える方式はまだあまり好きになれません。単純なダイアログの文言を翻訳するだけならあまり問題はないかもしれませんが、それがどこでどのように使われているかの確認が面倒だからです。「ソースコードが…

確かに 「colorToPatch: はselectorではなくtile wording」であるなんて、実際にコードを読んだ人でない限りわからないだろうな。 「引数を持つタイルにwordingを与える場合、:の数と場所が重要」みたいなことも知ってないといけないし、 gettextフォーマッ…