Drupal 8 で強化された多言語機能の特徴と比較

こんにちは、スタジオ・ウミの大野です。今回の内容は Drupal 8 で強化された多言語化機能がテーマです。Drupal 8 の3つの翻訳モジュールの役割分担と、新旧の翻訳方式のデメリット・メリットについて解説します。

ここで書かれた内容は Drupal Meetup Haneda Vol.3 で登壇させていただいた時の内容を元に作成したブログとなります。

Drupal 翻訳機能の「翻訳」の意味

Drupal の翻訳(Translation)機能のことを説明をすると、たまに認識に齟齬が起きるときがあります。まずはその違いについて確認しましょう。

翻訳 ≒ ローカライゼーション

翻訳とローカライゼーション（局地化）は混同されやすいのですが、厳密には意味が違います。翻訳とは「ある言語の文章を、原文にそくして他の言語に変えること」ですが、ローカライゼーションは「翻訳と同時に、その言語が使われる地域に合わせてコンテンツの内容を変えること」を指します。なお、Drupal では翻訳機能を使って、コンテンツをローカライゼーションすることも可能です。

翻訳機能 ≠機械翻訳

Drupal の翻訳機能と言うと、Goolge 翻訳などのように「コンテンツを機械的に翻訳してくれる機能」と勘違いされることがあります。Drupal の翻訳は「ユーザーが作成したコンテンツを、ユーザー自身で翻訳コンテンツを作成することができる機能」と考えてください。

滋賀県国際協会のウェブサイトを紹介

http://www.s-i-a.or.jp/

いきなりですが、こちらは弊社で構築して今年の4月位にオープンした滋賀県国際協会と言う Drupal 8 で構築されたサイトです。県内の外国人をサポートするための情報サイトで、弊社としては Drupal 8 で初めて本格的に多言語化に取り組んだプロジェクトです。裏側の管理画面をお見せすることはできませんが、8つの言語に対応しており、挙動などがわかるのでよろしければ参考にしてください。

3つの翻訳モジュールとその役割

この画像はモジュールの一覧画面から切り取ってきたスクリーンショットです。一口に翻訳機能と言っても、Drupal 8 では翻訳の特性ごとに3つのモジュールに分けられています。まずはモジュールそれぞれの特性について見ていきましょう。

Content translation モジュール

Content translation モジュールは、ノードなどのエンティティに入力された内容を翻訳する機能を提供します。

赤枠で囲われた部分がこのモジュールが担当する部分です。コンテンツの編集画面にある「タイトル」や「本文」がそれにあたることがわかりますね。

管理タブの「翻訳」をクリックすると画面のように翻訳の追加画面に遷移します。

一般的な運用フローでは、この画面から追加したい言語の翻訳コンテンツを追加していきます。この画面の「追加」を押すと、通常のノード編集フォームと全く同じフォームが表示され、保存すると Drupal が自動的に翻訳ページとして関連付けの処理を良きようにやってくれます。

Interface translation モジュール

Interface translation モジュールは、Drupal コアやモジュール・テーマなどに予め組み込まれているテキストを翻訳する機能を提供します。

スクリーンショットの赤枠で囲われたテキストが、このモジュールが担当している翻訳エリアです。Drupal に最初から組み込まれている、メニューやタブ、ブロック関連がその対象となります。

インターフェイスを翻訳したい場合は、管理メニューの「環境設定 > ユーザーインターフェイスの翻訳」から翻訳の管理画面を開き、翻訳したい文字列を検索してデータを入力します。

なお、localize.drupal.org に寄与されている翻訳は全て、このモジュールの担当範囲になるため、インポートやエクスポート機能が含まれています。

Config translation モジュール

Config translation は、ユーザーが設定画面で入力した値を翻訳する機能を提供します。

この画像はおなじみのコンテンツタイプの設定画面ですが、赤枠で書かれた部分が、このモジュールの担当する翻訳範囲です。矢印の箇所を見ていただくとわかると思いますが、このモジュールが有効になっていると「翻訳」のメニューが追加されます。

翻訳ボタンを押すとこのような画面となり、あとは編集ボタンを押すだけで、各コンテンツタイプの設定を翻訳することができるようになります。

