Delphi Anwendung internationalisieren / Lokalisierungs Toolkits

[Uwe Raabe]

Hassen ist jetzt der falsche Begriff. Aus eigener Erfahrung kann ich nur sagen, dass sie im Vergleich zu einigen anderen Tools sehr viel schwerfälliger zu bedienen sind und in kaum mehr als "Hello World" Applikationen schnell überfordert sind. Sie werden auch seit geraumer Zeit etwas stiefmütterlich behandelt, weil die Kapazitäten dafür einfach nicht vorhanden sind. Ich persönlich sehe einfach die Gefahr, dass sie in naher bis mittlerer Zukunft durch eine andere Lösung (evtl. einen Zukauf) ersetzt oder einfach abgeschafft werden.

Im Laufe der Zeit habe ich schon einige Lösungen eingesetzt, darunter sowohl die bordeigenen als auch DxGetText. Einige davon gibt es schon lange nicht mehr.

Der Korzh Localizer ist bei mir nun schon seit 2001 im Einsatz. Es mag mittlerweile durchaus bessere Alternativen geben, aber ich habe ihn mithilfe eigener Tools eng in meinen Entwicklungsprozess eingebunden und er liefert immer noch alles was ich benötige. Ergänzungen und Anpassungen von Übersetzungen sind weitestgehend automatisiert und erfordern nur einen geringen manuellen Aufwand. Obwohl ich mir immer wieder neue oder andere Lösungen anschaue, rechtfertigen bislang die eventuellen Vorteile nicht den erforderlichen Wechselaufwand. Aber jeder hat da sicher seine eigene Umgebung, in der das durchaus anders bewertet werden kann.

[MyRealName]

Ich hatte mir mal eine Komponente dazu geschrieben, die ein eigenes Dateiformat dazu genutzt hat (ein Format für SQL und Sprache, ein anderes f+r Binärdateien). Komponente hat man auf das Formular gelegt und dann im eigenen Editor Captions etc der GUI Elemente mit ID's verbunden. Da konnte man dann zur Laufzeit die Sprache der Anwendung wechseln und hat in allen offenen Forms eine nachricht bekommen über ein Event und konnte zu den Standart-Sachen auch unbeaknnte Komponenten umstellen auf die neue Sprache.
Das war auch garnicht so schwer selbst zu bauen.

[Redeemer]

Ja gut, die haben ein paar Seltsamkeiten, aber ich habe mir dann ein paar Tools gebaut und seitdem geht das eigentlich auch mit großen Projekten sehr gut. Nur sowas wie ListView- und TreeView-Standardeinträge kriegen die nicht hin, aber das dürfte auch kein Tool schaffen bei dem Blödsinn, den Delphi in der DFM speichert.

[MyRealName]

Man sollte sowas eh nicht in der DFM speichern, weil Du neu compilieren musst, um etwas hinzuzufügen und es ist nicht so einfach suchbar.

[Redeemer]

Mach ich auch nicht. Mein größtes Problem mit den Delphi-Lokalisierungstools ist der Bug, dass es sich regelmäßig selbst die XMLs zerschießt, indem es vergisst, den Wert für das Attribut "id" zu schreiben. Kopiert man dann von dem einzigen anderen Attribut des fehlerhaften Tags und dann geht es auch wieder.

Ich hab mir dann ein Tool erstellt, das zusammen mit ResHacker aus den Kompilaten eine lokalisierte EXE baut. Ich brauche dann keinen Code schreiben und das Programm besteht weiterhin für alle User nur aus einer einzigen EXE. Bei solider Komprimierung wird das Projekt bleiben die verschiedenen EXEn im Installer auch schön klein.

[philipp.hofmann]

Ich mache es auch ähnlich wie MyRealName, jedes Element hat eine ID für den Text und eine ID für den Hint und diese habe ich in einer extra Datei abgespeichert, die für jede Sprache vorliegt und der Kunde kann on-the-fly die Sprache wechseln (was jetzt mehr für mich beim Testen bzw. dokumentieren ein interessantes Feature ist und ich kann die Datei auch on-the-fly austauschen). Ich habe es übrigens so gebaut, dass ich auch die Sprache XX auswählen kann und dann werden mir die IDs an allen Elementen angezeigt, so dass man auch relativ schnell als Nicht-Programmierer herausfinden kann, auf welche ID man hier gerade schaut.

Das ganze war keine 4 Stunden Arbeit an Programmierung, die Hauptarbeit geht auf die Übersetzung an sich drauf.

[Bbommel]

Zitat von dummzeuch:

Ich/mein Team verwenden DxGetttext + Gorm als Editor für po-Dateien.

Aber das ist nur was für Win32-Programme. Sobald man Win64 (habe ich nicht getestet) oder sonstige Plattformen unterstützen will, funktioniert das nicht mehr.

Ich nutze die von dir gepflegte gnugettext.pas auch in Win64-VCL-Programmen - funktioniert auch damit völlig problemlos.

Für Linux musste ich etwas an der gnugettext.pas rumbasteln, einige Funktionen rausschmeißen oder "lahmlegen". Aber das, was ich in dem Fall noch brauche (im Wesentlichen ist das bei einem WebBroker-Projekt dann der Aufruf der Funktion "_", um übersetzte Texte zu holen und an den Client zu senden), funktioniert letztlich auch unter Linux problemlos - hat mich selber etwas überrascht.

