unusable with non-ASCII characters.

This is reproduceable on a Apache2 server with

* PHP Version 5.2.6
* MySql Server Version: 5.0.67

I don't know how often we, the clients, have urged WA to check for inconsistencies in their UTF-8 product - implementations. Because if this is not done correctly, all non US-ASCII characters are diplayed incorrectly or replaced by � characters, estimada Se�ora.
óíáñéúü¿ show up as ��������. Very funny.
Quel Hors d’�uvre. How come, wikipedia, vBulletin and countless others can display this correctly as Hors d’œuvre and Site Sculptor, PowerGallery ... can't?

All pages in Sitesculptor have correct UTF-8 settings:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

But in the moment we need content management, a key feature of Site Sculptor, chaos reigns. No idea how this could pass any quality control at web assist after so many months of claiming?

Database creation in Site Sculptor uses latin-1 collition! How can this work when each page is UTF-8 encoded?

It does not. It is the same with PowerGallery and maybe many other WA products which need foreign characters to be stored and retrieved in a mysql database.

Mysql and php even handles Chinese kanji character sets correctly if setup with UTF-8.
Kanji.

Sorry for putting all my frustration about this but its been simply too long that this was known and nothing was changed.