こんにちは。最近やっと大型案件が落ち着いて気づいたら年末な大野です。
最近では色々なウェブサイトで多言語化が望まれるようになってきましたね。弊社でいただくお問い合わせも多言語サイトでの案件が多くなってきています。
Drupal ではコアの Locale モジュールさえ有効にしてしまえば簡単な多言語サイトは作ってしまうことはできますが、細かい調整が必要なサイトの場合は様々な多言語化用のモジュールを入れて対応しなければなりません。
今回は具体的な翻訳機能の使い方ではなく、Drupal で多言語化したサイトを作るにはどんなモジュールが必要で、モジュールがどんな役割をしているのか翻訳システムの全体像と、2つの翻訳方式について紹介したいと思います。
i18n と l10n について
i18n や l10n と言う言葉をご存知でしょうか？ちなみに私は Drupal を使いはじめるようになって初めて知りました。この後に紹介するモジュールに i18n やら l10n などのモジュールが出てきますので、先に意味を正しく理解しておきましょう。
i18n は Internationalization の略語で意味は国際化です。なぜ i18n と略されるかと言うと頭文字の I と語尾 n の間にアルファベットが 18 個あるからだそうです。日本人には想像も付かない略し方ですね。そして l10n は Localization の略で、国際化とは逆に地域に合わせる事を言います。
観点によってモジュール名が変わりややこしいのですが、ここではどちらの意味も含めて多言語化として解説します。
Locale module
Drupal 7 に含まれているコアモジュールの一つで、多言語化するための最低限の機能を提供するモジュールです。
このモジュールを有効にすると、以下の機能が有効になり、英語以外の言語が選択できるようになります。Drupal が日本語環境になっているのであれば、既にこのモジュールが有効になっているはずです。
- 言語切替ブロックが追加されます。ユーザーはブロックのリンクから言語を切り替えることができます。
- コンテンツタイプの設定に多言語化オプションが追加され、コンテンツ作成時に言語が選択できるようになります。
このモジュールだけでは管理用 UI のテキストとコンテンツ部分しかできないので、通常は後述の Internationalization モジュールを合わせてインストールすることになります。
初心者がよくハマる点で気をつけなければならないのは、URL パスエイリアスも言語ごとに設定されると言うことです。よく「エイリアスを設定しているけど効かない」みたいになるのですが、大抵はエイリアスの言語が合ってないことが原因です。
Localization update (l10n_update) モジュール
Localization update モジュールは Drupal コミュニティが運用する翻訳サーバー localize.drupal.org (通称 l.d.o) からほぼ最新の翻訳ファイルを自動的に取得してインポートしてくれるモジュールです。また、その後に翻訳が追加・更新された場合もこのモジュールの機能で更新することができます。
一昔前は翻訳ファイルを l.d.o からダウンロードして管理画面からインポートすることが普通だったのですが、今ではこのモジュールを有効にするだけで翻訳できるすぐれものです。
Localization client (l10n_client) モジュール
翻訳用のインターフェイスを各ページに用意してくれて、自力で翻訳する際に役立つモジュールです。
コアの Locale モジュールでも管理画面から翻訳対象の文字列を検索して翻訳することは可能ですが、このモジュールは画面上で翻訳対象の文字列を見ながら翻訳できるところがミソです。
また、話はそれますが、このモジュールで翻訳した内容を localize.drupal.org へ直接データを送信する機能も兼ね備えていますので、未翻訳の部分があればどんどん翻訳して Drupal コミュニティへ貢献しましょう！
Internationalization (i18n) モジュール
Drupal コアの Locale モジュールだけではカバーしきれないところの翻訳をサポートするモジュールです。後述の Entity translation モジュールを使う場合でも使用しますので、サイトを多言語化する際はほぼ必須のモジュールと言っていいでしょう。
このモジュールは機能ごとにサブモジュールとして提供されていますので i18n を有効にするだけでは多言語化されないことに注意してください。なお、サブモジュールは i18n に含まれていますので個別にダウンロードする必要はありません。
Entity translation モジュール
Drupal コアが提供する Locale モジュールの方式とはまた違った翻訳方法を提供するモジュールです。
Locale モジュールはコンテンツごとに翻訳するノードベース方式なのに対し、Entity translation モジュールはフィールド毎に翻訳するフィールドベース方式となります。どちらとも一長一短があって一概にはどちらが良いとは言えないので次の節で解説します。
ちなみに Drupal 8 ではこの Entity translation がコアに取り込まれています。Drupal 7 のフィールドのデータ構造も多言語に対応できるようになっているので、それを考えると Drupal 7 も最初からこっちにしたかったんだけど、コードフリーズに間に合わなかったんでしょうね。歴史を感じます。
Locale モジュール VS Entity translation モジュール
それぞれの得意・不得意を表にすると、ざっとこんな感じです。
| Locale | Entity translation | |
|---|---|---|
| 安定性 | ◯ | △ |
| 設定の容易さ | ◯ | × |
| パスを一つにできる | × | ◯ |
| フィールドデータの使い回し | × | ◯ |
Locale モジュールのメリット・デメリット
- Locale はコアに内蔵されているモジュールなので、他のモジュールとの親和性が高く安定しています。
- Internationalization モジュールの設定は少々複雑ですが、このモジュールだけで見れば設定は簡単です。
Locale の場合は言語ごとにノード ID がふられるので、翻訳したコンテンツはそれぞれ独立したものとなることに注意してください。URL エイリアスを使用する場合には、それぞれに設定する必要があります。
Entity translation モジュールのメリット・デメリット
- フィールド毎に翻訳の有無を設定できるので、必要なフィールドだけを翻訳し、共通の項目は値を使い回すことができます。
- ノード（エンティティ）自体は同じなので URL が一つで済み、Pathauto モジュールなどで URL エイリアスを作成する必要がありません。
Entity translation は2015年12月現在で、まだベータ版なところが気になりますが、実際に使用した感じでは十分に安定していると感じます。
タイトルなどの一部の項目は Drupal 内ではフィールドではなくエンティティのプロパティ扱いになるため標準では翻訳できませんが、Title モジュールを使うことでタイトルをフィールドとして扱い翻訳することも可能です。
いかがでしたでしょうか。個人的な感想を言えば、今からサイトを作るのであれば基本的には Entity translation モジュールを使用した方がメリットは多いと感じます。また、ノードベースの翻訳方式と、Entity translation のフィールドベースの翻訳方式は、コンテンツタイプごとに選択できるので要件によっては使い分けたほうが良いかもしれません。
途中から既存のコンテンツの翻訳方法を変更するのはかなり骨が折れる仕事ですので、これから開発するのであれば慎重に決めてスタートしましょう。
募集しています
スタジオ・ウミは「Drupal」に特化したサービスを提供する Drupal のエキスパートチーム。
フルリモート＆フレックス制だから、働く場所を選ばず時間の使い方も自由です。
そんなワークライフバランスの整った環境で、当ブログに書かれているような
様々な技術を共に学びながら、Drupalサイト開発に携わってみたい方を募集しています。
まずはお話だけでも大歓迎！ぜひお気軽にご連絡ください。