java swing localization

Mejores prácticas de localización de Java



swing localization (2)

1) Por lo general, guardo todo en un archivo y uso nombres que indican dónde se usan las propiedades. Por ejemplo, prefijo con cosas como "ver" 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í, pasar la clave simplifica las cosas y facilita la prueba del código del servidor. También evita tener que pasar información de configuración regional al servidor para que decida el idioma del cliente. Es un cliente grueso, así que déjalo manejar la localización.

3) No he localizado los datos antes (generalmente solo etiquetas, y el verbage estático de la interfaz de usuario), pero probablemente me inclinaría por tener una sola tabla con todas las cadenas y locales localizados para comenzar (solo para mantenerlo simple). No estoy seguro de lo que estás preguntando en referencia a la interfaz de usuario, pero te sugiero que te asegures de que cualquier conjunto de caracteres que uses permita todos los idiomas que quieras admitir. Asegúrese de leer el artículo de Joel Spolsky titulado: El Absoluto Mínimo de todos los desarrolladores de software Absolutamente, positivamente debe saber acerca de los conjuntos de caracteres y Unicode (¡sin excusas!)

Tengo una aplicación Java con servidor y cliente Swing. Ahora necesito localizar la interfaz de usuario y posiblemente también algunos de los datos deban ser específicos del entorno local. Hay pocas cosas en concreto en las que me gustaría escuchar sus opiniones.

  1. ¿Cómo debo distribuir las cadenas localizadas para la IU en 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 guardar todas las traducciones para un idioma en el mismo archivo? Actualmente me inclino por un archivo por vista e idioma, pero no estoy seguro de cómo debo manejar algunos términos específicos de dominio que aparecen en muchos lugares. Tener la misma traducción en varios archivos no suena demasiado bien.
  2. El servidor lanza algunas excepciones que contienen un mensaje que debe mostrarse al usuario. Podría 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 desde el servidor con algún tipo de marcadores de posición para información específica de error, que se enviaría con la excepción. Luego, el cliente podría construir el mensaje basándose en la clave de localización y reemplazar los marcadores de posición con la información específica del error. ¿Suena como una buena forma 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, " Ya existe un usuario con nombre de usuario Khilon ", en cuyo caso la cadena en el archivo de propiedades sería algo así como " Ya existe un usuario con nombre de usuario {0} ".
  3. La localización de los datos es el área que menos me queda clara. 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 clara, básicamente solo necesita una tabla adicional para las cadenas y una columna para indicar la configuración regional de 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 las 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, se requeriría 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 finé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 encantaría saber cómo lo hizo.

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

PD: Si conoce algún sitio web o libro excepcionalmente bueno sobre el tema, me encantaría saberlo. Por supuesto, he hecho un poco de googlear y he leído algunos artículos sobre localización, pero todavía no hay nada alucinante.

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

anuncio 1). Un archivo de propiedades por vista y configuración regional (no es necesario el idioma, ya que es posible que desee utilizar diferentes traducciones para ciertos idiomas según el país, es decir, usar diferentes cadenas para el inglés británico y el estadounidense, por lo tanto, diferentes lugares) es el método adecuado. 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 encontrar cadenas que necesiten ser actualizadas). recién traducido). También sería más fácil de usar con las herramientas de la memoria de traducción si lo haces correctamente (nuevas cadenas al final del archivo todo el tiempo).

anuncio 2). La mejor idea es enviar solo la clave de recursos desde el servidor u otro proceso; otro enfoque podría ser adjuntar una clave de recursos y posiblemente los datos (es decir, el valor numérico) utilizando delimitadores, por lo que el mensaje podría recrearse y reformatearse en el idioma local.

anuncio 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 las claves de recursos y volver a crear 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, uno debe pensar qué funciona mejor en su contexto. Me inclino por incluir una columna de clave externa que identifique el idioma, pero realmente depende del tipo de datos que se almacenarán.

Desafortunadamente, i18n no termina aquí, recuerde que debe formatear correctamente las fechas y los números para que sean comprensibles para las personas que utilizan su programa. Y también, si tiene alguna lista de cadenas, el orden de clasificación también debe depender de la configuración regional (se denomina intercalación). Sol solía tener (ahora nuestro querido oráculo) tiene un rastro i18n bastante bueno que puede encontrar aquí: http://download.oracle.com/javase/tutorial/i18n/index.html .

Si desea leer un buen libro sobre el tema de i18n y L10n, eso le ahorrará años de aprender estos temas (aunque no es necesario, le enseñará cómo programarlo), hay un gran libro de Microsoft Press: "Desarrollando software internacional" - http://www.amazon.com/Developing-International-Software-Dr/dp/0735615837 . Sigue siendo relevante, aunque bastante antiguo.