当前位置：文江博客话题详情

网站翻译架构及实现

发布于 2024-10-24 04:58:13 字数 343 浏览 2 评论 0原文

我正在开展一个项目，其中网站应该具有多语言支持。现在，该网站预计每天为大约 50 万+ 访问者提供服务，因此它必须非常高效。

我创建了一个参数表 {[ID],[Name]} 和一个链接表 {[objectID],[parameterID],[languageID],[value]}。我认为这是部署多语言支持的最佳方式，同时有权为每种语言翻译不同的参数。

据我所知，服务器的内存比物理硬盘快得多。因此，我计划为我的翻译架构存储 ASP.NET 应用程序状态对象。 (http://msdn.microsoft.com/en-us/library/ms178594.aspx)

到目前为止我的计划听起来怎么样？有什么建议吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

怪异←思 2024-10-31 04:58:13

如果您计划制作一个支持多种语言的应用程序，您的第一反应应该是让 .net 为您完成这项工作。我在你的问题中读到的是你正在设置一些东西来支持这一点。您应该知道，当您想要开发多语言环境时，本地化是必经之路。

看看这篇 msdn 文章，它应该能让您有一个大概的了解关于这个话题。

回复收藏 0 原文

天赋异禀 2024-10-31 04:58:13

因此，应用程序本地化可以分为两个部分：

本地化业务逻辑实体。
本地化其他一切。

在问题中，我看到与业务实体本地化相关的单词。为此，我同意实体及其本地化之间分离的概念。

第 1 部分 - 本地化实体：

我个人在数据库中这样做：

table Entity {EntityID, Name} -this is the entity-related table.
table EntityByLang {EntityID, LanguageID, Name} -this is the localized version of the table for each supported language.

这种方式允许我为每个可本地化属性（如 Name 及其本地化（如果可用））设置默认值在本地化表中。剩下的事情取决于您 - 您需要实现数据访问层，该数据访问层采用针对当前用户语言本地化的 Name 或默认值（如果语言或翻译不适用于给定的语言）。

第 2 部分 - 本地化其他所有内容：

在性能方面没有其他选择的情况下，我建议使用某种静态资源。就我个人而言，我喜欢使用可用于标准 ASP.NET 应用程序的静态资源。

从架构的角度来看，不要直接从 UI 代码中引用本地化代码，就像这样（我不喜欢）：

var translation = HttpContext.Current.GetGlobalResourceObject("hello");
//excuse me, if I don't exactly remember the GetGlobalResourceObject() method name...

相反，我建议使用这种方法：

var translation = AppContext.GetLocalizationService().Translate("hello");

其中：AppContext - 某种门面/工厂（实际上，抽象门面/工厂的实现）。 GetLocalizationService - 最初返回某种ILocalizationService，实现后返回StaticResLocalizationService（它实现ILocalizationService）。这种方式允许从一种本地化切换到另一种本地化。特别是 StaticResLocalizationService 适用于 asp.net 静态资源

抱歉示例代码混乱，但我希望您理解我的方法。

我希望这有帮助！

So, localizing an application can be divided into two parts:

Localizing business logic entities.
Localizing everything else.

In the question I see words which are related to business entity localization. For that purpose I agree with the concept to have separation between entities and their localizations.

Part 1 - Localizing entities:

Personally I do this way in database:

table Entity {EntityID, Name} -this is the entity-related table.
table EntityByLang {EntityID, LanguageID, Name} -this is the localized version of the table for each supported language.

This way allows me to have default values for each localizable property like Name and its localization, if such is available in the localized table. What's left here up to you is - you need to implement the data-access-layer which takes the Name localized for the current user language, or the default value (if language or the translation is not available for the given language).

Part 2 - Localizing everything else:

Here, with no alternatives in terms of the performance, I would recommend using some kind of static resources. Personally I live with static resources available for standard asp.net applications.

From the architectural point of view, don't directly refer to localization code from your UI code, like this (which I don't like):

var translation = HttpContext.Current.GetGlobalResourceObject("hello");
//excuse me, if I don't exactly remember the GetGlobalResourceObject() method name...

Instead, I would recommend using this kind of approach:

var translation = AppContext.GetLocalizationService().Translate("hello");

Where: AppContext - some kind of facade/factory (in fact, implementation of abstract facade/factory). GetLocalizationService - initially returns some kind of ILocalizationService, when implemented it returns StaticResLocalizationService (which implements ILocalizationService). This way allowing switching from one kind of localization to another. And particularly StaticResLocalizationService works with asp.net static resources

Sorry for messy sample codes, but I hope you understand my approach.

I hope this helps!

回复收藏 0 原文