国際化と同じことを繰り返さないでください

StackOverflow https://stackoverflow.com/questions/56574

  •  09-06-2019
  •  | 
  •  

質問

しばらく前に、「」に関する W3C の記事を読んでいました。スクリプト化されたコンテンツでの文字列の再利用」には、国際化に関するいくつかの有益なアドバイスが含まれていますが、繰り返しコードを排除するという DRY (Don'trepeat Yourself) 原則とは相容れないように思えます。

彼らの例を挙げると、次のようなコードがあるかもしれません...

print "The printer is ";
if (printer.working) {
    print "on.\n";
} else {
    print "off.\n";
}

print "The stapler is ";
if (stapler.working) {
    print "on.\n";
} else {
    print "off.\n";
}

私の直感では、おおよそ次のように繰り返しを排除するでしょう...

report-state(printer, "printer");
report-state(stapler, "stapler");

function report-state(name, object) {
    print "The "+name+" is ";
    if (object.working) {
        print "on\n";
    } else {
        print "off\n";
    }
}

...しかし、そうすることで、スペイン語にローカライズする必要がある場合にコードに問題が発生します。これは、これら 2 つのケースでは「on」を表す単語が明らかに異なるためです。

そこで私の質問は、他の開発者はコードの国際化と DRY 原則のバランスをとるためにどのように取り組んできたのでしょうか?

私の心の一部は、国際化は極端なプログラミングの 1 つであると主張したいのです。」それは必要ないでしょう」という状況。しかし逆に言えば、DRY 原則を念頭に置いたリファクタリングは、ここで行うように難しくはなく、必要に応じて機能を実装することを容易にすることでバランスをとることになっています。

役に立ちましたか？

解決

完全な文を言語リソースに保存するように努めます。あなたが言ったように、異なる文脈では異なる言葉が必要になるかもしれません。しかし、さらに大きな問題は、文の順序が言語によって異なる可能性があることです。したがって、単語から文字列を構築すると問題が発生する可能性があります。

ただ保管するだけ

The printer is on
The printer is off
The stapler is on
The stapler is off

すべての言語の言語リソースにあります。ここでの繰り返しは、アプリケーションのどこにすべての単一の単語が表示されるかを把握することよりも、メンテナンスの悩みどころではありません。

他のヒント

メンデルトの意見に100%同意します。

これはメンテナンスの問題だけでなく、言語の問題である可能性もあります。すべてのラテン語では、主語の性別、数、大文字小文字が他の要素に影響します。ルーマニア語の例

  The printer is on: Imprimanta este pornită // feminine
  The printer is off: Imprimanta este oprită
  The stapler is on: Perforatorul este pornit // masculine
  The stapler is off: Perforatorul este oprit

こちらもご覧ください http://www.mihai-nita.net/article.php?artID=20060430a

文またはフレーズ全体を言語リソース ファイルに保存する必要があるというメンデルト ジーベンガの意見に、私も同意します。文法の違いにより、言語間で 1 つの単語を置換することが常に妨げられます。これでも、オブジェクトの種類とその状態を確認して、言語リソースから適切なメッセージを出力するだけで済むため、最初の例よりもコードの繰り返しは少なくなります。

loc が存在するため、プログラム操作によってメッセージ文字列を作成しないように努めています。チームには見えません。

ロック。チームは実際には、別々ではあるがほぼ重複したメッセージを好みます。ただし、パラメータ化されたメッセージは受け入れられます。

例: 「%(アプライアンス)% は %(on_or_off)% です。」

パラメータは故障する可能性がありますが、少なくとも loc チームにとって、いつ機能するか、いつ機能しないかはより明確になります。

それはあなたが達成したい言語品質のレベルに依存すると思います。

これらの実際の言語文字列を処理するコードの繰り返しを最小限に抑えようとすると、さまざまな言語の構文や構造におけるロジックの別の層にさらされることになります。繰り返しを最小限に抑えながら言語の元の構造を保持するコードを作成するには、膨大な量の作業が必要になります。

特定の問題に対してどちらのアプローチがより適切であるかを判断する必要があります。繰り返し実行されるコード、または何でも屋になろうとし、無数の言語ルールに対応しようとするコード (間違いなくメンテナンスの悪夢です)。

もちろん、中間点を見つけてコードの繰り返しを最小限に抑えながら、満足のいく文法上の雄弁さを放棄することもできます。Ultima Online の例を見てみましょう。ローカライズされると、以前は「329 枚の金貨の山」という文字列が、「金貨の山:329」。素晴らしいというわけではありませんが、ローカリゼーションに容易に適したかなり合理的なソリューションです。

ローカリゼーションをカバーするためにテキスト値をハードコーディングするのではなく、CMS を使用することをお勧めします。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top