アクロニスは、ロシアで主要な研究開発を行う国際企業ですが、当社の主要言語は英語です。 地域の製品には独自の言語があり、かなりの数があります。 ウェブサイトの言語は、ソフトウェアの言語以上のものです。
したがって、このようなシステムをDrupalで作成しました。
- 英語（米国）のマスターテキストが表示されます。 「ゴールデン」イメージとしてすべてのサイトに展開されます。
- ロケール言語への直接翻訳がある場合は、それが使用されます。
- ロケール言語への直接翻訳はないが、継承言語への翻訳がある場合、継承言語のテキストが使用されます。
つまり、メキシコ（スペイン語から派生した言語を話す）では、チェーンは次のようになります 。 そうでない場合は、スペイン語を使用します。 そうでない場合は、英語を米国に置きます。 英国では、シーケンスは短くなります。クラシック英語、次にアメリカ英語です。 同時に、価格は別の方法で継承されます。最初にローカルがチェックされ、次にヨーロッパではなくアメリカが取得されます。
2番目に重要なことは、変数（価格、日付形式、製品名、個々のボタン名など）の依存関係を保証するために、すべてのページ全体を断片とトークンに分割することです。 箱から出してすぐにDrupalがすべてを「木製」かつ簡単にしたため、倒錯が必要でした。
入門情報
多くのコンテンツ、透明、短い編集プロセスではなく、翻訳のレビューと校正。 サイトを編集している約30人。 Drupal 7のインスタンスは1つだけで、ロケールのさまざまなコンテンツ-特別オファー、割引、通貨とその形式、特定の条件に応じた製品とページの可用性。 面白いですね。
誰かがコードを書くと、コンテンツが生まれます
おそらくそうあるべきでしょうが、常にそうなるとは限りませんよね？ 正直に言うと、この点で、すべてが非常に整然とデバッグされています。
- 基本言語（英語）に基づいて構築されており、翻訳可能な文字列、フィールドコンテンツ、および画像を形成するのはその上です。
- このコンテンツは、サイトに投稿するプロセスで調整され、最初のレビューを受けて、さらなるアクションの開始点になります。
- 出力では、レイアウトが完全に完成したページに英語のコンテンツが含まれています。 この作業が2つのプロセスに分かれていることは注目に値します。Drupalインターフェイスとレイアウトへのテキストの単純な配置、t（）Drupal関数を使用した翻訳可能な文字列を含むJavaScriptコードとテンプレートファイルの記述です。
翻訳する方法は？
ご存じのとおり、Drupal 7には、コンテンツを翻訳するための2つのオプションしかあり
ません。エンティティの完全なコピーを作成する
か、フィールドを翻訳します。 1つ目は、より「核」ですが、
ロケールモジュールを使用した、柔軟性が低く、明らかにオーバーロードされたメソッドです。 2番目のパスであるEntity Translationに沿って進みました。そのため、
ノードテーブルには
できるだけ多くのレコードがあり
ません 。
すぐに良くなかった
- Entity Translationで、ランダムで奇妙で恐ろしいバグを見つけるために、膨大な数の信じられないほどの冒険を行いました。
- 私たちは非常に
美しく整頓されたコードを見つけたため、道徳的に安定することを余儀なくされました。 - これらはすべて
非常に高速で安定しており、負荷がかかってもうまく機能しました。 - 翻訳のアップロードは
非常に便利でした。 - すべてのボックスシステムと同様に、Drupal 7は最初はあまり便利で快適ではありませんでしたが、柔軟性があり、チャンスがありました。
そしてついに建てられた...
同僚が分類用語を翻訳し、分類用語参照ウィジェットがローカライズされた用語ヘッダーを表示できるように、私たちはすべてを非常に一生懸命に試みました。 Drupalに、さまざまな状況で正確に希望する方法で翻訳のために候補言語のチェーン全体をバイパスするように教えることができました。 また、独自の個別の継承メカニズムを使用して、通貨形式を処理するための非常に正確で拡張可能なシステムを作成することもできました。 独自のEntityタイプがいくつかあり、それらも完全に管理され、同じスタイルに翻訳されています。 柔軟なメニュー機能を作成することができました。その機能は「ノード/」の制限をはるかに超えています。
よく知られている翻訳管理ツールプロジェクトを
少し書き直し、すべてのエンティティ
を翻訳し、独自のトークンを処理し、依存関係を使用してケース転送をXLIFFにアップロードするトリックと、いくつかのトリックを教えました。
また、必要なロケールのエンティティを非表示/表示する独自のオプションを作成する必要がありました。これにより、リクエスト段階でアクセス素材を正しく返すことができます（アクセスシステムでの整理方法とほぼ同じです）。このオプションにより、メニュー自体への「パススルー」目的のロケールのメニューからページが消えます。 非表示のページの後には、403クライアントを無差別に渡さないように、独自の
配信コールバックが続きました。
それをトークン化する！
トークンを使用するのが好きだったので、それが起こった。 変更は良好であり、テンプレートやページの本文部分などでトークンを思い付きました。 トークンは、原則として、別のエンティティであり、独自のタイプ-テンプレートです。 これにより、自分自身を整理し、これらのトークンの名前と配置の標準を開発し、変更を恐れることがなくなりました。 1つのロケールで20ページの電話を削除または変更しますか？ -簡単！ オーストラリアのオファーからいくつかのオプションを削除しますか？ -もちろん！
特定のページからのリダイレクトが存在する場合でも、クライアントにローカライズされたリンクを常に返すことを目的とした独自の作業アルゴリズムを使用して、コンテンツに正しいURLリンクを設定するためのトークンを実装しましたが、それ自体は存在しません。
最も重要なことはローカリゼーションです
そして、私たちがこの瞬間のために話したことすべて。 モスクワのローカリゼーションチームは、Drupalと完全に対話することができます。 これはまさに私たちがやろうとしていたことです-プロセスはほぼ平行になりました。 選択したページのすべてのフィールドからデータをアンロードするタスクを作成し、翻訳が必要な言語を示し、XLIFFファイルを受け取って作業を開始します。 原則として、まれな言語への翻訳者自身は、ネイティブスピーカーを持つ遠隔地の従業員または代理店であるため、荷降ろしは単に外部に転送されます。 そこで翻訳され、再び翻訳者のソフトウェアに送られ、そこから検証後、Drupalにインポートされます。そこで、各エンティティの新しい翻訳が自動的に作成され、翻訳されたフィールドの値が追加されます。 ページの翻訳版へのリンクを地域マネージャーに送信することは残っています。
おわりに
同じシステムインスタンス内で多言語で非常に複雑な構造を操作した非常に良い経験があります。 Zero Downtimeで安定して、サイトのリリースを更新します。 少なくともサービスの観点からは、サイトが本当に正確であるため、意図的にサイトを小さなサイトの塊に分割しませんでした。 結論の重要な点は、Drupalコア
をまったくハッキングすることなく、上記のすべての成功を達成できたことです。