On 27/11/12 12:33, Tom Evans wrote:
> On Mon, Nov 26, 2012 at 9:43 PM, Some Developer
> <someukdeveloper@gmail.com> wrote:
>> On 10/11/12 21:49, Some Developer wrote:
>>>
>>> In the documentation it is quite clear that the following syntax is
>>> correct in templates:
>>>
>>> {% load i18n %}
>>>
>>> {% trans "my_string" as blah_string %}
>>>
>>> {{ blah_string }}
>>>
>>> etc etc.
>>>
>>> This works fine if the original trans tag is inside a block but then the
>>> blah_string variable is only valid within that block. If you place the
>>> trans tag in a global position (outside of any blocks) the blah_string
>>> variable does not work when you try and use it in a block (that is any
>>> block). I am using Django 1.4.2 and think this behaviour is somewhat
>>> strange given the documentation for this particular feature. Surely you
>>> should be able to declare the trans tag outside of any block as the
>>> chances are that you will want to use the blah_string variable in more
>>> than one block (I often have three or four blocks per page for various
>>> things).
>>>
>>> So is this a bug or am I doing something wrong?
>>
>>
>> Any comments on this at all? I'm still not entirely sure if this behaviour
>> is intentional or not.
>>
>
> Templates have scope, so yes, this is expected. Any nodes in a derived
> template that aren't {% block %} or inside a {% block %} tag are
> ignored or not output*.
>
> An alternative would be to pass a list or dictionary of shared
> translations to the template.
>
> Cheers
>
> Tom
>
> * I must admit, I don't know precisely how template rendering handles
> this. Certain tags, eg loading tag libraries will work fine. Any tag
> that outputs anything will not, and any tag that sets things in the
> context will not be in scope in other blocks.
>
Thanks for the reply.
I have to admit to finding this behaviour both counter-intuitive and
somewhat perplexing.
This use case in particular would benefit greatly from allowing a
variable to be declared in a global scope and used throughout a specific
template. I'm not suggesting that global variables be inherited by
derived templates mearly that you can have global variables in
individual templates.
I guess I'll have to go with the list or dictionary approach although
I'm not that happy about it as it feels like a bit of a hack to get
round a problem that really shouldn't exist.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment