GUI übersetzen - Unicode

[kub]

Hallo zusammen,

ich habe mich bis jetzt noch nie mit Unicode beschäftigt. Nach einer Kundenanfrage soll ich bis morgen den Zeitaufwand abschätzen, eine Anwendung von mir auf eine chinesische Oberfläche umzustellen.

Ich benutze Delphi6 Professional und das Projekt läuft noch unter Win2000.

Bis jetzt nutze ich ein selbst geschriebenes Tool, dass mein Projekt nach Komponenten durchsucht, die übersetzt werden sollen und diese dann in eine Exceltabelle einträgt, wo alles übersetzt werden kann. Mit dieser Tabelle erstelle ich dann automatisch Delphicode, mit dem ich dann meine GUI zurLaufzeit in verschiedene Sprachen umschalten kann. Allerdings handelt es sich bis jetzt nur um ASCII Zeichen.

Jetzt meine Fragen:
Kann ich z.B. chinesische Zeichen aus einer (Text?)Datei einlesen und den Texteigenschaften wie Captions zuweisen?
Muss ich dabei mit größeren Problemen rechnen?
Gibt es evtl. einen besseren Ansatz? Die Sprache muss aber umschaltbar bleiben, da auch deutsche Servicetechniker die Maschine bedienen müssen.

Ich weiß, es gibt viele Beiträge zu diesem Thema, aber ich muss eben bis morgen den Aufwand abschätzen und habe leider keine Zeit mich jetzt für das Angebot tiefer in das Thema einzuarbeiten.

Gruß und Danke im Voraus
Thomas

[Phoenix]

Delphi 6 kann kein Unicode. Das ist erst ab Delphi 2009 möglich.
Du musst also das Projekt erstmal auf Delphi 2009 umstellen. Dann sollte das gehen.

[himitsu]

Du nutzt also keinerlei Unicodefähige Komponenten?

Dann wirst du wohl eine andere Schriftart einsetzen müssen, welche im verfügbaren Zeichenvorrat die entsprechenden Zeichen zur verfügung stellt.

Da dieser ebenso nur den ANSI-Bereich umfassen wird, sollten die ganzen Funktionen weiterhin nutzbar sein.

es wird dann z.B. einfach nur statt dem A irgendein chinesisches Zeichen angezeigt.

[Delphianer]

Hi,

ich weiß zwar nicht, ob mein Ansatz der Beste ist (der preiswerteste bestimmt nicht), aber vollkommen unproblematisch.
Ich verwende Delphi 2009, da damit das Unicode-Problem der Anwendung geklärt ist.
Zum Übersetzen nehme ich Sisulizer. Sisulizer übersetzt die fertige EXE und erzeugt Resourcen-DLLs. Du musst Dich nur um die übersetzten Texte kümmern (natürlich) und evtl. eine Sprachumschaltung ins Programm einbauen (wenige Zeilen). Die ca. 900 € haben sich in meinem aktuellen Projekt schon mehrfach gelohnt.

Gruß,

Lutz

[Bernhard Geyer]

Zitat:

Zitat von kub

Kann ich z.B. chinesische Zeichen aus einer (Text?)Datei einlesen und den Texteigenschaften wie Captions zuweisen?

Ja. Am besten nimmst du eine Unicode-Textdatei

Zitat:

Zitat von kub

Muss ich dabei mit größeren Problemen rechnen?

Kommt auf deine Implementierung an. Wenn du es richtig gemacht hast kannst du mit minimalen Anpassungen (lesen von Unicode-Textdateien) auf einem chinesischen Windows chinesische Zeichen problemlos anzeigen.

Zitat:

Zitat von kub

Gibt es evtl. einen besseren Ansatz? Die Sprache muss aber umschaltbar bleiben, da auch deutsche Servicetechniker die Maschine bedienen müssen.

Wenn der Techniker damit zurecht kommt das die öüä zu oua werden dann sollte das kein Problem darstellen. Du wirst dann auch nur Fragezeichen auf deinem deutschen System haben wenn du die chinesischen Texte einlist.

[Bernhard Geyer]

Zitat:

Zitat von Phoenix

Delphi 6 kann kein Unicode. Das ist erst ab Delphi 2009 möglich.
Du musst also das Projekt erstmal auf Delphi 2009 umstellen. Dann sollte das gehen.

Komisch :gruebel: Unserer Delphi 6-Programme laufen Wunderbar mit Unicode mit Chinesisch unter deutschen XP/... :-)

[himitsu]

ach ja .. schau mal, ob du mit Font.Charset = CHINESEBIG5_CHARSET eventuell irgendwas anfangen kannst

