Ludovic Dubost wrote:
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.
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.
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/