On Wed, Oct 15, 2008 at 9:40 AM, Jerome Velociter <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Sergiu Dumitriu wrote:
>> Hi devs,
>>
>> The new localization component is committed. I think it is working
>> pretty well, so it's time to decide what to do next (estimate deadlines
>> and responsibles after each item):
>>
>> 0. Outside review - me and Marta refactored it about 5 times already, a
>> third opinion would be nice.
>> ASAP, let's say by the end of the week - volunteers; this is a good
>> exercise, as it shows how to write and use components
>> 1. Add it in the build cycle (include it in the core pom as a submodule)
>> ASAP - me
>> 2. Deprecate the XWikiMessageTool class and methods. Should be
>> completely phased out by 1.9 according to our deprecation strategy.
>> ASAP - me
>> 3. Use it in the xwiki-core, replacing the messagetool
>> Full replacement until 1.7M2 - me and other volunteers
>> 4. Propose a standard for writing keys
>> Next week - me + discussion on devs
>> 5. Start properly translating applications in their own documents
>> Until 1.7 final - everybody, especially application owners
> ok, I can help and do that for the scheduler and workstream
>
>> 6. Split ApplicationResources into smaller files, moving everything to
>> its proper place: .properties files in plugins, wiki documents for
>> applications, CoreResources.properties (the clean version of
>> ApplicationResources).
>> Until 1.7 final - everybody
>> 7. Improve the localization component:
>> 7a. Replace hashmaps with caches
>> Until 1.7M2 - me or volunteers
>> 7b. Write tests
>> Until 1.7M2 - me or volunteers
>>
>> A note for items 2 and 3: The localization component interface is
>> compatible with the message tool, as it provides the get(string) and
>> get(string, list) methods. However, old code casts the retrieved object
>> to XWikiMessageTool, so replacing the "msg" context variable is not
>> advisable yet. I used 'l10n' as the variable name for the new tool, as
>> it reflects better what it does. And, as Vincent suggested, this is a
>> workaround until the velocity bridge is in place, when we shouldn't use
>> direct context variables, but request access to services through this
>> bridge.
> $l10n.get("key") ?
>
> -0
> I don't like it very much. What about $messages.get("key") ?Same here not really for me but seems too technical for a user. >> >> From me, +1 to all of these. > +1 for all the rest +1 > >> WDYT? Any volunteers where needed? Most of the work is already done for application manager and wiki manager, simply it's another toold so I will take care of "migration" for theses two plugins/applications when it will depends on 1.7 (when 1.7 will be stable branch). > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
