Planung eines Multilingual-Systems

[kalmi01]

Hi,
DKlang kann ich empfehlen.

[Prototypjack]

Guten Tag!

Zitat von raffo:

Ach ja, und um es nicht "zu einfach" zu machen, ich persönlich habe auch vor, auf polnisch zu übersetzen, und dann sind da die Zeichen ą ć ę ś etc.

Kein Problem Das ganze System baut intern auf WideStrings auf (UniCode) die später per UTF-8 in ein XML-Konstrukt gespeichert werden. Du kannst das Programm damit auch in einem Dialekt aus der Mongolei übersetzen

Zitat von raffo:

Die Language Datei (die hab ich noch), kann dann ganz simpel aussehen:

Wie bereits eben angemerkt baut meine "Sprachdatei" auf einem XML-Konstrukt auf. Ist nicht ganz so einfach gehalten wie deines hat aber den Vorteil multidimensional zu sein, was späteres bearbeiten/erstellen geradezu enorm viel komfortabler macht.

Zitat von raffo:

Also die Anwendung wird nativ (z.B.) auf Deutsch geschriebe. Problem ist leider zusätzlich noch, das ja manche Labels in der neuen Sprache ggf. länger werden, also abgeschnitten werden etc.

Da müsste dann sogar noch die Größe des Elements editiert werden können, was ich erstmal bisher nicht eingeplant habe.

Ja, mit diesem Problem sehe ich mich ebenfalls konfrontiert (und da bin ich wohl neben einigen kommerziellen Herstellern nicht der einzige). Das Problem hierbei ist, dass man nicht ahnen kann was man gerade übersetzt, sprich, wenn man sich bei einem Label befindet ist's leicht, einfach das nächste Width Property miteinbeziehen. Wenn man sich jedoch in einem Spalte (Kopfspalte) eines Gridviews (Oder was auch immer ) befindet und der Komponentenentwickler hat hier vorgesehen die Width-Eigenschaft gesondert in einem "Options"-Feld zu behandeln, dann hat man keine Chance mehr.

Zitat von raffo:

2.) In Code selbst sind ja auch u.a. Bezeichnungen, Texte etc, diese müssten als Funktion aufgerufen werden können um automatisch zu übersetzen, Beispiel:

Delphi-Quellcode:

Label1.Caption:=translate('Bitte Kundennummer eingeben'); //Das Programm weiss ja, in welche Sprache ich übersetzen will

//oder

if x_string=translate('Bearbeiten') then
   begin
   ...
   end;

Diese "Hardcoded-Strings" sollten sich sowieso nicht im Code befinden (Trennung GUI/Core). Deshalb bietet mein Übersetzungssystem einen Wizard (Ganz komfortabel wie bei einem Setup) an, der alle diese Strings extrahiert (Natürlich kann man vor irgendeiner Änderung im Code alles einsehen und gegebenenfalls die Änderung im Code unterbinden) und dieses gesondert verwaltet. Dies geschieht dann im "Constants-Editor" ein neues Fenster der IDE (Auswählbar über einen speziellen Menüpunkt bzw. Hotkey(Vielleicht)). Dort kann man alle Konstanten bequem verwalten. Alles andere (Was sich nicht direkt im Code befindet, sprich Komponenten-Propertys)) wird vollautomatisch von meinem System mit einem einzigen Befehl übersetzt, auch Formunabhängig, wenn gewünscht (Form1: Englisch; Form2: Polnisch).

Zitat von raffo:

Der Hintergrund ist, das es übersetzt wird, und nicht Element für Element eine eigene Bezeichnung bekommt a la Label1='Auftragsdaten'; Label2='Auftragsdaten'; Weil meinen "Schliessen" Schalter nenne ich IMMER "Schliessen". Ich hoffe Du verstehst. Damit sind sogar selbst zur Laufzeit, wenn dann schon einiges übersetzt ist, viele Elemente bereits fertig.

Dieses Problem habe ich auch bereits bedacht. Deshalb wird es im Übersetzungseditor ein sogenanntes "Übersetzungsdepot" geben. Dort wird alles was man übersetzt zusammen mit der Sprache, in welche Übersetzt wurde gespeichert. Bei einem neuen Projekt kann man dieses Depot dann mal über die Ausgangssprache laufen lassen und muss später nur noch anpassen.

Zitat von raffo:

1.) Auf der Oberfläche sollte DER KUNDE selbst die Elemente übersetzen können (natürlich werde ich soweit wie möglich einen Anfang machen). Also man geht in ein bestimmtes Menü, drückt: Übersetzung bearbeiten. Wenn man dann mit der Maus über ein Element ist (die Schwierigkeit ist hier z.B. TLabel, aber TStaticLabel geht, könnte ich verkraften und alle TLabels nach TStaticLabel umwandeln) drückt man eine Tastenkombination (nicht die rechte Maustaste allein, da man je ggf. nen Unterpunt wählen muss, um zum nächsten Dialog zu kommen) und es öffnet sich ein Fenster um nun den NEUEN TEXT zu editieren.

Das schwerste habe ich mir nun mal für den Schluss aufgehoben. Verstehe ich dich richtig: Der User soll im Programm (Also, das Programm welches Übersetzt werden soll) nach WYSIWYG-Motto Editieren können? Das dürfte ziemlich unmöglich werden, zumindest kann ich mir keine mögliche Lösung vorstellen. Was ich theoretisch anbieten könnte wäre der normale Übersetzungseditor in Dialog-Form (Aus dem Programm heraus aufrufbar) und der User editiert dann dort. Wie ich jedoch diesen "WYSIWYG"-Editor realisieren könnte: Ich habe keine Ahnung

So,
das war's erstmal von mir!

Gruß,
Max

Edit: Achja, da war ja noch was

Zitat von kalmi01:

DKlang kann ich empfehlen.

Das System arbeitet an einigen Stellen suboptimal, ich zitiere mich mal selbst:

Zitat von Prototypjack:

Bei dkLang ist der Editor perfekt aber das Grundsystem ansich sagt mir nicht zu (besonders, dass man nur durch selbstständiges Parsen an manche Informationen aus der Sprachdatei kommt (Autor zB.))