[TYPO3-dev] Bug: tslib_pibase::pi_getLL doesn't recognize translation state of pages and/or records

[JoH asenau]

>> The only reliable source for the language currently used on a page is
>> $GLOBALS['TSFE']->sys_language_uid, which is why we discovered the
>> bug, since parts of the plugin were translated by our own functions
>> using sys_language_uid, while the rest used pi_getLL
>
> it seems to be different. All settings are done in
> $TSFE->settingLanguage();
>
> and if you look into the reliable part should be
> $TSFE->sys_language_content
>
> sys_language_uid always hold the var set in config (from my quick
> view)

Exatcly this was NOT the case while we discovered the bug.
The TypoScript was set via condition based on the L parameter.
Both, sys_language_uid AND language were changed there according to the
desired behaviour.

Result:
Without a translated page available, $GLOBALS['TSFE']->sys_language_uid was
ALWAYS 0 regardless of the L parameter, while language changed regardless of
the sys_language_uid used by the rest of the page.

pi_getLL uses $this->LLkey which is set in function tslib_pibase based on
$GLOBALS['TSFE']->config['config']['language']
or
$GLOBALS['TSFE']->config['config']['language_alt']
only, without checking the current sys_language_uid

IMHO this should at least be connected to the fallback mechanism to have
them behave the same way.

Joey

BTW: This is a good example, why having a sys_language_uid instead of
ISO-codes is a bad idea at all ...

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your gob sometimes!)
Dieter Nuhr, German comedian
Xing: http://contact.cybercraft.de
Twitter: http://twitter.com/bunnyfield
TYPO3 cookbook (2nd edition): http://www.typo3experts.com