On Tue, Oct 23, 2012 at 4:47 PM, Jerome Velociter <[email protected]> wrote: > On 10/23/2012 04:30 PM, Thomas Mortagne wrote: >> >> On Tue, Oct 23, 2012 at 4:17 PM, Jerome Velociter <[email protected]> >> 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. You will have to push on new model for this feature then ;) > > > Ok cool then, I'll give it a go. > > >> >>> 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. >> >> Well you will have other documents for the translations anyway so I'm >> not sure I really see the point. > > > 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 > > >> >>> Cheers, >>> Jerome >>> >>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
