XLIFF BRS Task Problems
Description
relates to
Activity
UnicodeBot June 30, 2018 at 11:45 PM
Trac Comment 6 by —2013-09-23T23:03:34.665Z
following patch gives a
target that just verifies
can be regenerated. I don't think it's worth verifying the xliff2icuconverter here, as long as ra.xlf can be regenerated. In icu4j land can have a unit test that verifies the xliff2icu converter.
So:
1. add to the makefile
1. update BRS
1. checkin an updated
that is properly tagged as language=ra
UnicodeBot June 30, 2018 at 11:45 PM
Trac Comment 4 by —2010-06-15T05:35:50.000Z
The test instruction is bogus, because XLIFF2ICUConverter with -t option specifies the target translation language to be extracted, but no translation is provided in this test case. (For that reason, the tool simply fails. It should use -c, ie. source only.) Also, ICU XLIFF tools assume the top level table represents a locale - in this example, "ra" is used. However, the first step (genrb -x) uses -l en.
As of now, I do not think ICU tooling for XLIFF support is practically usable. We have new line problem (#6382). Also, resource re-ordering in a table is really bad practically (although, they are logically equivalent).
For now, I'll update the BRS instruction and state that the tools/test case need to be fixed. We probably leave ICU XLIFF tooling as is unless someone really wants these issues fixed.
UnicodeBot June 30, 2018 at 11:45 PM
Trac Comment 3 by —2010-06-15T05:18:41.000Z
Closed ticket as dup. Now I took over this ticket.
UnicodeBot June 30, 2018 at 11:45 PM
Trac Comment 2 by —2009-03-24T17:18:18.000Z
unsched for now
Details
Details
Assignee
Reporter
Priority
minor
Deleted Component: tools
The BRS task "Verify XLIFF conversion" says:
Convert icu/source/test/testdata/ra.txt to XLIFF
genrb -s icu/source/test/testdata -d icu/source/test/testdata/ -x -l en ra.txt
Verify that the ra.xlf produced is identical to the one in CVS HEAD (except for generation date)
Convert icu/source/test/testdata/ra.xlf back to ICU format
java -cp icu4j/classes com.ibm.icu.dev.tool.localeconverter.XLIFF2ICUConverter -d . -t ra ra.xlf
Verify that the ra.txt produced is identical to the one in CVS HEAD (except for generation date)
Go through the steps given in http://icu.sourceforge.net/docs/papers/localize_with_XLIFF_and_ICU.pdf
This will never produce files that compare as equal because:
the round-tripped .txt file contains the contents of the text file that's included in the original
the whitespace in the comments in the round-tripped file has been canonicalized
the elements are in a different order owing to how genrb parses the original .txt file.
We need to design a test for this that will actually pass - perhaps generating .res files from the original and round-tripped .txt files and comparing those?