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
-~----------~----~----~----~------~----~------~--~---
