Papyrus/Oxygen Work Description/NewFeature/Internationalization

Papyrus Internationalization

Overview

This feature must allow to manage the internationalization of all Papyrus application using properties file by project. The internationalization is managed by language, country.

Requirements

Requirements for the internationalization are this following:

Use case

The principal use case for this feature is this following:

Technical proposal

Properties files

The initial internalisation data are stored in a ‘*.properties’ file with this following pattern : ‘label_QualifiedName=value’ where:

• QualifiedName corresponds to the UML NamedElement qualified name
• value corresponds to the string value to display

Actually, the internationalisation must be managed as following according to the language (for example, french language):

1. ‘name_fr_FR.properties’
2. ‘name_fr.properties’
3. ‘name.properties’

Resource

The internationalisation must be managed by a resource containing data from EMF meta-model according to the ‘*.properties’ file. The EMF meta-model can be similar to this one:

This data must be loaded and set when the resource set of the project will be opened. This must be managed as following:

To read the ‘*.properties’ file (if exists), the ‘ResourceBundle’ simplify this one. By example:

InternationalisationLibrary library = InternationalisationFactory.eINSTANCE.createInternationalisationLibrary();

ResourceBundle resourceBundle = ResourceBundle.getBundle(eObject, localize);

Enumeration keys = resourceBundle.getKeys();

while (keys.hasMoreElements()) {

InternationalisationEntry entry = InternationalisationFactory.eINSTANCE.createInternationalisationEntry();

String key = (String)keys.nextElement();

entry.setKey(key);

entry.setValue(resourceBundle.getString(key));

library.getEntries().add(entry);

}

The internationalisation library must be created as previously with String ‘key’ in a first way. To create the UML Element reference in a second way, two ways are possible:

• Browse all the UML elements in model and search the qualified name match
• Retrieve the UML Element by its qualified name using ‘NameResolutionUtils’

getLabel() and getKeyword()

All the NamedElement ‘getName()’ methods called must be replaced for the model explorer, diagrams, tables, palette, properties, dialog, etc. In the case of qualifiedName change, the properties file must be not valid anymore for the current modified object. To manage this problem: A Util class must be created to use ‘getLabel()’ or ‘getKeyword()’ instead of ‘getName()’ if the internationalization is managed. This one may use our proper ‘getLabel()’ implementation instead of the UML implementation, because the non-saved properties change must not be retrieve without ‘*.properties’ file saving.

Internationalization preference

The internationalization preference to display label instead of name must be managed by project. Certainly by a namespace, it must maybe be managed by a specific property page on the project?

Other details

Comment UML Element

The comment must not be managed in Papyrus internationalisation.

Diagrams and Tables

The diagrams and the tables must managed the internationalization by using a getLabel() managed directly by our own class.

Direct editors

When the label is display instead of name, the “F2” action must allow modifying the label. The NameResolutionHelper must be managed differently in another hand.

Visualization

Here, find some visualization of future internationalization:

Model Explorer:

Diagram:

Properties view:

Discussion

Ecore Implementation

The implementation of HashMap with object as key and string as value must use some ChangeRecorder with some performance possible impacts. To avoid this problem, this was possible to manage the key as structural feature creating by the ‘getStructuralFeature()’ re-implementation where a structural feature was corresponding to a property key and the value to the property value. Disavantage of this implementation: When an object qualifiedName changed, we are not notified, and its corresponding key is not valid anymore whereas with the HashMap of objects, this management doesn’t change anymore. Maybe this implementation is more efficient is another way, but it is needed to search about another possible reference to the object.