Version Info: latest as of 8 dec 2009

What steps will reproduce the problem? 1.import a non english java i18n properties file with escape sequences

What is the expected output? What do you see instead? escape sequence are mostly unintepreted. Uppercase letters are not recognized in \u sequences, \n and \t are not recognized, generic \ escape sequence is not recognized (see attached screenshots)

The java properties file import/export tool should conform the specifications of java.util.Properties.load() method (http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html#load%28java.io.InputStream%29), as this is the way java ressource bundle loads them and the way other property files editor do. Most specificaly those sections:

http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#100850 http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#101089 should be conformed with exception of " * Octal escapes are not recognized. * The character sequence \b does not represent a backspace character. * The method does not treat a backslash character, , before a non-valid escape character as an error; the backslash is silently dropped. For example, in a Java string the sequence "\z" would cause a compile time error. In contrast, this method silently drops the backslash. Therefore, this method treats the two character sequence "\b" as equivalent to the single character 'b'. * Escapes are not necessary for single and double quotes; however, by the rule above, single and double quote characters preceded by a backslash still yield single and double quote characters, respectively. "

This is in direct conflict with issue http://code.google.com/p/tongue-tied/issues/detail?id=43&can=1&q=import%20properties. There are no reasons to keep \n in the translator's interface, translator are not supposed to understand java escape sequences. There are not supposed, imho, to type any escape sequence, it's should be the tool work to convert text from and to properties files.

Also, it seem the export to properties file does not do proper escaping of text, at least it doesn't escape '\' in user interface as '\' in export. As a consequence if a translator type, for example "use the backslash () to separate your item orders", the java ressourcebundle will see "use the backslash () to separate your item orders", which will be a non sense to final user. Once again, translators should not have to worry about escaping, they translate a text from one language to another. As you can see from my screenshot, it can quickly becme a nightmare for them ;)

After investigation of source code, it seems that tongue-tied is properly decoding sequence (use of java.util.Properties) but then issuing a StringUtils.escapeJava to reescape everything, leading to all non Ascci characters beeing unreadable for most translators.

Here is a proposed patch (including unit tests) that solves the issue

I also need to see how this affects other output formats. I was trying to be too clever with the import process. It just seems to make things difficult.

tchize, Thanks for the patch and adding some of the missing elements. I will work the patch in, but might need to amend a few things.

Hi tchize,

I have uploaded a war file with the fix for this issue (based on your patch). Could you download it from here: http://tongue-tied.googlecode.com/files/TongueTied_1_3_2RC1-20091214.war

and let me know if you have any issues. I just want to confirm that the problem is fixed before I commit the change (I believe it is but I would like a sanity check :).

BTW, how would you like me to acknowledge you contribution, by your username or real name?

thanks alot. Ben

Hello,

since we run already run a patched version at work, and considering am out of office for one week, i won't be able to test the war until monday 21.