Hi,
Am 05.07.2007 um 10:26 schrieb Benjamin Krause:
zunaechst halte ich gettext fuer nicht sehr praktikabel, da das
konzept der po/mo files IMHO nicht gut zu bearbeiten ist. Es kommt
hier aber sicher auf die menge der zu uebersetzenden strings an.
Ich finde es angenehmer, meine uebersetzungen in den fixtures zu
halten, statt mit mo und po files zu hantieren.
Hm. Ich finde gerade den Vorteil von Gettext, das es eine Reihe von
Tools gibt, mit denen man die Dinger übersetzten kann. po/pot-Files
von Hand zu bearbeiten ist mühsam, zugegeben.
Der große Vorteil von po/pot-Dateien ist allerdings, dass sie
Metadaten zu den Strings speichern können, so daß man z.B. hilfreiche
Kontext-Informationen dazuspeichern kann, Übersetzer Kommentare
dazuspeichern können und, nicht zuletzt, Workflow-Funktionen
unterstützt werden. Das alles macht die Dateien komplizierter, aber
eben auch mächtiger.
Die Hauptvorteile ggü. gettext sehe ich in:
- uebersetzungen via fixtures/db (d.h. ick kann z.B. redakteuren
ein web interface zum uebersetzen an die hand geben)
Genau das hat sich bei uns wegen der Sync-Probleme zwischen den
verschiedenen Environments so gar nicht bewährt.
- l10n wird unterstuetzt (nummern-, datumsformate), die vorgaben
fuer l10n sind gleich mit dabei (fuer quasi alle laender)
Das ist sicher ein Vorteil. Hier greift ja das von mir erwähnte
Plugin an, was solche Dinge, wo sie denn bei Gettext noch fehlen,
nachrüstet. Zugegeben, die Datenbasis von Gettext ist schon ganz nett.
- Support fuer sprintf-like statements .. also z.b. "The user %s
could not be deleted" .. bei gettext muss ich sowas erst dazubauen
Ja. Wir reden hier über folgendes (für die Perspektive):
l("The user %s could not be deleted", user.name) # globalize
versus
_("The user %s could not be deleted") % user.name # gettext
Das ist allerdings auch mein Hauptkritikpunkt an ruby/gettext, das
man eben viele Dinge auf dem "gettext"-weg statt auf dem "rails"-weg
lösen muss, z.B. auch pluralisierungen.
- Ich bekomme automatisch eine Liste der noch zu uebersetzenden
Strings, d.h. ich kann kein String vergessen.
Hm. Genau das ist doch aber des gettexts größte Stärke. Nach einem
updatepo-task werden alle fehlenden Strings in die pot/po-Dateien
eingetragen und neue strings als "neu" markiert, so dass z.B. PoEdit
die fehlenden Strings hervorheben kann.
Klar bekommt man die Information bei Globalize auch, aber, wenn ich
das richtig sehe, ja nur dann, wenn die entsprechende Methode
mindestens einmal aufgerufen wird, oder? Ich habe bei meiner
Recherche jedefalls keine Möglichkeit gefunden, analog zu gettext
einmal über die Anwendung zu greppen um die missing strings
rauszusuchen. (Zugegeben, das selbst zu bauen ist nicht sonderlich
komplex)
Gruß,
Jan_______________________________________________
rubyonrails-ug mailing list
rubyonrails-ug@headflash.com
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug
