japanische Sprache

[roderich]

Ich habe folgendes Problem:

Mein Programm ist mehrsprachig ausgelegt. Es funktionieren auch die europäischen Sprachen wie deutsch, englisch, spanisch, etc. problemlos. Zur Laufzeit werden den Controls Texte aus einer Sprachdatei zugewiesen, je nach Klasse die properties Caption, Hint, Text usw.

Nun habe ich japanisch dazugenommen, ein Japaner hat Texte übersetzt. Auf einem japanischen Windows sollten dann die Texte entsprechend sein. Nun habe ich aber das Problem, daß es bei einigen Controls klappt, bei anderen nicht. Z.B. klappt es bei TMenuItem, TButton oder TRadioButton. Es klappt nicht bei TGroupBox, TLabel oder TBitButton.

Was mir aufgefallen ist, daß die japanischen Texte in UniCode (2 Byte / Zeichen) gespeichert sind. Offensichtlich kommen einige Controls damit klar, andere nicht. Seltsamerweise ist TBitButton von TButton abgeleitet und verhält sich anders.

Jemand eine Idee ?!?

Roderich

[tommie-lie]

Unicode funktioniert generell nicht unter Win95 und 98 (bei ME weiß ich's nicht mehr). Bei den Systemen muss man sich den Microsoft Unicode Mapper runterladen. Deine Strings müssen alle als WideString deklariert sein, damit pro Zeichen 2 Byte benutzt werden.

Ansonsten hat Mike Lischke irgendwo mal Unicode-Komponenten für Delphi geschrieben. Die könntest du alternativ zu den Borland-Komponenten verwenden, ob die aber das Problem des fehlenden Mappers lösen, weiß ich nicht.

[roderich]

hi tommie-lie,

schon mal vielen Dank für die Hilfe. Ich werd's mal mit WideString probieren. Auf dem Japaner-Rechner läuft Windows XP.
Komisch ist nur trotzdem, daß einige Controls ihre Caption richtig setzen - als ob sie in SetCaption erkennen, daß der String einen UniCode-String darstellt. In NotePad sehe ich in den Strings immer abwechselnd eine Art Lo-Character und einen Hi-Character.

erst mal vielen Dank
Roderich

[tommie-lie]

Zitat von roderich:

Komisch ist nur trotzdem, daß einige Controls ihre Caption richtig setzen - als ob sie in SetCaption erkennen, daß der String einen UniCode-String darstellt.

Das finde ich auch seltsam. Ich weiß zwar nicht, wie du deine Sprachdateien einliest, aber wenn du es beispielsweise mit 'nem Filestream machst und in einen "normalen" String einliest, sollte das eigentlich sowieso nix werden...

Zitat:

In NotePad sehe ich in den Strings immer abwechselnd eine Art Lo-Character und einen Hi-Character.

Jupp, weil für das deutsche Notepad ein Zeichen ein Byte lang ist. Da bei Unicode es immer zwei Byte sind, zeigt er jedes getrennt an. In einem Hexeditor solltest du erkennen, daß bei Zeichen, die noch in die ASCII/ANSI-Tabelle passen, das zweite Byte immer 00h ist und das erste Byte den ANSI-Wert des Zeichens hat. Das ändert sich dann bei den Zeichen, die in ASCII/ANSI nicht mehr darstellbar sind.

[roderich]

hi tommie-lie,

ich lese die Sprachdateien ganz einfach ein mit TIniDatei.ReadString, d.h. in einen normalen 1 Byte-pro-Zeichen-String. Trotzdem funktioniert es auf dem Japaner-PC komischerweise bei einigen Controls.
Wie gesagt scheinen einige Controls die Intelligenz zu haben, einen UniCode-String in einem "normalen" String zu erkennen.

Roderich

[tommie-lie]

Zitat von roderich:

Trotzdem funktioniert es auf dem Japaner-PC komischerweise bei einigen Controls.

Wie sieht es denn bei den Controls aus, bei denen es nicht funktioniert? Einfach nichts, oder nur der erste Buchstabe oder was ganz anderes?

Zitat:

Wie gesagt scheinen einige Controls die Intelligenz zu haben, einen UniCode-String in einem "normalen" String zu erkennen.

Hmm...
Bei C-Strings wie sie Wndows verwendet markiert ein Nullbyte ja das Stringende. Da bei Unicode im westlichen Raum das ja jedes zweite byte ist, ist bei Unicodestrings ein Doppel-Nullbyte der Terminator, evtl erkennen das einige. Aber theoretisch müssten es alle erkennen, schließlich sollte Windows da nicht großartig unterscheiden, die VCL greift ja auch nur auf die Windows-Funktionen zurück...

[Luckie]

Zitat von roderich:

ich lese die Sprachdateien ganz einfach ein mit TIniDatei.ReadString, d.h. in einen normalen 1 Byte-pro-Zeichen-String.

Dann sollte das aber nicht gehen. Du liest einen 2 Byte Zeichensatzstring in ein 1 Byte Zeichensatzstring ein. Und was passiert mit dem zweiten Byte? Bei den westlichen Sprachen mit Lateinischenbuchstaben mag das ja noch gehen, da das zweite Byte #0 ist und keine Informationen trägt, aber was ist bei anderen Sprachen, wo das zweite Byte auch Informationen beinhaltet?
Ich würde bei dir im Moment auf Zufall tippen.

[roderich]

hi tommie-lie,

bei den Controls, wo es nicht funktioniert (z.B. TBitButton) wird der Text so dargestellt, als ob es ein normaler String wäre. Also beispielweise ƒŒƒCƒAƒEƒg (= 10 Zeichen Schrott), wo eigentlich 5 japanische Zeichen stehen sollten. Man erkennt deutlich das jeweilige Lo-Char (ƒ). Die Caption-Zuweisung bei TButtons, wo es klappt, ist haargenau die gleiche; grob gesagt aButton.Caption := aIniFile.ReadString(blabla, blabla).

Wenn man googelt, findet man Aussagen, daß Delphi kaum UniCode-Unterstützung bietet und man daher Komponenten verwenden muß, deren Caption ein WideString ist und deren TextOut speziell angepasst ist. Nur leider hat mein Hauptprogramm ca. 250.000 Zeilen und ca. 100 Formulare mit zusammen sowiesoviel Komponenten Habe keine Lust, die alle zu ersetzen.


Dir jedenfalls 1000 Dank für die Hilfe !

viele Grüße
Roderich

[Chewie]

250.000 Zeilen Hast du ein Betriebsystem geschrieben?

[roderich]

Zitat:

250.000 Zeilen Hast du ein Betriebsystem geschrieben?

so ungefähr.....
nee, das Projekt läuft schon 3 Jahre. Aber eigener Code sind es vielleicht 200.000 Zeilen, der Rest sind Komponenten.

Luckie, ich glaube nicht an Zufall. Ich habe einige Screenshots bekommen, und da sieht man, daß z.B. TMenuItems immer funktionieren und TBitButtons nie. Es muß daran liegen, daß einige Komponenten ihre eigene nicht-unicode-fähige Draw-Routine haben, während andere Komponenten auf ExtTextOutW o.ä. aus der API zugreifen. Dieses ExtTextOutW ist dann wohl so schlau, daß es UniCode-Strings richtig ausgibt.

Roderich