*国際化 [#g192bddf] ''自動で言語選択ができる機能''を実装すること。 動作イメージとしては、Apache で言うところの ''MultiViews''の機能を使って、 ''content negotiation'' する。そんなことを、PukiWiki でやってみようという試み。 ''content negotiation'' の機能を真面目に実装するイメージではない。 **イメージ [#e426a799] +''Accept-Language'' から言語を取得 +言語にあわせたスキンを選択 +文章も、その言語対応版があれば表示 ++[[WikiFarm>PukiWiki/WikiFarm]] 的な挙動に近い という動きをする機能。 **処理 [#i4de1184] -HTTP_ACCEPT_LANGUAGE >言語コードを取得する。未定義の場合は、デフォルトの言語コードとする。 < --用意した言語コードに一致している場合 ---スキンを利用する ---用意されている文書があれば、それを表示する ---Content-Language ヘッダーを追加して表示する **文書の取り扱い [#qfa5d31f] 文書ファイルの国際化を考えた際に、プラグインを1つ作ることで対応ができることに 気が付いた。イメージとしては、include プラグイン的なもの。これを、国際化対応 専用に作り上げていく。そんな感じ。 #i18n_msg(ja,ヘルプ) #i18n_msg(en,Help) みたいな(素案っす)。ファイル名一覧をどうする。とか、まぁ。考えれば色々と。 ただ、この素案だと、即日完成ですかね。LANG が等しい時しか反応しないなんて。 ---- 書き留めていた部分ですので、みなさんで色々と固めていけたらと思います。-- [[upk]] &new{2003-08-19 (火) 00:58:20}; **コメント [#i3655077] ***国際化一般 [#v84ac56f] -国際化にはもう1つ意味があるのではないでしょうか?それは、コンテンツをのぞいてどの言語でも容易にインストールでき動作することだと思います。それが第一段階かとは思いますが.. -- [[merlin]] &new{2003-08-19 (火) 02:59:01}; -保存はすべてUnicodeで行い、表示/編集時は 設置者が決めるというのではどうだろうか? 設定は、ファイル直接いじるらなくても好いようにしないと受け入れられにくいかも。あと、サーバへの負荷が問題になるかもしれない。 -- [[merlin]] &new{2003-08-20 (水) 11:06:41}; #comment ***多言語コンテンツ [#nea1000b] -言語ごとにページができてしまうのは致し方無いものだと思う。単に翻訳するなら excite,babelfishなどで事足りるが、動的コンテンツの場合には、ニュアンス的な問題も発生するので別に設けた方がいいのでは? -- [[merlin]] &new{2003-08-20 (水) 10:56:52}; #comment *** 実装方法 [#v25cc8fc] -文書フォルダを別途に掘り、文書名を同一とするのはどうだろう? 関連文書もさがし易くなる。UI では、多言語コンテンツの存在をページに表示させるプラグインにて解決できるだろう。問題点は、localizeされた文書名。文書名にASCIIのIDを付けるしかないのか? -- [[merlin]] &new{2003-08-20 (水) 11:03:02}; #comment **関連しそうな BugTrack [#vbb5a072] -[[BugTrack/363]] 言語設定LANGと独立した表示言語の設定 -[[BugTrack/147]] requireのパスチェックを修正してほしい。(LANG.lngファイル) ---- **過去の文書 [#vef73081] ***議論 [#l56ee9b1] -言語コード毎に、文書を持てることの是非。 --同一タイトルで、言語コード毎に複数文書が持ててしまうこと。 ./wiki/XXXXXXX.txt を ./wiki/XXXXXXX.ja.txt とかにするイメージを実装する際に、 ファイル名 = 文書名 = タイトル なのが PukiWiki なので、文書名とマッピングをするのか?みたいなイメージとなる。 これは、スキンを考慮した際に、同一文書にも関わらず、日本語名の文書を、 例えば、英語文書で表示するのはおかしいなぁ。という発想から。 ***独立させると [#v45570c0] 日本語ページと英語ページの文章が、お互いに疎という関係になると、 2サイト設置しているのと同じになってしまう。 スタティックな文章だからこそ、言語コード毎に用意できるものの、 ダイナミックなコンテンツを、分離させることは、問題となりえる。 **ファイル名=文書名=タイトル [#b4920f58] 理解しやすい名前に命名する。ということで考えれば、日本語であれば、 当然、文書名も日本語にすることでしょう。しかし、英語圏(シングルバイト)の 方々にすれば、読めもしなければ、入力することもできない。 このような関係にある文書名を、どう捉えるのか?という問題が発生する。 ***解決するには [#w5ea8333] マッピングテーブルを作って、管理するしかない。つまり、両方操れる誰かが その対応関係を作るしかない。 このソフトを、もっと広く利用してもらいたいと考えるのであれば、残念ではあるが 英語基準で、テーブルを作ることになる。しかし、日本発のソフトを主張したいなら、 日本語基準となるであろう。とか考えながら、デフォルト言語を、基準言語とし、 対応した言語分、サブ言語として追加する。ということで、考えてみる。 管理者の母国語を主とするのは、当然な流れであり、その管理者が理解している言語 への対応が、限界であろう。 |default_lang=ja| |lang_arry = array("ja","en");| *問題事項 [#ub5368a0] -文書を分離することの弊害 -文書名を対応付ける必要性