sounds like asking for a PHPCR-ODM DQL , then we could handle this perfectly transparent. as an intermediate, a method to build the criterion for a field of a mapped entity would be the right way i think. you could even do that for non-multilang in case you mapped the documents field to some differently named PHPCR property.

here is an example where i manually handle this:
https://github.com/symfony-cmf/SearchBundle/blob/master/Controller/PhpcrSearchController.php

if we were to do it automatically we might not need our own DQL, we could do a QOMWalker. however i doubt that we can fully automate this, since everything can be mixed. ie. one path can have any number of different strategies.

btw .. it might make sense to always namespace the property names, even when using the child translation strategy. this could make it easier to deal with searching across mixed translation strategies.

if we do this change we should provide a migration script

it gets even worse when translated and non-translated documents get mixed up. see for example the cmf sandbox menu admin (not multilang menu). it mixes translated and non-translated documents. since https://github.com/sonata-project/SonataDoctrinePhpcrAdminBundle/pull/100 you can sort on columns, so sorting will half work half not.

there seem to be other solutions like descendant, but if we had join in jackalope-doctrine-dbal that could be a good option https://github.com/jackalope/jackalope-doctrine-dbal/issues/15

I started working on the Join issue and will start working on this issue when the Join feature is more or less stable.