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:

On 7/16/07, Vincent Massol <vincent(a)massol.net> wrote: 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 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 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 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?

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. 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 <vincent(a)massol.net> 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 > > * 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 xwiki-dev(a)objectweb.org mailing list. > To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org > For general help: mailto:sympa@objectweb.org?subject=help > ObjectWeb mailing lists service home page: http://www.objectweb.org/wws > >