You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Alexander Klimetschek <ak...@day.com> on 2008/06/05 12:41:16 UTC
Re: I18N changes
Hi all,
sorry for the suspense ;-) Here are my ideas for an IMHO better i18n
message structure; please find listings of the current nodetypes and
my new proposal at the end of the mail.
1) I think the name "sling:Language" is misleading. I suggest to name
it "sling:MessageBundle", because it is a container for messages, not
a language.
2) Not sure for which use cases the sling:basename propert is needed.
3) sling:MessageBundle would only contain sling:Messages - we don't
want to mix it with other content if this structure is typically
auto-generated (eg. XLIFF importer)
4) sling:Message can be a node type, I don't see the case where one
wants to mix it with an existing node type structure and needs a
mixin. sling:MessageEntry can be removed then.
5) Not sure about the nt:hierarchyNode inheritance for
sling:Message(Entry) - do we need it?
6) The sling:key should be optional and only be used if the actual key
(which would typically be the original, eg. english, source string) is
not a valid JCR name. Otherwise the node name should be the key (no
need for generating message1, message2, etc.)
7) If the key is not valid for the jcr name, we generate a valid name
based on the key, to make the node structure more browsable.
Here is a pseudo algorithm for generating the key:
input: node name
esc = cut off 50 char from key
esc = escape esc (using
org.apache.jackrabbit.util.Text.escapeIllegalJcrChars())
if escaped == original key => put in node name
else => put in sling:key property, use
ensure unique name! append number
WDYT?
Current i18n nodetypes
==================
// The sling:language mixin node type allows to list one or more base
// names of resource bundles to which the messages below this language
// node belong.
[sling:Language] > mix:language
mixin
- sling:basename (string)
- sling:basename (string) multiple
// Mixin node type for a single key to message mapping
// This mixin node type may be applied to any node such, that mappings
// may be located just inside some existing node hierarchy
[sling:Message]
mixin
- sling:key (string)
- sling:message (undefined)
[sling:MessageEntry] > nt:hierarchyNode, sling:Message
Proposed new i18n Nodetypes
========================
Example node tree:
/libs/languages
+ Deutsch (sling:MessageBundle)
- jcr:language = de-ch
+ Ok (sling:Message)
- sling:message = "'sch Ok"
+ Lorem_Ipsum_001 (sling:Message)
- sling:key = "Lorem Ipsum is simply [...]"
- sling:message = "Mir doch egal."
Nodetypes:
[sling:MessageBundle] > mix:language
+ * (sling:Message)
[sling:Message]
- sling:key (string)
- sling:message (undefined)
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: I18N changes
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Jun 5, 2008 at 12:41 PM, Alexander Klimetschek <ak...@day.com> wrote:
> input: node name
Ups, this is wrong. It should say "input: key". The node name is the
outcome of this algorithm, the key / source string of the message is
the input.
> esc = cut off 50 char from key
> esc = escape esc (using
> org.apache.jackrabbit.util.Text.escapeIllegalJcrChars())
> if escaped == original key => put in node name
> else => put in sling:key property, use
> ensure unique name! append number
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: I18N changes
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Dienstag, den 10.06.2008, 17:06 +0200 schrieb Carsten Ziegeler:
> As we're cutting a new release, it would imho be great to include these
> changes as well.
That would be good. Not sure, whether we get the code ready by then ...
Regards
Felix
>
> Carsten
>
> Felix Meschberger wrote:
> > Hi,
> >
> > Am Donnerstag, den 05.06.2008, 15:18 +0200 schrieb Alexander
> > Klimetschek:
> >> On Thu, Jun 5, 2008 at 2:06 PM, Felix Meschberger <fm...@gmail.com> wrote:
> >>> Given the changes below, I think, we should not release the i18n module
> >>> yet with the initial Sling release. Instead we should carefully build
> >>> these changes into the module and release as soon as we are ready.
> >> Ok, sounds like the best way to handle this situation. AFAIK there is
> >> only one project using this bundle right now and we have control over
> >> it.
> >>
> >>> Please, create an issue for these changes.
> >> I will do so once when we have concensus in this thread.
> >
> > I think we almost have consensus, except for the key thing below ...
> >
> >
> >>>> 6) The sling:key should be optional and only be used if the actual key
> >>>> (which would typically be the original, eg. english, source string) is
> >>>> not a valid JCR name. Otherwise the node name should be the key (no
> >>>> need for generating message1, message2, etc.)
> >>> Not sure, whether this is implementable.
> >>>
> >>> If you could provide me with good queries to find messages by key, I
> >>> might get convinced. In priniciple, I think it is not a bad idea. But it
> >>> must be implementable ;-)
> >> Three solutions come to my mind:
> >>
> >> a) Use a sling:key == key OR nodename = escaped(key) (algorithm from
> >> 7) query. But I am not sure if this is possible.
> >
> > not needed, see (c)
> >
> >> b) The query would run use algorithm from 7) below to generate the
> >> non-unique part of the node name and do a jcr:like("Same_name_%"). If
> >> this results in multiple results (eg. Same_name_1, Same_name_2), it
> >> has to manually find the correct one by looping over the result set
> >> and looking at the sling:key properties.
> >
> > not needed, see (c)
> >
> >> c) Don't load messages one-by-one but have the JcrResourceBundle load
> >> all messages up-front (upon the first call) in-memory. The internal
> >> hash-map would only store the actual keys. Pro: Simpler implementation
> >> and this might be more efficient anyway, since the messages get
> >> cached. Con: Yet another cache...
> >>
> >> WDYT?
> >
> > Actually, we have two queries in the i18n JcrResourceBundle class: One
> > to get an exact message for a language given its key and one to get all
> > messages for a language. Currently all key/message mappings are cached
> > any way, and when the ResourceBundle.getKeys() method is called, all
> > messages are loaded and cached anyway. So, we just could load these
> > upfront.
> >
> > This of course also makes the code leaner, which giving some performance
> > penalty to the first user of the resource bundle.
> >
> > The other advantage of loading everything upfront is, that we only need
> > a single query which does NOT involve quering for the key value.
> >
> > So, I think, you can create the issue -- and fmeschbe says, he would be
> > happy to also get a patch ;-)
> >
> > Thanks and Regards
> > Felix
> >
> >
>
>
Re: I18N changes
Posted by Carsten Ziegeler <cz...@apache.org>.
As we're cutting a new release, it would imho be great to include these
changes as well.
Carsten
Felix Meschberger wrote:
> Hi,
>
> Am Donnerstag, den 05.06.2008, 15:18 +0200 schrieb Alexander
> Klimetschek:
>> On Thu, Jun 5, 2008 at 2:06 PM, Felix Meschberger <fm...@gmail.com> wrote:
>>> Given the changes below, I think, we should not release the i18n module
>>> yet with the initial Sling release. Instead we should carefully build
>>> these changes into the module and release as soon as we are ready.
>> Ok, sounds like the best way to handle this situation. AFAIK there is
>> only one project using this bundle right now and we have control over
>> it.
>>
>>> Please, create an issue for these changes.
>> I will do so once when we have concensus in this thread.
>
> I think we almost have consensus, except for the key thing below ...
>
>
>>>> 6) The sling:key should be optional and only be used if the actual key
>>>> (which would typically be the original, eg. english, source string) is
>>>> not a valid JCR name. Otherwise the node name should be the key (no
>>>> need for generating message1, message2, etc.)
>>> Not sure, whether this is implementable.
>>>
>>> If you could provide me with good queries to find messages by key, I
>>> might get convinced. In priniciple, I think it is not a bad idea. But it
>>> must be implementable ;-)
>> Three solutions come to my mind:
>>
>> a) Use a sling:key == key OR nodename = escaped(key) (algorithm from
>> 7) query. But I am not sure if this is possible.
>
> not needed, see (c)
>
>> b) The query would run use algorithm from 7) below to generate the
>> non-unique part of the node name and do a jcr:like("Same_name_%"). If
>> this results in multiple results (eg. Same_name_1, Same_name_2), it
>> has to manually find the correct one by looping over the result set
>> and looking at the sling:key properties.
>
> not needed, see (c)
>
>> c) Don't load messages one-by-one but have the JcrResourceBundle load
>> all messages up-front (upon the first call) in-memory. The internal
>> hash-map would only store the actual keys. Pro: Simpler implementation
>> and this might be more efficient anyway, since the messages get
>> cached. Con: Yet another cache...
>>
>> WDYT?
>
> Actually, we have two queries in the i18n JcrResourceBundle class: One
> to get an exact message for a language given its key and one to get all
> messages for a language. Currently all key/message mappings are cached
> any way, and when the ResourceBundle.getKeys() method is called, all
> messages are loaded and cached anyway. So, we just could load these
> upfront.
>
> This of course also makes the code leaner, which giving some performance
> penalty to the first user of the resource bundle.
>
> The other advantage of loading everything upfront is, that we only need
> a single query which does NOT involve quering for the key value.
>
> So, I think, you can create the issue -- and fmeschbe says, he would be
> happy to also get a patch ;-)
>
> Thanks and Regards
> Felix
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: I18N changes
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Alex,
Am Freitag, den 06.06.2008, 13:00 +0200 schrieb Alexander Klimetschek:
> On Thu, Jun 5, 2008 at 3:52 PM, Felix Meschberger <fm...@gmail.com> wrote:
> > So, I think, you can create the issue -- and fmeschbe says, he would be
> > happy to also get a patch ;-)
>
> See https://issues.apache.org/jira/browse/SLING-517
>
> Unfortunately I don't have time to create a patch for that until end
> of next week... So I tried to be very explicit in the description of
> the issue ;-)
Ok, lets see. Thanks and Regards
Felix
Re: I18N changes
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Jun 5, 2008 at 3:52 PM, Felix Meschberger <fm...@gmail.com> wrote:
> So, I think, you can create the issue -- and fmeschbe says, he would be
> happy to also get a patch ;-)
See https://issues.apache.org/jira/browse/SLING-517
Unfortunately I don't have time to create a patch for that until end
of next week... So I tried to be very explicit in the description of
the issue ;-)
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: I18N changes
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Donnerstag, den 05.06.2008, 15:18 +0200 schrieb Alexander
Klimetschek:
> On Thu, Jun 5, 2008 at 2:06 PM, Felix Meschberger <fm...@gmail.com> wrote:
> > Given the changes below, I think, we should not release the i18n module
> > yet with the initial Sling release. Instead we should carefully build
> > these changes into the module and release as soon as we are ready.
>
> Ok, sounds like the best way to handle this situation. AFAIK there is
> only one project using this bundle right now and we have control over
> it.
>
> > Please, create an issue for these changes.
>
> I will do so once when we have concensus in this thread.
I think we almost have consensus, except for the key thing below ...
> >> 6) The sling:key should be optional and only be used if the actual key
> >> (which would typically be the original, eg. english, source string) is
> >> not a valid JCR name. Otherwise the node name should be the key (no
> >> need for generating message1, message2, etc.)
> >
> > Not sure, whether this is implementable.
> >
> > If you could provide me with good queries to find messages by key, I
> > might get convinced. In priniciple, I think it is not a bad idea. But it
> > must be implementable ;-)
>
> Three solutions come to my mind:
>
> a) Use a sling:key == key OR nodename = escaped(key) (algorithm from
> 7) query. But I am not sure if this is possible.
not needed, see (c)
> b) The query would run use algorithm from 7) below to generate the
> non-unique part of the node name and do a jcr:like("Same_name_%"). If
> this results in multiple results (eg. Same_name_1, Same_name_2), it
> has to manually find the correct one by looping over the result set
> and looking at the sling:key properties.
not needed, see (c)
> c) Don't load messages one-by-one but have the JcrResourceBundle load
> all messages up-front (upon the first call) in-memory. The internal
> hash-map would only store the actual keys. Pro: Simpler implementation
> and this might be more efficient anyway, since the messages get
> cached. Con: Yet another cache...
>
> WDYT?
Actually, we have two queries in the i18n JcrResourceBundle class: One
to get an exact message for a language given its key and one to get all
messages for a language. Currently all key/message mappings are cached
any way, and when the ResourceBundle.getKeys() method is called, all
messages are loaded and cached anyway. So, we just could load these
upfront.
This of course also makes the code leaner, which giving some performance
penalty to the first user of the resource bundle.
The other advantage of loading everything upfront is, that we only need
a single query which does NOT involve quering for the key value.
So, I think, you can create the issue -- and fmeschbe says, he would be
happy to also get a patch ;-)
Thanks and Regards
Felix
Re: I18N changes
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Jun 5, 2008 at 2:06 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Given the changes below, I think, we should not release the i18n module
> yet with the initial Sling release. Instead we should carefully build
> these changes into the module and release as soon as we are ready.
Ok, sounds like the best way to handle this situation. AFAIK there is
only one project using this bundle right now and we have control over
it.
> Please, create an issue for these changes.
I will do so once when we have concensus in this thread.
>> 2) Not sure for which use cases the sling:basename propert is needed.
>
> This is to support getting a subset of all messages and is comparable in
> some sense to the basename argument of the
> ResourceBundle.getResourceBundle(String, Locale) method. It is used to
> implement the SlingHttpServletRequest.getResourceBundle(String, Locale)
> method.
Ok, makes sense. The property would then be optional.
> but have sling:MessageBundle extend nt:hierarchyNode to be able to place
> such bundles below nt:folder.
+1
>> 4) sling:Message can be a node type, I don't see the case where one
>> wants to mix it with an existing node type structure and needs a
>> mixin. sling:MessageEntry can be removed then.
>>
>> 5) Not sure about the nt:hierarchyNode inheritance for
>> sling:Message(Entry) - do we need it?
>
> If sling:Message are only required (and supported) to be children of a
> sling:MessageBundle node, I am fine with removing that. Instead the
> sling:MessageBundle should extend nt:hierarchyNode (see above).
Yes.
>> 6) The sling:key should be optional and only be used if the actual key
>> (which would typically be the original, eg. english, source string) is
>> not a valid JCR name. Otherwise the node name should be the key (no
>> need for generating message1, message2, etc.)
>
> Not sure, whether this is implementable.
>
> If you could provide me with good queries to find messages by key, I
> might get convinced. In priniciple, I think it is not a bad idea. But it
> must be implementable ;-)
Three solutions come to my mind:
a) Use a sling:key == key OR nodename = escaped(key) (algorithm from
7) query. But I am not sure if this is possible.
b) The query would run use algorithm from 7) below to generate the
non-unique part of the node name and do a jcr:like("Same_name_%"). If
this results in multiple results (eg. Same_name_1, Same_name_2), it
has to manually find the correct one by looping over the result set
and looking at the sling:key properties.
c) Don't load messages one-by-one but have the JcrResourceBundle load
all messages up-front (upon the first call) in-memory. The internal
hash-map would only store the actual keys. Pro: Simpler implementation
and this might be more efficient anyway, since the messages get
cached. Con: Yet another cache...
WDYT?
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: I18N changes
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Hi,
>
> Given the changes below, I think, we should not release the i18n module
> yet with the initial Sling release. Instead we should carefully build
> these changes into the module and release as soon as we are ready.
>
I already anticipated this :) and removed i18n from our release build.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: I18N changes
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Given the changes below, I think, we should not release the i18n module
yet with the initial Sling release. Instead we should carefully build
these changes into the module and release as soon as we are ready.
Please, create an issue for these changes.
More comments inline.
Am Donnerstag, den 05.06.2008, 12:41 +0200 schrieb Alexander
Klimetschek:
> 1) I think the name "sling:Language" is misleading. I suggest to name
> it "sling:MessageBundle", because it is a container for messages, not
> a language.
+1
> 2) Not sure for which use cases the sling:basename propert is needed.
This is to support getting a subset of all messages and is comparable in
some sense to the basename argument of the
ResourceBundle.getResourceBundle(String, Locale) method. It is used to
implement the SlingHttpServletRequest.getResourceBundle(String, Locale)
method.
> 3) sling:MessageBundle would only contain sling:Messages - we don't
> want to mix it with other content if this structure is typically
> auto-generated (eg. XLIFF importer)
+1
but have sling:MessageBundle extend nt:hierarchyNode to be able to place
such bundles below nt:folder.
> 4) sling:Message can be a node type, I don't see the case where one
> wants to mix it with an existing node type structure and needs a
> mixin. sling:MessageEntry can be removed then.
>
> 5) Not sure about the nt:hierarchyNode inheritance for
> sling:Message(Entry) - do we need it?
If sling:Message are only required (and supported) to be children of a
sling:MessageBundle node, I am fine with removing that. Instead the
sling:MessageBundle should extend nt:hierarchyNode (see above).
>
> 6) The sling:key should be optional and only be used if the actual key
> (which would typically be the original, eg. english, source string) is
> not a valid JCR name. Otherwise the node name should be the key (no
> need for generating message1, message2, etc.)
Not sure, whether this is implementable.
If you could provide me with good queries to find messages by key, I
might get convinced. In priniciple, I think it is not a bad idea. But it
must be implementable ;-)
>
> 7) If the key is not valid for the jcr name, we generate a valid name
> based on the key, to make the node structure more browsable.
>
> Here is a pseudo algorithm for generating the key:
>
> input: node name
> esc = cut off 50 char from key
> esc = escape esc (using
> org.apache.jackrabbit.util.Text.escapeIllegalJcrChars())
> if escaped == original key => put in node name
> else => put in sling:key property, use
> ensure unique name! append number
+1 if (6) proves possible.
>
> Proposed new i18n Nodetypes
> ========================
>
> Example node tree:
>
> /libs/languages
> + Deutsch (sling:MessageBundle)
> - jcr:language = de-ch
>
> + Ok (sling:Message)
> - sling:message = "'sch Ok"
>
> + Lorem_Ipsum_001 (sling:Message)
> - sling:key = "Lorem Ipsum is simply [...]"
> - sling:message = "Mir doch egal."
>
> Nodetypes:
>
> [sling:MessageBundle] > mix:language
> + * (sling:Message)
As said above, this would be:
[sling:MessageBundle] > nt:hierarchyNode, mix:language
- basename (string)
+ * (sling:Message)
>
> [sling:Message]
> - sling:key (string)
> - sling:message (undefined)
>
>
All in all this sounds reasonable IMHO.
Regards
Felix