On 5/24/07, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi,On 5/21/07, Grizz Lee <[EMAIL PROTECTED]> wrote: > I have an application that stores projects with a code and a name in a jackrabbit > repository. In a new version of this application it must be possible to have names > in english and in french. > [...] > So I'm thinking to make a name-language childnode: > [app:project] > nt:folder > - app:code (string) > + * (app:name) multiple > [app:name] > nt:hierarchyNode > - app:name (string) > - app:language (string) > And then use XPath to select the correct childnode for a given language. > > Is there a better way to handle multiple languages or is this the way to go? > Comments are welcome. There's no clear best practice yet on how to represent multilingual content. I would also go for separate child nodes for the different languages, but in a slightly more general mannner: [i18n:localizable] mixin + * (i18n:localization) [i18n:localization] - * (STRING) A i18n:localizable node could have any number of i18n:localization child nodes named after the specific language. The localization nodes could have any string properties with translated values. Something like this: .../mynode .../mynode/i18n:en - title = "Hello, World!" .../mynode/i18n:fi - title = "Hei maailma!"
We are using exactly this model to store i18n values, so thanks for confirming our initial modelling :-).
The downside of using child nodes is that even though Jackrabbit currently does support the child axis in XPath predicates the standard JCR API does not, so you can't formulate standard queries that look for properties both in the mynode parent and in a i18n:* child.
I am still wondering about some of these details in the spec. Most of the time they sound like limitations on some of possible implementations, but nothing that couldn't be overcome. ./alex -- .w( the_mindstorm )p.
BR, Jukka Zitting
