WPにおける多言語サイトの構築

…配信元を読む

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

WordPressで多言語サイトを作るときの、考えるべきことを整理して、プラグインの比較・選び方の指針になればと。紹介しているのはqTranslate, Bogo, WPML, Polylangに加えて、マルチサイト用のMultilingual Press, Multi Language Switcherなど。

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

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

また、プラグインにもたくさんの種類があり、それぞれに一長一短がありますので、以下の6つのタイプごとにまとめてみました。

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

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

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

バーっと考えたものなのであとから気がついたら追加したいし、もし何かあればコメントください。

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

この他にも、固定ページをフロントページとして指定できるとか、is_homeがどうなるのかとか、言語の判別式が使えるか、アーカイブがどうなるのかとかいろいろありますね。

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

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

というわけで、サイトの条件、仕様に合わせて選ばないといけないわけですね。では、各プラグインの様子を見てみましょう。

1投稿に複数言語型

事例: qTranslate X

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

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

メリットとデメリット

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

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のコアの仕組みを利用しているのが嬉しいです。

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

僕、WordPressについて書いているブログが日本語(このブログ)と英語の2つになってしまっているので、Bogoでまとめちゃおうかしらと思っております。でも、全部を翻訳するのはキツイしなぁ。。。

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

事例: WPML

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

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

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

有料のプラグインなのでスクリーンショットありません。

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

事例:Polylang

軽いらしい。他のプラグインとも問題なく動くというのを読みました。けど、うーん、どうだろうw やっぱりウィジェットとかメニューとかすごく不安なので、マルチサイトがいいなぁ、と思いました。試してみたいですが。カスタム投稿タイプとかどうなるのかしら?

ということでインストールしてみたのでスクリーンショット。

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

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

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

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

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

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

事例

メリット・デメリット

僕はこれが大好き。

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

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

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

コツ

  • 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 は一度有効化して運用を始めたらもう戻れません。他のプラグインにもいけません。投稿が10個くらいで2言語だけだったら頑張れるかもですが。。

WPMLもWPMLが前提になってウィジェットもメニューも何もかもが動いているとすると、離れられないですよね。

そうしたプラグインが3年後になっても開発やメンテナンスが続いているのかがわからないというのは非常に不安です。

全体的な方向としてWordPress自身が多言語に対応するというのはやめたほうがよくて、hookを足すとかそういう感じで進むのがいいだろうな、という風には思うのですが、なんらかのスタンダードがコア側から提供されて、それに沿って工夫がされたプラグインがいっぱい出てくるというのがいいのかぁ。

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

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

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

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

データの持ち方が面白いなと思って、整理しはじめたら長くなっちゃった!みなさんのやり方も教えてくださいな。

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

保存

保存

Related posts