Page History
...
Rationale
Magnolia 5.0 went slightly backwards - we lost some translations. The mechanisms are still in place, but we "forgot" to implement them; many dialogs are configured with "hardcoded" labels. Some code, too.
More importantimportantly, the way we apply i18n through the UI is currently inconsistent or inexistent. Most new constructs (apps, action bars, ...) have no notion of i18n. Blindly applying the same slightly dated concept we've been using up to 4.5 would blow the configuration out of proportion. Below are a few suggestions to explore and make this simpler, smaller, or more consistent.
To explore
- Generate key from app-dialog-field(.desc)
- Generate i18nbasename?
- (Updtask remove if match)
- (Check contents)
- Migrate existing translations
- Chain bundles for simple defaults (chain with generated bundle names, sort of package fallback)
- Process for contributing and integrating contributed translations
...
If we have a lot of these, we could think about rolling out our own tool - or write code that behaves similarly.
Convention over configuration
We want to introduce a naming convention, both for basenames (i.e the location of the message files) and the key themselves.
To avoid a lot of redundant and verbose configuration, we could take this one step further and use the conventional name - if none is configured - to lookup a particular text.
With some clever fallback mechanisms, this could make translations easier and simpler.
Suggestion for a fallback chain: given a bundle, the following keys are "tried". The first value to be found is used:
Field labels: – optional fallback to a key with a .label
suffix to make things less verbose
<dialog-name>.<tab-name>.<field-name>.label
<dialog-name>.<tab-name>.<field-name>
<dialog-name>.<field-name>.label
<dialog-name>.<field-name>
Field descriptions - here we can't fallback to a key without the .desc
suffix
<dialog-name>.<tab-name>.<field-name>.desc
<dialog-name>.<field-name>.desc
Tab labels:
<dialog-name>.<tab-name>.label (or .tablabel for explicitness?)
Action labels:
99% of our dialogs have the same save/cancel actions. Those should be defaults. Labels should still be overridable on a dialog-per-dialog basis.
<dialog-name>.actions.<action-name>.label
<dialog-name>.actions.<action-name>
I introduced the .actions
portion here to avoid confusion with fields; consistency would dictate having a .fields
or .tabs
portion for field and tabs labels too, but that would downplay the conciseness.
Other elements tbd:
- actions in dialog
- actionbar in subapps
- workbench/<view>/columns in content apps: column names
- in workbench/view/columns, we also have
formatterClass
which should be locale-sensitive - app (label in app launcher, tab)
- page templates
- page components
If fields or other elements need to be empty, like today, the label has to be configured as "empty", or the corresponding key.
The "generated" key should reflect the real "location" of an element, not where it's inherited from. e.g the "save" action label of dialog foobar should first be looked up at <dialog-name>.actions.save
before actions.save
.
dialogs.pages.faq.stkFAQHeader.tabMain.title.label
- TBD - The
dialogs
prefix is not relevant and noisy. It was historically introduced to separate those labels from the page templates and page components names and description. Indeed, we're likely to have astkFAQHeader.name
somewhere. Currently leaning towards using separate message bundles. Or have an non-mandatory prefix/suffix (i.e there's a chance the component's title/name needs the same label as its first tab ?)
MessagesManager
info.magnolia.cms.i18n.MessagesManager
is the component that has been used to handled i18n up until Magnolia 4.5. It has its flaws, and should be rewritten.
...
However, actions definitions also need to be i18n'd. For apps, it would make sense to have i18nBasename
defined at the app level ({{AppDescriptor
}}). Dialogs however are not necessarily tied to an app i.e they're used by the page-editor, so we wouldn't want to use the page-editor's i18nBasename.
...