On Tue, Oct 23, 2012 at 1:17 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: +1. I like the separation between getting the translation and rendering it with parameters. +1. For extensions (especially applications) its better to pull the translation bundle rather than registering it for the entire wiki. +1, though I think this is less important.

Thanks, Marius _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On 10/23/2012 12:17 PM, Thomas Mortagne wrote: 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").

The main reason I think support for that use case if important is that more and more like the notion of "single XWiki page" application (for small applications, obviously) makes sense to me. Where the page holds everything : XClass definition, sheet, sheet binding, a wiki macro, JSX/SSX, etc. Having to use the content field it forces to have a separate page for i18n.

Cheers, Jerome _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

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