Java properties filter supports two modes - MessagePatternEscape AUTO and ALL. These options are designed for escaping/unescaping apostrophe characters for MessageFormat pattern translation.
For example, string resource like File {0} can''t be deleted. consumed by MessageFormat need to have apostrophe character doubled to represent a literal apostrophe. However, this is not something translators should worry about - and translation should see File {0} can't be deleted. Java properties filter does this conversion for import, and restore MessageFormat safe expression during export.
The current implementation works fine for simple cases like above, but it does not work well when apostrophes are used for quoting curly braces.
For example, when a resource file contains a value
''abc'' {0} '{0}' ''{0}''
With this expression,
'{0}' is literal {0} and not a variable and will be formatted as {0}
''{0}'' is a variable surrounded by apostrophe and when args[0] is "Foo", it will be formatted as 'Foo'.
This is imported to Globalization Pipeline as below with the current implementation (both AUTO/ALL)
'abc' {0} '{0}' '{0}'
So distinction between '{0}' and ''{0}'' is lost while import, so it cannot be exported back to a properties file keeping the original semantics any more.
I propose to change the behavior of the filter to produce ICU ApostropheMode.DOUBLE_OPTIONAL compatible string with all redundant apostrophes removed. It means extra apostrophe characters are preserved only when they are necessary to preserve the semantics. With this definition, above MessageFormat pattern string will be imported as below
'abc' {0} '{0}' ''{0}''
With this implementation, translators can deal with more natural text representation, while they can still handle special cases when quoted curly braces, or apostrophe surrounding variable is used.
Java properties filter supports two modes - MessagePatternEscape AUTO and ALL. These options are designed for escaping/unescaping apostrophe characters for MessageFormat pattern translation.
For example, string resource like
File {0} can''t be deleted.consumed by MessageFormat need to have apostrophe character doubled to represent a literal apostrophe. However, this is not something translators should worry about - and translation should seeFile {0} can't be deleted.Java properties filter does this conversion for import, and restore MessageFormat safe expression during export.The current implementation works fine for simple cases like above, but it does not work well when apostrophes are used for quoting curly braces.
For example, when a resource file contains a value
''abc'' {0} '{0}' ''{0}''With this expression,
'{0}'is literal{0}and not a variable and will be formatted as{0}''{0}''is a variable surrounded by apostrophe and when args[0] is "Foo", it will be formatted as'Foo'.This is imported to Globalization Pipeline as below with the current implementation (both AUTO/ALL)
'abc' {0} '{0}' '{0}'So distinction between
'{0}'and''{0}''is lost while import, so it cannot be exported back to a properties file keeping the original semantics any more.I propose to change the behavior of the filter to produce ICU ApostropheMode.DOUBLE_OPTIONAL compatible string with all redundant apostrophes removed. It means extra apostrophe characters are preserved only when they are necessary to preserve the semantics. With this definition, above MessageFormat pattern string will be imported as below
'abc' {0} '{0}' ''{0}''With this implementation, translators can deal with more natural text representation, while they can still handle special cases when quoted curly braces, or apostrophe surrounding variable is used.