Localizer für Delphi-Programme

[RWarnecke]

Hallo zusammen,

ich möchte gerne mein Programm mehrsprachig machen. Dazu habe ich mittlerweile mehrere Localizer im Freewarebereicht ausprobiert. Hängen geblieben bin ich bei Lingus von wicht. Das Programm ist echt super. Nur einen Nachteil hat es, wenn ich zur DesignTime in der TTreeview Knoten festlege, werden diese nicht übersetzt. Der Grund dafür ist mir auch klar, da die Knoten in der DFM Datei nicht im Klartext stehen. Jetzt bin ich auf der Suche nach einem einfachen Localizer wie Lingus, der aber auch die Knoten eines TTreeViews übersetzen kann. Kennt jemanden einen Localizer als Freeware oder OpenSource, der so etwas kann ?

Andere Alternative wäre nur noch, den Inhalt von Items.NodeData auszulesen und da stellt sich mir die Frage, wie ?

[wicht]

Weil ich es gerade lese:
Hat jemand Infos, wie man diese "serialisierten" Daten auslesen könnte?
Bitte nicht hauen, weil ich mich noch nicht groß informiert habe...

[Bernhard Geyer]

Zitat von RWarnecke:

Andere Alternative wäre nur noch, den Inhalt von Items.NodeData auszulesen und da stellt sich mir die Frage, wie ?

Hier wäre mein Liebling RTTI zu nennen. Wenn die relevanten NodeData-Infos als properties vorlegen könntest du das mithilfe der Funktionen aus der TypeInfo.pas-Unit machen. Bei D2010 dann die erweiterte RTTI vewenden.

[himitsu]

Zitat von RWarnecke:

da stellt sich mir die Frage, wie ?

