axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell Butek" <bu...@us.ibm.com>
Subject Re: AXIS System Integration Guide - with internationalization
Date Thu, 01 Nov 2001 15:01:07 GMT
I debated about requiring a key syntax, but I decided against it for two
reasons:

1.  Meaning.  Keys of the form: AXIS00001, AXIS00002, have no meaning and
are merely placeholders.  You cannot read the code and get a reasonable
idea of what the message is.  Folks can be a little descriptive with
free-form keys:
noOperation=No operation name specified.

2.  Conciseness.  Anything that is organizational tends to be rather
longwinded.  For instance, we COULD require keys to contain the class name
as well as some descriptive text, like:
org.apache.axis.client.Call.noOperation=No operation name specified.
But I really want to avoid a system where the key is longer than the actual
text!

The point about being careful to always add and never change entries is
important.  I thought I made it clear in the doc, but if you had to
reiterate it, perhaps I didn't.

I'd like a little more explanation about your following 3 points:

           - you must assign a key ( A-Za-z0-9 )
           - you must add at least a key to en/en or en/us mapping.
           - you should not reuse a key

I'm against the first item, as you see above, unless someone can present a
scheme that's both concise and meaningful.

For the 2nd item, in AXIS the default mapping is all we'll provide.  We
won't provide an en/us or en/en mapping.  In other words, we'll only
provide the resources.properties file.  If anyone else wants to provide
other files, such as resources_en.properties and
resources_en_US.properties, that's up to them, but it will not be part of
AXIS.  It is not the role of AXIS to do translations, just provide a way
for others to plug in those translations.

What do you mean by "reuse"?  Do you mean you should not have an entry
abc=xyz
and then later change that to be
abc=vwx?
If that's what you mean, I'd restate it:  "- you must not change entries.
If code changes force a message change, add a new entry, don't change the
message in an existing entry."

Russell Butek
butek@us.ibm.com


Richard Sitze/Charlotte/IBM@IBMUS on 11/01/2001 07:55:21 AM

Please respond to axis-dev@xml.apache.org

To:   axis-dev@xml.apache.org
cc:
Subject:  Re: AXIS System Integration Guide - with internationalization



I would propose keys of the form "AXIS[0-9][0-9][0-9][0-9][0-9]", ie
AXIS00001 ...

<ras>




                    Dirk-Willem
                    van Gulik            To:     axis-dev@xml.apache.org
                    <dirkx@covalen       cc:
                    t.net>               Subject:     Re: AXIS System
Integration Guide - with
                                          internationalization
                    10/31/2001
                    03:21 PM
                    Please respond
                    to axis-dev







On Wed, 31 Oct 2001, Russell Butek wrote:

> I haven't heard a thing from folks about the internationalization
proposal
> in the document.  Can I take silence as consent?  If so, I will commit
this
> document on Friday and start implementing internationalization in AXIS.

Your internationalization approach is fine. You want to be really carefull
about the keys. Always add - never change.

If you are worried about people not using it; you could allow for some
wrapper:

           someWrapper("keyName","Could not find the begin tag")

but IMHO in an open source project it is easy enough to make sure there is
a community standard which says that

           - you must assign a key ( A-Za-z0-9 )
           - you must add at least a key to en/en or en/us mapping.
           - you should not reuse a key

and then help people with it as commits come in. It is a bit of a havit to
get into. I'd be more worried if you had proposed to allow things like
a 'key' which could double as the english text; i.e keys like
           "Could_not_find_the_begin_tag"
and then rely on s/_/ /g substitions :-)

You could advice people to start numbering them keys right from the
start; i.e keys should be

           /^[A-Za-z0-0]{1,}[0-9]+$/

and/or use some clever perl script to detect 'naughty'ness.

Dw








Mime
View raw message