Rails L10n | 255Globalize that compete with gettext, Gibberish, and the other text-based localiza-
tion libraries commonly used with Rails. Later, we will examine some of the other
features that make Globalize so compelling.
As is the custom, Globalize provides a simple method to access translations of a
string; it can be called asString#torObject#_(the latter is provided for gettext
compatibility):
<% Locale.set("es-MX") %><%=h "Hello, World!".t %>
==> Hello, World!<%=h _("Hello, World!") %>
==> Hello, World!However, there is a twist. Unlike gettext and Gibberish, which both use text files to
store translations, Globalize uses the database. Since we had no Mexican Spanish
translation for “Hello, World!”, Globalize passed it through, storing the “Hello,
World!” tag in the database for future reference when you need to translate. This
replaces gettext’s harvesting phase and uses the strings themselves from your appli-
cation to determine what needs to be translated.
When we do add a translation to the database, it works as expected:
Locale.set 'es-MX'
Locale.set_translation 'Hello, World!', '¡Hola, mundo!'puts "Hello, World!".t
# >> ¡Hola, mundo!Globalize also tries to capture all of the Rails error messages and add them to the
table, to be localized. When they have been translated, Globalize will intercept them
and replace them depending on the current locale.
Globalize includes a collection of data about the world’s languages, to minimize the
amount rote translation of common data. Data provided includes the following:
- ISO codes, English names, and native names for each language (for example,
“FR,” “French,” and “Français”). - Pluralization rules (for example, is “0 items” inflected the same as “1 item,” or
the same as “2 items,” as in English?). - Writing direction (left-to-right or right-to-left).
- Date, currency, and number format (for example, “12,345.67” versus “12.345,67”)
for each locale. - Translation of date information (weekday and month names) for most languages.