文字列をより多く(別々に)変換する必要がある場合に備えて、カスタムIDを使用します。ドキュメンテーションでは、人間の理解しやすさと翻訳コンテキストを望む場合に使用することをお勧めします。翻訳を管理するためにツールを使用した場合、保守についてあまり心配する必要はありません(たとえばxliffmerge)。
xi18n
ツールではすでに文字列の一致が行われているため、より均等な文字列が見つかると、<trans-unit>
という文字列の下に文字列が埋め込まれます。あなたはこのユニットのための(ターゲット)翻訳された文字列を提供するよりも、すべてのソース文字列の代わりに使用されます。 IDは、文字列自体の内容に基づいているため、ローカライゼーションツールの複数の実行間で変更しないでください。
私の提案は、IDについて心配することではなく、あまりにも多くを再使用することではありません。文字列だけを書くと、それらは一緒にマッチし、翻訳はすべて同じになります。カスタムIDを使用する場合は、IDを使用して手動で翻訳を維持することを忘れないでください。
ソース文字列の変更の場合は、(もちろん)注意しなければならないものです。
完全性のための簡単なケーススタディをお試しください。 同じ翻訳が必要な2つの同じ文字列がアプリ内にあるとしましょう。 xi18n
を実行し、messages.xlf
を生成し、既に翻訳されたファイル(たとえばmessages.cs.xlf
)にマージして<trans-unit>
を翻訳し、アプリを構築して展開します。 誰かが来て、あなたがこれらの文字列の1つを変更したいと思っています。 2つの場合があります。ソース文字列を変更する(または新たに翻訳する)か、翻訳のみを変更する(ソース文字列は同じままです)。 最初の場合、コードに行き、ソース文字列を更新して、ローカライズプロセスを再度実行します。新しい<trans-unit>
が作成されます。新しい翻訳を提供し、アプリケーションをビルドすると完了です。 2番目のケースでは、コードに移動し、新しい翻訳を持つ必要がある文字列にカスタムID(説明と意味もお勧めします)をスラップします。ローカリゼーションプロセスを実行すると、新しい<trans-unit>
(カスタムID付き)が生成されます。あなたは、それが慣れ親しんで構築し、展開しているように翻訳します。