id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
33631	Blocktranslate asvar escapes variables, but stores the result as str instance, leading to double escaping	Richard Ebeling	Cheng Yuan	"In the docs, this snippet is given as an example usage of `blocktranslate` with the `asvar` argument (here: [https://docs.djangoproject.com/en/4.0/topics/i18n/translation/#blocktranslate-template-tag]:
{{{
{% blocktranslate asvar the_title %}The title is {{ title }}.{% endblocktranslate %}
<title>{{ the_title }}</title>
<meta name=""description"" content=""{{ the_title }}"">
}}}

However, this template is buggy when `title` is a string, which I'd argue is a common use case.

`title` will be escaped when formatting the content of the `blocktranslate` block, but the ""was escaped"" information is discarded, and `the_title` will be a `str` instance with escaped content.
When later using the `the_title` variable, it will be conditionally escaped. Since it is a `str`, it will be escaped, so control characters are escaped again, breaking their display on the final page.

Minimal example to reproduce (can be put in any view):
{{{
    from django.template import Template, Context
    template_content = """"""
{% blocktranslate asvar the_title %}The title is {{ title }}.{% endblocktranslate %}
<title>{{ the_title }}</title>
<meta name=""description"" content=""{{ the_title }}"">
""""""
    rendered = Template(template_content).render(Context({""title"": ""<>& Title""}))
    assert ""&amp;lt;"" not in rendered, ""> was escaped two times""
}}}

I'd argue that `blocktranslate` should:
* Either assign a `SafeString` instance to prevent future escaping
* or not escape the variables used within the translation, and store them marked as unsafe (= as `str` instance)"	Bug	closed	Uncategorized	4.0	Normal	fixed	blocktranslate asvar escape		Ready for checkin	1	0	0	0	0	0