Bug #22490
closed
tslib_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)
Updated by Jo Hasenau almost 14 years ago
The bad guy can be found between lines 2303 and 2335 of class.tslib_fe.php
No pageOverlay is found and therefor a switch is used to choose from
sys_language_mode
*strict: Shows an Error Message
doesn't matter in this case - no content gets shown
*content_fallback: Uses another language for the content, when available
doesn't matter either and will show a maximum of 2 different languages at
once, while leaving sys_language_uid as is
The latter makes sure that pi_getLL and other stuff like i.e. HMENU will
work with the same language, because sys_language_uid and config.language
are triggered by the same TypoScript condition. Content elements in other
languages than config.language will be seen on purpose, because this is the
desired behaviour set by the admin.
*ignore: Leaves sys_language_uid as is
doesn't matter in this case - see above
*default: Sets both, sys_language_uid and sys_language_content, to 0
It seems default is the bad guy here, since page and content will be set to
ID 0 while, the rest of the system will still work with the language set in
config.language regardless of the TypoScript condition.
Since default is the only case, that will cause unwanted behaviour, I guess
it will be enough to check for sys_language_uid or sys_language_content
being > 0 and sys_language_mode being false in any place that is currently
using config.language only.
Updated by Jo Hasenau almost 14 years ago
Well - the FE localization guide clearly states, that
"any TypoScript conditions (for example [globalVar = GP:L=1]) are still
effective so any settings there are kept regardless of the localization
mode"
So at a first glance, the behaviour with &L=1 without having a translated
page at hand seems to be correct, because the TypoScript we used contains
(adapted to the languages used in the manual)
config.sys_language_uid = 0
config.language = en
[globalVar = GP:L=1]
config.sys_language_uid = 1
config.language = dk
[global]
But at a second glance the behvaiour does not match the listed "Result",
which says (adapted to our case):
Content => English
Menu => English
A plugin IS a content element and in this case it is using danish labels,
because it is triggered by the TS condition only, which generates
config.language = dk
So IMHO the manual is misleading and the behaviour unwanted.
Updated by Alexander Opitz over 10 years ago
- Category deleted (
Communication) - Status changed from New to Needs Feedback
- Target version deleted (
0) - Is Regression set to No
Hi,
as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (4.5 or 6.1)?
Updated by Alexander Opitz about 10 years ago
- Status changed from Needs Feedback to Closed
No feedback within the last 90 days => closing this ticket.
If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.
Updated by Jigal van Hemert about 10 years ago
- Status changed from Closed to New
Updated by Mathias Schreiber about 9 years ago
- Target version set to 7.2 (Frontend)
Updated by Benni Mack almost 9 years ago
- Target version changed from 7.2 (Frontend) to 7.4 (Backend)
Updated by Susanne Moog over 8 years ago
- Target version changed from 7.4 (Backend) to 7.5
Updated by Susanne Moog over 6 years ago
- Category set to Localization
- Sprint Focus set to PRC
Updated by Benni Mack over 5 years ago
- Status changed from New to Closed
hi everybody,
we've fixed this config options of TypoScript now in v9 with site handling and Context API!
So, the localization guide could need some love - feel free to open an issue there now.
All the best,
Benni.
Updated by Benni Mack about 4 years ago
- Sprint Focus changed from PRC to Needs Decision