[cle-release-team] i18n locales defaults handling

Aaron Zeckoski azeckoski at unicon.net
Thu Apr 4 06:18:26 PDT 2013


Well, technically I would say it is anyone with kernel commit
privileges and I think that page is out of date.
Either way, if we wanted to handle it like that rather than giving
i18n team members commit to the file I mentioned, it would simple to
create a ticket and say "add language code BLAH to supported list" and
allow anyone who is able to make the change.
That also would provide nice tracking in JIRA.
-AZ


On Thu, Apr 4, 2013 at 8:54 AM, Neal Caidin
<nealcaidin at sakaifoundation.org> wrote:
> Thanks!
>
> Seems to me like keeping it through a kernel committer should be fine, since like you say, it is not every day that a new language is added. Is this the Kernel team - https://confluence.sakaiproject.org/pages/viewpage.action?pageId=19005576  ?  Or should this page be updated (or maybe I'm on the wrong page)?
>
> Cheers,
> Neal
>
> On Apr 4, 2013, at 8:48 AM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>
>> That happens quite rarely but as per the locales listing in
>> default.sakai.properties:
>> # NOTE FOR i18n TEAM: please update
>> /component-manager/src/main/java/org/sakaiproject/component/locales/SakaiLocales#SAKAI_LOCALES_DEFAULT
>> array if you add more supported locales
>>
>> So the supported set should be updated in both locations (one as
>> documentation and one as the definition).
>>
>> We should probably get an SVN admin to give commit access to the
>> "component-manager/src/main/java/org/sakaiproject/component/locales"
>> dir to the i18n group though honestly, since it does not happen much
>> it should really probably go through a kernel committer.
>>
>> -AZ
>>
>>
>> On Thu, Apr 4, 2013 at 7:52 AM, Neal Caidin
>> <nealcaidin at sakaifoundation.org> wrote:
>>> How are additional languages added? Do they require changes to code?
>>>
>>> -- Neal
>>>
>>> On Apr 3, 2013, at 5:58 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>>>
>>>> No one else needs to fetch the list of locales that I am aware of. If
>>>> they do, they should use the method in SCS though. In general it is
>>>> probably a core code thing only though.
>>>> -AZ
>>>>
>>>>
>>>> On Wed, Apr 3, 2013 at 5:53 PM, Steve Swinsburg
>>>> <steve.swinsburg at gmail.com> wrote:
>>>>> Is this something that everyone should use or is it really just for these particular tools that did it themselves?
>>>>>
>>>>> Cheers
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 04/04/2013, at 8:18, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>>>>>
>>>>>> Done
>>>>>> https://jira.sakaiproject.org/browse/KNL-1051
>>>>>> -AZ
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 3, 2013 at 11:46 AM, Beth Kirschner <bkirschn at umich.edu> wrote:
>>>>>>> +1
>>>>>>>
>>>>>>> On Apr 3, 2013, at 10:35 AM, Jean-Francois Leveque <jean-francois.leveque at upmc.fr> wrote:
>>>>>>>
>>>>>>>> SCS seems right.
>>>>>>>>
>>>>>>>> J-F
>>>>>>>>
>>>>>>>> On 03/04/2013 16:25, Aaron Zeckoski wrote:
>>>>>>>>> Hey folks,
>>>>>>>>> Just giving you one last chance to comment on this before I act on it
>>>>>>>>> unilaterally. Definitely would prefer some other opinions but I need
>>>>>>>>> to address this so I can't wait forever.
>>>>>>>>> -AZ
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Mar 25, 2013 at 1:40 PM, Aaron Zeckoski<azeckoski at unicon.net> wrote:
>>>>>>>>>> Related to the previous discussion on the CLE team call, it looks like
>>>>>>>>>> the i18n locales are being loaded in multiple places throughout the
>>>>>>>>>> code. This is dangerous because there is post processing that happens
>>>>>>>>>> for the locales (especially related to the "locales.more" for
>>>>>>>>>> debugging and removing duplicates and trimming spaces from the comma
>>>>>>>>>> delimited list.
>>>>>>>>>> This is now handled quite well in the place where user prefs are
>>>>>>>>>> handled but handled inconsistently in help and siteaction.
>>>>>>>>>> -------
>>>>>>>>>> Looks like we have 3 places in the code that duplicate some of the
>>>>>>>>>> code which pulls the languages (inconsistently I notice):
>>>>>>>>>> help/help-component/src/java/org/sakaiproject/component/app/help/HelpManagerImpl.java:936
>>>>>>>>>> site-manage/site-manage-tool/tool/src/java/org/sakaiproject/site/tool/SiteAction.java:13473
>>>>>>>>>>
>>>>>>>>>> I fixed the one here but the other ones do not affect the prefs so
>>>>>>>>>> therefore they were not found and adjusted:
>>>>>>>>>> user/user-tool-prefs/tool/src/java/org/sakaiproject/user/tool/UserPrefsTool.java
>>>>>>>>>>
>>>>>>>>>> Looks like the real solution here is going to be to make an actual
>>>>>>>>>> utility method somewhere (probably in the SCS or something like that)
>>>>>>>>>> to do special handling of the i18n strings.
>>>>>>>>>> ----------
>>>>>>>>>>
>>>>>>>>>> So I think we need to put this logic somewhere. I am open to
>>>>>>>>>> suggestions though I am leaning towards something like kernel utils or
>>>>>>>>>> maybe as part of the SCS. It can still be overridden by anyone who
>>>>>>>>>> wants to set the locales value themselves but given the post
>>>>>>>>>> processing that happens on the locales list I think we need to
>>>>>>>>>> centralize it.
>>>>>>>>>>
>>>>>>>>>> -AZ
>>>>>>>> _______________________________________________
>>>>>>>> cle-release-team mailing list
>>>>>>>> cle-release-team at collab.sakaiproject.org
>>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>>>>> _______________________________________________
>>>>>> cle-release-team mailing list
>>>>>> cle-release-team at collab.sakaiproject.org
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>>>>
>>>>
>>>>
>>>> --
>>>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>>
>>
>>
>>
>> --
>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>



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



More information about the cle-release-team mailing list