Community
Participate
Working Groups
The 'orion.edit.validator' extension point needs to support i18n. Below is a sketch of the new API. Service properties to be added to orion.edit.validator services: * nls : String - Gives the the message bundle path to be uses for translating this validator's messages. Fields to be added to the Problem object [2] * descriptionKey : String - Gives the message key used to look up translated description of this problem. * descriptionArgs : String[] - Arguments to be substituted into the translated message at display time. [1] http://wiki.eclipse.org/Orion/Documentation/Developer_Guide/Plugging_into_the_editor#orion.edit.validator [2] http://wiki.eclipse.org/Orion/Documentation/Developer_Guide/Plugging_into_the_editor#The_Problem_object
Maybe I am misunderstanding what is being asked for here, but it feels to me that the Orion framework side should not have to care about NLS'ing anything, translations should be done by the plug-in that is providing the extension / problem objects. Then on the service side it only shows the message provided to it as-is (via the the problem.description property).
I'm proposing to stick with the i18n story for plugins outlined here, in which the framework manages translations: https://wiki.eclipse.org/Orion/Internationalization#Plugins It does complicate the service APIs a bit, but allows us to ship "language packs" that contain translations for all the Orion default plugins without each having to implement translation logic. We will still support the old "description" field in the Problem API, for plugins that want to handle translation some other way (or not at all).
Created attachment 244760 [details] proposed fix This patch performs NLS'ing of problem messages. It makes use of the updated API on i18nUtil to accept an object for substitutions, and allows the nls property to be specified on the validator declaration, that way we are not resolving N nls bundle lookup promises for N validator problems. Mark, please review the patch to make sure it does not run afoul of any of our NLS stories.
(In reply to Michael Rennie from comment #3) A few minor things - I would name the fields "descriptionKey" and "descriptionArgs", since they're providing a translation of the problem description, not the problem itself. - The code as written doesn't allow a nls-supporting validator to return a simple Problem[] array instead of a { problems: Problem[] } wrapper object. You could just do this instead, which should cover it: > var probs = extractProblems(results); > if (probs.length > 0) { > return i18nutil.getMessageBundle(nls).then( ... > }
Pushed updated fix to: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=f1d2276bc8e645eb37650753b68cd2a0c4234c5d and updated the doc wiki: https://wiki.eclipse.org/Orion/Documentation/Developer_Guide/Plugging_into_the_editor#orion.edit.validator
