Closed Numkil closed 4 years ago
Fixed by #2692
I still have this problem in 5.6.2 somehow (after upgrafe from 4.2) despite I have changes from #2692
hi @krewetka could you share us a screenshot of the issue happening? that would help us a long way in figuring out where it still goes wrong. Also please take notice that the media folder tab is intentionally translated in the language of the content. we could discuss wether this is something we want to keep doing but that was how the CMS was built back in the day.
@Numkil I described a bit more here https://github.com/Kunstmaan/KunstmaanBundlesCMS/issues/1873 when it comes to internals ( priorities of listeners etc).
Screenshot of issues are:
My application uses Symfony 3.4 and I try to migrate application from KunstmaanBundlesCMS 4.2 to newest version and before it it was for me working like on the last sreenshot.
Website have both English and Arabic content.
@Numkil did you have chance to check this problem?
I made temporary fix in my code with overriding event subscriber and changed priority but still would be good to figure it out.
Do anyone have idea why AdminLocaleListener has comment:
// Must be registered before the default Locale listener
? :thinking:
For me it works only when it is registered after and not before.
@krewetka I can't reproduce the behaviour you are experiencing. I've also added the AR locale and have the default priority of 17.
Registered Listeners for "kernel.request" Event
===============================================
------- ------------------------------------------------------------------------------------------------------- ----------
Order Callable Priority
------- ------------------------------------------------------------------------------------------------------- ----------
#1 Symfony\Component\HttpKernel\EventListener\DebugHandlersListener::configure() 2048
#2 Symfony\Component\HttpKernel\EventListener\ValidateRequestListener::onKernelRequest() 256
#3 Symfony\Component\HttpKernel\EventListener\SessionListener::onKernelRequest() 128
#4 Symfony\Component\HttpKernel\EventListener\LocaleListener::setDefaultLocale() 100
#5 Symfony\Component\HttpKernel\EventListener\RouterListener::onKernelRequest() 32
#6 Symfony\Bundle\FrameworkBundle\EventListener\ResolveControllerNameSubscriber::resolveControllerName() 24
#7 Kunstmaan\AdminBundle\EventListener\AdminLocaleListener::onKernelRequest() 17
#8 Symfony\Component\HttpKernel\EventListener\LocaleListener::onKernelRequest() 16
#9 Symfony\Component\HttpKernel\EventListener\LocaleAwareListener::onKernelRequest() 15
#10 Symfony\Bundle\SecurityBundle\Debug\TraceableFirewallListener::configureLogoutUrlGenerator() 8
#11 Symfony\Bundle\SecurityBundle\Debug\TraceableFirewallListener::onKernelRequest() 8
#12 Kunstmaan\AdminBundle\EventListener\PasswordCheckListener::onKernelRequest() 1
#13 Kunstmaan\AdminBundle\EventListener\SessionSecurityListener::onKernelRequest() 0
#14 Stof\DoctrineExtensionsBundle\EventListener\LocaleListener::onKernelRequest() 0
------- ------------------------------------------------------------------------------------------------------- ----------
So the buggy behaviour might be project specific. Can you create a small repoducer app so we can debug the issue further? Thanks!
@acrobat Ok, I will try to prepare it after my vacation. I am starting 2 weeks holidays right now.
It might be solved right now - I will confirm it when I am back. We had at some point set up incorrectly default_locale
to ar
.
To be honest number of options to configure languages is kind of misleading and not clear ,especially when you switch from one version to another. Some thins can be taken from parameters if defined and some are configurable as options in cofiguration.
You have also default_admin_locale
and default_locale
as well and these are not well described in -> https://kunstmaanbundlescms.readthedocs.io/en/stable/bundles/config-reference/ - especially what is the use of them.
At some point we had set up kunstmaan_admin.default_admin_locale: en
- as this is main admin panel langauge and kunstmaan_admin.default_locale: ar
as we thought is should be the main website language. I think this might cause problem.
We switched kunstmaan_admin.default_locale
to main symfony fallback locale ( which is en
) after noticing we have some untranslated things in symfony profiler.
I will confirm in 2 weeks if this was cause of our main admin panel problem or not :crossed_fingers:
@acrobat I can confirm that in my case it was problem with kunstmaan_admin.default_locale: ar
instead of setting fallback locale there which is en
.
It was not clear in docs what this is for and how it is used and difference between this and default_admin_locale
.
My incorrect assumption was that it is website default locale which is "ar" and not "copy" of symfony framework default locale :)
I noticed in a few versions of the bundles that when you change the language of the content you want to edit the whole UI changes language with it instead of using the language chosen in your user object. This is a regression i think.