commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject RE: [logging] Internationalization of log messages
Date Fri, 23 Aug 2002 20:07:42 GMT
A change was made to the users guide this morning, taking the "MUST" out. 
The general guideline remains and is qualified by the term "Enterprise", 
as in "Enterprise Ready".

If you want to develop software that is Enterprise Ready, you should give 
serious consideration to NLS enabled messages.  If you don't, then you 
have more choice.  Realize also that the end-users will also have choice, 
and consider what their criteria are for their choices.

If you NLS enable then:

a) you can use it.
b) you can drop it with minimal effort (remove translated files, leaving a 
default message file).

The reverse is NOT true - if it's not NLS enabled you have no choice.


Richard A. Sitze
IBM WebSphere WebServices Development

The question seems to me to not be whether to do this, if reasonable, but 
how.  The present idea that is questioned is not a good one, and the 
objections are valid.  Why not change the way of doing it so the objection 

goes away?

At 04:36 PM 8/23/2002 +0200, you wrote:
> >
> > I'm not involved in commons-logging, and while I disagree with you a 
> > bit on this, Java is also not an i18nised language yet.
> >
> > There is no official chinese/japanese/arabic/hebrew/etc version of 
> > which compiles a syntax of java with translated words.
> >
> > ie) not int etc.
>If you mean a version of java where keywords etc. had been translated,
>I would consider this a very bad thing. A programming language is
>a language in itself (stretching the definition of language somewhat).
>That items of the programming language are borrowed from (normally) 
>is an other thing entirely.
>The words "int", "for" etc. do not themselves have a semantic because of
>their english meaning. Instead they rely on the semantic defined by
>the specification of, in this case, java.
>(If you meant something else, I am afraid I do not understand you.)
> > Until someone can write Java code purely in a foreign language, there
> > doesn't seem to be a big point in claiming people don't know English.
> >
> > On the other hand, if 4 chinese developers have to put up with logging 
> > poorly written english as a way to describe errors to each other, it 
> > counter-productive.
> >
> > So it still depends on the project I'd believe. Your point about 
having to
> > read poorly translated logging messages applies, but in reverse. Why 
> > a swede wish to read error logs in poor english when the creator could
> > have written a much better version in swedish. Would a dane/norwegian 
> > prefered the swedish log.
> >
> > Keeping these strictly to english seems to be workable for 
> > india and other anglicised/americanised nations. But the far east 
> > and middle-eastern would seem different? Ditto for S.America, wouldn't
> > some form of spanish make more sense there?
>This is a good point. If the people involved in a project do not have
>sufficient knowledge of english this might indeed be counter productive.
>It does however only address the question if english is suitable or not.
>The arguments for using no internationalization remains.
>As an argument, for not using e.g. swedish/chinese/spanish -- if the cost
>is not to high,
>one must consider the future group of developers. E.g. if a small swedish
>company with only swedish developers write their code, comments and log
>message in swedish they will be ok. For a while. Then the company expands
>to the U.K., is bought by Microsoft or hires a brilliant chinese, who 
>not no a word of swedish.
>But as you state, the common language might under circumstances more
>appropriately be something else.
> >
> > I wonder how Ruby handles this. Does the Ruby language output errors 
> > japanese by default etc.
> >
> > Also, are there Java programmers in other locales who take advantage 
> > the fact that they can use most of unicode in their Java identifiers? 
> > I expect to decode some German code with umlauts etc?
>Sofar I have never seen this done. (But a few examples
>of German with umlauts "encoded" as "ae", "oe" etc.)
>To unsubscribe, e-mail:   <>
>For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message