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: An i18n warning (was: cvs commit: xml-axis/java/src/org/apac he/axis/utils resources.properties)
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
butek@us.ibm.com


Tom Jordahl <tomj@macromedia.com> on 11/16/2001 09:51:02 AM

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

To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
cc:
Subject:  RE: An i18n warning (was:  cvs commit: xml-axis/java/src/org/apac
      he/axis/utils resources.properties)




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).

<RJB>
Perhaps.  We (Apache) have no control over when translators get stuff.
</RJB>

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

<RJB>
"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.
</RJB>

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

<RJB>
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.
</RJB>

  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.

<RJB>
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.
</RJB>

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

<RJB>
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.
</RJB>

As far as using the same message in two different places, I would
discourage
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
unnecessary
translation work.

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

--
Tom Jordahl
Macromedia


-----Original Message-----
From: Russell Butek [mailto:butek@us.ibm.com]
Sent: Friday, November 16, 2001 10:27 AM
To: axis-dev@xml.apache.org
Subject: An i18n warning (was: cvs commit:
xml-axis/java/src/org/apache/axis/utils resources.properties)


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
resources.properties 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 resources.properties, 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
butek@us.ibm.com
---------------------- Forwarded by Russell Butek/Austin/IBM on 11/16/2001
09:16 AM ---------------------------





dug@apache.org on 11/16/2001 08:23:31 AM

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

To:   xml-axis-cvs@apache.org
cc:

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




dug         01/11/16 06:23:31

  Modified:    java/src/org/apache/axis/utils resources.properties
  Log:
  Improve error message

  Revision  Changes    Path
  1.14      +1 -1
xml-axis/java/src/org/apache/axis/utils/resources.properties

  Index: resources.properties
  ===================================================================
  RCS file:
/home/cvs/xml-axis/java/src/org/apache/axis/utils/resources.properties,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- resources.properties    2001/11/13 14:56:05  1.13
  +++ resources.properties    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
()"







Mime
View raw message