Planung eines Multilingual-Systems

[Prototypjack]

Guten Tag!

Es wird für meine Projekte immer wichtiger multilingual zu sein. Nun könnte ich natürlich dieses vorgefertigte ITE (Ich glaube so hieß es) von Borland/CodeGear verwenden oder aber horrende Summen für eine andere proprietäre Lösung aufwenden. Da mir die Lösung von Borland/CodeGear aber nicht wirklich zusagt und ich sicherlich nicht derartig viel Geld für Opensource Projekte aus der eigenen Tasche aufwenden kann muss wohl eine eigene Lösung her.

Da ich keine Opensource alternative kenne (falls ihr welche kennt, bitte teilt sie mir mit ;) ) werde ich mein System dann zu gegebener Zeit veröffentlichen, möglicherweise unter der MPL 1.1.

Was ich eigentlich mit diesem Thread bezwecken will ist eine Ideensammlung (Und wenn sie auch noch so krank :mrgreen: sind, bitte äußert eure Wünsche/Ideen, denn ich will hier eine richtige Alternative schaffen) und vielleicht auch gleich ein paar Anregungen für die Umsetzung verschiedener Ideen (zum Beispiel habe ich noch keine Ahnung wie/wann/wo ich das Sprachtemplate erstelle(bzw. wann der beste Zeitpunkt dazu ist), welches dann später editiert werden kann).

Ich hoffe auf ein paar konstruktive Ideen

Grüße,
Max

[Bernhard Geyer]

Wie wäre es mit GNU gettext

[Prototypjack]

Moin!

Achja, mit GNU-Gettext hatte ich schon lange nichts mehr zu tun. Der Hauptgrund wieso ich mich damals daran gestört hatte wahr wohl die vorgesetzte Verzeichnisstruktur "locale/de_DE/LC_MESSAGES/default.mo" wobei man darüber ja hinwegsehen könnte. Hmm, ich denke ich werde mich nocheinmal näher mit Gettext auseinandersetzen müssen.

Gruß,
Max

[markusj]

Ich bin dazu übergegangen, jede Meldung durch einen Code zu ersetzen, nachdem dann in einer Sprachdatei geschaut wird.
Dieser Text wird dann angezeigt.
Wenn man von Anfang an mit solchen Codes arbeitet, ist das kein Problem, das ganze fügt dann perfekt in die Statusrückgabe ein, die bei mir jede Funktion hat, die Mist bauen kann. Der Rückgabecode wird ausgewertet und wenn nötig, die Message dazu generiert.
Nachteil: Deutlich höherer Codebedarf aufgrund der Auswertung nach Funktionsaufruf.
Vorteil: Klare Trennung von Oberfläche und Core, der Unterbau lässt sich jederzeit an anderer Stelle einsetzen, angepasst werden muss lediglich die Oberflächenkommunikation.

mfG

Markus

[DGL-luke]

Ich bin gerade dabei, ein halbautomatisches Übersetzungssystem zu schreiben, das DFMs ausliest und auf XML-Basis Sprachdateien erstellt. Per Tool können dann weitere Sprachen hinzugefügt werden. Ich glaube, dass das ganze relativ "neat" wird.
(Übersetzungsrelevante Strings, die nicht in der DFM stehen, sind dann natürlich per Hand nachzutragen - aber ich glaube, der ITE hat das auch nicht drauf, oder?)

[Prototypjack]

Moin!

Ich habe jetzt sowohl dkLang (dk-soft.org) als auch dxGettext nochmal durchgesehen und getestet.
Bei dxGetText ist mein größtes Problem, man glaubt es kaum, der Editor. Ich kann mit dem Interface von PoEdit nicht wirklich etwas anfangen, denn scheinbar fehlen Hotkeys, und dadurch wird das Übersetzen unglaublich mühsam.
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.))

Deshalb möchte ich meine Frage an dieser Stelle wiederholen: Was wünscht ihr euch von einem hervorragendem Übersetzungssystem in Delphi?

Gruß,
Max ;)

Edit: DGL-Luke, meine System wird auf ähnliche Weise wie deines arbeiten aber Differenzen sind doch vorhanden. Zum Beispiel plane ich an Template-Extraktion direkt aus der Exe (Param-Check, das läuft später alles im Hintergrund) und an einigen stellen ist das System mit der IDE direkt verwoben (Stichwort: ResourceStrings, dies wird der Lösung Dmitry Kanns(dkSoft) sehr ähnlich sein).

[raffo]

Zitat:

Zitat von Prototypjack

Deshalb möchte ich meine Frage an dieser Stelle wiederholen: Was wünscht ihr euch von einem hervorragendem Übersetzungssystem in Delphi?

Ich wünsche mir die Lösung mehrerer Probleme (bisher habe ich 2 Versionen englisch - deutsch, aber die laufen immer vom Versionstand her auseinander).

Habe in dieser Richtung auch mal was angefangen, aber potz blitz, die Unit1 ist plötzlich wech :(

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.

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;

---

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.

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.

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

Delphi-Quellcode:

Beschreibung=Description
Eingabe=Input
Auto=car
Haus=house
etwas anderes=something else

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. - könnte ich persönlich aber auf jeden Fall erstmal verschmerzen, weil ich mein altes Projekt unter D3 zunächst sowieso nach D5 konvertieren müsste.

[Daniel G]

Was ich immer gerne nutze, ist der DSLangMgr von AXMD (aka Dust Signs).

[Prototypjack]

Zitat:

Zitat von DGL-luke

Ich bin gerade dabei, ein halbautomatisches Übersetzungssystem zu schreiben, das DFMs ausliest und auf XML-Basis Sprachdateien erstellt. Per Tool können dann weitere Sprachen hinzugefügt werden. Ich glaube, dass das ganze relativ "neat" wird.
(Übersetzungsrelevante Strings, die nicht in der DFM stehen, sind dann natürlich per Hand nachzutragen - aber ich glaube, der ITE hat das auch nicht drauf, oder?)

So, ich bin's mal wieder ;)

Nach 3 Tagen Entwicklungszeit kann ich nun schon einiges vorweisen (Volle IDE-Integration, automatische Template-Extraktion(DFM-Parsing funktioniert auch schon hervorragend) und Einbindung durch Resourcefile(Voll automatisch :D)).

Dann fehlt noch das Stück Code, welches das Programm an sich befähigt auf die (bereits mit einkompilierten) Sprach-Elemente zugreift, sprich: Die Komponente.

Außerdem will noch ein Editor geschaffen werden, doch der Hauptgrund wieso ich hier überhaupt einen Statusbericht geben will ist folgender:

Ich will nicht das Thread schon nach 3 Tagen in der Versenkung verschwindet, denn ich erhoffe mir doch noch die ein oder andere Idee für ein Feature ;)

Also: Kräftig Ideen posten :mrgreen:

Gruß,
Max

[raffo]

Hey Max, bei mir "versinkt" Dein Thread nicht, aber hast Du denn irgendwas zu meinen Vorschlägen programmiert?