WordPressの多言語化をコアがどうサポートするのかしないのか、プラグインで複数言語をどう持つのかについての議論がWordCamp Europe 2015で行われたらしい

Photo CC BY-SA 2.0 Andrey Savchenko

WordCamp Europe 2015 で Drupal のコントリビューターを招いて、WordPressの多言語機能について話し合ったということで、Make.にレポートが上がってました。ヨーロッパはいろんな言語が混ざり合っていて、複数言語を話す人（Polyglots）もたくさんいる土地柄なので、この話が欧州で行われるのはなるほど感があります。

WordPress › WordCamp Europe 2015 – Multilingual Discussion « Make WordPress Core

Drupal の多言語機能の概要(Drupalの人の談話)

Drupalはすでにいくつかの多言語用の機構が組み込まれていて、Drupal 7ではコンテンツが何語なのかを指定することができるモジュールがある。WPにもあるi18nの機構もすでにある。

リリース予定のDrupal 8では、コンテンツの翻訳用のUIを提供する。

7と8でデータの持ち方が違う（西川感想：え、マジで？WordPressが常にアップデート前提でみんなで進む感じなのに比して、Drupalはバッサリ捨てて前に進むというのは聞いていたけど、もう、本当に7でできたサイトは8にはいけない感じなのがすごいですね。。。）。

7では、ポストがコピーされる。問題化するのは他のモジュール（プラグインかな？）が多言語をサポートしていない場合に、全部表示されちゃったりする。

8では、ポスト自体はコピーせずポストメタ的なところに保存する。タイトルとかコンテンツなどなどを。

WPからDへのQとA

Q. Drupalはどうやってひとつのコンテンツを言語違いということでグルーピングしてるの？

A. もしポストが他のポストの翻訳なのであれば、リンクするためのフィールドが持たされている。D7は2つのポストに分かれてるからそれでひもづけるということ。D8の場合には1ポストなのでメタ情報として、言語属性を持ちつつ保存される。

Q. 問題化しているのはどんなこと？

A. （西川注：D7でのことだと思われる）2個の違うポストになっているので、プラグインが多言語化を考慮していなければ、システムはそれらを異なるコンテンツだと認識するので問題になる。UIとか。たとえば、レイティング（西川注：星をつけるとか）のプラグインがあったとして、同じコンテンツで言語違いのポストは、そのレイティングをシェアしたいはず、など。

コンテンツに言語属性を持たせるいくつかのWordPress プラグインがとっているアプローチ

言語とコンテンツをどのようにまとめたり識別したりしているのか、いくつかの多言語化プラグインを見てみた。

• WPML: 別々の投稿。WPMLのデータベースがヒモ付を行なう。
• Babble: 翻訳を別の投稿タイプに保存する。たとえばpost, post_fr_fr, post_jaのような。で、タクソノミを利用してコンテンツをグルーピングする。当然、ポストタイプが違うのでそれに起因する問題が起こる。
• Multilingual Press: マルチサイト内の違うサイトにそれぞれ保存し、ヒモ付用のテーブルが別途ある。
• Polylang: 新規テーブルの追加は一切なし。4つのタクソノミが追加される。language（追加された言語）、term_language（タームの訳語。例：英語 – Uncategorize、日本語 – 未分類）、term_translations（タームの紐付け）、post_translations（ポスト同士の紐付け）。かなり軽くて、他のプラグインともちゃんとうごくようだ。

提案

まず、WordPress自体が多言語化をサポートするのはよして、プラグインに任せることで、いろんなシナリオに対応できるようにするのがよい。

ただし、コアがなんらかのサポートを提供することで翻訳プラグインがよりよくなるようにできるはず。

提案1

コンテンツ（ポストやターム）を言語でマーキングするためのミニマルな方法を、コアが持つ

• 単言語サイトであれば気にならない
• 多言語サイトプラグインに対し、コンテンツ（ポストやタームなど）をマーキングできるようにすることを義務化
• 見えない機能になるので事例は必要
• エクスポート／インポートどうする問題。多言語化プラグインの必須機能にする？なんかフック足したりしないと。
• no language 的な特殊なロケールがサポートする？Drupalはしてる。
• wp_postsおよびwp_termsにカラムが追加されるべきかも。その際、postとtaxonomy APIには、プラグインからアクセスできるなんらかの機能追加が必要だろう。

提案2

たとえばウィジェットみたいなコンテンツオブジェクトの文字列を翻訳する際のお作法や標準的な手法をコアが提供する

他に話し合われたこと

• フロントエンドと管理画面の言語を別のものにできるような仕組み
• ロケールの変種のサポート。たとえば「インフォーマルなポルトガル語」がポルトガル語とは別にあるのだけど、ISOスタンダートから外れてるのでこれをどうする。

コメント欄

• qTranslate Xについての言及あり。これは、同じフィールドで特殊なhtmlコメントっぽいので言語ごとをラッピングしてる。
• いろんな人を巻き込もう的な話あり。WPMLや他のプラグインの作者などを。
• Working Group作る？みたいな話あり。
• マット降臨あり。コア側でなんか変わるよりも純粋にプラグインだけでやったほうがよいとのコメント。コメントへの返信で、プラグインテリトリに留まるよとの返事はあったものの、複雑化とかクエリの増加とかシングルサイトに影響与えるのはな、というマットからの再返信があり、そういうつもりじゃないけどそうかもな気もするみたいな感じになった。