Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 428640

Summary:	Plugins should consume their own i18n framework
Product:	[ECD] Orion	Reporter:	Maciej Bendkowski <maciej.bendkowski>
Component:	Client	Assignee:	Project Inbox <orion.client-inbox>
Status:	RESOLVED INVALID	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	bartosz.grabski, konradk, libingw, mamacdon.bugs, mamacdon, Szymon.Brandys
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Maciej Bendkowski

2014-02-20 07:52:21 EST

In our current il18n plugin framework, we're putting the responsibility of loading translation bundles onto the plugin consumer, i. e. Orion. In case of plugins shipped with Orion, this solution does not reveal any issues, however might get quite problematic in case of external plugins (Orion extension plugins, 3rd-party plugins, etc.). A better solution would be to allow plugins to consume any arbitrary il18n framework of their own choosing based on the current locale, which should be injected into the plugin at invocation time (as the locale might be changed by users at any given time). This way plugins alone are responsible for their il18n strategy (since we introduce a clean separation of concerns). It also reminds the Eclipse standalone il18n policy for bundles.

Comment 1 Konrad Kolosowski

2014-10-24 10:38:30 EDT

Plugins are already responsible for their i18n of string required at run time  by plugin code (e.g. error messages).

The problem is with strings contributed to orion with service's description (command names, tooltips, etc.).  These are contributed as static and cached by Orion.

In eclipse this is distinction between java message bundles used by plug-in's and plugin.xml for localizing plugin.xml.  The framework reposinble for reading plugin.xml is responsible for accessing plugin.properties.  It seems Orion uses the same approach, but there is problem with implementation.  The bundles are loaded from the wrong domain, and even orion.i18n.message is not called for the default language.

Comment 2 Mark Macdonald

2014-10-30 16:54:09 EDT

(In reply to Konrad Kolosowski from comment #1)
> The problem is with strings contributed to orion with service's description 
> (command names, tooltips, etc.).  These are contributed as static and cached by 
> Orion.

This is a good point. If the Orion UI does not lookup messages at runtime, we must make it part of the plugin contract that whenever the locale changes, plugin data is refreshed. This would permit the plugin to re-register with the correct translations.

Comment 3 Maciej Bendkowski

2014-10-31 04:49:05 EDT

(In reply to Mark Macdonald from comment #2)
> This is a good point. If the Orion UI does not lookup messages at runtime,
> we must make it part of the plugin contract that whenever the locale
> changes, plugin data is refreshed. This would permit the plugin to
> re-register with the correct translations.

Sounds good to me.

Comment 4 Eric Moffatt

2015-05-08 10:30:10 EDT

Here's a link to the new way to do this...

https://wiki.eclipse.org/Orion/Internationalization#Translating_a_plugin