WordPress の多言語化で考えることとプラグインの比較

WordPressで多言語サイトを制作する場合、いろいろな選択肢があります。

  • プラグインを使う
  • マルチサイトを有効化してプラグインを使う
  • 別々のWordPressを使う

また、プラグインにもいくつかのタイプがあり、それぞれに一長一短があります。この記事では、以下の6つのタイプごとにまとめてプラグインをご紹介します。

  1. 1投稿に複数言語型
  2. 1言語1ポスト
    1. ポストメタ紐付け型
    2. テーブル紐付け型
    3. タクソノミ紐付け型
  3. マルチサイト型
  4. 別々のサイト型

本題に入る前に、ちょっと整理してから。

多言語サイトの条件とは?

多言語化する、というのは実際にはどのようなことでしょうか。以下のような機能が想定されます。

  • 投稿、固定ページ、カスタム投稿タイプなどを翻訳でき、対応するポスト同士をひもづけすることができる
  • タクソノミのタームを翻訳でき、対応するターム同士を紐づけできる
  • メニューを翻訳できる
  • ウィジェットの翻訳ができる
    • 最新の記事一覧など、言語別のソートができる
  • テーマの中にハードコーディングされている文字列が翻訳できる
  • サイトのタイトルやタグラインなどを翻訳できる
  • フロントエンドに言語の切り替えボタンがある
    • トップページではなく、今見ているポストの別の言語版のページに遷移する
  • 管理画面の言語を、フロントエンドと関係なく選ぶことができる
  • <link rel="alternate" hreflang="es" href="<?php // url here ?>">要素がある
  • パーマリンクの構造に言語的なルールがある
    • サブドメインとかサブディレクトリができるなど

また、単純にひとつのブログの中に複数の言語があればよいというシンプルな条件から、会社サイトが翻訳された形なので構造まるごとコピーする必要があるのかなど、考えるべきことが多いものです。

翻訳者全員がWordPressにログインしなければいけないわけではなく、翻訳体制がサイトの外側にある場合もあると思います。

サイトの条件、仕様に合わせて選ぶ必要があります。それを踏まえて、各種プラグインを見ていきましょう。

1投稿に複数言語型

事例: qTranslate X

1つの投稿の中に、すべての言語を放り込む形です。その実装の方法としては、特殊な形のHTMLコメントで各言語のコンテンツをラッピングしています。

ちなみに Drupal 8 では、1つの投稿の中に複数言語を持つのは同様だけれども、タイトルやコンテンツ、カスタムフィールドの翻訳をメタデータとして持たせるということのようです。

メリットとデメリット

これはこの型のメリットというわけではないのですが、qTranslate Xについていえば、同じ画面の中で複数の言語を編集することができるUIが人気です。

qTranslate Xで、1画面で全部編集できるの図
qTranslate Xで、1画面で全部編集できるの図

デメリット

データのもたせ方には無理やり感があり、他のプラグインとの競合が心配です。

また、このプラグインを入れた状態で開発したウェブサイトは、プラグインを無効化することが実質的にはできなくなります。

1言語1ポスト -> ポストメタでヒモ付型

事例: Bogo

Contact Form 7 の作者である三好さん作成のプラグインです。

Bogo のスクリーンショット
Bogo のスクリーンショット

Bogoのプラグインページには以下のように書かれていました。

The core of WordPress itself has the built-in localization capability so you can use the dashboard and theme in one language other than English. Bogo expands this capability to let you easily build a multilingual blog on a single WordPress install.

Here are some technical details for those interested. Bogo plugin assigns one language per post. It plays nice with WordPress – Bogo does not create any additional custom table on your database, unlike some other plugins in this category. This design makes Bogo a solid, reliable and conflict-free multilingual plugin.

  • WordPressがそもそも持っているローカライゼーションの機能を拡張している
  • 多言語ブログ
  • ひとつひとつのポストにひとつの言語を割り当てる
  • 追加のテーブルが無いので、しっかりとして信頼できて、(他のプラグインとの)コンフリクトがない

メニューの表示については複数のメニューを使ってロケールに従ってテーマで出し分けることになります。WordPressのコアの仕組みを利用している形です。

タームの翻訳については、これからも進化していくとのことで楽しみにしています。

1言語1ポスト -> テーブル紐付け型

事例: WPML

ひとつのサイト内で、同じ投稿タイプに言語ごとのコピーがあってお互いに紐付けされている。ある投稿の英語版は投稿の中に、ある固定ページの英語版は固定ページの中に、という形。

使われている事例はものすごく多いようです。その意味で典型的な使い方には困らないのではないかと思います。

一方、プラグイン開発者の方々にはWPMLが入っているサイトからのトラブル報告が多いという話をよく聞きます。一方ユーザーからは問題なく使えているという声も聞きます。また、テーブルが作られるということで、WordPressのオリジナルのDBの中に多言語関連の設定は保存されていないので他のプラグインに移行することはできません。

1言語1ポスト -> タクソノミ紐付け型

事例:Polylang

軽いらしい。他のプラグインとも問題なく動くという報告も多くあります。

なんかいい感じだった。
なんかいい感じだった。

カスタム分類(管理画面のメニューには非表示)を4つ作るそうです。

  1. language(追加された言語)
  2. term_language(タームの訳語。例:英語 – Uncategorize、日本語 – 未分類)
  3. term_translations(タームの紐付け)
  4. post_translations(ポスト同士の紐付け)

ヒモ付や翻訳の保存のために新しいテーブルを作ることがないので、プラグインを無効化した時にも、複数言語の整理が無くなるだけで、特に問題は起こりません。ヒモ付のやり直しは必要ですが、Bogoに乗り換えるということが可能です。

