I had just updated the patch which handles the new policy introduced in r8211 (good one!), if one of the core dev could take a look at it (it has been marked as RFC). I think it's an important addition for 1.0, otherwise it's really hard to do not repeat yourself in an i18nized templates. This new "feature" is fully compatible with the existing blocktrans tag.
> I had just updated the patch which handles the new policy introduced > in r8211 (good one!), if one of the core dev could take a look at it > (it has been marked as RFC). I think it's an important addition for > 1.0, otherwise it's really hard to do not repeat yourself in an > i18nized templates. This new "feature" is fully compatible with the > existing blocktrans tag.
I totally agree, this would make writing sane templates much easier. Given the serious limitations when using named URLs in translated templates with the url template tag, I would even say it's more a bug fix than a new feature.
At Pinax [1] we use the captureas template tag [2] as a workaround which is undoubtful nasty and definitely un-DRY.
On Sat, 2008-08-09 at 10:14 +0200, David Larlet wrote: > Hello,
> I had just updated the patch which handles the new policy introduced > in r8211 (good one!), if one of the core dev could take a look at it > (it has been marked as RFC). I think it's an important addition for > 1.0, otherwise it's really hard to do not repeat yourself in an > i18nized templates. This new "feature" is fully compatible with the > existing blocktrans tag.
I'll look at this in the next couple of days -- today and tomorrow are already busy -- and probably commit it before the beta (otherwise it will wait until after 1.0). I suspect any solution to this is going to be a slight compromise and I'm not entirely in love with the approach there, but I haven't seen (or been able to think of) anything else that doesn't look just as messy.
> On Sat, 2008-08-09 at 10:14 +0200, David Larlet wrote:
> > Hello,
> > I had just updated the patch which handles the new policy introduced
> > in r8211 (good one!), if one of the core dev could take a look at it
> > (it has been marked as RFC). I think it's an important addition for
> > 1.0, otherwise it's really hard to do not repeat yourself in an
> > i18nized templates. This new "feature" is fully compatible with the
> > existing blocktrans tag.
> I'll look at this in the next couple of days -- today and tomorrow are
> already busy -- and probably commit it before the beta (otherwise it
> will wait until after 1.0). I suspect any solution to this is going to
> be a slight compromise and I'm not entirely in love with the approach
> there, but I haven't seen (or been able to think of) anything else that
> doesn't look just as messy.
On Sun, 2008-08-10 at 15:00 -0700, Julien Phalip wrote: > Just a thought, the same approach would be valuable with the 'with' > tag:
> {% with url path.to.some_view arg1,arg2,name1=value1 as myurl %} > This is a <a href="{{ myurl }}" title="">link</a>. > {% endwith %}
No, you can't have a pony.
Please let's keep threads like this one (and similar "getting ready for 1.0" ones) on-topic. We're down to counting the hours until we have to be ready for 1.0-beta. This thread is about a significant i18n requirement for 1.0, not a minor typing saver that can wait until after 1.0 or even the end of time without things being significantly worse off.
Yes, it's just a wishlist item. But it's also yet another email that somebody trying to work through this thread needs to realise is not actually on-topic.
> On Sun, 2008-08-10 at 15:00 -0700, Julien Phalip wrote:
> > Just a thought, the same approach would be valuable with the 'with'
> > tag:
> > {% with url path.to.some_view arg1,arg2,name1=value1 as myurl %}
> > This is a <a href="{{ myurl }}" title="">link</a>.
> > {% endwith %}
> No, you can't have a pony.
> Please let's keep threads like this one (and similar "getting ready for
> 1.0" ones) on-topic. We're down to counting the hours until we have to
> be ready for 1.0-beta. This thread is about a significant i18n
> requirement for 1.0, not a minor typing saver that can wait until after
> 1.0 or even the end of time without things being significantly worse
> off.
> Yes, it's just a wishlist item. But it's also yet another email that
> somebody trying to work through this thread needs to realise is not
> actually on-topic.
> Thanks,
> Malcolm
Hi,
I don't think that my thought was completely off-topic here. I was
only trying to add to the discussion, not just add a random item on
the wish list.
Extending the 'with' tag syntax would allow you to wrap {% blocktrans
%} with a {% with url .... as myurl %}. That way, you wouldn't need to
change the blocktrans tag syntax at all, and more, you could re-use
that functionality in many other situations where {% with %} can be
applied.
If you think this is a bad idea or that what I suggest above is not
achievable, then I'm sorry. By no means did I want to clutter this
thread with irrelevant ideas.
On Sun, 2008-08-10 at 17:31 -0700, Julien Phalip wrote:
[...]
> Extending the 'with' tag syntax would allow you to wrap {% blocktrans > %} with a {% with url .... as myurl %}. That way, you wouldn't need to > change the blocktrans tag syntax at all, and more, you could re-use > that functionality in many other situations where {% with %} can be > applied.
Fair enough. It wasn't clear, at least to me, that that was what you were proposing (although expanding the use of "with" outside the blocktrans is definitely pony country). It requires a change in the way blocktrans work and the "with" tag is now being overloaded, which is a bit of a slippery slope. Putting tags inside other tags is just generally ugly, so a different block tag would be a better solution here. That's why we talked about something like a hypothetical "with-block" tag in one of the earlier threads.
> Fair enough. It wasn't clear, at least to me, that that was what you
> were proposing (although expanding the use of "with" outside the
> blocktrans is definitely pony country).
My apologies, I was indeed not very clear in my first post.
> It requires a change in the way
> blocktrans work and the "with" tag is now being overloaded, which is a
> bit of a slippery slope. Putting tags inside other tags is just
> generally ugly, so a different block tag would be a better solution
> here. That's why we talked about something like a hypothetical
> "with-block" tag in one of the earlier threads.
I always thought that the creation of variables within templates
wasn't very pythonic in the sense "There shouldn't be more than one
way to do something". Currently, both {% blocktrans %} and {% with %}
can create variables. My preference would be to let {% blocktrans %}
focus on its job for internationalisation, and move all the variable
creation to a single, dedicated for that purpose, tag (maybe 'with'?).
Just following up on the 'with-block' idea. Here's a suggested syntax:
{% withblock as myurl %}
{% url path.to.some_view arg1,arg2,name1=value1 %}
{% in %}
{% blocktrans %}
This is a <a href="{{ myurl }}" title="">link</a>.
{% endblocktrans %}
{% endwithblock %}
Very much like the {% captureas %} tag mentioned above, but a bit
prettier as it would limit the variable life to the given {% in %}
block. Plus, that would give a single and generic way to create block
variables. What if we later find other use cases than just passing
URL's to a blocktrans?
On Aug 11, 11:18 am, Julien Phalip <jpha...@gmail.com> wrote:
> > Fair enough. It wasn't clear, at least to me, that that was what you
> > were proposing (although expanding the use of "with" outside the
> > blocktrans is definitely pony country).
> My apologies, I was indeed not very clear in my first post.
> > It requires a change in the way
> > blocktrans work and the "with" tag is now being overloaded, which is a
> > bit of a slippery slope. Putting tags inside other tags is just
> > generally ugly, so a different block tag would be a better solution
> > here. That's why we talked about something like a hypothetical
> > "with-block" tag in one of the earlier threads.
> I always thought that the creation of variables within templates
> wasn't very pythonic in the sense "There shouldn't be more than one
> way to do something". Currently, both {% blocktrans %} and {% with %}
> can create variables. My preference would be to let {% blocktrans %}
> focus on its job for internationalisation, and move all the variable
> creation to a single, dedicated for that purpose, tag (maybe 'with'?).
> Just following up on the 'with-block' idea. Here's a suggested syntax:
> {% withblock as myurl %} > {% url path.to.some_view arg1,arg2,name1=value1 %} > {% in %} > {% blocktrans %} > This is a <a href="{{ myurl }}" title="">link</a>. > {% endblocktrans %} > {% endwithblock %}
> Very much like the {% captureas %} tag mentioned above, but a bit > prettier as it would limit the variable life to the given {% in %} > block. Plus, that would give a single and generic way to create block > variables. What if we later find other use cases than just passing > URL's to a blocktrans?
It looks interesting but I can't see how you define more than one variable with this syntax.
I agree that the current implementation has cons and lack of some genericity, we had chatted about that with Jannis before and the patch is the best compromise we found (the other one is to allow all tags in blocktrans definition which is not backward incompatible with the proposed one). We discuss about that for months and I think that's better than nothing to have at least an extended blocktrans tag. If another solution comes up in the next months, that's great but during this time we'll be able to use it (hopefully in 1.0).
> You can have a look and see if that can help in this situation.
Well, to be honest, I'm not fond of this solution which is very verbose. On the other hand, if we'd like to see this in 1.0 we need to take a decision. Malcolm seemed to be +0 (correct me if I'm wrong), Jannis +1 on the initial implementation, any one else strongly against the extension of blocktrans?
> > You can have a look and see if that can help in this situation.
> Well, to be honest, I'm not fond of this solution which is very verbose. > On the other hand, if we'd like to see this in 1.0 we need to take a > decision. Malcolm seemed to be +0 (correct me if I'm wrong), Jannis +1 > on the initial implementation, any one else strongly against the > extension of blocktrans?
I've looked at it some more and reviewed the patch. I'm not comfortable rushing it in at the moment because the API really is a bit dubious still. We can still add stuff in a backwards-compatible fashion after 1.0, so it's being punted for now. Sorry, but time has run out.
The more I look at all those things that are tags without looking like tags in the blocktrans tag, the more it looks messy (particularly as you cannot break a tag over multiple lines). Something like #8297 but with a better syntax feels more Django-y and Pythonic. So play with that a bit if you like, but the code is post-1.0 for now.
|
