jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tako Schotanus" <quinte...@gmail.com>
Subject Re: Properties in multiple languages
Date Thu, 24 May 2007 14:34:02 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!"

But doesn't this mean that the i18n:xx nodes are always, let's say,
"untyped"? Because the node definition of "mynode" could contain the
"title" property for example, but you can't do that for the i18n:xx
sub-node because you might need it for a bunch of other node types as

I've used a very similar structure where it basically comes down to
naming conventions: "mynode" would just be a generic folder type while
the name of the node itself determines it's language, but somehow for
me it doesn't "feel right". It depends too much on a rule of thumb. Of
course you can make a tool that enforces the rule but still.

In other cases I tend to only allow translated resources and have an
extended nt:resource that has a language attribute and something
similar to nt:file that allows multiple nt:resources.

But in the end I'm still looking for a way to solve this
transparently, a bit in the way that you don't know if your repository
has versioning or not, a way where I automatically get the resources
in my defined language if it exists or a fallback if it doesn't. :-)

View raw message