#19915 closed Bug (fixed)
templatetag "blocktrans" ignores the TEMPLATE_STRING_IF_INVALID setting
Reported by: | Natalia Bidart | Owned by: | matiasb |
---|---|---|---|
Component: | Template system | Version: | 1.4 |
Severity: | Normal | Keywords: | blocktrans, template_string_if_invalid |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
If I define the setting TEMPLATE_STRING_IF_INVALID to something other than the empty string, for example:
TEMPLATE_STRING_IF_INVALID = 'INVALID'
when I have a template that uses the templatetag blocktrans, all those variables not defined in any context (neither local nor global context) are not shown as INVALID but they are rendered as the empty string instead.
You can reproduce this by:
- define the setting to be:
TEMPLATE_STRING_IF_INVALID = 'INVALID'
- create a dummy template
foo.txt
:
{% load i18n %} {% blocktrans %}Hello {{ thing }}! Django {{ action }} big time! {% endblocktrans %}
- render the template with an incomplete context:
>>> from django.template.loader import render_to_string >>> print render_to_string('foo.txt', {'thing': 'world'}) Hello world! Django big time!
- then, remove the blocktrans tags, and re-render, you will get instead:
>>> print render_to_string('foo.txt', {'thing': 'world'}) Hello world! Django INVALID big time!
I would expect the same behaviour with or without the use of blocktrans.
Change History (6)
comment:1 Changed 11 years ago by
comment:2 Changed 11 years ago by
Component: | Uncategorized → Template system |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:3 Changed 11 years ago by
Owner: | changed from nobody to matiasb |
---|---|
Status: | new → assigned |
comment:4 Changed 11 years ago by
Has patch: | set |
---|
Proposed fix, pull request: https://github.com/django/django/pull/865
(all tests passing using SQLite).
comment:5 Changed 11 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
A simple solution would be to apply something like this (if approved I can propose a proper patch with tests):
django/templatetags/i18n.py