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 goo
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
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 i
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 bel
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 pr
On 7/13/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote:
Vladimir Gorr wrote:
Have you looked at the patch I've sent? It doesn't use gettext.
What about
* ---8<--- apples.c
#include
#include
#define _(String) gettext(String)
*
you mentioned about before?
It just proposes the way to move fo
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
>> inter
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 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 co
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.
-
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 str
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 xg
> -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
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 go
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.
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
> i
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
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) Agr
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 *u
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
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:
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,
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:
> 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 th
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 cons
Hi Harmony community.
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
We'd like to consider this approach for the DRLVM first of all. However it
can be suitable for other parts of Harmony project I suppose.
Please let me know your opinions/o
26 matches
Mail list logo
