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/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
