Russische Übersetzung funktioniert nicht auf rus. Windows

[H4ndy]

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.