Generic i18n keys - 5 UI
These generic i18n keys have been deprecated since Magnolia 6.0. They are part of the Magnolia 5 UI framework.
For the updated implementations, see Generic i18n keys for Magnolia 6 UI instead.
Generic i18n keys can be used in more than one location simultaneously, such as in multiple modules, apps and subapps, tabs or views. A list of such keys is provided at the end of this page.
Reusing keys from other modules
At startup, Magnolia creates a global message bundle by reading keys
.properties files of all modules in the current project. The
global bundle is a virtual bundle, not a physical file. It includes keys
from your module and keys from Magnolia’s own modules such as
This means that you do not need to provide keys for all UI elements in your app. Keys for commonly reused elements such as buttons and subapps are in Magnolia’s own modules. Just reuse the UI element in your app, and Magnolia will find the existing key automatically. In simple terms, the shorter the form of the key, the more places it will apply to.
Example: The contact edit form has Save changes and Cancel buttons.
The Contacts app does not provide
the text for either button in its own message bundle. They are provided
file of the
# Default Action Labels actions.commit=save changes actions.cancel=cancel
Therefore, it is not necessary to insert two specific keys such as the
following into the
.properties file of the Contacts app.
contacts-app.actions.commit=save changes contacts-app.actions.cancel=cancel
If your app needs these buttons, just name your
Providing a key to other modules or apps
If a key is to be made available to other modules or apps, make the key
less specific by omitting the
<app> part of the key. See
the list below for acceptable shorter forms of i18n keys.
Example: The key for the
teaser component in the MTK module
can be shortened just to
By omitting the module name (
mtk) from the key, the shorter form can
be reused for translation in other modules, e.g. in Travel Demo
Overriding a generic key
There are, however, scenarios when a translation for an element has to
be different from the one available in the generic key. In this case,
the user still has the option to expand the key from its short (generic)
form into a longer pattern that specifies the element (e.g. the module,
app, subapp, etc.) where the translation should appear. For example, if
the key for the
teaser component in the Travel Demo module needs a
different translation from that used in MTK, the key can be expanded
into a more specific form:
travel-demo.templates.components.teaser=The Travel Demo Teaser
The translation will now be available primarily to the
component in the Travel Demo module.
List of generic i18n keys
The parts in
[brackets] can be omitted.
If used in the key,
If used in the key,
The generic i18n key for a field validator is
If a validator is defined for the field, the i18n keys may take the validator suffix: