Hilfe beim Test eines GnuGetText Patches

[dummzeuch]

Hi,

ich habe einen Patch für gnugettext.pas bekommen, der folgendes Problem lösen soll:

Wenn ein Programm mit einer deutschsprachigen IDE compiliert wird, werden Shortcut-Tasten z.B. "Ctrl+C" auf Deutsch eingebunden ("Strg+C") und bei der Übersetzung nicht korrekt berücksichtigt.

Der Patch funktioniert wohl mit aktuellen Delphi Versionen (10.x), aber da gnugettext rückwärtskompatibel bis zu Delphi 6 sein soll, musste ich einige Änderungen vornehmen, damit er kompiliert.

Jetzt habe ich das Problem, dass ich die IDE immer nur auf Englisch installiere und deshalb gar nicht testen kann, ob der Patch funktioniert.

Also: Ich bräuchte für diverse ältere Delphi-Versionen (mindestens Delphi 6, 2007, 2009, 2010, XE und XE2) jemanden, der diese Tests für mich durchführen kann. Idealerweise jemand, der sowieso gnugettext verwendet und einfach eines seiner existierenden Programme mit der geänderten Unit compileren kann.

Die erweiterte gnugettext.pas Unit habe ich angehängt.

Der Patch ist aktiv, wenn man im Sourcecode den Define dx_German_Delphi_fix setzt:

Delphi-Quellcode:

// Programs that are compiled with German Delphi will always show the German shortcut
// keys in menus and hints because the German RTL resourcestrings are not translated.
// This results in German menu shortcuts 'Strg+<X>', 'Umsch+<X>' to be shown instead of
// 'Ctrl+<X>', 'Shift+<X>', even if the applications language is not German.
//
// This function hooks into Vcl.Menus.ShortCutToText and replaces the German consts with
// their English counterparts if the current application language is *not* German.
// Tested with Rad Studio 10.2 Tokyo and 10.3.1 Rio
{$define dx_German_Delphi_fix}

Und ensprechend ausgeschaltet, wenn man ihn nicht setzt:

Delphi-Quellcode:

{.$define dx_German_Delphi_fix}

Bitte beides testen und vergleichen, ohne, sollten die Shortcuts falsch sein, mit korrekt.

[dummzeuch]

Keine Antwort bisher.

Heisst das, niemand benutzt mehr gnugettext? Oder niemand benutzt mehr alte Delphi-Versionen? Oder will keiner die paar Minuten in eine Open Source Unit investieren?

Wenn das so ist, brauche ich mir ja zukünftig keine Sorgen mehr um deutsche User von älteren Delphi-Versionen machen und kann mich auf das konzentrieren, was ich selbst brauche. Dann würde ich einfach den neuen Sourcecode einchecken, denn er betrifft mich nicht, und nach mir die Sintflut.

[Der schöne Günther]

Das ist aber auch eine ganz schöne Erwartungshaltung dass sich innerhalb von weniger als 24 Stunden die Leute alle gleich draufstürzen.

Um aber ganz schonungslos ehrlich zu sein: Mein ganz persönliches Interesse an Rückwärtskompatibilität zu Delphi-Versionen aus meiner Grundschulzeit ist wirklich sehr gering, auch für so großartige Sachen wie dxGetText

[Uwe Raabe]

Zitat:

Zitat von dummzeuch (Beitrag 1429866)

Heisst das, niemand benutzt mehr gnugettext? Oder niemand benutzt mehr alte Delphi-Versionen? Oder will keiner die paar Minuten in eine Open Source Unit investieren?

Die Bedingung wäre dann ja <benutzt gnugettext> AND <benutzt alte Delphi-Versionen> AND <will ein paar Minuten in eine Open Source Unit investieren>. Da kann die Schnittmenge schon mal recht klein ausfallen. Deine drei OR-Folgerungen lassen sich daraus aber nicht direkt ableiten (können allerdings trotzdem zutreffen).

Ich habe aber auch den Eindruck, daß tatsächlich seit Erscheinen von Delphi 10.2 Tokyo der Anteil der alten Delphi-Versionen schlagartig abgenommen hat.

