Sprache bei TMsgDlgBtn ändern
-
- Lazarusforum e. V.
- Beiträge: 2809
- Registriert: Sa 9. Sep 2006, 18:05
- OS, Lazarus, FPC: Linux (L trunk FPC trunk)
- CPU-Target: 64Bit
- Wohnort: Dresden
- Kontaktdaten:
Sprache bei TMsgDlgBtn ändern
Ich hab gerade mal gesucht, aber bin nicht fündig geworden.
Wo wird denn die 'Caption' für diese Typen festgelegt?
Ziel ist, das in nem deutschen Programm auch Abbrechen, anstatt Abort steht.
Wo wird denn die 'Caption' für diese Typen festgelegt?
Ziel ist, das in nem deutschen Programm auch Abbrechen, anstatt Abort steht.
-
- Lazarusforum e. V.
- Beiträge: 2809
- Registriert: Sa 9. Sep 2006, 18:05
- OS, Lazarus, FPC: Linux (L trunk FPC trunk)
- CPU-Target: 64Bit
- Wohnort: Dresden
- Kontaktdaten:
Ich habs gerade nochmal probiert, und komme nicht zu deutschen Buttons.
Wenn ich über die Api die Systemsprache auslese, erscheint deutsch, wenn ich einen Testdialog anzeige, sind die Buttons in Englisch.
Resultat siehe Anhang.
Gibt es eine Möglichkeit, die Sprache per Laufzeit zu überschreiben?
P.S.: Hat irgendwer sonst die selben Probleme oder bin ich der einzige?
Wenn ich über die Api die Systemsprache auslese, erscheint deutsch, wenn ich einen Testdialog anzeige, sind die Buttons in Englisch.
Code: Alles auswählen
procedure TForm1.Button1Click(Sender: TObject);
function GetOSLanguage: string;
var
LanguageID:LangID;
Len: Integer;
begin
SetLength(Result, 255);
LanguageID:=GetSystemDefaultLangID;
Len:=VerLanguageName(LanguageID,PChar(Result), Length(Result));
SetLength(Result, Len);
end;
begin
ShowMessage(GetOSLanguage);
end;
procedure TForm1.Button2Click(Sender: TObject);
begin
MessageDlg('test', 'test', mtConfirmation, mbAbortRetryIgnore, 0);
end;
Gibt es eine Möglichkeit, die Sprache per Laufzeit zu überschreiben?
P.S.: Hat irgendwer sonst die selben Probleme oder bin ich der einzige?
http://www.lazarus.freepascal.org/index ... messagedlg" onclick="window.open(this.href);return false;
Siehe Code bei TranslateUnitResourceStrings
Siehe Code bei TranslateUnitResourceStrings
-
- Lazarusforum e. V.
- Beiträge: 2809
- Registriert: Sa 9. Sep 2006, 18:05
- OS, Lazarus, FPC: Linux (L trunk FPC trunk)
- CPU-Target: 64Bit
- Wohnort: Dresden
- Kontaktdaten:
Danke.
Funktioniert prima
falls jemand anderes es auch mal braucht, die Lösung in Kurzfassung:
Funktioniert prima

