Hi there,
When using i18n I'm getting a nice stacktrace for every request, this
only happens once you set the language for a client and the exception
raises due to Content-Language being a Unicode string for some reason.
Backtrace:
Traceback (most recent call last):
File
"/var/lib/python-support/python2.4/django/core/servers/basehttp.py",
line 272, in run
self.result = application(self.environ, self.start_response)
File
"/var/lib/python-support/python2.4/django/core/servers/basehttp.py",
line 614, in __call__
return self.application(environ, start_response)
File
"/var/lib/python-support/python2.4/django/core/handlers/wsgi.py", line
206, in __call__
start_response(status, response_headers)
File
"/var/lib/python-support/python2.4/django/core/servers/basehttp.py",
line 360, in start_response
assert type(val) is StringType,"Header values must be
strings"
AssertionError: Header values must be strings
If I place "import pdb; pdb.set_trace()" on basehttp.py before the
assert it's the Content-Language header the one that is not a string:
>
/var/lib/python-support/python2.4/django/core/servers/basehttp.py(359)start_response()
-> for name,val in headers:
(Pdb) p headers
[('Vary', 'Accept-Language, Cookie'), ('Content-Type',
'text/html; charset=utf-8'), ('Content-Language', u'ca'),
('Set-Cookie', ' sessionid=9935d4ee987c1a0cc42f051fda2bbe09;
expires=Tue, 12-Jun-2007 10:03:45 GMT; Max-Age=1209600;
Path=/;')]
Not sure if that's my fault that made Content-Language to be a unicode
string or if it's a bug on unicode branch.
Cheers,
Marc
El jue, 24-05-2007 a las 23:06 +1000, Malcolm Tredinnick escribi�:
> Hi folks,
>
> The unicode branch, [1], is now at a point where it is essentially
> feature-complete and could do with a bit of heavy testing from the wider
> community.
>
> So if you have some applications that work against Django's current
> trunk and would like to try them out on the unicode branch, I'd
> appreciate your efforts. The porting effort should be very minimal
> (almost zero, in many cases).
>
> For code that is only meant to work with ASCII data, there are probably
> no changes required at all. For code that is meant to work with all
> kinds of input (essentially, arbitrary strings), there are a few quick
> porting steps required.
>
> See [2] for the short list (5 steps, maximum!) of changes you might need
> to make. For more detailed information, have a read through the
> unicode.txt document in the docs/ directory of the branch.
>
> Any bugs you find should be filed in Trac. Put "[unicode]" at the start
> of the summary title so that I can search for them later. No need to put
> any special keywords or anything like that in (the "version" field
> should be set to "other branch", if you remember).
>
> A couple of things to watch out for when you're testing:
>
> (A) Strings that seem to mysteriously disappear, but when you
> examine the source, you see something like
> "<django.utils.functional.__proxy__ object at 0x2aaaaf87a750>".
> These shouldn't be too common and will mostly be restricted to
> places like the admin interface that do introspection.
>
> (B) Translations that happen too early. If you have translations
> available and use your app in a language that is different from
> the LANGUAGE_CODE setting, watch out for any strings that are
> translated into LANGUAGE_CODE, instead of your current locale.
> This is a sign that ugettext() is being used somewhere that
> ugettext_lazy() should be used.
>
> (C) If you're using Python 2.3, look for strings that don't make
> much sense when printed. That is a sign that a bytestring is
> being used where a unicode string was needed (not your fault;
> it's an oversight in Django). Python 2.3 has some
> "interesting" (I could use nastier words) behaviour when it
> tries to interpolate non-string objects into unicode strings (it
> doesn't call the __unicode__ method!!) and we have to work
> around them explicitly. I think I've got most of them, but I'll
> bet I have overlooked some.
>
> Most bugs that people are finding at the moment fit into one of these
> categories and they are very easy to fix once we find them. I've tried
> to nail most of them in advance, but you can probably imagine how
> exciting it is to read every line of source code and try to find all the
> strings that are in a precise form that need changing. My attention may
> have drifted from time to time.
>
> Have realistic expectations about this branch, too. It is meant to be as
> close to 100% backwards-compatible as we can make it. So, for example,
> usernames still have to use normal ASCII alphabetic characters, etc.
> Similarly, the slugify filter still behaves as it did before. At some
> point it will be extended to handle a _few_ more non-ASCII characters,
> but it's never going to be a full transliteration function. They are the
> two big items I expect people would otherwise try to extend beyond what
> is intended. There may be others and I'm sure we'll discover what they
> are as the questions pop up.
>
> [1] http://code.djangoproject.com/wiki/UnicodeBranch
> [2]
> http://code.djangoproject.com/wiki/UnicodeBranch#PortingApplicationsTheQuickChecklist
>
> Regards,
> Malcolm
>
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
