【Python】gettextモジュールを用いて国際的な男になってみた

Google App Engineでアプリケーションを作ろうと考える以上、表示言語はもちろん英語を使わなければなりません。なんてったって全世界の人がアクセスできるわけですからね。

しかーし。我々日本人にはアレルギーとでも言わんばかりの英語嫌いがありまして、日本語のインターフェースにしない限り、どんなによいアプリでも誰も使ってくれません。それはさておいても、これからの国際社会を生き残るためには、「国際化対応？英語でアプリケーションを作ってハイおしまい！」でよいわけが無く、簡単にローカライズが出来るような仕組みを理解した上でアプリケーションを作ったほうがいいと思うわけです。

御託はこれぐらいにしまして。
というわけで、Python標準機能のローカライズモジュール"gettextを使用しまして、アプリケーションのローカライズにチャレンジしてみました。
参考にしたサイトはこちら。
2006-01-18 - himainuの日記
21.1 gettext -- Multilingual internationalization services（Python2.5.2公式ドキュメント）
6.27 gettext -- 多言語対応に関する国際化サービス（Python2.3日本語化ドキュメント）

公式のドキュメントを見ると意味不明な関数の羅列が並んでいて、コレでいったいどうすればいいんだと途方にくれてしまいます。
こんなときは、実装されたソースを読めばいいんです。なんといったってCやJavaと違いソース＝モジュールですから、いちいちソースをダウンロードしてくる手間すらありません。インタプリタ言語って素敵。
gettext.pyをエディタで開いて格闘すること1時間、おおよその動きはつかめました。図にまとめるとこんな感じです。



なんだか射的の的みたいなステートチャートになってしまいましたが、要するに先ほど紹介しました参考サイトの中で指摘されているように、「gettext.install()」を呼び出して「_('MESSAGE')」みたいにアンダースコア関数を使えばいいだけです。たったの2ステップ。滅茶苦茶楽勝です。

さっそくやってみました。
まずは翻訳元になるソースを書いて、pythonインストールフォルダにあるTools/i18n/pygettext.pyスクリプトを呼び出します。
python pygettext.py test.py
みたいに。



うまくいきました。途中%の使い方を間違えて散々苦労している姿が見受けられますが気にしないでください。
pygettext.pyスクリプトを呼び出すとpo形式のファイルが出力されますので、コレをエディタで開いて思う存分に翻訳します。以下、翻訳内容です。手を加えたところは強調表示しています。

---

# TESTTEST.
# Copyright (C) 2008 akisute
# FIRST AUTHOR <[e-mail]>, 2008.
#
msgid ""
msgstr ""
"Project-Id-Version: 0.1\n"
"POT-Creation-Date: 2008-05-08 10:44+JST\n"
"PO-Revision-Date: 2008-05-08 00:00+JST\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: japanese\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=Shift_JIS\n"
"Content-Transfer-Encoding: ENCODING\n"
"Generated-By: pygettext.py 1.5\n"


#: test.py:13
msgid "Q.E.D \"Ripples of %s Years\""
msgstr "Q.E.D \"%s年の波紋\""

---

最も重要なのは一番下のmsgstrと、ヘッダ中のContent-Typeです。特にContent-Typeのcharsetは極めて重要で、poファイルの文字エンコードとあわせないとうまくいきません。

編集したら次はTools/i18n/msgfmt.pyスクリプトを呼び出して、poファイルをmoファイルにします。
python msgfmt.py poファイルのファイル名（拡張子は不要）
私はpoファイルのファイル名をja.poにしていたので、python msgfmt.py jaと入れたらうまくいきました。

で、生成したファイルを以下のように配置してみました。

C:\Python25\workspace>tree /f
フォルダ パスの一覧
ボリューム シリアル番号は 0000EE57 1C83:607F です
C:.
│  ja.po
│  test.py
│  utf8ja.po
│
└─locale
    └─ja
        └─LC_MESSAGES
                ja.mo

ポイントは、install関数の引数localdirの指定と、LC_MESSAGESと言うフォルダを間に挟むことと、moファイル名を引数domainで指定することでしょうか。localdirとLC_MESSAGESの間にlanguagesフォルダがあって、これはなにやら環境変数から取得するだの何だのと言う話があったのですが、さっぱりわからないのでディレクトリ名をjaとしてみました。

moファイルも生成したし、早速試してみましょう。
・・・やっぱりだめでした。明らかにmoファイルを読み込んでくれていません。99%がlanguageフォルダの指定がうまくいっていないせいだと思われます。
だってWindowsの環境変数にLANGUAGEもLANGもLC_ALLも無いですし。だからといっていちいち環境変数を設定しなければ動かないシステムなんて欠陥です。第一環境変数に左右されるシステムなんてちょいと問題があります。
ですが、gettext.install()はそのままではlanguageを引数に取れません。仕方が無いのでgettext.translation()を使うことにします。再度試してみました！



ばっちりですね！
いやースクリプト言語はデバッグが難しい！ここまで来るのにだいぶ苦しみました。完成したときには正直軽く小躍りしてしまいましたよ。

・・・が。ダメです。まだ完成ではありません。
poファイルの文字エンコードが「Shift_JIS」じゃないと動作してくれないのです。UTF-8に変えて再度moファイルを生成し、試すと文字化けします。
別にShift_JISでいいじゃん？確かにその通りなのですが、Googleの発表によるとすでにWeb上のリソースの半数はASCIIではなくUnicodeになっているそうなので、ここでその流れに反するようなまねをするわけにはいきません。なんとしてもUnicodeで動作させたい。
Content-Typeの指定ミスかと何回も見直しましたがそうではない様子。困りました。

ここでNullTranslation.install()メソッドのソースを見直してみると・・・第2引数にunicode=Falseというものが指定されています。どうもこれが怪しい。さっそくt.install()としているところをt.install(unicode=True)にして再実行してみました。



ブラボー！やはりこいつでした。この引数の値に応じて_にバインドする関数をgettextとugettextで変化させているのが原因だったようです。

さて、次はこの成果をGoogle App Engine上で利用できるかどうかを試さなくてはいけませんね。
アクセスしてくるURLに応じて適切に言語体系を振り分ける必要がありそうです。どうしようかな・・・