falls jemand anderes es auch mal braucht, die Lösung in Kurzfassung:
Code: Alles auswählen
uses translations
TranslateUnitResourceStrings('LCLStrConsts', '[LazarusDir]\lcl\languages\lclstrconsts.de.po');
//anschließend sind die Meldungen in deutsch
-
- Beiträge: 58
- Registriert: So 16. Mär 2008, 23:40
- OS, Lazarus, FPC: Debian Lenny (L 0.9.28-2 FPC 2.2.4)
- CPU-Target: 64Bit
- Wohnort: Brake/Unterweser
Die Pfadangabe bei mir stimmte schon. Ich werde das heute Abend mal mit dem Debugger genauer kontrollieren. Melde mich dann wieder.
Nachtrag: Mir geht es nicht um die aktuelle Sprache der IDE, sondern um die Programme, die später auf anderen Rechner laufen.
Danke
Halvar
Nachtrag: Mir geht es nicht um die aktuelle Sprache der IDE, sondern um die Programme, die später auf anderen Rechner laufen.
Danke
Halvar
Das Leben ist wie eine Hühnerleiter - kurz und beschissen
-
- Beiträge: 58
- Registriert: So 16. Mär 2008, 23:40
- OS, Lazarus, FPC: Debian Lenny (L 0.9.28-2 FPC 2.2.4)
- CPU-Target: 64Bit
- Wohnort: Brake/Unterweser
Zuerst einmal bekomme ich beim CompilierenLinken die Meldung, dass die Unit Translations nicht verwendet wird! und zweitens hat sich nichts geändert. Nach wie vor sind alle Meldungen in Englisch.
Ich bin relativ vom Programmpfad ausgegangen:
Ich bin relativ vom Programmpfad ausgegangen:
Code: Alles auswählen
TranslateUnitResourceStrings('LCLStrConsts', '.\languages\lclstrconsts.de.po');
-
- Beiträge: 65
- Registriert: Sa 27. Okt 2007, 13:27
- OS, Lazarus, FPC: Winux (L 0.9.xy FPC 2.2.z)
- CPU-Target: xxBit
- Wohnort: Seebergen
Na prima, dann ist ja gut.
Nur was khh
@khh: Hast Du eine bessere möglichkeit?
Tschüsss!
Nur was khh
benutzt hat kann ich nicht sagen. Denn wenn die Function TranslateUnitResourceStrings im FormCreate-Abschnit codiert ist wird auch definitiv erst zur Laufzeit die Sprache geändert. Also probiere dein Programm erst mal auf einem Rechner auf dem kein Lazarus installiert ist. Denn wenn die Sprache beim kompilieren geändert werden soll dann müsste das mit einem kompilerschalter oder sowas gemacht werden.ich glaub nicht, dass die Sprache erst zur Laufzeit geladen wird.
Bei mir funktioniert das einwandfrei, ohne dass die *po datei mitgegeben wird.
@khh: Hast Du eine bessere möglichkeit?
Tschüsss!
-
- Beiträge: 65
- Registriert: Sa 27. Okt 2007, 13:27
- OS, Lazarus, FPC: Winux (L 0.9.xy FPC 2.2.z)
- CPU-Target: xxBit
- Wohnort: Seebergen
Hallo nochmal!
Ähm... , wenn da jetzt nich noch was nach kommt, dann hab ich da doch noch was. Was wäre, wenn die LCL nicht englischsprachig sondern deutschsprachig ist? Wie an anderer Stelle schon mal angemerkt, habe ich mal probeweise die Datei lclstrconsts.pas übersetzt und die LCL neu compiliert. Als Ergebnis waren die Buttontexte, Dialogbeschriftungen, Fehlermeldungen, Nachrichten u.s.w auf deutsch. Das ist aber leider noch nicht alles und ausreichend, denn die Sache hat noch einige haken.
1. Es ist nicht Versionsübergreifend.
2. Leider geht dadurch die Function "TranslateUnitResourceStrings" nicht mehr.
3. Damit geht auch die Mehrsprachigkeit der LCL zur Laufzeit zum Teufel.
Wie am Beispiel der Datei lclstrconsts.de.po zu sehen ist, ist der msgid - String englisch und der zugehörige auszutauschende msgstr - String ist deutsch. Jetzt kann aber zur Laufzeit keine Übereinstimmung mehr gefunden werden weil ja die kompilierten LCL-Strings deutsch sind.
4.Das würde aber nun bedeuten das alle lclstrconsts.xx.po Dateien auch noch umgewandelt werden müssen und noch eine lclstrconsts.en.po Datei erzeugt werden muss wegen der englischen Übersetzung zur Laufzeit.
Na, gut. An die Arbeit und ... , nein nicht den ganzen krempel selbst umwandeln. Sondern ein Tool bauen das die Arbeit macht. Naja, das ist halt wieder so eine Idee die fast keiner braucht. Aber trozdem, es ja doch der eine oder andere mal danach gefragt.
Ich habe mir gedacht, ich benutze die lclstrconsts.de.po als basis für die Umwandlungen.
1. Zuerst wird auf dieser Basis die lclstrconsts.pas neu erzeugt. Alle in der lclstrconsts.de.po gefundenen Resourcenstrings werden in der lclstrconsts.pas durch den zugehörigen deutschen String ersetzt.
2. Als nächstes wird eine englische .po Datei (lclstrconsts.en.po) erzeugt. Hier werden einfach nur die vorhandenen msgid-Strings mit den vorhandenen msgstr-Strings vertauscht.
3. Zulezt können dann in allen vorhandenen xxx.xx.po Dateien die englischen msgid-Strings durch die deutschen msgid-Strings ersezt werden. Damit währe dann auch das funktionieren der Function TranslateUnitResourceStrings wieder gewährleistet und die LCL ist wieder Multilingual.
Jetzt noch die original lclstrconsts.pas umbenennen und die neue Datei in's LCL-Verzeichnis kopieren. Danach das original Language-Verzeichnis umbenennen und das neue in's LCL-Verzeichnis kopieren. Zum Schluss nur noch die LCL neu kompilieren und fertig. Jetzt müsste die LCL auf deutsch als Basissprache umgestellt sein. Sicher liegt es nicht im sinne der Entwickler das sich beliebige Sprachlinien der LCL bilden und damit ein Fehlermeldungschaos anrichten könnten. Es ist deshalb sehr wichtig, das auch den entsprechenden Konstanten die zugehörigen String's zugewiesen werden und nicht irgendwie vertauscht und verwechselt werden.
Das soll jetzt keine Anlaufstelle für deutsche LCL-Sprachpakete aller Lazarusversionen werden. Ich schreibe das auch nur als Alternative zu TranslateUnitResourceStrings weil mehrfach nach anderen wegen gefragt wurde. Aber wenn jemand ernsthaft möchte, dann kann ich das fertige Tool natürlich zur freien Verfügung hier anhängen, zum ausprobieren und testen. Es kann sich dann jeder sein eigenes Sprachpaket bauen und benutzen, wenn er denn möchte.
So, jetzt will ich das Tool mal weitermachen. Es soll mal LCL-Translator heisen. Oder es sagt jetzt noch jemand wo der Haken gemacht wird, dann war's das. Ach ja, da war doch noch was. Darf ich das überhaupt? Wird das von GPL, LGPL und modifiedLGPL erlaubt? Naja, das Tool schon. Aber das was es macht?
Ach ja, die GUI ist fertig. Ich häng mal nen Screeshoot an um zu zeigen wie ich das gedacht habe.
Tschüssss!
Ähm... , wenn da jetzt nich noch was nach kommt, dann hab ich da doch noch was. Was wäre, wenn die LCL nicht englischsprachig sondern deutschsprachig ist? Wie an anderer Stelle schon mal angemerkt, habe ich mal probeweise die Datei lclstrconsts.pas übersetzt und die LCL neu compiliert. Als Ergebnis waren die Buttontexte, Dialogbeschriftungen, Fehlermeldungen, Nachrichten u.s.w auf deutsch. Das ist aber leider noch nicht alles und ausreichend, denn die Sache hat noch einige haken.
1. Es ist nicht Versionsübergreifend.
2. Leider geht dadurch die Function "TranslateUnitResourceStrings" nicht mehr.
3. Damit geht auch die Mehrsprachigkeit der LCL zur Laufzeit zum Teufel.