edit: hier zeigt sich dann auch, daß ANSI eigentlich ein MulitByteZeichensatz ist :stupid:

[Bernhard Geyer]

Zitat:

Zitat von himitsu

ach ja .. schau mal, ob du mit Font.Charset = CHINESEBIG5_CHARSET eventuell irgendwas anfangen kannst

Fang blos damit nichts an. Da ist die Delphi-Implementierung sehr Lückenbehaftet.

[himitsu]

Es wäre aber die schnellst'e Möglichkeit dort jetzt was zu machen

Man muß nur die Teste und den CharSet anpassen
und könnte weiterhin alle ANSI-Funktionen, welche man bisher zum Laden genutzt hat,
weiterhin verwenden.


Aber OK, diese Variante hab ich auch nie verwendet.
Hatte aber mal die TNTUnicodeControls im Einsatz (aber diese werden wohl schon 'ne Weile nicht mehr weiterentwickelt ??? )

Ansonsten hab ich die letzen Jahre das Unicode via NonVCL in D4-D7 ohne Probleme nutzen können,
aber dieser Weg wäre hier wohl nicht angebracht.

[Bernhard Geyer]

Zitat:

Zitat von himitsu

Es wäre aber die schnellst'e Möglichkeit dort jetzt was zu machen

Man muß nur die Teste und den CharSet anpassen
und könnte weiterhin alle ANSI-Funktionen, welche man bisßer zum Laden genutzt hat,
weitererwenden.

Damit könnte man probieren chinesische auf einem Deutschen System darzustellen. Um chinesische Texte auf einem chinesischen System darzustellen ist das nicht nötig.

Zitat:

Zitat von himitsu

Hatte aber mal die TNTUnicodeControls im Einsatz (aber diese werden wohl schon 'ne Weile nicht mehr weiterentwickelt ??? )

Werden sie. Und zwar bei TMS Software. Troy hat Sie dorthin verkauft nachdem er keine vernünftige Unterstützung aus der Community erhalten hat und er sich damit nicht mehr so viel Zeit investieren wollte.

Zitat:

Zitat von himitsu

Ansonsten hab ich die letzen Jahre das Unicode via NonVCL in D4-D7 ohne Probleme nutzen können,
aber dieser Weg wäre hier wohl nicht angebracht.

Wieso nicht. Der Austausch sollte relativ schnell von statten gehen. Jedoch ist ein wechsel nach D2009 für einen vollständigen Support vermutlich einfacher.

[himitsu]

Zitat:

Zitat von Bernhard Geyer

Wieso nicht. Der Austausch sollte relativ schnell von statten gehen.

das bezog sich auf's NonVCL ... ich glaub nicht, daß eine VCL-Anwendung von heut auf morgen entsprechend neu geschrieben wurde :nerd:

Was die TNT-Controls angeht ...
wie gesagt, ich weiß nicht, ob man sie unbedingt noch einsetzen sollte (also falls sie wirklich nicht mehr gewartet werden)
Aber notfalls gibt es bestimmt auch noch ein/zwei andere unicodefähige Komponentensammlungen.


Die TNTs sind/waren allerdings kompatibel zur den jeweiligen Standard-VCL-Komponenten, da diese NUR auf Unicode umgestellt wurden.

Zitat:

Damit könnte man probieren chinesische auf einem Deutschen System darzustellen. Um chinesische Texte auf einem chinesischen System darzustellen ist das nicht nötig.

stümmt ja, dort sollte ja der Default-Charset dem Chinesischen entsprechen :oops:

[kub]

Auf Delphi2009 möchte ich bei meinen alten Projekten auf Win2000 nicht umsteigen, da ich einige Fremdkomponenten benutze, von denen ich nicht weiß,ob sie dann noch funktionieren und ich möchte meine Sachen möglichst einheitlich halten, was den Service für mich leichter macht.

Andere Komponenten (TNT) möchte ich nur einsetzen, wenn das unbedingt notwendig ist, da meine GUI ziemlich umfangreich (ca. 2000 zu übersetzende Texte bzw. Ausdrücke) ist.

Wenn ich eure Antworten richtig verstehe, könnte ich auf einem chinesischem System meine Übersetzungen "einfach" aus einer Unicode Textdatei einlesen und dann einfach den Captions der Komponenten (hauptsächlich TLabel,TButton und TComboBox) zuweisen? Leider habe ich kein solches System da, um das Ganze auszuprobieren.

Wenn das so realisierbar ist, sollte das Ganze ja in 2 bis 3 Tagen realisierbar sein.

Habe ich eure Antworten richtig verstanden?

[himitsu]

Zitat:

Zitat von kub

Andere Komponenten (TNT) möchte ich nur einsetzen, wenn das unbedingt notwendig ist, da meine GUI ziemlich umfangreich (ca. 2000 zu übersetzende Texte bzw. Ausdrücke) ist.

Wie gesagt, TNT ist/war da sehr kompatibel.

Man braucht eigentlich (wenn man kein Refraktoring zur Verfügung hat) nur die .PAS und .DFM in einem Texteditor zu öffnen (vorausgesetzt die .DFMs sind natürlich im Text-Modus gespeichert)
und einfach z.B. alle TEdit durch TTNTEdit, TLabel durch TTNTLaben usw. ersetzen.
Wenn man dann die Anwendung wieder in Delphi öffnet ist nun (von den Komponenten her) alles Nötige umgestellt. :thumb:

Zitat:

Zitat von kub

Wenn ich eure Antworten richtig verstehe, könnte ich auf einem chinesischem System meine Übersetzungen "einfach" aus einer Unicode Textdatei einlesen und dann einfach den Captions der Komponenten (hauptsächlich TLabel,TButton und TComboBox) zuweisen?

Jupp, wenn dort die Codepage per Standard auf Chinesisch steht, dann würde bei Umwandlung in einen AnsiString (auch bei automatischer Umwandlung via Delphi) alles passend "übersetzt". :)
Delphi nutzt bei Zuweisung eines WideString an einen AnsiString WideCharToMultiByte und das müßte es hoffentlich richtig machen. :angel:

[Bernhard Geyer]

Zitat:

Zitat von kub

Leider habe ich kein solches System da, um das Ganze auszuprobieren.

Dann wird es zeit das du eine entsprechendes System in einer VM aufsetzt.

Zitat:

Zitat von kub

Wenn das so realisierbar ist, sollte das Ganze ja in 2 bis 3 Tagen realisierbar sein.

Wenn du alles richtig gemacht hast - Ja.
Wenn du pech hast wirst du an stellen viel Zeit investieren wo du bisher noch nicht dran gedacht hast (Eigene Binäre Speicherformate, ...)

[himitsu]

Jupp, VMs machen sich ganz gut.

So kann man sein Programm auch auf "anderen" Systemen testen
und man kann da auch einiges umstellen, ohne ständig an seinem System rumzufummeln. :angel:


codepage umstellen windows > http://www.pcwelt.de/forum/software-...windows-3.html

Hab das mal mit der angehängten Anwendung gemacht
(ist das Gleiche wie oben, nur das ich hier nicht vergessen hab den Quellcode mit anzuhängen :oops: )

oberes Memo = system codepage/charset
unteres Memo = CHINESEBIG5_CHARSET

Daß in dem Beispiel nun unterschiedliche "Texte" zu sehen sind, liegt daran, daß ich einfach "wahllos" irgendwelche Ansi-Codes zusammengestellt hab
und auch die beiden Codepages unter chinesisch wohl nicht die selben Waren.

Aber wenn du dem a bzw. .Text direkt einen WideString (Unicode) zuweißt, dann sollte es schon besser funktionieren.

[kub]

Vielen Dank für eure Hilfe.

Ich habe meine Zeitschätzung jetzt etwas nach oben korrigiert, aber ich denke dank euren Tipps sollte ich jetzt das Ganze realisieren können.

[himitsu]

So, jetzt weiß ich wieder, was mit den TNTs los ist.
Diese wurden ja an TMS verkauft und die vertreiben es ja nun kommerziell.
Deshalb ist auch nur noch die letzte "freie" Version im Umlauf, welche nun auch schonwieder 2 Jahre alt ist.

Eventuell könnte dieses dir helfen?
http://www.delphipraxis.net/internal...091191#1091191

Da müßte man "theoretisch" seine Formulare nicht umbauen
und bindet stattdessen diese Unit als LETZTES in seine Units ein.
Damit werden die verbauten Componenten einfach auf die entsprechenden TNTControls umgeleitet.


Also man baut über seine IDE ein TEdit im Formular ein und wenn die VCL dann das Formular erstellt, dann müßte an dieser Stelle ein TTntEdit auftauchen. :angel:

[kub]

Praktisch! Ich danke Dir.

[kub]

Hallo,
vor gut einem halben Jahr habt ihr mir bei der Zeitabschätzung für die Umstellung eines Delphi6 Projekts auf Unicode geholfen. Jetzt hat der Kunde tatsächlich noch bestellt.

Die Umsetzung hat eigentlich ganz gut funktioniert. Ich habe mir die von Himitsu empfohlenen TNT Tools heruntergeladen, im Windows die Unterstützung von Asiatischen Schriften installiert und entsprechende Fonts verwendet.Mit dem Einbinden der "Hack" Units hat es dann eigentlich schon funktioniert.

Jetzt habe ich das Problem, dass ich damals übersehen habe, dass auch ein Protokoll mit Quickreport erstellt wird. Diese Komponenten werden aber von den TNT Controls, die ich gefunden habe, nicht ersetzt. Irgendwo in einem anderem Forum habe ich gelesen, dass es auch für Quickreport TNT Controls gibt. Ich finde dazu aber nichts. Auch bei TMS finde ich nichts für Quickreport. Kennt oder hat jemand von euch entsprechende Komponenten?

Gruß
Thomas

[kub]

Guten Morgen,

kennt wirklich keiner niemand eine unicode fähige Komponente, die man unter Delphi 6 statt der Quickreport Controls einsetzen kann?

Gruß
Thoms

[mkinzler]

D6 ist halt schon sehr alt. Da wird es schwer was Passendes zu finden

[himitsu]

Du könntest dir ein neueres QuickReport (z.B. gleich eines mit Unicode von D2009+) in eine DLL einkompilieren lassen und dieses dann ansprechen.
('nen Interface als Schnittstelle und WideStrings für die Kommunikation)

[mkinzler]

Dann bräuchte er aber auch eine neuere Delphiversion und dann würde ich das Programm gleich dorthin migrieren

[himitsu]

Oder er braucht wen, der es für ihn kompiliert. :wink:

[taveuni]

Zitat:

Zitat von kub (Beitrag 1033904)

Guten Morgen,
kennt wirklich keiner niemand eine unicode fähige Komponente, die man unter Delphi 6 statt der Quickreport Controls einsetzen kann?

Fastreport vielleicht?

Auf jeden Fall steht auf der verlinkten Seite:
"UNICODE Support. Ihr Report kann in allen Sprachen der Welt angezeigt werden!"
und
"Es kann in den Umgebungen von CodeGear (exBorland) Delphi 4-2009, CodeGear C++Builder 6-2009 und CodeGear RAD Studio genutzt werden"

Ich habe jetzt nicht den ganzen Thread durchgelesen.
Vielleicht hat schon jemand darauf hingewiesen.

[mkinzler]

Könnte man Testen ist ist nur die Frage, ob die Version für D6 dann Unicode kann ( die Version von D2010 verwendet (Unicode-)string nicht WideString)

[kub]

Ich fürchte, ich muss mich jetzt doch von meinem Delphi6 verabschieden und mir die 2010 Version leisten. Je nach dem, wie aufwendig es ist das ganze Projekt zu migrieren, werde ich evtl. die Idee mit der DLL aufgreifen.

Bei Fastreport bin ich mir auch nicht sicher, ob das unter D6 richtig mit Unicode funktionieren wird und wenn ich eh die Software ändern muss und mir eine Komponente kaufen muss, halte ich eine neuere Delphi Version für sinnvoller.

Vielen Dank an alle für Eure Unterstüztung.

Gruß
Thomas

[mkinzler]

Von FastReport gibt es eine Demoversion. Aber wenn Unicode wichtig ist, würde sich D2010 wirklich anbieten

[Mschmidt]

Fastreport: Die Reports sind zwar unicode-fähig - allerding nicht deren pdf-Export. Da hab ich seit über einem Jahr einen Bug gemeldet...
Zitat der Hotline vom 26.02.2009 "...Yes, It is true. FastReport support unicode and can display it. And can export to many formats. But PDF export do not support unicode. We are work for it." Allerdings hab ich bis dato nichts gehört.
Falls du den aber nicht brauchst - wäre Fastreport die besste Wahl - ei sei denn du hast viel Kohle um Cristal Reports, LL oder ähnliches
zu ordern.
:-mschmidt

Edit: Schau grad in die Readme's. Ich korrigiere mich. Anscheinend soll ab Version 4.8 der PDF noch komplett Unicode unterstützen.
"* changed PDF export (D7 and upper): added full unicode support, improved performance, decreased memory requirement"

[mkinzler]

Hast du es auch mit der Version für D6 getestet?

[Mschmidt]

nein - da D6 von hause ohne Tricks nicht unicodefähig ist würde ich das auch nicht wirklich vorschlagen wollen.
Wurde ja hier auch schon angeraten.
:-)