cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "SuichII, Christopher" <>
Subject Re: UI Plugin Internationalization
Date Tue, 16 Jul 2013 15:05:42 GMT
Brian (and all),

I've come back to looking into this feature and want to discuss it a bit more. I like the
idea of putting each plugins dictionary into it's own namespace, but that may make utilizing
it a bit more difficult. Currently, strings are automagically localized through the _l() function,
but this only looks in the global 'dictionary' variable. It seems that our options here would
be to then look into each plugin's dictionary if lookup there fails or require that plugins
look up their own messages themselves.

With this in mind, do we still like the idea of keeping plugin dictionaries in their own namespace
or is putting them into the global dictionary more tempting?


On Jun 20, 2013, at 6:25 AM, Pranav Saxena <> wrote:

> This is a very valid question and I think the file containing the translation strings
for support for other languages would also have to be taken care off when the standard English
strings are being dynamically added to the dictionary from the plugin. 
> -----Original Message-----
> From: Sebastien Goasguen [] 
> Sent: Thursday, June 20, 2013 3:40 PM
> To:
> Cc: 'SuichII, Christopher'; Pranav Saxena; Sonny Chhen; Jessica Wang
> Subject: Re: UI Plugin Internationalization
> On Jun 18, 2013, at 2:08 PM, Brian Federle <> wrote:
>> FYI, I created an improvement ticket for plugin localization: 
> Hi folks, how does this play out with the translation efforts which populates the properties
files in:
> client/WEB-INF/classes/resources
> thanks,
> -sebastien
>> -----Original Message-----
>> From: Brian Federle []
>> Sent: Tuesday, June 18, 2013 11:00 AM
>> To:; 'SuichII, Christopher'
>> Cc: Pranav Saxena; Sonny Chhen; Jessica Wang
>> Subject: RE: UI Plugin Internationalization
>> Hey Chris,
>> How you described it is pretty much how I planned on implementing plugin dictionaries.
>> You can actually attach the plugin's dictionary to cloudStack.plugins.[pluginName],
for example cloudStack.plugins.testPlugin.dictionary, and only attach the dictionary JS that
is set to your locale -- there is a global variable in the JS which indicates what the current
locale is. Alternatively, plugin handling routine can attach the dictionary directly to the
object passed to your plugin's function (i.e., 'plugin.dictionary' from cloudStack.plugins.myPlugin(plugin)
{} function), so you won't have to worry about namespace issues.
>> If you've already written code, then feel free to submit a patch via
and I can take a look at it.
>> -Brian
>> -----Original Message-----
>> From: Chip Childers []
>> Sent: Tuesday, June 18, 2013 9:31 AM
>> To:
>> Cc: Brian Federle; Pranav Saxena; Sonny Chhen; Jessica Wang
>> Subject: Re: UI Plugin Internationalization
>> Adding some UI focused folks to the CC.
>> On Tue, Jun 18, 2013 at 03:15:53PM +0000, SuichII, Christopher wrote:
>>> Sure!
>>> What I'd like: As someone developing a UI plugin, I'd like to be able to contribute
my own internationalized messages/labels/etc. to the JS dictionary. Currently, this can be
done by shoving them all in to the dictionary when your plugin is initialized, but it is not
very pretty - requiring you to determine the locale and require the messages file yourself.
>>> So a little preface. As far as I can tell, all UI plugin loading is done in JS
- that is, not at all in JSPs. So, any UI plugin internationalization needs to be done in
JS, or some of the UI plugin loading needs to be done in JSPs (I'm gonna bet the former is
>>> My idea was to add some JS to dictionary.jsp (whose JS is executed after UI plugins
are loaded). Here we would take the locale from the JSP and require a JS file in plugins/<plugin_name>/dictionary/
depending on the locale.
>>> In my current prototype, the JS files holding the internationalized strings just
store everything in a hash in the cloudStack variable, like: cloudStack.plugin_dictionaries.<plugin_name>.
I've done this because (I'm new to requirejs and) I am yet to find a way to simply return
the hash or have the hash sent as a parameter to a callback of require(...).
>>> Does anyone with more requirejs experience know how we could accomplish this
more elegantly?
>>> I'm also open to suggestions on completely different designs. =)
>>> -Chris
>>> On Jun 18, 2013, at 10:55 AM, Chip Childers 
>>> <>
>>> wrote:
>>>> On Tue, Jun 18, 2013 at 12:18:16PM +0000, SuichII, Christopher wrote:
>>>>> I've got some ideas on how to implement a system for allowing ui plugins
to contribute internationalized strings to the ui dictionary, but I'd like to run things by
a committer. Is there someone(s) who would like to talk offline (or keep replying here) about
this feature?
>>>>> Thanks,
>>>>> Chris
>>>> The best method to collaborate on the project is to use the list to 
>>>> build up the feature proposal...  so explain away here please!

View raw message