许多项目通过附属程序集进行本地化的可扩展性

时间:2014-10-10 07:49:45

标签: .net localization translation satellite-assembly

我正在开发一个.Net软件产品,该产品包含多种不同大小的应用程序和数十种(可能数百种)程序集。一切都必须翻译成几种语言。

无论如何,在.NET中本地化字符串的建议方法是使用资源字符串创建附属程序集。当然,所有这些示例都只显示了一个程序集,以及如何使本地化在技术上发挥作用。我的问题是,在实践中我不知道这应该如何扩展到大量的程序集

如果我简单地复制每个程序集的方法,我最终需要维护和部署大量的附属程序集,并且我必须在每个需要它的程序集中跟踪同一个字符串/转换。每次翻译发生变化时,我都必须在所有程序集中找到此字符串的所有用法,并对其进行修改。

每当我需要更新我的翻译时,我需要从众多资源文件中提取所有内容,将其发送给翻译人员,然后再将结果传播到正确的资源。当然可以这样做,我假设其中一些可以(并且必须)编写脚本。但是,它并没有让我感到特别顺利和高效。

我能想到的另一个选择是创建一个专用的转换程序集(带有附属程序集),作为本地化字符串的中央存储库。所有程序集的所有字符串的所有翻译都将转到那里,并且每个程序集将依次引用它来吐出翻译。

这似乎使维护变得更加容易,但是当然这个具有大量资源字符串的中央程序集也必须部署在我的应用程序中,即使是最小的应用程序,实际上只需要它们中的一小部分。此外,许多开发人员必须经常更改此组装,这将导致冲突的高风险。

我的问题是:
 如何通过卫星组件进行本地化的方法应该扩展到具有许多组件的大型软件项目?建议的策略和最佳实践是什么?

0 个答案:

没有答案