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