[sakai2-tcc] Roster2 to replace Roster

Mon Sep 16 06:58:52 PDT 2013

It's more that the i18n data would load from the ResourceLoader (which
mostly means loading from the properties files in that vast majority
of cases and not from the database).
-AZ

On Mon, Sep 16, 2013 at 9:49 AM, Adrian Fish <adrian.r.fish at gmail.com> wrote:
> If I read things correctly, yes. Roster2 will replace Roster in trunk if and
> when the i18n packs are loaded from the db. That will mean 2.10, think.
>
> Cheers,
> Adrian.
>
>
> On 16 September 2013 12:08, Neal Caidin <neal.caidin at apereo.org> wrote:
>>
>> Does this mean that some changes will be made to Roster2 and it will be
>> targeted for 2.10/Trunk?
>>
>> Thanks,
>> Neal
>>
>>
>>
>> Neal Caidin
>> Sakai CLE Community Coordinator
>> neal.caidin at apereo.org
>> Skype: nealkdin
>> Twitter: ncaidin
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sep 16, 2013, at 4:40 AM, Adrian Fish <adrian.r.fish at gmail.com> wrote:
>>
>> Alright, already ... :)
>>
>> If it's not JIRA'd, could one of you fine fellows raise a ticket? I like
>> Matthew's generic REST target idea; it does sound like people have done this
>> a couple of ways, so standardising going forward makes sense.
>>
>> Cheers,
>> Adrian.
>>
>>
>> On 13 September 2013 15:35, John Bush <jbush at anisakai.com> wrote:
>>>
>>> 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. **
>>
>>
>> _______________________________________________
>> 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
>


-- 
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile