私のアプリケーション (およびおそらく他の多くのアプリケーション) で、ローカリゼーションを使用したいと考えています。ただし、ほぼ等しい文字列を管理するための最良の方法が何であるかはわかりません。
いくつかの質問：
クイックアンサートピック（ローカリゼーション）ではありませんが、少なくともあなたの質問に答えようとします：
1）はい、必須ではありませんが、各テキストを分離しておくことをお勧めします。それらの1つを変更する場合、両方を変更するリスクはありません（おそらく、異なる言語では、コンテキストのために異なるものに翻訳する必要があります）。
2）もちろんです。次の文字列があると想像してください：_Editと_Mark as read。たとえば、イタリア語では、とに翻訳され_ModificaますSegna come già letto。両方の文字列について、同じ文字に「_」を使用して追加することはできません。これは、翻訳者が注意する必要がある問題です。
3）いいえをお勧めします。1）については、異なる文字列を分離しておくようにしてください（前に述べたのと同じ理由で）。翻訳の費用を節約したい場合（誰が望まないのですか？）、文字列を事前に解析して「正規化された」出力を生成し、翻訳者に提供するプログラムを作成できます（可能な場合は、重複を削除して類似の文字列をマージします） ）。ただし、プログラムは詳細を認識しないようにする必要があります。
要約すると、いいえ、プログラム内で（類似した）文字列をマージしようとしないでください。本当に必要な場合は、外部プログラムを使用して（さまざまなモジュールからの文字列を考慮に入れることもできるため、より適切に機能します）、該当する場合にのみ実行されます（ケース3の場合は可能、ケース1と2絶対にありません）。
はい、別のリソース文字列を作成する必要があります。アプリケーションのさまざまなアクションを英語で説明するために edit という単語を使用しています。ただし、別の言語では、これらのアクションは異なる言葉で記述される場合があります (1 つは「編集」、もう 1 つは「変更」など)。そのため、メニューとボタンに異なる文字列を割り当てる機能が必要になります。
1）抽象化とデカップリングを優先する必要があります。カテゴリ「エディション」とアクション「編集」の2つの概念があるため、英語以外の言語では「編集/編集」を使用できないため、2つの別々の文字列を使用するのが理にかなっています。許容範囲内。
2）ここでは、2つの異なる形式の概念が1つしかないため、1つの文字列と変換規則（ "_" + myString）だけが意味をなします。
3）依存します：このボタンによってトリガーされるアクションは、上記のものとまったく同じ概念です：はいの場合は同じ文字列を使用し、使用しない場合は2つを使用します。
これはすべて一般的な考慮事項であり、もちろんニーズに合わせて調整する必要があります。
本当にn個の言語を事前にサポートする必要がある場合は、これらのガイドラインに従ってください。ローカリゼーションプロセス中に自然に表示されるはずです。
将来どこかで英語以外の言語をサポートする必要があり、現在は同じ文字列がたくさんあると予想している場合は、多くの可能性があるため、物事を完璧に行うためにあまり時間をかけないかもしれません。何の役にも立たず、コア機能の強化や追加に時間を費やすことができます。