Seitdem MMX nur noch Delphi 10 Seattle und aufwärts unterstützt, ist die aktuell älteste Delphi Version bei einem Kunden-Projekt XE2 und die wird diesen Monat noch durch Tokyo ersetzt. Damit ist z.B. für mich alles unter Seattle mehr oder weniger Geschichte. Die Versionen sind zwar noch auf dem Build-Server installiert, fallen aber nur noch unangenehm auf, wenn sie beim Compilieren eines meiner Plugins mal wieder ein Sprachfeature nicht unterstützen. Da kommt dann immer wieder der Gedanke, den Support für diese Versionen einfach einzustellen.

Übrigens, bei mir schlägt die obige Bedingung schon im ersten Teil fehl.

[Bbommel]

Ich benutze gnugettext noch sehr aktiv (siehe meine Mail neulich in der Mailingliste wegen Problemen mit Linux), allerdings nur mit aktuellen Delphi-Versionen (10.2.3 und 10.3.1). Ich habe hier noch ein Delphi 2009 mit deutscher IDE installiert, allerdings nur für ein Alt-Projekt, in dem ich kein gnugettext benutzt habe.

Wenn es hilft, kann ich aber später darin gerne mal ein Mini-Projekt zum Testen deines Patches erstellen.

[dummzeuch]

Zitat:

Zitat von Bbommel (Beitrag 1429877)

Ich benutze gnugettext noch sehr aktiv (siehe meine Mail neulich in der Mailingliste wegen Problemen mit Linux), allerdings nur mit aktuellen Delphi-Versionen (10.2.3 und 10.3.1). Ich habe hier noch ein Delphi 2009 mit deutscher IDE installiert, allerdings nur für ein Alt-Projekt, in dem ich kein gnugettext benutzt habe.

Wenn es hilft, kann ich aber später darin gerne mal ein Mini-Projekt zum Testen deines Patches erstellen.

Ich nehme jede Hilfe, die ich kriegen kann.

[Bbommel]

Funktioniert prinzipiell unter Delphi 2009.

Ein Problem, das aber wahrscheinlich nichts mit der Delphi-Version zu tun hat, ist mir aber noch aufgefallen. Auf der Seite von Lars gab es früher für verschiedene Sprachen eine system.po herunterzuladen, welche dafür gesorgt hat, diverse Meldungen, die aus den Tiefen der RTL/VCL kommen, auf Englisch auszugeben. Wenn ich die mit einbinde, dann funktioniert der Patch nicht mehr:

Delphi-Quellcode:

procedure TForm2.FormCreate(Sender: TObject);
begin
  AddDomainForResourceString('system');
  UseLanguage('en');
  TranslateComponent(Self);
end;

Ohne die Zeile "AddDomainForResourceString" klappt alles, wie von dir beschrieben, und ein Strg+O wird zu einem Crtl+O in der gepatchten Variante. Mit dieser ersten Zeile aber ist der Patch wirkungslos.

[v2afrank]

Moment. Bei mir stimmt die Schnittmenge. Ich benutze aktiv Delphi 6 mit Gnugettext.

Ich werde es mal testen und mich zurückmelden


Ich habe jetzt noch einmal durchgelesen was Du wolltest und
UseLanguage('en');
TranslateComponent(Self);

durchgeführt. Ich sehe keinen Unterschied ob dx_German_Delphi_fix gesetzt ist oder nicht.
Es ist in beiden Versionen richtig

[luebbe]

Zitat:

Zitat von v2afrank (Beitrag 1429939)

Ich habe jetzt noch einmal durchgelesen was Du wolltest und
UseLanguage('en');
TranslateComponent(Self);

durchgeführt. Ich sehe keinen Unterschied ob dx_German_Delphi_fix gesetzt ist oder nicht.
Es ist in beiden Versionen richtig

Hallo, da der ursprüngliche Patch von mir stammt, ich aber ebenfalls nichts vor Toyko zum Testen habe, folgende Info:

