Preferencias de Java e Internacionalización (i18n)

Question

Los tutoriales de Java recomiendan utilizar la API de Preferencias sobre los archivos de Propiedades. Los archivos de propiedades y los paquetes de recursos son la forma recomendada de manejar los requisitos de internación en las aplicaciones.

Estoy considerando usar ambos para una aplicación de escritorio que muestre las preferencias de una manera específica de la localidad.

¿Alguien puede señalar problemas con este enfoque?

Tal vez debería utilizar el período de archivos de propiedades?

Answer 1

Estoy considerando usar ambos para una aplicación de escritorio que muestre las preferencias de una manera específica de la localidad.

bien, así que lo que quiere es traducido archivo de configuración en forma de:

some_translated_key=some_value 

Bueno, a menos que desee apoyar MUI en algún momento que no debería ser un gran problema. Sin embargo, si lo hace, para que diferentes usuarios en la misma computadora puedan usar diferentes idiomas, o el usuario podría cambiar de idioma, tendría problemas para hacer coincidir la clave de una propiedad. Tendría que escanear todas las traducciones mientras lee la clave, y seguramente terminaría con múltiples entradas para la misma clave. ¿Cómo resolver eso? Bueno, esa es una buena pregunta.

Desde mi experiencia, los archivos de configuración deben ser independientes del idioma (cultura neutral) y nunca deben editarse a mano (es decir, las claves de traducción realmente no importan).

pensé que podría haber un problema con la codificación de caracteres, pero siguiente fragmento de código funciona sin un problema (los archivos están codificación UTF-8):

public class Main { 
    private static final String FILE_NAME = "i18ned.properties"; 
    private File propertiesFile; 
    private Properties properties; 

    public Main() { 
     properties = new Properties(); 
     propertiesFile = new File(FILE_NAME); 
     if (propertiesFile.exists()) { 
      try { 
       properties.load(new BufferedReader(new FileReader(
         propertiesFile))); 
      } catch (FileNotFoundException e) { 
       // not likely, but should be logged either way 
      } catch (IOException e) { 
       // logger should be used instead 
       e.printStackTrace(); 
      } 
     } 
    } 

    public void saveProperties() { 
     try { 
      properties 
        .store(new BufferedWriter(new FileWriter(propertiesFile)), ""); 
     } catch (IOException e) { 
      // oops, use logger instead 
      e.printStackTrace(); 
     } 
    } 

    public static void main(String[] args) { 
     Main main = new Main(); 
     main.storeSome(); 
     main.readSome(); 
    } 

    private void readSome() { 
     String highAsciiKey = "żółć"; 
     String value = properties.getProperty(highAsciiKey); 
     System.out.println(value); 
    } 

    private void storeSome() { 
     String highAsciiKey = "żółć"; 
     String highAsciiValue = "łąkę"; 
     properties.setProperty(highAsciiKey, highAsciiValue); 
     saveProperties(); 
    } 

} 

Answer 2

El uso de paquete de recursos para localizar aplicaciones es la forma estándar en Java. Los problemas de esta manera son:

1. no hay verificación del número de compilación y el tipo de parámetros requeridos por el recurso.
2. Es difícil mantener archivos limpios, p. no hay ningún mecanismo que ayude a eliminar cadenas no utilizadas
3. Es difícil hacer que todos los textos se traduzcan a todos los idiomas admitidos.

etc ....

El mecanismo probablemente mejor internacionalización es sugerido por Google en su GWT. Generan clase con método por cadena. Por ejemplo, si tiene texto Hello, {0} generarán método String hello(String name);

lo tanto, no puede pasar ni 0 ni 2 argumentos para este método. Solo uno.

Esto resuelve parcialmente el segundo problema también. Es más fácil ver si el método no se usa en todo el proyecto. No resuelve el tercer problema de todos modos.