SQL Server、EF 和 MVC 组合的多语言最佳实践
ASP.NET MVC,资源管理看起来足以支持应用程序的多语言多文化支持。
但我想知道有关数据的实践。
用户故事;
- 用户将文化设置为 en-US,并以英语查看所有产品项目。
- 用户将文化设置为 fr-FR,并以法语查看所有产品项目。
- 用户将文化设置为 ru-RU 并查看俄语的所有产品项目。
- 用户没有正确的更改文化设置,并且应用程序永远无法访问多语言资源,它将使用默认语言和文化。
ASP.NET MVC, resource management is look like enough for application multlingual multiculture support.
But I am wondering practices about data.
User stories;
- User set culture as en-US and see all product items in English.
- User set culture as fr-FR and see all product items in French.
- User set culture as ru-RU and see all product items in Russian.
- User doesn't have right change culture settings and application never reach multilingual resources, it will use default language and culture.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我不确定这正是您要问的问题,但如果您想在数据库级别进行本地化,可以使用依赖于 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
可能有一种更优雅的方法在数据库中进行本地化,但我只是将不同语言的数据值存储在这样的表中:
然后我要么创建单独的视图(例如 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:
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.