Opened 15 years ago
Closed 13 years ago
#12104 closed New feature (fixed)
Object->object lookup fails in blocktrans
| Reported by: | philipn | Owned by: | nobody |
|---|---|---|---|
| Component: | Internationalization | Version: | 1.1 |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Design decision needed | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Lookups such as {{O.a}} fail in blocktrans blocks.
Here is a complete example:
{% load i18n %}
<html>
<body>
This causes a keyerror:
{% blocktrans %}
Value 'a' of object O: {{ O.a }}
{% endblocktrans %}
The following, of course, works:
Value 'a' of object O: {{ O.a }}
</body>
</html>
With a view being:
def blocktrans(request):
O = {'a': 'Foo!'}
d = {
'O': O,
}
return render_to_response('home.html', d)
I have attached a patch.
Attachments (3)
Change History (8)
by , 15 years ago
| Attachment: | django_svn_blocktrans_patch.diff added |
|---|
comment:1 by , 15 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:2 by , 15 years ago
| Resolution: | invalid |
|---|---|
| Status: | closed → reopened |
If this is to keep translations simple then that makes sense, especially considering blocktrans doesn't allow for other blocks inside it.
Adding support for other block tags inside of blocktrans seems easy enough to add, though (using the same idea as my patch -- executing a template rendering).
But, unlike other blocks in blocktrans, this kind of variable access doesn't trigger an error message.
I've attached a patch that causes an error to be displayed when you try and use complex variable lookups inside a blocktrans block.
If we did decide to allow for variable.attr syntax then it would probably be better to use django.template's Variable class to look up the variable's values rather than the context-dictionary-key approach used in the code currently.
I guess it's also worth noting that the current blocktrans variable lookup behaviour will throw a keyerror for {{ variable_that_isnt_in_context }} when templates normally do not. With this in mind it really seems like the right thing to do is to replace the lookup behaviour with Variable(..).resolve(). I've attached a patch that does this, as well.
by , 15 years ago
| Attachment: | blocktrans_display_error.diff added |
|---|
displays templateerror instead of keyerror
by , 15 years ago
| Attachment: | blocktrans_variable_attribute_works.diff added |
|---|
normal-like variable reference in blocktrans
comment:3 by , 15 years ago
| Triage Stage: | Unreviewed → Design decision needed |
|---|
comment:4 by , 14 years ago
| Severity: | → Normal |
|---|---|
| Type: | → New feature |
comment:5 by , 13 years ago
| Easy pickings: | unset |
|---|---|
| Resolution: | → fixed |
| Status: | reopened → closed |
| UI/UX: | unset |
This is essentially fixed since KeyError isn't thrown any more after [16723].
Besides, I don't think that {{ variable.attribute }} lookups should be allowed, especially since blocktrans already offers ways of creating simple temporary variables and it's all well documented. One can always use {{ foo.bar }} inside blocktrans but that will count as a flat variable name called "foo.bar", which should work as far as gettext itself is concerned.
I believe this behavior is intentional (perhaps to keep substitution strings in translation messages simple?), as it is clearly documented. You need to use "with O.a as O_a" in your blocktrans opening tag.