¿Ustedes piensan que la internacionalización solo debería hacerse a nivel de código o debería hacerse en la base de datos también?Internacionalización en la base de datos
¿Existen patrones de diseño o prácticas aceptadas para la internacionalización de bases de datos?
Si cree que se trata de un problema de código, ¿simplemente utiliza los archivos de recursos para buscar una clave devuelta desde la base de datos?
Gracias
internacionalización se extiende a la base de datos de la medida en que sus columnas serán capaces de contener los datos. NText, NChar, NVarchar en lugar de Text, Char, Varchar.
En lo que respecta a su UI, para las etiquetas que no cambian, los archivos de recursos son un buen método para usar.
Depende mucho de lo que está almacenando en su base de datos. Tomando ejemplos de un proyecto reciente en el que participé, un título de película que se ingresa en el sitio de un cliente y que solo es visible para ese cliente es un juego justo para almacenar como está en la base de datos. Por otro lado, un código de error del proyector, ya que puede ser visto por el cliente, así como por centros de operaciones de red que pueden estar en diferentes países, debe almacenarse como un código de error (y datos de soporte, como horas de lámpara y el título de la película que se muestra) que se puede traducir a nivel gui dependiendo de la configuración de idioma del espectador.
Si hace referencia a la compatibilidad de su aplicación con varios idiomas en el nivel de interfaz de usuario, entonces hay más posibilidades. Si las etiquetas nunca cambian, a menos que cuando lance una nueva versión, los archivos de recursos que se incrustan en el ejecutable o el ensamblaje en sí son su mejor opción, ya que funcionan más rápido. Si sus etiquetas, por otro lado, necesitan ser ajustadas en tiempo de ejecución por los usuarios, entonces almacenar las traducciones en la base de datos es una buena opción. En cuanto al código en sí, los nombres de tablas & campos en la base de datos, los mantenemos en inglés tanto como sea posible, ya que el inglés es el estándar "de facto" para la gente de TI.
@hova cubre los aspectos técnicos, pero algo que tal vez desee considerar es la compatibilidad de un sistema que muestra un idioma que no comprende.
Una forma de hacer frente a esto es tener el inglés como idioma predeterminado y una configuración de usuario que cambie a un idioma diferente. De esta forma, los usuarios de soporte pueden iniciar sesión y ver el sistema de forma natural (asumiendo que el inglés es su primer idioma), y sus usuarios reales pueden ver el sistema en su primer idioma. OMI, los datos siempre deben ser 'naturales', en el idioma de los usuarios.
Lo que plantea otro punto interesante: ¿su sistema debería permitir idiomas múltiples para instalaciones transfronterizas? En mi experiencia, para la interfaz de usuario sí, pero para los datos, no. Para tomar un ejemplo trivial de formato de dirección, una carta a un tercero francés de un sistema suizo debería tener una dirección de formato suizo en lugar de una francesa, ya que primero tiene que pasar por el sistema postal suizo.
Si sus clientes son japoneses y desean ver sus nombres en Kanji y Katakana (y algunas veces en Gaiji más formal), debe almacenarlos como Unicode. No hay forma de evitar eso.
Incluso cosas como las direcciones son muy diferentes entre los Estados Unidos y Japón. Un esquema no lo reducirá para ambos.
En realidad, te equivocas con el formato de la dirección. La Unión Postal Internacional requiere que lo último en la dirección sea el nombre del país, y debe estar subrayado. Todo el sistema postal suizo necesita analizar es el nombre del país. –