best practise for multi language support

[Walter Raboch <wr...@ingen.at>]

Hi all,

We just debated how to support multiple languages.
Instead of using one node appl:learningObject we decided to split up 
into structural nodes (Ending Node) and describing nodes (Ending Desc). 
So we can add any number of lanugages and each describing node can be 
versioned by itself. So we can support translators by searching for each 
node having just one describing node or where the version numbers differ.

Node: appl:learningObjectNode (mixin:referencable)
   - Node: appl:learningObjectDesc (mixin:language)
     - Property: appl:lanugage = "DE"
     - Property: appl:title = "Lernobjekt"
   - Node: appl:learningObjectDesc (mixin:language)
     - Property: appl:language = "EN"
     - Property: appl:title = "Learning Object"
   - other children
     - Node: appl:chapter
     - Node: appl:chapter

Are there any other suggestions or is there already some best practise?

Perhaps the next version of JSR170 should support a MultiValue type with 
subkeys... e.g. title = [("DE", "Lernobjekt"),("EN","Learning Object")]

cheers,

Walter

Re: best practise for multi language support

[Walter Raboch <wr...@ingen.at>]

Hi Edgar,

> IMHO there's already a best practice and it's out of the jcr scope[1]. 
> Moreover, there are tools for extending the default localization 
> capabilities[2]. And if you stick to the standards there are GUIs that 
> might help you to edit your i18n texts [3].

I think you misunderstood me. I don´t want to internationalize the 
application itself (it is already) but the data. We develop a learning 
platform for one of our customers and we want to provide the learning 
content (scripts, audio, video, descriptions, pictures, ... ) in at 
least 2 languages (English, German). A future requirement is even Chinese.
So it is a matter of how to design the node types to store user data ?

> But it's not my intention to discourage you, on the contrary I think 
> there's an interesting role for jcr regarding i18n. A ResourceBundle 
> backed by a jcr impl might be useful, WDYT?. It could provide many 
> features that would ease i18n and l10n management.

We debated to store the Resources in the repository too. But decided 
against to seperate the application version specific language strings 
from user data. At least in the first step.

cheers,
Walter

Re: best practise for multi language support

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

hi guys,

my personal experience is that having more coarse 
grained language blocks works better for a number of
processes in an organization (workflows, acl, ...)

which essentially means that something like

(a)
/en
  /course01
    /learningobj01
  /course02
  /course03
/de
  /course01
  /course02


... works better than ...

(b)
/course01
  /learningobj01
    /en
    /de
/course02
/course03

i know that this is counter intuitive for most application 
developers, and i do not really have any reasoning beyond
experience why this is the case.

> > Are there any other suggestions or is there already some best practise?
i agree with edgar that it is outside the scope of jcr, but i think a well 
known mixin that specifies the language would be valuable for
many applications:
something along the lines of mix:language containing a property
jcr:language that would show values like: "de-DE" "en-GB"
this should obviously use the natural inheritance of the hierarchy
which means on the above example (a) it would on be applied
to /en and /de .

> But it's not my intention to discourage you, on the contrary I think
> there's an interesting role for jcr regarding i18n. A ResourceBundle
> backed by a jcr impl might be useful, WDYT?. It could provide many
> features that would ease i18n and l10n management.
we implemented resource bundles over repositories numerous times
and it think it is a great way to take the responsibility of translating 
resource strings, fix typos, etc. out of the hands of developers and 
put it into the hands of people that actually care about it.

it allows also to fix typos without having to redeploy the 
application, but instead use a cms, workflows, staging and 
content replication to do that.

regards,
david

Re: best practise for multi language support

[Edgar Poce <ed...@gmail.com>]

Hi walter

Walter Raboch wrote:
> Are there any other suggestions or is there already some best practise?
IMHO there's already a best practice and it's out of the jcr scope[1]. 
Moreover, there are tools for extending the default localization 
capabilities[2]. And if you stick to the standards there are GUIs that 
might help you to edit your i18n texts [3].

But it's not my intention to discourage you, on the contrary I think 
there's an interesting role for jcr regarding i18n. A ResourceBundle 
backed by a jcr impl might be useful, WDYT?. It could provide many 
features that would ease i18n and l10n management.

BR,
edgar

[1]
http://java.sun.com/docs/books/tutorial/i18n/index.html.

[2]
http://jakarta.apache.org/commons/resources/, 
http://jakarta.apache.org/commons/sandbox/i18n/

[3]
http://i18nedit.sourceforge.net/userdoc/

> 
> Perhaps the next version of JSR170 should support a MultiValue type with 
> subkeys... e.g. title = [("DE", "Lernobjekt"),("EN","Learning Object")]
> 
> cheers,
> 
> Walter
>