Hello all.
Salikh Zakirov wrote:
far below are results of my experiments with Log4cxx's ResourceBundle.
(I've managed to find it in Log4cxx documentation after carefully
rereading your original post).
The good news is that it does localization (severely limited).
The prototype has following
Salikh Zakirov wrote:
Geir Magnusson Jr wrote:
I'll state the obvious... there is another thread going on about how do
to similar things with Classlib. Maybe you can find common ground for
message bundles and such...
geir
1. The launcher already packages some translations in
Vladimir Gorr wrote:
Continue this discussion?
Vladimir,
far below are results of my experiments with Log4cxx's ResourceBundle.
(I've managed to find it in Log4cxx documentation after carefully
rereading your original post).
The good news is that it does localization (severely limited).
The
Geir Magnusson Jr wrote:
I'll state the obvious... there is another thread going on about how do
to similar things with Classlib. Maybe you can find common ground for
message bundles and such...
geir
1. The launcher already packages some translations in property-format,
it makes me believe
Salikh Zakirov wrote:
Geir Magnusson Jr wrote:
I'll state the obvious... there is another thread going on about how do
to similar things with Classlib. Maybe you can find common ground for
message bundles and such...
geir
1. The launcher already packages some translations in
Hi, Vladimir
Log4c and log4cpp are both good tools, but if our requirements are just
message internationalization, maybe log4cxx is overkill? After all, as a
complete log framework, it provides supports to i18n, category, layout
And if we talk about ResourceBundle only, I'd suggest
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
On 7/13/06, Paulex Yang [EMAIL PROTECTED] wrote:
Hi, Vladimir
Log4c and log4cpp are both good tools, but if our requirements are just
message internationalization, maybe log4cxx is overkill? After all, as a
complete log framework, it provides supports to i18n, category,
layout
And if we
Vladimir Gorr wrote:
On 7/13/06, Paulex Yang [EMAIL PROTECTED] wrote:
Hi, Vladimir
Log4c and log4cpp are both good tools, but if our requirements are just
message internationalization, maybe log4cxx is overkill? After all, as a
complete log framework, it provides supports to i18n, category,
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
Vladimir Gorr wrote:
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.
I think this is the case of good intentions, which
Vladimir Gorr wrote:
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
...
Please let me know your opinions/objections.
To make my point clearer, I would repeat my suggestion.
0) Agree on a design decision that the message key
is the
On 7/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
...
Please let me know your opinions/objections.
To make my point clearer, I would repeat my suggestion.
0) Agree on
Salikh Zakirov 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
I'll state the obvious... there is another thread going on about how do
to similar things with Classlib. Maybe you can find common ground for
message bundles and such...
geir
Vladimir Gorr wrote:
Hi Harmony community.
I'd like to discuss with you a design for the VM native code
On 7/13/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
On 7/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
...
Please let me know your opinions/objections.
To make my
Geir Magnusson Jr wrote:
Salikh Zakirov wrote:
Why not use GNU gettext -- de facto standard i18n system on GNU/Linux
systems?
Isn't it under the GPL?
The runtime part (libintl) is LGPL, so it allows linking to non-GPL programs.
The tools are indeed GPL, but Harmony project is not going
-Original Message-
From: Salikh Zakirov [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 10:32 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] proposals for VM internationalization
Geir Magnusson Jr wrote:
Salikh Zakirov wrote:
Why not use GNU gettext
Vladimir Gorr wrote:
Have you looked at the patch I've sent? It doesn't use gettext.
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
Andrew Zhang wrote:
Vladimir Gorr wrote:
namely, ICU4C or
LOG4CXX or combination of them.
log4cxx is already used in DRLVM. It does not provide localization services.
If only for i18n, icu4c is prefered.
So, would the following solution be acceptable to all?
1 mark the localizable strings
Magnusson, Geir wrote:
Do you mean there won't be any runtime dependencies? We can't
distribute LGPL-ed binaries.
In this case, libintl is definitely out of question.
However, I like the simplicity of _() interface.
I think we can use it with ICU4C too.
I don't know if this is being considered, but
1) Classlib has lots of java internationalization needs, and some native
internationalization needs
2) DRLVM has lots of native internationalization needs, and some java
needs (kernel classes).
So it seems clear to me we need to at least try for a
Geir Magnusson Jr wrote:
I don't know if this is being considered, but
1) Classlib has lots of java internationalization needs, and some native
internationalization needs
2) DRLVM has lots of native internationalization needs, and some java
needs (kernel classes).
FWIW, I as far as I can
we stand corrected. Both need localization, and we should be able to
find commonality in the approaches.
geir
Salikh Zakirov wrote:
Geir Magnusson Jr wrote:
I don't know if this is being considered, but
1) Classlib has lots of java internationalization needs, and some native
24 matches
Mail list logo
