[xwiki-devs] New localization module

Hi devs, I started recently to refactor the localization module Sergiu had started. You can look at the current status in the branch https://github.com/xwiki/xwiki-platform/tree/feature-localization. Nothing is working yet but I wrote enough APIs to see a bit more clear on what I'm up to so here it is. This mail is mostly to discuss the general architecture. There will be other more detailed mails for voting class name and things like that. = Get a translation = * here is the main client API: the client ask for a Translation object to LocalizationManager by indicating it's key (String) and locale (java.util.Locale). Then it calls Translation#render() with optional parameters to get a rendering Block as result. This Block is then inserted in the main XDOM using the translation macro or rendered as text by XWikiMessageTools#get() and other APIs like that if there is = Provide new translations = * support "injecting" new translations just by "marking" pages containing translation using an object to not have to list them in XWikiPreferences anymore. This is especially required for extensions. * the same way I think we should be able to provide translation in a jar extension * on idea introduce by Sergiu and that I agree with is the fact that like with ssx/jsx we need to be able to pull a specific translation explicitly without it to be automatically registered for the whole wiki or something like this * LocalizationManager (and more specifically BundleContext) find the right translations bundles to look at by lokuping all the org.xwiki.localization.Bundle components depending of the context (component can be registered for specific wikis/users). = Translation message syntaxes = * translation message syntax: the current syntax of our translations is a MessageTool based syntax depending on the fact that your have custom parameters or not. This syntax is not very good IMO (managing ' char is a mess) but good or not I think we need to have the possibility to introduce new features (like variables, light formating syntax, etc.) whenever we needs it without breaking anything and the way to do it is by having the possibility to have translation resources in different syntaxes and associated parsers. Note that TranslationMessage does not appear anywhere in the Translation API, any Bundle can implement Translation the way it want but we will have a lot of Bundle on our side using this concept of translation message syntax. The main target is wiki translations. Not all that is going to ends up in 4.3 but the goal is to have at least the new architecture support the "old" ApplicationResources resource and XWikiPreferences static translations pages and start introduce dynamically registered wiki translations. Shoot ! -- Thomas Mortagne