On Thu, Oct 27, 2011 at 7:05 PM, SmileyChris <[email protected]> wrote:
> I think this may be that the previous format worked but wasn't really
> supported.
> The 1.2 documentation on the blocktrans tag says:
>>
>> 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...
>
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
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
