BugTrack/748

Category: :Internationalization

[国際化] gettext の利用 / extension の利用 / gettextリーダーの作成†

ページ: BugTrack
投稿者: henoheno
優先順位: 普通
状態: 着手
カテゴリー: 本体新機能
投稿日: 2004-11-14 (日) 13:13:53
バージョン:

[国際化] gettext の利用 / extension の利用 / gettextリーダーの作成

↑

ポイント†

1) PukiWikiのメッセージを国際化するにあたり、gettext を利用できないか
- PHP の extension である GNU gettext extensionを利用できないか
- gettext extension の存在しない PHP環境のために、gettextエミュレータを用意できないか

2) PukiWikiがgettextを利用する場合、どのように設計するか
- リソースの数と種類 (ドメインは単一か、あるいは複数用いるのか)
- リソースの配置場所
- リソースの作成手段とその共有方法
- リソースの利用形態 (PukiWikiに組み込む形態)

3) gettextエミュレーターは現実的に動作するか
- gettext extension が存在しない場合にシームレスに動作するか
- 現実的な速度で動作するか

↑

ちょっと確認: GNU gettext†

http://www.gnu.org/software/gettext/
- manual http://www.gnu.org/software/gettext/manual/gettext.html

gettextメモ -- http://home.catv.ne.jp/pp/ginoue/memo/gettext.html

Python ライブラリリファレンス: GNU gettext API
- http://www.python.jp/pub/doc_jp/lib/node268.html

↑

ちょっと確認: PHP GNU gettext extension†

http://jp2.php.net/manual/ja/ref.gettext.php

"gettext checks for files once and keeps them in cashe. Especially it means that if it doesn't find your files it won't search again, so restart Apache after any directory changes!! "

<?php
// translation file: D:\Apache\htdocs\mypage\locale\bgr_BGR\LC_MESSAGES\messages.mo
putenv("LC_ALL=bgr_BGR");
bindtextdomain('messages', 'D:\Apache\htdocs\mypage\locale\\');
echo gettext("Hello");
?>

PHPのGNU gettext extensionを利用しているプロダクト
- squirrelmail (GPL) -- http://www.squirrelmail.jp/
  - http://cvs.sourceforge.net/viewcvs.py/squirrelmail/locales/

よくきたblog: PHP de gettext
- http://elf.no-ip.org/blog/index.php?categ=1&year=2004&month=11&id=1100620101

↑

メッセージ†

みなさんにご相談なんですが、gmo が読めるPHPの実装は概ねできたものの、PukiWiki での国際化を実装する上での方向感ってあっていますかね？個人的には、本体の lng は、今のままでも良いとして、プラグインに関して、開発者と翻訳者の分離から plugin_XXXXX_init() 内で行うのは、プログラムソースに手を入れることになるため不適切と考え、かと言って本体用の lng に吸収するのも違うだろうと考えています。ということで、gettext で実装できればと考えていましたが、PHP のビルドオプションということで敷居が高いこともあり、悩むところでした。ということで、gmo を読む部分の出来栄えにも左右しますが、あっていそうなら、一気に、前のようにパッチでも作りまくろうと思っています。じゃないと、下の添付ファイルもそうなんですが、これって結構疲れるんですよねぇ。-- upk 2004-11-03 (水) 17:19:46
- 人柱>upk:自作/PHP/gettext.php募集します。えいやぁの作りなので、チューニングのアドバイスもいただければ幸いです。-- upk 2004-11-03 (水) 17:19:46

