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

[maxsite]

Using WordPress 2.0.* - 2.1RC2 in non-UTF8 encoding (for example WINDOWS-1251), there is a mistake.

1 example.

When you create a post ( "Write post"), you can add new category (block located right). In non-english category added an error-in the "Manage-Categories" this can be seen clearly. (example : "тестовая" -> "тестовая")

2 case (in WordPress 2.1RC2)

If the "Dashboard" to change the name of the RSS non-english (example : "WordPress Development Blog-> Блог разработчиков WordPress"), then there is error-"???? ???????? WordPress"

MAX

Russian WordPress:  http://maxsite.org/

I using Google-translate

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.

And the issue #2 is tracked in #8572 together with more tickets that touch the AJAX encoding since the categories are added via AJAX request in the admin. (As such, I'm closing this as a dupe, trying to consolidate all the bugs into one meta-ticket. Feel free to reopen this if you feel it doesn't fall into the bucket with the other bugs there or if the future fix of said issue doesn't help to eliminate this problem from trunk.)