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.))