お、言語リソースを収めるフレームワークが現れた :) PHPで実装したgettextリーダーですか。今週末にでも触ってみようと思います -- henoheno 2004-11-03 (水) 20:08:27
- よろしくお願いします。lng以外のメッセージは、翻訳側からすれば、プログラム更新に振り回されて大変ですから、楽にさせてあげないと。-- upk 2004-11-05 (金) 01:41:55
といっても、最初にやるのはPHP gettextモジュールの用意とか、そのテストとか、gettextそのものの資料確認*1なんですけどね (^^; あまり期待しないで下さい (^^; -- henoheno 2004-11-06 (土) 00:01:56
了解しました。個人的に思っているのは、国際化を行う前に mbstring や gettext なんぞ不要な国々でも、PHPとして問題ないようにしておく必要があるのだろうと思っています。ということで、gettext もそうですが、前に話題になった mbstringエミュレータも、あわせて検討しておくのかなぁ？っていうイメージでいます。まぁ、こちらでも色々とやってみます。 -- upk 2004-11-08 (月) 01:50:23
昨日触ってみました。 test-msgunfmt.php だけしか動かせていませんが、30msが29msくらいにはなりましたので後で圧縮したものをあちらに添付しておきますね :) -- henoheno 2004-11-08 (月) 21:12:53
お手数をおかけします。趣味の問題なのかなぁ。と思いましたが、パフォーマンスアップにつながるんであれば、その作法に習おうと思います。違和感はありませんしね。あと、方向感って、どうですかね？国際化をやったことがある人なら、gettext って違和感なく入れるんですけど、やっていないと、ちょっと敷居が高くなるところもありますからね。まぁ、慣れと言えばそうですけどね。 -- upk 2004-11-09 (火) 00:40:21
- スキンの折り合いが微妙ですけど、プログラマと翻訳者とデザイナ*2は分離されたほうがいいとおもってますから、基本的には賛成です (^^) -- みこ 2004-11-09 (火) 01:20:04
  - そうなんですよね。この考えをスキンに組み込むことはできるんですが、よりプログラムチックになってしまうんですよねぇ。なので、この部分はペンディングかなぁ。-- upk 2004-11-09 (火) 02:07:20
- ただ、これを使用するのは .php (本体およびプラグイン）ですよね？だとしたら、できればPHP初心者のために、お手軽な.po版と汎用的なgmo版とあったほうがいいかもしれないけど（もう両方あるに等しいのかもしれませんが (^^;）・・・ -- みこ 2004-11-09 (火) 01:29:05
  - PHP用の、はじめての gettext という感じのものですか？ -- upk 2004-11-09 (火) 02:07:20
そうそう、そういう意味ではユニバーサルデザインにするために、ナビゲーションバーおよびツールバーで直接ページを指しているもの（リロード・トップ・最終更新・ヘルプ）はすべてアクションプラグインにしませんか？ -- みこ 2004-11-09 (火) 01:41:55

最新 cvs に gettext エミュレーション部分のみを組み込むと 1-gettext.diff.0 というイメージです。これから、lang をいじくり、pot を生成してという作業を進めます。あとpotを生成するスクリプトを devel の下にでも入れておくと便利かなぁ。というところです。ディレクトリを作成したかったので、差分では無理に index.html なんか作っています。 -- upk 2004-11-14 (日) 03:05:12
- このパッチの適用のみで止めておくと、lang と gettext との共存ができる状態ですので、gettext化したければ進めることもできると思います。逆に、一気に進めない方が良いんでしょうかね？環境準備だけ整えて、ドキュメントなどの整備を行ってという流れとか。まぁ、パッチをここに添付するにしても、１個にはせず、複数個に分けることにします。-- upk 2004-11-14 (日) 03:22:22
とりあえず、gettext話用のBugTrackに移動しましょう :) *3 -- henoheno 2004-11-14 (日) 13:13:08
了解しました。この件の派生として、gettext化した場合に、gmo を生成する必要がでてきますから、その環境について色々とやっています。Linux, FreeBSDなどの環境は、まぁ良いとして、Windows 環境下でも幸いにして GNU の方でバイナリが準備されていたので、敷居として高くならないで済みました。upk:国際化で現在、まとめています。 -- upk 2004-11-14 (日) 13:27:17
lnag ファイルを見ていますが、重複項目はあるは、日本語と英語で、一致していないところもあるし、ふーむ。というところです。$_tracker_messages の btn_name って、Name なんですかね？ページ名なんですかね？ gettext だと、Name って名寄せされちゃうんですよね。trackerって使ってないので、よく分からないんですよ。-- upk 2004-11-15 (月) 00:58:17

↑

20041115.zip†

20041115.zip は、gettext部分の本体パッチに加え、
- pot などの生成に関するシェルスクリプト
- refererプラグイン
- calendar2プラグイン
  の固有メッセージをlng ファイルから抹殺し、po にしています。いっきにやろうとしたんですが、同じ英語表記で日本語が違う部分を吸収できないので、メッセージを確認しながら、やっていかないと駄目みたいですね。あとは、mo を生成すれば終わりです。-- upk 2004-11-15 (月) 02:13:41

pukiwiki/develに以下のシェルスクリプトを入れておきました。

ファイル名	用途
po_php2pot.sh	potを生成するためのものです。ソース更新時は常に実行します。
po_update.sh	既に翻訳がされている ja.po などを、更新された potファイルを基に、最新化(マージ)します。
po_po2mo.sh	ja.poから mo ファイルを生成します。

こんなところです。-- upk 2004-11-15 (月) 02:13:41

IIS環境下で実験してみたら、gettext() の文字列は、SJISになって戻るようなので、bind_textdomain_codeset() で明示しないと、環境によっては厳しいようなので、次回パッチ添付時には、改定しておきます。 -- upk 2004-11-16 (火) 21:44:08
お疲れ様です ;) 20041115.zip を試しました。devel/ 以下のスクリプト(私はpukiwikiというディレクトリにpukiwikiを置いていないので、ちょっとディレクトリ指定を削って)を実行して locale/ja/LC_MESSAGES/pukiwiki.mo を生成し、うまく #calendar2() が「～は空です。」と(日本語を)表示することを確認しました。 -- henoheno 2004-11-16 (火) 22:01:39
ただ、gettext extensionを組み込んだ(gettext extensionにpukiwiki.moを処理させることを期待した)状態ではうまく動作しない様でした。そのへんは試されていますでしょうか？ -- henoheno 2004-11-16 (火) 22:02:45
```
if (! extension_loaded('gettext')) {
        require(LIB_DIR . 'gettext.php');
}
```
- 実は、通しのテストはさっきしていました。gettext の脱着が簡単な Windows 環境でですけが。うまくいかない＝文字化けなら、先に書いた bind_textdomain_codeset() あたりだと思います。-- upk 2004-11-16 (火) 22:55:29
- PHPのバージョンにも依存するんですかね？ 4.1.2 という古いので動かしたら、確かに英語になっていました。ちょっと調べます。-- upk 2004-11-16 (火) 23:37:53
- ja だと駄目で、ja_JP だと日本語になります。Windows環境下とLinuxとかだと、動きが違うようなので、もう少し確認します。-- upk 2004-11-16 (火) 23:43:35
mbstring.php と同様に、周囲のif文の追加をお願いします :) -- henoheno 2004-11-16 (火) 22:05:11
- 実は、この部分って気が付いていまして、既に修正はしていました。あとで、ちょっと po 対応を増やして、修正版を添付しておきます。-- upk 2004-11-16 (火) 22:32:57
20041117.zip WindowsXP(4.3.1), Debian(4.1.2), FC1(4.3.4) の環境でテストしてみました。Debian だけ、テストがちょっと足りないんですが、今日現在の状況ということで、添付しておきます。-- upk 2004-11-17 (水) 02:22:32
LinuxとWindows環境で、setlocale まわりの確認を行ってみようと思っています。 -- upk 2004-11-17 (水) 08:42:52
20041118.zip お手数をおかけしました。結局、PHP の殆どのバージョンで確認するはめになってしまいました。http://museum.php.net/ は便利ですね。これで、問題ないんじゃないかと思います。-- upk 2004-11-18 (木) 02:29:02
plugin.php で、各プラグインが gettext を行う場合にお呪いを書かないように、制御しちゃうようにしました。毎回同じお呪いを書かせるのなら、呼ぶ側で１度という発想です。メッセージカタログが存在していなければ、親(PukiWiki)ドメインのままなわけですから。 -- upk 2004-11-20 (土) 13:46:51
- プラグイン毎に切り替えるべきかしらと思っていましたが、結局その方がいろいろ楽そうですね :) -- henoheno 2004-11-20 (土) 16:28:32
  - パフォーマンスを考えれば１個ですが、プラグインの独立性確保とサードパーティ製を考慮して、どっちでもいける方が良いんだろうな、というイメージです。あと、PukiWiki本体で管理されるプラグインは、１つに吸収することもできるし分離することもできる道を残しておきながら、でもメンテを考えると分離しないほうが楽なはず。という整理もしています。-- upk 2004-11-20 (土) 16:54:00
