■ [Ruby] Ruby-GetText-Package-0.4.0 is out!

ちょっと気になったので、ngettext(またはn_)を実装してみました。こんな感じ。

 require 'gettext'
 
 include GetText
 bindtextdomain("plural")
 (0..10).each do |n|
   printf(n_("%d file was removed\n", "%d files were removed\n", n), n)
 end

■ このようにすることで、nによって単数形・複数形を分けて出力する事ができます。

■ で、おもしろいのが、「複数形」とはなんぞや？というのを各言語別のリソースファイルである（poファイル：メッセージカタログ）に記述できることです。かつ、1つのメッセージ自体も単数・複数の2つだけでなくいくつでも定義できます。

日本語であればあまり複数形とか意識しないのですが英語の場合は2つ、さらに4つくらいの表現に分ける必要のある言語もあるんですね。翻訳する人は大変だろうなぁ。

この辺興味のある人はRuby-GetText-Packageのドキュメントをどうぞ。ちょっとだけ詳しく書いてあります。

■ え？ で、なんで今まで実装してなかったのかって？

.... 単に知らなかったんです...ってオイ(^^;)。

＃こういうのまだあるかな？(ってまだGNU GetText全部の仕様を押さえてないらしい(^^;)）

■ [Ruby-GNOME2] RubyZilla - デモムービー

デモムービーがはやっているみたいなので、Ruby-GNOME2とGlade2を使ったデモムービーを作ってみました。全体で10分くらいのムービーでGeckoエンジンを使ったWWWブラウザを作ってしまおう、というものです。

まぁ、実際にWWWブラウザを作るにはこれから先が大変なわけですが、まぁ、それはそれということで（苦笑）。

■ こちらのGTK#とSteticというGTK#で作られたGUIビルダ(Glade2互換？)のデモに触発されて作ってたものの、こちらは5分ということなのでちょっと負けた気分....、ってコードを書く部分とかが強力に補完（省略？）されているので普通に書いてたら、私のデモの方が短いに違いない！...ってそんなところで張り合ってもしょうがないのですが(^^;)。

■ [Rails] STIなモデルを翻訳対象にする

Ruby-GetTextを使って、STIモデルが翻訳できないという指摘があったのですが、これはバグではなく仕様です。

具体的にはSTIなモデルで（updatepoで）テーブル名・カラム名を翻訳対象にしたいという場合は以下のように"ActiveRecord::Base"の文字列をファイル中に記述します。

 class Manager < User   # ActiveRecord::Base
 end

こうすることでManagerモデルのテーブル名・カラム名がmsgidとして抽出されるようになります。あとは通常どおり翻訳するだけです。
updatepoタスクでは、ActiveRecord向けにmsgidを抽出をする際に、そのファイル中に"ActiveRecord::Base"があればそれはActiveRecord::Baseのサブクラスのファイルである、とみなします。
したがって直接継承関係が無くても上記のように記述するわけです。

より詳しい情報はruby-gettext-MLのログを参照してください・・・・と思ってrubyforgeのMLログ見たら文字化けしてる・・・(ここでもsfmltojが必要か！？　昔は日本語通ったと思うんだけどなぁ、うーん)。一応、一月分のログなら見れるようです。こちらでsti-sampleと検索してみてください。

■ [Rails] STIなモデルを翻訳対象にする(2)

MLが読みづらいのでここに整理しておきます。問題の指摘内容を整理すると、

「Manager < User < ActiveRecord::Baseという関係のクラスがある（Userはemailというカラムを持つ）。

rake updatepoするとUserのみが翻訳対象になり、Managerは翻訳対象にならない(1)。

User|Emailは翻訳されるけど、Manager|Emailは翻訳されない。

UserモデルにUser|Emailが定義されているんだからそのサブクラスであるManagerモデルではManager|Emailが無い場合はUser|Emailが翻訳文字列として使用されるべき(2)」

の2点です。

まず、(1)ですが、これは上で述べた方法で回避します。厳密に言えば今のrgettextが力不足で、上記のような指定をしなくても翻訳文字列として抽出できるというのがベターなのですが、なかなかうまい実装が思いつかないのが現状です。

(2)ですが、GetTextの考え方で言うと、Manager|EmailとUser|Emailは本来別の意味を持ち、分けて考えるべきです。例えば、User|Emailは「Eメールアドレス」と訳すかもしれませんが、Manager|Emailは「管理者Eメールアドレス」と訳すかもしれません。

さて、Ruby-GetText-Packageは、国際化ライブラリの一つでメッセージをローカライズするというのが主目的のライブラリです。Railsを使う人の多くは自国だけのアプリを作るためにRuby-GetText-Packageを使っている人が多いのであまり意識されないのかもしれませんが、ここで開発者以外の「翻訳者」という登場人物を考える必要があります。

翻訳者は、poファイルだけを見て（アプリの実装を知らずとも）翻訳作業を行います。その時に、開発者が（翻訳対象が減る=DRY!という観点から）poファイルにManager|Emailを無くしてしまうとすると、翻訳者は訳すどころかManager|Emailの存在すら知ることができません。もちろん、アプリケーションの内部まで追ってManager|Emailが定義されていないことを発見するという強者の翻訳者もいるかもしれませんが、私が翻訳者だったら、

「なんだか思ったとおりの訳にならないけど、まぁ、いっか、そのままで。」

と考えてそこで終わりにすると思います。せっかく適切な訳にできる余地があるのに残念な結果になってしまうかもしれません。

Emailなんだからどこの国でも訳語は１つしかないよ、と思うかもしれませんが、国によっては訳したいポイントが違うかもしれませんので、そこは開発者自身の文化的背景だけで決めたりせず、翻訳者に委ねるべきでしょう。

したがって、Ruby-GetText-Packageというライブラリとしてはアプリケーション作者がManager|Emailを用意せざるを得ない環境を作る、というのが正しい方向性で、「なかったらUser|Emailを使ってしまう」というのは目指す方向性が違う訳です。