Ist das ein Fehler in dxGetText?

[Der schöne Günther]

Das viel genutzte dxGetText. Ich finde, da ist ein Fehler. Aber der kann doch noch nicht noch niemandem aufgefallen sein. Wo stehe ich auf dem Schlauch?

Folgender Testcode:

Delphi-Quellcode:

unit __langTest;

interface uses gnuGetText;

procedure justLanguageThings();

implementation

procedure justLanguageThings();
resourcestring
   sMessage = 'Hello';
var
   italian, spanish: TGnuGettextInstance;
begin
   italian := nil; spanish := nil;
   try
      italian := TGnuGettextInstance.Create();
      italian.UseLanguage('IT');

      spanish := TGnuGettextInstance.Create();
      spanish.UseLanguage('ES');

      Write('Italian: ');
      WriteLn( italian.LoadResString(@sMessage) );

      Write('Spanish: ');
      WriteLn( spanish.LoadResString(@sMessage) );

      readln;
   finally
      italian.Free(); spanish.Free();
   end;
end;

end.

Das Ergebnis ist leider

Code:

Italian: Hello
Spanish: Hello

Der Fehler liegt in der gnugettext.pas. Und zwar die letzte Zeile von

Delphi-Quellcode:

function TGnuGettextInstance.LoadResString(
  ResStringRec: PResStringRec): UnicodeString;

Warum steht da

Delphi-Quellcode:

Result:=ResourceStringGettext(Result);

?

Delphi-Quellcode:

ResourceStringGettext

ist eine global herumschlabbernde Routine welche immer auf die globale

Delphi-Quellcode:

DefaultInstance

eines

Delphi-Quellcode:

TGnuGettextInstance

geht, sich also nicht darum kümmert, welche Sprache ich vorgegeben habe. Ich hätte mir meine Instanzen

Delphi-Quellcode:

italian

und

Delphi-Quellcode:

spanish

also gleich sparen könnnen.

Damit es so funktioniert wie es soll müsste die obige Zeile so ersetzt werden:

Delphi-Quellcode:

 Result:= //ResourceStringGettext(Result);
  gettext(Result);

Wer kann mir das ausreden?

Die aktuelle Version ist hier, richtig?
https://svn.code.sf.net/p/dxgettext/...gnugettext.pas

[jaenicke]

Zitat:

Zitat von Der schöne Günther (Beitrag 1333593)

Die aktuelle Version ist hier, richtig?
https://svn.code.sf.net/p/dxgettext/...gnugettext.pas

In den JEDIs (JVCL glaube ich) ist die JvGnuGetText drin. Die ist glaube ich neuer.
Es kann durchaus sein, dass deshalb an anderen Versionen nichts mehr gemacht wird, bin aber am Handy und kann nicht nachschauen.

//edit:
Zumindest die Versionsangabe ist gleich:
https://github.com/project-jedi/jvcl...Gnugettext.pas
Es gibt also wohl nichts Neueres...

[Der schöne Günther]

Ich hatte anfangs bei dxGetText sowieso so gezögert da sich das Projekt anscheinend balkanisiert. Die zentrale Homepage hat den letzten Eintrag von 2008 und die ersten Seiten fehlen schon. Parallel findet man in mehreren Repos Kopien von gnuGetText, teilweise mit eigenen Änderungen (z.B. IFDEFs für neuere Delphi-Versionen).

Ich würde viel ruhiger schlafen, wenn irgendeine bekannte Persönlichkeit das unter ihre Schutzherrschaft nehmen und pflegen würden. Das, was Uwe Raabe und Roman Kassebaum mit den PngComponents gemacht haben, wenn ich es richtig verstanden habe.

[Bbommel]

Ich kann nachvollziehen, dass du etwas skeptisch bist. Manchmal bereue ich auch, dass ich mich für ein Produkt vor 8 Jahren für dxgettext entschieden habe, weil es eben keine zuverlässige, zentrale Wartung mehr gibt. Andererseits läuft das Kernstück, die gnugettext.pas, auch unter Seattle eigentlich noch problemlos und die Tools, die es um Gnugettext herum gibt (allen voran z.B. poEdit) machen die Benutzung schon sehr komfortabel. Gerade auch, wenn man irgendeinen ausländischen Partner mal eben etwas übersetzen lassen will. Insofern möchte ich es eigentlich auch nicht missen.

