Sputnik's user interface is internationalized. (Хотите по-русски? Tem português tambem.)

At the moment, English, Portuguese, Russian, and Spanish translations are available.

How to Use

To select interface language, set the following parameter in the "sputnik/config" node:

INTERFACE_LANGUAGE = "pt_BR"

For the list of available languages (or to add new ones), please see the "sputnik/translations" node.

If your language is not available and you want to make a translation, read on.

How It Works

Translation strings are marked in the templates with _(...), for example: _(HI_USER). This syntax looks (intentionally) like the one used by gettext, but our approach is a bit different and is more explicit. What goes inside the _(...) is a variable name, which should not have any spaces, punctuation, etc. E.g.:

_(HI_USER) (<a $logout_link> _(LOGOUT) </a>)

Those variables are replaced with values that are taken from a special "translation" node (currently "sputnik/translations"). This node contains Lua code, which assigns to each variable a table with one string value per language, e.g.:

HI_USER = {
   en_US = "Hi, $user!",
   ru    = "Салют, $user!",
   pt_BR = "Olá, $user!", 
}

So, if Sputnik is being run with Russian interface (ru), _(HI_USER) will be replaced with the value of HI_USER.pt_BR, which is "Салют, $user!".

Note that translated strings can contain Cosmo variables. The translation happens before Cosmo substitutions is run, so Cosmo will already see a translated template - something like:

Olá, $user! (<a $logout_link> Sair </a>)

Optionally (purely for documentation purposes), those Cosmo variables can also be included inside _(...):

_(HI_USER $user)

This would be equivalent to _(HI_USER), but has the advantage of alerting the reader of the template that the translated template will have a Cosmo variable here.

Languages, Dialects and Fallbacks

Each language should be identified in the translation tables by its two letter or three letter code (see IANA registry, followed by the necessary subtags, which could be regional or other, using IANA subtags when possible, e.g. pt_BR (Brazilian Portuguese), en_GB (British English), es_AR (Argentinian Spanish), zh_Hant_SG (Mandarin Chinese in traditional characters, Singapore style).

To avoid duplication, however, one language can rely on others for fallback.

E.g., since many of the strings would be the same for pt_BR and pt_PT, it is sufficient to provide pt_PT translations only for those strings that are different in pt_PT and pt_BR and specify pt_BR as a fallback language for pt_PT or for any variation of Portuguese. The fallbacks are specified in the FALLBACKS variable:

FALLBACKS = {
    pt = "pt_BR",           -- pt_* falls back on pt_BR
    en = "en_US",           -- en_* falls back on en_US
    zh_Hans = "zh_Hans_CN", -- simplified Chinese falls back on PRC Chinese
    zh_Hant = "zh_Hant_TW", -- traditional Chinese falls back on Taiwanese spellings
    _all = "en_US",         -- everything falls back on en_US
}

Bidirectional Text?

There is no support for bidirectional text (Arabic, Hebrew) at the moment, but if someone is interested in helping, we can try to do something about it.