Localización De Textos En J2me

[ethernet]

    Localización de textos en J2ME
Os presento una clase muy simple para recuperar cadenas de texto localizadas en J2ME. Permite seleccionar el idioma en el que queremos presentar los textos, usando por defecto la localización del dispositivo.

Antes de usar la clase, debemos colocar un fichero de texto para cada idioma que queremos soportar. Este sería un ejemplo para el idioma español:

menu.main.newgame = Nuevo juego
menu.main.options = Opciones
menu.main.help = Ayuda
menu.main.exit = Salir
ingame.lives = Vidas
ingame.energy = Energia

Este fichero lo llamariamos "es-ES.txt" y lo colocaríamos en un directorio llamado "i18n" dentro de los recursos de la aplicación. Si vamos a soportar español, inglés y alemán, tendríamos la siguiente estructura:

i18n/es-ES.txt
i18n/en-UK.txt
i18n/de-DE.txt

La notación de los nombres de ficheros viene dada por los códigos de idioma y país.

Ejemplo de uso

En el siguiente ejemplo, mostraríamos tres cadenas localizadas en el idioma por defecto del teléfono, en el caso de lo hayamos soportado. En otro caso, usaría la localización "en-UK" por defecto. Luego seleccionamos manualmente el idioma alemán-Alemania y volvemos a mostrar las tres cadenas:

Código: [Seleccionar]

Locale locale = new Locale();
  
System.out.println( "New game string = " + locale.getString( "menu.main.newgame" ) );
System.out.println( "Options string = " + locale.getString( "menu.main.options" ) );
System.out.println( "Lives string = " + locale.getString( "ingame.lives" ) );
  
locale.setLocale( "de-DE" );

System.out.println( "\nNew game string = " + locale.getString( "menu.main.newgame" ) );
System.out.println( "Options string = " + locale.getString( "menu.main.options" ) );
System.out.println( "Lives string = " + locale.getString( "ingame.lives" ) );
Podeis descargar un MIDLet de ejemplo desde este enlace. Debereis ejecutarlo en un emulador ya que imprime la salida por la consola.

Notas y posibles mejoras

- En caso de que Locale no encuentre ningun fichero, todas las llamadas a getString() devolverán null.

- Locale asume por defecto "UTF-8" como codificación para los ficheros. En el caso de idiomas asiáticos,hay que emplear "UTF-16" ya que cada caracter requiere dos bytes. En ese caso haríamos algo así:

Código: [Seleccionar]

locale.setEncoding( "UTF-16 " );
locale.setLocale( "jp-JP" );

Una mejora deseable sería seleccionar automáticamente la codificación para cada idioma. Otros idiomas que usan UTF-16 son el Polaco, el Finlandés y el Griego(corregidme si me equivoco)

- El código del analizador léxico podría ser reducido y optimizado usando una filosofía más "java".

- En sistemas de producción, suele existir una clase superior que devuelve "objetos" localizados, sean cadenas de texto, imágenes, etc.


Autor: Zaelsius - Julio Gorgé
Web:  http://www.lemonteam.com' target='_blank'>http://www.lemonteam.com
Código y minitutorial: locale.zip (38kb)
[/LIST]

Si quieres enviar un código de la semana solo tienes que mandarlo a qualopec@gmail.com o por PM a ethernet.

[sés]

 Está bastante bien, pero siento decir que no le veo sentido a algo tan "complejo" en entornos tan limitados como son los móviles.

Normalmente no se incluyen todos los idiomas en el JAR. Se tienen varios ficheros de texto y se empaquetan los del idioma que se deseé (como en la mayoría de los juegos de PC).

Además, nadie tiene un juego en todos los idiomas. Como mucho está en varios y se elige desde el menú, lo que hace innecesario el uso de System.getProperty( "microedition.locale" ).

También, en su momento, probé la clase InputStreamReader (la "supuesta" solución para leer textos), pero para mi sorpresa, en algunos móviles no funciona (creo que ni existía, curioso).


De todas formas es una buena solución si no nos importael tamaño o la velocidad.

[sés]

 Ya recuerdo lo del InputStreamReader. Lo que no me funcionaba (creo que en un Motorola) es este constructor:

Código: [Seleccionar]

InputStreamReader(InputStream is, String enc)No tragaba con ninguna codificación.

[zupervaca]

 yo para los idiomas en aplicaciones moviles tengo uno o varios java con constantes y el traductor solo traduce lo que esta entre comillas y luego compilo con el lenguaje que me interese ya que si no ocupa mucho y asi ademas el idioma se mete directamente en el codigo, aunque es otra forma de hacerlo, para moviles, fue la mas correcta que vi, que no quiere decir que esta que nos pones aqui este mal

saludos