dallaslu / gettext-commons

Automatically exported from code.google.com/p/gettext-commons
GNU Lesser General Public License v2.1
3 stars 3 forks source link

Using the apostrophe character with {0} #55

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Translating a string with a parameter :
#: src/name.c:36
msgid "My name is {0}.\n"
msgstr "Je m'appelle {0}.\n" 
2. Compile and run

What is the expected output? What do you see instead?

Expected is the retrieval of the string "Je m'appelle cindy.\n" but get "Je 
mappelle {0}.\n" instead.

What version of the product are you using? On what operating system?

Gettext Commons 0.9.6

Please provide any additional information below.

If we use 
msgstr "Je m''appelle {0}.\n"
, it is OK. But the double apostrophe appears on strings without parameters..

Original issue reported on code.google.com by fnicola...@gmail.com on 16 Oct 2012 at 9:53

GoogleCodeExporter commented 9 years ago
0.9.8 is still affected.

Seems like "MessageFormat.format()" is the cause of it.

Original comment by azrad...@gmail.com on 13 May 2014 at 9:55

rlf commented 9 years ago

The rules are a bit weird, but understandable.

If the string uses java-format, i.e. has a {0} or similar, any ' needs to be double quoted, if it doesn't single quoting is required.

This is due to the way the MessageFormat works, where ' is used as a literal escape character.

I wouldn't call this a bug, since changing it (i.e. to escaping 's used in java-format strings), would ruin any usages within the formatting block.

wiselynx commented 9 years ago

I have a patched version of the library, which simply uses the same logic for all strings. This to avoid having to treat strings differently in po files depending on whether there are arguments or not. With the proposed patch, all messages are treated "the MessageFormat way", i.e. apostrophes need to be escaped by doubling, even if the string contains no arguments.

If the maintainers like it, I would like of course to contribute the patch. I have the change in a branch of mine, and I have tested it through some external code. I'd like to also modify the unittests to ensure it, but I'm having unrelated issues with maven, so I didn't bother yet. Please let me know.