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

[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

Delphi-Quellcode:

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

Zitat:

Zitat von Headbucket (Beitrag 1276041)

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.

[Dejan Vu]

Schlechte Erfahrungen habe ich mit Systemen gemacht, die die EXE patchen, d.h. Resourcestrings austauschen, denn teilweise funktioniert das Ganze dann nicht mehr. Das waren zwar Einzelfälle, aber es ist mir wurscht. Einige meiner Programme waren darunter und damit war der Ansatz gestorben.

Die TSiLang-Suite ist recht brauchbar, da sie im Quelltext ansetzt. Man muss sich nur angewöhnen, Strings im Quelltext gleich als

Delphi-Quellcode:

VAR

oder

Delphi-Quellcode:

CONST x:String=...

anzulegen und den konkreten Text in der Initialisierung der Unit aus der Repository zu laden.

Delphi-Quellcode:

Procedure MyInit;
Begin
  myString := myTranslation.GetTextOrDefault('the default text of my string');

So oder ähnlich ging das. Die DFM wird automatisch übersetzt, bzw. werden die Strings gleich in die Repository zum Übersetzen genommen.

Legacy Code wird aber auch über einen rudimentären Parser konvertiert. Manchmal muss man selbst noch Hand anlegen, weil das Teil mit einer heißen Nadel gestrickt ist, aber alles zu verschmerzen. Beim Umstieg von der ITE auf TSiLang mit gefühlten 100 Units und Formularen hatte ich kaum Probleme. Nur die Übersetzung haben wir nochmal gemacht, aber der Kunde war dankbar und hat mitgeholfen.

Nie Probleme gehabt, ausgereifte Lösung. Das Übersetzerbüro kann Text-Dateien bekommen oder aber ein freies Tool, was die Übersetzungen gleich ins Binärformat packt. Echt praktisch. Umschalten der Sprache zur Laufzeit ist auch kein Problem, ein 'dazulernendes' Wörterbuch hat man auch, also was will man mehr?

"3x an der ITE verzweifelt" Ist vom Aufwand fast gleichzusetzen mit "TSiLang kaufen".

[dGeek]

Ich mache es komplett anders. Die Profis unter euch werden die Hände über dem Kopf zusammenschlagen ;)

Ich habe für jede Sprache eine Unit. In dieser Unit werden alle sichtbaren Texte (Captions usw.) durch die Übersetzung einer Sprache ersetzt.
In einer anderen Unit befinden sich Variablen, welche die jeweils zur Sprache passenden Strings enthalten (Dialogtexte usw.).

Auf diese Art und Weise brauche ich keine Tools von Drittanbietern oder anderen Quatsch.
Ich kann ebenfalls bestätigen, dass Projekte mit fast 100 Formularen/Dialogen so sehr einfach übersetzt werden können.

[Headbucket]

Zitat:

Zitat von Der schöne Günther (Beitrag 1276052)

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.

Vllt kannst du dieses Testprojekt ja auch mal hier zur Verfügung stellen. Dann würde ich es mir sicher auch nochmal anschauen.
Ich habe zwar auch noch mein Testprojekt zu Localizer da, aber das bringt ohne die zugehörigen Units leider nicht viel.

Was noch erwähnt werden muss und was wohl ein deutlicher Vorteil der ganzen professionellen Übersetzungstolls ist: Der Übersetzer kann sehen, wo die jeweiligen Texte auf der Form/dem Frame zu finden sind. Das war stets ein Kritikpunkt unseres Vertriebs bei unserer bisherigen Methode mit den INI-Dateien. Wir haben es jetzt vorübergehend so gelöst, dass wir eine Sprachdatei mit IDs erzeugen und der Übersetzer das Programm dann mit dieser Datei starten kann und sieht, wo welche Texte zu finden sind. Nicht ganz perfekt, aber zumindest erstmal eine Lösung.

Der Vollständigkeit halber hier nochmal drei Links zu dem Thema:
Grobe Übersicht von Möglichkeiten: http://www.del-net.com/delphi/delphimultilan.html
Translation-Manager: http://docwiki.embarcadero.com/RADSt...anager_-_Index
Top Übersetzungstools: http://delphi.about.com/od/toppicks/tp/aatplocalize.htm

Ich bin bei meiner damaligen Suche übrigens auf so viele Threads gestoßen, die alle zu 90% den selben Inhalt hatten. Hier hatte ich mir oft gedacht: "Wäre es nicht toll, wenn es irgendwo mal eine aktuelle Übersicht aller Möglichkeiten mit Vor-/Nachteilen und Beispielen gäbe?" Wenn also jemand von euch Ahnung davon hat und gerne Texte verfasst, so wäre das sicher eine große Bereicherung für das Forum. :thumb:

Grüße
Headbucket

[Der schöne Günther]

Zitat:

Zitat von Headbucket (Beitrag 1276109)

Vllt kannst du dieses Testprojekt ja auch mal hier zur Verfügung stellen.

Ich habe mir DxGetText nun einmal angesehen und etwas ganz kleines damit gebastelt. Mir geht es ähnlich wie dir- Die Delphi-Adaption von GetText bringt einen

Delphi-Quellcode:

TranslateComponents(..)

-Aufruf mit. Mir ist dieser Automatismus unsympathisch. Mir reicht es vollkommen wenn ich jemand habe, der meine Resource-Strings tauscht. Mehr möchte ich nicht.
Und das erledigt es fürs erste anscheinend mit Bravour. Das .po/.mo-Format ist anscheinend der de-facto-Standard für so etwas.

Auf den ersten Blick sieht es hervorragend aus :thumb:

Denn im Gegensatz zu einer Eigenlösung sehe ich schon einmal zwei gewaltige Vorteile

1. Ich kann im Quelltext einen Kommentar am Resourcenstring kleben lassen den der Übersetzer vollautomatisch in seiner Software bekommt. Beispielsweise Dinge wie "Lass das Leerzeichen am Ende um Gottes Willen stehen!". Das Bild im Anhang zeigt das recht gut.
2. Da steckt wohl noch einiges an Komfort unter der Haube. Automatische Pluralbildung in der jeweiligen Sprache hört sich für mich noch sehr interessant an.

Was ich nicht möchte, ist dass mir ein undurchsichtiger Automatismus alle Komponenten auf einem Formular/Frame anfasst und damit etwas anstellt. Wie gesagt, den gibt es. Aber nutzen muss man den nicht :-)


Bei Interesse einfach mal im Anhang wühlen :-)


PS: Ich sehe grade, das Archiv/Repo enthalten sinnigerweise nur die lesbaren .po-Dateien. Die muss man noch "kompilieren". Wenn du dafür jetzt keine Software wie (poEdit) installieren willst, nimm einfach http://po2mo.net/

Hört sich alles super kompliziert an. Im Endeffekt nutze ich nur den

Delphi-Quellcode:

UseLanguage(String)

-Aufruf der mir den Inhalt der Ressource-Strings tauscht. Mehr nicht.