Mein Traum wäre eigentlich, mit ein paar Leuten dafür zu sorgen, dass das Projekt wieder ordentlich gepflegt wird, eine vernünftige Homepage mit guter Dokumentation, einem aktuellen und funktionierenden Toolset drumherum (denn die Tools, die beim dxGettext-Download mitgeliefert werden, funktionieren unter Windows 10 teilweise nicht mehr, weil sie eine völlig veraltete Cygwin-Version benutzen). Ich würde mich da sicherlich auch gerne einbringen, so gut ich kann, alleine starten würde ich so etwas aber auch nicht. Teilweise fehlt mir da auch das Know-how, was von den bisherigen Tools man mit welcher Lizenz einfach weiter benutzen darf, wann man Lars (den früheren, jetzt offenbar inaktiven Autor) fragen muss und wann nicht.

In den letzten Jahren hat sich Thomas W. Mueller (http://blog.dummzeuch.de/) übrigens immer recht zuverlässig um die Aktualisierung und Fixes der gnugettext.pas im letzten offiziellen Repository (das, was du auch verlinkt hattest) gekümmert. Keine Ahnung, ob er hier im Forum mitliest und wenn ja, unter welchem Namen. Er wäre aber im Moment wahrscheinlich der beste Ansprechpartner für deine ursprüngliche Frage.

Bis denn
Bommel

[Der schöne Günther]

Ja, nichts gegen das Kernstück gnugettext.pas. Es ist an sich hervorragend. :thumb:

Ich kann alles was du meinst 1:1 unterschreiben. Ich würde auch gerne daran irgendwie mitwirken. Ich mache mich als erstes einmal über die Lizenz schlau, dann triggere ich dummzeuch mal an, dann sehen wir weiter 8-)

[Bbommel]

Köln, Königswinter und (falls dummzeuch die Zeit hat, ohne ihn da vereinnahmen zu wollen) Essen - falls wir da etwas auf die Beine stellen wollen, könnte man sich auf jeden Fall ja auch mal hier in der Region treffen, um das Projekt zu starten. Nur schon mal so als Gedanke...

[sh17]

Also ich nehme immer die Default-Instance, deswegen ist mir das noch nicht aufgefallen.

Bei mir klappt zwar alles unter windows 10, auch mit den Tools. Allerdings müsste da doch mal etwas aufgeräumt werden, schonmal die Verzeichnisstruktur ist verwirrend.

//Edit
Ich seh grad, poEdit ist ja noch aktiv
https://poedit.net/download
https://github.com/vslavik/poedit

Sehr schön

[Der schöne Günther]

Klar, poEdit ist eins von vielen Tools für das po/mo-Format (auch mein Favorit) und wird aktiv gepflegt. Das Format gibt es ja schon lange und ist ja keine Erfindung von dxGetText oder Delphi 😉

[neubert]

Hallo,

Zitat:

Zitat von Bbommel (Beitrag 1333648)

Mein Traum wäre eigentlich, mit ein paar Leuten dafür zu sorgen, dass das Projekt wieder ordentlich gepflegt wird, eine vernünftige Homepage mit guter Dokumentation, einem aktuellen und funktionierenden Toolset drumherum (denn die Tools, die beim dxGettext-Download mitgeliefert werden, funktionieren unter Windows 10 teilweise nicht mehr, weil sie eine völlig veraltete Cygwin-Version benutzen). Ich würde mich da sicherlich auch gerne einbringen, so gut ich kann, alleine starten würde ich so etwas aber auch nicht. Teilweise fehlt mir da auch das Know-how, was von den bisherigen Tools man mit welcher Lizenz einfach weiter benutzen darf, wann man Lars (den früheren, jetzt offenbar inaktiven Autor) fragen muss und wann nicht.

ich habe eine komplett neue Version von dxgettext in Perl zusammengehackt und auf Sourceforge zur Verfügung gestellt.

https://sourceforge.net/projects/dxgettext-perl/

Sie tut im wesentlichen das, was dxgettext von Lars Dybdahl täte. Doku ist auf der Sourceforge-Seite im Repo enthalten.

Viele Grüße
Boris

[dummzeuch]

Zitat:

Zitat von neubert (Beitrag 1339979)

ich habe eine komplett neue Version von dxgettext in Perl zusammengehackt und auf Sourceforge zur Verfügung gestellt.

https://sourceforge.net/projects/dxgettext-perl/

Sie tut im wesentlichen das, was dxgettext von Lars Dybdahl täte. Doku ist auf der Sourceforge-Seite im Repo enthalten.

