29 August 2009 at 3:09am
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?
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:
8 September 2009 at 9:42am
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:
8 September 2009 at 10:02am
(Last edited: 8 September 2009 10:06am),
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:
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...
8 September 2009 at 10:35am
(Last edited: 8 September 2009 10:49am),
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).
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.