The updated development approach in 4.2 and above is consistent with the pattern found in previous versions of Content Services, and have intentionally not followed the standard Dojo pattern. The latest approach uses the same Alfresco.messages object (although this can be reconfigured if you want to use a different root variable) and still sets the global and scope attributes.
If you create a widget with an i18nScope attribute then this is the scope into which the widget’s encapsulated messages will be added. If no i18nScope attribute is defined then the messages will go into a scope called default (unless the widget extends another widget in which case it will inherit the parent’s i18nScope attribute).
The i18n properties from the web script that processes the JSON model will automatically be placed into a new attribute of Alfresco.messages called page.
Whenever the .message() function is called from Alfresco/core/Core all applicable scopes are searched and the most specific result will be applied. These scopes are listed here:
- Global
- Page
- Default scope
- All inherited scopes
- Widget scopes
When creating a custom widget there is a distinction to be drawn between:
- Labels that never change
- Variable labels that can be selected from
- Custom labels
For example, the label for a menu item cannot realistically be included as part of the widget, but an error message could be. When accepting configurable labels they should be passed through the .message() function in case a message key (rather than a localized message) has been provided, as if no match is found then the value supplied to the method is returned.
This means that when constructing the JSON model for a page you could provide:
config: {
label: "message.key"
}
or
config: {
label: msg.get("message.key")
}
At first glance these might appear identical, but if the widget defines a message with the key message.key then this will override any message that the web script might be able to resolve.