n 层 .NET 应用程序本地化指南
我想了解您关于
- 资源名称/分类
- 资源位置
的一些想法让我简单介绍一下应用程序的范围：
- 3 种或更多支持的语言
- 3 个 MVC 网站[有很多共享资源，也有一些独特的资源]
- 1 个共享 MVC 扩展库
- 1 个核心业务库，具有共享功能和业务对象 [还包含资源]
- 3 个业务库，具有三个网站的特定业务逻辑 [还有资源]
- 1 SQL 2008 数据库在所有网站之间共享，有时会发送本地化的电子邮件。
我希望它易于维护（因此也可以轻松导出/导入以进行翻译），不重复（因为我们有公共资源），并且每个接触代码的人都可以理解
资源的位置：
- 我应该创建一个包含所有翻译的程序集吗？ 并在我的项目中创建对该程序集的引用（即使可能将其添加到 SQL Server）？
- 或者我应该使用源代码控制来保持所有资源文件同步？
- 还有其他想法吗？
资源名称/分类：
所以我们有本地化的电子邮件、按钮上的文本（类似命令的文本）、标签、错误消息、信息消息等。
您如何将这些项目分类到资源文件中，您只是将它们全部转储到一个文件中？ 或者您将它们分类为 strings 和 emails 资源文件，您使用哪种分类？
I would like to get some of your ideas about
- resource name / categorizing
- place of resources
Let me just give you the scope of the application:
- 3 or more supported languages
- 3 MVC websites [with a lot of shared resources, and also some unique resources]
- 1 shared MVC extensions library
- 1 core business library, which has shared functionality, and business objects [also contains resources]
- 3 business libraries that have specific business logic for the three websites [also with resources]
- 1 SQL 2008 database shared among all websites, sends sometimes localized emails.
I would like for it to be easily maintainable (so also easily exported/imported for translation), not to be duplicate (since we have common resources), and understandable for everybody that comes in contact with the code
Place of the resources:
- should I create one assembly containing all the translations? And create a reference to that assembly in my projects (even if possible adding it to SQL server)?
- or should I use source control to keep all the resource files in sync?
- some other ideas?
resource name / categorizing:
So we have localized emails, text on buttons (command like texts), labels, error messages, information messages etc etc.
How do you categorize these items into resources files, do you just dump them all in one file? Or do you categorize them into a strings , and an emails resource files, which categorization do you use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我们有类似的系统设置； 我们使用的是仅用于文本的数据库。 然后，我们有一个通用程序集，它提供了获取本地化字符串的方法以及自定义表达式提供程序，以便我们可以使用标准的 <%$ Resources:zzzz %> aspx/ascx 文件中的语法。
我们的数据库已设置好，因此我们可以为令牌提供默认文本，以及本地化版本和应用程序（例如，简化的“翻译”表具有以下列：（令牌、区域设置、应用程序、NativeText））。 这样，如果需要，我们可以为特定应用程序提供覆盖。
这样做的优点是我们还可以提供翻译编辑器（目前还没有，但将来可能会选择），而且导出/导入翻译也不错（并不是说它没有错误 - 我认为无论如何，翻译将是一个困难的话题）。
我们仍然使用标准资源文件，但仅适用于真正特定于应用程序且不太可能更改的字符串； 我建议不要这样做。 这只是意味着我们无法轻松创建要翻译的字符串列表。
We have a similar system setup; What we use is a database just for the text. Then we have a common assembly that provides methods to get localized strings along with a custom expression provider so we can use standard <%$ Resources:zzzz %> syntax inside aspx/ascx files.
Our database is set up so we can provide a default text for a token, along with a localized version and an application (eg, simplified our "Translation" table has the following columns: (Token, Locale, Application, NativeText) ). This way we can provide overrides for specific applications if we need to.
This has the advantage that we can also provide a Translation Editor (we don't currently, but it is a possible future option), and also exporting/importing translations isn't too bad (not claiming that it is without fault - I think translation is going to be a hard topic no matter what).
We do still use standard resource files, but only for strings that are truly application specific and also unlikely to change; I'd advise against this. It just means we can't create the list of strings to translate as easily.
正如 Groo 提到的，一个大型装配体并不是一个好主意，因为它会导致耦合问题。 例如，如果您想要更改网站 1 中的按钮文本，则必须更新该程序集，这会导致网站 2 和 3 更新，即使 2 和 3 根本不需要任何更改。 就像其他任何事情一样，您希望尽可能隔离您的更改，以便在出现问题时尽可能少地出现问题。
我将定义您的程序集，以便您可以根据需要共享一些程序集，但让其他程序集包含仅单个项目所需的资源。 根据您给出的描述，我将如何构建您的资源：
在上面的某些情况下，我可能混淆了只需要资源文件和需要完整独立程序集的情况，但资源的划分本质上是相同的。 当然，对于每种语言，您都需要上述每个文件的一个副本。
我绝对建议将这些文件存储在源代码管理中。 它们是应用程序源代码的一部分，就像代码一样，源代码控制将为您带来同样的好处。
关于 SQL Server，当您说它发送本地化电子邮件时，您的意思是它通过存储过程执行此操作，还是其他代码使用数据库中的数据发送电子邮件？ 不管怎样，我没有太多答案。 我不知道 SQL Server 本身如何处理本地化，如果它是一个发送电子邮件的应用程序，那么它在很大程度上取决于本地化文本需要来自哪里。
最后，关于您对资源分类的问题，这实际上取决于您和（我认为）您的团队认为最自然的方式。 根据您的描述，听起来您可能希望将资源分成将显示在网页上的文本和将包含在电子邮件中的文本，但这很难说。 这是一个非常个人化的选择，除了让每个人更容易找到他们正在寻找的资源之外，它对代码没有任何影响，所以只要选择对你来说最有意义的就可以了。
As Groo mentioned, one mega-assembly would be a bad a idea since it would cause a coupling issue. For example, if you wanted to change the button text in web site 1, you'd have to update that assembly, which then causes an update to web sites 2 and 3, even though 2 and 3 didn't need any changes at all. Just like with anything else, you want to isolate your changes where possible so that if something breaks, it breaks as little as possible.
I would define your assemblies so that you can share some as needed, but have others that contain resources needed only for individual projects. From the description you've given, here is how I would structure your resources:
In some cases above I may have mixed up where you just need a resource file and where you need a full standalone assembly, but the division of resources is essentially the same. And of course, you'll need one copy of each of the above files per language.
I would absolutely recommend storing these files in source control. They're a part of the source of your app, just like the code, and source control will give you the same benefits.
Regarding SQL Server, when you say that it sends localized e-mails, do you mean that it does that through a stored procedure, or that some other code uses data from the database to send e-mails? Either way, I don't have much of an answer. I don't know how SQL Server itself handles localization, and if it's an app that's sending the e-mails, it depends a lot on where the localized text needs to come from.
Finally, regarding your question on categorizing the resources, it really just depends on what seems the most natural to you and (I assume) your team. From what you've described, it sounds like you might want to split your resources out into text that will be shown on web pages, and text that will be included in emails, but it's hard to say. This is a very personal choice, and it has no effect on the code other than making it easier for everyone to find the resource they're looking for, so just go with what makes the most sense to you.
包含所有翻译的一个程序集是一个问题，因为这意味着所有程序集都耦合到该单个程序集。
我们通常做的是让每个程序集都有自己的资源，然后从所有引用的项目中生成并翻译一个 .pot 文件（有一个 nant 脚本可以做到这一点）。
One assembly containing all the translations is a problem, since it means all your assemblies are coupled to that single assembly.
What we usually do is have each assembly have its own resources, and then generate and translate a single .pot file from all referenced projects (there is a nant script which does that).