Hi,
kurz mal meine Erfahrung mit den Resourcen-
DLL's in
VCL-Projekten:
Ändert man am Projekt etwas, muss man zwingend die Resourcen-
DLL neu compilieren, wenn nicht, gibt es kuriose Schutzverletzungen. Das ist insbesondere beim Debuggen umständlich, wenn man z.B. einen Fehler sucht, der nur mit der Tschechischen Übersetzung auftritt.
Nach etlichen Jahren des Herumquälens mit Resourcen-
DLL's (erst per
ITE und später dann mit dem
Localizer) sind wir bei GnuGetText (dxgettext) angekommen.
Endlich braucht man nicht immer alles neu zu compilieren. Und bei der fertigen Exe kann der Übersetzer jederzeit das Resultat seiner Änderungen sehen, ohne dass ich ihm eine neue Exe comipiliere.
Und resourcestrings sind nunmal Standard.
Bleiben sie auch. Sie werden zur Laufzeit gegen die Übersetzung ausgetauscht.
Wenn man dann noch hier
http://dxgettext.po.dk/Home liest, daß seit 2008 sich gerade mal gar nichts getan hat stiftet das wenig Vertrauen.
Schau mal:
https://svn.code.sf.net/p/dxgettext/code/trunk
Einiges gibt es noch zu bemerken. Beim Betrachten der Quelltexte des Parsers für Resourcestrings war ich leicht schockiert. Aua, Bastelman und Söhne. Aber das Extrahieren und auch die Übersetzung im Programm funktioniert! Und es sind einige Tools zum Manipulieren der PO-Dateien dabei, wie z.B. Mergen von 2 PO-Dateien oder Übersetzen einer PO-Datei auf Basis einer anderen. So ist es auch relativ leicht, Übersetzungsrepositories zu erstellen und umgekehrt neue Projekte damit zu übersetzen. Daneben gibt es einige verschiedene PO-Editoren, die man ja nach Geschmack einsetzen kann.
Ohne die Forderung, dass der Vertriebspartner in anderen Ländern die Übersetzung mit einfachen Mitteln selbst anpassen können muss, wären wir vermutlich bei Resourcen-
DLL's geblieben. Nach der Einarbeitung in gnugettext, der Überwindung einiger kleinerer Hürden und der Anpassung des Übesetzungs-Workflows bin ich jetzt schneller und flexibler (und auch zufriedener) als vorher.
Viele Grüße