RCP language packs

Status
Nicht offen für weitere Antworten.

foobar

Top Contributor
Ich habe nur 3 Languagepacks installiert:

org.eclipse.jface.nl1
org.eclipse.swt.nl1
org.eclipse.ui.workbench.nl1

Damit sind alle Dialoge, Meldungen, Preferences, Menüs etc. schon mal abgedeckt. Für die Hilfe und Ähnliches brauchst du dann bei Bedarf noch mehr nl1-Plugins.
 
G

Gast2

Gast
ok alles klar dachte es gibt nur ein plugin....
wenn ich das System.getProperties().set("osgi.nl","<new_locale">); zu laufzeit ändern will hab ich schon mitbekommen dass es nicht geht...
Aber wenn ich es neu setze und restart mache sollte er doch meine neuen einstellungen übernehmen oder?
 

Wildcard

Top Contributor
Nein, ein Property ist flüchtig. Du brauchst schon einen Startup Parameter wie -Duser.locale=xy oder -nl xy
 

foobar

Top Contributor
Ohne Neustart stelle ich mir das aber ziemlich schwierig vor, weil dann alle Views/Editoren/Menüs etc neu erstellt werden müssten.
 
G

Gast2

Gast
ja das stimmt , ich versuch grad noch die Locale zu beeinflussen
bevor die Workbench gestartet wird
Code:
returnCode =
            PlatformUI.createAndRunWorkbench(display, new ApplicationWorkbenchAdvisor());
 
G

Gast2

Gast
mhm habs mal so versucht aber leider bringt es nicht weiß jemand genau was die methode macht??? Dachte die reinitialiert vielleicht die bundles...
versteht jemand den mechanismus richtig wie nl pakete gesetzt werden??

Code:
Locale.setDefault(<new Locale>);
    NLS.initializeMessages("org.eclipse.ui.internal.messages",
        org.eclipse.ui.internal.WorkbenchMessages.class);
// andere

 PlatformUI.createAndRunWorkbench(display, new ApplicationWorkbenchAdvisor());
 

Wildcard

Top Contributor
Es ist schon von Java aus technisch nicht möglich die Sprache zur Laufzeit zu wechseln, da alle Übersetzungen in public static final String Konstanten abgelegt sind.
 
G

Gast2

Gast
Soviel ich weiß stimmt des aber nicht...
Nehmen wir zum Beispiel WorkbenchMessages
Code:
public class WorkbenchMessages extends NLS {

	// ==============================================================================
	// Workbench Actions
	// ==============================================================================

	// --- File Menu ---
	public static String NewWizardAction_text;
	public static String NewWizardAction_toolTip;
	public static String CloseAllAction_text;
	public static String CloseAllAction_toolTip;
	public static String CloseAllSavedAction_text;
	public static String CloseAllSavedAction_toolTip;
	public static String CloseEditorAction_text;
	public static String CloseEditorAction_toolTip;
	public static String CloseOthersAction_text;
	public static String CloseOthersAction_toolTip;
	public static String NewEditorAction_text;
	public static String NewEditorAction_tooltip;
	public static String SaveAction_text;
	public static String SaveAction_toolTip;
	public static String SaveAs_text;
	public static String SaveAs_toolTip;
	public static String SaveAll_text;
	public static String SaveAll_toolTip;
	public static String Workbench_revert;
	public static String Workbench_revertToolTip;
	public static String Workbench_move;

	public static String Workbench_moveToolTip;
	public static String Workbench_rename;
	public static String Workbench_renameToolTip;
	public static String Workbench_refresh;
	public static String Workbench_refreshToolTip;
	public static String Workbench_properties;
	public static String Workbench_propertiesToolTip;


