Hi Jerome,

On Jul 18, 2007, at 7:59 PM, Jerome Velociter wrote:

On 7/16/07, Vincent Massol <vincent@massol.net> 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