[Proposal] Internationalizing XWiki Applications
Hi, Here's my proposal for internationalizing XWiki apps. The idea is to propose several solutions for XWiki apps writers: * Use case 1: I have lots of text on my page - solution: use XWiki's mechanism for translating page by creating several editions of the page in the different languages * Use case 2: I want translation resources for my application only and I'd like to share resources between pages - solution: use: $msg("mykey", "MySpace.MyTranslationDocForThisApplication") - MySpace.MyTranslationDocForThisApplication is a standard document to which a XWiki.PropertiesClass object is attached - It'll search first in that doc's PropertiesClass and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files * Use case 3: I want translation resources only for a given page - solution: use: $msg("mykey", $doc) - You'll need to have attached a PropertieClass object to the page where $msg is used - It'll search first in that object and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files * Use case 4: I want to have a global translation resources for all my apps in the wiki - solution: use: $msg("mykey") - You'll need to have created ad registered resource bundle documents in the Wiki preferences - It'll search first in XWiki's registered document bundles and if not there in XWiki's static resource bundle files Implementation details: * Add XWikiMessageTool.get(String, String) API * Add XWiki.PropertiesClass class in XE in the Administration Application + a class sheet for presenting the properties nicely WDYT? Thanks -Vincent
hmm... I forgot one thing... We still need the ability to translate in different language inside the XWiki.PropertiesClass object... Thus I propose the following convention: * One XWikiPropertiesClass per required translation * The language is defined as property of the XWikiPropertiesClass class which has 2 property: - one "locale" property - one "properties" property with properties on each line as in a properties file Thanks -Vincent On Jul 16, 2007, at 4:49 PM, Vincent Massol wrote:
Hi,
Here's my proposal for internationalizing XWiki apps. The idea is to propose several solutions for XWiki apps writers:
* Use case 1: I have lots of text on my page - solution: use XWiki's mechanism for translating page by creating several editions of the page in the different languages
* Use case 2: I want translation resources for my application only and I'd like to share resources between pages - solution: use: $msg("mykey", "MySpace.MyTranslationDocForThisApplication") - MySpace.MyTranslationDocForThisApplication is a standard document to which a XWiki.PropertiesClass object is attached - It'll search first in that doc's PropertiesClass and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
* Use case 3: I want translation resources only for a given page - solution: use: $msg("mykey", $doc) - You'll need to have attached a PropertieClass object to the page where $msg is used - It'll search first in that object and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
* Use case 4: I want to have a global translation resources for all my apps in the wiki - solution: use: $msg("mykey") - You'll need to have created ad registered resource bundle documents in the Wiki preferences - It'll search first in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
Implementation details:
* Add XWikiMessageTool.get(String, String) API * Add XWiki.PropertiesClass class in XE in the Administration Application + a class sheet for presenting the properties nicely
WDYT?
Thanks -Vincent
I can think of one potential drawback: Document objects are loaded/ saved at the same time as the object and thus the more translations there are for the page the longer it'll take to display the page, although the performance is probably minimal as this should be done in the same SQL query. -Vincent On Jul 16, 2007, at 5:00 PM, Vincent Massol wrote:
hmm... I forgot one thing... We still need the ability to translate in different language inside the XWiki.PropertiesClass object...
Thus I propose the following convention:
* One XWikiPropertiesClass per required translation * The language is defined as property of the XWikiPropertiesClass class which has 2 property: - one "locale" property - one "properties" property with properties on each line as in a properties file
Thanks -Vincent
On Jul 16, 2007, at 4:49 PM, Vincent Massol wrote:
Hi,
Here's my proposal for internationalizing XWiki apps. The idea is to propose several solutions for XWiki apps writers:
* Use case 1: I have lots of text on my page - solution: use XWiki's mechanism for translating page by creating several editions of the page in the different languages
* Use case 2: I want translation resources for my application only and I'd like to share resources between pages - solution: use: $msg("mykey", "MySpace.MyTranslationDocForThisApplication") - MySpace.MyTranslationDocForThisApplication is a standard document to which a XWiki.PropertiesClass object is attached - It'll search first in that doc's PropertiesClass and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
* Use case 3: I want translation resources only for a given page - solution: use: $msg("mykey", $doc) - You'll need to have attached a PropertieClass object to the page where $msg is used - It'll search first in that object and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
* Use case 4: I want to have a global translation resources for all my apps in the wiki - solution: use: $msg("mykey") - You'll need to have created ad registered resource bundle documents in the Wiki preferences - It'll search first in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
Implementation details:
* Add XWikiMessageTool.get(String, String) API * Add XWiki.PropertiesClass class in XE in the Administration Application + a class sheet for presenting the properties nicely
WDYT?
Thanks -Vincent
On 7/16/07, Vincent Massol <[email protected]> wrote:
Hi,
Hello Vincent, I am glad you raise that topic. With the current system, we tend to keep our application's translation in a unique document, and it can fast becomes unmaintainable. Here's my proposal for internationalizing XWiki apps. The idea is to
propose several solutions for XWiki apps writers:
* Use case 1: I have lots of text on my page - solution: use XWiki's mechanism for translating page by creating several editions of the page in the different languages
* Use case 2: I want translation resources for my application only and I'd like to share resources between pages - solution: use: $msg("mykey", "MySpace.MyTranslationDocForThisApplication") - MySpace.MyTranslationDocForThisApplication is a standard document to which a XWiki.PropertiesClass object is attached - It'll search first in that doc's PropertiesClass and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
Small XWiki applications that lives within a single XWiki space can alternatively use the current resources management system, and a WebPreferences for this space that precise the proper documentBundles to use only in that space, right ? * Use case 3: I want translation resources only for a given page
- solution: use: $msg("mykey", $doc) - You'll need to have attached a PropertieClass object to the page where $msg is used - It'll search first in that object and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
This sounds a bit being the same as use case 2, no? instead of passing the document name to use, you pass a reference to the document itself, and can possibly do something like $msg.get("mykey", $myAppResourceDoc) (however, It has the advantage to be literally shorter) What about a $doc.getMsg("key"), that would first lookup in a PropertieClass object in the doc, and if not found, in the registered bundles, then in the static resources ? * Use case 4: I want to have a global translation resources for all
my apps in the wiki - solution: use: $msg("mykey") - You'll need to have created ad registered resource bundle documents in the Wiki preferences - It'll search first in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
Implementation details:
* Add XWikiMessageTool.get(String, String) API * Add XWiki.PropertiesClass class in XE in the Administration Application + a class sheet for presenting the properties nicely
Once we have that new message system, it would be great IMHO for XE to have as much resources as possible stored inside the wiki, so that it's customizable by end users; and then keep static resources files only for when there's is no other choice (like exception localized messages ?) Jerome. WDYT?
Thanks -Vincent
-- You receive this message as a subscriber of the [email protected] list. To unsubscribe: mailto: [email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Hi Jerome, On Jul 18, 2007, at 7:59 PM, Jerome Velociter wrote:
On 7/16/07, Vincent Massol <[email protected]> wrote: Hi,
Hello Vincent,
I am glad you raise that topic. With the current system, we tend to keep our application's translation in a unique document, and it can fast becomes unmaintainable.
Here's my proposal for internationalizing XWiki apps. The idea is to propose several solutions for XWiki apps writers:
* Use case 1: I have lots of text on my page - solution: use XWiki's mechanism for translating page by creating several editions of the page in the different languages
* Use case 2: I want translation resources for my application only and I'd like to share resources between pages - solution: use: $msg("mykey", "MySpace.MyTranslationDocForThisApplication") - MySpace.MyTranslationDocForThisApplication is a standard document to which a XWiki.PropertiesClass object is attached - It'll search first in that doc's PropertiesClass and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
Small XWiki applications that lives within a single XWiki space can alternatively use the current resources management system, and a WebPreferences for this space that precise the proper documentBundles to use only in that space, right ?
This is not currently implemented (only wiki-wide resources are implemented right now) but it could be added.
* Use case 3: I want translation resources only for a given page - solution: use: $msg("mykey", $doc) - You'll need to have attached a PropertieClass object to the page where $msg is used - It'll search first in that object and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
This sounds a bit being the same as use case 2, no? instead of passing the document name to use, you pass a reference to the document itself, and can possibly do something like $msg.get ("mykey", $myAppResourceDoc) (however, It has the advantage to be literally shorter)
It is the same implementation but the use case is slightly different.
What about a $doc.getMsg("key"), that would first lookup in a PropertieClass object in the doc, and if not found, in the registered bundles, then in the static resources ?
Sounds good to me.
* Use case 4: I want to have a global translation resources for all my apps in the wiki - solution: use: $msg("mykey") - You'll need to have created ad registered resource bundle documents in the Wiki preferences - It'll search first in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
Implementation details:
* Add XWikiMessageTool.get(String, String) API * Add XWiki.PropertiesClass class in XE in the Administration Application + a class sheet for presenting the properties nicely
Once we have that new message system, it would be great IMHO for XE to have as much resources as possible stored inside the wiki, so that it's customizable by end users; and then keep static resources files only for when there's is no other choice (like exception localized messages ?
Yes, 100% agreed. Actually this is the exact reason I started this thread :) Thanks -Vincent
Hi Vincent, Sorry for responding so late to this. There is however something that scares me about your proposal. The use case is this: changing the translation of one single existing string (suppose the previous translation was not good enough). It seems to me it will be hard to find out where the translation of this particular string is defined. The most severe seem to be use cases 2 and 3, where the call to msg explicitly specifies a place, but well that is just taken as a hint.
- It'll search first in that doc's PropertiesClass and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
Assuming there are 3 document bundles registered with XWiki, there will be 5 different places (and a fixed order between them) where the user needs to look for his string. So what is the reason for applying the fallback mechanism when the user has explicitly mentioned where the string should come from? Regards, Catalin On 7/16/07, Vincent Massol <[email protected]> wrote:
Hi,
Here's my proposal for internationalizing XWiki apps. The idea is to propose several solutions for XWiki apps writers:
* Use case 1: I have lots of text on my page - solution: use XWiki's mechanism for translating page by creating several editions of the page in the different languages
* Use case 2: I want translation resources for my application only and I'd like to share resources between pages - solution: use: $msg("mykey", "MySpace.MyTranslationDocForThisApplication") - MySpace.MyTranslationDocForThisApplication is a standard document to which a XWiki.PropertiesClass object is attached - It'll search first in that doc's PropertiesClass and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
* Use case 3: I want translation resources only for a given page - solution: use: $msg("mykey", $doc) - You'll need to have attached a PropertieClass object to the page where $msg is used - It'll search first in that object and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
* Use case 4: I want to have a global translation resources for all my apps in the wiki - solution: use: $msg("mykey") - You'll need to have created ad registered resource bundle documents in the Wiki preferences - It'll search first in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
Implementation details:
* Add XWikiMessageTool.get(String, String) API * Add XWiki.PropertiesClass class in XE in the Administration Application + a class sheet for presenting the properties nicely
WDYT?
Thanks -Vincent
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Hi Catalin, On Jul 25, 2007, at 9:45 AM, Catalin Hritcu wrote:
Hi Vincent,
Sorry for responding so late to this. There is however something that scares me about your proposal.
The use case is this: changing the translation of one single existing string (suppose the previous translation was not good enough).
It seems to me it will be hard to find out where the translation of this particular string is defined. The most severe seem to be use cases 2 and 3, where the call to msg explicitly specifies a place, but well that is just taken as a hint.
- It'll search first in that doc's PropertiesClass and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
Assuming there are 3 document bundles registered with XWiki, there will be 5 different places (and a fixed order between them) where the user needs to look for his string.
So what is the reason for applying the fallback mechanism when the user has explicitly mentioned where the string should come from?
I wasn't sure about that myself and I think I agree with you that if the user specified the location from where to take the translation then we shouldn't bubble up. Thanks -Vincent
On 7/16/07, Vincent Massol <[email protected]> wrote:
Hi,
Here's my proposal for internationalizing XWiki apps. The idea is to propose several solutions for XWiki apps writers:
* Use case 1: I have lots of text on my page - solution: use XWiki's mechanism for translating page by creating several editions of the page in the different languages
* Use case 2: I want translation resources for my application only and I'd like to share resources between pages - solution: use: $msg("mykey", "MySpace.MyTranslationDocForThisApplication") - MySpace.MyTranslationDocForThisApplication is a standard document to which a XWiki.PropertiesClass object is attached - It'll search first in that doc's PropertiesClass and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
* Use case 3: I want translation resources only for a given page - solution: use: $msg("mykey", $doc) - You'll need to have attached a PropertieClass object to the page where $msg is used - It'll search first in that object and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
* Use case 4: I want to have a global translation resources for all my apps in the wiki - solution: use: $msg("mykey") - You'll need to have created ad registered resource bundle documents in the Wiki preferences - It'll search first in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
Implementation details:
* Add XWikiMessageTool.get(String, String) API * Add XWiki.PropertiesClass class in XE in the Administration Application + a class sheet for presenting the properties nicely
WDYT?
Thanks -Vincent
Vincent Massol wrote:
Hi Catalin,
On Jul 25, 2007, at 9:45 AM, Catalin Hritcu wrote:
Hi Vincent,
Sorry for responding so late to this. There is however something that scares me about your proposal.
The use case is this: changing the translation of one single existing string (suppose the previous translation was not good enough).
It seems to me it will be hard to find out where the translation of this particular string is defined. The most severe seem to be use cases 2 and 3, where the call to msg explicitly specifies a place, but well that is just taken as a hint.
- It'll search first in that doc's PropertiesClass and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
Assuming there are 3 document bundles registered with XWiki, there will be 5 different places (and a fixed order between them) where the user needs to look for his string.
So what is the reason for applying the fallback mechanism when the user has explicitly mentioned where the string should come from?
I wasn't sure about that myself and I think I agree with you that if the user specified the location from where to take the translation then we shouldn't bubble up.
General use case: A document will be part of an application, thus it will use mainly that application's resources. And a properly translated document will use several resources, most of them defined in the same document. So, why not have a $msg.useBundle("MyApp.MyAppsTranslationResources"), which will be marked as the default place where to look for resources, with a fallback on the wiki-wide resources? $msg.useBundle will register in the context the bundle used in the current request. In $msg.get(String), if there is a registered preferred bundle, then it is searched first, then fallback on the space bundles, the global bundles, and the static resources. The registered bundle should be stored and restored in the context whenever there is another document included. This means that #includeTopic will not change the bundle registered before the call. Some questions I'm not sure I have the right answer for: - Should the preferred bundles be a list or just a single value? Using more than one $msg.useBundle should mark all those bundles as used, and in which order? I'd say that only one used bundle at a time is enough. If the resources are all used in one document, then they should be defined in the same bundle. - When including other documents (#includeTopic, #includeForm), should the includer's bundle be preserved in the context? This might have an effect on how the included doc looks, depending on where it is viewed from, and this is not something we should allow, so I'd say that for each #include* the used bundle should be cleared during the include, and restored when returning to the outer document. - Is a fallback really needed? If we properly separate resources into applications, then there should be no need for it. As Jerome said, the platform should contain nothing but the most core platform specific messages, which an application wouldn't need to use. So, $msg.get should either search in the preferred bundle, if one is registered, or in the wiki-wide resources otherwise.
Thanks -Vincent
On 7/16/07, Vincent Massol <[email protected]> wrote:
Hi,
Here's my proposal for internationalizing XWiki apps. The idea is to propose several solutions for XWiki apps writers:
* Use case 1: I have lots of text on my page - solution: use XWiki's mechanism for translating page by creating several editions of the page in the different languages
* Use case 2: I want translation resources for my application only and I'd like to share resources between pages - solution: use: $msg("mykey", "MySpace.MyTranslationDocForThisApplication") - MySpace.MyTranslationDocForThisApplication is a standard document to which a XWiki.PropertiesClass object is attached - It'll search first in that doc's PropertiesClass and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
* Use case 3: I want translation resources only for a given page - solution: use: $msg("mykey", $doc) - You'll need to have attached a PropertieClass object to the page where $msg is used - It'll search first in that object and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
* Use case 4: I want to have a global translation resources for all my apps in the wiki - solution: use: $msg("mykey") - You'll need to have created ad registered resource bundle documents in the Wiki preferences - It'll search first in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
Implementation details:
* Add XWikiMessageTool.get(String, String) API * Add XWiki.PropertiesClass class in XE in the Administration Application + a class sheet for presenting the properties nicely
WDYT?
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi, The new Application Manager (http://www.xwiki.org/xwiki/bin/view/Code/WikiManagerApplication) support resource bundle translation page list by application. We can use it so that $msg("mykey") : - search in applications containing the current document - then applications dependencies - then resource bundle registered in XWiki.XWikiPreferences - and finish with static resource bundle files vmassol wrote:
Hi,
Here's my proposal for internationalizing XWiki apps. The idea is to propose several solutions for XWiki apps writers:
* Use case 1: I have lots of text on my page - solution: use XWiki's mechanism for translating page by creating several editions of the page in the different languages
* Use case 2: I want translation resources for my application only and I'd like to share resources between pages - solution: use: $msg("mykey", "MySpace.MyTranslationDocForThisApplication") - MySpace.MyTranslationDocForThisApplication is a standard document to which a XWiki.PropertiesClass object is attached - It'll search first in that doc's PropertiesClass and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
* Use case 3: I want translation resources only for a given page - solution: use: $msg("mykey", $doc) - You'll need to have attached a PropertieClass object to the page where $msg is used - It'll search first in that object and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
* Use case 4: I want to have a global translation resources for all my apps in the wiki - solution: use: $msg("mykey") - You'll need to have created ad registered resource bundle documents in the Wiki preferences - It'll search first in XWiki's registered document bundles and if not there in XWiki's static resource bundle files
Implementation details:
* Add XWikiMessageTool.get(String, String) API * Add XWiki.PropertiesClass class in XE in the Administration Application + a class sheet for presenting the properties nicely
WDYT?
Thanks -Vincent
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Thomas Mortagne -- View this message in context: http://www.nabble.com/-Proposal--Internationalizing-XWiki-Applications-tf408... Sent from the XWiki- Dev mailing list archive at Nabble.com.
participants (5)
-
Catalin Hritcu -
Jerome Velociter -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol