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 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 –
> {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]
