PukiWiki/国際化

国際化†

現在の国際化対応から一歩進めて、次バージョンでの実装方針などを 考えていくページです。

Unicode化†

各国で利用を想定すると、やはりUnicode化されていないと厳しい局面も多いでしょう。

• PukiWiki/1.4/UTF-8化 を任意でというわけにもいかないのかなぁ？

スキンの切り替え†

自動で言語選択ができる機能を実装すること。

動作イメージとしては、Apache で言うところの MultiViewsの機能を使って、 content negotiation する。そんなことを、PukiWiki でやってみようという試み。

content negotiation の機能を真面目に実装するイメージではない。

イメージ†

1. Accept-Language から言語を取得
2. 言語にあわせたスキンを選択
3. 文章も、その言語対応版があれば表示
   1. WikiFarm 的な挙動に近い

という動きをする機能。

処理†

• HTTP_ACCEPT_LANGUAGE

  言語コードを取得する。未定義の場合は、デフォルトの言語コードとする。

  • 用意した言語コードに一致している場合
    • スキンを利用する
    • 用意されている文書があれば、それを表示する
    • Content-Language ヘッダーを追加して表示する

メッセージファイル(.lng)の考え方取り扱い†

PukiWiki 本体†

PukiWiki 本体に絡むメッセージに関しては、従来通りの ex. ja.lng で管理する。 これは、LANG.lng ファイルが肥大化傾向にあり、各サイト毎の運用状況を考慮すれば 不用なメッセージとなってしまう部分もあり、本体部分とプラグイン部分を分離管理 することを目的としている。

プラグイン†

プラグインの独立性を確保する観点から、プラグイン毎に管理する。 また、現在のプラグイン埋め込み方式から分離することで、 プログラムが分からない人であっても、翻訳作業が容易に行えるようにする。 また、翻訳追加に伴うプログラムファイル本体への改修の発生を抑止し、 バージョン管理がスムースに行えるようにする。

意見†

• YIabXJUxsAGhqgug -- ookvupvye 2014-06-12 (木) 06:27:05

デバイス対応†

i_mode.ini.php や jphone.ini.php など User-Agent から判断しデバイス対応を 行っているが、このデバイスも、各国毎に異なる場合があり、考慮すべき事項となる。

文書の取り扱い†

文書ファイルの国際化を考えた際に、プラグインを１つ作ることで対応ができることに 気が付いた。イメージとしては、include プラグイン的なもの。これを、国際化対応 専用に作り上げていく。そんな感じ。

#i18n_msg(ja,ヘルプ)
#i18n_msg(en,Help)

みたいな(素案っす)。ファイル名一覧をどうする。とか、まぁ。考えれば色々と。 ただ、この素案だと、即日完成ですかね。LANG が等しい時しか反応しないなんて。

書き留めていた部分ですので、みなさんで色々と固めていけたらと思います。-- upk 2003-08-19 (火) 00:58:20

コメント†

国際化一般†

• 国際化にはもう１つ意味があるのではないでしょうか?それは、コンテンツをのぞいてどの言語でも容易にインストールでき動作することだと思います。それが第一段階かとは思いますが.. -- merlin 2003-08-19 (火) 02:59:01
• 保存はすべてUnicodeで行い、表示/編集時は 設置者が決めるというのではどうだろうか? 設定は、ファイル直接いじるらなくても好いようにしないと受け入れられにくいかも。あと、サーバへの負荷が問題になるかもしれない。 -- merlin 2003-08-20 (水) 11:06:41

多言語コンテンツ†

