#10369 closed (fixed)
{% trans %} and {% blocktrans %} breaking auto escape
| Reported by: | Owned by: | nobody | |
|---|---|---|---|
| Component: | Internationalization | Version: | 1.0 |
| Severity: | Keywords: | ||
| Cc: | Triage Stage: | Accepted | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
There is an issue with the {% trans %} and {% blocktrans %} breaking the auto escape of variables displayed in them.
If myvar is defined in the template these two examples will not escape the myvar:
{% trans myvar %}
{% blocktrans %}this is {{ myvar }}{% endblocktrans %}
However, if you use the "with" command with the blocktrans, auto escaping wont be lost:
{% blocktrans with myvar as myvar %}this is {{ myvar }}{% endblocktrans %}
Attachments (2)
Change History (8)
comment:1 by , 17 years ago
| milestone: | → 1.1 |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
comment:2 by , 17 years ago
| Owner: | changed from to |
|---|
by , 17 years ago
| Attachment: | i18n_autoescape_t10369_r10178.diff added |
|---|
comment:3 by , 17 years ago
| Has patch: | set |
|---|
Variables aren't getting escaped in the trans and blocktrans template tags because, unlike other template tags, they render their own contents. For blocktrans, one solution would be to save a VariableNode for each variable token in the parser, then render them all before the string interpolation. That seemed complicated, so I implemented the solution in this patch, at the cost of a new module-level function in django.template.
by , 17 years ago
| Attachment: | i18n_autoescape_t10369_r10178.2.diff added |
|---|
comment:4 by , 17 years ago
| Owner: | changed from to |
|---|
Added underscores to mark the function private. I've tried to come up with a way to do this using classes and inheritence but couldn't come up with anything sensible. The Node class already has a render method with a different signature. If "add some underscores and call it a day" is good enough, then I guess the patch is ready, otherwise someone else should take a look.
comment:5 by , 17 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Fix with tests