On 17.12.2013, at 14:05, Tobias Bocanegra <[email protected]> wrote: > I was looking at SLING-2881 [0] and reading the docu at [1]. the i18n > code has 1 queries, one is: > > 1) //element(*,mix:language)
Unfortunately this is too broad, mix:language can be many nodes, depending on the application. That's why we effectively are using the query below only which makes it more specific again by looking at mix:language nodes that have a sling:Message node. The mistake we probably made was to not introduce a "dictionary" base node type. The problem manifests in the observation which gets triggered on mix:language and is too broad (SLING-2881). Although I already made a proposal how we can solve SLING-2881 without having to change the content structure (see issue). > 2) > //element(*,mix:language)[@jcr:language='en']//element(*,sling:Message)[@sling:message]/(@sling:key|@sling:message) > > the first one is to find all language bundle roots, and the 2nd is > used to actually load all messages for 1 bundle. I suggest to replace > the second one by a manual traversal, since all messages are usually > just directly below the language nodes. Yes, it was just a bit simpler to implement using a query, since it also needs to support deep structures (we used them earlier, so sling i18n supports it). But even for that, a traversal using the javax.jcr.util.TraversingItemVisitor should be trivial. However, we might be iterating way too much if we start on all mix:language nodes. So I am not sure if we have to solve the performance of this query. If we fix the observation, this query will run only whenever a "dictionary" is updated or when the system starts. Updating dictionaries only happens very rarely in applications. Cheers, Alex