• 言語ごとにページができてしまうのは致し方無いものだと思う。単に翻訳するなら excite,babelfishなどで事足りるが、動的コンテンツの場合には、ニュアンス的な問題も発生するので別に設けた方がいいのでは? -- merlin 2003-08-20 (水) 10:56:52
• gettext での実装ができたとしても、プログラムのプログラマと翻訳者との分離がしやすくなるだけで、コンテンツの問題は裁けていないという認識です。この部分は、どう料理するのが良いのでしょうかね？ちょっとひらめかないんですよねぇ。プラグインとしてヒアドキュメントとして裁くのも手かなぁなんて思ったりもしています。でも、１ページというファイルには、各国語が入るので、汚いような感じもするけど。 -- upk 2004-11-14 (日) 04:03:59
• コンテンツの多言語化に興味があります。プラグインでも一部は対応できると思うので、 http://www.phpheaven.net/projects/phplang/ あたりを PukiWiki 向けにカスタマイズして使ってみることに挑戦してみようかと思います。 -- asari 2005-09-08 (木) 08:07:30
  • 日ごろお世話になっている Fink のサイトから phpLang の改変済みソース (GPL2です) を拝借して、ブラウザの送る ACCEPT_LANGUAGE を見て各国語のコンテンツを表示する(リダイレクトする) PukiWiki のプラグインをでっちあげてみました。改善、というより、カスタマイズ、といより、改悪という感じですが、まあ、動いているようです。 -- asari 2005-09-08 (木) 23:48:08
  • 冒険者な方は、svnレポジトリからダウンロード (プラグイン, 国旗) して、お試しください。Revision 98 では、うまく動いているようです。 -- asari 2005-09-09 (金) 21:24:43

    HTTP_ACCEPT_LANGUAGE や Cookie の値をみて適当な言語のページに
    リダイレクトする PukiWiki プラグイン。 使い方は、
    0. (必要に応じて) PukiWiki を UTF-8 で動かす。
    1. 国際化したいページ hoge を hoge.ja hoge.en などにコピーする。
    2. hoge というページを改めて作成する。
    3. hoge と hoge.ja hoge.en の内容の行頭に #phpLang と付け加える。
    ページ hoge は問答無用でリダイレクトされるページになることに注意。
    画面右上に登場する国旗をクリックすると、その言語のページに移動します。
    Javascript と Cookie を有効にすると、明示的に選んだ国旗を覚えていてくれます。

    • 多言語コンテンツ対応に取り組んでます。採用した基本ルールはとても単純です。以下にメモを書いておきます。 -- toydev 2017-05-29 (月) 22:10:00
    • サブドメインの先頭が ja だったら日本語、en だったら英語というルールを採用。サブドメインの文字列を解析して LANG 定数を設定するよう pukiwiki.ini.php を書き換える（別のルールにしたいなら LANG の設定方法を変えればいいだけ）。 -- toydev 2017-05-29 (月) 22:14:11
    • DATA_DIR や DIFF_DIR 等のディレクトリ定数に LANG wo -- toydev 2017-05-29 (月) 22:15:25
    • DATA_DIR や DIFF_DIR 等のディレクトリ定数に LANG を組み込んで、言語によって読み込まれるデータフォルダが自動的に切り替わるようにする。例えば「DATA_HOME . LANG . '/wiki/'」とする。 -- toydev 2017-05-29 (月) 22:16:26
    • wiki, diff 等のディレクトリを各言語ごとにコピーして用意する。 -- toydev 2017-05-29 (月) 22:17:28
    • 言語間リンクはinterwikiを使うなり、必要に応じてカスタムタグを作るなりしてがんばる。設定だけでほとんど本体は触らずできる。 -- toydev 2017-05-29 (月) 22:21:38
    • カスタムタグ＝プラグインのこと！500エラーでページの書き換えができない…。 -- toydev 2017-05-29 (月) 22:26:34
    • スパム対策の副作用で、元のページにURLが含まれていると編集ができません。分量がある場合、別のページを作った方が良いかもしれません -- umorigu 2017-05-29 (月) 22:58:51

実装方法†

• 文書フォルダを別途に掘り、文書名を同一とするのはどうだろう? 関連文書もさがし易くなる。UI では、多言語コンテンツの存在をページに表示させるプラグインにて解決できるだろう。問題点は、localizeされた文書名。文書名にASCIIのIDを付けるしかないのか? -- merlin 2003-08-20 (水) 11:03:02
  • 表示する側とか翻訳する側の人にとって、基準となるファイルのために、フォントを入れることを要求するかどうかということになるでしょうから、まぁ、そうなるのだと思います。-- upk 2003-09-27 (土) 17:58:38
• WikiFarm のイメージでいく前提で、どこかに紐付情報のページを作成する案。
  例えばen,ほげ,テストというFarmがあるとき、WikiFarmのルートの紐付情報のページ(InterFarmとか)に紐付内容を書く事で、Farm間の行き来を簡単に出来る仕組みを提供するのはどうでしょうか。

  en	ほげ	テスト
  Help	ヘルプ	使い方

  UIは例えば、en-FarmのHelp,ほげ-Farmのヘルプ,テスト-Farmの各ページについてはen,ほげ,テストのドロップダウンリストが出てくる(表示位置はスキンで指定)。選択すると指定したFarmの該当ページに移動できる。ページ名の制約がなくて、国際化以外の用途に活用できそうなのはメリット。デメリットはフォントの問題。英語ユーザーは、ほげやテストの選択肢が化け化けで見えない… -- にぶんのに 2003-09-27 (土) 18:49:07
