通常、文字列リソースがコード内ではなくコードの外部に保持されるのはなぜですか？

一般に、多くのプラットフォームでは、文字列リソースを.resxまたは.xmlファイルに書き込み、プラットフォームに依存するアプローチを使用してそれらを取得しています。

つまり、iOSでは、を介してNSBundle.MainBundle、Context.ResourcesAndroidで使用して取得しています。

このアプローチの利点は何ですか？また、コードで直接アクセスできない理由は次のとおりです：

1. クロスプラットフォームプロジェクトでは、どのプラットフォームでも統合せずに直接アクセスできます。

2. 構築中、リソースが適切に構築されたかどうかについての懸念はありません。

3. コーダーは、多言語処理などの機能を使用できます

要するに、文字列リソースがそのように構成されている理由は何ですか？

[編集]

私のファイルが他のプロジェクト間で共有される「コア」プロジェクトの一部であるとしましょう。（PCL、クロスプラットフォームプロジェクトのファイル構造について考えてください。）

そして、私のファイルは.resx / .xmlファイルとまったく同じで、次のようになっていると仮定します（私はxmlのプロではありません、ごめんなさい！）：パラメーターParamètres

したがって、これは基本的にカスタムxmlであり、適切な文字列を取得するためにキー/言語をポイントします。

ファイルは、アプリケーション内にアクセス可能なファイルを追加するのと同じようにアプリケーションの一部になり、PCLを使用してコーディングされた文字列リソースにアクセスするシステムになります。これにより、アプリケーションにオーバーヘッドが追加されますか？

ローカリゼーションと国際化、

文字列を外部に保持することで、再コンパイル（せいぜい再リンクだけで、せいぜい新しいフォルダにドロップする）しなくても、文字列を変更（読み取り：翻訳）できます。

文字列リソースのみを含むファイルがある場合は、リソースファイルを翻訳会社などに提供して翻訳を取得できます。素人にたくさんのコードファイルを渡して翻訳をしなければならない場合（おそらく誰にでもコードを渡したくないかもしれない）、どれだけ難しいか想像できると思います。

国際化/ローカリゼーションに加えて、このようにテキスト文字列を分離することにより、校正者はmessages.${LOCALE}、真のソースコードファイルに触れることなく、に分離されたスペル/文法/句読点の修正を送信できます。コードの変更でブラックアウトが発生する可能性がありますが、そのようなテキストの修正は受け入れます。コードとメッセージの両方の同時変更を受け入れる場合、校正者がチェックアウトしたときに存在したメッセージをコード変更が再定義しない限り、それらを分離しておくとパッチをマージしやすくなりますmessages.en_US。

また、実装方法によっては、アプリケーションを再リンクする必要がない場合もあります。コードはmessages.${LOCALE}、特定のメッセージから行138を取得するだけで、実行時に行番号が決定されます。

これは、言語/プラットフォームが文字列のローカライズを実装することを決定した方法です。ローカライズのすべてのアプローチでは、翻訳を取得するために何らかの外部リソースファイルが必要です。主な問題点は、これらのリソースをどのように維持するかです。

これらのリソースファイルを手動で保守する必要があるように見えますが、これはかなりの負担になる可能性があります。また、繰り返し文字列の共有が複雑になります。また、現在1つの言語のみを出荷しているときにこれを行う必要があるため、さらに負担が大きくなります。

一般的な代替手段は、ソースコード内の翻訳可能な文字列をマークアップし、これらの文字列をクロスプラットフォームおよびクロス言語でうまく機能する標準POファイルに自動的に抽出するGNU Gettextアプローチです。開発者の観点から見ると、XMLリソースファイルの手動メンテナンスに勝るものはありません。