Wichtig ist, dass mit einer deutschen IDE übersetzt wird, damit die deutschen Hotkeys verwendet werden.

ohne {$define dx_German_Delphi_fix}:
UseLanguage('en') -> Die Hotkeys in Menüs oder Hints werden als 'Strg/Umsch/Alt' angezeigt.
UseLanguage('de') -> Die Hotkeys in Menüs oder Hints werden als 'Strg/Umsch/Alt' angezeigt.

mit {$define dx_German_Delphi_fix}:
UseLanguage('en') -> Die Hotkeys in Menüs oder Hints müssen als 'Ctrl/Shift/Alt' angezeigt werden.
UseLanguage('de') -> Die Hotkeys in Menüs oder Hints müssen als 'Strg/Umsch/Alt' angezeigt werden.

Wenn dem so ist, wäre alles in Ordnung.

Es werden auch andere Tasten übersetzt, aber das sind die auffälligsten.

[dummzeuch]

Zitat:

Zitat von Bbommel (Beitrag 1429926)

Funktioniert prinzipiell unter Delphi 2009.

Ein Problem, das aber wahrscheinlich nichts mit der Delphi-Version zu tun hat, ist mir aber noch aufgefallen. Auf der Seite von Lars gab es früher für verschiedene Sprachen eine system.po herunterzuladen, welche dafür gesorgt hat, diverse Meldungen, die aus den Tiefen der RTL/VCL kommen, auf Englisch auszugeben.

Die kenne ich gar nicht. Ich kenne nur die DelphiXxxx.po-Dateien, um die Systemmeldungen in die jeweilige Zielsprache zu übersetzen (und die gibt es nur bis Delphi2011 aka XE).

Zitat:

Zitat von Bbommel (Beitrag 1429926)

Wenn ich die mit einbinde, dann funktioniert der Patch nicht mehr:

Delphi-Quellcode:

procedure TForm2.FormCreate(Sender: TObject);
begin
  AddDomainForResourceString('system');
  UseLanguage('en');
  TranslateComponent(Self);
end;

Ohne die Zeile "AddDomainForResourceString" klappt alles, wie von dir beschrieben, und ein Strg+O wird zu einem Crtl+O in der gepatchten Variante. Mit dieser ersten Zeile aber ist der Patch wirkungslos.

D.h. dann wird "Strg+O" nicht mehr umgesetzt sondern bleibt "Strg+O"?

Kannst Du mir diese system.po bitte mal zukommen lassen?

[v2afrank]

Zitat:

Zitat von luebbe (Beitrag 1429996)

Zitat:

Zitat von v2afrank (Beitrag 1429939)

Ich habe jetzt noch einmal durchgelesen was Du wolltest und
UseLanguage('en');
TranslateComponent(Self);

durchgeführt. Ich sehe keinen Unterschied ob dx_German_Delphi_fix gesetzt ist oder nicht.
Es ist in beiden Versionen richtig

Hallo, da der ursprüngliche Patch von mir stammt, ich aber ebenfalls nichts vor Toyko zum Testen habe, folgende Info:

Wichtig ist, dass mit einer deutschen IDE übersetzt wird, damit die deutschen Hotkeys verwendet werden.

ohne {$define dx_German_Delphi_fix}:
UseLanguage('en') -> Die Hotkeys in Menüs oder Hints werden als 'Strg/Umsch/Alt' angezeigt.
UseLanguage('de') -> Die Hotkeys in Menüs oder Hints werden als 'Strg/Umsch/Alt' angezeigt.

mit {$define dx_German_Delphi_fix}:
UseLanguage('en') -> Die Hotkeys in Menüs oder Hints müssen als 'Ctrl/Shift/Alt' angezeigt werden.
UseLanguage('de') -> Die Hotkeys in Menüs oder Hints müssen als 'Strg/Umsch/Alt' angezeigt werden.

Wenn dem so ist, wäre alles in Ordnung.

Es werden auch andere Tasten übersetzt, aber das sind die auffälligsten.

