mejores prácticas multilingües en SQL Server, EF y combinaciones de MVC

Question

ASP.NET MVC, gestión de recursos es mirada como el apoyo suficiente para multiculture multlingual aplicación.

Pero me pregunto prácticas acerca de los datos.

Historias de usuarios;

1. cultura del usuario como en-US y ver todos los artículos de productos en Inglés.
2. cultura del usuario como fr-FR y ver todos los artículos de productos en francés.
3. cultura del usuario como ru-RU y ver todos los artículos de productos en ruso.
4. El usuario no tiene que cambiar la configuración de cultivo adecuadas y aplicación nunca llegar a los recursos en varios idiomas, se utilizará el lenguaje y la cultura por defecto.

Answer 1

No estoy seguro de que esto es exactamente lo que preguntas acerca, pero si usted quiere tener en su localización a nivel de base de datos, se puede hacer uso de las vistas que se basan en CONTEXT_INFO. De esta manera siempre consultar el mismo punto de vista, pero sería devolver resultados diferentes en base a la CONTEXT_INFO.

Se puede leer más sobre esto aquí: localización de bases de datos - listas de consulta - forma más inteligente

Answer 2

Puede haber una manera más elegante de hacer esto localización en la base de datos, pero acabo de almacenar los valores de datos de diferentes idiomas en las tablas de la siguiente manera:

            WIDGETS
            widgetid
            widgetname nvarchar (default English)


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

Y entonces o bien crear vistas separadas (por ejemplo view_WIDGETS_enus, view_WIDGETS_ruru) o utilizar el código de idioma en la cláusula WHERE, o pasar código de idioma del usuario para un procedimiento almacenado. Nuestras bases de datos no están debidamente "localizada" en el sentido estricto de la palabra; sólo tenemos varias traducciones disponibles sobre la base de los idiomas nativos primarios de nuestra base de usuarios, que resultan ser Inglés, Español, Francés y diferentes.

Para las fechas, siempre usamos los EE.UU.-formato, pero con el mes abrevia el 15 marzo 2010 en lugar de cambiar entre dd / mm / yyyy y formatos dd / mm / aaaa. Nuestra base de datos no contiene ninguna columna de dinero por lo que no hacemos decimal encuentro o problemas de formato de moneda.