The merge is done, only bug #2487 remains to be handled. Congrats toddy for the piece of work done :)

How looks utf-8 mails with your mailers?

In my cast, the subject line is fine but the content, that is utf-8, is not rendered properly in gnus: it's shown like it were iso-8859-15 while it's really utf-8, it's fine if it pass it through `iconv --from-code utf-8 --to-code iso-8859-15`. It's fine in Squirrelmail.

The odd thing is the fact that I'm able to send mails supposedly in utf-8 with Squirrelmail and read them properly with gnus... (but I'm not 100% sure that Squirrelmail really sent an utf-8 mail, despite the headers).

That's definitely the last thing we should inquire about before the release.

Hum, several comments were lost because there's something very wrong in the way the database backup scripts make backups :((
It makes broken backups.

I did not checked and did not understood that you were not using mysqldump (well, I should have guess, since you wanted at first to avoid using the command line mysql client). And with complex databases like the one of Gna!, indeed we reached several cases were the hand made mysqldump was unable to cope with.
So I was left with a broken database and a broken backup. Hence I had to restore the database with the last proper backup, that I converted (well, not directly the backup, indeed) in UTF-8.

But, well, that's the price of using Gna!. We provide a free and usually efficient service, but we also use it as test platform, the one which help us to caught bug that typically cannot be caught on a test machine.
Quite true, I could have downloaded the database I made it the whole conversion stuff on another machine; I was overconfident on the backup script. But that's quite nasty to provide a backup script that is not safe.

Happy we caught that before the release.

I did it before but I redid it just in case and the result is the same. Everything is fine apart succes/error messages.

I think it would be quite unusual (possible though) to have a mysqld running without mysql command being available.

As Savane installation process already relies on it, we should not be worried about using it.

However, the fact that we have a perl script relying on Savane libs is in fact helpful, since the user is not forced to type password. Have you checked out my changes?

Finally, yes, the problem occurs only with error/success messages. That's what I found strange.

There\'s also an issue with the encoding of mails we should sort out before the release, mentioned in bug #2440

Looking at your script more carefully, I'm not sure to understand why you use perl to do the mysql insert instead of a simple dumb
mysql < my_converted_file.dump

I think it gets messy because dbi add quotes when it considers to be necessary but a mysql dumpfile is supposed to be correctly escaped already.

BTW, have original database file (in sql/mysql) have been converted for fresh installs?

Hum, will be done by the end of this week, promise (urf, got an already big list of things to do for this week, but this one has been on the list for too long already)

No, I'm sorry, I havent tested further since then (my brother was in Strasbourg for a few days, I was more or less off the net during that period and I have some backlog to handle right now).

"In fact, you should not commit on the HEAD a fix that have to go on the branch."

Right, but the fix was not specific to UTF-8, and the function seems to be used in some other places as well, so I thought it would be sensible to commit to HEAD.

Apart from that, did the HEAD version of Util.pm fix your problem?

Hm, that's strange. I didn't add any code for handling quotes, because the script operates on a database dump. In this dump (which is SQL) I thought all quotes are already escaped.

However, maybe the failure was not with a quote, but a newline. I changed the file Util.pm in the lib subdirectory a few weeks ago, to handle newlines as well. To make the merge easier, I didn't include the fix in the UTF-8 branch; it is only in HEAD. So could you update your file lib/Savannah/Util.pm back to HEAD and try that script again?

BTW: Should I commit the exact same fix in HEAD and the branch twice? I thought that this could create some confusion, so I refrained from doing so.

I'll try to test this stuff before the end of the week. If I cant, I'm afraid I wont be able to do it the next week.

This item is for tracking the progress of the switch to UTF-8, needed for correct I18N of Savane.

What has happened already?
- Initial version of README for update
- Generation of needed locales (UTF-8 enabled version)
- Conversion of site-specific files into UTF-8
- Switch in the PHP frontend to display only UTF-8

What needs still to be done?
- Complete README for update
- Conversion of database into UTF-8