In custom extension en-GB
file is located in language folder under extension folder like /components/com_component/language
. Localisation languages are located the following way:
ru-RU
file under /components/com_component/language
fr-FR
file under /language
Imagine that we have language string COM_COMPONENT_TITLE_CONTROL_PANEL="Component: Control Panel"
in en-GB
file and translations in ru-RU
and fr-FR
files.
Now if we remove this string from ru-RU
file we have a fallback to en-GB
and it is displayed as Component: Control Panel
.
If we remove this string from fr-FR
file then we do not have a fallback and it is displayed as COM_COMPONENT_TITLE_CONTROL_PANEL
.
Is it expected behavior and custom extensions should always distribute en-GB
in JPATH_SITE(ADMIN)/language
folder? Or it is a bug and should be fixed?
Do I understand well the matter by saying that you get the en-GB fallback when ru-RU is loaded but not when fr-FR is loaded (both files being present + the en-GB one ONLY in the extension language
folder)?
Or that fr-FR is only present in the core language
folders?
Status | New | ⇒ | Information Required |
I have tested here and I confirm the issue.
If the fr-FR ini file is placed in core language folders and one string is missing, then the en-GB file from the extension language folder is not loaded. Both have to be OR in the core language folder or in the extension language folder.
Something has changed in core as this was working before
@nikosdion
Could you have a look? That is an important bug.
Title |
|
Title |
|
Title |
|
Code used for lang fallback is here if I remember well:
https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Joomla/CMS/Language/Language.php#L719-L724
I am not sure why you pinged me? All I have ever pointed out is that you can and should load both the translation and the en-GB file :D Anyway, I can help you navigate this issue.
Per the code I'm reading in the Language package the fallback is being detected in the same $basePath. In other words, if your $basePath is /components/com_component/language then Joomla! correctly shows an untranslated string if the en-GB file is not there. So, it boils down to how your component tells Joomla! to load language files, i.e. which $basePath to use.
That seems to come from Joomla\CMS\Component\ComponentHelper circa line 361. As we can see, Joomla! tries to load the language from the system-wide directory. If that fails (and only if it fails), it tries to load from the component directory.
The problem with this approach is that if you load the local language from the system wide directory BUT your default (en-GB) file exists only in the component directory then your en-GB file will never be loaded because of Boolean short circuit evaluation. Your en-GB file should always be in the system-wide directory for Joomla! to pick it up.
There's another caveat: loading the default language only takes place when Debug Language is set to No. If it's set to Yes then Joomla! will not load the default language. So if you have Debug Language set to Yes because you're debugging language issues, well, of course you'll see untranslated strings. This is what it's supposed to do.
I am not sure which of the two cases above is what happened to you, but I assume it's the first because it's not immediately evident. However, as far as I am aware this has always been the case of how Joomla! worked. Disclaimer: I always put my en-GB and localised files in the system-wide directories so I can't provide first hand experience. Sorry :(
If you want to force load all language files from both the system wide and the component directory you can change the ComponentHelper line I pointed out with two separate lines:
$lang->load($option, JPATH_BASE, null, false, true);
$lang->load($option, JPATH_COMPONENT, null, false, true);
The downsides are:
The component-specific language files override the system-wide files (which is probably the intended effect but you MUST document it)
The system ones have to override the component one (which is current behaviour). Eg a language pack has to override the files shipped with an extension.
So the lines would have to be the other way around and it would work I guess.
The problem with this approach is that if you load the local language from the system wide directory BUT your default (en-GB) file exists only in the component directory then your en-GB file will never be loaded because of Boolean short circuit evaluation. Your en-GB file should always be in the system-wide directory for Joomla! to pick it up.
@nikosdion thank you for explanation. Now it is clear and seems that it is not a bug.
I didn't know what was the intended behavior since none is documented anywhere I could look. If we want the system to override extension translations then, yes, the order of lines should be;
$lang->load($option, JPATH_COMPONENT, null, false, true);
$lang->load($option, JPATH_BASE, null, false, true);
Would you like me to make a quick PR for this?
If you have time to spare, please yes.
Status | Information Required | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-07-31 18:16:50 |
Closed_By | ⇒ | zero-24 |
Closing here than. Thanks.
As far as I know there should always be a en-GB file. At least I ship for every of my extension such one.