XLIFF Filter doesn't parse decimal match-quality values

[Chase Tingley]

This affects attempts to parse alt-trans data from XLIFF produced by WorldServer (the old "Idiom XLIFF", not the SDLXLIFF which can be produced from the newer FTS filters). It produces alt-trans blocks like this:

<alt-trans match-quality="100.00" origin="Default">

This alt-trans will be parsed but will report a score of 0 in Okapi, because of this code from XLIFFFilter#processStartAltTrans():

        if ( !Util.isEmpty(tmp) ) {
            if ( Character.isDigit(tmp.charAt(0)) ) {
                if ( tmp.endsWith("%") ) tmp = tmp.substring(0, tmp.length()-1);
                try {
                    altTransQuality = Integer.valueOf(tmp);
                    if ( altTransQuality < 1 ) altTransQuality = -1;
                }
                catch ( NumberFormatException e ) {
                    // Do nothing
                }
            }
        }

I think it's reasonable to discard the precision and normalize the value to an int.

[Chase Tingley]

Fix Issue #500 - handle decimal match-quality values like 100.00

This is needed to parse alt-trans data from the Idiom/IWS XLIFF
produced by older WorldServer setups.

→ <<cset b521be4b7e14>>