Hier gibt es 3 Alternativen:
* Entweder du deserialisierst diese Daten selber: (würde ich nicht machen, da man so sich erstmal in das Format einarbeiten und auch noch aufpassen muß, wenn sich dieses mal ändert (wie z.B. beim Sprung von D2007 nach D2009)

* Dann könne man den Teil der Item.Data, bzw. die ganze TreeView aus der DFM extrahieren und diese Daten von einer temporär erstellen TreeView deserialisieren lassen, dann ändert man über den tree die Daten und serialisiert am Ende alles wieder.

* Oder man läßt die komplette Form von der DFM deserialisieren, welches wohl das Beste ist, da man dann gleich alles über die VCL bearbeiten kann und ebenfalls auch hier am Ende wieder serialisieren.

Die letzen Beiden haben nur einen Nachteil.
Und zwar, daß man den Lokalisierer möglichst mit der selbe Delphi-Version kompiliert, womit auch diese Form serialisiert wurde.


Aber mal was Anderes, willst du deine Anwendung über eine Fremdanwendung lokalisieren und alles direkt in der EXE umbauen lassen
oder soll dieses zur Laufzeit und womöglich noch mit mehreren integrierten Sprachen passieren?

PS: Ich hatte ja auch noch keinen Lokalisierer gefunden, welcher mit gefällt und probiere seit 'ner ganzen Weile immer mal verschiedene Methoden aus.
> bei meinem FileSplitter liegen alle Strings und Dialoge (nonVCL-Formulare) in den Programmresourchen, wobei die Resourcen ja mit Sprachinfos versehen werden, so daß man alle Resourchen mehrfach eingebunden haben kann und sich dann eine passende Sprachversion ausließt.
> und aktuell eim Manifest-Creator wird zur Laufzeit durch die Form interirrt und da über eine XML ersatzstings gesucht, wärend Strings im Programm ebenfalls aus der XML ausgelesen werden.
(bei beidem hab ich aber noch nichts, welches erstmal automatisch eine String-/Wortliste aus dem Programm erstellt, so daß man sich die übersetzen Komponenten selber anlegen muß.)


Aber ganz im Ernst, Lingus hab ich irgendwie übersehn ... also k.A. wie das ist.



PS: Hatte Sakura nicht auch einen Lokalisierer?

[RWarnecke]

Zitat von Bernhard Geyer:

Hier wäre mein Liebling RTTI zu nennen. Wenn die relevanten NodeData-Infos als properties vorlegen könntest du das mithilfe der Funktionen aus der TypeInfo.pas-Unit machen. Bei D2010 dann die erweiterte RTTI vewenden.

Hättest Du dazu Links, wo das ganze für die TypInfo.pas oder für die RTTI beschrieben steht ?

Zitat von himitsu:

Aber mal was Anderes, willst du deine Anwendung über eine Fremdanwendung lokalisieren und alles direkt in der EXE umbauen lassen
oder soll dieses zur Laufzeit und womöglich noch mit mehreren integrierten Sprachen passieren?

Nein, ein Fremdprogramm soll die übersetzung nicht machen. So wie Lingus es amcht über eine Resourcedatei, finde ich es sehr praktisch.

Zitat von himitsu:

Aber ganz im Ernst, Lingus hab ich irgendwie übersehn ... also k.A. wie das ist.

Probiere es einfach mal aus. Ich finde Lingus sehr praktisch.

Zitat von himitsu:

PS: Hatte Sakura nicht auch einen Lokalisierer?

Ja, aber dieser wird nicht mehr weiterentwickelt und kann auch keinen TTreeView auslesen umd den Inhalt zu übersetzen.

[himitsu]

Nja, mal sehn, wie es damit aussieht.
Aktuell reicht mir mein eigenes System, welches sich hier so langsam die letzen Jahre entwickelt, auch wenn ich noch keinen Editor hab, aber so oft brauch ich sowas noch nicht.

Aber Lingus sieht schonmal nicht schlecht aus.



Jup, das von Sakura (hatte ich es mir also richtig gemerkt ) liegt wohl wirklich auf Eis ... nichtmal das Setup läuft richtig, also vorallem das optionale Video fehlt.

[nahpets]

Hallo,

RTTI und Delphi bei Google [google]+rtti +delphi[/google]
Erster Treffer bei delphi.about.com und die Seite gründlich lesen und deren Links folgen. Ein erster Überblick ergab, dass das Wesentliche, um damit das gewünschte zu erreichen, dort zu finden ist.

Habe vor Jahr und Tag mal eine RTTI-Komponente geschrieben, die mir zur Laufzeit alle Captions, Hints, Shortcuts... einer Anwendung rekursiv ausliest und in eine INI-Datei schreibt. Die kann man dann kopieren und "übersetzen". Über ein Menü kann man sich dann die seiner Sprache entsprechende INI-Datei auswählen, die wird dann über RTTI eingelesen und alle Captions, Hints und Shortcuts... werden im Programm entsprechend gesetzt. Natürlich merkt sich das Programm die zuletzt genutzte INI-Datei und startet beim nächsten Mal mit der zuletzt ausgewählten Sprache.

Die Komponente braucht man genau einmal, bindet sie in alle Programme ein und wer seine eigene Sprache für ein Programm haben will, der kann sich seine individuelle INI-Datei erstellen, übersetzen.... Damit spar' ich mir dann auch das Übersetzen, die Texte können jederzeit angepasst werden, ohne dass man nochmal an's Programm ranmuss.

Statt INI-Dateien könnte man natürlich auch XML nehmen, aber INI-Dateien haben den Vorteil, dass Notepad zum "Übersetzen" ausreicht.

Die Idee kam mir, als mir mal jemand eine DOT für Word auf Bayrisch gab, und nun alles in Word auf Bayrisch beschriftet war.

[himitsu]

Zitat von nahpets:

aber INI-Dateien haben den Vorteil, dass Notepad zum "Übersetzen" ausreicht.

reicht bei XML auch
(drum konnte ich bis jetzt mein diesbezügliches himXML-Addon auch noch ohne so einen schönen Spracheneditor verwenden )

[mkinzler]

Zitat:

reicht bei XML auch Zwinkern

Wobei eine Ini aber leichter verständlich ist. XML ist natürlich viel mächtiger

[nahpets]

Zitat von mkinzler:

Zitat:

reicht bei XML auch Zwinkern

Wobei eine Ini aber leichter verständlich ist. XML ist natürlich viel mächtiger

Genau deshalb ja auch INI-Datei:

Code:

fmMain.acNew.Caption=Neu
fmMain.acNew.HelpKeyword=
fmMain.acNew.HelpContext=1020
fmMain.acNew.HelpType=0
fmMain.acNew.ShortCut=16462
fmMain.acNew.Hint=Neue Datei erstellen.
fmMain.acOpen.Caption=Öffnen
fmMain.acOpen.HelpKeyword=
fmMain.acOpen.HelpContext=1021
fmMain.acOpen.HelpType=0
fmMain.acOpen.ShortCut=16463
fmMain.acOpen.Hint=Datei öffnen.
fmMain.acSave.Caption=Speichern
fmMain.acSave.HelpKeyword=
fmMain.acSave.HelpContext=1022
fmMain.acSave.HelpType=0
fmMain.acSave.ShortCut=16467
fmMain.acSave.Hint=Datei im aktuellen Editor speichern.
fmMain.acSaveAs.Caption=Speichern unter
fmMain.acSaveAs.HelpKeyword=
fmMain.acSaveAs.HelpContext=1023
fmMain.acSaveAs.HelpType=0
fmMain.acSaveAs.ShortCut=16469
fmMain.acSaveAs.Hint=Datei unter anderem Namen speichern.
fmMain.acSaveAll.Caption=alles speichern
fmMain.acSaveAll.HelpKeyword=
fmMain.acSaveAll.HelpContext=1024
fmMain.acSaveAll.HelpType=0
fmMain.acSaveAll.ShortCut=0
fmMain.acSaveAll.Hint=Alle geöffneten Dateien speichern.
fmMain.acClose.Caption=Ende
fmMain.acClose.HelpKeyword=
fmMain.acClose.HelpContext=1025
fmMain.acClose.HelpType=0
fmMain.acClose.ShortCut=32856
fmMain.acClose.Hint=Beenden des Programmes.

Das ist der Auszug aus so einer INI-Datei. Das dürfte für den Laien deutlich einfacher zu "Übersetzen" sein, als eine entsprechende XML-Datei.