On 24 , 17:06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> 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).
Hello,
I've checked out unicode branch today and immediately found two bugs.
This code doesn't work:
def __unicode__(self):
langs = dict(settings.LANGUAGES)
return _("%s text of the page %s") % (langs[self.language],
self.page.url)
(I get TypeError: unsupported operand type(s) for %: '__proxy__' and
'tuple')
The second bug is actually the unicode bug that was present in non-
unicode django and still persists in unicode branch. Unicode data
fetched from postgresql using psycopg2 is invalid under some
circumstances. I'll provide more details when I'll have time.
Eugene
>
> 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#PortingApplicationsT...
>
> 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
-~----------~----~----~----~------~----~------~--~---
