Re: [xwiki-devs] New localization module

On 10/23/2012 04:30 PM, Thomas Mortagne wrote: > > On Tue, Oct 23, 2012 at 4:17 PM, Jerome Velociter <jerome(a)velociter.fr> > wrote: >> >> On 10/23/2012 12:17 PM, Thomas Mortagne wrote: >>> >>> 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 ! >> >> >> Hi Thomas, >> >> It sounds great overall. Just want to make sure a use case has been >> considered and would be easy to add support for : the possibility to have >> translation XObjects rather than just marker for pages (that would be >> XObjects with two properties : one for defining the language, the other >> one >> a textarea for the translation "properties"). > > Basically the only thing that a user of the module is supposed to use > is what is in the first point. The way you get the acttual Translation > object is totaly up to the Bundle implementation so that use case > would just need to add a new Bundle component for it. > > I don't plan to write any Bundle myself for this use case but > generally speaking my goal with this architecture is to support any > way to store translations.

Ok cool then, I'll give it a go. I was just pointing out it's not possible today with the current i18n mechanism, but that if translations are store one language per-object you can have as many as you want in a single page app. Jerome _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs