Russische Übersetzung funktioniert nicht auf rus. Windows

[H4ndy]

Hallo,

Ich hab wiedermal ein Problem mit der leidigen Übersetzungsproblematik mit nicht-westlichen Charsets.

Aufgrund von technischen Einschränkungen und einem riesigen Umfang, ist es uns im Moment leider nicht möglich, auf das neue Delphi mit UTF-8-Support bzw. auf UTF-8-enabled controls umzusteigen. Ich benötige also eine Lösung, welche irgendwie mit Bordmitteln funktioniert. Umgebung ist Delphi 7 Professional.

Folgendes Problem tritt bei uns auf.
Wir haben unsere Software von einem russischen Übersetzungbüro übersetzen lassen, was auch reibungslos funktioniert. Die Übersetzung läuft problemlos auf einem westlichen Windowssytem, welches über die Regions- und Sprachoptionen auf russisch gestellt wurde. Folgender Test ergibt das gewünschte Bild, wo mittels der Charset-Optionen gearbeitet wurde:

http://imghost.glorp.de/i/f8fcd2164c14.png
(Kompiliert auf dt. WinXP, EXE-Sprache ist Englisch (USA), Sprachoption auf Russisch ("für nicht UTF-8-Anwendungen"))

Starte ich nun die selbe EXE auf einem englischen XP funktioniert alles genauso.
Zu Problemen kommt es nun auf einem richtigen, komplett russischen XP:

http://imghost.glorp.de/i/a6cb486ebee0.png
(Selbe EXE wie oben auf einem RUS XP Pro SP3)

Unsere Sprachdaten enthalten auf einem deutschen System den Zeichensalat wie auf dem oberen Screenshot zu sehen, auf dem russischen System werden die Texte aber im Win-Editor korrekt kyrillisch angezeigt und "wie gewohnt" die deutschen Umlaute nicht dargestellt.

Wir vermuten einen Codepage-Dreher oder irgendsoetwas im Bereich der Fonts in Windows. Unsere Anwendung benutzt Tahoma programmweit, welche über ParentFont := True an alle Tochtercontrols vererbt wird. Andere Fonts, welche von einem deutschen XP kopiert wurden funktionieren auch nicht. Bisherige Suche war in dem Bereich leider sehr ernüchternt :/

Vielleicht hatte ja schonmal jemand dieses Problem.

Grüße,
Manuel

[Der Jan]

Hallo,

liegt es vielleicht am Font selbst? Ich habe schon mehrere Anwendungen ins russische übersetzt (ohne Unicode) und hatte noch nie Probleme. allerdings verwende ich MS Sans Serif.

[Bernhard Geyer]

Zitat:

Zitat von Der Jan

Hallo,

liegt es vielleicht am Font selbst? Ich habe schon mehrere Anwendungen ins russische übersetzt (ohne Unicode) und hatte noch nie Probleme. allerdings verwende ich MS Sans Serif.

Wenn ein Font die Zeichen nicht beinhaltet dann kommen entweder leere Kästchen raus oder schmale striche.

@H4ndy:
Kannst du die Anwendung mal auf einem russischen System kompilieren was dann passiert?

[H4ndy]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von Der Jan

Hallo,

liegt es vielleicht am Font selbst? Ich habe schon mehrere Anwendungen ins russische übersetzt (ohne Unicode) und hatte noch nie Probleme. allerdings verwende ich MS Sans Serif.

Wenn ein Font die Zeichen nicht beinhaltet dann kommen entweder leere Kästchen raus oder schmale striche.

@H4ndy:
Kannst du die Anwendung mal auf einem russischen System kompilieren was dann passiert?

Wie gesagt, wir haben schon verschiedenste Schriftarten ausprobiert.

@Bernhard:
Ich installiere Delphi gerade, und probier es dann aus. Soll ich irgendwas spezielles im Projekt einstellen?

[Bernhard Geyer]

Zitat:

Zitat von H4ndy

@Bernhard:
Ich installiere Delphi gerade, und probier es dann aus. Soll ich irgendwas spezielles im Projekt einstellen?

ist mir nur gerade eingefallen das teilweise irgendwelche CP-Einstellungen beim Kompilieren gemerkt werden.
Ansonsten bin ich Codepage-Free da ich mit D6 (fast) alles nach Unicode gebracht habe.

[H4ndy]

Habe jetzt die Software in unserem englischen Delphi unter dem russischen XP zum laufen gebracht.
Das Problem ist, dass Delphi das Russisch schon beim einlesen bzw. reinkopieren kaputt macht.

Aus "Çàãðóçèòü çàïèñü..." (auf einem "deutsch-russisch"-System dann korrekt: "Загрузить запись...") wird dann z.B. "Caa?oceou caienu..." (welches auf dem rus. System genauso ausgegeben wird).
Sieht so aus, als ob da die hohen ANSI-Zeichen einfach weggeschnitten oder gedreht werden.

[Bernhard Geyer]

Häng mal einen Auszug deiner Sprachdaten/dateien an diesen Thread an.

[Sherlock]

Mit welcher Software übersetzt Du eigentlich?

Sherlock

[H4ndy]

Zitat:

Zitat von Sherlock

Mit welcher Software übersetzt Du eigentlich?

Wir benutzen ein eigenes Tool dazu, welches als Komponente aufs Formular geklickt wird und seine Resourcen in der DFM ablegt.
Die aktuelle Sprache wird im Prinzip in den Controls abgelegt und die anderen speichert die Komponente.

Zitat:

Zitat von Bernhard Geyer

Häng mal einen Auszug deiner Sprachdaten/dateien an diesen Thread an.

Komplett darf ich das leider nicht, habe hier aber mal drei Auszüge. Der Export erfolgte aus Delphi heraus.

Export_DE: Export von Englisch und Russisch auf einem deutschen XP
Export_RUS: Export von Englisch und Russisch auf einem russischen XP
Export_DE_Import_RUS_Export_RUS: Import des deutschen Sprachfiles im russischen Windows, danach Export auf dem russischen Windows.

Das letzte wäre im Moment ein möglicher Workaround, da es so auf dem russischen System funktioniert.
Also ich exportiere die Sprachdateien auf dem deutschen XP und importiere diese im russischen XP.
Dann geht die russische Sprache auf dem russischen System, allerdings nirgendwo anders mehr (auch nicht "deutsch-russisch", es werden "?" angezeigt). Kann aber auch keine Dauerlösung sein.

Beim Import scheint die Konvertierung von Delphi nicht zu greifen und es funktioniert so (der erneute Export dann aus dem russischen System erzeugt eine Byte-gleiche Kopie des deutschen Exports).

Das Verhalten ist echt merkwürdig, hängt vielleicht mit dem DFM-Einlesen zusammen, obwohl die ja angeblich in UTF-8 vorliegt.

[Sherlock]

Also ist das Problem tatsächlich, daß die Übersetzung zum Compilezeitpunkt vorliegen mus, und hineinkompiliert wird. Es wird also kein Resourcestring im fertigen Kompilat ausgetauscht. Das dürfte dann auch der Kern des Problems sein, weil eben beim Compilieren die momentane Umgebung Einfluss hat.

Vielleicht habe ich das Verfahren auch missverstanden, aber so wie Du es schilderst scheint es unpraktisch.

Sherlock

[H4ndy]

Zitat:

Zitat von Sherlock

Also ist das Problem tatsächlich, daß die Übersetzung zum Compilezeitpunkt vorliegen mus, und hineinkompiliert wird. Es wird also kein Resourcestring im fertigen Kompilat ausgetauscht. Das dürfte dann auch der Kern des Problems sein, weil eben beim Compilieren die momentane Umgebung Einfluss hat.

Vielleicht habe ich das Verfahren auch missverstanden, aber so wie Du es schilderst scheint es unpraktisch.

Richtig, mit der Komponente kann man auch zur Laufzeit live die Sprache umschalten ohne Probleme. Die entsprechenden Strings sind eben innerhalb der Komponente gespeichert und liegen somit in der DFM (Das Format ist was eigenes und wird in der Text-DFM als Hex-Block gespeichert).
Und das funktioniert eben auch, außer auf dem richtigen russischen System, wo es eben den Text zerstört.

[H4ndy]

Ich habe der Sache noch ein bisschen hinterher debuggt. Ich hab mir mal den TReader.ReadWideString angeguckt. In der DFM steht ein UTF8 String. Der TReader ließt dann und macht ruft UTF8Decode. Innerhalb dieser Funktion wird irgendwann mal auf WideChar gecastet. Vorher ist auf beiden Systemen das Zeichen identisch. Nach dem Typecast kommt auf beiden Systemen etwas unterschiedliches raus, sodass der String kaputt geht.

Hat vllt jemand dieses Phänomen schonmal beobachtet/gefixt bekommen?

[Ydobon]

Das könnte jemand, der für Unicode Werbung machen will, vermutlich gut als abschreckendes Beispiel verwenden.

UTF8Decode müsste aus der UTF8-Kodierung wieder UCS2 bzw. einen Widestring machen, der sich auf den Systemen eigentlich nicht unterscheiden kann, da es mit den lokalen Einstellungen gar nichts zu tun hat. Wenn dieser danach aber einem Ansistring zugewiesen wird, bastelt Delphi automatisch Aufrufe von WideCharToMultiByte mit der aktuellen Codepage ein, die Ergebnisse unterscheiden sich dann.

Irgendwie sieht es so aus, als würde die Ansibytefolge als Unicode angenommen und zur kyrillischen Codepage konvertiert.
1. Загрузить (04170430043304400443043704380442044C)
2. Çàãðóçèòü (C7E0E3F0F3E7E8F2FC)
3. Caa?oceou (4361613F6F63656F75)

Für das Wort wäre 2. die richtige Bytefolge, als Latin 1 kommen die schönen Diakritika raus, ein russischer Rechner zeigt es richtig an. Nr. 3 wäre halt das Ergebnis, wenn man noch einmal konvertiert.

Eigentlich sollte sich die Komponente das UTF8 aus der DFM holen, in einen Widestring dekodieren und an einen Ansistring übergeben, wobei die Konvertierung entsprechend den Systemeinstellungen automatisch erfolgt. Da dürfte nicht viel passieren können.

Kann es sein, dass schon das falsche UTF8 gespeichert wird? Richtig wäre:
ЗагруЕить (D097D0B0D0B3D180D183D0B7D0B8D182D18C)
Çà ãðóçèòü (C387C3A0C3A3C3B0C3B3C3A7C3A8C3B2C3BC) sollte es nicht sein

[H4ndy]

@Ydobon: Genauso scheint es eben zu sein.

Wir konnten aber jetzt erfolgreich einen Workaround für das Problem erstellen.
Die angehängt Unit muss einfach als erste Unit im Projekt ge-used werden (am besten in der DPR), danach sollte das Problem behoben sein.

Wurde bisher nur mit Russisch getestet, könnte aber auch mit anderen Sprachen funktionieren, die eine nicht-western Codepage benutzen.

Nochmals Danke an alle, die geholfen haben, das Problem einzugrenzen.