better mapping for string-based inline code ID in XLIFF filter

[Former user]

Original issue 372 created by @ysavourel on 2013-10-20T20:25:08.000Z:

The XLIFF filter maps the original ID of the XLIFF file to integers, but uses hashcode for this. creating long and complex ID like -23434563.

There should be a better way to map the original ID in the extracted ext, as long as the same mapping is used for the whole file it should not matter.

maybe a hashtable could be used:

'pt123'->1
'pt235'->2
etc.

this would be used only in extraction.

[Jim Hargrave (OLD)]

We now have originalId (which ultimatley should become Code.id when it is changed to string). XLiff writer should use the originalId if availible. This will solve the problem here.

[YvesS]

BTW, using the hashCode is to convert string-based ID to int is bad since there is no guaranty that the hash code will be the same from one JVM to the next. (We didn’t know that way back then). If we somehow we use hashCode somewhere we should implement a Utils method for it so it gives always the same result.

[Jim Hargrave (OLD)]

agreed - I hope this will all go away once we refactor Code to use a string id.  The numeric id's could be called "index" or something like that.