最初からデフォルトの値として組み込まれている内容については、Interface translation モジュールの翻訳機能により自動的に翻訳されています。混乱しないように注意しましょう。また、このモジュールの担当範囲はコンテンツタイプだけではなく、Views モジュールの設定など、ユーザーが管理画面上で設定するほぼ全ての設定値を翻訳することができます。

余談となりますが、Drupal 7 まではこの機能がなく、その代わりに前述の Interface translation の機能を使って無理やり多言語化を行っていました。しかし、仕組み的に無理が生じることが多く、モジュールによってはちゃんと翻訳することができずに苦労する事が多くありました。個人的に Drupal 8 の翻訳関連で、恩恵を最も感じる部分がこの機能ですね。

これまでの翻訳方式と Drupal 8 で搭載されたフィールド翻訳について

先程までは Drupal 8 の翻訳モジュールの区分についてのお話でした。次は、これまでの Drupal 7 や WordPress などの一般的なCMSで採用されているページ翻訳方式と、Drupal 8 で採用されたフィールド翻訳方式の違いについて解説します。システムよりのお話です。

※ Drupal 7 まではページ翻訳方式を Content (Node) translation と呼び、フィールド翻訳方式を Entity translation と呼んでいました。先ほど説明した Content translation モジュールと混同してしまうので、ここでは私が勝手に命名しています。

ページ翻訳方式

ページ翻訳方式は、翻訳の元となるページのデータを丸ごと翻訳する方式です。冒頭でもお伝えしましたが、これまでの Drupal や、WordPress の有名な翻訳プラグイン、Concrete 5 の翻訳機能では、この方式が使われています。（完璧に調査している訳ではないので、もし間違っていたらこっそり教えてください。）

ページ単位での翻訳となりますから、ページそれぞれで全く同じ形式のフィールド構造でデータをそれぞれ持つことになります。また、システム上は別ページとして扱われるので、それぞれのページで異なるIDを持ちます。

この方式の欠点として、一部のフィールドのみを翻訳することができないため、例えばカテゴリを設定できるブログ記事を翻訳する場合、それぞれの翻訳コンテンツでカテゴリを同じように設定しなければなりません。後から画像を変更したい！となった時に、全ての翻訳コンテンツに対し、画像を変更する必要があります。

フィールド翻訳方式

フィールド翻訳方式は Drupal 8 で標準採用された新しい翻訳方式です。この方式ではページの枠は共通のまま、フィールド単位での翻訳設定を行うことができます。ページ翻訳方式で言った「翻訳コンテンツ間でデータを共有できない問題」が解決し、翻訳したコンテンツどうしでデータを共有することが可能となります。複数の言語を持つサイトでこの仕組を上手く利用すれば運用コストを大幅に下げることが可能です。

また、システムの内部ID、Drupal で言えばノード ID などが同じ ID となるため、外部からアクセスするための API を作った時に、処理をシンプルに実装することができるのも特徴の一つです。（取得するコンテンツの言語切り替えを ID ではなく、クライアントのセッションやURLで区別することができます）

ちなみに Drupal 7 でも Entity translation というモジュールを入れることで、ほぼ同等の機能を実装することができます。

Drupal 8 はなぜ他の CMS より多言語化に強いのかまとめ

Druapl 8 の翻訳機能は一言で説明するのがなかなか難しいので、伝わりにくい部分もあったかと思いますが、おわかりいただけたでしょうか。

最後に Drupal 8 が他の CMS と比べて優位と思う点を以下にまとめます。

1. フィールド単位で翻訳コンテンツ間でデータを共通化するか設定することができる (フィールド翻訳方式)
2. ユーザーが管理画面上で設定した値を綺麗に翻訳することができる (Config translation)
3. データ構造が素敵。Drupal のデータベース構造レベルで、データの集合体、ならびにフィールドごとに言語属性を持っているため、拡張モジュール側での対応コストが低くて親和性が高い
4. 言語の判定ロジックが豊富。ユーザーアカウント毎の設定や、ドメイン、階層、やろうと思えば独自のロジックを実装して言語の切り替えを行うことができる