リソースファイル、string.Formatと.NET内のプレースホルダ

Question

私の知る限り、.NETのリソースファイルを使用してローカライズされた文字列の動的データを処理する最適な方法は、resources.resxファイルにローカライズされた文字列を含めることですその中のプレースホルダ：Lorem {0} ipsum。とコード内で、このように処理します：string.Format(Resources.My_Localized_Key, myValue);。

私の懸念は、次のとおりです。

1 /どのようにプレースホルダは、実際の値に置き換えられますことを確認しますか？たとえば、チームの新しい開発者は、このローカライズされた文字列を書いている新しいコードで使用する必要があるかもしれませんが、データを入力する必要があることは認識していません。どのような種類のデータでもない。

2 /後で何らかの理由でローカライズされた文字列がLorem {0} ipsum {1}に変わります。、アプリケーション全体でこの文字列のすべての使用が更新されるようにするにはどうすればよいですか？

これを処理する方法はありますか？たとえば、リフレクションを使用することなく、またはローカライズされた文字列の内容を解析することなく、厳密に型付けされた方法でこれらのプレースホルダを処理する方法...？それともそれを行う方法ですか？

Answer 1

実際には、問題1の場合、開発者はコンテンツを確認せずに文字列を再利用する可能性は低く、そうした場合、コードを実行するときにプレースホルダに気づくでしょう。だからそれは起こりそうもなく、世界の終わりにはならないだろう。

問題2の場合、Visual Studioで自動的に生成されたプロパティの「Find Usages」を使用して、リソースが使用されているすべての単一の場所を検索し、適切な数（および順序）のパラメータが存在することを確認できますどこでも使用されています。しかし、一般的に言えばリソースストリングはそれほど再利用されません（たとえば、言語的ルールやスペース制限などにより、異なるコンテキストで翻訳を変更する必要があるため、異なるコンテキストでローカライズ可能なテキストを再利用することは実際には推奨されません）。

私が見る別のリスクは、トランスレータがプレースホルダを省略または混乱させる可能性があることです。これは検出するのが難しいでしょう。しかし、これはローカリゼーションのバグの一例に過ぎません...アプリをローカライズするときに間違っていることが多くあり、しばしばそれらを守るための確実な方法はありません。

Answer 2

私は、あなたがresxファイルからリソースクラスを生成し、代わりにそれを使用するVisual Studio（http://www.codeproject.com/Articles/31257/Custom-Tools-Explained）用のカスタムツールを書くことができると思います。標準的なもの。あなたのツールでは、ローカライズされた文字列を解析でき、プレースホルダがある場合は、プロパティResources.My_Localized_Keyの代わりにメソッドを生成できます。メソッドは、プレースホルダーの数に応じて適切な数のパラメータを持つResources.My_Localized_KeyFormat(object param)のように見えます。

しかし、これは単なるアイデアであり、私はそれを自分で実装していません（しかし、私はresx-file用のコード生成のためのカスタムツールを実装しました。

または、コンパイル時にparamsをstring.FormatのバージョンにチェックするF＃を使用できます。