多言語対応関連 (使用言語の設定)†
- ページ: BugTrack
- 投稿者: Ratbeta
- 優先順位: 重要
- 状態: 着手
- カテゴリー: その他
- 投稿日: 2004-04-10 (土) 13:22:16
- バージョン:
メッセージ†
現行のPukiWikiでは、言語関連の設定をすべてinit.phpで行っていますが、
これをpukiwiki.ini.phpと*.lngに分ける必要があると思います。
修正案 : (長いのでコメントアウトしておきました)
- 別手法で実装されました。 -- merlin
- 掘り出しお疲れ様です＞merlin 言語設定自体は確かに 開発日記/2004-09-19 にて、init.php から pukiwiki.ini.php に移動させました。ただ、ここで挙げられている案には 「*.lng に言語設定を集中させる」 というアイデアも含まれている様です。こうすると、言語関係の設定が一ヶ所に集まるだけでなく、pukiwiki.ini.php の複雑さも軽減される様な印象を受けました。ちょっと管理者が楽になるかもしれないという事ですね。ちょっと検討させて下さい。 -- henoheno
- 内部コンテンツのエンコーディングがUTF-8あるいはEUC-JPだったとき、SOURCE_ENCODINGの設定と、実際にエンコーディングされている言語リソースがそれと同一である事は自明です。Samba 2.x 日本語版の設定ファイルに誓って！ であれば同じファイルにあった方が・・・ふむふむ・・・ -- henoheno
- 修正内容がいろいろと乱雑ですんで見難いと思いますがご容赦を…(^^;)。SOURCE_ENCODINGの設定を言語ファイルにおくのは、他の多言語対応スクリプトでよく使われている手法です。あと、できるなら言語ファイルは下位ディレクトリに置くべきだと思いますが…。 -- Ratbeta
- コメントありがとうございます :) 取り込むべきものはパッチではなく、その考え方ですのでノープロブレムです :) -- henoheno
- 現状の *.lng を例えば lang/ ディレクトリ (を作成してそこ) に置いたとしても、skin/skin.*.lng ファイルがそこに置けるわけではありませんから、現状はこのままがシンプルだと思います。実際に３～４ファイル置くことになったその時に考えれば十分でしょう。ただ、今思いますに、ファイル名は直した方がいいですね。拡張子をphpに揃えておかないと(アクセス権限的に)覗き見が可能になったりする可能性がありますし。それぞれ *.lng => lang.*.php, skin/skin.*.lng => skin_lang.*.php かな？ -- henoheno
- BugTrack/579 Move language settings into language resources together
- 開発日記/2004-10-17で、処理がlib/init.phpに移動されたみたいですが、これは問題だと思われます。init.phpにこのコードが記述されている場合、他の言語(もしくは文字コード)のlngファイルが追加された場合に、その度毎にlib/init.phpを編集しなければいけない必要が生じてきます。また、言語を増やしていくと、コードが肥大化してしまいます。できれば言語ファイル内の設定でお願いしたいのですが…、なにか上手い方法はありませんかね？(^^; -- Ratbeta
- (バージョン関連の話題はロードマップへ移動)
- 私個人としては、互換さえ保たれていればいくらでも手を入れていいという考えですんで… (^^; とりあえず今のコードは多言語対応としてはまずいんじゃないか、と思っているところです。かといっていいアイデアも浮かばないんですけどね (^^; -- Ratbeta
- たしかに、この部分は *.lng にあるべきものですね。ついでにいうならそういう意味では define でない（init.phpで変数からdefineへ変換する）ほうがいいかもしれません。 -- みこ
- 確かに変数にする方がいいですね。下の事項にも関わってきますし…。 -- Ratbeta
第二段階 : 言語ファイルに不足がある場合はen.lngで補填する†
- 追加された言語ファイルに最新版との不足がある場合は、表示の乱れを防ぐ為に他の言語ファイルから補填する必要があると思います。ja.lngでは文字コードの整合の問題が有りますので、en.lngからの補填が適当であると思いますが、どうでしょうか？ -- Ratbeta
- 処理としてはen.lngをロードした後に de.lng などをロード(重ねがけ)する様にして、言語リソースの漏れを無くするという事ですね。私の考えとは違った切り口ですが、指している方向は同じ様です。私が考えていたのは en をデフォルトにするべきだという事ですが、Ratbetaさんのアイデアの方が実践的ですね :) -- henoheno
- 処理の流れはそれでいいと思います。問題は、en.lngがなかったり完全でなかったりする場合ですが… (^^; -- Ratbeta
- どちらも、en.lng の存在を大前提にすることで問題ないと思います。 -- henoheno
第三段階 : encode_hintとUTF-8関連†
- 顕在化していない、もう一つの問題にも気づいています。現在はコードの中に埋め込まれている邪悪な $encoding_hint、これをコードの外に出そうと思ったとき、置く場所が無いという問題です。*.lng は UI_LANG で変動するようになりましたから、コンテンツ内部のエンコーディングとエンコーディングを合わせておく必要のある $encoding_hint を置くべき場所ではなくなってしまいました。 -- henoheno
- あ、狙っているのは、PHPコードのエンコーディングはEUC-JPに保ったまま、一部の設定ファイルとコンテンツのエンコーディングだけはUTF-8、というサイト運用を可能にする方向ですよ、念のため。これができないとUTF-8サイトの管理がいつまでも大変です。 -- henoheno
- 保ったまま運用を可能にすることもできるという理解で間違っていませんかね？-- upk
- そうですね・・・。現状よりは楽な運用環境を実現する事で、今までの様に しないことができる という状況に持って行きたいと思っています。(どうしてもUTF-8でないといけない部分を除き)大部分についてcvsやviなどを使った従来通りの運用が通用し、歌って踊れるUTF-8環境ですね :) -- henoheno
- 例えば、プラグインなどで、日本語には無い文字を表示したい場合に、EUC-JP じゃ困ることが過去にあったので、そうなると、UTF-8化できるけど、したい人はどうぞ。ていうイメージなら良いんですがね。あと、国際化の妨げにもなりますから、どうなんだろうと考えたわけです。でも、いまでも、UTF-8とかって、可逆になれない文字があると思うので、コンテンツを変換させる実装だと面倒なことになるでしょうね。IMの日本語対応のときに難儀しましたから。ということで、共存箇所次第で苦労しますね。-- upk
- pukiwiki.ini.php内でコンテンツのエンコードを指定する(あるいはユーザに指定してもらう)というのはどうでしょうか？encode_hintは消去の方向でいくのがベターではないでしょうか…。 -- Ratbeta
- $encoding_hint はもともと、コンテンツがどんなエンコードだろうと送信に別のエンコードで送ってくるブラウザからコードを識別できるように入れているもののはずです。日本語に限って言えばできれば消去してほしくはないです。 PHPconference2003 -- みこ
- したがって、*.lng(この場合、ja.lng)に入れるのが筋だと思います。（他言語は空文字列でもかまいませんが・・・） -- みこ
- ということは、(CJK含む)英語以外ではencoding_hintが必要という事ですね？accept-charset属性とかはやっぱり無効なんでしょうか？ -- Ratbeta
- CJKというよりは、１つの国でUTF-8以外の複数の文字コード（主にダブルバイト）をもっている場合が該当する可能性があります。*1 -- みこ
- ちなみに、accept-charsetはあまり信用しないほうがいいかとおもいます。（このあたりは三浦克介さんがくわしくありませんでしたっけ？ (^^; ） -- みこ
- 見つけた (^^) PHP GET/POSTメソッドでの日本語の文字化け防止 -- みこ
- ふむふむ。「encoding_hintを消す」という案は、固定値のそれに代わる何か別のアイデアと置き換えるという案なのかと思っていました。例えばエンコーディング設定を元に encoding_hint の値を動的にエンコーディングするといった方法ですね。文字化けを防止する役目がありますから、消すのはまずいです (^^; -- henoheno
- encoding_hintについてはこのトリックが突破口になるかしらん？ -- henoheno
- ふむふむ…。じっくり読ませていただきました。最終的にどんな形であれencoding_hintは必要になってくる訳ですね。 -- Ratbeta
余談 : 言語ファイルと複数Wiki†
- 言語ファイル(*.lng.php)は現状ではDATA_HOME以下に直接置くことになっていますが、これだとWikiFarmライクな構成にした場合に複数のDATA_HOMEに言語ファイルをコピーする必要が生じてきます。言語ファイルはWiki毎に異なるものではないと考えられますので、一つの言語ファイルを全てのWikiから参照できるようにinit.phpを変更する必要があると思います。 -- Ratbeta
--- init.1.26.php Sun Feb 20 23:24:50 2005
+++ init.php Wed Feb 23 20:26:49 2005
@@ -82,8 +82,8 @@
/////////////////////////////////////////////////
// INI_FILE: Require LANG_FILE
-define('LANG_FILE_HINT', DATA_HOME . LANG . '.lng.php'); // For encoding hint
-define('LANG_FILE', DATA_HOME . UI_LANG . '.lng.php'); // For UI resource
+define('LANG_FILE_HINT', LANG . '.lng.php'); // For encoding hint
+define('LANG_FILE', UI_LANG . '.lng.php'); // For UI resource
$die = '';
foreach (array('LANG_FILE_HINT', 'LANG_FILE') as $langfile) {
if (! file_exists(constant($langfile)) || ! is_readable(constant($langfile))) {
- 関連： BugTrack2/13: Korean(韓国語) support patch -- henoheno
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
