ノードの翻訳とエンティティ(フィールド)の翻訳


26

多言語サイトにあなたがお勧めするものを知りたいです。たとえば、次の場合を考えてみましょう。ページとそのコンテンツは、3つの言語(ドイツ語、英語、スペイン語など)で利用できる必要があります。このサイトでは、1つのプロファイルタイプ、複数のコンテンツタイプとビュー、分類法、分類法参照、ノード参照、ユーザーおよびフィールド参照、フィールドコレクション、メニューなどを使用します。この情報はすべて翻訳可能である必要があります。

私が知る限り、これを取得する方法は2つあります。エンティティ変換と「ノードベース」メソッドを使用する方法、または国際化モジュールとl10n を使用する通常の方法です。

どのような方法を選択すればよいですか?どの場合、なぜ他の方法ではなく方法を考慮する必要がありますか?

回答:


8

Randy Fayは最近、Entity Translationsで達成された可能性について議論する投稿を作成しました。そこでは、Gabor Hojtsyが、考慮すべき考慮事項のいくつかについてコメントしました。

[古き良き]ノードの翻訳によって提供されるいくつかの良い点には、個別のノードコメントのサポートが含まれます(たとえば、ドイツ語と英語のコメントは混在しません)。言語ごとの改訂のサポート。公開ワークフロー(たとえば、ドイツ語のノードは公開前の改訂ワークフロー内にあり、英語は既に公開されています。調整されたアクションは、すべてがワークフローの特定のステップに到達したときに複数の言語バージョンを公開できます); Drupalの過度のノードアクセスシステムなどのおかげで、異なる許可処理(たとえば、特定の人々は英語のオリジナルではなくドイツ語の翻訳しか編集できない)など。メニューについて考えてください。ほとんどのサイトでは、すべての翻訳バージョンで1-1メニュー構造を使用する予定はありません。

Content / Entity / field-level Translationで見られる主な注意点は、その時代のDrupalismの特別なケースです。ノードタイトル...実際にはフィールドではないため、別のモジュールなしでは翻訳できません。いくつかのパッチ作業。現時点では、フィールド翻訳は依然として「実験的」な分野であると思いますが、新しい領域に進出するためのより多くの力があなたにあります。


ありがとうございました。ノード変換のための非常に興味深いポイントとプロ。
ランス

5

DrupalCon DenverでのSuzanne KennedyとFlorian Loretanのプレゼンテーションは、この質問に対処しました。エンティティ変換は将来の方法であり、少なくとも部分的にコアへの統合が予定されているようです。

改訂のサポートが必要でない限り、エンティティの翻訳を使用することを推奨しました。


2
実際、Entity TranslationはDrupal 8 Coreの一部になりました。プロジェクトページによると。
タニウス

5

Node翻訳を使用しましたが、Entity Translationを試した後、間違いなく私のお気に入りです!

Drupalコミュニティでは長い議論があるため、主な問題はエンティティ変換のインポート機能だと思います。それ以外の場合は、新しいモジュールについて読みますが、まだ試していません。しかし、私は後で私のフィードバックを提供します!

エンティティの翻訳をタイトルモジュールと組み合わせると、すべてを翻訳できます。また、モジュール「Localization update」も好みます。

したがって、これらの提供モジュールをインストールして有効にする必要があります。

そして、これらのコアモジュールを有効にする必要があります。

  • ロケール。
  • コンテンツ翻訳。

がんばろう!


このトピックに関する素晴らしい要約、+ 1!
Pierre.Vriens

2

私はここで死者を上げていることを知っていますが:

私が言えることから、6スタイルのノード翻訳方法(各翻訳は新しいノードです)は、コンテンツを翻訳するための唯一の便利な方法であり、誰もが慣れていることと機能的に完全であるという利点があります。(ノードタイトルは7ではフィールドではないため、他の愚かな欠点の中でもフィールド変換できません。)

常にi18n / localeを使用します。唯一の選択肢(実際には選択肢ではありません)は、ノードレベルまたはフィールドレベルの翻訳であり、そのうちノードの翻訳のみが有用である可能性があります。

編集:これが書かれて以来、Entity Translation + Titleモジュールはフィールドレベルの翻訳を非常に効果的にしました。それらを使用できる場合は、使用する必要があります。


5
これはcontribモジュールですが、Titleモジュール(drupal.org/project/title)により、ノードタイトルをフィールドとして機能するように変換できます。
パトリックケニー

1

ほとんどの場合、エンティティの翻訳はノードの翻訳よりもはるかに意味があります。しかし、残念なことに、多くのモジュールがまだサポートしていないため、D7にとって実際には実行可能なオプションではありません。プレゼンテーションを行い、それがどれほど素晴らしいかを示す人々は、非常に単純な仕事をしているだけです。たとえば、フィールドコレクションのような一般的で人気のあるものは、ETではまだサポートされていません。

新しい多言語サイトを開始するときは、素晴らしいアイデアであるため、常にETから始めます。互換性のないものに関する問題が多すぎるとわかるまでそれを守り、最終的には古いD6メソッドに戻ります。


あなたが経験した困難について、もう少し詳しく教えてください。私たちはあなたが説明したのと同じ状況にあります(新しいサイトを作成し、翻訳に使用するモデルを決定する必要があります)。私たちのサイトが十分にシンプルで、あなたが抱えている問題に遭遇しないかどうか疑問に思っています。体験の詳細を知ることは非常に役立ちます。
ジョシュ14

D7には6000を超えるモジュールがあります。どれが機能し、どれが機能しないかを言うのは難しいです。フィールドコレクションがETで適切に変換されないことを知っています。他にもあると思います。最善の策は、作成した各バンドルを試して、ETを使用して翻訳できるかどうかを確認することです。ETとNTを同じサイトで混在させることができます。同じバンドル内ではありません。これは、以前に確認しておらず、サポートされていないフィールドタイプを後で追加する場合のように、ETをより危険にします。または、サポートされていない機能を追加します。困っているかもしれません。
liquidcms 14
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.