¿Cuáles son las mejores prácticas para internacionalizar una aplicación de escritorio Java Swing?

Question

Estoy seguro de que hay una gran cantidad de métodos, pero ¿cuál es la forma recomendada de hacer esto que tiene la menor cantidad de impacto a su código?

Lo evidente es que se crea archivos de propiedades, pero ¿cómo se intercambian los valores en la prestación? En J2EE siempre vuelve a renderizar toda la página, así que es fácil. Pero en las aplicaciones Swing, ¿acabas de agregar el código para .getProperty() en el método paintComponent (Graphics g)?

Si ese es el caso, ¿no parece pesado ya que ahora tendrá que reemplazar este método en todas partes donde antes no lo necesita ...

adicional: ¿Cómo se configurar un sistema de notificación para volver a procesar todos los componentes actualmente visibles sin forzar algún tipo de patrón de registro?

supongo que si sobreescribo paintComponent (Graphics g) todo lo que tengo que hacer es disparar un evento que algo ha cambiado y el (g Gráficos) paintComponent método será llamado ...

Answer 1

La única solución que se me ocurrió fue la creación de un registro masivo de todos los componentes que tendrían que ser re-renderizados. Luego, si se realiza una llamada para cambiar de configuración regional, simplemente puede llamar al registro y pasará por todos los componentes registrados y ajustará sus valores. Así, por ejemplo para todas las JLabels registrados que va a hacer algo en la línea de

for(JLabel specificJLabel : REGISTRY.registeredJLabels) 
{ 
    String localeKey = specificJLabel.getActionCommand(); 
    specificJLabel.setText(ResourceBundle.getString(localeKey)); 
} 

donde la clave Locale se almacena en el ActionCommand componentes. Entonces, cualquiera que sea la pantalla que se esté procesando actualmente, el panel principal principal es responsable de volver a renderizarla. También de esta manera, el registro no tiene que administrar las claves de configuración regional, estas están completamente desacopladas del registro. Cada componente es responsable de administrar sus propias claves de configuración regional para ResourceBundle.

Answer 2

Lo que se necesita es una ResourceBundle que le permite tener un archivo de propiedades basado en la configuración regional al que acaba de acceder como un archivo de propiedades.

Here is a sample on how to do it

Answer 3

Apoyo cambios en el lenguaje dinámico es un problema complicado. La solución más simple es organizar su UI de tal forma que pueda recrear cualquier panel visible. Eso evita la necesidad de registrar o actualizar componentes, cuando el lenguaje cambia simplemente recreas la vista.

Obviamente se pierde el estado de todos los componentes visibles que pueden ser un problema - pero eso es por lo general la misma en una aplicación web cuando la página se actualiza.

Answer 4

Por lo que yo sé, algunas aplicaciones utilizan el diseño/componente constructores (aconsejado por Karsten Lentzsch, y parte de JGoodies API). Estos constructores incluyen el código para localizar componentes (usando ResourceBundle debajo del capó).

Otras personas (yo incluido) prefieren inyección de recursos; este es normalmente el método menos intrusivo. Esta es la forma elegida por el Swing Application Framework (JSR-296) y otros marcos GUI como Guts-GUI.

También es posible que desee echar un vistazo a this question que es bastante similar a la suya.

En cuanto a los cambios de idioma "sobre la marcha" (Locale notificación de cambio), creo que es más fácil de implementar al usar inyección de recursos (ya lo he implementado en Guts-GUI, Swing Application Framework también puede tenerlo pero yo no estoy seguro de eso).

Java no ofrece ninguna forma de escuchar los cambios Locale, por lo tanto, debe crear su propio "Servicio de configuración regional" (al que debe dirigirse cualquier solicitud de cambio de configuración regional). En este servicio, usted tendría que enumerar todas las ventanas visibles (esto es posible con Window.getWindows(), sin necesidad de registrar los componentes visibles antes) y luego inyectar recursos de nuevo.

Si quieres un ejemplo, echar un vistazo al paquete resource en Guts-GUI source code:

• ResourceInjector muestra la inyección de recursos y método para cambiar Locale, que envía un evento de notificación (utiliza un Evento autobús para ese , pero los oyentes simples serían muy bien también) sobre este cambio
• WindowController escuchas a Locale eventos de cambio

El código interesante para actualizar todas las ventanas visibles se copia en futuro:

for (Window window: Window.getWindows()) 
{ 
    if (window.isVisible()) 
    { 
     injectResources(window); 
     window.repaint(); 
     if (window instanceof RootPaneContainer) 
     { 
      ((RootPaneContainer) window).getRootPane().revalidate(); 
     } 
    } 
} 

Answer 5

Java SE 6 permite volver a cargar los paquetes de recursos sobre la marcha. Simplemente llame a la función estática clearCache() de la clase ResourceBundle. Luego llame de nuevo al getBundle().

Ver this article bajo caché Controles