Relates to MAGNOLIA-5284 - Getting issue details... STATUS
We have 3 distinct i18n "areas" in Magnolia:
* System: used for translations of Magnolia itself
* Content: localization of content (a site in multiple languages)
* Authoring: provides authors with means to translate their sites (relies on i18n-content)
Additionally, templates currently use the "system" components for some additional translations that are currently not handled by authors (such as "Read more" links)
Currently, the following packages exist:
* {{info.magnolia.cms.i18n}} (main)
* {{info.magnolia.ui.api.i18n}} (ui)
* {{info.magnolia.ui.framework.i18n}} (ui)
* {{info.magnolia.ui.vaadin.gwt.client.editor.i18n}} (ui)
* {{info.magnolia.cms.gui.i18n}} (legacy-admininterface)
The {{info.magnolia.cms.i18n}} package contains components for system and content. It also contains, i.e, {{Content}}-API based wrappers.
Additionally, info.magnolia.jcr.wrapper.I18nNodeWrapper is, well, in the wrong package; it should be packaged along the i18n-content features.
After an initial short discussion with [~pbaerfuss], we thought about having these 3 packages:
* {{info.magnolia.i18n.system}}
* {{info.magnolia.i18n.content}}
* {{info.magnolia.i18n.authoring}}
... but as shown above, we probably want to keep the differentiations between api, framework, .... Would {{info.magnolia.i18n.authoring.api}} and {{info.magnolia.i18n.authoring.framework}} work ? If we want {{info.magnolia.ui.}} as a parent to both, I'd favor dropping the {{.}} and using package names in a "single word", such as {{info.magnolia.i18ncontent}}.
TODO : use template below...
> The goal of this template is to remind you of many aspects that you could consider, to help you create a good concept.
> Tip: Use whichever sections are appropriate for the concept, delete the rest, rename and add at will, these are simply a suggestion.
> Tip: Delete all these comments.
Purpose
The Problem
> AKA (Also known as): Starting Position
> Why is this concept being considered? What is the issue that someone is having that needs to be addressed?
Goals
> This feature will be a success if it achieves these criteria.
> Tests could be defined based on these goals.
Use Cases
> AKA: User Stories
> List concrete ways in which this feature will be used.
Proposal
Concept
> AKA: Design
> What is the overall approach to solve the problem. First summarize the high level overview in a few lines.
Reasoning
> AKA: Rationale
> Pros and Cons
> Consequences of this approach.
Implementation
> Describe concrete details of how the feature will be implemented. Could include class diagrams or interfaces.
> Requirements
> Thoughts
> Open Questions
Etcetera
> Possible Improvements
> Discarded Proposals
> Discussion
> References