jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu ☀" <the.mindstorm.mailingl...@gmail.com>
Subject Re: Properties in multiple languages
Date Thu, 24 May 2007 14:02:31 GMT
On 5/24/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On 5/21/07, Grizz Lee <grizz_lee@hotmail.com> 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
>

Mime
View raw message