15 Oct
2008
15 Oct
'08
6:55 p.m.
Ludovic Dubost wrote:
Jerome Velociter wrote:
The problem is not $msg from velocity, but 3rd party plugins that
explicitely uses com.xpn.xwiki.web.XWikiMessageTool. I could put the
localization component behind $msg today and it will be 100% backwards
compatible.
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 ?
Yes, besides javadoc, there's
http://code.xwiki.org/xwiki/bin/Plugins/LocalizationPlugin
>> 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") ?
No, the proper term is Localization, and the official acronym is L10N. I
could go with $localization if $l10n is too cryptic.
Or, an alternative is to take the risk and replace $msg until we can
access $services.localization.
>> From me, +1 to all of these.
>>
> +1 for all the rest
>
>
>> WDYT? Any volunteers where needed?
>>
--
Sergiu Dumitriu
http://purl.org/net/sergiu/