Mehrsprachige Anwendung: Ich kriegs nicht hin

[bgeltenpoth]

Hallo,

vielen Dank für die Anmerkungen ich werden mit DXGetText mal anschauen

[Rollo62]

Mit dxGetText arbeite ich auch in einem Projekt mit einem angepassten Gorm-Editor weil
das Orginal PO-Edit nicht ganz mein Fall ist.
Aber das Projekt ist schon sehr undurchsichtig, und ich meine so aus dem Bauch heraus
das ganze könnte viel schlanker sein.
Die dxGnugettext.pas hat so ca. 150 kB Sourcen.

Dazu gibt es noch verschiedene Versionen und auch ein JEDI JvGnugettext, so das ich nie wirklich
sicher bin was denn nun eigentlich der richtige dxGnugettext ist.

Für Firemonkey scheint dxGnugettext wohl noch keine Portierung zu geben, oder ist das schonmal jemanden
untergekommen ?

Rollo

[Cubysoft]

Ich habe mitlerweile eine eigene Klasse geschrieben, mit der ich Lnaguage-Files direkt aus den Ressourcen laden kann. Ich weiß nicht ob die Klasse alle Wünsche erfüllt, aber in meinem Projekt läuft sie einwandfrei. Wenn jemand interesse hat, kann ich mein Werk gerne mal posten

[Sherlock]

Wenns auch etwas Geld kosten darf, kann ich uneingeschränkt den Sisulizer empfehlen. DFMs werden ohnehin übersetzt, und im Strings im Quellcode einfach zu resourcestrings machen (Gibt ja ein Refaktoringtool dafür). Und schon bekommt man einfache Lokalisierung inklusive wiederverwendbarer Übersetzungs-DB und einem schicken kostenlosen Tool, das man an Übersetzer geben kann.

Sherlock

[nuclearping]

Zitat von Sherlock:

Wenns auch etwas Geld kosten darf, kann ich uneingeschränkt den Sisulizer empfehlen. DFMs werden ohnehin übersetzt, und im Strings im Quellcode einfach zu resourcestrings machen (Gibt ja ein Refaktoringtool dafür). Und schon bekommt man einfache Lokalisierung inklusive wiederverwendbarer Übersetzungs-DB und einem schicken kostenlosen Tool, das man an Übersetzer geben kann.

Sherlock

Wenn ich mir deren Seite so anschaue, scheint diese Lösung aber die gleichen Probleme und Einschränkungen zu haben, wie das Board-Werkzeug von Delphi?

- Umständlich
- Aufgebläht
- Resourcenstrings
- Localized Builds

Zitat:

Now that your translator has finished translating all of your strings, and you've received your updated file, simply run Sisulizer to build the new version of your program in the new language.

So wie das klingt gibt es dann für jede Sprache eine eigene Anwendung?

Wir haben für unser Projekt eine eigene Lösung entwickelt, die eine extreme "Lightweight"-Variante von GNU GetText ist.
Der Source des Parsers zum extrahieren der Texte ist ~30kB groß.
Die Localizer-Unit ist nur 18kB und arbeitet nach dem gleichen Schema, also Formulare werden per L.Translate(Self) übersetzt und Texte im Code per LabelX.Caption := L['Hallo Welt'] gekapselt.
Dazu haben wir noch einen WYSIWYG-Editor geschrieben, der die Bearbeitung im Tabellenformat, wie Excel, ermöglicht.

Damit betreiben wir unser Projekt schon seit fast 10 Jahren und hatten bei keiner Sprache bisher irgendwelche Probleme, egal ob Deutsch, Englisch, Russisch, Japanisch, ...

Verstehe nicht, wieso Firmen / Entwickler solche aufgeblähten und umständlichen Tools für so eine simple Sache entwickeln und / oder nutzen?

[Sherlock]

Weil wir nicht das Rad neu erfinden wollten. Und resourcestrings sind nunmal Standard. 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. Ich behaupte nicht, daß das Tool Mist ist. Ich würde es nur nich kommerziell einsetzen wollen. Wie ist es eigentlich um die Wiederverwendbarkeit der Übersetzungen über Projektgrenzen hinaus bestellt? so wie sich mir das darstellt, sind die Übersetzungen dort projektbezogen.

Sherlock

[nuclearping]

Zitat von Sherlock:

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.

So eine Lösung ist meiner Erfahrung nach auch nicht besonders wartungsintensiv. In unserer Localizer-Klasse haben wir auch schon seit Jahren nichts mehr ändern müssen.

Zitat von Sherlock:

Wie ist es eigentlich um die Wiederverwendbarkeit der Übersetzungen über Projektgrenzen hinaus bestellt? so wie sich mir das darstellt, sind die Übersetzungen dort projektbezogen.

Das ist im Prinzip egal. Die Kapselung in _('...') bzw. (bei uns) L['...'] ist ein Dictionary und er sucht sich die dazu passende Übersetzunge aus der eingestellten Sprachdatei raus.

[Uwe Raabe]

Zitat von nuclearping:

So wie das klingt gibt es dann für jede Sprache eine eigene Anwendung?

Ich weiß jetzt nicht genau, wie es Sisulizer macht, aber die anderen mir bekannten Übersetzungstools, die auf DFM (=Resource) und resourcestrings arbeiten, legen die Übersetzungen als separate Resource-DLLs neben die unübersetzte Exe. Wenn du mal in deinem Delphi-Bin-Ordner nachsiehst, wirst du dort unter anderem eine bds.exe und eine bds.de entdecken. Die DE-Datei enthält lediglich die übersetzten Teile.

Der Vorteil bei dieser Herangehensweise ist, daß die entsprechende Funktionalität bereits in der RTL implementiert ist. Damit muss kein zusätzlicher Code eincompiliert werden, der deine Anwendung in eine andere Sprache übersetzt. Du musst lediglich eine passende Resource-DLL dazulegen und die Sache ist geritzt. Tools zum Erstellen dieser DLLs gibt es mehrere. Es würde mich wundern, wenn nicht auch Sisulizer dafür zumindest eine Option hat.

[rwalper]

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.

Zitat von Sherlock:

Und resourcestrings sind nunmal Standard.

Bleiben sie auch. Sie werden zur Laufzeit gegen die Übersetzung ausgetauscht.

Zitat von Sherlock:

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