Page History

...

info.magnolia.ui.form.AbstractFormItem#getMessages - should not be public
- Is broken: doesn't use the user locale afaict.
info.magnolia.ui.form.AbstractFormItem#getMessage - should not be public
AbstractFormItem defines a semi-arbitrary message bundles chain (see AbstractFormItem#UI_BASENAMES)
Definition objects( TabDefinition, etc) have an i18nBasename property, which is very redundant with that of the "runtimes" objects ( FormTab, ...). Usage seems consistent ( return definition.getI18nBasename();) but I don't know why this isn't implemented in info.magnolia.ui.form.AbstractFormItem.
Definition objects don't have a common interface. If they did, we could move i18nBasename and label in there. OTOH, some of these objects have more than 1 item to translate (label and description, for example).
view.addFormSection(tab.getMessage(tabDefinition.getLabel()), tab.getContainer()); ...translates the message from the tab and passes it translated before it's actually "displayed". (while the method argument is called tabName not tabLabel - but that passed object becomes an argument called caption later down the stack) - the below would make this sort of code much more explicit. You pass an object meant to be a label. You translate it explicitly - most likely at the last possible moment. Or we even extend Vaadin component so that they know about I18nItem.
getI18nBasename is defined in too many places. It's inconsistent and unintuitive. Why the redundancy between info.magnolia.ui.dialog.Dialog#getI18nBasename and info.magnolia.ui.dialog.definition.DialogDefinition#getI18nBasename for example ?

Suggested key patterns

The below is a rough outline. The 3 goals below are somewhat hard to reach all at once.

...

<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.

for all dialog-related items, we could also use <dialog-id> and fallback to dialog-name, for further specializing. Dialog ID is possibly currently not available; if it is, it's a single string concatenating module name and dialog name, which isn't ideal. It'd be sweet to be able to get back to module id (and app id) from a dialog.

Apps:

<app-id>.label

<app-id>.icon # because the icon might have to be localized

<app-id>.description # because a mouse-over title of the app might be interesting ?

<app-id> could be <module-id>.<app-name> or just app-name (same as for dialogs)

App launcher groups:

app-launcher.<app-group-name>.label # we use the app-launcher prefix, as if app-launcher was an app (which we should consider considering, I suppose)

Templates:

<module-name>.<template-name>.title # I think "title" is what we've been using in 4.x - we could use label for consistency, or simply name

<module-name>.<template-name> # same as above

<module-name>.<template-name>.desc # Useful in template selector

<module-name>.<template-name> is essentially the component ID.

Page components:

<module-name>.<component-name>.title # see remark above

<module-name>.<component-name>

<module-name>.<component-name>.desc

<module-name>.<component-name> is essentially the component ID.

Workbench columns:

<app-id>.<sub-app-name>.views.<view-name>.<column-name>

Example: configuration.browser.views.list.name for /modules/ui-admincentral/apps/configuration/subApps/browser/workbench/contentViews/list/columns/name/label

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

Suggested i18nBasename patterns

Defined in module descriptor
/mgnl-i18n/<module-name>/messages

...

Page tree

Versions Compared

Old Version 23

New Version 24

Key

Suggested key patterns

Suggested i18nBasename patterns