Mehrsprachige Anwendung: Ich kriegs nicht hin

[dummzeuch]

Zitat von nuclearping:

Aber nebenbei: Benutzt eigentlich wirklich jemand produktiv diese Delphi-eigenen Übersetzungswerkzeuge?

Ich habe das Anno dazumal versucht und recht schnell sein gelassen.

Mir ging es genauso, allerdings ist das schon mindestens 15 Jahre her. Vielleicht sind sie ja besser geworden?

Zitat von nuclearping:

Dafür ist es zu einschränkend und umständlich. Zum Beispiel um Strings in einer Unit zu übersetzen, musst du diese als resourcestring -Konstante deklarieren.

Es gibt immer wieder Leute, die das fuer einen Vorteil halten. Ich konnte deren Argumente nie nachvollziehen, ausser einem: Man kann die Uebersetzung dann mit einem beliebigen Tool, das Resource Strings unterstuetzt, durchfuehren.

Zitat von nuclearping:

Schau dir mal GNU GetText an. Einen ähnlichen Ansatz nutzen wir auch für unsere Anwendung (Deutsch, Englisch, Slowakisch, Spanisch, Japanisch, Russisch, ...)

Bei GNU GetText extrahiert er automatisch Strings aus DFM Dateien. Und für deine Texte im Code musst du diese in _('...') kapseln. Also zB ...

Delphi-Quellcode:

MessageDlg(_('Hallo Welt'), ...);
Label_Status.Caption := Format(_('Kopiere %s nach %s'), [strSourceFile, strTargetFile]);
// usw.

Da fehlt noch was: Man muss die Uebersetzung eines Formulars im Constructor oder in OnCreate mit

Delphi-Quellcode:

constructor TMyForm.Create(_Owner: TComponent);
begin
  inherited;
  TranslateComponent(Self);
end;

anstossen.

Zitat von nuclearping:

Es gibt keine DLLs und der Übersetzer braucht nur einen Texteditor.

Oder er benutzt ein Tool, das bequemer ist, z.B. PoEdit oder das von mir favorisierte Gorm bzw. ein neueres Release

[Der schöne Günther]

Zitat:

Aber nebenbei: Benutzt eigentlich wirklich jemand produktiv diese Delphi-eigenen Übersetzungswerkzeuge?

Ich habe das Anno dazumal versucht und recht schnell sein gelassen.

Ich habe es vor ca. einem Jahr versucht, mich geschüttelt, und es auch bleiben gelassen. Mit DxGetText bin ich ebenfalls sehr glücklich geworden, besser hätte es nicht werden können

[bgeltenpoth]

Hallo,

vielen Dank für die Anmerkungen ich werden mit DXGetText mal anschauen

[Rollo62]

Mit dxGetText arbeite ich auch in einem Projekt mit einem angepassten Gorm-Editor weil
das Orginal PO-Edit nicht ganz mein Fall ist.
Aber das Projekt ist schon sehr undurchsichtig, und ich meine so aus dem Bauch heraus
das ganze könnte viel schlanker sein.
Die dxGnugettext.pas hat so ca. 150 kB Sourcen.

Dazu gibt es noch verschiedene Versionen und auch ein JEDI JvGnugettext, so das ich nie wirklich
sicher bin was denn nun eigentlich der richtige dxGnugettext ist.

Für Firemonkey scheint dxGnugettext wohl noch keine Portierung zu geben, oder ist das schonmal jemanden
untergekommen ?

Rollo

[Cubysoft]

Ich habe mitlerweile eine eigene Klasse geschrieben, mit der ich Lnaguage-Files direkt aus den Ressourcen laden kann. Ich weiß nicht ob die Klasse alle Wünsche erfüllt, aber in meinem Projekt läuft sie einwandfrei. Wenn jemand interesse hat, kann ich mein Werk gerne mal posten

[Sherlock]

Wenns auch etwas Geld kosten darf, kann ich uneingeschränkt den Sisulizer empfehlen. DFMs werden ohnehin übersetzt, und im Strings im Quellcode einfach zu resourcestrings machen (Gibt ja ein Refaktoringtool dafür). Und schon bekommt man einfache Lokalisierung inklusive wiederverwendbarer Übersetzungs-DB und einem schicken kostenlosen Tool, das man an Übersetzer geben kann.

Sherlock

[nuclearping]

Zitat von Sherlock:

Wenns auch etwas Geld kosten darf, kann ich uneingeschränkt den Sisulizer empfehlen. DFMs werden ohnehin übersetzt, und im Strings im Quellcode einfach zu resourcestrings machen (Gibt ja ein Refaktoringtool dafür). Und schon bekommt man einfache Lokalisierung inklusive wiederverwendbarer Übersetzungs-DB und einem schicken kostenlosen Tool, das man an Übersetzer geben kann.

Sherlock

Wenn ich mir deren Seite so anschaue, scheint diese Lösung aber die gleichen Probleme und Einschränkungen zu haben, wie das Board-Werkzeug von Delphi?

- Umständlich
- Aufgebläht
- Resourcenstrings
- Localized Builds

Zitat:

Now that your translator has finished translating all of your strings, and you've received your updated file, simply run Sisulizer to build the new version of your program in the new language.

So wie das klingt gibt es dann für jede Sprache eine eigene Anwendung?

Wir haben für unser Projekt eine eigene Lösung entwickelt, die eine extreme "Lightweight"-Variante von GNU GetText ist.
Der Source des Parsers zum extrahieren der Texte ist ~30kB groß.
Die Localizer-Unit ist nur 18kB und arbeitet nach dem gleichen Schema, also Formulare werden per L.Translate(Self) übersetzt und Texte im Code per LabelX.Caption := L['Hallo Welt'] gekapselt.
Dazu haben wir noch einen WYSIWYG-Editor geschrieben, der die Bearbeitung im Tabellenformat, wie Excel, ermöglicht.

Damit betreiben wir unser Projekt schon seit fast 10 Jahren und hatten bei keiner Sprache bisher irgendwelche Probleme, egal ob Deutsch, Englisch, Russisch, Japanisch, ...

Verstehe nicht, wieso Firmen / Entwickler solche aufgeblähten und umständlichen Tools für so eine simple Sache entwickeln und / oder nutzen?