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:

markieren

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:

markieren

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 von dummzeuch:

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

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:

markieren

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 von v2afrank:

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

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 von Bbommel:

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

markieren

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?