Hi,
I am using lingua in an environment with multiple contexts and different sets of languages. Most of them have English as one of the languages, but initially the pages should be dislayed in the default language, ie fr, de, ko etc., as it is set by the contexts cultureKey.
Unfortunately when setting a different cultureKey in context settings, lingua.cultureKey keeps pulling the value from the main settings, eg [[++cultureKey]] gives the proper key ‘de’ as set in context settings, while [[+lingua.cultureKey]] shows ‘en’ as set in system settings.
After some digging around I noticed that if you leave the cultureKey in system settings blank, the frontend will display correctly based upon the context cultureKey. Unfortunately then the manager won’t show the dropdown option to switch between languages, no matter what cultureKey setting in the context.
Looking at the plugin I wonder if that issue had been tried to be solved before, as some lines seem to be experimenting with this?
I was thinking of workarounds like initially placing an ‘edited’ version of the cookie that lingua sets, or some sort of tv that would influence the default lingua value, but none of this has worked out.
Any suggestions would be greatly appreciated … Alternatively I would need to get rid of this extra and build something myself with loads of tv’s (migxmultilang doesn’t seem very userfriendly), but if lingua worked it would be such a cleaner solution?!
Have you tried setting manager_language and/or locale as a Context Settings?
Hi Bob,
thanks for taking time to look at this. I tried adding the two settings you suggested just now, but they don’t make any difference. There is this code in the plugin
$modx->context->config['cultureKey'] = $lingua->getCultureKey();
if ($modx->cultureKey !== $modx->getOption('cultureKey')) {
$modx->setOption('cultureKey', $modx->cultureKey);
$modx->context->config['cultureKey'] = $modx->cultureKey;
}
$modx->setPlaceholder('lingua.cultureKey', $modx->cultureKey);
$modx->setPlaceholder('lingua.language', $modx->cultureKey);
which seems to address the issue, but I haven’t been able to figure out what goes wrong where.
I’d be curious to see the code of that method.
You might comment out that whole block of code and add this code below it:
$ck = $modx->getOption('cultureKey');
$modx->setPlaceholder('lingua.cultureKey', $ck);
$modx->setPlaceholder('lingua.language', $ck);
Thanks, Bob!
I have been trying to debug all similar versions of this code I could think of by putting them in a test snippet that I then called on the same page where lingua runs, and they all return the correct value, ie the context cultureKey.
Yet if inserted in the plugin it doesn’t work. Same with your code: If executed from a single snippet it works fine, but within the lingua extra it doesn’t. Which had me thinking there must be another function somewhere in the extra’s files, but I couldn’t find it.
Maybe the issue is in the JS code?
Do you use an Extra like ‘ContextRouter’?
‘ContextRouter’ switches the context on the Event ‘OnMODXInit’ which is called after the Event ‘OnInitCulture’ that Lingua uses. So all the Lingua-Code is executed before modx is switched to the right context.
When you put the following line in the Lingua-Plugin and then check the error log, does it log the right context?
$modx->log(modX::LOG_LEVEL_ERROR,'Lingua->OnInitCulture->Context-Key: ' . $modx->context->key);
Hi
Thanks for pointing me in the right direction: It is in fact not the cultureKey of the system setting, but the one of the default backend context. If I add a cultureKey setting here (that differs from the system one), lingua pulls that modified cultureKey even when called in another context.
I inserted your line into the plugin, this is what I got:
[2020-06-08 15:07:27] (ERROR @ /XXX/core/cache/includes/elements/modplugin/16.include.cache.php : 623) Lingua->OnInitCulture->Context-Key: web
[2020-06-08 15:07:27] (ERROR @ /XXX/core/cache/includes/elements/modplugin/16.include.cache.php : 623) Lingua->OnInitCulture->Context-Key: jobsAsia
[2020-06-08 15:07:32] (ERROR @ /XXX/core/cache/includes/elements/modplugin/16.include.cache.php : 623) Lingua->OnInitCulture->Context-Key: mgr
I am not sure I get this right, would this mean the plugin code is executed multiple times?
I am using Gateway Manager for routing the domains, which is only called on OnHandleRequest, as well as is Lingua. Changing the priority here doesn’t make a difference. I have tried XRouting as well as ContextRouter right now, but they won’t change an thing either.
Edit: I have just switched to ContextRouter again instead of Gateway Manager, but it doesn’t have the event OnModxInit but instead OnHandleRequest (as does Lingua). Changing the priority here between Lingua and ContextRouter doesn’t make any difference.
The Lingua-Plugin reacts to multiple events but in case of OnHandleRequest it breaks immediately.
switch ($event) {
case 'OnHandleRequest': // for global
break;
case 'OnInitCulture': // for request class
if ($modx->context->key === 'mgr') {
return;
}
The relevant code is executed OnInitCulture.
Where did you insert the $modx->log(modX::LOG_LEVEL_ERROR,... line in the plugin-code? If you insert it right after the code snippet shown above, do you get any other context-key than web in the log-file?
Ohmy, I have inserted it right after the code as you said, and the whole site broke down just now. Had to do a DB and file restore from this morning, I think that was enough adrenalin for today.
Anyhow, in the previous version I had inserted te code at the end of the plugin, and always got two error lines every time I called one of the pages as seen in the log above, default context web and second context jobsAsia.
The first entry must have been from the OnInitCulture event where the code got executed but the context was wrong. The second entry from the OnHandleRequest event where the context was correct but no code was executed.
To solve your problem you can try this:
- In the Plugin move the code from
case 'OnInitCulture': to case 'OnHandleRequest':
- Make sure that the priority of the Lingua-Plugin is higher than the priority of the ‘Gateway Manager’ Plugin.
- Append the code with a new
else-clause and a call to $lingua->setCultureKey.
} else if(empty($langGetKeyValue) && empty($langCookieValue)){
$detectBrowser = $modx->getOption('lingua.detect_browser');
if ($detectBrowser === '1') {
//nothing changes here
...
} else { //add this new else-clause
//add this new line
$lingua->setCultureKey($modx->context->getOption('cultureKey'));
}
}
Thank you, halftrainedharry! It did something, but not everything … It did change the cultureKey correctly to the current context one, so when I call it with [[!+lingua.cultureKey]] it displays en, de, ko etc.
BUT: It doesn’t change the default language version of the frontend that is displayed when you visit the site forthe first time (or re-visit without the preference cookie set).
Neither does it have an effect in the manager, where the default/first language is still the one set in the system settings, not the one in the context.
Also when I re-enter your code form above into the plugin and change this
$modx->log(modX::LOG_LEVEL_ERROR,'Lingua->OnInitCulture->Context-Key: ’ . $modx->context->key);
to
$modx->log(modX::LOG_LEVEL_ERROR,'Lingua->OnHandleRequest->Context-Key: ’ . $modx->context->key);
I get this in the error log:
[2020-06-08 19:49:15] (ERROR @ /XXX/core/cache/includes/elements/modplugin/16.include.cache.php : 631) Lingua->OnInitCulture->Context-Key: web
[2020-06-08 19:49:15] (ERROR @ /XXX/core/cache/includes/elements/modplugin/16.include.cache.php : 631) Lingua->OnInitCulture->Context-Key: jobs-de
[2020-06-08 19:49:22] (ERROR @ /XXX/core/cache/includes/elements/modplugin/16.include.cache.php : 631) Lingua->OnInitCulture->Context-Key: mgr
and if I uncheck the OnInitCulture event in the plugin setting I get
[2020-06-08 19:53:31] (ERROR @ /XXX/core/cache/includes/elements/modplugin/16.include.cache.php : 631) Lingua->OnHandleRequest->Context-Key: mgr
[2020-06-08 19:53:38] (ERROR @ /XXX/core/cache/includes/elements/modplugin/16.include.cache.php : 631) Lingua->OnHandleRequest->Context-Key: web
I am getting the feeling solving this issue would become a too long task …
I agree. Especially if you start to change stuff in the manager it’s getting really messy…