harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Gorr" <vvg...@gmail.com>
Subject Re: [drlvm] proposals for VM internationalization
Date Thu, 13 Jul 2006 07:41:55 GMT
In my opinion using the gettext() for the i18n goals will involve too big
re-factoring of source code.
I also disagree with the 'no-meaning' for message key. All we need is to
create the sensible ID for these messages.

*4) Add to this that most of the developers will not know where the
localized messages are kept,
and you'll get the situation when most of the messages are not localized in
any way.
*
I'm not sure the gettext() will eliminate this issue.

Thanks,
Vladimir.

On 7/13/06, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:
>
> 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} C 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 kept,
> 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 C
> > {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" plural,
> 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", ".");
>    textdomain("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;
> }
> ---8<---
>
> 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
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message