Projektübersetzung mittels Ressource Dlls

[Der schöne Günther]

Embarcaderos Docwiki schreibt erfreulich viel zur Lokalisierung von Anwendungen:
http://docwiki.embarcadero.com/RADSt...ications_Index

Der von Embarcadero vorgeschlagene Weg scheint zu sein:

• Benutzung der im RAD Studio eingebauten Funktionalität unter Projekt -> Sprachen
• Hier wird für jede "Sprache" eine Kopie von DFMs und in .pas-Dateien gefundenen resourcestrings angelegt
• Welche man dann von Hand bearbeiten kann
• Für jede Sprache wird dann ein eigenes Projekt angelegt welche beim Kompilieren eine "Ressource Dll" ausspuckt.
• Diese dll soll man ins Arbeitsverzeichnis der Anwendung legen. Beim Programmstart würde es sich automatisch die am besten passende Sprache suchen und einladen. Alternativ könnte man über Registry-Einträge steuern, welche Sprache geladen werden soll

Ich glaube es zwar verstanden zu haben, bekomme es aber nicht ans Laufen. Um meinem Erzählfluss vorwegzugreifen: Ich habe eine ganz konkrete Frage.

Lohnt es sich diesen Weg weiter zu gehen oder gibt es bessere Lösungen?

Embarcaderos Weg, die DFMs hier anzufassen macht mir schon einmal Angst. Das riecht bei Drittanbieter-Komponenten wie TeeChart und FastReport irgendwie schon stark nach unvorhersehbaren Problemen...


Man findet natürlich schnell Drittanbieter welche ihre eigenen Lösungen vorstellen. Gefunden und noch nicht näher angesehen habe ich

• http://devtools.korzh.com/localizer/
• http://www.tsilang.com/press/en/tsil...d_rad_php.html
• http://www.sisulizer.com/
• http://dxgettext.po.dk/ (Danke an Bernhard Geyer)

Ich habe übrigens Null Erfahrung was die technische Umsetzung von einer Oberflächen-Übersetzung angeht. Deshalb würde ich mich über Erfahrungsberichte und Leidensgeschichten sehr freuen

[Bernhard Geyer]

