Multilingual best practices on SQL Server, EF and MVC combinations

Question

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.

It may help: http://stackoverflow.com/questions/119568/best-practice-to-make-a-multi-language-application-in-c-winforms — ShahidAzim, Dec 31 '10 at 13:19

score 2 · Accepted Answer · edited May 23 '17 at 11:55

2

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

edited May 23 '17 at 11:55

Community

1
1

answered Dec 31 '10 at 13:47

Moshe

2,638
2
28
32

score 0 · Answer 2 · answered Dec 31 '10 at 16:20

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.

Multilingual best practices on SQL Server, EF and MVC combinations

2 Answers2