Übersetzung in andere Sprachen mit bestimmten Anforderungen

[Dalai]

Hallo Leute .

Ich schreibe gerade an einer DLL für ein Fremdprogramm (Plugin für Total Commander um genau zu sein). Nun bin ich an einem Punkt angelangt, an dem ich diese DLL gerne in andere Sprachen übersetzen möchte. Also hab ich natürlich die Forensuche und sonstige Suchmaschinen bemüht und einige Komponenten, Möglichkeiten usw. gefunden: Kryvich's Delphi Localizer, (dx)GetText, Sisulizer, DeLoc/DelLoc usw.

Bevor ich mir alle nach und nach anschaue, frage ich vorher mal in die Runde, da sich mit Sicherheit schon einige von euch mit Übersetzungen beschäftigt haben und die Varianten dafür (besser) kennen. Außerdem habe ich bestimmte Vorgaben/Bedingungen, die erfüllt werden sollten:

• Die Sprachdateien müssen vom Nutzer später editierbar sein! Oder anders ausgedrückt: sie müssen als normale Textdateien (Text, INI o.ä.) mitgeliefert werden. Ich habe keine Lust, jedesmal das Projekt oder eine Ressourcen-DLL neu zu kompilieren, um neue Sprachstrings einzufügen oder Übersetzungen zu ändern. Damit fallen jegliche Wege raus, die die Sprachen/Übersetzungen in binärer Form (DLL, .MO bei GetText) mitbringen.
• Es wäre schön, wenn die Geschichte im Delphi 5 läuft, auch wenn das nicht unbedingte Voraussetzung ist. Derzeit habe ich die Möglichkeit, ein XE2 zu nutzen, aber ich weiß nicht, wie lange. Momentan schreibe ich den Code so, dass er unter beiden IDEs kompiliert.
• Die Übersetzung betrifft VCL-Komponenten, Messageboxen, Strings an anderer Stelle (in der Dateiliste vom Total Commander), und bestimmt hab ich noch andere vergessen.
• Ich brauche keine dicke fette Lösung sondern etwas Einfaches genügt mir.
• Leichte Einbindung in die IDE bzw. den Code wäre auch von Vorteil.

Kann mir jemand eine Empfehlung geben?

MfG Dalai

[Namenloser]

Für GetText-Dateien gibt es eine Vielzahl kostenloser Editoren, mit denen auch Nichtprogrammierer die Sprachdateien komfortabel selbst editieren können. Das ist ein großer Vorteil bei GetText, es ist quasi ein Standard. Ich habe gute Erfahrungen damit gemacht. In meinem Fall hat irgendeine externe Übersetzungfirma, mit der ich selber nie Kontakt hatte, die Übersetzung gemacht, und die konnten dort mit meinen Dateien anscheinend sofort etwas anfangen. Gab jedenfalls keine Rückfragen.

Ich kann allerdings nicht sagen, wie komfortabel die Übersetzung von visuell zusammengeklickten Formularen bei dxGetText gelöst ist, da es in meinem Programm so etwas nicht gab und ich mich deshalb nicht damit beschäftigt hatte.

[Furtbichler]

Die TotalCommander-Plugins benötigen eigene Übersetzungen? Hat TC das nicht auch? Naja, schade.

Ich habe früher TSiLang verwendet, ein sehr sehr gutes Produkt. Kostet aber etwas.

dxGetText würde ich heute verwenden.

[Dalai]

Zitat von Furtbichler:

Die TotalCommander-Plugins benötigen eigene Übersetzungen?

Für Inhaltsplugins kann man einfach eine .lng schreiben, die dann vom TC ausgelesen und ausgewertet wird. Für alle anderen Typen (in meinem Fall ein Dateisystemplugin) muss man sich einen eigenen Kopf machen. In der Tat ist das schade, auch wenn ich verstehen kann, dass TC sich nicht um alles kümmern kann .

Zitat:

Ich habe früher TSiLang verwendet, ein sehr sehr gutes Produkt. Kostet aber etwas.

Tja, es liegt in der Natur der Sache, dass ich für ein einmaliges kostenfreies Plugin kein Geld ausgeben will...

Zitat:

dxGetText würde ich heute verwenden.

Es fällt aber leider aus dem ersten o.g. Grund raus - und der steht fest. Ich kenne GetText im Prinzip, weil ich damit schon Bash-Skripte übersetzt habe. Einem Übersetzer könnte man evtl. zumuten, ein bestimmtes Programm zum Übersetzen zu benutzen, aber es geht mir hier wirklich um Endanwender, den einfachen TC-Benutzer.

Ich würde es auch selbst programmieren, aber momentan fehlen mir gute Ideen. Andererseits will ich ungern das Rad neu erfinden, weil es da mit Sicherheit etwas gibt.

MfG Dalai

[Zoot]

Ich komme mit DKLang ganz gut klar, es liefert auch eine editierbare Textdatei.

[Furtbichler]

dxGetText liefert auch eine editierbare Textdatei, nur ist die nicht sonderlich benutzerfreundlich. Dafür gibt es spezielle Editoren, die auch umme sind. Aber vielleicht ist das mit Kanonen auf Spatzen schießen.

