Code

Changes between Version 5 and Version 6 of UnicodeInDjango


Ignore:
Timestamp:
01/13/06 13:01:44 (8 years ago)
Author:
hugo
Comment:

fixed typo in setting name

Legend:

Unmodified
Added
Removed
Modified
  • UnicodeInDjango

    v5 v6  
    55Just a pin-down of things that spring to mind, all of them need more complete checking: 
    66 
    7  * database backends need to handle unicode vs. DATABASE_ENCODING translations 
     7 * database backends need to handle unicode vs. DATABASE_CHARSET translations 
    88 * special casing: the psycopg backend will need type handlers for string types (just as it already has type handlers for date/time types) 
    9  * the HTTPResponse sending machinery needs to do the unicode to DEFAULT_ENCODING translation 
    10  * the HTTPRequest creation process needs to turn outside strings into unicode strings, using the provided charset (if given) or defaulting to DEFAULT_ENCODING (as that is what was sent to the browser when the form was transmitted) 
     9 * the HTTPResponse sending machinery needs to do the unicode to DEFAULT_CHARSET translation 
     10 * the HTTPRequest creation process needs to turn outside strings into unicode strings, using the provided charset (if given) or defaulting to DEFAULT_CHARSET (as that is what was sent to the browser when the form was transmitted) 
    1111 * special casing: what happens with GET parameters? those don't provide charsets, what should we do if DEFAULT_ENCODING is utf-8, but the GET parameters aren't valid utf-8? The clean way would be to throw an exception (like with all other places, too) 
    1212 * internal usage of str() needs to be checked and supposedly changed over to unicode() usage