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

[JoH asenau]

> time to debug ;)
>
> I will look into if i find some time in between.

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.

What do you think?

Joey

-- 
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