[MAGNOLIA-5652] i18n property files should not need to be converted to ascii Created: 29/Jan/14 Updated: 06/Jun/18 Resolved: 28/Feb/14 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | 5.2.2 |
| Fix Version/s: | 5.2.2 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Christopher Zimmermann | Assignee: | Daniel Lipp |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | i18n, support | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| 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)
|
||||||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||||||
| Description |
|
It is currently required for the "legacy" property files, (those that are stored in resources/info/magnolia/ui/[modulename] that they be in an escaped utf format, ascii that looks like this: It causes problems that only some files must be in this escaped format and it is an unnecessary extra hassle to have to convert them. The i18n implementation should be changed to accept the standard unicode character sets for all translation property files. Currently the files often have to be translated with a tool on the command line like so: Note: assigning to Greg for his review of the improvement, and suggestions on implementation. |
| Comments |
| Comment by Christopher Zimmermann [ 29/Jan/14 ] |
| Comment by Christoph Meier [ 31/Jan/14 ] |
|
"New" bundles (since introduction of the new i18n-concept) are loaded with a StreamReader which specfifies the encoding. If DefaultMessagesImpl is using a streamReader which specfifies the encoding, too, this should fix the problem. |
| Comment by Christoph Meier [ 31/Jan/14 ] |
|
My proposed fix seems to work. |
| Comment by Christoph Meier [ 31/Jan/14 ] |
|
probably needs further review by Greg. |
| Comment by Daniel Lipp [ 02/Feb/14 ] |
|
New implementation is unnecessarily complex. We should take the simplest approach. |
| Comment by Christoph Meier [ 02/Feb/14 ] |
|
The important point is to read the file from the disk with specified encoding. In the „1st part“ that’s easy But: The question is, why and when the „else-part“ (2nd part as mentioned above) is ever used. Would be nice to get rid of, if possible. |
| Comment by Magnolia International [ 03/Feb/14 ] |
|
To try and clarify some of the above, and add my grain of salt:
|
| Comment by Christian Ringele [ 28/Feb/14 ] |
|
Seems its not working for SUPPORT-3268, reopening issue. |
| Comment by Christian Ringele [ 28/Feb/14 ] |
|
Closing again, should have created new issue: |