Kann ich leider so nicht bestätigen. Auch ohne dass define wird alles richtig übersetzt.
Siehe Screenshot

[hoika]

Hallo,
ich benutze es nicht, aber

Zitat:

Dann würde ich einfach den neuen Sourcecode einchecken, denn er betrifft mich nicht, und nach mir die Sintflut.

Tolle Haltung.
schon mal was von $IFDEF gehört?
Wenn Du nur einen Compiler zum Testen hast, warum schreibst du dann Code für alle anderen?

[haentschman]

Moin...:P

Zitat:

wird alles richtig übersetzt

..sehe ich nicht so. :wink:

In beiden Screeshots steht im Menü "Datei". In der englischen Variante hätte ich "File" erwartet. :zwinker:

[Bbommel]

Zitat:

Zitat von dummzeuch (Beitrag 1430010)

Kannst Du mir diese system.po bitte mal zukommen lassen?

Ist per E-Mail an dich raus.

Zitat:

Zitat von hoika (Beitrag 1430035)

Zitat:

Dann würde ich einfach den neuen Sourcecode einchecken, denn er betrifft mich nicht, und nach mir die Sintflut.

Tolle Haltung.
schon mal was von $IFDEF gehört?
Wenn Du nur einen Compiler zum Testen hast, warum schreibst du dann Code für alle anderen?

Da muss ich doch mal kurz was zu schreiben: ich glaube nicht, dass man Thomas eine mangelnde Haltung vorwerfen kann - er ist derjenige, der die gnugettext.pas im Repository bis heute aktuell hält und an neue Delphi-Versionen anpasst und versucht, auch ältere Fehler darin zu korrigieren, wenn sie einem in der Community (diskutiert dann meistens über die dxgettext-Mailingliste) auffallen. Ich finde das aller Ehren wert.

Und was die IFDEFs angeht: das ist ja das "Problem" - die gnugettext.pas ist bis zum Rand voll mit IFDEFs, um eine sehr weitgehende Kompatibilität bis runter zu D6 zu gewährleisten. Da muss man bei Änderungen schon sehr aufpassen und braucht halt die Unterstützung beim Testen.

Zitat:

Zitat von haentschman (Beitrag 1430036)

Zitat:

wird alles richtig übersetzt

..sehe ich nicht so. :wink:
In beiden Screeshots steht im Menü "Datei". In der englischen Variante hätte ich "File" erwartet. :zwinker:

Jo, der Bug war aber schon "immer" da und kam jetzt nicht durch den Patch. :-)

[dummzeuch]

Zitat:

Zitat von hoika (Beitrag 1430035)

ich benutze es nicht, aber

... du musst trotzdem Deinen Senf dazugeben.

Zitat:

Zitat von hoika (Beitrag 1430035)

Zitat:

Dann würde ich einfach den neuen Sourcecode einchecken, denn er betrifft mich nicht, und nach mir die Sintflut.

Tolle Haltung.

Freut mich, dass sie Dir gefällt.

Zitat:

Zitat von hoika (Beitrag 1430035)

schon mal was von $IFDEF gehört?

Ja, ich mache das nicht erst seit gestern.

Zitat:

Zitat von hoika (Beitrag 1430035)

Wenn Du nur einen Compiler zum Testen hast, warum schreibst du dann Code für alle anderen?

Weil ich im Moment der einzige bin, der
1. Noch Interesse an dem Projekt hat (Lars hat anscheinend keines mehr).
2. Schreibzugriff auf das dxgettext Repository hat.
3. Alle unterstützten Compiler hat (nur eben nicht die jeweils deutsche Version)
4. Ich, anscheinend im Gegensatz zu Dir, verstehe, wovon die Rede ist.

Danke für die Durchsage.

[luebbe]

Zitat:

Zitat von v2afrank (Beitrag 1430034)

Kann ich leider so nicht bestätigen. Auch ohne dass define wird alles richtig übersetzt.
Siehe Screenshot

