[TYPO3-core] RFC: Bug #4183: Incorrect display in htmlArea RTE of utf-8 labels defined in PageTSConfig

[Martin Kutschker]

Stanislas Rolland schrieb:
> Hi,
> 
> This is an SVN patch request.
> 
> Type: Bugfix
> 
> Problem:
> When the backend is forced to utf-8, labels or names (for classes, 
> colors or fonts) directly entered in PageTSConfig are entered as utf-8.
> 
> PageTSConfig may be set through some php script. Perhaps, if 
> PageTSConfig is set from a php script, the values should be specified 
> through some language file (LLL:EXT:file or LLL:file).
> 
> If the values are entered directly in PageTSConfig and processed through 
> $LANG->sL, $LANG->sL will apply a charset conversion if 
> $LANG->origCharset is not utf-8. For many languages, $LANG->origCharset 
> is NOT utf-8.
> 
> Solution:
> Do not use $LANG->sL when the label is defined by a simple string rather 
> than by reference to a locallang file.
> 
> Comments:
> I tested the attached patch in a utf-8 backend (I think whatever the 
> backend charset, the problem could arise if it is not the same as the 
> 'original' charset). Would appreciate feedback on the approach.

I think the fix is ok. The whole orig charset thingy is a bit tricky 
(forceCharset is easy, multi-charset is hell!), but it is safe to assume 
that any literal is in the charset of the installation.

Maybe you can go even farther and move the check to sL() itself. That is 
only do charset processing for external files. It's nearly impossible 
(you'd have to switch BE language and revisit the record for each charset) 
to write a multi lang string (with |) in various charsets, but Kasper will 
perhaps be able to answer that one.

But this one should really be tested very good in all kind of setups (with 
and without forceCharset, etc).

Masi

PS: Ideally any strings from resource files are returned in the current 
charset, not in the default charset of the language (aka origCharset).