モジュラーWPF/Clickonceローカリゼーションソリューションをご利用になる場合

Question

Clickonceで実行されるWPFアプリケーションをローカライズする必要があります。このアプリを配布する予定の製品には、ユーザーがスペイン語、フランス語、日本語などをアップロードできる「言語パック」が付いているということです。言語パックを使用してWebインターフェイスを翻訳します。また、WPFアプリケーションをウェブサイトが実行されている言語で動作させたいと思っています。ローカライゼーションにWPFローカライゼーションエクステンションを使用する予定です：http://wpflocalizeextension.codeplex.com/

問題は、各言語パックがリリース上で独自の分離製品サイクルは主製品のリリースサイクルとは別のものです。さらに、すべての言語を含めることはできません。これは、8MBのROMを搭載した小型のARM9デバイス上で行われるためです。また、各言語パックは別々のサイクルなので、アプリケーションを構築するときにどの言語パックが存在するのかわかりません。 （たとえば、新しいバージョンをリリースして数週間後に、以前はサポートされていない言語を追加する新しい言語パックをリリースします）。

私が考えていた解決策の1つに、WPFアプリの英語バージョンがデフォルトの英語各言語パックにResources.dllを追加し、マニフェストを新しいResources.dllへの参照を持つものに置き換えます。厳密なファイルハッシュやClickonceのコード署名要件でもこれが可能ですか？それとも、言語パックがインストールされたときにアプリケーションマニフェストが改ざんされているのではないかということですか？マイクロソフトのエコシステムでこれを行う方法はありますか？ Clickonceの展開を生成する際には、事前にサポートされている言語を知っている必要があります。それを除いて、よりモジュラ的なローカリゼーション+デプロイメントシステムの提案はありますか？

Answer 1

ファイルの1つを変更してマニフェストに再署名しないと、音が鳴りません。

これは内部専用のアプリだと、それを配備して署名/ハッシュを有効にすることができます。これにより、セキュリティ上の重大なリスクが高まります（アプリがハイジャックされマルウェアに置き換えられる可能性があるため）。インターネットにアクセスできない場合は、そのようにする必要はありません。

私は、1つのファイルのハッシュをオフにすることもできます - アプリケーションファイルダイアログを見てください。繰り返しますが、これはセキュリティ上のリスクですが、デプロイメント全体を覆すほどではありません。

言語パックごとに異なる展開を作成することもできますし、アプリケーションを起動してリソースへのパスを変更した後、適切な言語パックをダウンロードさせることもできます。私はそれが本当に可能かどうかは分かりませんが、私はそこに投げ捨てると思っていました。