Ohne jetzt Deine Leistung in Frage stellen zu wollen:
Warum? Das DxGettext Tool funktioniert doch problemlos.

[dummzeuch]

fixed:
https://sourceforge.net/p/dxgettext/code/commit_browser

Danke fuer den Hinweis.

[neubert]

Hallo,

[QUOTE=dummzeuch;1339984]

Zitat:

Zitat von neubert (Beitrag 1339979)

Das DxGettext Tool funktioniert doch problemlos.

als ich das Tool vor ein paar Wochen geschrieben habe, hat dxgettext bei mir unter Windows 10 nicht funktioniert und ich habe im Web auch nach umfangreicher Suche keinen Fix gefunden.

Viele Grüße
Boris

[dummzeuch]

Bezüglich der Aktivität des dxgettext Projekts:
Lars ist seit einiger Zeit wirklich ziemlich inaktiv gewesen. Es gab zwar auch noch ein paar andere Contributoren (vermutlich aus seiner Firma), aber auch von denen kam in letzter Zeit kaum noch was. Obones hatte mir vor einiger Zeit seine Änderungen an gnugettext.pas zur Verfügung gestellt und ich habe sie eingebaut, soweit ich sie verstanden habe.

Was die Tools, die zum Projekt gehoeren angeht: Sie funktionieren halt, warum sollte man was dran aendern? Schade finde ich, dass der Po-Editor Gorm anscheinend kaum benutzt wird, der ist naemlich in meinen Augen deutlich besser als Poedit.

Ich bin immer fuer Beitraege anderer offen, aber meine Zeit ist begrenzt. Ich kann nicht im Alleingang saemtliche Delphi-Tools pflegen. Im Moment habe ich am meisten Spass an GExperts und inbstiere die meiste Zeit darin. Aber das kann sich auch wieder aendern.

twm

[dummzeuch]

[QUOTE=neubert;1339987]

Zitat:

Zitat von dummzeuch (Beitrag 1339984)

Zitat:

Zitat von neubert (Beitrag 1339979)

Das DxGettext Tool funktioniert doch problemlos.

als ich das Tool vor ein paar Wochen geschrieben habe, hat dxgettext bei mir unter Windows 10 nicht funktioniert und ich habe im Web auch nach umfangreicher Suche keinen Fix gefunden.

Ok, das kann sein, Windows 10 habe ich mir bisher geschenkt. Unter Windows 8.1 habe ich bisher keine Probleme gehabt.

Was genau war denn das Problem?

twm

[neubert]

[QUOTE=dummzeuch;1339989]

Zitat:

Zitat von neubert (Beitrag 1339987)

Was genau war denn das Problem?

Egal welches Tool aus der (d)xgettext-Suite ich aufgerufen habe, es hat sich danach immer wieder selbst aufgerufen bis ich tausende von Prozessen hatte. Es ist vermutlich die verwendete Version von cygwin Schuld.

Ich fand bei meiner Suche das native Kompilat von gettext für Windows von https://mlocati.github.io/gettext-iconv-windows/ und musste daher nur noch ein Tool schreiben, das aus .pas- und .frm-Dateien .pot-Dateien generiert. Mit Perl war das ein überschaubarer Aufwand.

Viele Grüße
Boris

P.S.: Du bist der dummzeuch, der GExperts geschrieben hat. Vielen Dank dafür, das nutze ich seit vielen Jahren!

[sh17]

Was ist denn nun das aktuelle Sourcecode Repository für die Delphi-Version? Die auf SourceForge?

[neubert]

Zitat:

Zitat von sh17 (Beitrag 1339991)

Was ist denn nun das aktuelle Sourcecode Repository für die Delphi-Version? Die auf SourceForge?

Version von was? dxgettext von Lars Dybdahl, dxgettext.pl von mir oder gnugettext.pas?

[dummzeuch]

Zitat:

Zitat von neubert (Beitrag 1339990)

P.S.: Du bist der dummzeuch, der GExperts geschrieben hat. Vielen Dank dafür, das nutze ich seit vielen Jahren!

Zuviel der Ehre. GExperts gab es schon, als ich mit Delphi Programmieren angefangen habe, Anfang der 90er. Ich habe vor allem den Sourcecode Formatter eingebaut (auch der ist nicht selbst geschrieben) und ein paar kleinere Aenderungen gemacht.

[dummzeuch]

Zitat:

Zitat von sh17 (Beitrag 1339991)

