Run an update and let me know if that fixes the problem for you.
Whoops. Missed the last two posts.
Banal, I don't think we need to worry about users who already use UTF-8 because Silverstripe throws an HTTP header for the UTF-8 charset on all responses, right?
Sadly not, if you run an UTF-8 encoded string through utf8_encode, you'll end up with garbled umlauts. And that's exactly what will happen if you use a UTF-8 locale and run the strftime output through utf8_encode. I suggest you revert back to the previous version and tell the users to use the setlocale fix, where the user has to switch to an UTF-8 locale.
I had the same problem in german, that MÃ¤rz was written with ? instead of Ã¤.
I activated the following line in event_calendar/code/CalendarUtil.php (line: 85):
// Need to figure out how we're handling non- UTF-8 users.
return utf8_encode(strftime($char, $ts));
With the return strftime($char,$ts); it didn't bring back the right value, it was ISO-8859-1 encoded and the website showed, to whatever encoding changed in the browser, mixed content with Ã¤ and ?.
Now I can run the whole site under UTF-8. Cool
is guess, this is still an unsolved problem. On my PC (de_DE.utf8) only
works. On my server (de_DE) only
I attached a patch for CalendarUtil.php at revision 89 to this post, that solves this Problem. It is based on http://www.php.net/manual/en/function.utf8-encode.php#89789.
Wow.. this is excellent. Huge thanks, Beutlin.
You're welcome. But one more comment: the patch expects, that the target's character set is UTF-8, which is - I suppose - default in Silverstripe. But maybe you can test this using:
$string = strftime($char, $ts); if (ContentNegotiator::get_encoding() == 'utf-8' && !mb_check_encoding($string, 'utf-8')) return utf8_encode($string); else return $string;