[MAGNOLIA-6862] DefaultMessagesImpl's fallback uses system locale to locate message properties file and reads them using ISO-8859-1 resulting in translation issues Created: 07/Nov/16  Updated: 21/Dec/16  Resolved: 19/Dec/16

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: 5.5.1

Type: Bug Priority: Neutral
Reporter: Philip Mundt Assignee: Philip Mundt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File legacy_translation_broken.png    
Issue Links:
Relates
relates to MAGNOLIA-6861 DefaultMessageBundlesLoader might not... Accepted
causality
caused by MGNLPUR-164 Get rid of dependency to legacy admin... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Sprint: Basel 75
Story Points: 5

 Description   

When running Magnolia on a system with system locales differing from Locale.ENGLISH one might end up with scenarios where translations provided by new and old translation system come from different languages. See

So even though current use (here superuser) has the locale set to English in his settings, one of the legacy translations shows up in the system locale (which was de_CH.UTF-8, or simply de). Additionally those translation might show up with encoding errors due to being read without UTF-8 but rather ISO-8859-1.

Source of the problem

So when no bundle matching Magnolia file naming convention is found, the following line info/magnolia/cms/i18n/DefaultMessagesImpl.java:106 will fallback to Java's bundle loading:

bundle = ResourceBundle.getBundle(getBasename(), locale);

Java's messages properties file a read with ISO-8859-1 character encoding by default, see link below. Additonally the Locale is detected from the system, resulting in more issues.

(..) The input stream is in a simple line-oriented format as specified in load(Reader) and is assumed to use the ISO 8859-1 character encoding; (..)



 Comments   
Comment by Michael Mühlebach [ 14/Nov/16 ]

Timeboxed
Main focus is finding the issues and not fixing it. It has to do with differences between the legacy and new i18n mechanism. The question is why!?!?!?!?!?!?

Generated at Mon Feb 12 04:18:33 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.