	public static String Workbench_print;
	public static String Workbench_printToolTip;
	public static String ExportResourcesAction_text;
	public static String ExportResourcesAction_fileMenuText;
	public static String ExportResourcesAction_toolTip;
	public static String ImportResourcesAction_text;
	public static String ImportResourcesAction_toolTip;
	public static String OpenRecent_errorTitle;
	public static String OpenRecent_unableToOpen;
	public static String Exit_text;
	public static String Exit_toolTip;

ich denke ich müsste einfach die neu setzen und dann passt des, aber die oben genannte methode macht des leider nicht und den mechanismus wo das mit den nl packete gesetzt wird hab ich noch nicht gefunden.... oder noch nicht richtig verstanden....
 

Wildcard

Top Contributor
Ach, stimmt ja, die sind nicht final. Ändert trotzdem nichts, der Aufwand alle Strings zu ersetzen wäre viel zu groß. Jede Klasse die irgendwelche externalisierten Strings verwendet müsste in ein lächerlich großes Observer Monster eingespannt werden.

@foobar
der Eclipse Weg ist ganz nützlich, da der Compiler deine Strings prüfen kann und wenn man eine Message Klasse pro Package verwendet, wird auch nur das geladen was benötigt wird.
 
G

Gast2

Gast
Welchen NLS-Mechanismus verwendest du denn?

Ich suche nur grad wie eclipse die reource bundles mit den nl packs verwendet und vielleicht kann ich da was abschauen und dann irgendwie manipulieren


ich glaub nicht dass ich mit deinem link die eclipse konstanten beeinflussen kann damit er mir die neu setzt bevor ich die workbench neu initialisert wird...

@ wildcard ich kann mir doch via reflection mir alle konstanten holen und dann muss ich die neu setzen mit der entprechenden propertie datei...

Mein Ziel ist es ja nur vor die workbench initalisiert wird das einmal zu machen sobald sie initialisiert ist kann man sie sprache nicht mehr ändern...
 

foobar

Top Contributor
Wildcard hat gesagt.:
der Eclipse Weg ist ganz nützlich, da der Compiler deine Strings prüfen kann und wenn man eine Message Klasse pro Package verwendet, wird auch nur das geladen was benötigt wird.

Klingt für mich erstmal nach unnötigem Mehraufwand. Im Moment habe ich eine Propertiesdatei pro Anwendung und mit Hilfe von Eclipse lässt sich wunderbar nach obsoleten und fehlenden Properties suchen. Wenn man zusätzlich noch eine Klasse verwendet, muß man ja immer an zwei Stellen nachpflegen. Ist das nicht aufwendiger?
 
G

Gast2

Gast
Hier meine lösung in der Klasse MessageResourceBundle gibt es folgende Methode...
sobald die applikation einmal gestartet wird , wird nlSuffixes !=null und es werden keine neuen bundles mehr geladen...
wenn man die locale neu setzt nlSuffixes auf null setzt(Reflection) und die oben genannte methode ausführt funktioniert des mechanismus wunderba...

Code:
private static String[] buildVariants(String root) {
		if (nlSuffixes == null) {
			//build list of suffixes for loading resource bundles
			String nl = Locale.getDefault().toString();
			ArrayList result = new ArrayList(4);
			int lastSeparator;
			while (true) {
				result.add('_' + nl + EXTENSION);
				lastSeparator = nl.lastIndexOf('_');
				if (lastSeparator == -1)
					break;
				nl = nl.substring(0, lastSeparator);
			}
			//add the empty suffix last (most general)
			result.add(EXTENSION);
			nlSuffixes = (String[]) result.toArray(new String[result.size()]);
		}
		root = root.replace('.', '/');
		String[] variants = new String[nlSuffixes.length];
		for (int i = 0; i < variants.length; i++)
			variants[i] = root + nlSuffixes[i];
		return variants;
	}
 

Wildcard

Top Contributor
foobar hat gesagt.:
Klingt für mich erstmal nach unnötigem Mehraufwand. Im Moment habe ich eine Propertiesdatei pro Anwendung und mit Hilfe von Eclipse lässt sich wunderbar nach obsoleten und fehlenden Properties suchen. Wenn man zusätzlich noch eine Klasse verwendet, muß man ja immer an zwei Stellen nachpflegen. Ist das nicht aufwendiger?
Nein, der Wizard macht das. Er legt dir die Strings in der Klasse und in der Properties Datei an. Alle Projekte der Eclipse Foundation externalisieren AFAIK auf diese Weise. Ist auch ganz nett um zu prüfen ob ein String an mehreren Stellen verwendet wird.
 

foobar

Top Contributor
Wildcard hat gesagt.:
foobar hat gesagt.:
Klingt für mich erstmal nach unnötigem Mehraufwand. Im Moment habe ich eine Propertiesdatei pro Anwendung und mit Hilfe von Eclipse lässt sich wunderbar nach obsoleten und fehlenden Properties suchen. Wenn man zusätzlich noch eine Klasse verwendet, muß man ja immer an zwei Stellen nachpflegen. Ist das nicht aufwendiger?
Nein, der Wizard macht das. Er legt dir die Strings in der Klasse und in der Properties Datei an. Alle Projekte der Eclipse Foundation externalisieren AFAIK auf diese Weise. Ist auch ganz nett um zu prüfen ob ein String an mehreren Stellen verwendet wird.
Ja das habe ich im Wizard schon gesehen. Da kann man ja auswählen welchen Mechanismus man verwenden will. Ist eben nur die Frage wie leicht sich das später pflegen lässt, denn die Beschriftungen ändern sich ja schon mal oder fallen weg. Ich werds nachher einfach mal ausprobieren.
 

foobar

Top Contributor
Wie bringe ich Eclipse denn dazu den neuen NLS-Mechanismus zu verwenden? Ich habe das Bundle org.eclipse.osgi.util bereits überall hinzugefügt d.h. Runconfig, plugin etc. und trotzdem ist die Funktion im Externalizewizard nicht verfügbar? Was mache ich falsch?
 

Wildcard

Top Contributor
Hinzufügen musst du eigentlich gar nichts. Bei einem Plugin Projekt bietet dir der Wizard 'Use Eclipse Externalization' an.
Die Pflege ist auch kein Problem, geht über find broken externalized strings. Ausserdem logged die Plattform alle unused und missing Entries in den Properties Dateien beim Laden des Bundles mit und erzeugt einen Eintrag in der Error Log View. Damit siehst du sofort wenn etwas nicht mehr passt.
 

foobar

Top Contributor
Wildcard hat gesagt.:
Hinzufügen musst du eigentlich gar nichts.
Die Option ist aber erst verfügbar, wenn das Plugin org.eclipse.osgi.util sich im Buildpath befindet. Bei meinem auf Features basierenden Projekt wird die Option aus irgendwelchen Gründen nie aktiv. Bei dem RcpMailProjekt habe ich das Plugin einfach dem Product hinzugefügt und sofort war die Option verfügbar.

siehe hier:
If unchecked the standard externalization mechanism is used, otherwise the new Eclipse string externalization mechanism is used.
Note: This field is only present if the project build path contains the org.eclipse.osgi.util.NLS class.
Quelle: http://help.eclipse.org/help32/inde.../reference/ref-wizard-externalize-strings.htm

Wildcard hat gesagt.:
Bei einem Plugin Projekt bietet dir der Wizard 'Use Eclipse Externalization' an.
Die Pflege ist auch kein Problem, geht über find broken externalized strings. Ausserdem logged die Plattform alle unused und missing Entries in den Properties Dateien beim Laden des Bundles mit und erzeugt einen Eintrag in der Error Log View. Damit siehst du sofort wenn etwas nicht mehr passt.

Ich habe den Mechanismus mal an einem RcpMailProjekt getestet und bin echt begeistert davon. Die Pflege der Propertiesdatei funktioniert wunderbar.
 

Wildcard

Top Contributor
Ok, bei mir sind es meistens PlugIn Projekte, da ist es automatisch in Build Path. Wieder was gelernt...
Ich habe den Mechanismus mal an einem RcpMailProjekt getestet und bin echt begeistert davon. Die Pflege der Propertiesdatei funktioniert wunderbar.
Ich bin auch sehr angetan davon. Allerdings frage ich mich, ob die Eclipse Probleme mit dem PermSpace eventuell auch auf die vielen static Strings zurückzuführen sind ???:L
 
G

Gast2

Gast
Muss ich die NL packages noch irgendwie besonders hinzufügen in meinem feature??? Kann ja nicht sein dass ich jedes NL plugin dass ich verwende extra im feature.xml hinzufügen muss oder??
Mein Problem ist beim export des products exportiert er meine NL plugins nicht mit(in der target platform sind sie definitiv mitdrin)
 
G

Gast2

Gast
ja aber wo sind die downloads???? Ich bin zu doof die zu finden...
 

Wildcard

Top Contributor
Natürlich ein eigenes jar. Willst du etwa tausende properties in die einzelnen Plugins packen?
 
G

Gast2

Gast
ja in den alten packs war es so, dass für jedes plugin ein eigenes nl plugin gab und nicht für ein plugin n nl plugin für sprachen...bei 5 plugin mit 20 sprachen sind das ja 100 plugins
 

Wildcard

Top Contributor
Nicht 100 PlugIns, sondern 100 Fragments. Ist doch aber wesentlich komfortabler als alles aus- und wieder einzupacken
 
G

Gast2

Gast
Sorry ich versteh ich jetzt nicht ganz... :p

1. Ich finde gar nichts auf der Babel Seite zum runterladen
Babel
Oder kannst du mir sagen wo ich die Fragemente runterladen kann???
2. Ich hab nur plugins auf der oben an genannten Seite gefunden(vielleicht war die auch falsch)...
Auf jeden Fall ist es dort so dass ich z.B. für das org.eclipse.ui.workbench ein org.eclipse.ui.workbench.nl_de,
org.eclipse.ui.workbench.nl_en,org.eclipse.ui.workbench.nl_fr usw. habe
d.h. für mich jedes plugin hat x nl plugins...
 
G

Gast2

Gast
ok aber trotzdem muss ich für jedes plugin x language fragemente einbinden ...
hätte es nicht eins getan wo alle darin enthalten sind???
 

Wildcard

Top Contributor
Und wenn du nicht alle haben willst? Ist doch völlig egal wie viele Fragmente das sind, was stört dich?
 
G

Gast2

Gast
Das ich die bis jetzt alle einzeln runter laden müsste...und im jnlp file auch jedes fragment hinzufügen müsste...
 

Wildcard

Top Contributor
Auf Babel kannst du das Ding doch komplett laden. Ein JNLP kannst du dir auch mit ANT/Maven bauen.
 
G

Gast2

Gast
Ok aber nochmal ne frage habe ich dazu...
Warum exportiert er mir die language fragemente erst mit aus, wenn ich die in meinem feature.xml expliziet hinzugefügt hab... Geht das auch anders?
 
G

Gast2

Gast
ja schon klar die frage war eher geht das auch eleganter als jedes fragement einzeln hinzuzufügen?

EDIT: Noch ne andere Frage ich hab jetzt die deutschen fragemente runtergeladen und in meiner target platform mit aufgenommen jetzt ist ber mein eclipse auch deutsch(voll häßlich :p), obwohl mein eclipse ja nichts mit meiner target platform zu tun hat... woher zieht eclipse denn die???
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
T Buckminster 3.6: Signierung von Babel-Packs Plattformprogrammierung 2

Ähnliche Java Themen

Neue Themen


Oben