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

Question

我想听听你的一些想法

• 资源名称/分类
• 资源地点

让我告诉你应用范围:

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

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

资源位置:

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

资源名称/分类:

所以我们有本地化的电子邮件、按钮上的文本(命令之类的文本)、标签、错误消息、信息消息等。

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

Answer 1

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

我们的数据库已设置好，因此我们可以为 token 提供默认文本，以及本地化版本和应用程序(例如，简化我们的“翻译”表具有以下列:( token 、区域设置、应用程序、本地文本) ).这样我们就可以在需要时为特定应用程序提供覆盖。

这样做的好处是我们还可以提供一个翻译编辑器(我们目前没有，但它是 future 可能的选择)，而且导出/导入翻译也不是太糟糕(并不是说它没有错误- 我认为无论如何翻译都将是一个难题)。

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