n层.NET应用程序本地化准则

Question

我希望得到你的一些想法有关

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

让我给你的应用范围：

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

我想它是易于维护的（所以也很容易导出/导入翻译），不存在重复的（因为我们有共同的资源），并可以理解为所接触的代码

大家

资源的地方：

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

资源名称/归类：

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

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

Answer 1

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

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

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

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

Answer 2

包含所有翻译的一个程序集是一个问题，因为它意味着所有的程序集都与该程序集相关联。

我们通常会做的是每个程序集都有自己的资源，然后从所有引用的项目中生成并翻译一个.pot文件（这是一个不错的脚本）。

Answer 3

正如Groo所说，一个巨型组件会是一个糟糕的主意，因为它会导致耦合问题。例如，如果您想更改网站1中的按钮文本，则必须更新该程序集，然后更新网站2和3，尽管2和3完全不需要任何更改。就像其他任何事情一样，你想在可能的情况下隔离你的改变，这样如果有什么事情发生，它会尽可能少地破坏。

我会定义您的程序集，以便您可以根据需要共享一些程序集，但其他程序只包含单个项目所需的资源。从你给出的描述，这里是我会怎样构建你的资源：跨网站共享

• 1 UI相关的资源文件
• 3站点特定的UI相关的资源文件
• 1业务在核心库逻辑相关的资源文件
• 3站点特定的业务逻辑相关的资源文件，存储在各自的业务逻辑项目

在某些情况下，上面我可能混合了哪里哟你只需要一个资源文件，你需要一个完整的独立程序集，但资源的分配基本上是一样的。当然，您需要每种语言的上述每个文件的一个副本。

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

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

最后，关于你对资源分类的问题，这实际上只取决于你自己和（我认为）你的团队最自然的东西。从你所描述的内容来看，这听起来像是你可能想将资源分成显示在网页上的文本和将包含在电子邮件中的文本，但很难说。这是一个非常个人的选择，除了让每个人都更容易找到他们正在寻找的资源之外，它对代码没有任何影响，所以只需按照对您最有意义的方式进行操作即可。