自分の興味の赴くままにIT技術系のネタを取りとめもなくメモっています。
Ruby言語やLinuxのネタが多いです。

July 05, 2006

[Ruby] Railsで日本語を使う時に必須のパッケージ Ruby-GetText

タイトルの割に微妙に欠点(欠点とは思っていませんが(苦笑))が誇張されている感じですねぇ。うーむ。

まず、なんだか、gemが悪者にされていますが、そもそも、Rails自体、gemでインストールされるのだから、そのタイミングで半ば無意識にRuby-GetTextもインストールしちゃえば良いんじゃないかと思います。

にしても、なんで、「gemは致命的」なんでしょう。インストーラのコマンド入力方法がプラグインに比べて難しいとは思えません。Rails使っていても、DBドライバをはじめgemでリリースされているライブラリを使う場面も少なくないですよね。Rails的にPluginより使い勝手が落ちる、というのはともかくとして「致命的」なほど差があるとはとうてい思えません。

Ruby-GetText-Packageは他のプラグインをローカライズするために使用することも可能です。なので他のプラグインより先にロードされる必要があります。さらに言えば、Ruby-GetTextに対応したライブラリがあれば、それらより先に読み込まれる必要があります。そういうことを考慮に入れるとgem(というか普通のライブラリ形式)の方が好都合です。ってそんな(GetText対応された)ライブラリは今のところ見たことないですけど(苦笑)。

「Ruby-GetTextが流行らないのは、名前が悪い様な気がするなぁ」とのことですが、おそらく全世界的に見るとGlobalizeより使われている(=流行っている(?))んじゃないかと思っています。少なくとも英語を除いても12カ国で利用されているはずですし、私のところにはかなり頻繁に質問メールが来たりしています(ホントはMLに投げて欲しいんですけどね(苦笑))。

蛇足ですが現時点でGlobalizeはカナダやヨーロッパあたりのごく一部の国で使われているくらいじゃないでしょうか。日本語のリソースも用意されてないですよね。

日本語に特化して言うと、ActiveHeartやjascaffold等の先輩がいて、そちらに慣れている方が多いという特殊事情があるため、「流行っていない」と感じられるのかもしれません。しかし、確実にRuby-GetTextを使って頂いている方は増えていると実感しています。確実に。

JapaneseUtilsとするのはあり得ないですね。日本語化のためだけのツールじゃありませんし。

「TransSid機能がない」件ですが、この機能自体は日本語化(ローカライズ)とはちょっと別機能ですよねぇ。まぁ、どうしてもと言うことなら取り込むこともできますが、私としては、TransSid機能+絵文字対応+携帯機種判別機能+α的な「携帯専用プラグイン」を作ってRuby-GetTextとは別にインストールできるようにするのが良いんじゃないかと思います。きっと今、その辺の機能をまとめたプラグインを作ると話題の人になれると思いますよ。誰かやりません?(と人頼み)

scaffoldの件はどうなんでしょう。Ruby-GetText対応版があっても良いなぁと思いますが、私自身は自前scaffoldを書いてそちらを使うようにしているのでその際にGetText化を組み込んじゃうんですよね。

「適当な英語を思いつくのがめんどくさー」という場合、Ruby-GetTextをActiveRecord翻訳専用に使えば良いんじゃないかと思います。Viewはもう日本語のみ(GetTextのメソッドは一切使わない)で。テーブルやカラム名だってローマ字で良いんじゃないでしょうか。ってか実際そういう(テーブル名やカラム名にローマ字を使う)プロジェクトは結構あるんじゃないかな(笑)。

「敷居が高い」と思うのは否定しませんが、単純にその学習(インストール)コストを高く見積もりすぎな気がします。一度Ruby-GetText-Packageの開発手順を学習できれば驚くほど簡単にメッセージの日本語化、およびその維持ができると思っています。

まぁ、単純なアプリはともかくとして継続的なRailsアプリ開発でのローカライズツール・ライブラリとしてRuby-GetText-Packageを導入することを考えてはいかがでしょうか。その際には必然的にソースコードのメンテナンスコストに比重が重く置かれるようになるでしょう。

まぁ、ともかく、Ruby-GetTextもまだまだな点があることは事実です。

もし、改善案などがあれば、ご相談ください。ってかパッチください(笑)。

[Ruby] Railsのプラグインについて思うこと

Railsのプラグインの話が出たのでついでに書いておこう。

実はtDiaryのプラグインを開発していた時も思っていたんだけど、優秀で汎用性のあるライブラリに成りうる機能がプラグインとしてRails専用になっちゃうのはちょっと寂しいなぁ、と思う今日この頃。その方が作りやすいのはよくわかる(tDiaryのプラグインの時に経験済み)んだけどね。

