2008-10-02 23 views
17

He estado jugando con las características de localización .NET integradas y parece que todos confían en poner datos en archivos resx.¿Cómo localizas un sitio web basado en bases de datos?

Pero la mayoría de los sistemas no pueden confiar en esto porque se basan en bases de datos. Entonces, ¿cómo resuelves este problema? ¿Hay una forma integrada en .NET o creas una tabla de traducción en SQL y lo haces todo de forma manual? Y si tiene que hacer esto en la mayoría de sus sitios, ¿hay alguna razón para usar incluso la forma de localización de resx?

Un ejemplo de esto es que tengo una lista de preguntas frecuentes en mi sitio, guardo esta lista en la base de datos para poder agregar/eliminar más fácilmente, pero al ponerlo en la base de datos, no tengo forma de traducir esto información en múltiples idiomas.

Respuesta

16

En mi opinión, la localización del contenido dinámico (por ejemplo, sus preguntas frecuentes) debe hacerla en su base de datos. Dependiendo de cómo se almacenan sus preguntas, probablemente crearía una columna de "configuración regional" y la usaría al seleccionar las preguntas de preguntas frecuentes de la base de datos. No estoy seguro de si esto se escalaría muy bien cuando comenzaras a localizar muchas tablas.

Para contenido estático (por ejemplo, etiquetas de campo de formulario, texto estático, iconos, etc.) probablemente debería estar bien utilizando recursos basados ​​en archivos. Sin embargo, si realmente quisiera, parece que no sería muy difícil crear una implementación de proveedor de recursos personalizada que pudiera manejar esto.

Aquí hay algunos enlaces relacionados:

0

Actualmente, t La traducción no es algo que se pueda hacer automáticamente. La mejor manera es hacer que una persona traduzca y use los métodos de Nick para mostrar el idioma adecuado.

2

Para un elemento dado en su modelo de datos, divida la parte de la descripción en una tabla localizada con una columna Id de entorno local (LCID).

Así la mesa para el Producto no en el hecho de contener la descripción de productos o nombre, sino sólo su valor duras y rápidas (ProductId, EAN, NumberInStock, NextStockData, isActive, IsPublished), etc.

ProductDescription contiene entonces Nombre del producto, nombre, descripción, LCID

2

Vivo en Canadá, por lo que el multilingüismo es un gran problema. He visto dos enfoques. La primera opción es almacenar todos los datos localizados para un registro específico en una tabla diferente, vinculada a la tabla original por la clave principal y la configuración regional. La segunda opción es similar a la primera, excepto que para cada configuración regional, hay una tabla diferente, con la configuración regional como sufijo para el nombre de la tabla.

Opción A

Item (ItemID, ...) 
ItemLocal (ItemID,LocaleID,....) 

Opción B

Item (ItemID, ...) 
Item_ENUS (ItemID,....) 
Item_ENGB (ItemID,....) 
Item_FR (ItemID,....) 

Una tercera opción pensé reciente, lo que sería muy bueno si una base de datos compatible de forma nativa sería la de almacenar los valores de todos los locales en el mismo campo Y si el campo se configuró como varchar-multilocal, entonces tendría que acceder pasando un parámetro para especificar el idioma. Nada de esto existe tal como lo conozco, pero es algo que creo que realmente haría las cosas mucho más fáciles y mucho más fluidas.

+3

FYI: local! = Locale – Tanktalus

Cuestiones relacionadas