$ export GETTEXT_PATH=locale
$ mkdir locale/es/LC_MESSAGES
$ rmsgfmt locale/es/hello.po -o locale/es/LC_MESSAGES/hello.mo
When we run the script with our locale set to es_MX.UTF-8, gettext searches a series
of paths under GETTEXT_PATH (including locale/es/LC_MESSAGES) for an appropriate
.mo-file. Finding the one we just created, it displays the properly localized text:
$ LC_ALL=es_MX.UTF-8 ./hello.rb
??Hola, mundo!
This is a very simple example, but it illustrates many of the basic aspects of gettext.
There is a document available detailing how to integrate the Ruby bindings to gettext
into a Rails application. See http://manuals.rubyonrails.com/read/chapter/105 for the
full explanation and source files. This is essentially a do-it-yourself approach; it is a
thin layer on top of gettext, and you have to fill in some of the gaps (such as allowing
Rails L10n | 253
users to change their locale and dialect) yourself. But there are good examples on
that page, and it is a good start. Also see http://jonathan.tron.name/articles/2007/03/
30/gettext-and-rails for a few miscellaneous concerns if you decide on this approach.
Gibberish
Gettext has a few disadvantages, the primary one being that translated strings are
keyed by the original string. Under gettext, even changing "Hello, world!" to "Hello
world!" would require updating that entry in every .po file and recompiling everything.
Pages:
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395