GUI-Sprache dynamisch ändern
GUI-Sprache dynamisch ändern
ich möchte die Sprache des Benutzer-Schn. dynamisch ändern. ich habe entsprechende .qm Dateien fertig, lade sie über menü und installiere die jeweiligen Translatoren. Soweit kein problem, aber dadruch dass die Oberfläche zu diesem Zeitpunkt schon erstellt und angezeigt wurde, passiert nix weiter. Die Frage: Wie kann man ein Update der gesamten Oberfläche erzwingen, so dass Menüeinträge usw. neu übersetzt werden?
Was genau meinst damit?lepsai hat geschrieben:Doch noch ein kleines Problem. Aus irgend einem Grund werden QActionGroup's nicht übersetzt. Dann sieht es so aus:
hat jemand eine Idee ?
QActionGroups werden nicht uebersetzt?
Du willst also die Oberflaeche zur Laufzeit umschalten, ja?
Wie machst das grundsaetzlich?
Funktioniert nur die Umschaltung der QActionGroups zur Laufzeit nicht, oder werden die auch nicht richtig gesetzt, wenn du gleich in einer anderen Sprache startest?
...bzw. vielleicht hab ichs auch ganz falsch verstanden. Werden Uebersetzungen nicht angezeigt, oder wird nicht uebersetzt -> also die Uebersetzung fehlt im entsprechenden *.qm File.
Goos
Das Ziel:
Die Sprache der Oberfläche lässt sich zur Laufzeit umschalten.
Realisierung:
Nach Qt-Konzept müssen alle übersetzbaren Widgets die Funktion languageChange() überladen. Diese wird jedesmal, wenn ein Translator instaliert wird, von Qt aufgerufen. Also werden zur Laufzeit verschiedene Translatoren installiert und so die Oberfläche in einer neuen Sprache aktualisiert. So weit so gut. Hat auch prima funktioniert.
Was nicht geht ist die Übersetzung von Dropdown-QActionGroup's, weil diese, wie ich heute herausgefunden habe, NICHT in languageChange() auftauchen. Da dieser Teil des Codes aber durch Qt Designer generiert wurde, muss ich über Umwege das Ganze nachimplementieren, also praktisch eine zweite Version von languageChange() schreiben, die dann die Übersetzung von diesen QActionGroup's extra behandelt...
Die Sprache der Oberfläche lässt sich zur Laufzeit umschalten.
Realisierung:
Nach Qt-Konzept müssen alle übersetzbaren Widgets die Funktion languageChange() überladen. Diese wird jedesmal, wenn ein Translator instaliert wird, von Qt aufgerufen. Also werden zur Laufzeit verschiedene Translatoren installiert und so die Oberfläche in einer neuen Sprache aktualisiert. So weit so gut. Hat auch prima funktioniert.
Was nicht geht ist die Übersetzung von Dropdown-QActionGroup's, weil diese, wie ich heute herausgefunden habe, NICHT in languageChange() auftauchen. Da dieser Teil des Codes aber durch Qt Designer generiert wurde, muss ich über Umwege das Ganze nachimplementieren, also praktisch eine zweite Version von languageChange() schreiben, die dann die Übersetzung von diesen QActionGroup's extra behandelt...
Ist mal wieder ein klarer Punkt gegen die Designer Benutzung.lepsai hat geschrieben:Da dieser Teil des Codes aber durch Qt Designer generiert wurde, muss ich über Umwege das Ganze nachimplementieren, also praktisch eine zweite Version von languageChange() schreiben, die dann die Übersetzung von diesen QActionGroup's extra behandelt...
Wenn man den nicht benutzt und es gleich alles selbst macht, dann kommts auch nicht zu solchen Fehlern
Goos, der noch nie Probleme mit Fremdprachigkeit hatte
Ok, ich hab' jetzt herausgefunden, dass dieses Problem wohl an einer älteren Version von Designer lag. Wenn ich jetzt mit der aktuellen Version die QActionGroups anlege, gibt es auch keine Probleme bei der Übersetzung. Grundsätzlich sehe ich das mit dem Designer anders. In meinem Projekt gibt etwa 10.000 Zeilen Code, die vom Designer generiert wurden.Ich hätte da nicht unbedingt Lust, die von Hand zu schreiben. Wichtiger ist es aber, diesen generierten Code auch zu verstehen. Daher ist es für einen Anfänger wahrscheinlich besser, alles von Hand zu schreiben, aber in einer proffesionellen Umgebung ist eine gewisse Automatisierung von Vorgängen einfach nicht wegzudenken.
Ich will mich auch gar nicht mit dir darueber streitenlepsai hat geschrieben: Grundsätzlich sehe ich das mit dem Designer anders. In meinem Projekt gibt etwa 10.000 Zeilen Code, die vom Designer generiert wurden.Ich hätte da nicht unbedingt Lust, die von Hand zu schreiben. Wichtiger ist es aber, diesen generierten Code auch zu verstehen.
Ich mag nur keine umstaendlichen Implementierungen, die man noch neben dem Designercode einbauen muss und weiterhin auch Fehlersuche aufgrund von Tools, die fehlerbehaftet sind, womit ich in diesem Fall den Designer meine. (Was aber auch ganz normal ist, denn jedes Tool hat Bugs)
Wenn ich also alles von Hand mache, so kann ich mir wenigstens nur vorwerfen selbst Fehler gemacht zu haben
So allgemein gehalten hast du Recht.lepsai hat geschrieben: Daher ist es für einen Anfänger wahrscheinlich besser, alles von Hand zu schreiben, aber in einer proffesionellen Umgebung ist eine gewisse Automatisierung von Vorgängen einfach nicht wegzudenken.
Auf den Designer bezogen ist das aber nur deine Meinung und die kann ich leider nicht teilen. Das kann allerdings auch an Sachen wie Gewohnheit und der Art von Projekten liegen die man bearbeitet.
Goos
Der Designer macht aus 3000 Zeilen Code einen 8000 Zeilen Code... Also wärst per Hand wohl doch besser dran gewesen 
Naja, habs schonmal gesagt: Geschmackssache. Mir hat der Designer auch für ein, zwei Projekte gefallen. Aber dann hab ich gemerkt das man ohne einfach viel mehr Freiheiten hat....
Naja, habs schonmal gesagt: Geschmackssache. Mir hat der Designer auch für ein, zwei Projekte gefallen. Aber dann hab ich gemerkt das man ohne einfach viel mehr Freiheiten hat....
>>[-]>[-]>[-]>[-]<<<<<[->>+<-[>>>]>[[<+>-]>+>>]<<<<<]