There is apparently a difference in behaviour between the Play i18n messages format and a standard Java properties file with regard to multi-line values. In the former whitespace after the line continuation character is significant, and in the latter it is not, e.g.:
Play:
Parsed string: Some Value.
Properties:
Parsed string: Some Value.
This is fair enough since the Play documentation doesn't say anything about multi-line values (or Java properties files) at all, so it's wrong to assume the behaviour is the same; they're different formats after all. In the context of a web application it mostly doesn't matter anyway if the string goes in some HTML since it'll get normalised.
However, if you use a translation management service (like e.g. Transifex) that integrates with your codebase and parses your messages.* files as UTF-8 Java properties, you currently end up with subtle spacing (or lack of spacing) issues that confuse translators. This seems sub-optimal to me, and frankly the Java behaviour is much more convenient for making externalised strings readable by lining up the portions across lines.
I recognise that changing the default Play behaviour is a non-starter for compatibility reasons, but if there was a way to specify this as a config value (or there's currently a way to do it I don't know about?) I'd find this really useful.
At minimum, the documentation could be clarified with regard to multi-line strings.
There is apparently a difference in behaviour between the Play i18n messages format and a standard Java properties file with regard to multi-line values. In the former whitespace after the line continuation character is significant, and in the latter it is not, e.g.:
Play:
Parsed string:
Some Value.Properties:
Parsed string:
Some Value.This is fair enough since the Play documentation doesn't say anything about multi-line values (or Java properties files) at all, so it's wrong to assume the behaviour is the same; they're different formats after all. In the context of a web application it mostly doesn't matter anyway if the string goes in some HTML since it'll get normalised.
However, if you use a translation management service (like e.g. Transifex) that integrates with your codebase and parses your messages.* files as UTF-8 Java properties, you currently end up with subtle spacing (or lack of spacing) issues that confuse translators. This seems sub-optimal to me, and frankly the Java behaviour is much more convenient for making externalised strings readable by lining up the portions across lines.
I recognise that changing the default Play behaviour is a non-starter for compatibility reasons, but if there was a way to specify this as a config value (or there's currently a way to do it I don't know about?) I'd find this really useful.
At minimum, the documentation could be clarified with regard to multi-line strings.