[cle-release-team] i18n locales defaults handling

[Aaron Zeckoski]

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

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