Was ist denn nun das aktuelle Sourcecode Repository für die Delphi-Version? Die auf SourceForge?

dxgettext? -> Sourceforge

Wobei: Definiere aktuell!
Da ja "neuerdings" die Verwendung von Git + GitHub so beliebt ist, gibt es inzwischen so viele Forks, dass ich den Überblick verloren habe. Offiziell ist das Projekt auf Sourceforge. Ob irgendwelche Forks aktueller sind, je nach Definition von "aktuell", kann ich nicht sagen.

[dummzeuch]

Zitat:

Zitat von neubert (Beitrag 1339990)

Zitat:

Zitat von dummzeuch (Beitrag 1339989)

Was genau war denn das Problem?

Egal welches Tool aus der (d)xgettext-Suite ich aufgerufen habe, es hat sich danach immer wieder selbst aufgerufen bis ich tausende von Prozessen hatte. Es ist vermutlich die verwendete Version von cygwin Schuld.

Ich fand bei meiner Suche das native Kompilat von gettext für Windows von https://mlocati.github.io/gettext-iconv-windows/ und musste daher nur noch ein Tool schreiben, das aus .pas- und .frm-Dateien .pot-Dateien generiert.

Jetzt, wo du das sagst: Ich erinnere mich ganz dunkel, dass ich auch mal die gnugettext-Tools, die original im Installer waren, weggeworfen und durch nativ compilierte ersetzt hatte, weil ich ein Problem damit hatte. Das ist schon ewig her.

dxgettext.exe, das Tool zum extrahieren von strings aus .pas und .dfm war aber nicht betroffen, das ist in Delphi geschrieben und die sourcen sind im svn. Das gilt auch fuer:

• assemble.exe
• msgmkignore.exe
• msgremove.exe

[sh17]

Zitat:

Zitat von dummzeuch (Beitrag 1339994)

Zitat:

Zitat von sh17 (Beitrag 1339991)

Was ist denn nun das aktuelle Sourcecode Repository für die Delphi-Version? Die auf SourceForge?

dxgettext? -> Sourceforge

Wobei: Definiere aktuell!
Da ja "neuerdings" die Verwendung von Git + GitHub so beliebt ist, gibt es inzwischen so viele Forks, dass ich den Überblick verloren habe. Offiziell ist das Projekt auf Sourceforge. Ob irgendwelche Forks aktueller sind, je nach Definition von "aktuell", kann ich nicht sagen.

Ich meine natürlich das offizielle Projekt. Mir wäre es auch lieb, es würde zu Github umziehen, so wäre es einfacher, etwas beizusteuern. (Das gilt auch für GExperts...). So lasse ich es nämlich, weil es mir zu aufwändig ist. Ich mein, die Delphipraxis hat doch ein Team bei GitHub, da könnte man solche Projekte sehr gut unterbringen, die sonst nicht mehr gepflegt werden würden.

[dummzeuch]

Hi,

der Thread ist zwar schon "etwas" älter, aber:

Zitat:

Zitat von Der schöne Günther (Beitrag 1333593)

Der Fehler liegt in der gnugettext.pas. Und zwar die letzte Zeile von

Delphi-Quellcode:

function TGnuGettextInstance.LoadResString(
  ResStringRec: PResStringRec): UnicodeString;

Warum steht da

Delphi-Quellcode:

Result:=ResourceStringGettext(Result);

?

Delphi-Quellcode:

ResourceStringGettext

ist eine global herumschlabbernde Routine welche immer auf die globale

Delphi-Quellcode:

DefaultInstance

eines

Delphi-Quellcode:

TGnuGettextInstance

geht, sich also nicht darum kümmert, welche Sprache ich vorgegeben habe. Ich hätte mir meine Instanzen

Delphi-Quellcode:

italian

und

Delphi-Quellcode:

spanish

also gleich sparen könnnen.

Damit es so funktioniert wie es soll müsste die obige Zeile so ersetzt werden:

Delphi-Quellcode:

 Result:= //ResourceStringGettext(Result);
  gettext(Result);

Wer kann mir das ausreden?

Ich ;-)

Ich habe gerade die Änderung von damals rückgängig gemacht, da damit AddDomainForResourceString keine Auswirkungen mehr hatte.

Allerdings habe ich aus der globalen Function ResourceStringGettext eine Methode von TGnuGettextInstance gemacht, so dass jetzt beides funktioniert: Eigene Instanzen von TGnuGettextInstance für spezielle Sprachen und AddDomainForResourceString.

twm