Prácticas recomendadas de localización de Java

Question

Tengo una aplicación Java con servidor y cliente Swing. Ahora necesito localizar la interfaz de usuario y posiblemente también algunas de las necesidades de datos sean específicas de la configuración regional. Hay pocas cosas en particular sobre las que me gustaría escuchar sus opiniones.

1. ¿Cómo debo distribuir las cadenas localizadas para la IU en los archivos de propiedades? En mi aplicación hay varias vistas y cada una tiene varios paneles. ¿Debo tener un archivo de localización por idioma para cada panel o vista o debo conservar todas las traducciones para un idioma en el mismo archivo? Actualmente me inclino por un archivo por vista y por idioma, pero no estoy seguro de cómo debo manejar algunos términos específicos del dominio que aparecen en muchos lugares. Tener la misma traducción en varios archivos no suena demasiado bien.
2. El servidor arroja algunas excepciones que contienen un mensaje que debe mostrarse al usuario. Pude obtener la configuración regional seleccionada de la sesión y manejar la localización en el servidor, pero creo que sería más elegante mantener todos los archivos de localización en el cliente. He estado pensando en enviar solo una clave de localización del servidor con algún tipo de marcador de posición para información específica de error, que se enviaría con la excepción. Entonces el cliente podría construir el mensaje basado en la clave de localización y reemplazar los marcadores de posición con la información específica del error. ¿Eso suena como una buena manera de manejarlo, o hay otras opciones? Normalmente, mis mensajes de excepción contienen información adicional que cambia para cada caso. Podría ser, por ejemplo, "Un usuario con nombre de usuario Khilon ya existe", en cuyo caso la cadena en el archivo de propiedades sería algo así como "Un usuario con nombre de usuario {0} ya existe".
3. La localización de los datos es el área que me resulta más incierta. Como no estoy seguro de si alguna vez será necesario, hasta ahora no lo he planeado mucho. La parte de la base de datos suena lo suficientemente directa, básicamente solo necesitas una tabla adicional para las cadenas y una columna para saber para qué locale está la cadena. Aunque no estoy seguro de si sería mejor tener una tabla de localización para cada tabla de datos (por ejemplo, Product y Product_names), o podría usar una tabla para cadenas de localización para todas las tablas de datos. La parte realmente difícil es cómo manejar la interfaz de usuario, ya que hasta cierto punto sería necesario que un usuario ingrese texto para un objeto en varios idiomas. En la práctica, esto podría significar, por ejemplo, que un trabajador en Finlandia le daría un nombre al objeto en finlandés e inglés, y luego un trabajador en otro país podría traducirlo a su propio idioma. Si alguno de ustedes ha hecho algo similar, me gustaría saber cómo lo hizo.

Estoy muy agradecido con todos los que pueden compartir sus experiencias conmigo.

P.S. Si conoce sitios web o libros excepcionalmente buenos sobre el tema, me complacerá escucharlos. Por supuesto, he hecho algunas búsquedas en Google y he leído algunos artículos sobre localización, pero aún no me ha pasado nada.

Answer 1

En realidad, de lo que está hablando es Internacionalización (i18n), no Localización (L10n). Según mi experiencia, estás en el camino correcto.

ad 1). Un archivo de propiedades por vista y configuración regional (no es el idioma necesario, ya que es posible que desee utilizar diferentes traducciones para determinados idiomas según el país, es decir, utilizar diferentes cadenas para inglés británico y estadounidense, por lo tanto, diferentes idiomas) es el enfoque correcto. Dado que las aplicaciones tienden a evolucionar, podría ahorrar una buena cantidad de dinero cuando quiera modificar una sola vista (ya que los traductores le cobrarán incluso por algo que no tocarán; tendrán que buscar realmente las cadenas que necesitan actualizarse/recién traducido). También sería más fácil de usar con las herramientas de Memoria de traducción si lo hace bien (nuevas cadenas al final del archivo todo el tiempo).

ad 2). La mejor idea es enviar solo la clave de recursos del servidor u otro proceso; Otro enfoque podría ser asociar una clave de recursos y posiblemente los datos (es decir, un valor numérico) utilizando delimitadores, por lo que el mensaje podría ser recreado y reformateado en el idioma local.

ad 3). He visto varios enfoques para localizar Bases de datos, pero el mejor (y no solo es mi opinión, sino también los miembros de IEEE) es almacenar claves de recursos y recrear los datos en el lado del cliente utilizando la configuración regional adecuada. Por supuesto, esto se aplica a los datos preinstalados, si permite que los usuarios ingresen los datos, surgirán otros problemas ... No hay una solución mágica, hay que pensar qué funciona mejor en su contexto. Me inclinaría a incluir una columna de clave externa que identificará el idioma, pero realmente depende del tipo de datos que se almacenarán.

Desafortunadamente i18n no termina aquí, por favor recuerde dar formato correcto a las fechas y números para que sean comprensibles para las personas que usan su programa. Y también, si tiene una lista de cadenas, el orden de clasificación también debería depender de la configuración regional (se denomina intercalación). Sol solía tener (ahora nuestro adorado Oracle) tiene bastante buen camino i18n que puedes encontrar aquí: http://download.oracle.com/javase/tutorial/i18n/index.html.

Si quiere leer un buen libro sobre el tema de i18n y L10n, le ahorrará años de aprendizaje de estos temas (aunque no necesariamente le enseñará a programarlo), hay un excelente libro de Microsoft Press: " Desarrollo de software internacional "- http://www.amazon.com/Developing-International-Software-Dr/dp/0735615837. Sigue siendo relevante, aunque bastante viejo.

Answer 2

1) Normalmente guardo todo en un archivo y uso nombres que indiquen dónde se usan las propiedades. Por ejemplo, yo uso el prefijo con cosas como "vista" y "menú"

• view.add_request.title
• view.add_request.contact_information.sectionheader
• view.add_request.contact_information.first_name.label
• view.add_request.contact_information.last_name.label
• menu.admin.user_management.add_user.label
• menu.admin.user_management.add_role.label

2) Sí, el hecho de pasar la tecla simplifica las cosas y hace que el código del servidor sea más fácil de probar. También evita tener que pasar información de ubicación al servidor para que decida sobre un idioma para el cliente. Es un cliente complicado, así que deja que se encargue de la localización.

3) No he localizado datos antes (generalmente solo etiquetas, y verbos de UI estáticos), pero probablemente me inclinaría por tener una sola tabla con todas las cadenas locales y locales para empezar (solo para mantenerlo simple)) No estoy seguro de lo que está preguntando en referencia a la interfaz de usuario, pero le sugiero que se asegure de que el conjunto de caracteres que utilice permita todos los idiomas que desee. Asegúrese de leer el artículo de Joel Spolsky titulado: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)