Japanische Version von Delphi 7 kaufen

[gore]

Hallo,

weiß einer, wo ich die japanische Version von Delphi 7 kaufen kann? (es sollen auch nicht zuviele Versandkosten anfallen, ein deutscher Shop wäre schön ;-)
Danke für Eure Hilfe!

Ben

[sakura]

Rufe mal im InfoCenter von Borland an: 00800 BORLAND-T oder Email an: [e-mail]

...:cat:...

[Bernhard Geyer]

Für was benötigst Du eine japanische Version?
Reicht dier keine Deutsche oder Englische?

[gore]

Zitat:

Zitat von Bernhard Geyer

Für was benötigst Du eine japanische Version?
Reicht dier keine Deutsche oder Englische?

Ein Japaner hat mein Programm übersetzt. TButton u.a. zeigen aber keine Unicode Zeichen an (VCL ist nicht unicodefähig). Ich denke, die japanische Version zeigt die japanische Zeichen richtig an.

[CK_CK]

Ich denke, es reicht, wenn du auf die TNT-Komponenten umstellst. Die sind gratis und können Unicode.

Such' mal hier im Forum danach...

CK_CK

[sakura]

Zitat:

Zitat von gore

Ein Japaner hat mein Programm übersetzt. TButton u.a. zeigen aber keine Unicode Zeichen an (VCL ist nicht unicodefähig). Ich denke, die japanische Version zeigt die japanische Zeichen richtig an.

Das hat nichts mit Delphi zu tun, sondern mit den Einstellungen von Windows. Am sichersten ist es hier eine zweite Windowsumgebung zu installieren und diese auf japanische Einstellungen zu trimmen. Zeichensätze müssen installiert werden, Umgebungsoptionen ausgewählt, etc.

...:cat:...

[Phoenix]

Alternativ gibt es Microsoft AppLocale. Delphi bzw. die Zielanwendung wird dann innerhalb von AppLocale gestartet, welches ihm eine andere Windows-Sprachversion vorgaukelt. Klappt zumindest für polnisch ganz gut :)

Zum Testen reicht das vollkommen aus, produktiv sollte die Software dann aber besser in der jeweiligen Windows-Sprachversion laufen.

[Bernhard Geyer]

1, Auch die Japanische Delphi-Version kann nicht mehr

2, Die VCL ist Unicode-Fähig, jedoch sind die von Borland mitgelieferten (Win32-Wrapper-)Komponenten es nicht.

3, Man sollte auf keinen Fall auf Krückenlösungen wie Codepages/Charsets setzen. Ich denke Microsoft AppLocal zählt auch dazu sondern sein Programm auf Unicode auslegen.

4, Die TNTWare-Komponenten gehen wenn man nichts ausgeben will und auch nicht zu viel Erweiterungen zu den Standard-Komponenten will/benötigt. Ansonsten sag ich nur ElPack. Damit geht Unicode auch unter Win9x/ME

[gore]

Danke für Eure Antworten.
Wenn die VCL Unicode-Fähig ist, dann kann ich also die caption Eigenschaft von TButton, TLabel usw mit einem WideString setzen?

Der japanische Übersetzer schrieb:
> Although I saved tentative language file with UTF-8 encoding, it
> didn't show Japanese correctly. Then I saved it with S-JIS encoding,
> now only menus are displayed correctly.

Soll er die japanische Übersetzung in eine UTF-8 encodierte Datei speichern?

[NicoDE]

Zitat:

Zitat von gore

Soll er die japanische Übersetzung in eine UTF-8 encodierte Datei speichern?

Ist anzuraten, da die meisten Tools damit umgehen können.

[himitsu]

Zitat:

Zitat von gore

Wenn die VCL Unicode-Fähig ist, dann kann ich also die caption Eigenschaft von TButton, TLabel usw mit einem WideString setzen?

So einfach geht das nun auch nicht, da Capption doch als AnsiString definiert ist, es also erst nach Ansi und dann wieder zurück konvertiert würde (dabei gehen natürlich die meisten Unicodeinformationen verloren).


Du müßtest also Caption umgehen und praktisch dort einsteigen, wo der String wieder Unicodemäßig gehandelt wird.

[Bernhard Geyer]

Zitat:

Zitat von gore

Danke für Eure Antworten.
Wenn die VCL Unicode-Fähig ist, dann kann ich also die caption Eigenschaft von TButton, TLabel usw mit einem WideString setzen?

Da TButton ein Borland-Wrapper um die Ansi-Version des Win32-Buttons ist geht das nicht. Auch nicht das Umschiffen. Auch ist das Caption-Property hier nur Ansi.

