[sakai2-tcc] Roster tool changes

[John Bush]

I don't think this is critical either.

My two cents re: feasibility of including this in the 2.8 release?

I'm with Megan, I don't think there time for enough production
experience.  I think I'd feel different if this was crucial
functionality that we don't have that everybody wants, but that's not
the case here, its a re-write.

On Fri, Aug 20, 2010 at 8:54 AM, csev <csev at umich.edu> wrote:
> Yes, ultimately, at the end of the day, for the Roster tool and other JS-rendering tools, the translations come from the server in Javascript format.   The browser grabs a URL and gets the translations.
>
> In order to allow a bit of abstraction, for example to allow the translations to end up happening in a database rather than property files so we can do translations continuously instead of only as part of a release, we would need to get a bit of a servlet that fed out the Javascript formatted translations - it would look the same to the client side code - it would grab a URL and get translation strings.
>
> The difference is that a bit of code would be involved in producing the strings instead of a flat file and naming convention.
>
> I am not sure this is *critical* - but it seems like a good opportunity to use this moment to get it right if folks have a bit of resources.  The benefit of getting it right is that other tools can use the same pattern going forward so we end up with "one way to do it".
>
> At the same time this should hopefully not block progress or cause too much pain.
>
> /Chuck
>
> On Aug 20, 2010, at 11:09 AM, John Bush wrote:
>
>> It's not about how you get the locale that sounds fine, it's about how
>> you define the translations. 2.8 is going to have a new feature that
>> allows bundle data to load from the db, this makes tinting changes and
>> maintaining local mods (even just in english) much easier vs
>> maintaining 150+ bundle files.
>>
>> The issue is with how you define the translations in js files , this
>> will totally bypass this feature.I'm suggesting we look at that and
>> find a way to still allow you to import js files but those would be
>> generated via database backed data vs hardcoded on the client dude.
>> Make sense?
>>
>> Sent from my commodore 64
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>



-- 
John Bush
602-490-0470