axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Jordahl <t...@macromedia.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 15:51:02 GMT

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

Then they would be able to simply do a file diff on the two files and
pinpoint exactly what messages have changed.  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.  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
also do not like the numbering of the messages for the same reasons.  Its
visual clutter and is unnecessary.

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