dxggettext mit Projekt und Code-Sammlung

[CCRDude]

Ich versuche mich gerade für ein neues Übersetzungssystem für meine Software zu entscheiden. Früher lief ich mit etwas selbstgeschriebenem sehr gut, allerdings müsste ich das auf Unicode umstellen, und es gibt ja auch so vielversprechende Ansätze.

MUI als Standard schlechthin musste ich leider verwerfen, weil die VCL mit übersetzten DFM-Resourcen nicht klarkommt

ITM/ETM gruseln mich, die Extra-IDE-Optionen wirken auf mich zu komplex (nicht vom Verständnis her - aber scheinen mir zusätzliche potentielle Fehlerquellen zu sein).

Momentan schaue ich mir gnugettext an, das sieht wirklich vielverpsrechend aus. Ich hänge aber noch an einem Problem. Wenn ich auf meine Platte schaue, sehe ich:

C:\Code\Projekte\HalloWelt\src\*.pas;*.dfm;*.dpr
C:\Code\Projekte\EmptyDummy\src\*.pas;*.dfm;*.dpr
C:\Code\Units\Eigene\*.pas

Im eigenen Repo habe ich etlichen Code (einige Hundert Units), der von vielen meiner Anwendungen verwendet wird. Nicht wenige davon beziehen sich auf das User Interface und verwenden daher auch schon Texte. Nun könnte ich weiter hingehen und diese Texte gegen Konstanten ersetzen, die ich von der übersetzen Anwendung überschreiben lasse (der Ansatz meines alten Codes). Oder ich könnte den kompletten Ordner von dxgettext mit durchsuchen lassen, ende dann aber bei viel zu vielen Strings.

Kann ich nicht einfach alle von einem Projekt verwendeten Units parsen lassen? Evtl., indem ich vorher eine Liste der verwendeten Units erstelle (dxgettext kennt für die Parameter einen @-Prefix für Listen)? Um zur Frage zu kommen: was ist dafür der beste Ansatz? Spuckt der Compiler selber sowas schon an der Kommandozeile aus, wenn ich ihn nett bitte? Muss ich ein externes Tool verwenden (ich erinnere mich da grob an ein Tool, das unbenötigte uses-Klauseln identifizieren sollte, das hat ja beispielsweise schon eine List)?

Oder grob gesagt: hat sich schon jemand mit dieser Problematik auseinandergesetzt und einen guten Tipp dazu, bevor ich mich in die vielleicht falsche Richtung stürze?

[haentschman]

Schau dir mal http://www.delphipraxis.net/146618-l...swerkzeug.html an...

[wicht]

Danke für die Erwähnung ...
Lingus ist wahrscheinlich nicht perfekt, kann aber meiner Meinung nach locker mit dxgettext mithalten und bietet an der ein oder anderen Stelle sogar etwas mehr. Ein bisschen Support könnte ich auch leisten, falls die Anleitung auf der Webseite das nicht ausreichend beschreibt. Ausserdem sind die Quellen frei verfügbar, aber das sind die von dxgettext ja auch.

[CCRDude]

Danke für die Empfehlung

Darüber war ich hier im Forum tatsächlich auch schon gestolpert, und es sieht fraglos gut aus. In Details deutlich ordentlicher als meine eigene alte Lösung. Leider aber schien es zu meiner Problemstellung nicht zu passen. Unsere aktuelle Version (mit Delphi 2006 und noch AnsiStrings mit Charsets) gibt es in über 30 vollständigen Übersetzungen - sowas ist als Resource fest einkompiliert einfach nicht hinzubekommen - alle Übersetzer sind Freiwillige, deshalb natürlich nicht innerhalb kürzester Zeit vor einem Release verfügbar, und getrennte Versionen sind einfach unpraktisch, da würde die Build Chain ewig lang werden.

Wenn ich schon auf Resourcen setzen würde, dann der Flexibilität halber per MUI, die lassen sich beliebig jederzeit neue Übersetzungen ergänzen. Evtl. würde das in Lingus per zur Laufzeit nachgeladener .lpf funktionieren?

Das soll Lingus jetzt nicht schmälern, es sieht halt auf den ersten Blick nur nicht zu meinen Anforderungen passend aus.

Wie sieht es denn mit Lingus und der oben genannte Problematik aus (nur verwendete Units aus Pfaden wirklich in Übersetzungsdatei landen lassen)? In meinem eigenen Code hatte ich das so gelöst, dass die Basis-Sprachdatei zur Laufzeit generiert werden kann, mit dem Nachteil, dass alle Strings quasi im initialization stecken müssen, um da bekannt zu sein.

Vielleicht starte ich mal mit einer Meta-Unit, die es mir ermöglicht, später einfach über eine Änderung der Meta-Unit das System ändern zu können.

Eine kurze Idee in Sachen ursprünglicher Problematik: die verwendeten Units könnte ich doch aus der .map-Datei rausholen (für die habe ich schonmal einen Parser geschrieben), oder? Dann könnte ich es evtl. sogar in die Build Chain packen. Ein Funktionsaufruf in der initialization aller Units, die die Meta-Unit verwenden, wäre auch möglich, aber entweder mit Konstante (unschön), oder bekomme ich den aktuellen Unit-Namen per Code raus, ohne Debug-Infos?

[wicht]

Zitat:

