Multilanguage - language change issues

[lindapowers]

Some of us managing multilingual  sites had these problem in the past and with all the guys I spoke it ended up being a plugin causing the issue as Milbo described.

For us it was a custom made plugin, others a one page checkout plugin etc

[Studio 42]

A customer reported me yesterday a similar issue using Sp page builder , so i think that the bug is in Joomla and reordering language plugin should solve this.
Note that you can have other that "system" plugin called, so language filter should be on top of the list of all plugins.

[ptrouw]

I tried the reorder. Unfortunately no difference. As I mentioned in my first post of this tread, after a second refresh the whole page has changed correctly.

[Milbo]

It seems there is a problem with the piwik of alatak

[ptrouw]

For now I fixed the problem with disabling one of the plug-ins.
But what I understood so far, is that changes made in recent VM versions don't work nicely any more with a lot of 3rd party plug-ins. It seems to be discussion if the implementation of the language thing is correct in VM and therefore the problem leis within the 3rd party plug-ins!
As we run 2 major ehops with significant sales and also with quite a few plug-ins this makes our life very difficult. And this makes the process with core updates very very tricky.

[Milbo]

It is unevitable. From my viewpoint the bug is in joomla, or better said, the problem. It is also not a problem, when people write properly. It means always that their plugins were not correctly working already in multilanguage systems. You just notice it now also for single language page.

So when we want to solve the problem, that we can send 2 emails in different language, or just use 2 different languages at the same time, then we need this new system. So always when your user or admin does not use the shop default language, we had a problem before. For example the problem with the overrides was not solveable on another way. So which plugins did you unpublish? Most time it is a simple fix, just by removing quickn dirty stuff.

[ptrouw]

Why didn't I had any problems with 3.0.16 and earlier release? Doesn't that mean is has to do with the newer VM releases.
BTW is was the dropshipment plug-in.

[Studio 42]

The problems is that other 3party as sp page builder, override the Joomla language directly and this is saved in the session in filter language plugin, other simply force a language.
But the other problem is that Joomla language filter plugin is bugged too when you need to full remove the prefix for default language.
I have write a plugin(in beta test for now) to fix this behavior for my language switcher, because it's a problem for some user needing to always remove the /en prefix in sef mode because google site complain about this.
Note that this problem is not in all case and apparently depend the other plugins and some SEF plugin and components adding own rules in sef links.

[Milbo]

No, the problem is the "onAfterInitialise" trigger, which provides the joomla languge set by the session. Because it is fired before the "onAfterRoute" event. But you must route to know which language got selected.

VM used for vmText just the old code of joomla, which gets the language object for any call by the JFactory. We want to use different JLanguage objects in the vmText, so we cannot use anylonger the JFactory::getLanguage. We set now the language, which is also more performant. But when it is not set,... it throws an error. It was not a big deal to avoid this errors. But when the language is set by session to en and it is changed by the route to de,... the language en got already loaded and cached in vm. So we get the wrong language. Therefore the config has now a new parameter, "do not initialise the language".

We gain a lot advantages due this change. Only 3rd party using one of these both triggers notice a difference, the rest works as before.