変換ファイルのキー値のベストプラクティス

Question

一般に、変換メソッドはキー>値マッピングを使用し、そのキーを値に変換するためにキーを使用します。今私は、あなたの翻訳キーの名前を付けるための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のようなキーを使用することで解決されますが、フレーズは完全にコンテキスト外です。抽象的な変換キーのリストは膨大なものになります。その使用方法を説明するすべてのキーのメタデータが必要であり、衝突がより簡単に発生する可能性があります。

どちらの世界でも最高の方法がありますか？あなたのアプリケーションでどのように翻訳キーを使用しますか？私たちの場合、それはPHPベースのWebアプリケーションですが、上記の問題は一般的にi18nについて話すには十分一般的だと思います。

Answer 1

これはiOS/OSX開発者が直面する問題です。また、方法1を前提としたstandard tool called genstringsもあります。もちろん、Appleの開発者はこのツールを使用する必要はありません。

方法1で得られるセーフティネットはいいですが（つまり、文字列をローカライズするのを忘れた場合はキーを表示できます）、競合するキーにつながるという欠点があります。文法規則や文脈の違いのために、表示テキストの同一部分を2つの異なる方法でローカライズする必要がある場合があります。たとえば、 "Eメール"のフランス語の翻訳は、ダイアログのタイトルであれば "Eメール"、ボタンの場合は "Envoyer un eメール"（フランス語では "Eメール"という単語は名詞となります。名詞と動詞の両方の英語とは異なり、動詞として使用することはできません）。方法2では、この問題を解決するためにEMAIL_TITLEとEMAIL_BUTTONというキーを持つことができました。これはボーナスとして、翻訳者に正しく翻訳するためのヒントを与えます。

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

ですので、方法2をおすすめします。

Answer 2

なぜ両方の世界を使用しないのですか？私は短い文字列のために方法＃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のスレッドのように、開発者のチームがコーディングスタイルに挑戦する場合など）、より "アナキスト的"なアプローチを好みます。