[sakai2-tcc] Roster2 to replace Roster

[John Bush]

Right that is the other benefit, anyone who just talks in English and
wants to change the instructional text on the site editor page...
Problem solved.  Without that you end with forked nightmares, been
there done that.

On Fri, Sep 13, 2013 at 7:30 AM, Matthew Jones <matthew at longsight.com> wrote:
> We are making heavy use of the dynamic translations. If you're just one
> school, maybe it's not a huge time saver but it is for managing dozens.
> Still the flexibility it gives for a single school (being able to put up a
> clarifications, warnings or new information immediately) is pretty great. It
> saves on a lot of code changes, keeping custom forks up dated and providing
> much quicker fixes. Even though there was a bug where it was going to the DB
> a lot more than expected (soon to be fixed in 2.9.x SAK-23887), it was still
> worth it to save on the code changes/redeploys. So i'd say having this
> feature consistent for everything is a good thing.
>
>
> On Fri, Sep 13, 2013 at 10:24 AM, Adrian Fish <adrian.r.fish at gmail.com>
> wrote:
>>
>> There's also jquery's way:
>>
>> https://code.google.com/p/jquery-i18n-properties
>>
>> It uses standard java property files so translations can handled with the
>> same tools. It doesn't solve the dynamic updating of i18n props though. How
>> important is that though? How often do people actually need to dynamically
>> update translations, and is it worth the overhead of hitting the db or cache
>> to get them?
>>
>> Cheers,
>> Adrian.
>>
>>
>> On 13 September 2013 15:10, John Bush <jbush at anisakai.com> wrote:
>>>
>>> There's at least one thing I'd like to see addressed.
>>>
>>>
>>> https://source.sakaiproject.org/contrib/roster2/trunk/roster-app/src/webapp/roster-translations-ca.js
>>>
>>> I don't find that an acceptable way of doing localization.  Its not
>>> consistent with the rest of Sakai, and it won't work with the dynamic
>>> manipulation of bundles.  It makes it harder for anyone who is used to
>>> working with properties to maintain this stuff, since tools won't
>>> support this arbitrary js format.
>>>
>>> It easy to address, I had to do it for gb2.  You need to just create a
>>> servlet that loads this the data from the ResourceLoader and then
>>> transforms it into your javascript format.
>>>
>>> Also, I'd like verification that there aren't any FERPA issues
>>> introduced.   I see https://jira.sakaiproject.org/browse/RSTR-16, but
>>> its worth asking just to be sure.
>>>
>>> On Fri, Sep 13, 2013 at 6:54 AM, Steve Swinsburg
>>> <steve.swinsburg at gmail.com> wrote:
>>> > I proposed it years ago. Better integration, better support, more
>>> > features, same UI as old roster tool.
>>> >
>>> > Cheers,
>>> > S
>>> >
>>> > Sent from my iPad
>>> >
>>> > On 13/09/2013, at 23:45, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>>> >
>>> >> Those notes were from the conference back in June and have just been
>>> >> slightly reorganized. I am not sure who proposed replacing roster with
>>> >> roster 2 but maybe that person can add the reasoning. I am not aware
>>> >> of anything myself.
>>> >>
>>> >> On Fri, Sep 13, 2013 at 9:31 AM, May, Megan Marie <mmmay at iu.edu>
>>> >> wrote:
>>> >>> I don’t see rationale in the notes.   Can you please provide
>>> >>> something
>>> >>> substantial for those of us not on the call?
>>> >>>
>>> >>>
>>> >>>
>>> >>> From: sakai2-tcc-bounces at collab.sakaiproject.org
>>> >>> [mailto:sakai2-tcc-bounces at collab.sakaiproject.org] On Behalf Of Neal
>>> >>> Caidin
>>> >>> Sent: Friday, September 13, 2013 7:37 AM
>>> >>> To: sakai2-tcc at collab.sakaiproject.org 2
>>> >>> Subject: [sakai2-tcc] Roster2 to replace Roster
>>> >>>
>>> >>>
>>> >>>
>>> >>> From the TCC - CLECC call -
>>> >>> https://confluence.sakaiproject.org/display/TCC/TCC+CLE+Action+Items
>>> >>>
>>> >>>
>>> >>>
>>> >>> For the folks on the call, there was consensus that Roster2 should
>>> >>> replace
>>> >>> Roster for 2.10/trunk.
>>> >>>
>>> >>>
>>> >>>
>>> >>> Steve Swinsburg says this is not a lot of work to make happen.
>>> >>>
>>> >>>
>>> >>>
>>> >>> Consensus on this one?
>>> >>>
>>> >>>
>>> >>>
>>> >>> Cheers,
>>> >>>
>>> >>> Neal
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> Neal Caidin
>>> >>>
>>> >>> Sakai CLE Community Coordinator
>>> >>>
>>> >>> neal.caidin at apereo.org
>>> >>>
>>> >>> Skype: nealkdin
>>> >>>
>>> >>> Twitter: ncaidin
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> sakai2-tcc mailing list
>>> >>> sakai2-tcc at collab.sakaiproject.org
>>> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>> >> _______________________________________________
>>> >> sakai2-tcc mailing list
>>> >> sakai2-tcc at collab.sakaiproject.org
>>> >> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> > _______________________________________________
>>> > sakai2-tcc mailing list
>>> > sakai2-tcc at collab.sakaiproject.org
>>> > http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>
>>>
>>>
>>> --
>>> John Bush
>>> 602-490-0470
>>>
>>> ** This message is neither private nor confidential in fact the US
>>> government is storing it in a warehouse located in Utah for future
>>> data mining use cases should they arise. **
>>> _______________________________________________
>>> sakai2-tcc mailing list
>>> sakai2-tcc at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>
>>
>>
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>
>



-- 
John Bush
602-490-0470

** This message is neither private nor confidential in fact the US
government is storing it in a warehouse located in Utah for future
data mining use cases should they arise. **