2011-02-09 38 views
0

我需要本地化通过Clickonce运行的WPF应用程序。问题在于我们打算发布该应用的产品具有“语言包”,用户可以在其中上传西班牙语/法语/日语等。语言包,它翻译网页界面。我们还希望WPF应用以任何网站运行语言运行。我打算使用WPF本地化扩展进行本地化:http://wpflocalizeextension.codeplex.com/寻求模块化的WPF/Clickonce本地化解决方案

问题是每个语言包必须是其发行版本上自己的独立产品循环与主要产品的发布周期分开。此外,我们不能包含所有的语言,因为这是在一个有8MB ROM的小型ARM9设备上进行的。而且由于每个语言包都是独立的循环,因此在构建应用程序时我们不知道什么语言包存在。 (例如:发布新版本几个星期后,我们发布了一个新的语言包,增加了以前不支持的语言。)

我想到的一个解决方案是包含英文版的WPF应用程序,默认的英文版安装,然后让每个语言包添加Resources.dll,并将清单替换为具有对新的Resources.dll的引用的清单。这甚至可以通过Clickonce的严格文件散列和代码签名要求实现,或者如果在安装语言包时应用程序清单已被篡改,它会吓坏了吗?有没有办法在Microsoft生态系统中执行此操作?看起来您在生成Clickonce部署时必须事先知道支持哪些语言。除此之外,对于更多模块化本地化+部署系统的任何建议?

回答

1

如果您更改其中一个文件并且不重新签名清单,它会吓坏了。

如果这是一个仅限内部使用的应用程序,则可以部署它并转换签名/散列。这确实会增加很大的安全风险(您的应用程序可能很容易被劫持并被恶意软件取代),所以如果有互联网访问安装,您不希望这样做。

我想你也可以关闭一个文件的哈希 - 查看应用程序文件对话框。再次,这是一个安全风险,但并不像整个部署一样困难。

您可以为每个语言包创建不同的部署,或让应用程序在启动后下载正确的语言包并更改资源路径。我不知道这是否真的有可能,但我认为我会把它扔出去。