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 Fri, 14 Jul 2006 05:33:04 GMT
On 7/13/06, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:
>
> Vladimir Gorr wrote:
>
> Have you looked at the patch I've sent? It doesn't use gettext.


What about

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

#define _(String) gettext(String)
*
you mentioned about before?

It just proposes the way to move forward towards propertly localized DRLVM.
> I think we will be able to use ICU4C java-like localization in the
> following way:
> * extract localizable strings from .cpp files using xgettext


Do I correctly understand there are some doubts about the license for these
utilites?
I mean if *we can't distribute LGPL-ed binaries (Geir said) *whether can we
distribute the output from them?

* process resulting .po files and autogenerate resource bundles from them
> * use resource bundles for translation and distribution

> There is an essential obstacle to use the *gettext* approach.
> > It's impossible to run VM on Windows platform if not to take into
> account
> > CYGWIN environment.
>
> I do not insist on using gettext, but will answer just for the record:
> there exists a project to port libintl to native Windows using MinGW [1]



What about Geir' note for this?

> I'm not clear as well how we will merge the previous .po catalogs (already
> > translated) with new ones (when new strings to be added).
>
> Again, I do not insist on using gettext,
> however, gettext has the tool exactly for this task: msgmerge [2]


Thanks for information. However I understood we will not (or cannot) use
these tools, right?

> However _() should be inserted for all strings (and then deleted?) to
> > achieve this. It involves too big efforts.
>
> The effort could be big, but is needed for any localization system we use.
> The task to classify the messages to translatable (visible to user on a
> day-to-day
> basis) and non-translatable (internal errors and debug logging) is needed
> anyway,
> because we do not want to overload translators with useless work of
> translating
> every string in the project.


Agree we need to strain. However there are the works we need to perform
and some addditional ones we can avoid to facilitate our life, right?

IMHO, _() marker is visually the prettiest way mark localizable strings.
> (compared to "// NON-NLS" comments and resource bundle constants)
>
> > Therefore my preference is to use more universal approach, namely, ICU4C
> or
> > LOG4CXX or combination of them.
>
> I've looked through Log4cxx manual and haven't found anything concerning
> both localization
> and internationalization.


Indeed, some extension of LOG4CXX needs to achieve this. Sorry it was not
clear from design document.

| By the way, DRLVM already uses Log4cxx.

Therefore we suggested to use it.

ICU4C provides both internationalization and localization services [3].
> It's native system uses ResourceBundles and looks similar to Java
> localization system,
> and it suffers from the same drawback: the message keys are constants,
> which are
> never printed, but have to be defined and referenced in multiple places.
>
> The developer overhead to make a localizable message is as high as
> * define a new constant in some file
> * add a message to the default resource bundle
> and inolves editing multiple files. I have no doubt that this overhead
> significantly higher
> than putting three characters to mark the string in _() way.


I have no objections against this. If we can use xgettext output & msgmerge
we will use them.
Continue this discussion?

Thanks,
Vladimir.

--
> Salikh.
>
> [1] http://gnuwin32.sourceforge.net/packages/libintl.htm
> [2]
> http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC36
> [3] http://icu.sourceforge.net/userguide/localizing.html
>
> ---------------------------------------------------------------------
> 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