Hi Jerome,
On Jul 18, 2007, at 7:59 PM, Jerome Velociter wrote:
On 7/16/07, Vincent Massol <vincent(a)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