TYPO3 Core

Steps to reproduce (TCEforms):

1) Set forceCharSet = utf-8.
2) Login to the backend, create a usergroup called "ÄÄÄ" (or any other non-ascii-char)
3) Create a user and add the group to the user (clicking on the right box). Upon adding, the group-name is add correctly to the left box.
4) Save the form and look at the result. Instead of "ÄÄÄ" you have a 6 bytes-string

Other place where it occurs (flexforms):

1) Set forceCharSet = utf-8.
2) Add tt_news extension
3) Create a News Category called "ÖÖÖ"
4) Add a News-Plugin as a content element, and tell it to display only elements in the category "ÖÖÖ".
5) Save and look at the displayed value in the left category box, its garbled again.

The attached minor patch (to latest 4.0-CVS) seems to solve it. But I think more thinking has to be done here.

The only change the patch does is that LANG->sL() won't try to convert from the encoding specified for the current users language (e.g. iso-latin-1) to UTF-8. In the case of values coming from the DB, they are already UTF-8, so this would cause double-encoding.

There might be side-effects, because sL() is also used for the "language-splitted" labels, but they are obsolete anyway. And I cannot imagine any latin-1 encoded string to enter this part of the function if the site is set to forceCharSet=utf8.

Non-forceCharSet-sites aren't affected by this change, because hscAndCharConv won't don anything other than htmlspecialchars, which I still do in my change.

Initially reported for TYPO3 4.0
(issue imported from #M2396)