Bug #22490
closedtslib_pibase::pi_getLL doesn't recognize translation state of pages and/or records
0%
Description
While showing a pibase-based plugin on multilanguage sites, the labels will always be translated based on config.language settings only. This is done regardless of the translation state of the page and/or the record using the plugin.
Happens not just with 4.4. but with earlier versions as well, since this seems to have been the official behaviour for ages.
To see what happens, simply create a new page in a multilingual environment using the usual language switch with conditions like that:
config.sys_language_uid = 0
config.language = en
[globalVar = GP:L = 1]
config.sys_language_uid = 1
config.language = de
[global]
Don't create a translation of the page yet and insert any plugin that is based on pibase and i.e. uses the built in page browser or any other kind of localized labels.
Now check the FE of that page with &L=1
Since you haven't got any translation available, the page usually will show the fallback version, which is: Default language (depends on your settings though) - if it is not showing at all, you won't face the problem in this scneario, but it still will be there.
If you cansee the fallback version, the content of that page, the menus and all other stuff will not be translated at all - but surprisingly the labels of the plugin will!
This is due to the fact that pi_getLL is based on config.language only.
Conclusion: There might be two options to solve this.
1) Have pi_getLL check the sys_language_uid as well and make it behave accordingly
2) Have fallback mode take care of the correct config.language settings instead of setting sys_language_uid only
Anything I forgot?
(issue imported from #M14159)