未実装関数がなくなりましたので、PHPでサポートされている関数がエミュレートできるようになりました。あと、PHPのマニュアルに書かれている通りに関数がサポートされていないような感じなので、その部分の確認が終わった後、添付しておきます。 -- upk 2004-11-22 (月) 21:07:41
あと、gettext_noop ( N_ ) の扱いについて、PHP ではサポートされていないようなので、gettext のサポートを問わず、ダミー関数を作ると便利なので、そのように修正しておきます。 -- upk 2004-11-22 (月) 21:13:46
お疲れ様です :) お手元ではgettext extensionがある状態でも動きましたでしょうか？であれば安心です -- henoheno 2004-11-22 (月) 22:19:24
- 動いていますよ。PHPバージョンの差異を吸収するのに難儀しましたが。-- upk 2004-11-22 (月) 23:09:18
PHP 4.2.0で追加になった関数がまともに動くのは 4.3.2 からということが分かりました。3.0.7 当時からある関数は、PHP3 で機能をどうしたら有効にできるのかがわからなかったため、確認できていません。4.0.4pl1 からは、機能していることは確認できています。-- upk 2004-11-23 (火) 02:19:44
20041122.zip - 翻訳数などは変わっていませんが、エミュレーション部分の未実装がなくなっています。あと、devel のスクリプトの一部を、ちょっとだけ変えています。-- upk 2004-11-23 (火) 03:59:54

