Nachteile von dxgettext?

[Bbommel]

Hallo zusammen,

ich stehe vor der Aufgabe, ein Projekt mit Mehrsprachigkeit auszustatten. Prinzipiell ist mir auch klar, wie das in Delphi (habe hier BDS2006) von Haus aus funktioniert und habe damit auch schon mal ein Projekt erstellt, aber so richtig glücklich war ich damit nicht (Compilieren wurde leicht nervig, Übersetzung aufwendig, Sprache nicht zur Laufzeit zu wechseln, ...).

Nun bin ich beim Suchen hier im Forum zur Mehrsprachigkeit schon öfter über dxgettext gestolpert. Das ganze sieht auch tatsächlich recht brauchbar für mich aus:

• Die Sprachdateien sind einfach mit einem Editor zu bearbeiten und damit auch durch einen externen Übersetzer.
• Das Ganze scheint sich recht leicht in Delphi einbauen zu lassen.
• Die Sprache des Programms kann zur Laufzeit gewechselt werden.

Meine Frage daher: Gibt es irgendwas, auf das ich noch achten muss? Hat das Programm bekannte Probleme/Fehler? Läuft es stabil? Was kann ein teures Übersetzungs-Tool, was dieses Programm nicht kann?

Für ein paar Rückmeldungen wäre ich dankbar. Die Entscheidung ist halt recht wichtig, weil ich keine Lust habe, ein ganzes Projekt in einigen Monaten noch mal umkrempeln zu müssen.

Danke
BBommel

[OregonGhost]

Ich habe dxgettext zwar bisher nicht verwendet, aber mir das mal ein wenig angeguckt. Als "professionelles" Übersetzungstool (gibt es sowas?) habe ich bisher nur mit dem Qt Linguist gearbeitet. Das Konzept ist dort ähnlich: Im Quelltext stattet man alle Strings mit einem Funktionsaufruf aus (dort tr()). Dann kann man das in die Sprachdatei exportieren, die natürlich inkrementell aktualisiert wird. Man öffnet sie im Linguist und hat dort eine Übersicht, die ähnlich wie poedit aussieht, allerdings zusätzlich noch eine Gruppierung nach Klasse vornimmt (tr ist dort eine Methode in jedem Objekt). Zusätzlich kann man tr() noch einen Kommentar übergeben, der ebenfalls im Linguist angezeigt wird. Ist man mit einer Übersetzung fertig, klickt man im Linguist "Release" und erhält die Binärdatei, die man dann mit der Anwendung ausliefern kann. Nach kurzer Zeit hat man sich auch an das Konzept gewöhnt und umschließt von vornherein jeden String, den der Benutzer sehen könnte, mit dem Funktionsaufruf. Der Aufwand als Programmierer ist dadurch sehr gering.

Das ist im Prinzip alles, was ich von einer Übersetzungsbibliothek erwarte, und auch wenn mir poedit ein wenig unübersichtlicher zu sein scheint, dürfte dxgettext nach den Informationen auf der Website das auch alles bieten. Der Vor- und Nachteil zugleich dieser Systeme ist, dass du die Strings in der neutralen Sprache direkt im Quellcode hast. Der Vorteil ist, dass du als Programmierer die Strings einfach eintragen kannst und auch einfach findest, weil Strings ja hervorgehoben sind. Der Nachteil ist, dass insbesondere mehrere gleich lautende Übersetzungen auch mehrfach enthalten sind, und wie es um eventuelle Laufzeitverzögerungen aussieht, weiß ich nicht so genau. Der alternative Ansatz ist, mit Konstanten zu arbeiten. Das ist, wenn man es manuell macht, sehr unangenehm, aber wenn man ein Framework wie z.B. den Ressourcen-Editor von Visual Studio 2005 benutzen kann, der einem die Konstanten (typsicher und mit Intellisense) generiert und das Laden der verschiedenen Strings damit erleichtert, eigentlich ganz ok. Allerdings ist das eigentlich Übersetzen dort etwas umständlicher.

Das ganze mal als meine Meinung dazu, ob ein Tool wie dxgettext für deine Zwecke geeignet ist und im Endeffekt auf deine Frage nach den "professionellen" Übersetzungstools.

[Thomas_K]

Zitat von Bbommel:

Meine Frage daher: Gibt es irgendwas, auf das ich noch achten muss? Hat das Programm bekannte Probleme/Fehler? Läuft es stabil? Was kann ein teures Übersetzungs-Tool, was dieses Programm nicht kann?

Ich benutze dxgettext und gravierende Nachteile konnte ich bis jetzt nicht finden. Beachten sollte man das man idealerweise das Programm zuerst in Englisch geschrieben hat, von Vorteil ist auch wenn man die Möglichkeit hat sein Programm mit einer Englischen Delphi Version Kompilieren lassen kann, damit man auch die standard Resourcen Texte von dxgettext einfacher übersetzt werden können.
Als eiziges weigert sich hardneckig der shortcut Text 'Ctrl' <-> 'Strg' in Menus übersetzt zu werden, doch das sollte man verschmerzen können.
Bei mir hat es ein rundum soliden Eindruck hinterlassen. Besonders gefällt mir die Möglichkeit, das ein Übersetzer unabhängig vom Programmierer arbeiten kann. Er kann eine Übersetzungen hinzufügen und sieht sofort das Resultat und er kann somit gleich sein Werk überprüfen und entsprechend korigieren, ohne das der Programmierer hierbei eingreifen müsste.
Da die Basisübersetzungen in UTF8 Textdateien gespeichtert werden und damit auf Unicode setzten, eigenden sie auch ideal jetzt im Zusammenspiel mit Unicode Componenten, wie die TNT/TMS Componenten. Da die VCL in Delphi 2008(Win32) von vorherein auf Unicode setzten wird, dürfte sich die Entscheidung auf dxgettext einzusetzten sicherlich nicht als Nachteil herausstellen.