-
Bug
-
Resolution: Unresolved
-
Neutral
-
None
-
None
-
None
info.magnolia.i18nsystem.DefaultMessageBundlesLoader might read messages.properties files incorrectly, resulting in broken translations.
The problem becomes visible due to another issue, where the locale of the legacy translation system is determined in another way than the new mechanism, see MAGNOLIA-6862.
Here, the German translation from the lang-de module would show up in the ee-pro-demo-bundle. Key menu.security.usersPublic of travel-demo:pages/pur template (which uses legacy i18nBasename and key). In https://git.magnolia-cms.com/projects/LANG/repos/de/commits/28546be5f8469d1e02363cd2edd5d2e361e13c11#src/main/resources/mgnl-i18n/public-user-registration/app-public-user-registration-security-messages_de.properties UTF-8 encoded chars were removed and replace by proper Umlauts. Broken Umlauts now show up in the template selection dialog see .
Ćffentlicher Benutzer should be Ćffentlicher Benutzer.
Possible source
When removing the org.apache.commons.io.input.BOMInputStream (introduced in https://git.magnolia-cms.com/projects/PLATFORM/repos/main/commits/1b0de82a4a715e6fb5c8187b27dcc1d239b38e78) from info.magnolia.i18nsystem.DefaultMessageBundlesLoader#loadResourcesInPropertiesMap the translation show up correctly. Might relate to https://code.google.com/p/guava-libraries/issues/detail?id=345.
- relates to
-
MAGNOLIA-5823 i18n message bundles that contain UTF-8 chars are no longer read correctly by i18n service.
- Closed
-
MAGNOLIA-6862 DefaultMessagesImpl's fallback uses system locale to locate message properties file and reads them using ISO-8859-1 resulting in translation issues
- Closed
- links to