indexes or/and translates some indexed english messages
Alias of gettext().
gettext("The literal reference message") gettext(["item #1" ; "item#2"]) translated = gettext("The literal reference message") translated = gettext(["item #1" ; "item#2"]) translated = gettext(msgid) .. gettext(domain, ..)
- "The literal reference message"
Single literal text of an english message to be indexed or/and translated. A column of literal texts explicitly separated with semi-colons may also be specified.Only standard ASCII characters can be used. Any other extended ASCII or UTF-8 characters would make gettext() failing.
single or array of messages identifiers (in english) to be translated, in a variable.Only standard ASCII characters can be used.
Input messages translated in the current language of the Scilab session. If no translated version is available for an input message, the input version in english is returned. The input and output arrays have the same sizes.These messages are defined in the ./locales/*.po files. They can include extended ASCII or UTF-8 characters.
word of text: the name of a domain. When localizing an external module,
domainmay be usually set to the technical name of the module.
domaincan indifferently be a literal or a variable. It is case-sensitive.
domainis required by
tbx_generate_pofile()to make the literal msgid string indexed (harvesting stage. See below).
gettext(domain, msgid)is used to retrieve the translated version,
domainis used to get the path to the directory where translations are stored, as beforehand registered with
Harvesting messages and overall processing
gettext is a free and open external application shipped within Scilab to support multilinguism for messages. This support consists in 4 main stages:
Harvesting messages among the code and indexing them to be translated. For an external module, this is explicitly performed with the
xgettextexternal binary, that is part of the
gettextexternal application, and that is called by the tbx_generate_pofile Scilab function. In Scilab, it is also possible to use
tbx_make . localization, that both call
Each collected message is considered as an identifier (a message id, = msgid) for all its forthcoming translations. In Scilab, the reference language for identifiers is english. Therefore, the msgids to be indexed must be written in english.
Only single literal and in one piece messages being as
gettextinput argument are collected. Hence, the following syntaxes and cases won't index the considered message, and no further translated versions will be available:
# Syntax Status Harvesting results 1
gettext("To be translated")
OK standard syntax 2
msg = "To be translated"; gettext(msg)
NOK The text is in a variable. It is not a literal. It won't be indexed. Nevertheless, this syntax will work to retrieve the translated version, provided that the message has been collected elsewhere in a right way. 3
gettext("To be" + " translated")
NOK "To be" and " translated" are indexed as 2 separate msgid. Then, since the concatenated msgid "To be translated" does not exist, retrieving its translation will fail. 4
gettext("To be" + .. " translated")
NOK Same as #3 5
NOK Only "item#1" is collected. "item#2" is ignored. 6
NOK "item#1item#2" is indexed. Then, since "item#1" and "item#2" are unknown separate msgid, retrieving their respective translation will fail. 7
NOK Same as #6 8
gettext(["item#1" ; "item#2"])
OK "item#1" and "item#2" are indexed as separate msgids. 9
gettext(["item#1" ; "item#2"])
OK Same as #8. Please take care of the semi-colon. Without it, the case #7 fails.For an external module, tbx_generate_pofile() harvests only
gettextoccurrences that specify a
domain. It ignores any call to
gettextwith only one input argument.
Harvesting does not need to beforehand declare the
All indexed texts are then translated by the author of the code or by some contributors. Anyway, by some humans. Good translation tools are also available online.
All translated versions are bundled in a way that
gettext(..)becomes efficient to retrieve the version in the current session's language. This is done by running
Finally, some calls like
gettext("The message content")are used to retrieve and return the translated version.
When the message is not a native Scilab one (for instance it is specific to an external module), the
domainwhere the message and its translations can be found must be specified, as in
gettext(domain, "The message content"). In this case,
addlocalizationdomain(domain, path)must be run before in order to make
domainpointing to the storage directory.
Most often, a message is declared to be harvested and is used to retrieve its
translated version through the same
gettext("The literal message")
However, it is not mandatory. Hence, a piece of code like
if %F, gettext("The literal message"), end will never execute
gettext call, but is nevertherless meaningfull: It is here only
to make the message visible to the
Then, somewhere else in the code, it will be possible to use
msg = "The literal message"; gettext(msg) to return the translated
As well, using several times the same literal
gettext("The literal message") call won't be rare, for example to
retrieve the translation in several files. In this case, the
harvester will collect the message only once, and the same translation will be returned
for all calls.
Limitations: There is no way to translate a message
To be correctly processed, english messages must comply with a few rules:
Messages identifiers are case-sensitive.
Literal harvestable messages may be indifferently delimited with single or double quotes.When
_()is used in a XML or XSL file such as in the preferences files of an external module, the literal domain string and the literal message id must no longer be delimited. For instance,
_(my_domain, My message)will be used instead of
_("my_domain", "My message").
In addition, spaces before and after the messageID are then never taken into account and never belong to the message. For example, the actual message ID corresponding to
_(my_domain, My message: )is
"My message:", not
" My message: ".
Double quotes must be avoided in the body of messages. Please use single quotes.
Inner escaped sequences like "\t" "\n" etc are not interpreted, neither by the
xgettextscanner nor by the
gettextfunction. They are collected and stored as is in the messages.
Some template messages may often include some "%" C-like directives aiming to be replaced with some custom input data through
msprintf()at run time. For instance,
msprintf("Hi %s, could you come at %s today?", "John", "12:30")will return
"Hi John, could you come at 12:30 today?".
Now, let's assume that you wish to make the template message translatable:
msg = _("Hi %s, could you come at %s today?")and
msprintf(msg, "John", "12:30")will be used. However, the author or/and translaters must be aware that, in the translated versions, the input data must appear in the same order: "%s" for "John" before "%s" for "12:30", to comply with the order imposed by the
msprintf()input list of values. This is not always possible, noticeably for languages far from latin like right-to-left languages.
setlanguage("fr"); // Messages ids are case-sensitive: // "monday" is not an indexed native msgid, while "Monday" is: gettext(["monday" ; "Monday"]) //_() is an alias of gettext(): _("Sunday") // In Scilab, messages ids are in english: setlanguage("ru"); _("Dimanche") // The french version can't be used as msgid _("Sunday")
--> gettext(["monday" ; "Monday"]) ans = !monday ! !Lundi ! --> _("Sunday") ans = Dimanche --> setlanguage("ru"); --> _("Dimanche") ans = Dimanche --> _("Sunday") ans = Воскресенье
Using a domain: Here, "tbx" is a predefined domain used to test translation features:
setlanguage("fr"); msg = "%s: something not in Scilab.\n"; // unknown in the main native Scilab domain: gettext(msg) // So, it is returned as is. // If we use the domain without having declared it before, // Scilab does not know where to find the translation: gettext("tbx", msg) // The input message is still returned as is. // So, let's declare the domain: addlocalizationdomain("tbx", "SCI/modules/localization/tests/unit_tests/locale"); gettext("tbx", msg) // Now it works // The answer is a joke: Here it is still in english (while french is expected). // The point is that it has been set as the french translation of the input msgid. // The same msgid can be used as a native Scilab one with its native translations, // and in one or several domains, with other translations: msg = "%s: No more memory.\n"; [_(msg) ; _("tbx", msg)]
--> msg = "%s: something not in Scilab.\n"; // unknown in the main native Scilab domain: --> gettext(msg) ans = %s: something not in Scilab.\n --> // Scilab does not know yet where to find the translation: --> gettext("tbx", msg) ans = %s: something not in Scilab.\n --> // We declare the domain: --> addlocalizationdomain("tbx", "SCI/modules/localization/tests/unit_tests/locale"); --> gettext("tbx", msg) // Now it works ans = %s : it is true, that is not in Scilab.\n --> msg = "%s: No more memory.\n"; --> [_(msg) ; _("tbx", msg)] ans = !%s : Plus de mémoire disponible.\n ! !%s : Overwrite Scilab translation.\n !
- msprintf — データを変換,整形し,文字列に書き込む
- setlanguage — chooses the language used for standard messages and help pages for the current session
- addlocalizationdomain — ローカライゼーション機構に新規ドメインを追加.
- tbx_generate_pofile — Extract localized strings from toolbox sources (toolbox compilation process)
- tbx_make . localization — Builds a toolbox having a standard structure (EXPERIMENTAL)
- tbx_build_localization — Build localization "mo" file from "po" files (toolbox compilation process)
- GNU gettext website
|5.5.0||Domain management added.|
|Report an issue|
|<< getlanguage||Localization||setdefaultlanguage >>|