[sakai2-tcc] Roster tool changes

[Daniel Robinson]

I think there may be some confusion here, at least in the case of the  
new Roster tool.

We don't do any localization server-side. We only use ResourceLoader  
to retrieve the language code from the locale, which is then passed as  
a parameter with the request. The language code is required so the  
client uses the appropriate translations .js file.

If the language code is not specified, we get it via  
navigator.userLanguage for IE and navigator.language for other browsers.

Perhaps it would better to just get it via navigator and avoid  
ResourceLoader completely.

Best wishes,

Daniel

On 20 Aug 2010, at 15:34, John Bush wrote:

> Right, that's where I was going to go next.   The stuff I did is all
> under the ResourceLoader cover, caching included.  So the first thing
> is every existing tool/new tool really needs to use that to load
> bundles (when they are doing stuff server side), a lot of current
> tools bypass it, and load stuff right through ResourceBundle.  You
> can't modify ResourceBundle without violating sun's I mean oracle
> license, already looked into that, and we don't want to get sued too.
> But that's not a big deal, all the web frameworks have hooks for that
> sort of thing.  I've got a JSF and Spring one done that works with the
> RSF tools, and Steve has pointed me to a wicket one as well.  I've
> identified the affected existing tools and am working to fix that now.
>
> But back to JS, probably what we need is a general server side servlet
> type thing, that takes a bundle via a parameter or path and then just
> calls the ResourceLoader and builds up the javascript.  We also need
> to work out the loading of the bundle data into that database.  The
> options are:
>
> 1.  force these types of tools to continue to declare data in bundles
> and deploy in a webapp and make them load that bundle during init time
> via a ResourceLoader call (that's how it works now).
> 2.  add another mechanism to the server side component mentioned above
> which some how allows the data to be loaded.
>
> I think there's there are probably reasons beyond technical ones to
> consider.  For example, most of the tools people use to do
> translations understand property file syntax.  So that makes going
> with #1 a better option, or if we are going to explore #2, maybe find
> a way to keep the property file syntax.
>
> On Fri, Aug 20, 2010 at 5:08 AM, csev <csev at umich.edu> wrote:
>> John,
>>
>> Just thinking out loud, it does seem like a good opportunity here  
>> to add support for your new way of storing localization in the DB  
>> for Javascript/Trimpath style apps and get that right from the  
>> beginning for JS style apps.
>>
>> Also, does your new db-backed localization have some caching built  
>> in?  I would think that it would really respond well using cashe.  
>> (Separate question)
>>
>> /Chuck
>>
>> On Aug 20, 2010, at 4:42 AM, Daniel Robinson wrote:
>>
>>> Hi John,
>>>
>>> Yes, the locale is determined server-side using ResourceLoader and
>>> passed as an argument to the JavaScript code.
>>>
>>> Best wishes,
>>>
>>> Daniel
>>>
>>> On 19 Aug 2010, at 23:48, John Bush wrote:
>>>
>>>> Couple questions about how you are handling localization.  Looks  
>>>> like
>>>> all the bundle data is coming from .js files.  How is the locale
>>>> determined ?  Is that still from ResourceLoader on the server  
>>>> side ?
>>
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>
>
>
>
> -- 
> John Bush
> 602-490-0470