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