[cle-release-team] i18n locales defaults handling

Thu Apr 4 06:07:28 PDT 2013

I didn't realize we were moving the definition of locales out of sakai.properties and into the kernel. I worry that this will make adding new translations to Sakai even more difficult that it currently is. I think that adding new translations is not "rare", but it will be with this change :-(

Now the only way a language can be added is through a kernel change, where it used to be through a sakai.properties change. It looks like we've also lost the support for the "locales.more" sakai property, which was greatly valued by the i18n community when testing out new translations. I think that loading the locales in one place is fine, but requiring a kernel change is very bad. 

- Beth

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
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team