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

JoH asenau info at cybercraft.de
Tue Apr 20 16:22:48 CEST 2010


>> JoH asenau wrote:
>>> What do you think?
>>
>> Check if your suggestion is inline with the "Frontend Localization
>> manual" on typo3.org. That document defines how exactly localization
>> should work.
>
> some weeks ago i tried all possible combinations to check what really
> happens and i also got the feeling that it doesn't work the way as
> described in this document. Ok, i checked with TV and the DS settings
> which makes it even more complex.
>
> I agree that it should behave the way it's described in this manual
> (except the TV part is really ununderstandable even after 10 readings
> :) )

Well - the manual 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.

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






More information about the TYPO3-dev mailing list