我们目前正在讨论两种本地化策略：
：一种。拥有一个用于业务对象结构的XML文件，其中包含用于翻译的单独CSV文件的本地化密钥。
例如。 /Resources/Schema.xml
在单独的CSV文件中：我们拥有翻译的所有键/值对：
/Resources/Localized.txt
Model_Title，Title，Title（in French），...
这样，当结构发生变化时，我们只需在LocalizedKey到位时更改XML一次。
B中。根据Culture为每种语言提供单独的XML文件。
例如。有两个文件： /Resources/en-US/US-Localized.xml /Resources/fr-AU/AU-Localized.xml
这样，它们将具有相同的架构但是具有单独的文件。因此，用户必须确保模式与他们需要更改两次相同，而不是选项＃1，他们可以只更改一次。
但是，这里的可读性要好得多，因为用户不必跟踪进行更改的密钥。
您对我建议的策略有什么想法/想法？
谢谢，
答案 0 :(得分：0)
环境尚不清楚 - 网络？桌面？内部企业是否整合了某种东西？您是否有任何特殊原因没有使用您的工具链支持的任何i18n框架（gettext，.NET资源文件......）？
总的来说，我想说你想要按文化来划分资源（但要成为最好的，fr_AU应该是罕见的），以便具有更好的可维护性，而不必为许多文化版本加载整个文件。的情况。如果支持的语言/文化数量达到数十个或更多，则尤其如此。
但是，适应XML架构更改很重要。 XML可以从简单的结构（键值，在数据库或文件中）自动生成，并通过通用模式进行验证。
这是（作为评论者注意到）您是否提供本地化产品，或者客户是否可以创建自己的本地化。
答案 1 :(得分：0)
一般来说，您应该考虑现有工具，而不是从头开始。
在.net中，我们正在使用由Data Driven ASP.NET Localization Resource Provider and Editor
创建的rick strahl