[#16287] - Fixes language loading for system plugins in Language Filter plugin
- Fixed in Code Base
- 6 Jun 2017
- Medium
- Build: staging
- # 16287
- Diff
- Kubik-Rubik:staging
User tests: Successful: Unsuccessful:
Encountered a bug in the Language Filter plugin that prevents the loading of the correct language files for system plugins. This bug was reported by a user of my plugin EasyCalcCheck Plus. All system plugins (also core) are affected.
In the beginning of the process the language files from the plugins are loaded properly using \JPlugin::loadLanguage (with correct path: JPATH_ADMINISTRATOR). But once the language is switched in the frontend, all language files are reloaded in the plugin Language Filter ($newLang->load($extension)) but the problem is that the path for the plugins is not set to JPATH_ADMINISTRATOR but the default parameter is used (JPATH_BASE).
Result is:
Since the languages files of plugins are stored in the administrator's language folder, wrong paths are used to find the languages files. You see that the paths are not correct (site language folder) and the result is false (obviously).
This leads to non-translated strings after the language switch. A reload of the page will load the proper translation strings.
The problem is that you cannot reload the correct translations later with \JPlugin::loadLanguage because it checks whether the loading of the language file was already processed.
Additional information: The system plugin has to use the "protected $autoloadLanguage = true" property or load the \JPlugin::loadLanguage function before the Language Filter plugin triggers the language switch.
Summary of Changes
The change is quite simple. If the language file could not be loaded, we try to load the file with the JPATH_ADMINISTRATOR attribute. This will only happen, if the files of plugins have to be loaded. With the correct path the files will be loaded properly and are available directly after the language switch.
Testing Instructions
The easiest way to test it is to create a multilingual website and install my plugin EasyCalcCheck Plus (https://extensions.joomla.org/extensions/extension/access-a-security/site-security/easycalccheck-plus/). Create a menu entry for each language to the registration form of the core user component. Open the page and change the language with the language module.
Expected result
The strings are translated properly directly after the language switch.
Actual result
The language strings are not translated since the Language Filter plugin does not load the correct strings (wrong path to language files of plugins).
Documentation Changes Required
No changes required. No B/C breaks.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Front End Plugins |
| Labels |
Added:
?
|
||
This needs more tests. Let's wait a bit.
@Kubik-Rubik
I think this need a bit more code.
- We should be sure we only deal with system plugins.
- As the language files may only be present in the language folder of the extension, we also have to load them from there.
I propose this code which works here fine.
$newLang = JLanguage::getInstance($lang_code);
foreach ($language->getPaths() as $extension => $files)
{
if (strpos($extension, 'plg_system_') !== false)
{
$extensionName = substr($extension, 11);
$newLang->load($extension, JPATH_ADMINISTRATOR, null, false, true)
|| $newLang->load($extension, JPATH_PLUGINS . '/system/' . $extensionName, null, false, true);
}
else
{
$newLang->load($extension);
}
}
@infograf768 Thank you for your input. Updated my PR!
@Kubik-Rubik
It works fine, but your plugin is not very respectful of API.
You force load using
$this->loadLanguage('plg_system_easycalccheckplus', JPATH_ADMINISTRATOR);
I suggest you use
protected $autoloadLanguage = true; above the __construct method as this would load language if the language folder was copied in the extension (which should be and what I did to make tests here).
Also you have some strings missing:
<option value="0">Red</option>
<option value="1">White</option>
<option value="2">Blackglass</option>
<option value="3">Clean</option>
and
JGLOBAL_FIELDSET_DONATION
JGLOBAL_FIELDSET_PLG_ECC_ANTISPAMSERVICES
JGLOBAL_FIELDSET_PLG_ECC_EXTRA
JGLOBAL_FIELDSET_SETTINGS
which, btw, should not be JGLOBAL ;)
Can you test again?
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/16287.
@infograf768 Thank you for the test and your input!
Regarding my extension: Yes, I have to update it with the autoloadLanguage property.
I set several tabs in the settings, so the strings automatically are converted to JGLOBAL_FIELDSET_X (X => name attribute).
For instance:
<fieldset name="PLG_ECC_EXTRA">
....
</fieldset>
The name attribute is converted to JGLOBAL_FIELDSET_PLG_ECC_EXTRA. So, I can only translate this name if I use it like this in my language files.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/16287.
@infograf768 RTC?
Hi, Can you tell when you are planing to release Joomla with this fix?
Please advise,
Sandra
@infograf768 can you please retest?
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/16287.
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/16287.
rdeutz
- | Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-06-06 18:17:33 |
| Closed_By | ⇒ | rdeutz | |
| Labels |
Added:
?
|
||
I have tested this item✅ successfully on 42cd608
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/16287.