WordPress の言語別機能とそのあり方 (WordPress Locale Mechanism) 倉石 政典/Seisuke Kuraishi
-
0:05 - 0:08「WordPress の言語別機能とそのあり方」
-
0:08 - 0:13スピーカーは倉石さんです。
よろしくお願いします! -
0:19 - 0:21倉石政典です。
-
0:24 - 0:26みなさん、 WordPress 4.0 で
-
0:27 - 0:30言語まわりの大きな変化があったのを
覚えてますでしょうか。 -
0:34 - 0:37WPLANG 定数が非推奨となり、
-
0:37 - 0:40Language chooser で言語の master value を
設定するように -
0:40 - 0:42変更が行われました。
-
0:44 - 0:47こちらの画像は、日本語のインストールで
-
0:47 - 0:51外部ネットワークに繋がっていないものと
仮定してください -
0:51 - 0:55「インストール済み」に、英語と日本語があり
言語が日本語に設定されています。 -
0:58 - 1:02この状態で
日本語の翻訳ファイルを削除します。 -
1:04 - 1:09すると、インストール済みの文字列が
英語表記の Installed に変わり -
1:10 - 1:13そこから、日本語が消えて
英語だけになってしまいました。 -
1:13 - 1:15下には、「Available」と書いてありますが
-
1:15 - 1:17翻訳ファイルを手に入れられない環境では
-
1:18 - 1:21言語を日本語に設定することはできません。
-
1:21 - 1:23これは一体、どういうことでしょうか。
-
1:25 - 1:30それは、翻訳ファイルの存在がある場合に限り
言語設定ができる -
1:30 - 1:34という仕様変更が
バージョン4.0で行われたからです。 -
1:34 - 1:37なぜ、このような制限が
加えられたのでしょうか。 -
1:40 - 1:44それは「翻訳ファイル集約主義」の
考えによるものです。 -
1:45 - 1:48これは、WordPress のコア開発で
現在主流となっている -
1:48 - 1:52言語別機能に関する実装方式です。
-
1:54 - 1:56ぼくが勝手に名づけて
そう呼んでいるだけです。 -
1:56 - 2:01そういうコンセプトがある、ということを
理解していただければと思います。 -
2:01 - 2:04どういうものか
言葉で定義するならば、 -
2:05 - 2:10「言語ファイルに、各言語の特性を
機能レベルまで集約させて -
2:10 - 2:12一元的に管理するという考え」
-
2:12 - 2:16といった感じになると思います。
-
2:18 - 2:20このコンセプトを推し進めてきたのは
-
2:20 - 2:23リードデベロッパー、アンドリューネイシンです。
-
2:23 - 2:27彼はほんのすこし前まで、IAT の
国際化の責任者をしていました。 -
2:27 - 2:30「翻訳ファイル集約主義」
という基本アイディアを -
2:30 - 2:32彼が考えたのかはわかりませんが
-
2:32 - 2:37どのように実装するかは彼が中心となって
考えていたと思います。 -
2:37 - 2:40これから少しネガティブな話をしますが
-
2:40 - 2:43僕は、基本的には彼のことが大好きで
-
2:43 - 2:45尊敬できるすばらしい人物だと思っていますので
-
2:45 - 2:48誤解しないよう、よろしくお願いします。
-
2:48 - 2:54僕は、彼が国際化の責任者の立場から離れた時
本当に寂しく感じました。 -
2:54 - 2:57彼は多くの労力を費やして
英語圏以外のユーザーのために -
2:57 - 3:00WordPress をよくしてきてくれました。
-
3:00 - 3:02ネイシンありがとう。
-
3:02 - 3:05この場を借りて、心から礼をいいたいと思います。
-
3:05 - 3:11でも、安心してください。
次の i18n 責任者も素晴らしい人です。 -
3:11 - 3:13ニューネイシンこと、
-
3:13 - 3:20オーシャンナイン、
ドミニクシニグさんです。 -
3:20 - 3:23国際化関連の新しい技術責任者ですので
覚えておいてください。 -
3:23 - 3:30何か困ったことがあったときは
きっと力になってくれると思います。 -
3:32 - 3:37翻訳ファイル集約主義の実装について
具体的に説明します。 -
3:37 - 3:41例えば、このような PHP のコードがあるとします。
-
3:41 - 3:46_x というのは、
コンテキストの 2番目のパラメータにくる翻訳関数です -
3:47 - 3:48画面の内容を説明しますと、
-
3:48 - 3:53第1パラメーターの 'words' は、
翻訳対象文字列であり、ID -
3:53 - 3:58第2パラメーターの
'word count: words, characters or all?' は、 -
3:58 - 4:01ID のコンテキストを示す追加文字列です。
-
4:01 - 4:06この部分が違えば、翻訳対象の ID が同じでも
衝突すること無く -
4:06 - 4:11別のものとして訳すことができる
という仕組みです。 -
4:13 - 4:19先ほどの x から抽出された翻訳ファイル内の
エントリーがこちらになります。 -
4:20 - 4:23msgctxt が、コンテキスト
-
4:23 - 4:27msgid が、翻訳対象文字列
-
4:27 - 4:31msgstr は、翻訳語の文字列です。
-
4:31 - 4:35ワーズ?などで、のあとにある単語などに訳されるはずですが、
-
4:35 - 4:36ここで期待されているのは、
-
4:36 - 4:43アルファベットの文字列の 'words' は、
'charactors' か 'all' になります。 -
4:43 - 4:46日本語の場合は、もうすぐリリースされるバージョン4.3から
-
4:46 - 4:52'all' を選択するべきなので
画面の赤い部分はそのようになっています。 -
4:52 - 4:55そしてこの値は、
-
4:55 - 5:00こちらの画面の左下、
管理画面投稿エディタの文字数の部分 -
5:00 - 5:03文字列カウントの方式を、
単語数ベースなのか、 -
5:03 - 5:10あるいは文字数ベースなのかを決定するオプションの値として利用されます。
-
5:13 - 5:16ここまでの話で理解できたと思いますが
-
5:16 - 5:21現在 WordPress では、言語別機能で利用されるオプションの値は
-
5:21 - 5:22データベースの中ではなく
-
5:22 - 5:26各言語の翻訳ファイルの中にあります。
-
5:26 - 5:28このことを自分は知っているという方は
-
5:28 - 5:31この中にどれだけ
いらっしゃいますでしょうか。 -
5:31 - 5:34お手数ですが、
自分は知っている、という方 -
5:34 - 5:45手を挙げていただけますか?
-
5:45 - 5:49(メガネをかける)
-
5:49 - 5:55ゼロですか?
誰もいないですか? -
5:59 - 6:03参考になりました。ありがとうございます。
-
6:03 - 6:06言語別機能の挙動を制御する
オプションの値を -
6:06 - 6:09言語ごとの翻訳ファイルに保持して、
読み込ませる -
6:09 - 6:11というアイディアが出てきた時は
-
6:11 - 6:14とても合理的で良いアイディアだな、
と感じました。 -
6:14 - 6:16しかし、色々なことが出てきて、
-
6:16 - 6:19すぐにその考えは変わりました。
-
6:21 - 6:23言語別機能とは、何か?
-
6:23 - 6:28あらためて説明するまでもないと
思いますが -
6:28 - 6:35文字数での抜粋、
ISO-2022-JP でのメールなど、 -
6:35 - 6:37特定の言語環境でのみ必要な機能で、
-
6:37 - 6:42WP Multibyte Patch で取り扱って
いるような機能を指します。 -
6:42 - 6:46日本語圏の人間にはごくごくあたりまえの
存在だと思いますが -
6:46 - 6:52ところが、WordPress 本体で言語別機能の取り組みが開始されたのは
-
6:52 - 6:562012年、つい3年前です。
-
6:56 - 7:00WordPress が初めてリリースされたのが
12年前の2003年、 -
7:00 - 7:04WP Multibyte Patch が初めてリリースされたのが、
8年前、 -
7:04 - 7:062007年ですので、
-
7:06 - 7:11これは非常に遅い対応であるといえます。
-
7:11 - 7:12具体的には、
-
7:12 - 7:18こちらの、エディターの文字数ベースのカウントの実装や、
-
7:18 - 7:23こちらの抜粋関数での、文字数ベース
抜粋での対応などが、 -
7:23 - 7:28コアでの言語別機能を意識した初めての実装だと思います。
-
7:28 - 7:32ぼくは、このどちらの実装の時もチケットをみて
リアルタイムで関わっていたのですが、 -
7:32 - 7:36後々、今に至るまで
影響をおよぼすこととなる、あまり好ましくない実装を -
7:36 - 7:41このときは見過ごしていました。
-
7:41 - 7:46翻訳ファイルがないとオプション値が読み込まれない
-
7:46 - 7:49これは、データが保存されているのだから
-
7:49 - 7:51当たり前の話です。
-
7:51 - 7:57MySQL のデータが消えてしまえば
WordPress サイトが見れなくなるのと同じことです。 -
7:57 - 7:59このような事態は、めったにあってはならないことですが、
-
7:59 - 8:03翻訳ファイルに関しては色々なケースで発生します。
-
8:03 - 8:07ネットワークに繋がらない環境では、翻訳ファイルは手に入りません。
-
8:07 - 8:10ユーザーが誤って削除してしまうこともあります。
-
8:10 - 8:16また、そもそも個人ブログなどでは
公開側のインターフェイスが翻訳されている必要がない、 -
8:16 - 8:20あるいは、一時的に翻訳させたくないケースも少なくありません。
-
8:20 - 8:23ぼくのサイトでは、翻訳ファイルは管理画面だけにして、
-
8:23 - 8:25公開側では読み込んでいません。
-
8:25 - 8:29このように、翻訳ファイルが存在しないという状況が
いろいろあり得るのですが、 -
8:29 - 8:33そんなとき、機能まで完全に英語版になってしまう、
-
8:33 - 8:36抜粋がきかなくなってしまう、といったような、
-
8:36 - 8:42不便で不安定な実装は好ましくありません。
-
8:42 - 8:44誤って修正された場合、
-
8:44 - 8:48重要な機能が正しく動作しなくなってしまう。
-
8:48 - 8:51これは深刻な問題です。
-
8:51 - 8:58現在、翻訳は、GlotPress という仕組みで
ボランティアによって共同で行われています。 -
8:58 - 9:00こちらはそのインターフェイスですが、
-
9:00 - 9:03現在、WordPress 周辺の様々な文字列翻訳が
-
9:03 - 9:05こちらのシステムで行われており、
-
9:05 - 9:09WordPress.org のフォーラムの
アカウントさえ持っていれば -
9:09 - 9:13どなたでも翻訳に参加することが出来ます。
-
9:13 - 9:19こちらで行われた翻訳は、自動的に
世界中の WordPress サイトで配信されます。 -
9:19 - 9:22WordPress の管理画面で、
「新しい翻訳が利用可能です」という通知を -
9:22 - 9:24頻繁に見かけると思います。
-
9:24 - 9:27例えば、こちらのシステムで
-
9:27 - 9:34新米の翻訳者が、誤って日本語の抜粋カウントを
単語ベースに変えてしまったら -
9:34 - 9:36どうなると思いますか?
-
9:36 - 9:40すぐにネット中が
「WordPress で抜粋が行われなくなった」という -
9:40 - 9:44日本人ユーザーの悲鳴でうめつくされることになるかもしれません。
-
9:44 - 9:47しかし実際は、そこまでひどいことには
ならないと思います。 -
9:47 - 9:49なぜなら、日本人ユーザーの多くの方が使っている
-
9:49 - 9:52WP Multibyte Patch が、翻訳ファイルを利用しないで
-
9:52 - 9:56抜粋カウント方式を文字数ベースに固定する機能がついており
-
9:56 - 9:59デフォルトで有効となっているからです。
-
9:59 - 10:01したがって、WP Multibyte Patch を有効にしている方は
-
10:01 - 10:07とりあえずは、この問題を心配する必要はありません。
-
10:07 - 10:09その他、使い勝手の問題としては
-
10:09 - 10:15仕様として知られていない、先ほどゼロだったことからわかるように
-
10:15 - 10:18誰も知らない仕様です。
-
10:18 - 10:19理解しにくい。
-
10:19 - 10:26ユーザーによる編集が困難、などが挙げられます。
-
10:26 - 10:29Polyglots という WordPress 国際化の公式ページに
-
10:29 - 10:33この問題についての様々な問題や意見が投稿されているスレッドが有ります。
-
10:33 - 10:36英語ですが、興味がある方は見てみてください。
-
10:36 - 10:39こちらには、僕も意見を投稿しています。
-
10:39 - 10:41主な内容としては、
-
10:41 - 10:45翻訳ファイルは中身が常に変動して
存在自体が不安定なので -
10:45 - 10:48重要な言語機能のオプションがそこにある、ということは
-
10:48 - 10:52言語別機能の動作の信頼性を損ねている、ということや、
-
10:52 - 10:57翻訳ファイルに言語別機能のオプション値を保存する実装を廃止して、
-
10:57 - 11:06翻訳ファイルと言語別機能を完全に分離するべきである、ということなどです。
-
11:06 - 11:08投稿には書きませんでしたが、
-
11:08 - 11:10翻訳ファイルに保存しないならば、
-
11:10 - 11:17言語別のオプションは、どこに保存されるのが望ましいか、という課題があります。
-
11:18 - 11:21思いつくのは、データベースの中
-
11:21 - 11:25あるいは、フィルターできる形での値のハードコーディングです。
-
11:25 - 11:29WP Multibyte Patch は、今後
後者のアプローチで -
11:29 - 11:35実験的に取り入れていくかもしれません。
-
11:37 - 11:41これは、Make.WordPress.org のトップページに使われている
-
11:41 - 11:442012年のコミュニティサミットの時の
集合写真です。 -
11:44 - 11:51前から2列目、赤いベストのマットの右隣
チェックのシャツがネイシンです。 -
11:51 - 11:57階段の上のほう、右端で、
グレーの帽子にメガネをかけているのがぼくです。 -
11:57 - 12:04Contact Form 7 の三好さんもいるんですが
どこにいるかわかりますでしょうか。 -
12:07 - 12:10僕はこのとき以来、2,3年越しでネイシンと
-
12:10 - 12:14「翻訳ファイル集約主義」の問題点について
やりとりをしていたのですが -
12:14 - 12:18それは、冒頭で話した2014年の
バージョン 4.0 の実装で -
12:18 - 12:23ひとつのクライマックスを迎えました。
-
12:23 - 12:28バージョン 4.0 で行われた
翻訳ファイルの存在がある場合に限り、 -
12:28 - 12:31言語設定ができる、という実装。
-
12:31 - 12:34これには先程述べた翻訳ファイルがないと
-
12:34 - 12:37オプション値が読み込まれない、という問題の防止策としての
-
12:37 - 12:39意図があったように思います。
-
12:39 - 12:42真意はわかりませんが、しかしこれは明らかな
-
12:42 - 12:47本末転倒の、誤った実装です。
-
12:47 - 12:50正しくはこのようになるはずです。
-
12:50 - 12:55なぜなら、言語設定に合わせて
適切な言語ファイルを読み込むという動作が -
12:55 - 12:58言語別機能のひとつに過ぎないからです。
-
12:58 - 13:03また、これは長年の WordPress の仕様でもありました。
-
13:05 - 13:09「言語別機能は、翻訳よりも重要である」
-
13:09 - 13:12英語圏の開発者の多くは、
-
13:12 - 13:16非英語圏のユーザーにとって言語別機能がいかに大切であるか、ということを
-
13:16 - 13:18理解していません。
-
13:18 - 13:20いかにインターフェイスが日本語になっていようとも、
-
13:20 - 13:23抜粋が機能しなかったり、日本語のメールが文字化けしてしまうようなシステムは
-
13:23 - 13:25利用したくありません。
-
13:25 - 13:27逆に、インターフェイスが英語でも、
-
13:27 - 13:30便利で、日本語の処理に問題がないシステムであったなら、
-
13:30 - 13:32多くの日本人が利用するでしょう。
-
13:32 - 13:35そもそも、英語が読める人にとっては
-
13:35 - 13:38インターフェイスが翻訳されている必要は無いのですから
-
13:38 - 13:43翻訳とは、オプションで選べる、ピンのようなものであると思います。
-
13:46 - 13:52こちらのチケットで、4.0 の問題点について
話し合いが行われました。 -
13:52 - 13:56結果として「翻訳ファイル集約主義」に欠陥があること、
-
13:56 - 13:59また、言語別機能が翻訳よりも重要であるということを
-
13:59 - 14:01ネイシンが理解して、受け入れてくれたことは
-
14:01 - 14:03大きな収穫でした。
-
14:03 - 14:09そしてその後、4.0以降の言語設定の実装が
次のように変更されました。 -
14:11 - 14:15WordPress を日本語でインストールする。
-
14:15 - 14:19日本語の翻訳ファイルを削除。
-
14:19 - 14:22言語を日本語に設定することができなくなる。
-
14:22 - 14:26と、ここまでは先ほどの説明と同じです。
-
14:26 - 14:34次に、wp-config.php に 'WPLANG' 'JA' を加えます。
-
14:34 - 14:39すると、今度は日本語が選択肢にあらわれて
設定できるようになります。 -
14:39 - 14:46翻訳ファイルがないので、
インターフェイスは英語のままです。 -
14:46 - 14:54この状態で英語に設定すると、
今度は WPLANG は不要という注意が出てきます。 -
14:56 - 15:00WPLANG は実は廃止になったわけではなく、別の役割、
-
15:00 - 15:04翻訳ファイルがない場合の
フォールバックとして残っています。 -
15:07 - 15:14また、これは翻訳ファイルの有無にかかわらず、
言語設定を自由に行なえる唯一の方法である、 -
15:14 - 15:21ということを知っておいてください。
-
15:21 - 15:24WordPress の i18n の実装で
-
15:24 - 15:28「翻訳ファイル集約主義」が問題であることについて説明しましたが
-
15:28 - 15:32もう一つの大きな問題があります。
-
15:32 - 15:37それは、PHP で使われている
正規表現のライブラリーである、 -
15:37 - 15:40PCRE の挙動が不安定であり
-
15:40 - 15:42そのために、一部環境で
-
15:42 - 15:45マルチバイトの文字列が破壊されてしまうという問題で、
-
15:45 - 15:50WordPress の世界における大きなマルチバイトのバグの原因となっています。
-
15:56 - 15:59Perl 互換の正規表現の置換関数で、
-
15:59 - 16:05空白文字を、エスケープシーケンスである \s が
マルチバイト文字の一部にマッチしてしまい、 -
16:05 - 16:08文字を破壊して
文字化けを起こすことがありますが、 -
16:08 - 16:10このようなバグを引き起こすコードが
-
16:10 - 16:15WordPress のいたるところに潜んでいます。
-
16:15 - 16:20WordPress では、文字列操作の多くを
Perl 互換の正規表現に依存しているために -
16:20 - 16:24この問題が起こります。
-
16:26 - 16:28解決策として、
-
16:28 - 16:31U 修飾子を利用する方法があります。
-
16:31 - 16:36この修飾子を使うと
最初の文字列が、UTF-8 として認識されるようになり -
16:36 - 16:41\s がマルチバイトの一部にマッチしてしまうことがなくなります。
-
16:41 - 16:47しかし、一見理想的に思えるこの解決策には
落とし穴があります。 -
16:48 - 16:54PCRE U 修飾子の利用には
コンパイル時に UTF-8 サポートのオプションが必要で -
16:54 - 16:58それが全てのユーザー環境でコンパイルされているとは
限らないということが -
16:58 - 17:00徐々にわかってきました。
-
17:00 - 17:06つまり、ユーザーの環境においては
この方法はうまくいかないのです。 -
17:08 - 17:13ただでさえ、PCRE の Unicode property support が
コンパイルされているか否か、 -
17:13 - 17:14また、そのオプションにより
-
17:14 - 17:19\s の挙動が異なることまでわかってきました。
-
17:21 - 17:26これらの詳しい情報に興味がある方は、
こちらのチケットを見てみると良いでしょう。 -
17:26 - 17:28大変難しい内容ですが、
-
17:28 - 17:31PHP 開発者の方は読んでみることを
おすすめします。 -
17:31 - 17:35Unicode property support の挙動に関する PHP のバグは、
-
17:35 - 17:38なんとこのチケットでのリサーチから発見されました。
-
17:38 - 17:43発見者は、Robert Chapin さんと、
-
17:43 - 17:45Andrew Ozz さんです。
-
17:45 - 17:50この2人は、最重要になる
PCRE library 作者のところまで行き -
17:50 - 17:53問題の根源をつきとめました。
-
17:53 - 17:59この発見は、今まで不明だった
PHP のファイル互換正規表現関数の挙動を知る上で -
17:59 - 18:04多くの開発に役に立つものと思われます。
-
18:05 - 18:10PCRE が絡んだ、文字破壊の最新の解決策のゆくえを知りたい方は、
-
18:10 - 18:13こちらのチケットを定期的にチェックしてみるといいでしょう。
-
18:13 - 18:19今のところ、 WordPress コアではこの問題に対する決定的な解決策がないため
-
18:19 - 18:23チケットは、バグが直されないまま一年以上に渡り保留されていますが
-
18:23 - 18:29いつかは解決する時が来るでしょう。
-
18:29 - 18:35WP Multibyte Patch では、WordPress コアでは
直せない PCRE の問題箇所の幾つかを -
18:35 - 18:37修正しています。
-
18:37 - 18:41コアでは直せないものを、なぜ
WP Multibyte Patch で直せるのか。 -
18:41 - 18:44その秘密は、WP Multibyte Patch では
-
18:44 - 18:49マルチバイト文字列関数を提供する mbstring が PHP に組み込まれていることを
-
18:49 - 18:53プラグイン有効化の条件としていることです。
-
18:53 - 18:55そして、より安全な mbstring 系の関数で
-
18:55 - 19:00コアの問題のある PCRE 系のコードを置き換えています。
-
19:00 - 19:04WordPress コアでは、mbstring は
システム要件ではないため -
19:04 - 19:07このように、簡単に直すことは出来ません。
-
19:07 - 19:15このように、プラグインだからこそ直せる問題
というものもあるということです。 -
19:18 - 19:24最後に、日本語ユーザー全体の課題、
マルチバイト圏ユーザー共通の課題について -
19:24 - 19:26話したいと思います
-
19:26 - 19:28いま、ローカル言語チームが
-
19:28 - 19:32ローカルパッケージに、独自の言語
特有機能を追加するための自由領域が -
19:32 - 19:35制限される方向にあります。
-
19:35 - 19:39そして、近いうちにほとんどなくなるかもしれないという状況にあります。
-
19:39 - 19:41WordPress の良い所として、
-
19:41 - 19:45コンパチビリティの重視が挙げられますが
-
19:45 - 19:47これは、言い換えれば
-
19:47 - 19:52一度実装された機能はなかなか覆せないということでもあります。
-
19:52 - 19:55だからこそ、我々マルチバイト圏のユーザーにとって
-
19:55 - 19:59WordPress が使いにくくなってしまうような実装が行われないよう
-
19:59 - 20:02目を光らせていることが大切なのです。
-
20:02 - 20:08みんなで協力し、日本語についてよく知らないコア開発者の人たちを助けて
-
20:08 - 20:12WordPress がいつまでも我々マルチバイト圏の
ユーザーにとって使いやすいツールであるように -
20:12 - 20:16見守っていけたらと思います。
-
20:16 - 20:20ご清聴ありがとうございました。
-
20:20 - 20:27ありがとうございました。
-
20:27 - 20:45スピーカーは倉石政典さんでした。もう一度拍手をお願いします。
- Title:
- WordPress の言語別機能とそのあり方 (WordPress Locale Mechanism) 倉石 政典/Seisuke Kuraishi
- Description:
-
元のビデオ: http://wordpress.tv/2015/11/23/seisuke-kuraishi-wordpress-locale-mechanism/
WordPress における インターナショナライゼーション(国際化、i18n) は翻訳だけではありません。このセッションでは、英語以外の言語利用者にとって大変重要でありながら、コア開発者の間では認識として新しい「言語別機能」(language-specific functionality)を中心とした i18n 実装のコンセプトについてお話します。また、WP Multibyte Patch をコアに組込むことがなぜ難しいのか、WordPress の国際化は今後どうあるべきなのかについて、現状の WordPress が抱えている問題点に触れながら考察します。
- Video Language:
- Japanese
- Duration:
- 21:35