[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