Hi!

I'm testing the latest build of event_calendar module. I'm getting crazy with an encoding problem: my pages are all in French and, sure enough, words containing special chars as août (August) are being correctly displayed. I can use $LastEdited.Format18N(%d %B %Y) and get nice août in my recent pages… save some items of the Calendar page. There, the date in events and in the filter widget show the infamous � char in place of û. On the other hand, event content is correctly shown. Also, the month in the calendar widget is not translated.

I've tried saving all module's files in UTF8 without BOM without success. I've seen in the forum that German folks use the module without problems, somebody could help?

Thanks in advance,
Juan

(bump) Am I the only one having this problem? ;(

I have been playing around with this for several hours and I can't figure it out. I have my locale set to fr_FR, and indeed, I'm getting the black question marks. I'm also getting them when I use the $LastEdited.FormatI18N function. If I change the default character encoding in my browser to Western, it appears correctly, but I'm not sure why UTF-8 is not working. It's not a database issue because even when I force a return value of:

return strftime('%b',strtotime("2009-08-08"));

I still get the question mark.

Anyone got any ideas? Banal?

Hi UncleCheese! 'm feeling less alone now…

I don't know if it could help, but here's a little story: The last time I had a problem with encodings was with the Blog module. This module includes an Archive Widget with a Dates() function which allows for classifying blog entries by month and year. I was getting the � char in French months when I used FormatI18N in the ArchiveWidget.ss included template, the only solution I found was changing in ArchiveWidget.php this two lines of the Date() function:

$results->push(new ArrayData(array(
	'Date' => $date,
	'Link' => $link
)));

To:

$results->push(new ArrayData(array(
	'Month' => htmlentities($date->FormatI18N('%B')),
	'Year' => $date->Year(),
	'Link' => $link
)));

(Note the htmlentities() function).

Why FormatI18N works here and not in the template and why encoding entities is necessary is beyond my comprehension of SilverStripe and PHP in general.

Hope it helps.

Best regards,
Juan

My guess would be, that the PHP Date function return ISO-8859-1 encoded strings. A lot of the core PHP functions do not return multibyte character strings (or UTF-8 for that matter). One solution would be to wrap the return value in a utf8_encode statement. Something like this:

return utf8_encode(strftime('%b',strtotime("2009-08-08")));

Update It may also have something to do with the system locale. AFAIK there are locales with different encoding available. If you have a system that doesn't use a utf-8 locale, the strftime function won't return a utf-8 encoded string! That's probably why this error hasn't shown up earlier...

Works. Knew you'd have the answer, Banal. Thanks.

I'm going to check in a bunch of changes to the module that wrap all the strftime functions with utf8_encode. I'll post when ready for testing.

Noo! Don't do that UncleCheese. You would break the event-calendar module for all the users that actually use a UTF-8 locale setting (that's probably the majority).
I don't think there's an easy fix for this, as there will always be systems that use different locales... some of them might use UTF-8 encoding, some not.

You could try to detect the encoding, then wrap it in utf8_encode if necessary: http://php.net/manual/en/function.mb-detect-encoding.php
But that's ugly and will reduce performance.

I think you should tell the users, that they should set an appropriate utf-8 locale in their _config.php (http://php.net/manual/en/function.setlocale.php). Or you build your own date formatter and use translations for month and days from the translation files (where you can safely assume that they are all utf-8 encoded).

Edit spelling/wording

Update If I find some time, I'll have a look at the locale implementation of the zend framework (http://framework.zend.com/manual/en/zend.locale.date.datesandtimes.html). I'm pretty sure they dumped the system-locale based php functions in favor of more portable code.

Thanks for your efforts. You're great! Have you realized how generous is to spend all this time helping us?

Well… You're not going to believe me, but when I read what Banal was saying about encoding in UTF-8, I changed this line in my _config.php:

setlocale(LC_ALL, 'fr_FR', 'fr-FR', 'fr_FR.UTF8', 'french');

To:

setlocale(LC_ALL, 'fr_FR.UTF8', 'fr_FR', 'fr-FR', 'french');

And it works! This is one of the most crazy fixes I've never applied. Don't you think I should write a line on the multilingual wiki page about this?

Thanks again,
Juan