RCP language packs

[SirWayne]

Hallo

welche language pack brauche ich für die nativen Dialoge bei einer RCP anwendung unter 3.2.2??



archive.eclipse.org/eclipse/downloads/drops/L-3.2_Language_Packs-200607121700/index.php

ich hab die RCP Runtime Binary Language Packs runtergeladen aber sind ja 20 neue plugins die ich da einfügen müsste??? Stimmt das???

[foobar]

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.

[SirWayne]

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]

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

[SirWayne]

also der einzigste weg dass zu machen ist das .ini file zu ändern...

www.toedter.com/blog/?p=19

hier kann man sich ein bsp runterladen...
max-server.myftp.org/trac/mp3m

[foobar]

Wäre schön wenn man das zur Laufzeit ohne Neustart der Workbench machen könnte

[SirWayne]

ja das wäre auch gut für mich :P...
mit dem ini file musst du halt immer erst deployen...

aber vielleicht gehts ja bald in der nächsten eclipse version

https://bugs.eclipse.org/bugs/show_bug.cgi?id=222023

[foobar]

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

[SirWayne]

ja das stimmt , ich versuch grad noch die Locale zu beeinflussen
bevor die Workbench gestartet wird

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

[SirWayne]

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??

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

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

[Wildcard]

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.

[SirWayne]

Soviel ich weiß stimmt des aber nicht...
Nehmen wir zum Beispiel WorkbenchMessages

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....

[foobar]

Welchen NLS-Mechanismus verwendest du denn?

http://help.eclipse.org/help32/index...ze-strings.htm

Ich bin bisher immer den traditionellen Weg ohne zusätzliche Klasse gegangen.

[Wildcard]

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.

[SirWayne]

Zitat:

	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]

Zitat: Wildcard

	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?

[SirWayne]

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...

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]

Zitat: foobar

	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]

Zitat: Wildcard

	Zitat: foobar 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]

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?