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 (JIRA)" <ji...@apache.org> on 2009/10/28 12:55:59 UTC

[jira] Issue Comment Edited: (SLING-1131) i18n: do not enforce a flat node hierarchy below mix:language

    [ https://issues.apache.org/jira/browse/SLING-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770902#action_12770902 ] 

Alexander Klimetschek edited comment on SLING-1131 at 10/28/09 11:54 AM:
-------------------------------------------------------------------------

> the key went away

Because the key is not mandatory (for quite a while), because if it is not present, the node name is used (that's why I added [@sling:message] to fetch only all nodes that have at least that required property set).

In my (manual) tests it worked fine, albeit as you note it now, I wonder why the /@sling:message was necessary to get the property, but a missing /@sling:key does work somehow. I think we could change the code to use a NodeIterator for the results (or Resource iterator when the resource query api is used) and not use the IMHO somewhat awkward row iterator JCR result.

I will try to write a test case and verify it, albeit that involves the repository and thus needs a bit more effort.

      was (Author: alexander.klimetschek):
    > the key went away

Because the key is not mandatory (for quite a while), because if it is not present, the node name is not used (that's why I added [@sling:message] only to fetch only all nodes that have at least that required property set).

In my (manual) tests it worked fine, albeit as you note it now, I wonder why the /@sling:message was necessary to get the property, but a missing /@sling:key does not work. I think we should change the code to use a NodeIterator for the results (or Resource iterator when the resource query api is used) and not use the IMHO somewhat awkward row iterator JCR result.

I will try to write a test case and verify it, albeit that involves the repository and thus needs a bit more effort.
  
> i18n: do not enforce a flat node hierarchy below mix:language
> -------------------------------------------------------------
>
>                 Key: SLING-1131
>                 URL: https://issues.apache.org/jira/browse/SLING-1131
>             Project: Sling
>          Issue Type: Improvement
>          Components: Extensions
>    Affects Versions: I18n 2.0.2
>            Reporter: Alexander Klimetschek
>            Priority: Minor
>             Fix For: I18n 2.0.2
>
>         Attachments: SLING-1131.patch
>
>
> Currently the search for translations enforces a flat hierarchy below the mix:language node (that eg. says 'de' for the translation language) for the sling:Message nodes that hold the single translations. If you have many translations, eg. thousands, the flat hierarchy can get slow in Jackrabbit, so it would be good to support a nested hierarchy as well.
> The change boils down to the query that is done. Currently it looks like this (eg. for fetching all translations for 'de'):
> //element(*,mix:language)[@jcr:language='de']/*/(@sling:key|@sling:message)
> It should introduce a descendant-or-self step:
> //element(*,mix:language)[@jcr:language='de']//*/(@sling:key|@sling:message)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.