Opened 17 years ago
Closed 17 years ago
#7100 closed (invalid)
breadcrumb UnicodeEncodeError
Reported by: | dvainsencher | Owned by: | nobody |
---|---|---|---|
Component: | Core (Management commands) | Version: | dev |
Severity: | Keywords: | breadcrumbs | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Non ascii str string raise UnicodeEncodeError in breadcrumbs render in django/contrib/admin/templates/admin/change_form.html
14 {% if add %}{% trans "Add" %} {{ opts.verbose_name }}{% else %}{{ original|truncatewords:"18" }}{% endif %}
when editing an object.
I purpose change django/contrib/admin/views/main.py
403 - 'original': manipulator.original_object, 403 + 'original': smart_str(manipulator.original_object),
or, if original can't be changed, we can just add another variable in the Request
404 + 'original_str': smart_str(manipulator.original_object),
and change reference in the template - django/contrib/admin/templates/admin/change_form.html
14 - {% if add %}{% trans "Add" %} {{ opts.verbose_name }}{% else %}{{ original|truncatewords:"18" }}{% endif %} 14 + {% if add %}{% trans "Add" %} {{ opts.verbose_name }}{% else %}{{ original_str|truncatewords:"18" }}{% endif %}
Attachments (1)
Change History (6)
comment:1 by , 17 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 17 years ago
Has patch: | unset |
---|
by , 17 years ago
Attachment: | defaultfilters.diff added |
---|
comment:3 by , 17 years ago
Sorry by the missing patch. I tried other approach now as showed in the patch.
I'm still in doubt if the check for to_str in _dec function is really necessary, but i'm sure that for now it have little impact over other stringfunctions decorated functions.
comment:4 by , 17 years ago
There is also the workaround of use unicode function in the model but i think that a generic solution is better.
comment:5 by , 17 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
I've verified truncatewords handles unicode properly. The problem seems to be a Model that returns a non-ASCII data via an __str__() function instead of a __unicode__() function. Having a __unicode__ function in your model is not a workaround, it is the generic solution for having your models return non-ASCII representations of themselves. If I have misunderstood how you ran into this problem please reopen with specifics of the Model involved, data contained in it, and a traceback of the error you are seeing. The one I can recreate is definitely a user error of not having a __unicode__ method on a model that needs one.
Next time, please attach a proper patch file, since it will include context in the even that line 402 or 403 changes before we get to the ticket.
This looks like a bug, but the proposed fix isn't the right approach. Instead, truncatewords should be fixed to work with unicode strings. And we don't need to go overboard here; we'll still consider "words" to be whitespace-separated sequences of characters, rather than teaching it to understand all the constraints of all the languages in the world.