Delphi Anwendung internationalisieren / Lokalisierungs Toolkits

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

[Redeemer]

Warum hassen alle so die integrierten Übersetzungstools von Delphi?

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