[MAGNOLIA-6559] Support i18n directory in light module Created: 18/Feb/16  Updated: 17/Oct/16  Resolved: 17/Mar/16

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

Type: Story Priority: Neutral
Reporter: Christopher Zimmermann Assignee: Antonín Juran
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MAGNOLIA-6234 TranslationService could use new Reso... Closed
dependency
is depended upon by MTE-74 Use i18n "best practices" in MTK Closed
duplicate
is duplicated by MAGNOLIA-6557 New location for translation files Closed
supersession
supersedes MGNLRES-257 Make hiding of resources in the resou... 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)
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Epic Link: LD: components + pages
Sprint: Kromeriz 35
Story Points: 3

 Description   

MAGNOLIA-6234 Introduces loading i18n bundles in the resources app.
But the current directory format will not work for light modules which are present in the webapp "resources directory", because all files associated with a light module should go in one directory.
Therefore:

  • translations should continue to be loaded from the current /src/main/resources/mgnl-i18n directory of a maven module.
  • On a light module should also be loaded from <resources dir>/<module-name>/i18n.
  • Which means in a maven module they should also be loaded from /src/main/resources/<module-name>/i18n

Open Questions:
Before implementation, it must be decided if this new i18n directory supports all of the existing keys, or only a subset.



 Comments   
Comment by Roman Kovařík [ 25/Feb/16 ]

czimmermann: Before implementation, it must be decided if this new i18n directory supports all of the existing keys, or only a subset.

Validation is not possible from the implementation perspective (besides some hacks):

  1. Translations are loaded. (no clue about the keys, we'd have to introduce sort of crazy parser with validator. There could be custom keys so such validator won't be ever able to work properly.)
  2. Keys are created as set of strings (no way to pass information about deprecated keys).
  3. Translation is requested with set of keys.
  4. A translation is found for a key from the set (no clue if it was for a deprecated key or not).
Generated at Mon Feb 12 04:15:40 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.