マルチサイトでサイト間のポスト同士紐付け型

マルチサイトの仕組みを使って言語ごとに子サイトを作り、それぞれのサイト内のポスト同士を紐付けします。

事例

メリット・デメリット

多言語化プラグインが他のプラグインとちゃんと動かないだろうという不安は大きいです。従前は、マルチサイトだから使えないプラグインがあるという不安も大きかったですが、今は特殊なものでなければそんなこともないです。

また、別のメリットとしてスペイン語だけの管理者というのを作るのとか、すごく簡単です。スーパーアドミンは全部ログインできるしプラグインも管理できる。

普通のアドミンは各サイトのみとか、英語と日本語は操作できるけど中国語には入れないとかできます。

コツ

  • i18nとL10Nを活用する
  • 親テーマと子テーマをうまく利用する
    • 親テーマはどこでも有効化されず全サイトのテンプレート的に設置
    • 各サイト用に子テーマを作り(最初は空でもよい)、差分を吸収していく
  • 機能的なものはプラグインに入れる
    • 分割することで、オンオフでサイト間の差を出せる
  • get_template_part( ‘something’, $locale ); とか便利です

別々のWordPressでソースは同期型

これも僕があるプロジェクトでやっていて、条件付きでオススメです。

かなり大きなサイトでデザインも機能も部分的に違う、みたいなことになった場合(規模の大きいビジネスだったらたいていそうなる。そういう場合)に、意外にこの方が簡単ということもあります。

メリットとしては、完全に独立したサイトなので、多言語プラグインがあることで起こる問題が起きないことです。

一方、ページ同士のヒモ付が必要なサイトの場合にも選択肢から外れます。ヒモ付が行われると、たとえば http://example.com/hello という固定ページがあると、head内にlink要素が追加されます。

<link rel="alternate" hreflang="es" href="http://es.example.com/hola" />
<link rel="alternate" hreflang="ja" href="http://example.com/ja/こんにちは" />

といったものです。これはSEO上重要なメタタグであり、このヒモ付が行われていることで、UXとしてもあるページを閲覧中に言語選択ボタンを押したらトップページではなく、その言語のそのページに直接移行させるためのリンクを発行することもできます。

考察

プラグインの領域なのか問題

こうして見てくると、WordPress を多言語のサイトにするということを可能にするのは、プラグインの領域なんだろうかという疑問が湧いてきます。あまりにもファンダメンタルすぎて、コアでサポートされたほうがいいのかもしれないですよね。

そういう意味で、この記事を書くきっかけになったDrupalの場合を踏まえてWordPress自体も多言語対応したほうがいいんじゃないか会議がWordCamp Europe 2015で行われたのは興味深いです。(ここに翻訳があります。)

ロック問題

qTranslate は一度有効化して運用を始めたらもう戻れません。他のプラグインに移行することはとてもむずかしいです。そうしたプラグインが3年後になっても開発やメンテナンスが続いているのかがわからないというのは非常に不安です。

なんらかのスタンダードがWordPressの本体から提供されて、それに沿って工夫がされたプラグインがいっぱい出てくるというのが理想でしょう。ただし、現在のところ、そういう話は開発側では出ておりません。

以下はFacebook上の僕のウォールでの議論の様子が見れるエンベッドなのでこちらも見てみてください。

WordCamp Europe 2015 で Drupal のコントリビューターを招いて、WordPressの多言語機能について話し合ったということで、Make.にレポートが上がってました。ヨーロッパはいろんな言語が混ざり合っていて、複数言…

Posted by Shinichi Nishikawa on Sunday, 12 July 2015

実際に作る立場からすると他のプラグインといっしょに動くのかどうか、同じサイトとはいえ、言語ごとにサイトに差異が出る際にどのようにそこを統合&分離するのかというのが大事だと思います。

最初はえいやで力技でできるところもあると思うのですが、多言語サイトの難しいところは途中から仕様が変わったり、コンテンツの有無が変わったりして、言語ごとの差が広がってしまうところなのですね。

その時に既存のプラグインが使えないとか、同じひとつのテーマがロケールの判別式だらけになってワケがわからないとか、そういうことが起こると大変になります。

↓ プラグインを作る方々への本、書きました。 ↓

「WordPress の多言語化で考えることとプラグインの比較」への12件のフィードバック

  1. ワードプレスの多言語化ですが、それぞれの言語でワードプレスをインストールしようと思っております。それにともない、example.comで日本語はexample.com/japanese、英語はexample.com/english、として example.comのページはそれぞれの言語へのリンクだけにするのと
    example.comに日本語のワードプレスをインストールしてほかの言語はサブディレクトリにするのではどちらがいい(ユーザビリティーと検索エンジン最適化に関して)とお考えになりますか?お忙しいところ恐縮ですが教えていただけますでしょうか?

  2. SEOに関しては専門ではないのでよく分かりませんが、どちらでも問題ないように思います。ディレクトリ構造よりも、hreflangメタタグがきちんと整備されることを考えたほうがいいケースはあると思います。その意味で、お互いの投稿同士が紐付けられる場合には、シングルでもマルチサイトでも、プラグインの利用を検討したほうがよいと思います。

    ユーザビリティーについては、個人的な意見になりますが、

    • 明示的に各言語へのリンクが各ページにあるようにしたようがいい気がする
    • ブラウザの設定言語を見て、こちらがわで飛ばしてあげたほうがいい気がする
    • トップページへのアクセスしたユーザーが自分で選ばないといけないのは手間だ

    というのが雑感です。

  3. 回答ありがとうございます。

    コメントが付いたらメールが来るかと思っていたのでブログを確認しておりませんでした。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です