Bug 270181

Comment 1 James Bruck 2009-04-22 14:15:58 EDT

Deferred to the next release

Comment 2 Christian Damus 2013-09-23 16:11:17 EDT

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

Comment 3 Kenn Hussey 2013-10-01 22:08:22 EDT

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