content modelling

[qcfireball <qc...@yahoo.com>]

Can anyone see a problem with using namespaces to differentiate the different
languages that a piece of content may be in?

For example:  
    I have attributes:  Title, Description, Body
    So, within a given node I may have:
        tnc-en-us:Title
        tnc-en-us:Description
        tnc-en-us:Body
        tnc-esp:Title
        tnc-esp:Description
        tnc-esp-Body
        tnc-fr:Title
        tnc-fr:Description
        tnc-fr:Body
        etc, etc, etc

Or would it be preferable to model it by node structure:
     ..../lang/en-us/
                  Title
                  Description
                  Body
     ..../lang/esp/
                  Title
                  Description
                  Body
     ....etc, etc, etc
or

     ..../lang-en-us/
                  Title
                  Description
                  Body
     ..../lang-esp/
                  Title
                  Description
                  Body
     ....etc, etc, etc
-- 
View this message in context: http://www.nabble.com/content-modelling-tp14619895p14619895.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

Re: content modelling

[David Nuescheler <da...@day.com>]

Hi,

>From my perspective I would argue that it depends a little
bit on the type of content.

If you have trees of relatively coarse grained
content like webpages or documents, (which
it seems, based on the example with description and body) I would
definitely go with a content hierarchy as described below:

/content/myapp/en/myfolder/mypage
/content/myapp/de/myfolder/mypage
/content/myapp/fr/myfolder/mypage

This allows the language trees to structurally
drift apart, which they always do in my experience,
once we deal with the real-life situations of
actual coarse grained content and the subtleties of
localization.

On top of that I would use a mixin to specify the natural
language you are using for a given subtree. in public review
of jsr-283 we specify a mixin with the property jcr:language
that contains the fully qualified language identification like
"en-US". This mixin should only be used once per subtree,
not necessarily on every object in the tree.

Now not all "language trees" need to be able to diverge
(keep in mind though: most do).
In case that I would like to manage something like a message
bundle of an application that really needs all the strings to
be translated in every language i would probably recommend
something like this.

/apps/myapp/i18n/en
/apps/myapp/i18n/fr
/apps/myapp/i18n/de

...and right underneith these nodes I would put stuff like:

+ de
  - jcr:language = "de-DE"
  - myapp:Ok = "OK"
  - myapp:Search = "Suche"
  - myapp:File Not Found = "Datei existiert nicht"


So, personally I would probably stay away from mixing different natural
languages in a single node and also from separating things out with
namespaces or simple different property names.

regards,
david

On 1/4/08, qcfireball <qc...@yahoo.com> wrote:
>
> Can anyone see a problem with using namespaces to differentiate the different
> languages that a piece of content may be in?
>
> For example:
>     I have attributes:  Title, Description, Body
>     So, within a given node I may have:
>         tnc-en-us:Title
>         tnc-en-us:Description
>         tnc-en-us:Body
>         tnc-esp:Title
>         tnc-esp:Description
>         tnc-esp-Body
>         tnc-fr:Title
>         tnc-fr:Description
>         tnc-fr:Body
>         etc, etc, etc
>
> Or would it be preferable to model it by node structure:
>      ..../lang/en-us/
>                   Title
>                   Description
>                   Body
>      ..../lang/esp/
>                   Title
>                   Description
>                   Body
>      ....etc, etc, etc
> or
>
>      ..../lang-en-us/
>                   Title
>                   Description
>                   Body
>      ..../lang-esp/
>                   Title
>                   Description
>                   Body
>      ....etc, etc, etc
> --
> View this message in context: http://www.nabble.com/content-modelling-tp14619895p14619895.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>