On 2007-07-05, at 10:11 AM, Jan Krutisch wrote:
Hallo Benjamin,
Am 05.07.2007 um 09:48 schrieb Benjamin Krause:
alles in allem erscheint mir globalize fuer komplexere webseiten
durchaus angebracht.. es kommt aber halt in der tat darauf an, wie
umfangreich deine seite sein wird. fuer einfache applikationen
reicht gettext oder gloc durchaus..
Das ist 'ne interessante Schlussfolgerung. Was für Vorteile siehst
du bei "komplexen" Webseiten (Wie auch immer man das Kriterium
definiert) für globalize?
Hey ..
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.
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)
- l10n wird unterstuetzt (nummern-, datumsformate), die vorgaben fuer
l10n sind gleich mit dabei (fuer quasi alle laender)
- Support fuer sprintf-like statements .. also z.b. "The user %s
could not be deleted" .. bei gettext muss ich sowas erst dazubauen
- ein Currency-Model kommt gleich mit
- Model-Translations sind nahtlos integriert.
- Ich bekomme automatisch eine Liste der noch zu uebersetzenden
Strings, d.h. ich kann kein String vergessen.
Alles in allem bin ich froh, bei einer "komplexeren" Webseite wie
omdb.org nicht auf gettext gesetzt zu haben. Andere Loesungen wie
gloc oder Gibberish hab ich mir auch noch nicht genauer angesehen..
aber nach mehreren gettext/globalize projekten wuerde ich nur noch
bei apps in der groessenordnung wie bratwurst-on-rails.com auf
gettext setzen. :)
Ben
_______________________________________________
rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug
