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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
