Page tag: 10571080108910901077108410721088107710811090108010851075108610741080107210851090108010891087107210841072.

The page language was set to 'en' and Wacko took the &#1057&#1080&#1089&#1090&#1077... htmlspecialchars was used after do_unicode_entities, the forum is not well tested and probably your browser local was set to 'en'. This is one of the big unsolved issues, at least as long as UTF-8 is not implemented, we can offer the user an additional form field where he can change the page language for the new page if the page language differs from the one chosen in the user settings. I changed the page language to 'ru' via /properties.

PHP still sucks abysmally at Unicode. Now we have a small unicode branch/fork based on PHP 5.3 and mb_string but a future PHP version(?) may come with native UTF-8 support and rewriting the Wacko default branch for mb_string makes no sense in the long run, so I did not come to a final conclusion.

The development of PHP 6 has been delayed because the developers have decided the current approach to handling of instance unicode is not a good one, and are considering alternate ways in the next version of PHP.

the workaround e.g.

if ($this->page['lang'] != $topic['lang'])
	$topic['title'] = $this->do_unicode_entities($topic['title'], $topic['lang']);

The chosen user language (account) must be equal with the posted text charset to avoid the situation as described above.
lang/lang.xy.php -> charset