例えば、ActiveRecordのサポートプラグイン。ActiveRecord自体はRailsが無くても使えるけど、ActiveRecordサポートプラグインってRailsが無いと動かせないよね?(これ勘違い?だとしたらスマン)

本日のツッコミ(全2件) [ツッコミを入れる]

Yugui [でもRails勉強会で私が最初にRuby-GetTextのことを知ったとき、うっかり「それってGNU gettext..]

むとう [するどいですねー。痛いところをぐっさりと(苦笑)。 本文では名前の良し悪しについてはわざと言及しませんでした。 ..]


July 05, 2007

[Rails] Ruby-GetText+Railsのキャッシュ

rubyonrails-talkでRuby-GetTextでキャッシュってどうやるの?という質問があった。そういえば、この質問、過去にも何回かあったなぁ、と思ってちょっと見てみたら、Page/Action/Fragmentの各キャッシュのうち、Action/Fragmentについてはあっさりと対応できることがわかった。具体的には以下のコードをどこかしら(プラグインやapplicaton.rbあたり)に追加すればOK。

module ActionController
  module Caching
    module Fragments
      def fragment_cache_key_with_gettext(name) 
        fragment_cache_key_without_gettext(name).gsub('?', '.').gsub(/:/, ".") << "_#{Locale.current}"
      end
      alias_method_chain :fragment_cache_key, :gettext
 
      def expire_fragment_with_gettext(name, options = nil)
        return unless perform_caching
 
        key = %r{#{fragment_cache_key_without_gettext(name).gsub('?', '.').gsub(/:/, ".")}}
        self.class.benchmark "Expired fragments matching: #{key.source}" do
          fragment_cache_store.delete_matched(key, options)
        end
      end
      alias_method_chain :expire_fragment, :gettext
    end
  end
end

上記はFragmentキャッシュの実装なんだけど、実はActionの方もこちらを呼んでるのでこれだけでよいはず。

使い方はRails本体とまったく変わらないけど軽く説明しておこう。念のため言っておくけど、この例ではArticleというモデルを利用している。あ、そうそう、init_gettextとか、Ruby-GetTextの諸々の設定は先に済ませておくように。

# app/controller/articles_controller.rb
class ArticlesController < ApplicationController
  caches_action :show   #showのアクションをキャッシュ
   :
   :
  def show
    @article = Article.find(params[:id])
  end
  #とりあえずcreate時にキャッシュをクリアする。
  def create
    @article = Article.new(params[:article])
    if @article.save
      expire_fragment(:action => "list")  #Flagmentキャッシュをクリア
      expire_action(:action => "show")   #Actionキャッシュをクリア
      :
      :
  end
# app/views/articles/list.rhtml
<h1>Listing articles</h1>
<% cache do %>   これ以降がキャッシュされる
  :
  :
<table>
  :
  :
</table>
  :
  :
<% end %>   ここまで

要はまったくGetTextを意識する必要がなく、オリジナルのRailsの意識のままで使うことが出来る。ステキ。

Pageキャッシュが最強なのは言うまでもないんだけど、こちらは難しそうなのでちょっと棚上げ。でも、Scaffold直後(+GetText化済み)の10レコードくらいのサンプルアプリケーションの一覧表示でも、Actionキャッシュは2.4倍, Fragmentキャッシュは、1.5倍程度高速化できたので、ちょっと複雑なビジネスロジック、DBアクセスがあればもっと高い効果があるはず。

思いもかけず簡単に実装できてしまったのでちょっと不安も残るけど、せっかくのなのでこの機能を次バージョンのRuby-GetTextに含める予定。

ひとまず、どなたか追試してみません?

[Rails] Ruby-GetText+Railsのキャッシュ(2)

もうちょっとだけ。キャッシュが実際に効いてるかどうかを目で見るには、キャッシュファイルが作成されたり削除されたりを確認するのが手っ取り早い。で、config/environment.rbの一番下に以下の記述を追加。

ActionController::Base.fragment_cache_store =
  ActionController::Caching::Fragments::FileStore.new("/home/mutoh/rails/cache/")

こうしておくと前述の例では以下のようなファイルが生成される。

/home/mutoh/rails/cache/
`-- localhost.3000
    |-- articles
    |   |-- list_en.cache
    |   |-- list_fr.cache
    |   |-- list_ja.cache
    |   `-- show
    |       `-- 24_ja.cache
    `-- articles_ja.cache