[WG: I18N & L10N] i18n strings duplicated across projects

Jean-Francois Leveque jean-francois.leveque at upmc.fr
Wed Sep 9 08:23:10 PDT 2009


As far as I can still think at the end of my day of work, I'm concerned 
about:
- a test we don't need in my favored proposal (complexity increment 1),
- an uncertainty about where ResourceLoader will get the defaults values 
which seems to mean another test with your favored proposal (complexity 
increment 2),
- having to change the kernel for this

- Jean-Francois

Beth Kirschner a écrit :
> I'd worry that making the change to each and every tool would broaden 
> the scope of the change, making it riskier and less likely to succeed. 
> Are you concerned about the timeline of getting out a new kernel version 
> or something else?
> 
> - Beth
> 
> On Sep 9, 2009, at 10:04 AM, Jean-Francois Leveque wrote:
> 
>> Beth,
>>
>> With config avalaible, you're right we don't need another project and 
>> this is a bug fix. The name config made me forget there already was 
>> localization in it.
>>
>> I'm afraid the link in SAK-12351 to 
>> http://www-128.ibm.com/developerworks/java/library/j-bundles/ does not 
>> work anymore.
>>
>> I would favor a common directory in 
>> localization/bundles/src/bundle/org/sakaiproject/localization/bundle 
>> for these shared strings.
>>
>> Instead of adding a test in ResourceLoader.getString() and having to 
>> update the kernel, I would favor tools explicitly calling the common 
>> bundle properties.
>>
>> What do you think?
>>
>> Beth Kirschner a écrit :
>>> Jean-Francois,
>>>   I would call this more of a bug fix than a project that needs to go 
>>> through incubation. Ideally, it would just update the the 
>>> ResourceLoader class (in the kernel) and also move the redundant 
>>> properties to one common properties file. I have commit rights for 
>>> changes to the properties files, if the individual project teams 
>>> don't have the resources and/or time to make the changes. You might 
>>> want to take a look at SAK-12351 which has some ideas. Perhaps the 
>>> simplest fix would be something like this:
>>> // ResourceLoader.getString() pseudo-code
>>> if (requested property file has key/value)
>>>   return value;
>>> else if (common property file has key/value)
>>>   return value;
>>> else
>>>   return property key not found error;
>>>   The sakai/config/localization directory provides us a common 
>>> location for a global properties file, that is accessible to all 
>>> projects (Thanks Anthony!), so this shouldn't be that difficult of a 
>>> task.
>>> Thanks!
>>> - Beth
>>> On Sep 9, 2009, at 6:19 AM, Jean-Francois Leveque wrote:
>>>> Hi Clay and i18n WG members,
>>>>
>>>> There are issues such as:
>>>> http://jira.sakaiproject.org/browse/SAK-16735
>>>> http://jira.sakaiproject.org/browse/SAK-16738
>>>>
>>>> I think these issues should be fixed.
>>>>
>>>> I volunteer to provide a solution for sharing i18n strings across 
>>>> Sakai.
>>>>
>>>> If anyone else is willing to work on this, he's welcome.
>>>>
>>>> The thing I need is project teams volunteering to review and merge
>>>> changes to the affected tools when a solution is available.
>>>>
>>>> I will also need a project directory on the main svn to host the
>>>> shared-i18n code.
>>>>
>>>> I think this project should go through incubation, even if it's a light
>>>> incubation. Do you agree, Clay?
>>>>
>>>> Jean-François
>>>> _______________________________________________
>>>> i18n mailing list
>>>> i18n at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/i18n
>>>>
>>>> TO UNSUBSCRIBE: send email to 
>>>> i18n-unsubscribe at collab.sakaiproject.org with a subject of 
>>>> "unsubscribe"


More information about the i18n mailing list