SQL Server、EF 和 MVC 组合的多语言最佳实践

发布于 2024-10-10 00:51:57 字数 260 浏览 4 评论 0原文

ASP.NET MVC,资源管理看起来足以支持应用程序的多语言多文化支持。

但我想知道有关数据的实践。

用户故事;

  1. 用户将文化设置为 en-US,并以英语查看所有产品项目。
  2. 用户将文化设置为 fr-FR,并以法语查看所有产品项目。
  3. 用户将文化设置为 ru-RU 并查看俄语的所有产品项目。
  4. 用户没有正确的更改文化设置,并且应用程序永远无法访问多语言资源,它将使用默认语言和文化。

ASP.NET MVC, resource management is look like enough for application multlingual multiculture support.

But I am wondering practices about data.

User stories;

  1. User set culture as en-US and see all product items in English.
  2. User set culture as fr-FR and see all product items in French.
  3. User set culture as ru-RU and see all product items in Russian.
  4. User doesn't have right change culture settings and application never reach multilingual resources, it will use default language and culture.

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

扫码二维码加入Web技术交流群

发布评论

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

评论(2

み零 2024-10-17 00:51:57

我不确定这正是您要问的问题,但如果您想在数据库级别进行本地化,可以使用依赖于 CONTEXT_INFO 的视图来完成。
这样,您始终查询相同的 VIEW,但它会根据 CONTEXT_INFO 返回不同的结果。

您可以在这里阅读更多相关内容:
数据库本地化 - 查找列表 - 更智能的方式

I'm not sure this is exactly what you're asking about, but if you want to have localization in your DB-level, it can be done using VIEWs that rely on CONTEXT_INFO.
This way you always query the same VIEW, but it would return different results based on the CONTEXT_INFO.

You can read more about this here:
Database Localization - Lookup lists - smarter way

预谋 2024-10-17 00:51:57

可能有一种更优雅的方法在数据库中进行本地化,但我只是将不同语言的数据值存储在这样的表中:

            WIDGETS
            widgetid
            widgetname nvarchar (default English)


            WIDGETSLOCAL
            widgetid      foreign key references WIDGETS(widgetid)
            language_code
            widgetname  nvarchar
            unique composite index on (widgetid, language_code)

然后我要么创建单独的视图(例如 view_WIDGETS_enus、view_WIDGETS_ruru),要么使用WHERE 子句,或将用户的语言代码传递给存储过程。我们的数据库没有严格意义上的“本地化”;我们只是根据用户群的主要母语提供了几种不同的翻译,这些语言恰好是英语、西班牙语和法语。

对于日期,我们始终使用美国格式,但月份缩写为:15 MAR 2010,而不是在 dd/mm/yyyyy 和 mm/dd/yyyy 格式之间切换。我们的数据库不包含任何货币列,因此我们不会遇到小数或货币格式问题。

There may be a more elegant way to do this localization in the database, but I just store the different-language data values in tables like this:

            WIDGETS
            widgetid
            widgetname nvarchar (default English)


            WIDGETSLOCAL
            widgetid      foreign key references WIDGETS(widgetid)
            language_code
            widgetname  nvarchar
            unique composite index on (widgetid, language_code)

And then I either create separate views (e.g. view_WIDGETS_enus, view_WIDGETS_ruru) or use the language code in the WHERE-clause, or pass the user's language code to a stored-procedure. Our databases are not properly "localized" in the strict sense of the word; we just have several different translations available based on the primary native languages of our user-base, which happen to be English, Spanish, and French.

For dates, we always use the US-format but with the month abbreviated: 15 MAR 2010 rather than switching between dd/mm/yyyyy and mm/dd/yyyy formats. Our database does not contain any money columns so we don't encounter decimal or currency formatting issues.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文