Community
Participate
Working Groups
Ensure that where possible, UML2 uses the platform’s mechanism for loading messages, i.e. with a class that has static keys for all of its messages.
Deferred to the next release
The platform's Messages/NLS framework is implemented in Equinox. I am assuming that we don't want to use this in plug-ins that need to support stand-alone deployment (Eclipse-free). -> Is this assumption correct? Given this assumption, that restricts applicability of the Messages/NLS framework to the plug-ins that require the Eclipse environment anyways, namely: * the codegen plug-ins * the example editor * the Ecore model importer plug-in * the Ecore model exporter plug-in Analyzing the code and prototyping some changes shows that most of the strings in the editor plug-in (being mostly in custom actions) can be replaced with access to a Messages class and some of the strings in the other plug-ins can likewise be Messages-ified. The exceptions are primarily strings in * generated code based on templates in or derived from EMF/Ecore (editor, action bar contributor, codegen adapters) * strings shared amongst multiple plug-ins, declared in the org.eclipse.uml2.uml plug-in and accessible via EMFPlugin's flexible resource delegation mechanism. Anything to do with conversion options is in this category, plus some others I would not want to convert these strings to Messages/NLS because 1. Many of these strings are already translated into several languages by IBM and the Babel project. Copying or moving them means breaking existing translations or having to move/copy the translations, too (how?) 2. These strings are effectively API: it's all public EMF APIs that provide access to these strings and UML2's XyzPlugin classes are all public API. As a result, these exceptions are so many that it makes the code rather inconsistent once as many strings as possible are converted to Messages/NLS. Moreover, the majority of those strings are in an example plug-in (the editor). So, it is hard to conclude that there is sufficient merit in making any changes and I am inclined to resolve this enhancement as "investigated and resolved as WONTFIX".
(In reply to comment #2) > -> Is this assumption correct? Yes. > As a result, these exceptions are so many that it makes the code rather > inconsistent once as many strings as possible are converted to Messages/NLS. > Moreover, the majority of those strings are in an example plug-in (the editor). > So, it is hard to conclude that there is sufficient merit in making any changes > and I am inclined to resolve this enhancement as "investigated and resolved as > WONTFIX". Agreed. Thanks for taking the time to investigate this and for providing the careful analysis.