順次、整理していきますが、ちょっとだけ。ページを分けますか？どうしましょう？

理由などは、upk:PHP/国際化/ドメインでうだうだ書いています。簡単に書くとこんな感じです。

↑

2) PukiWikiがgettextを利用する場合、どのように設計するか†

↑

リソースの数と種類 (ドメインは単一か、あるいは複数用いるのか)†

PukiWiki本体が配布するアーカイブの単位で１つと考えています。その理由は、

１ドメインの方が管理がらく。
xgettextコマンドで、拡張子が php のものだけ拾えばよい。
言い換えれば、ドメインを分割すると、ファイル単位で指定するか、スクリプトを作るかなどの対応が必要となる。

メッセージカタログというファイルが単一なので、パフォーマンス的にも良い

以下の利用を考慮して、複数ドメインでの稼動もサポートしておく。

サードパーティ製プラグインへの対応
本体の翻訳のみならず、サードパーティ製プラグインの国際化も容易となる
本体は lng ファイルで吸収できていると認識

翻訳作業を行うこと＝プログラムソースに手を入れることの撲滅

プログラムとメッセージを分離することで、翻訳のみの作業に特化できる(役割分担)

メッセージのカスタマイズ(プラグインのみであれば簡単)

というイメージです。

お疲れ様です。上記でコメントしたのちまた考えましたが、単一ドメイン方式だと、PukiWikiやそのメッセージを個別にカスタマイズしたり、個別にプラグインを抜き差しした場合に、ユーザーにコマンドラインでの作業を強要してしまいそうですね。動的にリソースをコンパイルするような機能でもない限り。 -- henoheno 2004-11-24 (水) 21:14:43

みこさんが言われていた、po を読むという前の版と組み合わせが良いんでしょうかね？ちょっとやってみますかぁ。 -- upk 2004-11-24 (水) 21:21:01

↑

リソースの配置場所†

pot および po ファイルは、稼動時は不要です。ドメイン構成の決定後に、単一構成に決定した場合には、po を分けるが妥当だと思っています。現状は、単一・複数でもいけるだろう以下のような構成を案としました。

案１

pukiwiki
└─locale
    │  └─ pukiwiki.pot, es_ES.po, ja.po, ns_NL.po
    ├─es_ES
    │  └─LC_MESSAGES
    │      └─ pukiwiki.mo
    ├─ja
    │  └─LC_MESSAGES
    │      └─ pukiwiki.mo
    └─nl_NL
        └─LC_MESSAGES
            └─ pukiwiki.mo

案２(複数ドメイン構成を考慮した場合)
po の保存先を間違えると危ないです。

pukiwiki
└─locale
    │  └─ pukiwiki.pot
    ├─es_ES
    │  └─LC_MESSAGES
    │      └─ pukiwiki.mo
    │           pukiwiki.po
    ├─ja
    │  └─LC_MESSAGES
    │      └─ pukiwiki.mo
    │           pukiwiki.po
    └─nl_NL
        └─LC_MESSAGES
            └─ pukiwiki.mo
                 pukiwiki.po

仮に複数ドメインにした場合には、以下のようになると思います。

pukiwiki
└─locale
    │  └─ pukiwiki.pot, edit.pot, article.pot ...
    ├─es_ES
    │  └─LC_MESSAGES
    │      └─ pukiwiki.mo, edit.mo, article.mo ...
    │           pukiwiki.po, edit.po, article.po ...
    ├─ja
    │  └─LC_MESSAGES
    │      └─ pukiwiki.mo, edit.mo, article.mo ...
    │           pukiwiki.po, edit.po, article.po ...
    └─nl_NL
        └─LC_MESSAGES
            └─ pukiwiki.mo, edit.mo, article.mo ...
                 pukiwiki.po, edit.po, article.po ...

total:
today:
yesterday:
now: 3