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!"
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 well. 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. :-)
