n-Tiered .NET应用程序本地化指南

Question

我想了解一些关于

的想法

• 资源名称/分类
• 资源的地方

让我给你一个应用范围：

• 3种或更多支持的语言
• 3个MVC网站[有很多共享资源，还有一些独特的资源]
• 1个共享的MVC扩展库
• 1个核心业务库，具有共享功能和业务对象[还包含资源]
• 3个具有三个网站特定业务逻辑的业务库[也包含资源]
• 1 SQL 2008数据库在所有网站之间共享，有时会发送本地化的电子邮件。

我希望它易于维护（因此也很容易导出/导入以进行翻译），不要重复（因为我们有共同的资源），并且对于与代码接触的每个人都可以理解

资源的位置：

• 我应该创建一个包含所有翻译的程序集吗？并在我的项目中创建对该程序集的引用（即使可能将其添加到SQL服务器中）？
• 或者我应该使用源代码管理来保持所有资源文件同步吗？
• 其他一些想法？

资源名称/分类：

所以我们有本地化的电子邮件，按钮上的文字（像文本一样的命令），标签，错误信息，信息信息等等。

如何将这些项目分类为资源文件，您只是将它们全部转储到一个文件中吗？或者您将它们分类为字符串和电子邮件资源文件，您使用哪种分类？

Answer 1

正如Groo所提到的，一个超级装配将是一个不好的主意，因为它会导致耦合问题。例如，如果要更改网站1中的按钮文本，则必须更新该程序集，然后更新网站2和3，即使2和3根本不需要任何更改。就像其他任何事情一样，您希望在可能的情况下隔离您的更改，以便在出现故障时尽可能少地进行更改。

我会定义您的程序集，以便您可以根据需要共享某些程序集，但是其他程序包含仅包含单个项目所需的资源。从您给出的描述中，我将如何构建您的资源：

• 1个跨网站共享的UI相关资源文件
• 3个特定于站点的UI相关资源文件
• 核心库中的1个与业务逻辑相关的资源文件
• 3个与站点相关的业务逻辑相关资源文件，存储在各自的业务逻辑项目中

在上面的某些情况下，我可能已经混淆了你只需要一个资源文件，你需要一个完整的独立程序集，但资源的划分基本相同。当然，每种语言都需要上述每个文件的一份副本。

我绝对建议将这些文件存储在源代码管理中。它们是应用程序源代码的一部分，就像代码一样，源代码控制将为您带来同样的好处。

关于SQL Server，当你说它发送本地化的电子邮件时，你的意思是它是通过存储过程实现的，还是其他一些代码使用数据库中的数据来发送电子邮件？无论哪种方式，我都没有太多答案。我不知道SQL Server本身如何处理本地化，如果它是一个发送电子邮件的应用程序，它很大程度上取决于本地化文本的来源。

最后，关于你对资源进行分类的问题，它实际上只取决于你和（我假设）你的团队最自然的东西。根据您的描述，您可能希望将资源分成将显示在网页上的文本和将包含在电子邮件中的文本，但很难说。这是一个非常个人化的选择，除了让每个人都能更容易找到他们正在寻找的资源之外，它对代码没有任何影响，所以请选择对你来说最有意义的东西。

Answer 2

我们有类似的系统设置;我们使用的是仅用于文本的数据库。然后我们有一个通用程序集，它提供了获取本地化字符串以及自定义表达式提供程序的方法，因此我们可以使用标准＆lt;％$ Resources：zzzz％＆gt; aspx / ascx文件中的语法。

我们的数据库已设置好，因此我们可以为令牌提供默认文本，以及本地化版本和应用程序（例如，简化我们的“翻译”表格包含以下列:(令牌，区域设置，应用程序，NativeText） ）。这样，如果需要，我们可以为特定应用程序提供覆盖。

这样做的好处是我们还可以提供翻译编辑器（我们目前没有，但它可能是未来的选项），而且导出/导入翻译也不是太糟糕（并没有声称它没有错误） - 无论如何，我认为翻译将成为一个难题。

我们仍然使用标准资源文件，但仅适用于真正特定于应用程序且不太可能更改的字符串;我建议不要这样做。这只是意味着我们无法轻松创建要翻译的字符串列表。

Answer 3

包含所有翻译的一个程序集是一个问题，因为它意味着所有程序集都耦合到该单个程序集。

我们通常做的是让每个程序集都有自己的资源，然后从所有引用的项目中生成并转换单个.pot文件（有一个nant脚本可以执行此操作）。