• レンタルサーバとかでは、PHP の gettext って有効になっているものなのでしょうかね？ -- upk 2003-10-05 (日) 17:46:53
  • XREA は だめっぽいですね。 -- merlin 2003-10-05 (日) 19:11:40

    './configure' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex' 
    '--enable-i18n' '--with-xml' '--with-mysql=/usr/local/mysql' 
    '--with-pgsql=/usr/local/pgsql' '--enable-track-vars' '--enable-discard-path' 
    '--with-gd' '--enable-gd-native-ttf' '--with-zlib-dir=/usr' 
    '--with-jpeg-dir=/usr' '--with-pdflib=/usr/local' '--enable-shared-pdflib' 
    '--with-tiff-dir=/usr/local' '--with-freetype-dir=/usr' 
    '--with-png-dir=/usr/local/libpng' '--disable-debug' '--enable-debug=no' 
    '--enable-debugger=yes' '--enable-memory-limit=yes' '--enable-magic-quotes=yes' 
    '--with-exec-dir=/usr/bin' 
    '--with-config-file-path=/usr/local/apache_shared/conf' 
    '--without-system-regex' '--with-dbase=yes' '--enable-bcmath=yes' 
    '--enable-ftp' '--enable-versioning' '--enable-safe-mode' '--enable-sockets' 
    '--with-mcrypt=/usr/local/lib/libmcrypt' '--disable-posix-threads' 
    '--with-apxs=/usr/local/apache/bin/apxs'

  • VineLinux は、4.2.3だけどなんでもありなので入っていますが、Redhatだとたぶん入っていないのでレンタルサーバなどではちょっときついと思います -- merlin 2003-10-05 (日) 19:21:44

    './configure' '--prefix=/usr' '--with-config-file-path=/etc' 
    '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic'  
    '--enable-inline-optimization' '--with-apxs=/usr/sbin/apxs' 
    '--with-exec-dir=/usr/bin' '--with-bz2' '--with-regex=system' '--with-gettext' 
    '--with-gmp' '--with-gd' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' 
    '--with-ttf' '--with-zlib' '--with-gdbm' '--with-openssl' '--with-layout=GNU' 
    '--enable-debugger' '--enable-magic-quotes' '--enable-safe-mode' 
    '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' 
    '--enable-yp' '--enable-ftp' '--enable-wddx' '--without-mysql' 
    '--without-oracle' '--without-oci8' '--with-xml' '--with-expat-dir=/usr' 
    '--with-dom=/usr' '--enable-xslt' '--with-xslt-sablot=/usr' 
    '--with-dom-xslt=/usr' '--enable-iconv' '--enable-mbregex' '--with-namazu=/usr' 
    '--with-kakasi=/usr' '--enable-mbstring' '--enable-mbstr-enc-trans' 
    '--enable-versioning' '--enable-zend-multibyte'

    • ふむ。では、gettext互換用に関数を作って、利用できる場合には、mo を利用して、駄目なら互換関数を利用(po)で、という考え方も考慮すれば、大丈夫かなぁ？というか、どうあるべきなのかなぁ？と思うんですよね。 -- upk 2003-10-05 (日) 21:36:47
  • gettext.zip にドライバと、サンプル po と mo ファイル、gettext が無効のとき用の互換関数を作ってみました。これだと、*.lng も廃止。スキンも、enとjaで分ける必要も無くなると思います。あと、プラグイン毎にメッセージを分離できます。どうでしょう？まぁ、チューニングの余地はあると思いますけどね。 -- upk 2003-10-06 (月) 02:29:23
  • わおっ、素早い。gettextが使えると便利ですね。 ただ、i18nモジュールとの競合がどうなるのかなぁ? -- merlin 2003-10-06 (月) 12:06:01
    • うぅ。互換時は mo 読めません。po で我慢。というすごい仕様です。-- upk 2003-10-06 (月) 17:50:42
  • とりあえず、lng ファイルから po を切り出して mo を作っています。(うぅ、なんだこの文章) -- upk 2003-10-08 (水) 01:35:19
  • po分離は終了しましたが、一部、メッセージを共有している箇所もあり、難儀しています。段階的な作業が現実的かなぁ。-- upk