Achtung, in gnugettext ist auch ein {$define dx_German_Delphi_fix}. Nicht, dass der bei dir immer aktiv war und dein {$define dx_German_Delphi_fix} oder {$.define dx_German_Delphi_fix} im Hauptformular unwirksam ist.

[old7]

Lieber Thomas Mueller/dummzeuch,

ich programmiere hier (aktuell W10 1809 v17763.437) mit D7personal seit vielen Jahren (seit XP), mit der dt. Version von D7pe.

Und würde Dir auch gerne helfen. Aber wie?

Eine/Meine Bitte an Dich:
Werd' bitte bitte bitte nicht zum frustrierten A.loch (wie z.B. "*** piep ***"), weil keiner ihn "mag".

Klar, habe auf meiner SSD auch Delphi 10.2 Version 25.0.31059.3231.

Mein nächstes Update/Upgrade von Delphi wird aber auf Linux/Antergos KDE/FPC/Laazarus hinauslaufen.

Halt weil ich die vielen Fragen zum Umstieg von "Delphi_irgendeineversion" auf "Delphi_irgendeineversion"+1 hier maßgeblich - für mich - halte.

Für den uralten "Borland-Kram" habe ich (damals) nächtelang durchgemacht.

Früher (TM) war eben ALLES besser :-)

Sorry,
old7

[luebbe]

Zitat:

Zitat von dummzeuch (Beitrag 1430041)

Weil ich im Moment der einzige bin, der
1. Noch Interesse an dem Projekt hat (Lars hat anscheinend keines mehr).

Einspruch Euer Ehren!!

[v2afrank]

Achtung, in gnugettext ist auch ein {$define dx_German_Delphi_fix}. Nicht, dass der bei dir immer aktiv war und dein {$define dx_German_Delphi_fix} oder {$.define dx_German_Delphi_fix} im Hauptformular unwirksam ist.[/QUOTE]


Treffer versenkt.
Ich kann Vollzug melden. Ohne dass define steht da STRG mit Ctrl

[luebbe]

Zitat:

Zitat von v2afrank (Beitrag 1430106)

Zitat:

Achtung, in gnugettext ist auch ein {$define dx_German_Delphi_fix}. Nicht, dass der bei dir immer aktiv war und dein {$define dx_German_Delphi_fix} oder {$.define dx_German_Delphi_fix} im Hauptformular unwirksam ist.

Treffer versenkt.
Ich kann Vollzug melden. Ohne dass define steht da STRG mit Ctrl

Danke :thumbsup:

[dummzeuch]

Zitat:

Zitat von v2afrank (Beitrag 1430106)

Zitat:

Achtung, in gnugettext ist auch ein {$define dx_German_Delphi_fix}. Nicht, dass der bei dir immer aktiv war und dein {$define dx_German_Delphi_fix} oder {$.define dx_German_Delphi_fix} im Hauptformular unwirksam ist.

Treffer versenkt.
Ich kann Vollzug melden. Ohne dass define steht da STRG mit Ctrl

Danke, aber irgendwie habe ich überlesen (oder Du hast es nicht geschrieben), mit welcher Delphi-Version Du getestet hast. Ist es XE2 wie es in Deinem Profil steht?

Edit: Ich bin ein blinder Fisch! Delphi 6 war's. Also genau die Version, die am dringendsten getestet werden musste, weil der Code von mir angepasst wurde (Lübbe's code benutzte TStringBuilder). Danke nochmal!

twm

[dummzeuch]

Zitat:

Zitat von Bbommel (Beitrag 1430038)

Zitat:

Zitat von dummzeuch (Beitrag 1430010)

Kannst Du mir diese system.po bitte mal zukommen lassen?

Ist per E-Mail an dich raus.

Danke, ist angekommen. Das scheint eine umgedrehte deutsche Delphi7.po zu sein, wo MSGID und MSGSTR vertauscht wurden.

Aber nochmal zum eigentlichen Problem:

Habe ich das richtig verstanden: Wenn Du diese Datei mit AddDomainForResourceString('system'); einbindest, werden die Shortcuts trotz Patch mit "Strg+ ..." etc. ausgegeben? Sind noch andere mo-Dateien eingebunden?

