Changes between Version 5 and Version 6 of StringEncoding


Ignore:
Timestamp:
Apr 6, 2007, 8:54:47 AM (18 years ago)
Author:
Malcolm Tredinnick
Comment:

Note gettext_lazy problems

Legend:

Unmodified
Added
Removed
Modified

  • StringEncoding

    v5 v6  
    7777'''Proposal:''' For databases that support table creation with different collation or encoding schemes, add support in the existing DATABASE_OPTIONS setting for these.
    7878
    79 This would be analagous to the current encoding support that is provided in DATABASE_OPTIONS for !MySQL.
     79This would be analagous to the current encoding support that is provided in DATABASE_OPTIONS for MySQL.
    8080
    8181== Talking To External Processes ==
    … …  
    107107 * The getttext() functions return bytestrings using DEFAULT_CHARSET. This causes a number of difficulties in the code, because UTF-8 encoded bytestrings cannot safely be passed to the string.join() method.
    108108    * Consider switching to ugettext() and friends everywhere internally. These return unicode strings that can be used in join() calls. The alternative requires being aware of when bytestrings might be involved and doing yet another decode()/encode() round-trip around the join(). Error-prone and time-consuming.
     109 * gettext_lazy() is not a perfect proxy for a string. In particular, ''.join([gettext_lazy('some string'), foo]) does not work, because join() wants a real string instance as the first element.
     110     * This might be fixable by using metaprogramming to make the returned result of gettext_lazy() look like an instance of its result classes. This could have unintended side-effects, though. I haven't tested this out yet.
     111     * The alternative is to blow away gettext_lazy and do what other languages do: use gettext_noop() to mark strings and then put gettext() calls in at the presentation locations to do the translation.
Back to Top