Bug #16177
closedwrong charset in spell checker pop-up
0%
Description
i noticed that the spell checker-ui doesn´t care about the charset typo3 is running at. the text-frame in the spell checker pop-up always outputs ISO-8859-15, even if the backend runs at utf-8. as a result, i.e. german umlauts are broken and the spell checks does not work properly.
quick and dirty hack to fix this:
open the file htmlarea/plugins/SpellChecker/spell-check-logic.php and put the following line
header('Content-type: text/html; charset='.$TYPO3_CONF_VARS["BE"]["forceCharset"]);
before the spell checker gets initiated.
detected in plugin version 1.3.7 on typo3 4.0
(issue imported from #M3546)
Files
Updated by Martin Kutschker over 18 years ago
The solution is wrong as forceCharset may not be set at all. use $GLOBALS['LANG']->charset.
Updated by Stanislas Rolland over 18 years ago
The spell cheker will work in either iso-8859-1 or utf-8 because it uses the php xml parser and these are the only character sets supported by this set of php functions (besides useless US_ASCII).
If the content is not in one of these two character sets, I think it will convert it to utf-8 and do the spelling in that character set, and convert it back on return... if I remember well.
But if the backend uses forceCharset = utf-8, then everything will be done in this charset.
If your version of Aspell is not 0.60+, utf-8 may not be well supported. Versions older than 0.60 are not supported by htmlArea RTE. See the requirements section of the manual.
Updated by Niels Vornholt over 18 years ago
so,
you mean when i upgrade to aspell 0.60+, the spell checker result window will be outputted with charset=utf-8 in the http-header?
the spell checking process itself works fine, i just wondered why the result popup gets delivered in ISO while the whole BE is outputted in UTF-8! that made no sense to me...
when i forced the output of the result window to be interpreted as UTF-8 via the php-header function, everything was ok. so the return of aspell must be well usable UTF-8, only the browser doesn´t know that it IS UTF-8... ;)
i can´t imagine that my problem here has something to to with the version og aspell...
do you need more information about the test system? perhaps i misconfigured something?
Updated by Stanislas Rolland over 18 years ago
I checked this again, just to make sure. I don't see how you could put the headers you describe in file htmlarea/plugins/SpellChecker/spell-check-logic.php.
The page loaded in the iframe is outputed by pi1/class.tx_rtehtmlarea_pi1.php. If you check the source code, you will see that the charset on the headers of this page is variable.
I checked on a site with utf-8 backend, and so is the window. I checked on a site using an iso-8859-1 backend, and so is the spell checker window.
Both sites can spellcheck French and Spanish without any problem.
Is php compiled with mbstring and mb_regex?
You seem to think that a spell checker should not care about charsets?... Please confirm that the problem occurs with Aspell 0.60+.
Updated by Sven Grützmann almost 18 years ago
I' ve got the same problem with german umlauts and special characters in the spellchecker popup. The special character "ß" ist always replaced with "??" and words with an umlaut at first position like "Überblick Schüler Mühe Ärger Änderung Öffnungszeiten" are not recognizes by the spellchecker (underlined red from second character till wordend). Words like "Führerschein Mühe Gründung Küche Tür" are ok.
My config:
Server: apsell 0.60.3 with aspell-de 0.50.2
PHP: 5.1.2, mbstring, pcre-regex
MySQL-database ist utf-8
TYPO3:
config.metaCharset = utf-8, config.renderCharset = utf-8
$TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
$TYPO3_CONF_VARS['SYS']['t3lib_cs_convMethod'] = 'iconv';
$TYPO3_CONF_VARS['SYS']['t3lib_cs_utils'] = 'iconv';
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;
Updated by Daniel Krupke over 16 years ago
I had similar problems with spell checker using the UTF-8 charset for Typo3. When I added this lines in my php.ini, the spell checker turned into working fine:
[iconv]
iconv.input_encoding = UTF-8
iconv.internal_encoding = UTF-8
iconv.output_encoding = UTF-8
[mbstring]
mbstring.internal_encoding = UTF-8
mbstring.encoding_translation = On
mbstring.http_input = auto
mbstring.http_output = UTF-8
mbstring.detect_order = auto
mbstring.substitute_character = none;
Maybe this fixes the bug for you, too.
Updated by Stanislas Rolland about 16 years ago
A long time ago, I do not know nor remember why, a line in script pi1/class.tx_rtehtmlarea_pi1.php was commented out:
$regex_encoding = mb_regex_encoding(strtoupper($this->parserCharset));
Turns out that the line may be essential when the backend is utf-8 encoded, depending on the default settings of the PHP mbstring extension. This is because the script changes the mbstring internal enoding to utf-8, but that does NOT change the internal encoding used by mb_regex.
So I think the attached patch should solve this issue in TYPO3 4.0 to 4.2.
In TYPO3 4.3 the requirement for mbstring will be removed.
Updated by Stanislas Rolland about 16 years ago
Attaching patches for TYPO3 4.1 and TYPO3 4.2
Updated by Stanislas Rolland about 16 years ago
Committed to SVN TYPO3core branch TYPO3_4-1 (revision 4084) and branch TYPO3_4-2 (revision 4085).