Wenn Du Code-Mäßig auf einem japanischen System einem Caption einen japanischen Widestring übergibst wird dieser vor der Zuweisung mit der Japanischen Codepage in einen Ansi-String umgewandelt und es würde gehen. Machst du das gleiche auf einem deutschen System wird dieser String mit unserer Codepage umgewandelt und du erhälst lauter Fragezeichen.

Hast Du bei deinen Control irgendwas an dem Property Font.Charset geändert? Falls hier nicht mehr DEFAULT_CHARSET steht geht eh alles falsch und du mußt dich mit Codepages/Charsets herumärgern.

Ich kann dir nur dringend raten dein Programm auf Unicode-Controls wie ElPack oder TNT umzustellen. Wird zwar ein paar Tage-Monate je nach Programmkomplezität dauern aber mit Ansi-Controls sowas zu machen ist m.E. vergeutete Zeit.

[himitsu]

Zitat:

Zitat von Bernhard Geyer

Da TButton ein Borland-Wrapper um die Ansi-Version des Win32-Buttons ist geht das nicht. Auch nicht das Umschiffen. Auch ist das Caption-Property hier nur Ansi.

Über das Handle des Win32-Buttons kann man sich auch direkt an Windows wenden und über die Wide-API-Funktionen die Caption direkt setzen.

Aber mal ehrlich, dann kann man ja och gleich ganz auf NonVCL umsteigen.

[Ydobon]

Das bringt ebenfalls nichts, da Delphi nur Ansi-Komponenten erzeugt, das W bei CreateWindowsEx fehlt. Damit sind auch die
entsprechenden Windows-Fenster nicht unicodefähig -> IsWindowUnicode(Button1.Handle)=false und SetWindowTextW bringt genauso nur
Fragezeichen.

Wenn man das System auf Quasi-Japanisch einstellt, kann man mit Delphi einigermaßen japanische Anwendungen schreiben, Applocale
wird da aber nicht ausreichen, da nicht nur der Delphi Exe Japanisch vorgegaukelt werden muss. Man könnte es aber vermutlich zum Testen verwenden. Intern ist Codepage 932 in etwa Shift-JIS, daher wird das dann mit den Menüs geklappt haben.

Am Sinnvollsten ist es allerdings in jedem Fall unicodefähige Komponenten zu verwenden.

[himitsu]

Hmm, ich dachte die Ansi-APIs werden dann intern auf die Wide-Versionen umgeleitet, so daß dann dennoch alles Unicode ist ... muß es eigentlich, denn ich konnte schon Unicode in ein TEdit kopieren (Strg+V), auch wenn es dann nur als ANSI wieder ausgelesen wurde.

[Ydobon]

Weißt du noch, wie du es geschafft hattest? Eigentlich sollte sich ein TEdit nur für den Text in der Zwischenablage interessieren und den Unicode Teil ignorieren.

Für die entsprechenden Funktionen gibt es doch eigentlich in den Bibliotheken jeweils eine Ansi und eine Unicode Version, mit unterschiedlichen Adressen, dann sollten sie auch getrennt implementiert sein.

[Bernhard Geyer]

Zitat:

Zitat von himitsu

Hmm, ich dachte die Ansi-APIs werden dann intern auf die Wide-Versionen umgeleitet, so daß dann dennoch alles Unicode ist ... muß es eigentlich, denn ich konnte schon Unicode in ein TEdit kopieren (Strg+V), auch wenn es dann nur als ANSI wieder ausgelesen wurde.

Evtl ist ganz im Hintergrund eine Unicode-Control. Aber es werden zu viele "Prüfstellen" eingebaut sind die Verhindern das du damit vernünftig arbeiten kannst wenn es als ANSI-Control "angefordert" wurde.

[Amnon82]

Falls es hilft: D6PE JAPANESE

[Phoenix]

Andere Sache... auch wenn's ned ganz billig ist: Multilizer ( http://multilizer.com/ ).

Damit kannst Du jede Anwendung, auch wenn sie nicht wirklich auf Multilanguage ausgelegt ist, gut Übersetzen. Und noch besser: Bei Delphi-Projekte bekommt der Übersetzer nicht nur die Strings zu sehen sondern gleich auch noch die Formulare und hat so einen kontext - und kann z.B. Labels auch noch gleich größer oder kleiner ziehen, wenn der übersetze Text z.B. nicht ganz reinpasst.

[gore]

Danke für alle Antworten. Hier abschließend meine Lösung: Alle Strings hat mir der Japaner in Shift-JIS gespeichert (lokale Codepage, kein Unicode). Ich habe am Programm nicht viel geändert, nur die Strings eingebunden und alle verwendeten Schriftarten auf "MS Shell Dlg" gesetzt. Somit nimmt ein japanischen Windows die Schrift "MS Gothic". Scheint alles zu klappen, sieht auch richtig gut aus. Mal sehen obs unter Vista auch klappt....

Ben