Projektübersetzung mittels Ressource Dlls

[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.