On Tue, Oct 23, 2012 at 3:31 PM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
On Tue, Oct 23, 2012 at 1:17 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> 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
+1. I like the separation between getting the translation and
rendering it with parameters.
= 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).
+1. For extensions (especially applications) its better to pull the
translation bundle rather than registering it for the entire wiki.
= 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.
+1, though I think this is less important.
Yes a lot less but it's the kind of thing that needs to be done from
the start ;)
Thanks,
Marius
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs