Delphi Anwendung internationalisieren / Lokalisierungs Toolkits

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

2022-10-25 11_49_02-LANGUAGE EDITOR.jpg