Wir verwenden den GNU GetText-Ansatz (http://dxgettext.po.dk/) und sind zufrieden damit.
Einzig RTL-Sprachen unterstützen wir vom Formulardesign nicht.

[kretabiker]

Ohne zu sehr ins Detail gehen zu wollen: Mit der integrierten ITE ist es ein Weg der Leiden. Bei kleineren Projekten mag es noch gehen, aber ich habe mal vor einigen Jahren versucht, damit eine meiner großen Applikationen (> 200 Dialoge/Formulare, diverse Fremdkompos) mehrsprachig aufzubauen, das ging gar nicht. Wobei nicht das Übersetzen der Ressorucen pro Form ansich ein Problem war, auch mit Fremdkompos wie TMS oder FastReport (mit Hilfe dessen Supports) ging es, aber das Kompilieren der Sprachdateien dauerte ewig, das wahlweise Einbinden war kniffelig und es kam immer wieder zu dem seltsamen Effekt, dass die übersetzten Ressouren an falschen Stellen dargestellt wurden. Ich hab dann irgendwann aufgegeben und die Übersetzung verschoben und bis heute nicht gemacht...

Die drei von dir genannten Dritt-Lösungen sind wohl die bekanntesten, allerdings kenne ich keine davon aus eigener Anschauung.

[Sherlock]

Wir verwenden Sisulizer. Schönes, komfortables Tool, das mehr übersetzen kann als nur Exen.

Sherlock

[Dalai]

Vor einiger Zeit hatte ich auch mit diesem Thema zu tun: Übersetzung in andere Sprachen mit bestimmten Anforderungen.

MfG Dalai

[Headbucket]

Ich habe mich vor ein paar Wochen auch mehrere Tage mit dieser Thematik beschäftigt. Am Ende bin ich wieder bei der Übersetzung mit INI-Dateien gelandert, wie es bei einem großen Projekt von uns bisher auch gemacht wurde (>2500 Zeilen INI-Datei pro Sprache).

Ich habe mir zum einen den "Translation-Manager" von Delphi angeschaut mit welchem ich aber nicht so recht warm wurde.
Ebenso habe ich mir Programme wie "Localizer" usw. angeschaut.
Was mich hier gestört hat: Die Programme greifen zu tief ins System ein und für die Übersetzung werden extra Programme benötigt.

Wir arbeiten hier mit mehreren Leuten an einem Projekt, wobei es auch vorkommen kann, dass mal unterschiedliche Delphiversionen verwendet werden. Außerdem möchte ich nicht nur Texte übersetzen, die auf der Bedienoberfläche sind, sondern auch Dialoge usw. Außerdem kann es ja mal vorkommen, dass z.B. ein Button je nach Zustand verschiedene Beschriftungen hat. Diese Möglichkeit war mir beim delphieigenen Tool nicht direkt ersichtlich.

GetText habe ich mir ehrlich gesagt nur mal kurz angeschaut. Allerdings greift mir das auch schon fast zu tief in den Quellcode ein und man ist wieder irgendwo abhängig.
Was mir hier außerdem aufgefallen ist: Kann es sein, dass ein un derselbe deutsche Text bei GetText immer gleich übersetzt wird? Es kann ja auch sein, dass es z.B. im englischen mehrere Bezeichnungen gibt - im deutschen aber nur eine. Wie kann ich hier dann unterschieden?

Unsere Lösung deshalb bisher: Pro Sprache eine INI-Datei. Diese INI-Dateien kann man mit einem Zusatzprogramm parallel öffnen und ebenso parallel bearbeiten.
Durch ein paar Units im Projekt ist der Zugriff kinderleicht und wir kommen ohne externe Programme aus. Außerdem kann wirklich JEDER die Texte bearbeiten.

100% zufrieden bin ich damit trotzdem nicht, das gebe ich zu. Aber eine bessere Lösung habe ich bisher noch nicht entdeckt.

Gruß
Headbucket

[Uwe Raabe]

Mit der Delphi ITE hatte ich auch schon so meine Problemchen - obwohl immer mal wieder ausprobiert.

Mit dem Prinzip von DxGetText konnte ich mich auch nach mehreren Anläufen nicht so recht anfreunden. Andererseits ist das Ding kostenfrei.

Seit einigen Jahren verwende ich den Korzh Localizer. Wie wohl jedes System hat auch dieses seine kleinen Macken und Eigenheiten, aber ich komme für meine Zwecke ganz gut damit zurecht. Im Laufe der Zeit habe ich mir ein paar kleine Tools geschrieben, die einem die Arbeit insbesondere im automatischen Build etwas erleichtern.

Auch der Localizer arbeitet im Endeffekt mit dem Prinzip der Resourcen-DLLs, da dieser Mechanismus in Delphi halt auch schon implementiert ist. Damit halten sich die Eingriffe in das System und insbesondere in die Sourcen schon ziemlich in Grenzen. In der Standard-Version reicht es schon, die Sprach-DLLs neben die Exe zu legen. Wenn man die Systemsprache nicht will, setzt man einfach einen Registry-Eintrag. Bei der On-The-Fly-Version kann man die Sprache im laufenden Betrieb umstellen. Dabei werden die Sprach-Dlls dynamisch erzeugt und dann geladen. Das erfordert natürlich das einbinden der dazu nötigen Localizer-Units. Das Problem der kontextsensitiven Button-Captions löst man sinnvollerweise mit resourcestring über Actions in deren OnUpdate-Event (übrigens auch ohne das Übersetzungsproblem).

Wenn man im Programm eine Liste der verfügbaren Sprachen anzeigen bzw. eine daraus auswählen will, dann tut man sich mit dem Einbinden der entsprechenden Units auch einen Gefallen. Andernfalls müsste man die Liste selbst zusammenstellen bzw. den Registry-Eintrag selber setzen.

Zu TsiLang und Sisulizer kann ich nichts sagen.

[Der schöne Günther]

Vielen Dank für die Antworten bislang!

Zitat von Headbucket:

GetText habe ich mir ehrlich gesagt nur mal kurz angeschaut. Allerdings greift mir das auch schon fast zu tief in den Quellcode ein

Mehr als nur "Kurz anschauen" konnte ich bislang auch nicht, aber eigentlich sah es für mich bislang doch im Endeffekt sehr, sehr ähnlich zu "eurer" .ini-Lösung aus. Nur dass das Format etwas "standarisierter" ist (Übersetzungsbüros kommen damit direkt zurecht) und noch ein paar kleine Schlauheiten enthalten sind wie automatische Pluralbildung in verschiedenen Sprachen.

Ich werde hoffentlich heute noch mal ein Testprojekt wagen und dann auch erzählen können, wie das im Vergleich zu komplett selbst gestrickten .txt/.ini-Imports aussieht.

[Bentissimo]

Eine Überlegung wert sein dürfte auch die Precision Language Suite (http://www.be-precision.com/products/precision-langs/).

Bisher habe ich gute Erfahrungen damit gemacht und der Preis ist kein Hindernis.

[TiGü]

Bei uns auf Arbeit verwendet der Mensch für Dokumentation und Lokalisierung das Tool SDL Passolo:
http://www.sdl.com/de/products/sdl-passolo/

Wir übersetzen damit unsere VCL-Programme in bis zu acht Sprachen.
Was da als Dateiformat raus fällt scheint auch jede professionelle Übersetzungsagentur zu verstehen.