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