I'm working on a project trying to internationalise all the templates and
ran into this problem today, with the blocktrans tag as mentioned earlier.
Since the DEP doesn't appear to be going anywhere, I'd like to suggest some
alternatives which might be more palatable.
Since the problem appears to be with the blocktrans tag, perhaps we should
fix it there? The only reason that you need these long lines is because the
blocktrans tag doesn't allow real variables. But that sounds like a
restriction that could be lifted. So instead of:
{% blocktrans with foo=a.b.c bar=b.c.d %}{{ foo }} {{ bar }}{%
endblocktrans %}
You could simply say:
{% blocktrans %}{{ a.b.c }} {{ b.c.d }}{% endblocktrans %}
In the output PO file these could just be assigned hidden variables like _1
or something (you could try to be smarter I guess).
I'd actually like the variable interpolation to be expanded to handle cases
like:
{% blocktrans %}For more help click {{ '<a href=link>' }}here{{ '</a>'
}}{% endblocktrans %}
using the same hidden variables as above. That would make it much easier to
separate the text from the layout. Perhaps even {{ '<a href=link>' as
beginlink }} to specify the variable name.
A lame suggestion is to require backslashes for line continuation within
tags. For the syntax it;s not strictly required, but it might help with the
backward compatibility concerns.
While I'm giving suggestions, I'd also like to add something to help with
getting everything on one line. So something like:
{% blocktrans spaceless %}
A rather
long line
{% endblocktrans %}
This would strip any spaces so everything appears on one line in the PO
file.
Thoughts?
On Saturday, May 10, 2014 7:01:15 PM UTC+2, ted wrote:
>
> Let me rephrase -- Where do I voice support that I too would like this
> feature? Here, on the DEP pull request, on the original ticket?
>
> I get that there is a difference between core devs voting and non core
> devs voicing support, and that +1 from a core dev is a vote whereas +1 from
> a non-core user is an expression of support. That wasn't the question.
> The question is about how to most effectively join the chorus so core devs
> know that people do care about this when they cast their votes.
>
> T
>
> On Tuesday, April 29, 2014 10:24:12 PM UTC-4, Florian Apolloner wrote:
>>
>> Technically I'd think only core devs would vote. So neither here or there
>> would make a diff imo.
>>
>> P.S.: That said I am not sure we have a formal policy on how we act on
>> DEPs yet (or maybe I should just read DEP 001 more carefully ;))
>>
>> Cheers,
>> Florian
>>
>> On Wednesday, April 30, 2014 4:02:26 AM UTC+2, ted wrote:
>>>
>>> Now that there is a DEP, where do we voice our support (cast +1 votes)?
>>> Here, on the DEP pull request, on the original ticket?
>>>
>>> T
>>>
>>> On Wednesday, April 16, 2014 10:14:25 PM UTC-4, Loic Bistuer wrote:
>>>>
>>>> On Thursday, April 17, 2014 5:47:10 AM UTC+7, Josh Smeaton wrote:
>>>>>
>>>>> And for the last month or so a patch has existed and feedback has been
>>>>> requested. Performance was one of the concerns mentioned, so download
>>>>> Curtis' patch, and test that it works for your use case. He has asked for
>>>>> feedback a number of times. Unless you try it out, I fear that you won't
>>>>> be
>>>>> seeing multi-line tags.
>>>>>
>>>>
>>>> My thought exactly.
>>>>
>>>> I intend to review the patch, benchmark it, and work on improvements if
>>>> need be, but that's no replacement for extensive community testing. This
>>>> patch doesn't stand a chance unless the latter has happened since we can't
>>>> risk breaking all the templates out there; the diff may look small, but
>>>> it's a significant change to the parsing algorithm.
>>>>
>>>> Decision making in Django goes by "rough consensus and working code".
>>>> The DEP process that Curtis started is the right way to work
>>>> constructively
>>>> on "rough consensus", but people who really want this feature need to play
>>>> their part in coming up with "working code" and the code needs to be well
>>>> tested to be considered as working.
>>>>
>>>> If you want this feature, please try the patch against your own
>>>> projects and report your findings. The DEP is also awaiting community
>>>> feedback.
>>>>
>>>> --
>>>> Loic
>>>>
>>>>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/739652d9-9d75-4789-8af4-5e12ffe1189d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
