harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <Salikh.Zaki...@Intel.com>
Subject Re: [drlvm] proposals for VM internationalization
Date Thu, 13 Jul 2006 07:05:22 GMT
Vladimir Gorr wrote:
> Internationalization design *1. Introduction*
> ...
> The key idea is to use ResourceBundle class from apache log4cxx which allow
> to store and effective use bundles with localized messages.

Why not use GNU gettext -- de facto standard i18n system on GNU/Linux systems?
I think the developers' API can be a designed to allow a wide range of
i18n implementations, just like we did with logging.

(* DRLVM logging system was designed in such a way, that its implementation
   could be rewritten completely from scratch. It was in fact rewritten once
   to use log4cxx. No client code modifications were required *)

I think we could devise a simple localization API, which even could be dummy
to get us started, like

----8<----- vm/include/l10n.h
#define _(x) (x)
inline void init_l10n() {}

Scan over the DRLVM code, mark the translatable strings with _(),
and then evolve the l10n system independently of the development efforts.

> MessageId1=localized message1
> MessageId2=localized message2
> Where:
> MessageId{i} – ASCII string on English language. It should consist of vm's
> subcomponent name ( e.g. init, port, gc.) and short description of message.
> E.g. "init.help" is localized help message from "init" subcomponent of VM.

The gettext has an advantage, that the "unlocalized" messages are used as the
keys for the translation, thus, the developers do not need to care about
l10n at all. 

On the other hand, in the system you propose, to create a message,
one will need to
1) come up with the message identifier
2) add the message identifier and it's unlocalized text to the resource file

and, most annoyingly,

3) consult resource file each time s/he wants to know, what message is printed,
because in most cases, the message key will bear no meaning.

(* Compare with the issue we've come across recently: "SecurityException: K00Ec" *)

4) Add to this that most of the developers will not know where the localized messages are
and you'll get the situation when most of the messages are not localized in any way.

With gettext, localizing for developers is as easy as putting _() around your string message,
and leaving *everything* else up to the translators. Even the source code scanning to extract
messages that need to be translated is done automatically with 'xgettext'.

> Localized message can contain parameters. E.g. localized message pattern:
> "This is message on English with two parameters: parameter number one –
> {0}, ...

with gettext, parameters in localized messages is a non-issue. You can use printf
or cout with gettext without any restrictions. You even can teach your program
to use correct plurals.

(* In slavic languages, there is two kind of plurals: 2-4 is "dual" plural, 5-9 is "multiple"
see the concrete example below *)

>   - All localized messages may be printed through apache log4cxx logger.

gettext's job is to translate strings, and then it's up to developer to choose
how to print the message, so this requirement is satisfied by gettext.

>   - Minimize performance impact.

Below is the simple example of using gettext in a toy application to count apples:

---8<--- apples.c
#include <locale.h>
#include <libintl.h>

#define _(String) gettext(String)

int main() {

    bindtextdomain("apples", ".");
    setlocale(LC_ALL, NULL);

    printf(_("internationalized message\n"));
        int i;
        for (i = 0; i < 27; i++) {
            printf(ngettext("%d apple\n", "%d apples\n", i), i);
    return 0;

The translators job then would be to fill in a template with translated messages, like
------8<---- ru/LC_MESSAGES/apples.po
msgid "internationalized message\n"
msgstr "русское сообщение\n"

msgid "%d apple\n"
msgid_plural "%d apples\n"
msgstr[0] "%d яблоко\n" 
msgstr[1] "%d яблока\n" 
msgstr[2] "%d яблок\n"

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message