Je einfacher Du die Text-Datei gestaltest (INI-Datei z.B.), desto mehr musst Du im Code programmieren, was aber auch kein Beinbruch ist. Natürlich wäre es Toll, alles im Code automatisch zu machen, aber wie wäre es mit diesem Ansatz (funktioniert sofort)

Delphi-Quellcode:

uses
  myTranslations; // <-- contains a loaded Translations : TStringList'
Procedure TMyForm.FormCreate(...
begin
  Self.Caption := Translations.Values['TMyForm.Caption'];
  Label1.Caption := Translations.Values['TMyForm.Label1.Caption'];
  btOk.Caption := Translation.Values['Buttons.OK'];
....

Du setzt alle Beschriftungen also individuell zur Laufzeit. Das ist so banal, da traut man sich ja gar nicht, Dir das vorzuschlagen. Das sieht zwar dämlich aus, aber bei -sagen wir- < 20 Formularen ist der Zusatzaufwand wirklich nicht groß. Das ist in einer Stunde erledigt.

Die Textdatei sieht dann so aus:

Code:

TMyForm.Caption=Überschrift Formular 1
TMyForm.Label1.Caption=Vorname
Buttons.OK=OK

Natürlich ist das optimierbar (Sections etc.) und die Schlüssel in der Textdatei kannst Du ja auch noch für den Endanwender kompatibler gestalten (Wer kann sich schon etws unter 'TMyForm.Label1.Caption' vorstellen?)

Wäre das nicht ein Anfang?

[Bentissimo]

Ich verwende seit kurzem dieses Produkt:

http://www.be-precision.com/products/precision-langs/

Gefällt mir persönlich sehr gut.

Ist zwar nicht ganz kostenlos, dürfte aber das Budget nicht sprengen.

[Dalai]

Zitat von Furtbichler:

dxGetText liefert auch eine editierbare Textdatei, nur ist die nicht sonderlich benutzerfreundlich. Dafür gibt es spezielle Editoren, die auch umme sind.

Ja, ich weiß. Ich kenne PoEdit, auch wenn ich den erst vor Kurzem entdeckt habe (und das Bash-Skript mit einem normalen Editor übersetzt habe ).

Zitat:

Aber vielleicht ist das mit Kanonen auf Spatzen schießen.

Nicht nur das. Ich kenne es von GetText unter Linux so, dass man als Programmierer die (vorher zur Übersetzung markierten) Strings aus dem Quellcode extrahiert, diese für den/die Übersetzer in ein Template überführt (.pot) und dessen Ergebnis (.po) dann "kompiliert" in eine Binärdatei (.mo). Schwer vorstellbar, dass das mit der Delphi-Variante komplett anders läuft. Und Binärdateien will ich ja nicht.

Zitat:

Du setzt alle Beschriftungen also individuell zur Laufzeit. Das ist so banal, da traut man sich ja gar nicht, Dir das vorzuschlagen.

Doch, immer her damit. Manchmal kann man nicht einfach genug denken. Ich hatte ja selber schon daran herumgedacht, es mit einer Schleife über TForm.Components zu machen. Aber ich habe keine Idee, wie ich beim Auslesen eines INI-Eintrags und einer leeren Rückgabe (Komponentenname nicht in der Sprachdatei) unterscheiden soll, ob das ein String ist, der nicht übersetzt werden darf, oder ob dort stattdessen die Quellsprache benutzt werden soll. Für jede Komponente eine Zeile im Quelltext zu haben, ist auch irgendwie etwas ... doof viel Schreibarbeit.

Zitat:

Das sieht zwar dämlich aus, aber bei -sagen wir- < 20 Formularen ist der Zusatzaufwand wirklich nicht groß.

Momentan ist es nur ein einzelnes Formular, es kommen wahrscheinlich noch zwei weitere hinzu.

Zitat:

Wäre das nicht ein Anfang?

Ich muss das mal durchdenken und ggf. in einem Testprojekt anschauen. Aber dankeschön für den Denkanstoß!

MfG Dalai

[Namenloser]

Das, was Furtbichler vorschlägt, kann man auch mit der RTTI noch automatisieren. Allerdings ist das dann schon irgendwie das Rad neu erfinden. Ich kann mir einfach nicht vorstellen, dass es dafür nicht schon eine fertige (kostenlose) Lösung da draußen gibt.

[dummzeuch]

Rein theoretisch koennte man auch die Unit GnuGetText.pas so abaendern, dass sie statt auf .mo-Dateien direkt auf .po-Dateien zugreift. Das dxGetText-Projekt enthaelt entsprechende Sourcen zum Zugriff. Dann koennten Deine Anwender mit PoEdit oder Gorm (den ich uebrigens sehr empfehlen kann) einfach die .po-Dateien editieren.

Das wuerde Dir den aufwaendigen Parsing-Code fuer Komponenten ersparen. Aber es gibt bestimmt einfachere Loesungen. Ich bin aber ein ziemlicher Fan von dxGetText.

"I liked the shaver so much, I bought the company" -- Victor Kiam