本地化战略答案

【问题标题】：Localization Strategy本地化战略
【发布时间】：2010-07-30 18:50:10
【问题描述】：

我们目前正在讨论两种本地化策略：

A.拥有一个用于业务对象结构的 XML 文件，其中包含一个本地化键，用于翻译一个单独的 CSV 文件。

例如。 /Resources/Schema.xml

在单独的 CSV 文件中：我们有所有用于翻译的键/值对：

/Resources/Localized.txt

Model_Title、Title、Title（法语）、...

这样，当结构发生变化时，我们只需在 LocalizedKey 就位时更改一次 XML。

B.根据文化为每种语言提供单独的 XML 文件。

例如。有两个文件： /Resources/en-US/US-Localized.xml /Resources/fr-AU/AU-Localized.xml

这样，它们将具有相同的架构但不同的文件。因此，用户必须确保架构相同，因为他们需要更改两次，而不是选项 #1，他们只能更改一次。

但是，这里的可读性要好得多，因为用户不必跟踪进行更改的键。

您对我建议的策略有什么想法/想法？

谢谢，

【问题讨论】：

为什么不只为每种语言创建一个文件？对于 B，我不明白为什么每种语言会有两个文件...
因为对于客户端来说，读取xml并进行任何更改会更容易。
你们提供翻译的资源吗？现在我重新阅读了 yoru 问题，似乎客户或用户正在提供他们自己的翻译。我理解正确吗？
我认为您是在开玩笑说 your XML 文件更易于阅读。请尝试为此使用标准化的文件格式，而不是重新发明轮子 - 尝试使用 gettext 格式，如果您真的喜欢 XML，请使用 XLIFF。对于他们俩来说，已经制作了很多工具。

【解决方案1】：

环境不清楚——web？桌面？内部企业集成了某种东西或其他东西？您没有使用工具链支持的任何 i18n 框架（gettext、.NET 资源文件...）是否有任何特殊原因？

一般来说，我会说你想按文化分离资源（但老实说，fr_AU 应该很少见）以获得更好的可维护性，并且不必为许多每个文化版本加载整个文件情况。如果您支持的语言/文化数量达到数十种或更多，则尤其如此。

但是，适应 XML 架构更改很重要。 XML 可以从更简单的结构（数据库或文件中的键值对）自动生成，并通过通用模式进行验证。

这是（如评论者所述）您提供本地化产品还是客户可以创建自己的本地化。

【讨论】：

【解决方案2】：

一般来说，您应该考虑现有工具，而不是从头开始。

【讨论】：