OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xliff] Revised XLIFF Profile for Java Resource Bundles

On Tue, 2006-05-02 at 14:32 -0500, David Walters wrote:

Hi David,

Thanks for providing feedback. As I said in my previous message, the profile needs a detailed review and your comments are helpful.

Please see my comments interleaved below.

I am glad to finally see these XLIFF Profiles being developed.  I think
these Profiles are critical to helping people understand the intent of
XLIFF and how best to use it so that there is some consistency across
products, companies and tools which process XLIFF files.

I recently became an observer of this Technical Committee, so some of my
comments may have already been covered in previous discussions.  I work for
IBM in a globalization area, so my comments are not intended to be "IBM's
comments", but only my personal comments.

   1.  Throughout the document, I would suggest that the terms
   "ResourceBundle", "PropertyResourceBundle" and "ListResourceBundle"
   should always be written as single words, since these are references to
   specific Java classes.

You are right. I will adjust the text accordingly.

   2.  Listing 1.  Keys s4, s5 and s6 indicate that they are choices for
   ChoiceFormat() processing.  It would be good to also provide an example
   for this situation when it is coded like this:

                    "The disk \"{1}\" contains {0,choice,0#no files|1#one
file|1<{0,number,integer} files}.");

I will rewrite the example completely. The code included in the profile was originally taken from the Sun's Javadocs. The new example will include your suggestions.

I will also have to add a section explaining how to deal with choices.

   3.  Listing 1.  Another interesting example would be to show how
   concatenated text would be handled, like:

               {"s9", "The disk \"" + Var1 + "\" contains " + Var2 + "." }
          {"s10", "The disk \"" +
                     Var1 +
                     "\" contains " +
                     Var2 +
                      "." }

Concatenated strings with variables is bad practice. Developers should use MessageFormat class instead. I think that a comment regarding this should be added.

   4.  Listing 2.  For PropertyResourceBundles, I do not think that there
   is the ability to have a comment after the text  like is shown on the
   last line of the example:

      planet = Mars // Inline comment

I've seen this in sample files from Sun. I never used comments like this in my own programs and can't tell for sure if it is possible. I will check this and adjust the profile accordingly.

   5.   Listing 2.  A ChoiceFormat() example would be good:

        example1=The disk "{1}" contains {0,choice,0#no files|1#one
file|1<{0,number,integer} files}.

Agreed. I will add this case to the listing.

   6.   Listing 2.  Other examples with escaped characters, single quotes
   in text not handled by MessageFormat(), single quotes in text handled by
   MessageFormat() should be included.  The question is whether the filter
   resolves these items to a simplified form so that the translator does
   not have to worry about the original file format, or if the translator
   is responsible for insuring these file specific formats are correct
   (which would sort of be in conflict with the intent of XLIFF).

Good point. IMHO, the filter should handle single quotes. I will add a paragraph about this. If anyone has a different opinion, please speak before Friday.

   7.   Section 2.8, 2nd bullet.   I do not think that there is the ability
   in PropertyResourceBundles to have a comment after the text  as is shown
   on the last line of Listing 2.  Neither 2 forward slashes nor 2 backward
   slashes seem to work.  The description uses the example "//" but then
   references this as backslashes.  In fact, there does not appear to be a
   way to have any type of comment text in the middle of the localizable
   text in a PropertyResourceBundle.

As said above, I've seen this in files from Sun. I Will do some research and adjust the text as needed.

   8.   Section 2.8.  Why does comment text in the middle of localizable
   text need to be preserved at that specific location.  Wouldn't it be
   sufficient to just include the comment text in the <note> for that

The draft that I modified included this requirement. I think that the location of the comment should be preserved and for the comment to be useful, its content should be included in a <note> element as you suggest.

   9.   In the XLIFF 1.2 Representation Guide for HTML, it recommends a
   "maximalist" approach rather than a "minimalist" approach.  Does that
   same recommendation apply for ResourceBundles?  It seems like the
   translator would prefer to see a "minimalist" approach to reduce as much
   clutter in the text as possible.

I personally prefer the minimalist approach. If anyone wants to add a paragraph regarding minimalist vs. maximalist, please suggest the text to add before Friday.

   10.   One of the items not discussed is the use of a skeleton file. In
   the XLIFF 1.2 Representation Guide for HTML, it appears that almost all
   of the HTML tag information is saved as XLIFF attributes so that a
   skeleton file almost is not needed.  Should that same method apply to
   ResourceBundles?  It would be beneficial to include the skeleton file in
   your XLIFF examples so that users can understand how everything fits

Skeletons are necessary when dealing with ListResourceBundles. Non-translatable Java code needs to be preserved somewhere.

It is not really necessary to use skeletons with .properties files, but IMHO it is better to do so to preserve the layout of the file.

One of the strengths of XLIFF is that it tries to normalize information
from a variety of formats into a single common format.  But the more
format-dependent information that is carried along in the <SOURCE> element,
the further XLIFF moves away from that goal.  If the same segment is coded
in several different formats, each of which may require slight differences
in the text, I would hope that the XLIFF representation would be as similar
as possible and as format independent as possible.  The translator should
not have to know about the coding conventions for each of the original file
formats, and translation memory entries should be easily reused so the
segment's text needs to be translated only once.  For example:

      Java PropertyResourceBundle   msg1=Question {0,number,integer} will
appear in this color: {1}.
      Windows StringTable           msg1    "Question %d will appear in
this color: %s."

Converting each to XLIFF:

      Java PropertyResourceBundle   <source>Question <x id="1"
ctype="x-variable"/> will appear in this color: <x id="2"
      Windows StringTable           <source>Question <x id="1"
ctype="x-variable"/> will appear in this color: <x id="2"

Rather than:

      Java PropertyResourceBundle   <source>Question <ph
id="1">{0,number,integer}</ph> will appear in this color: <ph
      Windows StringTable           <source>Question <ph id="1">%d</ph>
will appear in this color: <ph id="2">%s</ph>.

I personally prefer to deal with <ph> elements and let the XLIFF editor handle the content of <ph> tags present in TM automatically. Using <x/> tags the ability to reuse tag content is lost, as the protected code is stored in the Skeleton and not in the XLIFF file.

Best regards,
The information in this e-mail is intended strictly for the addressee, without prejudices, as a confidential document. Should it reach you, not being the addressee, it is not to be made accessible to any other unauthorised person or copied, distributed or disclosed to any other third party as this would constitute an unlawful act under certain circumstances, unless prior approval is given for its transmission. The content of this e-mail is solely that of the sender and not necessarily that of Heartsome.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]