Internationalisierung I18N

[ibp]

Hallo,

mal wieder ein neuer Anspruch für ein bestehendes Projekt. Das Programm soll in Russisch übersetzt werden, ggf könnten noch andere Sprachen hinzukommen. Die globale Bandbreite aller Sprachen soll aber nicht beachtet werden.

Je mehr man darüber liest desto mehr Arbeit sieht man darin. Nun muss ich abschätzen was dass für ein Aufwand ist, das bestehende Programm für den Kyrillischen Sprachgebrauch anzupassen.

Daher braucht es natürlich erstmal eine Taktik. Was das Programm nicht braucht ist eine Multi-Sprachunterstützung per Knopfdruck, da daran eine Datenbank hängt, die ebenfalls übersetzt werden muss. Auch eine extra Kompilierung für jede Sprache schließe ich aus.

Derzeit wird das Programm unter D7 gepflegt. Neben den Standardkomponenten kommen noch einige von TMS dazu. An dieser Struktur soll auch nichts geändert werden.

Mir wäre lieb, wenn jemand schon mal selber ein bestehendes Projekt internationalisiert hat und kurz über Vorteile/Nachteile referiert.

[Bernhard Geyer]

Am besten schaust du erstmal das du dein Programm anch D2009/2010/XE bringst. Damit ist schon mal die Grundlage für eine einfachere Internationalisierung gegeben. Unter D7 hättest du viel mehr Aufwand.

[ibp]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1096167)

Am besten schaust du erstmal das du dein Programm anch D2009/2010/XE bringst. Damit ist schon mal die Grundlage für eine einfachere Internationalisierung gegeben. Unter D7 hättest du viel mehr Aufwand.

Das Projekt bleibt erstmal unter D7. Der nächste Schritt der gegangen werden wird beginnt dann mit D64-Bit im 2. Jahr...

[Uwe Raabe]

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

[Bernhard Geyer]

Zitat:

Zitat von ibp (Beitrag 1096169)

Das Projekt bleibt erstmal unter D7. Der nächste Schritt der gegangen werden wird beginnt dann mit D64-Bit im 2. Jahr...

Um dann festzustellen das gar nix geht. Auch für D64-Bit steht die Anpassung an Unicode an. Und wenn du beitest auf einen schlag versuchtst wirst du sehr lange brauchen überhaupt unter D64-Bit kompilieren zu können.

Mit D7 und den meisten Komponenten wird dein Programm zwar unter der jeweiligen Landessprache korrekt laufen aber du wirst auf einem deutschen Windows das nicht kontrollieren können. Hierfür wäre ein ersatz aller Kompos durch Unicodefähige Controls wie Elpack oder TNTWare-Komponenten nötig. Ebenfalls wirst du einiges an Test + Umstellungsaufwand auf der DB-Schnittstelle haben so das du nicht versehentlich beim Betrachten von Daten und versehentlichen Speichern diese reihenweise "entunicodisierst".

Ich schlage folgendes vor wenn du mal auf 64-Bit umsteigen willst:

1, Aktualisieren der verwendeten Komponenten auf eine Version die auch D2009 und neuer unterstützt
2, Hochziehen der verwendeten IDE auf D2009 oder neuer mit herstellung der Kompilierbarkeit
3, Hochziehen auf eine 64-Bit IDE wenn verfügbar.

[ibp]

Zitat:

Zitat von Uwe Raabe (Beitrag 1096171)

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:

Zitat von ibp (Beitrag 1096178)

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

Delphi-Quellcode:

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:

Zitat von mquadrat (Beitrag 1096204)

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 8-)

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.

[FredlFesl]

TsiLang ist gut und nicht teuer. Externe Übersetzungstools, Sprachrepositories etc. alles schon dabei.