Feature #17123
closed
No charset conversion for eID scripts, thus no locallang.xml useable
0%
Description
While writing an AJAX FE plugin that needs to be multilanguage, I discovered that the use of locallang.xml files through pi_getLL or any other function that reads language files needs either the FE $GLOBALS['TSFE'] object or the BE $GLOBALS['LANG'] to be available, which is not the case whit eID scripts, and of course shouldn't.
On the other hand it would be nice to use the t3lib_div funtions to read locallang.xml files of the plugin i want to add some ajax functionality to.
So it would be great if you could incorporate a solution for that.
(issue imported from #M5231)
Updated by Thomas Murphy about 17 years ago
Update: It doesn't even work with locallang.php files, because the pi_getLL function relies on it -> so no multilang eID AJAX functionality possible (!) without GLOBAL TSFE object. And this is what we wanted to get rid of in the first place with eID, so it's no option to initialize one...
Updated by Nikolas Hagelstein about 17 years ago
i did a similar thing ...
another way:
/* Fake class LL support */
class csConvObj {
function parse_charset() {
return 'utf-8';
}
function utf8_decode($l,$c) {
return $l;
}
}
$TSFE=new stdClass;
$TSFE->csConvObj=new csConvObj;
$LOCAL_LANG=t3lib_div::readLLfile('EXT:myext/pi8/locallang.xml',$LLkey)
Updated by Dominik Schmich about 17 years ago
Hi Nikolas,
could you add your eid-skript to this bug, so I can take a look at it?
On my local machine, the "Fake class LL support" works but on the remote machine I get this error:
Warning: Problem with method call - please report this bug in... and points to the readLLfile() call
Any ideas?
Updated by Ingo Renner about 17 years ago
eID was invented with the purpose of not having all the usual overhead. Thus it is left to you to initialize the required objects
-- works as intended