4.Das würde aber nun bedeuten das alle lclstrconsts.xx.po Dateien auch noch umgewandelt werden müssen und noch eine lclstrconsts.en.po Datei erzeugt werden muss wegen der englischen Übersetzung zur Laufzeit.

Na, gut. An die Arbeit und ... , nein nicht den ganzen krempel selbst umwandeln. Sondern ein Tool bauen das die Arbeit macht. Naja, das ist halt wieder so eine Idee die fast keiner braucht. Aber trozdem, es ja doch der eine oder andere mal danach gefragt.
Ich habe mir gedacht, ich benutze die lclstrconsts.de.po als basis für die Umwandlungen.
1. Zuerst wird auf dieser Basis die lclstrconsts.pas neu erzeugt. Alle in der lclstrconsts.de.po gefundenen Resourcenstrings werden in der lclstrconsts.pas durch den zugehörigen deutschen String ersetzt.
2. Als nächstes wird eine englische .po Datei (lclstrconsts.en.po) erzeugt. Hier werden einfach nur die vorhandenen msgid-Strings mit den vorhandenen msgstr-Strings vertauscht.
3. Zulezt können dann in allen vorhandenen xxx.xx.po Dateien die englischen msgid-Strings durch die deutschen msgid-Strings ersezt werden. Damit währe dann auch das funktionieren der Function TranslateUnitResourceStrings wieder gewährleistet und die LCL ist wieder Multilingual.
Jetzt noch die original lclstrconsts.pas umbenennen und die neue Datei in's LCL-Verzeichnis kopieren. Danach das original Language-Verzeichnis umbenennen und das neue in's LCL-Verzeichnis kopieren. Zum Schluss nur noch die LCL neu kompilieren und fertig. Jetzt müsste die LCL auf deutsch als Basissprache umgestellt sein. Sicher liegt es nicht im sinne der Entwickler das sich beliebige Sprachlinien der LCL bilden und damit ein Fehlermeldungschaos anrichten könnten. Es ist deshalb sehr wichtig, das auch den entsprechenden Konstanten die zugehörigen String's zugewiesen werden und nicht irgendwie vertauscht und verwechselt werden.
Das soll jetzt keine Anlaufstelle für deutsche LCL-Sprachpakete aller Lazarusversionen werden. Ich schreibe das auch nur als Alternative zu TranslateUnitResourceStrings weil mehrfach nach anderen wegen gefragt wurde. Aber wenn jemand ernsthaft möchte, dann kann ich das fertige Tool natürlich zur freien Verfügung hier anhängen, zum ausprobieren und testen. Es kann sich dann jeder sein eigenes Sprachpaket bauen und benutzen, wenn er denn möchte.
So, jetzt will ich das Tool mal weitermachen. Es soll mal LCL-Translator heisen. Oder es sagt jetzt noch jemand wo der Haken gemacht wird, dann war's das. Ach ja, da war doch noch was. Darf ich das überhaupt? Wird das von GPL, LGPL und modifiedLGPL erlaubt? Naja, das Tool schon. Aber das was es macht?
Ach ja, die GUI ist fertig. Ich häng mal nen Screeshoot an um zu zeigen wie ich das gedacht habe.
Tschüssss!