Sprachumstellung per Checkbox, Konzeptfrage

[Tallan]

Hallo zusammen,

ich habe folgende Frage zum Konzept der Sprachänderung eines Programms.


Gehen wir von einem simplen Fall aus:

Ich möchte die Sprache per Menu ändern, hierzu sind im Menu die entsprechenden Checkboxicons angelegt.

Mein JFarme enthält nun sagen wir 3 Contents welche Sprachbestandteile haben.
1. Menu
2. Infofeld
3. Liste

Wenn ich nun per Menu die Sprache ändere muß der Actionlistener im Menu allerdings Referenzen auf die beiden anderen Objekt (2 und 3) haben damit dort entsprechend die Sprache geändert werden kann (per Methodenaufruf z.b).

Gibt es eine bessere Lösung oder muß ich dem entsprechenden Menu alle referenzen auf die Objekte mitgeben die in diesem Fall relevant sind?

Danke Vorab.

 

[Atze]

ich würde eher über das Locale gehen, bzw. mit properties die sprachen implementieren. so dass du nur platzhalter für die token einsetzt und diese dynamisch gefüllt werden.

Trail: Internationalization (The Java™ Tutorials)

 

[Tallan]

ich würde eher über das Locale gehen, bzw. mit properties die sprachen implementieren. so dass du nur platzhalter für die token einsetzt und diese dynamisch gefüllt werden.

Trail: Internationalization (The Java™ Tutorials)

Das habe ich bereits zumindest wenn ich da nichts falsch verstanden habe gemacht

languageBundle = mainFrame.getLanguageBundle();
    	
	    language = new JMenu(languageBundle.getString("language"));

allerdings wenn ich das ganze jetzt per menu ändern möchte brauche ich ja einen listener der auf das menu reagiert und dementsprechend die sprache ändert.
Der Listener benötigt meines erachtens nun referenzen auf alle objekte die "sprachrelevant" sind, um diesen zu sagen das sie die sprache umstellen sollen.
Mein Frage ist jetzt, ob es keine alternative dazu gibt das ich z.b dem Listener nicht alle referenzen mitgeben muß.

 

[Atze]

he? steh ich auf dem schlauch?

Internationalizing the Sample Program (The Java™ Tutorials > Internationalization > Introduction)

anhand dieser schritte kannst du dir den anzeigetext (felder, buttons) doch beim zeichnen dynamisch holen und setzten, wozu denn n listener? oder bin ich grad verwirrt und erkenn den ernst der lage nicht? wenns so ist, dann sorry

 

[Tallan]

he? steh ich auf dem schlauch?

Internationalizing the Sample Program (The Java™ Tutorials > Internationalization > Introduction)

anhand dieser schritte kannst du dir den anzeigetext (felder, buttons) doch beim zeichnen dynamisch holen und setzten, wozu denn n listener? oder bin ich grad verwirrt und erkenn den ernst der lage nicht? wenns so ist, dann sorry

der listener wird benötigt um auf das drücken des menuknopfs zu reagieren und daraufhin soll die sprachänderung stattfinden. ich will im programm also während der laufzeit hin und her springen können.

 

[Atze]

aber neu zeichnen musst du doch so oder so! also kannst du auch mit den neuen werten zeichnen, und musst bei dem event nur mit dem laden des neuen locales etc weitermachen

also wollte ja nicht sagen, dass du keinen listener brauchst! nur dass du dich da nicht mit den referenzen ärgern mussT den listener darfst / musst du ja behalten

 

[Tallan]

aber neu zeichnen musst du doch so oder so! also kannst du auch mit den neuen werten zeichnen, und musst bei dem event nur mit dem laden des neuen locales etc weitermachen

also wollte ja nicht sagen, dass du keinen listener brauchst! nur dass du dich da nicht mit den referenzen ärgern mussT den listener darfst / musst du ja behalten

soweit stimmen wir überein, aber um die "neuen" locals zu laden brauche ich doch die referenzen auf die objekte die die locals neu laden müssen um ihnen eben dies mitzuteilen oder?

 

[Atze]

also beim umschalten gibt dir der event die info für die gewählte sprache, bspw US

damit lädst du n neues löööööcale:
locale = new Locale("en","US");

holst dir damit das passende Bundle:
messages = ResourceBundle.getBundle("MessagesBundle",
locale);

und beim nächsten mal haste am bspw. textfeld den richtigen string
String msg1 = messages.getString("greetings");

 

[Tallan]

also beim umschalten gibt dir der event die info für die gewählte sprache, bspw US

damit lädst du n neues löööööcale:
locale = new Locale("en","US");

holst dir damit das passende Bundle:
messages = ResourceBundle.getBundle("MessagesBundle",
locale);