Meine Vermutung ist, dass der Patch "Strg+" nach "Ctrl+" konvertiert, und es dann dafür keine Übersetzung gibt. Könntest Du bitte testen, ob eine zusätzliche Pseudo-Übersetzung
"Ctrl+" -> "Ctrl+" das Problem behebt? Oder, wenn das nicht funktioniert "Ctrl+" -> "Control+" (damit die Übersetzung <> dem Original ist).

twm

[dummzeuch]

Zitat:

Zitat von old7 (Beitrag 1430046)

ich programmiere hier (aktuell W10 1809 v17763.437) mit D7personal seit vielen Jahren (seit XP), mit der dt. Version von D7pe.

Und würde Dir auch gerne helfen. Aber wie?

Wenn Du bisher kein gnugettext einsetzt, ist das aufwändig zu erklären.

Danke für das Angebot, aber der erfolgreiche Test von v2afrank mit Delphi 6DE reicht mir schon. Da brauche ich kein Delphi 7 mehr, weil sich diese beiden Versionen kaum unterscheiden. Compilefehler hatte ich schon durch meine englische Version ausgschlossen.

Interessant wären noch Delphi 2005 bis XE. Bei neueren Versionen erwarte ich keine Probleme mehr.

twm

[Bbommel]

Zitat:

Zitat von dummzeuch (Beitrag 1430212)

Meine Vermutung ist, dass der Patch "Strg+" nach "Ctrl+" konvertiert, und es dann dafür keine Übersetzung gibt. Könntest Du bitte testen, ob eine zusätzliche Pseudo-Übersetzung
"Ctrl+" -> "Ctrl+" das Problem behebt? Oder, wenn das nicht funktioniert "Ctrl+" -> "Control+" (damit die Übersetzung <> dem Original ist).

Also, noch mal zur Sicherheit ganz ausführlich:

Deutsches Delphi 2009, das heißt mit deutschsprachiger IDE. Darin habe ich ein neues Projekt erstelt mit einem Hauptmenü mit zwei Menüpunkten, diese auch auf deutsch beschriftet. Dann habe ich für das Projekt eine normale default.po/mo erstellt mit Deutsch->Englisch-Übersetzungen. Im Ordner locale\en\LC_MESSAGES gibt es also die besagte system.mo und die projektspezfische default.mo.

Der einzige echte Code im Projekt ist das erwähnte:

Delphi-Quellcode:

procedure TForm2.FormCreate(Sender: TObject);
begin
  AddDomainForResourceString('system');
  UseLanguage('en');
  TranslateComponent(Self);
end;

Mit der Zeile AddDomain... werden also zwei mo-Dateien benutzt: die default.mo für das normale Zeug auf dem Formular und die system.mo. In dem Fall funktioniert der Patch nicht. Kommentiere ich diese erste Zeile aus, so funktioniert der Patch.

Deine Lösungsvorschläge haben so nicht geholfen. In der system.po gibt es aber auch den Eintrag Strg+ -> Ctrl+. Entferne ich diesen Eintrag aus der system.po, so funktioniert der Patch auch bei aktivierter AddDomainForResourceString. Andererseits ist es auch so, dass auch mit aktivierter system.po und ohne Patch das Strg nicht korrekt nach Ctrl übersetzt wird, insofern bringt das ohne Patch eh nix.

Fazit also: Durch den Patch wird es nicht schlechter als vorher, weil der Eintrag Strg+->Ctrl+ aus der system.po ohnehin keine sichtbare Wirkung hat. Man kann den Eintrag in der system.po aber entfernen, dann funktioniert auch der Patch.

[luebbe]

Ob das mit der system.po so mal funktioniert hat? Das scheint ja der ursprüngliche Ansatz gewesen zu sein, dieses Problem zu lösen. Meine erste Lösung, für mit deutscher IDE übersetze Anwendungen, hat, ohne Kenntnis der system.po, genau so funktioniert. Ich wollte aber die zweite .po Datei loswerden.