27

一般に、変換メソッドはキー > 値のマッピングを取り、キーを使用してそれを値に変換します。現在、翻訳キーに名前を付ける 2 つの異なる方法を認識していますが、私のチーム内では、どの方法が最善と思われるかについて合意に達していません。

方法 1: 完全な英語の単語または文を使用します。

Name => Name
Please enter your email address => Please enter your email address

方法 2: 状況を説明するキーワードを使用します。

NAME => Name
ENTER_EMAIL => Please enter your email address

個人的には、メッセージの意味を直接示す方法 1 を好みます。翻訳が存在しない場合は、キーにフォールバックできますが、これは問題を引き起こしません。ただし、翻訳が頻繁に変更される場合、すべてのファイルを更新する必要があるため、この方法は面倒です。また、テキストが長い場合、これらのキーは非常に大きくなります。これは のようなキーを使用することで解決されますENTER_EMAILが、言い回しは完全に文脈から外れています。抽象変換キーのリストは膨大になります。すべてのキーの使用方法を説明するメタデータが必要であり、衝突がはるかに簡単に発生する可能性があります。

両方の長所または 3 番目の方法はありますか? アプリケーションで翻訳キーをどのように使用しますか? 私たちの場合、それはphpベースのWebアプリケーションですが、上記の問題はi18n全般について話すのに十分一般的だと思います.

4

2 に答える 2

22

これは、iOS/OSX 開発者も直面する質問です。そして彼らのために、方法 1 を想定したと呼ばれる標準ツールgenstringsさえあります。しかしもちろん、Apple 開発者はこのツールを使用する必要はありません。私は使用しません。

方法 1 で得られるセーフティ ネットは優れていますが (つまり、何らかの理由で文字列をローカライズするのを忘れた場合にキーを表示できます)、競合するキーにつながる可能性があるという欠点があります。文法規則や文脈の違いにより、1 つの同一の表示テキストを 2 つの異なる方法でローカライズする必要がある場合があります。たとえば、「E-mail」のフランス語訳は、ダイアログ タイトルの場合は「E-mail」、ボタンの場合は「Envoyer un e-mail」になります (フランス語では、「E-mail」という単語は名詞であり、名詞と動詞の両方である英語とは異なり、動詞として使用することはできません)。方法 2 では、EMAIL_TITLE と EMAIL_BUTTON のキーを使用してこの問題を解決できます。おまけとして、翻訳者が正しく翻訳するためのヒントが得られます。

方法 2 のもう 1 つの利点は、英語およびすべてのローカライズでキーを更新することを心配することなく、英語のテキストを変更できることです。

ということで、方法2をオススメします！

于 2012-05-18T14:44:42.927 に答える
1

なぜ両方の世界を使わないのですか？短い文字列には方法 1 を使用し、完全な文である長い文字列には方法 2 を使用します。同じファイルに両方を混在させることを恐れません。

たとえば、次の文字列では、新しいアプリ バージョンでユーザー エクスペリエンスが変更された場合、テキストが変更される可能性があります。

"screen description" = "Tap the plus button to add a new item. Tap an item for more options or to edit its details.";

したがって、ここでは方法 2 を適用するのが理にかなっています。ただし、次の例のような単純な文字列の場合は、方法 1 の方が便利です。

"Preferences" = "Preferences";

一般に、人々が物事を標準化しようとするとき、それは私には制限的に見えることがよくあります。個人的には、いくつかのメソッドが有効な、より「アナキスティック」なアプローチを好みます (メソッド #1 とメソッド #2 のスレッドだけでなく、たとえば、開発者のチームがコーディング スタイルをめぐって争う場合など)。

于 2015-08-31T15:09:26.610 に答える