Ü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:

Zitat von Furtbichler (Beitrag 1253519)

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. :thumb:

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

[Dalai]

Zitat:

Zitat von Furtbichler (Beitrag 1253590)

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

[Furtbichler]

Leute bei einem Formular und vielleicht 20 Texten würde ich noch nicht einmal drüber nachdenken, irgend etwas anzupassen. Einfach die Texte, die man übersetzen will, nach meinem Vorschlag einlesen. Wer will, kann noch folgende Funktion verwenden:

Delphi-Quellcode:

Function Translate (string aKey, aDefault : String) : String;
begin
  Result := Translations.Values[aKey];
  if Result='' then Result := aDefault;
End;

Dann schreibt man einfach:

Delphi-Quellcode:

...
  MyLabel.Caption := Translate('MyLabel',MayLabel.Caption);
...

D.h. man übergibt einfach der 'Translate'-Funktion einfach den aktuellen Wert. Wenn nun -aus welchem Grund auch immer- der übersetzte Text nicht vorhanden ist, wird wenigstens der Originaltext verwendet.

Klar, kann man alles verbessern, automatisieren, per RTTI automatisch erstellen, aber wie schon gesagt: Bei 1-2 Formularen absoluter Overkill. Oder Spielerei.

[Namenloser]

Hier mal ein RTTI-Beispiel, basierend auf einem alten Testprojekt von mir von 2006. Sollte sich recht leicht für deine Zwecke anpassen lassen.

(Analog zu GetPropValue gibt es auch SetPropValue.)

[Dalai]

So, die Programmierung hat etwas länger gedauert, als ich gehofft hatte. Naja, wie immer eigentlich ;).

Ich hab mich für die einfache Methode von Furtbichler entschieden :thumb:. Ich hab die Funktion ähnlich umgesetzt:

Delphi-Quellcode:

unit Translation;

interface

uses Classes, SysUtils, IniFiles;

const
    CRLF = #13#10;

procedure CreateLangFile(const AFileName: string);
procedure FreeLangFile;
procedure ReadLangFileSection(const ASection: string);
function Translate(const AName: string; const ADefault: string): string;

implementation

var hLangFile  : TIniFile;
    sl: TStringList;

procedure CreateLangFile(const AFileName: string);
begin
    hLangFile:= TIniFile.Create(AFileName);
    sl:= TStringList.Create;
end;

procedure FreeLangFile;
begin
    if Assigned(hLangFile) then
        hLangFile.Free;
    if Assigned(sl) then
        sl.Free;
end;

procedure ReadLangFileSection(const ASection: string);
begin
    if Assigned(sl) then
        hLangFile.ReadSectionValues(ASection, sl);
end;

function GetLangString(const AName: string; const ADefault: string; const Asl: TStringList): string;
var idx: integer;
begin
    Result:= ADefault;
    idx:= Asl.IndexOfName(AName);
    if (idx <> -1) then
    begin
        Result:= Asl.Values[Asl.Names[idx]];
    end;
    Result:= StringReplace(Result, '\n', CRLF, [rfReplaceAll]);
end;

function Translate(const AName: string; const ADefault: string): string;
begin
    Result:= GetLangString(AName, ADefault, sl);
end;

Zum Abrufen der übersetzten Strings dann einfach:

Delphi-Quellcode:

Translation.CreateLangFile('C:\full\path\to\German.lng');
...
Translation.ReadLangFileSection(Self.Name);
Self.Caption:= Translate(Self.Name, 'Properties of %s');
btnOK.Caption:= Translate(btnOK.Name, btnOK.Caption);
...
Translation.FreeLangFile;

Genaugenommen müsste man das objektorientiert umsetzen, aber dazu fehlte mir gestern echt der Nerv. Mal sehen, vielleicht mach ich das noch, sofern es sich lohnt.

Danke auch an Namenloser für die Anregung mittels RTTI. Nette Methode, aber so kann ich nicht steuern, welche Strings nicht übersetzt werden dürfen. Oder man müsste dafür mehr Aufwand treiben, indem man sich genau überlegt, wann man die Übersetzung durchführt - was durchaus schwierig wird, wenn bestimmte Strings nur bei Bedarf genutzt werden.

MfG Dalai