Wie sieht es denn mit Lingus und der oben genannte Problematik aus (nur verwendete Units aus Pfaden wirklich in Übersetzungsdatei landen lassen)?

Es gibt die Option, nur Texte aus Units einlesen zu lassen, die LanguageObjects im Uses-Abschnitt haben (Eben Units, die Übersetzungen benutzen). Dann fehlt vielleicht der ein oder andere Text aus anderen Units, aber die Texte kann man dann noch separat über den Importer hinzufügen. Es läuft ja so ab, dass man die Quellen nach Texten durchsucht und dann hat man ein Fenster, wo man sagen kann "Text ignorieren" oder "Text hinzufügen".

[EWeiss]

Ich verwende dxgettext für das was ich übersetzen muss reicht das völlig aus.
Vor allem ist die implementierung simple und nicht gerade aufwendig.

gruss

[CCRDude]

Danke für Deine Erklärung, wicht!

Ich fürchte aber, dass ich meine Problematik entweder nicht gut genug beschrieben habe, oder Deine Erklärung nicht verstehe. Ich versuche mal, nicht zu weit auszuschweifen.

Ich habe 500 eigene Units in einem globalen Unit-Ordner, alle mit Strings, alle mit Übersetzungsunit und _('blub') angewendet.

Projekt A verwendet nun 20 von diesen 500, Projekt B verwendet 150, Projekt C vielleicht 100, und diese Mengen überschneiden sich. Parst das Übersetzungsprogramm nun den kompletten Ordner, würde es immer alle 500 aufnehmen, auch wenn längst nicht alle verwendet werden!

Disclaimer: natürlich verwenden nicht alle 500 Units Strings, das wäre kein guter Stil (Stichwort Trennung GUI vs. Funktionalität). Aber zu fast jeder Datenklassenunit etwa habe ich eine Darstellungsunit. Und das ganze ist auch auf ein Dutzend Ordner verteilt. Und was brauche ich Übersetzungen für PE-Dateistrukturbezeichnungen, wenn ich ein Programm, das mit Packformaten umgeht, übersetzen will? Wenn aber alles im Ordner analysiert wird, wäre der komplette fileformats-Ordner drin.

Also nochmal anders gefragt: kann Lingus alternativ auch eine Liste der zu durchsuchenden Dateien verarbeiten? Und wenn ja, möglichst auch geskriptet (momentan FinalBuilder & ActionChain).

[wicht]

Nein, so direkt wird das vermutlich nicht gehen. Ich mache aber etwas (vielleicht) vergleichbares: Ich habe einen Bibliotheks-Ordner und dann meine zu übersetzenden Programme. Ein Lingus-Projekt hält die Bibliothek-Übersetzungen, weitere Lingus-Projekte die Übersetzungen zu dem eigentlichen jeweiligen Programm. Ich habe dann 2 .res/.lpf-Dateien (für Bibliothek und Programm an sich), die ich ins Programm mit reinhaue. Klar, es kann dann sein, dass ein Projekt von einem bestimmten Teil der Bibliothek keinen Gebrauch macht, aber die Übersetzungen trotzdem beinhaltet. Das ist mir aber nicht so wichtig.
Und Integration in FinalBuilder oder so gibt es auch nicht, kenne ich mich auch nicht mit aus. Mein Build-Server ist ein langes Python-Skript ..

[CCRDude]

FinalBuilder kann auch einfach Konsolen-Anwendungen aufrufen

Ich habe es in ActionChain mit GNU Gettext jetzt gelöst, FinalBuilder folgt. Falls es jemanden interessieren sollte:

1. Selbstgeschriebenes UnitListFromMapFile.exe extrahiert aus allen Map-Files in einem Suchpfad die verwendeten Units und ergänzt sie anhand des globalen Suchpfades und der Projektdatei um die Endungen (nicht die Pfade!), speichert sie in compiled-units.lst.
2. dxgettext -b C:\genericcoderepo\ @compiled-units.lst --so compiled-units.po
3. dxgettext -b C:\project1\ @compiled-units.lst --so compiled-project.po
4. msgcat compiled-project.po compiled-units.po default.po

Ich sammle diese Schritte mal eben in einem kleinen weiteren Tool, um sie besser automatisieren zu können

[CCRDude]

So, hier wie versprochen die kleinen Helfer.

Code:

UnitListFromMapFile <mapfilemask> <projectfilemask> [/paths] [/strip]

Findet alle für ein Programm kompilierten Units, indem es die erzeugte .map auswertet und mit Hilfe des Standard-Suchpfades (Delphi XE, XE2) und der Projektdatei ergänzt.

Beide Pfadparameter können Masken enthalten, um mehr als eine Datei auswerten zu können. Mit dem Parameter /paths werden vollständige Pfade ausgegeben (für dxgettext unbedingt weglassen), /strip entfernt alle Unit-Namen von Units, die nicht auf der Platte gefunden wurden.

Code:

dpdxgupdate <configfilename>

Aktualisiert die GNU Gettext-Dateien eines Delphi-Projektes. Mit dem gleichen Code wie oben wird intern eine Liste alle vom Projekt verwendeten Units erstellt. Für jeden in der Konfigurationsdatei angegeben Pfad wird hier eine separate .po erstellt. Diese werden am Ende zu einer zusammengefügt, und existierende Übersetzungsdateien werden aktualisiert.

Eine Beispielkonfigurationsdatei ist enthalten.