[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] Revised XLIFF Profile for Java Resource Bundles
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.
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 <trans-unit>?
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 together.
Skeletons are necessary when dealing with ListResourceBundles. Non-translatable Java code needs to be preserved somewhere.
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"
ctype="x-variable"/>.
Windows StringTable <source>Question <x id="1"
ctype="x-variable"/> will appear in this color: <x id="2"
ctype="x-variable"/>.
Rather than:
Java PropertyResourceBundle <source>Question <ph
id="1">{0,number,integer}</ph> will appear in this color: <ph
id="2">{1}</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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]