Error in non-UTF8 encoding (for example WINDOWS-1251)

It is a commong problem with browsers nowadays. Sometimes browsers always encode url's in UTF-8 and sometimes they use the current system encoding.

If you are using Firefox you could try changing the values of the following two config variables: network.standard-url.encode-utf8 and network.standard-url.escape-utf8 (navigate to about:config in firefox and type the name in the filter field).

Unfortunately, this does not help. The problem, as I understand it is AJAX. Data transferred AJAX to convert the encoding blog UTF8. Then again transferred to encode blog.

Yeap, AJAX is the problem. It seems that different encodings just couldn't easily live in that cruel AJAX world ;)

I am from Bulgaria (another windows-1251 country) and recently also had the same problem with an application of mine. The solution was to decode the incoming data - if it was valid UTF-8 to cp1251. However I do not think in WordPress there is place for such dirty hacks :-)

Maybe migration to UTF-8 will be the best choice you can go for.

Thanks :). Transition to UTF-8 excellent decision, but the majority of Russian-speaking hosts working with MySQL 4.0.*, where UTF-8 works with the mistake. :-(

Perhaps developers want to transform data to work with the Ajax encoding other than encoding.

By the way I way I was wrong to some extent :-) When testing the latest Bulgarian version in Konqueror I came across a similira to your situation in the Dashboard and it turned out that the file, which delivers the news, index-extra.php, does not specify encoding, so the encoding mangles. My locale on the system is UTF-8 and thus it looks like that Firefox assumes UTF-8 for all files and that is why I haven't experienced the problem before.

Unfortunately there isn't such a problem with the encoding of the AJAX responser for the category addition feature :(

Yeap, you are absolutely right that in MySQL UTF-8 works too much out-of-the-box. It is more like a bug (aka accidental feature), than a feature :)

About the conversion - another deficiency of the conversion approach is the dependancy of a conversion library (e.g. iconv). Anyway - I guess it could be a nice plugin.

I am adding a patch for the Dashboar part part of the bug.

Let's use #3754 to track issue #2.

Issue #2 fixed.