You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 16, 2021. It is now read-only.
Currently, the PhpcrOdmAdapter does not take care of the content document locale when creating the routes for translatable documents.
The _locale default is not added to the route defaults. So, when the route content document is mapped to the contentDocument request attribute, the request locale remains to the default locale.
I know this can be resolved by using the Lunetics Locale bundle but it rely on the URL, which isn't what I'm looking for.
The '_locale' requirement is not added to the route requirement. So, when an URL is generated from a content document (using the ContentAwareGenerator), the first route always matches regardless the locale of the content.
I resolved those issues using a custom Adapter which simply add the missing default and requirement when creating a route.
But are those behaviors intended ?
The text was updated successfully, but these errors were encountered:
sounds like it would be useful to have this. question is whether it should always be active or only on demand. @dantleech wdyt about this? should there be a config to enable this? should it be enabled or disabled by default? or does it always make sense to do this (if the doctrine phpcr odm manager has multilang enabled, that is)?
i don't see harm, but feel that its a BC break to do it by default. people might have relied on it to work the way it used to work. we are about to release 2.0, i won't have time to implement this for 2.0 and at this point rather want to get the release out than delay further...
adding to the mapping should work in a BC manner. and having a way to specify arbitrary defaults for the route looks like a clean solution.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Currently, the PhpcrOdmAdapter does not take care of the content document locale when creating the routes for translatable documents.
The
_locale
default is not added to the route defaults. So, when the route content document is mapped to thecontentDocument
request attribute, the request locale remains to the default locale.I know this can be resolved by using the Lunetics Locale bundle but it rely on the URL, which isn't what I'm looking for.
The '_locale' requirement is not added to the route requirement. So, when an URL is generated from a content document (using the ContentAwareGenerator), the first route always matches regardless the locale of the content.
I resolved those issues using a custom Adapter which simply add the missing default and requirement when creating a route.
But are those behaviors intended ?
The text was updated successfully, but these errors were encountered: