Jerome Velociter 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
>>
I don't think you can remove the old XWikiMessageTool in XWiki 1.9.
Even if this seems far away, a lot of applications use it.
Except if you provide backwards compatiblity for $msg and that things
work seemlessly for applications of course.
Is there a doc of the new component ?
>> 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") ?
>
>> From me, +1 to all of these.
>>
> +1 for all the rest
>
>
>> WDYT? Any volunteers where needed?
>>
>
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
>
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
