Internationalisierung I18N

[Uwe Raabe]

Es gibt sicher einige Möglichkeiten - auch unter D7. Ich verwende dafür schon seit Jahren erfolgreich den Localizer.

[ibp]

Zitat von Uwe Raabe:

Es gibt sicher einige Möglichkeiten - auch unter D7. Ich verwende dafür schon seit Jahren erfolgreich den Localizer.

das sieht ja schon mal nicht schlecht aus. Welche Konsequenzen hat das für den Programmcode, hard coded texts? Wie werden Komponenten anderer Anbieter unterstützt? Was sind da deine Erfahrungen?


@Bernhard: Im Prinzip hast du ja recht aber... den Aufwand bezahlt mir keiner, da er für die meisten Nutzer nicht relevant ist und wenn der Auftrag kommt die Umsetzung auf Russisch relativ schnell erfolgen muss. Des weiteren möchte ich nicht einen totale Umstrukturierung mit neuen Komponenten haben, da das eben ein hohes Maß an Testaufwand nach sich zieht. Wie gesagt, bei diesem Projekt sind Internationalisierungen immer gesondert zu betrachten wenn diese gefordert werden, da eben die Daten in der Datenbank ebenfalls übersetzt werden müssen.

[stahli]

Ich habe mir tsilang für diese Zwecke vorgemerkt, aber bisher keinerlei Erfahrungen damit.
Der Localizer scheint sehr ähnlich zu sein.

[Uwe Raabe]

Zitat von ibp:

das sieht ja schon mal nicht schlecht aus. Welche Konsequenzen hat das für den Programmcode, hard coded texts? Wie werden Komponenten anderer Anbieter unterstützt? Was sind da deine Erfahrungen?

Dein eigener Programmcode bleibt, bis auf das Einbinden von ein paar DCUs unverändert - solange deine "hard coded texts" als resourcestring vorliegen. Sollte das nicht so sein, bietet der Localizer auch einen Wizard, der das für dich im gesamten Projekt erledigt.

Bei Fremdkomponenten muss man manchmal Hand anlegen, damit ein paar Properties mit in die Übersetzung aufgenommen werden. Das hält sich aber in Grenzen. Die üblichen Verdächtigen werden bereits von Haus aus verarbeitet.

[mquadrat]

Für Russisch braucht man doch Unicode oder nicht? Das bedeutet doch, dass in D7 auch die Komponenten getauscht werden müssten, oder?

[Bernhard Geyer]

Zitat von mquadrat:

Für Russisch braucht man doch Unicode oder nicht? Das bedeutet doch, dass in D7 auch die Komponenten getauscht werden müssten, oder?

Auf einem Russischen Windows kannst du für Russische Texte mit D7 arbeiten. Dort siehst du dafür keine deutschen Umlaute.
Und ebenfalls werden nur die "untere" Hälfte der kyrilischen Zeichen unterstützt. Alles im Bereich $0480...$04FF geht damit nicht.

[GHorn]

Ich habe das so gemacht:

a) Unicode Entwicklungsumgebung
b) Unicode DB
c) Alle Texte eines Formulars bzw. deren Komponentenbeschriftungen in einem kleinen Tool abklappern und in der DB (in Deutsch) speichern. Parallel dazu einen weiteren Datensatz in Englisch. Damit sind die Vorlagen vorhanden. Den englischen Teil übersetze ich selbst - die anderen frei zu erstellenden Sprachen übersetzt der Anwender selber

Für das Übersetzen gibt's im Programm integriert eine entsprechende Bearbeitungsmaske. Wenn der Anwender also z.B. ins Russische übersetzen will, erstellt er einen neuen Spracheintrag (z.B. RU), wählt eine Sprachvorlage aus, die er versteht (meistens Englisch) und gibt die russischen Begriffe ein. Im Konfigurationsmenü stellt er "seine" Sprache ein. Das Programm ersetzt dann beim Öffnen der jeweiligen Form die deutschen Texte mit den russischen aus der DB.

Hoffe, es ist halbwegs verständlich beschrieben.

Das ist zwar anfangs mit Aufwand verbunden, erspart mir aber die Übersetzungsarbeit bzw. den Übersetzer...

[Namenloser]

Ich habe für ein kleineres Projekt schon erfolgreich dxGetText eingesetzt. Vorteil: Es basiert auf GnuGetText und hat somit eine recht breite Unterstützung.

Übersetzungen können in einem extra Ordner abgelegt und zur Laufzeit geladen werden oder direkt in die Exe eingebettet werden. Zusätzliche DLLs und Co. sind nicht erforderlich.