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/