Falls mal Lust und Zeit ist, können wir auch gerne mal zusammen versuchen, diese etwas rabiaten Änderungen von mir ordentlich zu machen und in IFDEFs zu überführen, um sie dann so ins Repository aufzunehmen und der Allgemeinheit zur Verfügung zu stellen.

[dummzeuch]

Zitat von Bbommel:

Zitat von dummzeuch:

Ich/mein Team verwenden DxGetttext + Gorm als Editor für po-Dateien.

Aber das ist nur was für Win32-Programme. Sobald man Win64 (habe ich nicht getestet) oder sonstige Plattformen unterstützen will, funktioniert das nicht mehr.

Ich nutze die von dir gepflegte gnugettext.pas auch in Win64-VCL-Programmen - funktioniert auch damit völlig problemlos.

Für Linux musste ich etwas an der gnugettext.pas rumbasteln, einige Funktionen rausschmeißen oder "lahmlegen". Aber das, was ich in dem Fall noch brauche (im Wesentlichen ist das bei einem WebBroker-Projekt dann der Aufruf der Funktion "_", um übersetzte Texte zu holen und an den Client zu senden), funktioniert letztlich auch unter Linux problemlos - hat mich selber etwas überrascht.

Falls mal Lust und Zeit ist, können wir auch gerne mal zusammen versuchen, diese etwas rabiaten Änderungen von mir ordentlich zu machen und in IFDEFs zu überführen, um sie dann so ins Repository aufzunehmen und der Allgemeinheit zur Verfügung zu stellen.

Das mit der Zeit ist immer so eine Sache... Aber Du könntest mir mal Deine Version zukommen lassen, vielleicht sind die Unterschiede ja gar nicht so groß und man braucht nur ein paar IFDEFS drübersprenkeln. Ich kann das aber für Linux nicht testen. Für Win64 könnte ich testen, ob es compiliert, zu testen, ob es funktioniert, ist dann schon wieder zeitaufwändiger.

[Bbommel]

Zitat von dummzeuch:

Das mit der Zeit ist immer so eine Sache... Aber Du könntest mir mal Deine Version zukommen lassen, vielleicht sind die Unterschiede ja gar nicht so groß und man braucht nur ein paar IFDEFS drübersprenkeln. Ich kann das aber für Linux nicht testen. Für Win64 könnte ich testen, ob es compiliert, zu testen, ob es funktioniert, ist dann schon wieder zeitaufwändiger.

Bei mir ist in dieser Woche die Zeit auch etwas knapp, weil ich noch ein Projekt halbwegs fertig bekommen will. Aber ich habe mir mal eine Erinnerung in den Kalender eingetragen, damit ich das mal in Ruhe aufbereiten kann (du musst ja nicht Dinge aufbereiten, die ich mir vorher selber schon anschauen kann) und melde mich dann per Mail bei dir.

[BigAl]

Da ich Anwendungen schreibe die weltweit im Einsatz sind mache ich die Lokalisierung seit über 20 Jahren selbst. Die Texte sind dabei in einer Datenbank gespeichert. Meist MSSQL aber z.T. auch in AbsoluteDB wenn keine größere Datenbank erforderlich ist. Dafür habe ich mir auch verschiedene Tools geschrieben für export und import von Übersetzungen, da wir diese meist von den Kunden machen lassen (Ich kann weder chinesisch noch ...). An der Oberfläche nutze ich die TAG-Eigenschaft. Ist ein Tag = 1, dann wird der entsprechende Text beim Laden des Formulars übersetzt. Weiterhin habe ich eine globale Umschaltung für Fettschrift implementiert, da diese je nach Sprache (Zeichensatz) anpassbar sein sollte. Das mache ich dann mit Tag = 1 oder Tag = 2.

In der Datenbank habe ich dann z.B. folgende Felder:

LangID (Sprachkennung)
Part (z.B. der Form-Name oder aber auch GLOBAL für globale Texte, ALARM für Alarmtexte etc.)
Entry (z.B. der Name der Komponente oder aber auch sonstige Kennungen wie "ALARM0001" oder "strYes")
Text (der zur Sprachkennung passende Text)

Ich habe auch einen Standarddialog erstellt, der es dem Endkunden erlaubt Texte zur Laufzeit anzupassen. Das ist erforderlich, da oftmals die Übersetzung vom Kontext abhängt.

Geladen wird immer ein kompletter Part. Es ist also für die Übersetzung eines kompletten Forms (Dialog...) nur ein SQL-Zugriff erforderlich.

Das ganze geht ohne merkliche Verzögerung und läuft sehr zuverlässig. Ich schreibe das, da ich mich über die Jahre - bis auf ein paar Ausnahmen - von gekauften Bibliotheken unabhängig gemacht habe. In der Vergangenheit wurden leider immer wieder tolle Komponenten vom Markt genommen.

Soviel vielleicht mal als Anreiz sowas "zu Fuß" zu machen.

Der Spracheditor präsentiert sich z.B. so: