axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell Butek" <>
Subject RE: An i18n warning (was: cvs commit: xml-axis/java/src/org/apac he/axis/utils
Date Fri, 16 Nov 2001 17:18:32 GMT
I wrote the internationalization section of the integration guide and
presented it to axis-dev.  There were very few comments - like adding the
number onto messages - and I incorporated them.  Once I committed the
integration guide I went through all the code (spending almost a week doing
it) and changed all the English-language strings to follow what was written
in the Integration Guide.

Since we're still in the alpha stage, we have some leeway about changing
our philosophy.  But we should decide what that philosophy is SOON,
document it in the Integration Guide, change the code to follow it, and
stick to it.

It's not that I'm particularly attached to the current philosophy, it's
just that it is NOT going to be me that makes sure the code follows any new
philosophy we come up with.  I've gotten to despise the string
"JavaUtils.getMessage".  My fingers can type it in my sleep!

I have a couple comments in the note below within <RJB> ... </RJB>

Russell Butek

Tom Jordahl <> on 11/16/2001 09:51:02 AM

Please respond to

To:   "''" <>
Subject:  RE: An i18n warning (was:  cvs commit: xml-axis/java/src/org/apac

Wouldn't a translator have a check pointed version (say 1.0) and would not
revisit the translation again till another checkpoint version (i.e. 1.1).

Perhaps.  We (Apache) have no control over when translators get stuff.

Then they would be able to simply do a file diff on the two files and
pinpoint exactly what messages have changed.

"diff?  file?  What're those?"  You're talking about folks that probably
know as much about computers as I know about the Russian language.  They'll
probably get a hardcopy of the files and translate things with a pencil.

  The resulting work would be
identical.  For major releases (say 2.0) I would think the translation
be done from scratch, given the expected large numbers of changes.

Why force translators to do work they've already done?  From past
experience, the changes from release to release usually affect less than
half the messages.

  Even if
it wasn't, the file difference method would still be a scalable way to do
the same work.

An endlessly growing message file seems like a losing proposition to me.

I agree with you.  I suggested in the Integration Guide that we could clean
up the message file on major releases.  If new stuff is ALWAYS at the end,
then the translators don't even have to be aware that messages went away.

also do not like the numbering of the messages for the same reasons.  Its
visual clutter and is unnecessary.

I agree with you here, but someone - I don't recall who - said they had
good results when they used them so, since they're just a couple extra
characters, I added them.

As far as using the same message in two different places, I would
this as bad practice.  Each message should be unique so changes (for the
good, like improved error messages) wont have ripple effects.

To summarize my opinion:
1. All messages should be used in one place only, with very few exceptions.
2. Messages can change from release to release and should not be
'versioned', but gratuitous changes should be avoided to prevent
translation work.

Can I gets some +1's? :-)

Tom Jordahl

-----Original Message-----
From: Russell Butek []
Sent: Friday, November 16, 2001 10:27 AM
Subject: An i18n warning (was: cvs commit:

What dug's done here isn't too critical at this early stage of the game,
but it's not the sort of thing we should be doing for 2 reasons.

1.  If this message is used in multiple places, and you don't know about
those other places, you might have just messed up the meaning for those
other places.  This particular message is only used in one place and I
assume Dug changed it for meaningful reasons.

2.  If a translator has already translated this document, then the next
time the translator is given the document, it will have to be translated in
toto again because it won't be obvious which messages are changed and which
are unchanged.

What we should REALLY do if we don't like a message is make a new entry in at the end of the file and make the code point to this
new message.  This is good for two reasons.

1.  You won't mess up anyone else that depended on this message.

2.  By putting the new message at the end of, the
translator, when visiting the file after having translated it previously,
only needs to look at the bottom few messages and figure out which was the
last one translated last time, and only translate the new messages.

Russell Butek
---------------------- Forwarded by Russell Butek/Austin/IBM on 11/16/2001
09:16 AM --------------------------- on 11/16/2001 08:23:31 AM

Please respond to


Subject:  cvs commit: xml-axis/java/src/org/apache/axis/utils

dug         01/11/16 06:23:31

  Modified:    java/src/org/apache/axis/utils
  Improve error message

  Revision  Changes    Path
  1.14      +1 -1

  RCS file:
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  ---    2001/11/13 14:56:05  1.13
  +++    2001/11/16 14:23:30  1.14
  @@ -239,7 +239,7 @@
   # NOTE:  in noClassname00, do not translate "classname"
   noClassname00=No classname attribute in type mapping

  -noComponent00=No component type for {0}
  +noComponent00=No deserializer defined for array type {0}
   noConfig00=No engine configuration file - aborting!

   # NOTE:  in noContext00, do not translate "MessageElement.getValueAsType

View raw message