Regression in blocktrans tag parsing between 1.2 and 1.3

23 views
Skip to first unread message

Tom Evans

unread,
Oct 26, 2011, 5:29:03 AM10/26/11
to django...@googlegroups.com
Hi all

Django 1.3's blocktrans tag is documented as still supporting 1.2's
more verbose syntax. However, if you attempt a plural translation, it
barfs. More importantly, it rejects a format that 1.2 accepts, and
accepts a format that 1.2 rejects.

This format is rejected by 1.2 and accepted by 1.3:

tmpl2 = """
{% load i18n %}
{% blocktrans with items as stuff and count items|length|add:"-3" as
more_count %}
{{ more_count }} more
{% plural %}
{{ more_count }} more
{% endblocktrans %}
"""

This format is accepted by 1.2 and rejected by 1.3:

tmpl3 = """
{% load i18n %}
{% blocktrans count items|length|add:"-3" as more_count and items as stuff %}
{{ more_count }} more
{% plural %}
{{ more_count }} more
{% endblocktrans %}
"""

The 1.3 documentation states that "The previous more verbose format is
still supported", without going into details of what that format is.
This probably requires either a fix to be more 1.2 compatible, or a
documentation note in 1.3 noting the differences in formats that it
will parse and an update to the 1.3 backwards incompatibilities
noting this difference.

Cheers

Tom


Full transcripts below:

>>> from django.template import Template, Context, TemplateSyntaxError
>>> import django
>>> django.VERSION
(1, 2, 7, 'final', 0)
>>> try:
... Template(tmpl2).render(Context({'items':[1,2,3,4,5,6]}))
... except TemplateSyntaxError, e:
... print e
...
variable bindings in 'blocktrans' must be 'with value as variable'
>>> try:
... Template(tmpl3).render(Context({'items':[1,2,3,4,5,6]}))
... except TemplateSyntaxError, e:
... print e
...
u'\n\n\n3 more\n\n'


>>> from django.template import Template, Context, TemplateSyntaxError
>>> import django
>>> django.VERSION
(1, 3, 1, 'final', 0)
>>> try:
... Template(tmpl2).render(Context({'items':[1,2,3,4,5,6]}))
... except TemplateSyntaxError, e:
... print e
...
u'\n\n\n3 more\n\n'
>>> try:
... Template(tmpl3).render(Context({'items':[1,2,3,4,5,6]}))
... except TemplateSyntaxError, e:
... print e
...
"count" in u'blocktrans' tag expected exactly one keyword argument.

SmileyChris

unread,
Oct 27, 2011, 2:05:54 PM10/27/11
to django...@googlegroups.com
I think this may be that the previous format worked but wasn't really supported.

Designate and bind a counter value with the name count
[...] 
A more complex example:
{% blocktrans with article.price as amount count i.length as years %}

Your "working in 1.3" example isn't correct -- the 'and' is superfluous (in fact, I'm surprised it worked).
Your "working in 1.2" example should only be binding a single value with count, as shown in the 1.2 documentation.

So it sounds like this is a case of things working which probably shouldn't have to begin with...

Tom Evans

unread,
Oct 27, 2011, 3:01:24 PM10/27/11
to django...@googlegroups.com

Is the and superfluous? Remember we are not talking about the 1.3
format, but 1.3 parsing the 1.2 format, which it is specified to do.

The 1.2 documentation states:

"If you need to bind more than one expression inside a blocktrans tag,
separate the pieces with and:"

and further:

"This tag also provides for pluralization. To use it:

Designate and bind a counter value with the name count. This value
will be the one used to select the right plural form.

Specify both the singular and plural forms separating them with the {%
plural %} tag within the {% blocktrans %} and {% endblocktrans %}
tags."

whilst specifying this as an example for count:

"{% blocktrans count list|length as counter %}
There is only one {{ name }} object.
{% plural %}
There are {{ counter }} {{ name }} objects.
{% endblocktrans %}"

If you look at tmpl3:

It binds a counter value with the name count
It specifies the count parameter in the same way as the docs
It separates the variables to be bound with 'and', as specified by the docs.

I don't doubt that the ambiguity of the documentation and the
complexity of the parsing played a part in why the tag was changed to
specify binding parameters in a completely different manner, but the
critical thing is that the docs specify that formats that worked in
1.2 will continue to work in 1.3, and that is not the case.

Either the code should be changed to parse 1.2 style formats in the
same way as 1.2 did, or the 1.3 documentation/rel notes should be
changed to note that this is a breaking difference in 1.3, that
formats that were accepted are now not.

Cheers

Tom

Reply all
Reply to author
Forward
0 new messages