web-dev-qa-db-ja.com

国際化のベストプラクティス：合成文？

クライアントがデータベースにオブジェクトを作成できるプロジェクトに取り組んでいます。これらの各オブジェクトには、オブジェクトを説明する説明文字列があります。車を表すオブジェクトを見ているとしましょう：

  • A 赤車[〜＃〜] bmw [〜＃〜]製造62000マイル
  • A pickup-truck製造Dodge201から
  • A 車5席

「車」クラスにはさまざまな属性があり、すべてが必須というわけではありません。例えば：

  • 車のタイプ：車、セダン、ピックアップトラック、SUV
  • マイレージ
  • ブランド
  • 席
  • 年
  • 以前の所有者の数

説明文にはこの情報を含める必要があります。例えば。座席数がわかっている場合、この情報は文の一部である必要がありますが、そうでない場合はそうではありません。これを1つの言語だけで行う場合、これはそれほど複雑ではありません。文の構造を分析し、次のように文を作成するだけです。

A [{色}] {車のタイプ} [{ブランド名}製] [{マイル}マイルあり] [{年}から] [{座席}座席あり}

[....]内の部分は、属性（{...}内）が設定されている場合、最終文の一部にすぎません。

ただし、このプロジェクトは複数の言語をサポートする必要があり、これを迅速に翻訳する方法が必要です。つまり、「製造元」と他のすべての要素をすべての異なる言語で翻訳し、同じ構造の文を作成することはできません。言語が異なれば、文の構造が大きく異なる場合があります。明らかに、要素の各組み合わせを個別に翻訳することもできますが、組み合わせの数が膨大になる可能性があるため（10以上の属性を持つオブジェクトがあるため）、その努力はすぐに高くなります。

このようなシナリオに対処するための推奨される方法は何ですか？

プロジェクトはRuby on Railsで実装されているため、理想的にはこれをサポートするアプローチを探しています。

rubyruby-on-railsinternationalizationlocalization
8
wsg

ユーザーを苛立たせない/奇妙/不快/混乱させない国際化が必要な場合は、次の2つのいずれかを実行します。ブロック全体を取り出し、コピーを項目ごとに一度に翻訳するか、または説明文の構造を削除します。言語構造の違いを完全に回避できるように、変数属性を含めることを提案します。

これが行われる最も一般的な方法は、自然言語で書かれた一般的な製品の宣伝文であり、これはサポートする任意の言語に翻訳されます。製品クラスによって異なる情報は含まれていないため、いくつかのオプションを含める必要がある場合は、「2ドアまたは4ドアモデルで利用可能...」のように記載されています（ただし、通常は可能な限り避けます）。

次に、属性セクションを基本的にキーと値のペアとして使用するため、次のようになります。

  • 属性：値
  • 赤色
  • ドア：4
  • 年：3000

これが非常に人気がある理由は、提案されたプレースホルダーソリューションが言語間で機能しないためです。他の言語のネイティブスピーカーがあなたの壊れた翻訳を理解していないとき、またはそれでもとにかくそれを購入しても構わないと思っているときに驚かれるかもしれませんが、自然言語は難しいので、正しく実行することをお勧めします（テキストの単一のセットブロックを処理する流暢な翻訳者）または問題を回避します（Key-Valueはどこでも自然言語ではありません。製品をスキャンして比較するのが簡単で、Wordレベルの翻訳をはるかに簡単に実行できます。あなたが遭遇する可能性が高い言語の大部分）。

11
BrianH

基本理念

文の構造と文法の微妙さは、確かに国際化の取り組みを困難にする可能性があります。

すべてのケースで使用する必要があるコアプラクティスは次のとおりです。

  • コードからテキストデータを分離します。それを翻訳者に提供できる別のリソースファイルに入れます。
  • 数値の場合、単位変換を行うことができるコードが必要です（例：マイルからキロメーター）

属性のリスト

ブライアンの答え で提案されているように、最も簡単な方法は確かに属性とその値をリストすることです。

不便なのは、データの表示が画面上の多くの場所を消費することです。

分類されたスタイル

もう1つの方法は、属性に名前を付けることさえせずに、さまざまな値を単に連結する分類されたような文字列を作成することです。これは、値が混乱を招かない場合に適しています。

ここでは、別の優れた方法が必要です。すべてのエラーメッセージまたはテキストアセンブリについて、パラメーターの順序をハードコードせずに、名前付きプレースホルダーを含む多言語文字列を使用します。プレースホルダーの順序は、もちろん言語とローカルの使用法に依存します。

English example               French example                  German example
---------------               --------------                  --------------
BMW car, red, 62000 miles     Berline BMW, rouge, 99000 km    BMW Pkw, rot, 99000 km
Dodge pickup-truck, 2010      Pick-up Dodge, 2010             Dodge Pick-up, 2010
Car, 5 seats                  Berline, 5 sièges               Pkw, 5 Sizter 

{brand}{type}{miles}{seats}   {type}{brand}{miles}{seats}     {brand}{type}{miles}{seats}

より複雑ですが、いくつかの利点があります。

  • 生成するのは難しくありません。
  • はるかにコンパクトになり、ユーザーがリストを簡単に参照できるようになります。
  • スクリーンリーダーを使用する必要がある視覚障害のあるユーザーにとっては、はるかにアクセスしやすくなっています。
  • 複雑な画面レイアウトよりも音声アシストに対応しています。

文

完全な文を生成することは、さらに複雑なレベルです。ただし、要件によっては、これは必須機能（契約の生成、音声アシスタントアプリケーションなど）になる場合があります。

したがって、ここでは、正しい順序でプレースホルダーを含む多言語文字列に加えて、高度な文法認識テキストジェネレーターがない限り、以下に対処するために、より多くの語彙を予測する必要があります。

  • 単数形（車）と複数形（車）
  • 文法上の性別：多くの言語には性別があります。フランス語での車のタイプは、男性（「ルピックアップ」）または女性（「ラベルライン」）です。ドイツ語では、3つの性別（男性、女性、中立）さえ持っています。このような言語では、単語の正しい順序では不十分であり、ローカライズAPIで英語の単語を使用してローカライズされた同等語を見つけることも、もはや解決策ではありません。ここには、これらの文法上の制約に対応するテキスト生成コードが必要です（たとえば、フランス語： "le pick-up bleu"と "la berline bleue "）

単純な文、またはオブジェクトの自己記述の場合、追加の属性を使用して多言語リソースを管理するだけで十分です。

type: car:     ->  French: gender=F;  (berline, S), (berlines,  P)  
type: pick-up  ->  French: gender=M;  (pick-up, S), (pick-ups, P)
color:  red    ->  French: (rouge, M, S), (rouge, F, S), (rouges, M, P), (rouges, F, P) 
color:  blue   ->  French:  (bleu, M, S), (bleue, F, S), (bleus, M, P), (bleues, F, P)

したがって、コンテキストによっては、単数か複数かがわかる場合があります。次に、使用する性別を推定する必要があります（タイプでわかります）。次に、残りの値について、既知の属性の組み合わせを持つWordを選択します。

注意：より洗練された文章を作成したい場合、すぐに非常に複雑になります（たとえば、ドイツ語のような言語では、車の自己記述を文で使用することは非常に難しい場合があります。ドイツ語では、グループの文法機能に応じてすべての単語を微調整する必要がある場合があります。そして、すべての言語には異なるルールがあるかもしれません。次に、NLP翻訳サービスを使用することが考えられます。

6
Christophe