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:

1. Harvesting messages among the code and indexing them to be translated. For an external module, this is explicitly performed with the xgettext external binary, that is part of the gettext external application, and that is called by the tbx_generate_pofile Scilab function. In Scilab, it is also possible to use tbx_build_localization(..) or tbx_make . localization, that both call tbx_generate_pofile(..).

   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 gettext input 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	gettext(["item#1", "item#2"])	NOK	Only "item#1" is collected. "item#2" is ignored.
   6	gettext(["item#1" "item#2"])	NOK	"item#1item#2" is indexed. Then, since "item#1" and "item#2" are unknown separate msgid, retrieving their respective translation will fail.
   7	gettext(["item#1" "item#2"])	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 gettext occurrences that specify a domain. It ignores any call to gettext with only one input argument. Harvesting does not need to beforehand declare the domain with addlocalizationdomain()

2. 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.

3. 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 tbx_generate_pofile() another time.

4. Finally, some calls like gettext(message) or 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 domain where the message and its translations can be found must be specified, as in gettext(domain, message) or gettext(domain, "The message content"). In this case, addlocalizationdomain(domain, path) must be run before in order to make domain pointing 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") call. However, it is not mandatory. Hence, a piece of code like if %F, gettext("The literal message"), end will never execute the gettext call, but is nevertherless meaningfull: It is here only to make the message visible to the xgettext scanner/harvester. Then, somewhere else in the code, it will be possible to use msg = "The literal message"; gettext(msg) to return the translated version.

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 xgettext 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 in a language other than the current session's one. If this is really required, the session's language will have to be temporarily switched to the desired language, then gettext() called, and at last the initial session's language restored. from a translated version rather than from the message id in english.

Messages

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 gettext() or _() is used in an XML 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").

• 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 xgettext scanner nor by the gettext function. 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 input custom 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.