und beim nächsten mal haste am bspw. textfeld den richtigen string
String msg1 = messages.getString("greetings");

soweit so gut so hab ich das ja, aber :

messages = ResourceBundle.getBundle("MessagesBundle", locale);

muß ich ja in den entsprechenden anderen klassen die davon abhängen auch ausführen?

 

[Atze]

kannst du das nicht "globaler" designen, das alle benötigten klassen drauf zugreifen können?

 

[Tallan]

kannst du das nicht "globaler" designen, das alle benötigten klassen drauf zugreifen können?

darauf zugreifen ist nicht das problem, aber wie sag ich den klassen das sie die sprache neu einlesen sollen dafür brauch ich ja wieder referenz auf die klassen

 

[Atze]

ne, müssen die ja garnicht selber machen, da brauchst du halt ne art filter, der das event mitbekommt, das benötigte locale lädt und allen klassen zur verfügung stellt

 

[Tallan]

Das Bundle steht allen Klassen zur verfügung, aber das alleine Reicht nicht :

mein Bundle liegt im MainFrame, dieser beinhaltet z.b das
Menu und ein Infofeld.
Im Menu wird jetzt die Spracheinstellung für das Bundle(im MainFrame) geändert, hier passiert jetzt noch garnichts, erst durch erneutes abfragen der per bundle.getString....
erhalte ich die gewünschten Daten. D.h ich muß dies auch für das Infofeld ausführen, womit ich eine Referenz auf dieses Brauche um eine entsprechende Methode aufzurufen.

 

[Atze]

ok, dein design

 

[Landei]

Ich halte es generell für eine gaanz schlechte Idee, die Sprache zur Laufzeit zu wechseln, denn diese Funktion wird im Lebenszyklus eines normalen Programms in der Regel höchsten 1 (in Worten: EIN) Mal aufgerufen. Wenn man sowieso ein Properties-File oder so hat, bietet sich eine kleines separates "Sprachwechsel-Tool" an. Natürlich sollte ein eventuell vorhandener Installer auch schon die Sprache abfragen.

 

[tfa]

Ich halte es generell für eine gaanz schlechte Idee, die Sprache zur Laufzeit zu wechseln, denn diese Funktion wird im Lebenszyklus eines normalen Programms in der Regel höchsten 1 (in Worten: EIN) Mal aufgerufen. Wenn man sowieso ein Properties-File oder so hat, bietet sich eine kleines separates "Sprachwechsel-Tool" an. Natürlich sollte ein eventuell vorhandener Installer auch schon die Sprache abfragen.

Die Sprache im laufenden Betrieb umstellen zu können, ist absolut keine schlechte Idee. Bei uns ist das eine Anforderung. Die Software wird an vielen verschiedenen Standorten eingesetzt, Anwender arbeiten auch oft außerhalb ihrer Heimatländer. In Belgien ist es z.B. Gesetz, dass eine Software sich jeder Zeit auf Niederländisch und Französisch betreiben lässt. Für Service und Entwickler ist es auch praktisch, eben mal die Sprache umschalten zu können, wenn man etwa einen Bugreport aus dem Ausland bekommt oder jemanden telefonisch was erklären möchte.

Rein technisch ist so ein Feature auch kein großes Problem. Wir gehen den ganzen Swing-Komponentenbaum durch. Jede Komponente hat einen eindeutigen Namen, über den in den Property-Dateien der lokalisierte Text geholt werden kann. So kann man auch Tabellenheader, Tooltips usw. verwalten.

 

[Tallan]

Die Sprache im laufenden Betrieb umstellen zu können, ist absolut keine schlechte Idee. Bei uns ist das eine Anforderung. Die Software wird an vielen verschiedenen Standorten eingesetzt, Anwender arbeiten auch oft außerhalb ihrer Heimatländer. In Belgien ist es z.B. Gesetz, dass eine Software sich jeder Zeit auf Niederländisch und Französisch betreiben lässt. Für Service und Entwickler ist es auch praktisch, eben mal die Sprache umschalten zu können, wenn man etwa einen Bugreport aus dem Ausland bekommt oder jemanden telefonisch was erklären möchte.

Rein technisch ist so ein Feature auch kein großes Problem. Wir gehen den ganzen Swing-Komponentenbaum durch. Jede Komponente hat einen eindeutigen Namen, über den in den Property-Dateien der lokalisierte Text geholt werden kann. So kann man auch Tabellenheader, Tooltips usw. verwalten.

richtig technisch ist das kein problem, die frage ist allerdings wie man es am besten umsetzt

und es macht sehr wohl sinn, da in diesem fall personen verschiedener nationalitäten abwechselnd an dem rechner arbeiten weshalb multilanguage unerlässlich ist