cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <run...@gmail.com>
Subject Re: UI Plugin Internationalization
Date Thu, 20 Jun 2013 10:10:03 GMT

On Jun 18, 2013, at 2:08 PM, Brian Federle <Brian.Federle@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.Federle@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.childers@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.childers@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!
>> 
>> 


Mime
View raw message