• スキンについてはofficial:欲しいプラグイン/57で要望が出ているように、手動で切り換えることもできるような仕組みもほしいですね。 -- reimy 2003-10-06 (月) 21:21:33
• mbstring 互換関数の UTF対応も必要になるのかなぁ? -- merlin 2003-10-07 (火) 09:20:04
• gettext の実装を行ってみました。本体への改変も終了し、テストしています。現在だと、以下のようになっています。-- upk 2003-10-14 (火) 00:36:53
  • プラグインの独立性を確保するという観点から、プラグインのみ gettext を採用する。
  • pukiwiki 本体への gettext の採用は見送るというか、lng のまま維持する。また、プラグイン間で、共通して利用するような語は、ここへ登録して利用することも、妨げない。
  • それとも、本体を gettext対応し、プラグインは、やらない？ふーむ。
  • こんなところで、どうでしょうか？

• i18n.zip を添付しました。これは、gettext に対応した PukiWiki です。誰か人柱を募集いたします。プラグインの全てを改修しちゃっています。また、一部、対応していないものもありますが、これは、lng 対応から漏れていたものです。暫定的に放置しました。lng ファイルは、本当に本体で必要なもののみにし、小さくしています。これだけでも実現すれば、プラグイン開発は、間違いなく独立できますから、便利になると思います。-- upk 2003-10-14 (火) 01:38:45
  • $_no_subject、$_no_nameについて、lng にあるものの、po を参照しちゃっているので、１つ修正すればよいものなどは、lng に残すほうが便利そうなんですけど、まだ、実装が中途半端になっています。-- upk 2003-10-14 (火) 01:45:01
• 昔、yomi searchを改造して、英語用と日本語用に設定ファイルをAccept-Languageで切り分けるようにしていたことがありますが、DCとか一部のブラウザや標準で日本語を指定してない場合、英語表記になってしまう問題がありました。結局、Accept-Languageでやるのはやめて、Path-indoを使って見かけ上別のページにすることでかたをつけました。自分としてはCookieでやるでいいと思いますが。 -- Logue 2004-09-13 (月) 22:25:23
• ふむ。Accept-Language盲信することなかれ、ですか。ブラウザには毎度泣かされそうですね -- henoheno 2004-09-14 (火) 20:49:27
• 英語リソースを叩き台に国際化対応をした例として、MacOSXのブラウザShiiraの開発でスマートな手法だなぁと思ったのがあります。http://hmdt-web.net/ の http://hmdt-web.net/shiira/localization/localize.html です。 -- bebebe 2004-10-24 (日) 18:20:43
  • Webに入力フォームを用意して英語と対になる言葉を入力してもらって、リリース時に入力内容を元にリソースファイルを作るって事ですね？
    確かにgettextにせよ、lng方式にせよ、PukiWikiでも真似出来そうですね。 -- にぶんのに 2004-10-24 (日) 18:57:33
• やっと、gettext での目処がたちました。po を読むのではなく、gmo を php で読めるようにできました。これで、gettext をサポートしていない php でも使えるなぁ。 -- upk 2004-10-27 (水) 21:09:44
  • おおっ。 -- merlin 2004-10-27 (水) 22:41:58
• そういえば、似たようなものにIPBというフォーラムがありますけど、管理人画面から言語翻訳できるようになっているのが印象的でした。自分のアイデアだと、:configあたりに言語表示の設定をいれるというのもいいのでは？と思っています。page_readigなんかでも使われてますしね -- Logue 2004-10-27 (水) 23:12:06

• みなさんにご相談なんですが、gmo が読めるPHPの実装は... => BugTrack/748 gettextリーダー

関連しそうな BugTrack†

• BugTrack/363 言語設定LANGと独立した表示言語の設定
• BugTrack/147 requireのパスチェックを修正してほしい。(LANG.lngファイル)
• BugTrack/748 gettextリーダー

• BugTrack
• 開発版
  • リポジトリ
  • 開発日記
• :CategoryDev
  • PukiWiki2
  • PukiWiki/1.5
  • PukiWiki/1.4
  • PukiWiki/1.3
  • メーリングリスト
  • 開発談義
  • 雑談
• 開発者向け情報
  • Books
  • プラグイン

最新の16件