i18n und localization in Java (Kurzfassung mit dem wichtigsten)

[flaite]

Hi,

es ist eigentlich ein ziemlich einfacher aber imho effektiver Mechanismus.
Ich halte die Hoffnung nicht unbegründet, dass dies in Hannover so ähnlich oder vielleicht noch komfortabler genutzt wird, so dass die bestehenden Problematiken weniger werden.

Also:
Die Java Anwendung liest aus den Properties des OS oder des Browsers (je nach Typ der Anwendung) den Locale aus.
Man kann dem Anwender auch eine Funktionalität zur Verfügung stellen, mit der er das Locale für die Anwendung umstellen kann.

Was ist zu tun:
1. Man muß unterschiedliche .properties Dateien mit verschiedenen locale Endungen erstellen.
In help_ws sind das z.B. translations_de.properties und translations_en.properties. Hm. Mir fällt gerade auf, dass es schlauer wäre translations_en.properties in translations.properties umzubenennen aber dazu später.
Das sind eigentlich nur lange Listen von Key/Value-Paaren:
Ein Ausschnitt der translations_de.properties:

Code

exception.internationalisation.PropertyNotFound=Der Datei translation_{0} fehlt das Property {1}.
exception.dblocal.DAOExceptionInsert=Das Objekt {0} kann nicht in der Datenbank gespeichert werden.
exception.dblocal.DAOExceptionSelect=Das select-Statement {0} kann nicht gegen die lokale Datenbank ausgeführt werden.  
exception.dblocal.DAOExceptionDelete=Das Objekt {0} kann nicht aus der lokalen Datenbank gelöscht werden. 

Java ist schlau genug die zum locale passenden Datei zu finden. Wenn man z.B. das Locale es_cl (chilenisches spanisch) hat, wird zuerst nach einer Datei <name>_es_cl.properties gesucht. Dann nach <name>_es.properties und dann nach translations.properties (diese Suche geht unmerklich schnell).

Der lookup auf die Werte im code wird über einfache statische Methode geregelt.

Code

class AppUtils {
// Java findet automatisch die zum Locale gehörige translations_ländercode.properties Datei. 
private static ResourceBundle resourceBundle = ResourceBundle.getBundle("translations");

public static String getValue(String key) { 
	// java sucht automatisch 
        String value = resourceBundle.getString(key);
        if (value == null) value = key; 
        return value;
        
    }
[...]
}

Man kann das locale auch während der Anwendung umsetzen, wenn man oder der Anwender das will.

In zu internationalisierenden Meldungen kann ich dann so einfach darauf zugreifen.

Code

String msg = MessageFormat.format(AppUtils.getValue("exception.dblocal.DAOExceptionInsert"), ticketFull);

Das ist jetzt einfach geschachtelt.
AppUtils.getValue("exception.dblocal.DAOExceptionInsert") ruft die obige statische Methode auf. Und ersetzt bei deutschen Locale:
"exception.dblocal.DAOExceptionInsert"
mit
"Das Objekt {0} kann nicht in der Datenbank gespeichert werden."
(in translations_de.properties steht ja:
exception.dblocal.DAOExceptionInsert=Das Objekt {0} kann nicht in der Datenbank gespeichert werden.

Mit dem äußeren MessageFormat.format(wert, einfuegen); (die äußere Methode in der geschachtelten Methode oben), kann man das noch parametrisieren (geht auch mit mehreren Parametern und Arrays).

Also
MessageFormat.format("Das Objekt {0} kann nicht in der Datenbank gespeichert werden", ticketFull);
ersetzt {0} mit dem String-Wert von TicketFull.

Reicht eigentlich. Bei Zahlen, Datumswerten, etc. greift ein ähnlicher Mechanismus.

Für die Verwaltung der <dateiname>_ländercode.properties gibts Tools mit denen man den Erstellungs-Prozess ein bischen einfacher verwalten kann.
Es ist ein bischen nervig, geht aber.

Gruß Axel