| 18 | | |
| 19 | | |
| 20 | | === Comments made by Michael in the above mailing list thread === |
| 21 | | |
| 22 | | The problem that started the original thread in django-users was that |
| 23 | | the MySQLdb backend thought it was using latin-1 encoding for the |
| 24 | | connection and therefore could not encode '€', which is in iso-8859-15 |
| 25 | | but not in iso-8859-1 aka iso-latin-1. Ticket #2896 seems to explain how |
| 26 | | this can happen. |
| 27 | | |
| 28 | | In my opinion, each of the three tickets in the subject should solve |
| 29 | | this issue, and none tries to cope with templates written in a different |
| 30 | | encoding than settings.DEFAULT_ENCODING. |
| 31 | | |
| 32 | | #952 allows to use a different encoding on the connection than |
| 33 | | settings.DEFAULT_CHARSET. It does it for all backends. |
| 34 | | |
| 35 | | #1365 sets connection.charset in the mysql backend to utf8. This makes |
| 36 | | the MySQLdb use utf8 encoding, but it's hackish and has been reported |
| 37 | | not to work in all environments. |
| 38 | | |
| 39 | | #3370 opens the mysql backend connection with charset='utf8', which |
| 40 | | seems a cleaner way to do the same as #1365. It also fixes the __repr__ |
| 41 | | of models (not sure if this is the best way, but this can be added to |
| 42 | | any of the other patches) |
| 43 | | |
| 44 | | My bottom line is that #952 has a different scope than the other two |
| 45 | | tickets, and that #1365 should be closed as duplicate of #3370. #3370 |
| 46 | | and #952 can co-exist. |
| 47 | | |
| 48 | | I'm still working on a different proposal. |
| 49 | | |