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? -Chris On Jun 20, 2013, at 6:25 AM, Pranav Saxena <pranav.sax...@citrix.com> 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 [mailto:run...@gmail.com] > Sent: Thursday, June 20, 2013 3:40 PM > To: dev@cloudstack.apache.org > Cc: 'SuichII, Christopher'; Pranav Saxena; Sonny Chhen; Jessica Wang > Subject: Re: UI Plugin Internationalization > > > On Jun 18, 2013, at 2:08 PM, Brian Federle <brian.fede...@citrix.com> wrote: > >> FYI, I created an improvement ticket for plugin localization: >> https://issues.apache.org/jira/browse/CLOUDSTACK-3058 > > 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 [mailto:brian.fede...@citrix.com] >> Sent: Tuesday, June 18, 2013 11:00 AM >> To: dev@cloudstack.apache.org; '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 >> reviews.apache.org and I can take a look at it. >> >> -Brian >> >> -----Original Message----- >> From: Chip Childers [mailto:chip.child...@sungard.com] >> Sent: Tuesday, June 18, 2013 9:31 AM >> To: dev@cloudstack.apache.org >> 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 preferred). >>> >>> 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 >>> <chip.child...@sungard.com> >>> 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! >>> >>> >
