Hallo,
Am 05.07.2007 um 00:18 schrieb Daniel Weinand:
Hallo,
wer hat Erfahrung mit der Internationalisierung von Rails
Anwendungen. Ich möchte eine neue Anwendung von Anfang an
darauf auslegen. In [1] wird Ri18n vorgeschlagen. Allerdings
scheint das Ri18n Projekt schon relativ lange nicht mehr gepflegt
zu werden.
[ACHTUNG: Für alle, die meinen Vortrag auf der Railskonferenz gesehen
haben, wirds jetzt langweilig]
Mit Internationalisierung ist es so ein bisschen wie mit Caching,
auch hier greifen die two rules of optimization:
1. Don't do it
2. Don't do it NOW.
Warum? Je nach verwendeter I18n-Lösung steht einem der Kram bei der
Entwicklung mehr oder weniger doll im Weg, d.h. Turnaround-Zeiten
verlängern sich, Workflows werden komplizierter, etc. Ich würde mir
daher wirklich gut überlegen, ob eine I19g wirklich notwenidig ist,
oder ob das eher so ein "könnte ja eventuelll vielleicht unter
Umständen mal sinnvoll sein"-Ding ist. Sollte das zutreffen, mach die
Internationalisierung dann, wenn Du sie brauchst. Das ist u.U. ein
bisschen schmerzhaft, weil es viel Aufwand auf einmal ist (je nach
lösung mehr oder weniger), aber sicher weniger problematisch als die
ganze Zeit den Overhead mit sich rumzuschleppen.
(Es gibt Leute, die sind da grundsätzlich anderer Meinung, die auch
schon andere Erfahrungen gemacht haben. Das ist also nicht absolut zu
sehen, sondern nur meine Erfahrung.)
That beeing said kann ich Martin nur beipflichten, was die
Schlussfolgerungen angeht. Zu Thomas' und Ralfs Ehrenrettung sei
gesagt, dass die beiden in der neuen Auflage des Buches auch eher
ruby/gettext als Lösungsansatz verfolgen, ebenso wie Ramon und ich in
unserem Buch übrigens :)
Will sagen: ruby/gettext (eventuell mit dem Plugin gettext_localize)
scheint auch mir die 1. Ausgereifteste Lösung zu sein (gnu gettext
wird seit x Jahren erfolgreich für die lokalisierung von sehr sehr
sehr vielen aus dem Unix-Bereich stammenden Programmen eingesetzt)
und 2. Workflows am besten zu unterstützen (ich sag mal PoEdit) und
nicht zuletzt 3. für Entwickler sehr viel transparenter als andere
Lösungen zu sein.
Globalize hat seine Schwächen, insbesondere finde ich den Ansatz, UI-
Texte mit Modellübersetzungen und überhaupt dem Rest des Contents in
der selben Datenbank zu speichern nicht so prickelnd, da für mich die
UI-Texte ganz klar Teil der Applikation sind und daher auch
ablagetechnisch (Stichwort Versionskontrolle) zur Applikation
gehören. Die Stärken liegen, wie Martin schon erwähnt hat, ganz klar
in den zusätzlichen Features (wobei die Model-Translation auch noch
nicht wirklich ausgereift ist) und für Anwendungsfälle wie BookMooch
oder ähnlichem, wo man die Übersetzung den Benutzern überlassen will
(dann macht es Sinn, die Sachen in der DB abzulegen, nech)
Alle anderen Lösungen (localization, gloc, globalite, gibberish)
erschienen mir nach meiner Recherche für den Konferenz-Vortrag eher
"egal" zu sein. Sie wollen alle bestimmte Dinge neu machen, verraffen
(meiner Meinung nach) alle das bei Gettext nahezu perfekt gelöste
Workflow-Thema und sind alle irgendwie unfertig. Man kann sicher alle
Lösungen einsetzen, ich sehe allerdings keinen Vorteil darin, NICHT
gettext einzusetzen :)
In entwas ausführlicher könnt Ihr Euch das demnächst dann auch noch
im Video von der Konferenz ansehen, das dauert allerdings leider noch
ein paar Tage.
Gruß,
Jan_______________________________________________
rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug
