i18n missing feature ... continued (proposed solution for the upcoming sprint)
alain D.
Following up on a previous discussion about an important but
complex i18n missing feature :
http://groups.google.com/group/django-developers/browse_thread/thread/c88b582fa4764aaa
I've been thinking over and over about the problem and came up with
an idea of a proposed syntax that I want to submit to the django
community. Maybe the sprint coming up could be a chance for me to
implement it under the wise patronage of a senior django fellow.
Let say I want to print this (taken from django i18n manual page) :
{% blocktrans with value|filter as number %}This will have
{{ number }} items inside.{% endblocktrans %}
But I want to have the words "{{ value }} items" to be a link on
something (another page).
Here is the proposed syntax (this may sound complex but I think it
adresses a pretty complex [but frequent] problem ).
{% blocktrans %}This will have
{% insideblocktrans as link_items %}
<a href="{% url another-page %}">
{% blocktrans with value|filter as number %}{{ number }}
items{% endblocktrans %}
</a>
{% endinsideblocktrans %}
inside.
{% endblocktrans %}
This way, the string to translate would be :
- "This will have %(link_items)s inside"
- "%(number)s items"
Mark Green
I generally agree with your approach to the problem but the syntax
you propose is, sorry, horrible. It counts no less than 8 lines
with obscure markup, only to mark a oneliner for translation!
How about a less headache-inducing syntax, I'm thinking
along the lines of:
---
Template:
-
{% blocktrans with value|filter as number %}
This will have [[<a href="{% url %}">]]one item[[</a>]] inside
{% plural %}
This will have [[<a href="{% url %}">]]%{number} items[[</a>]] inside
{% endblocktrans %}
-
Translation strings:
* This will have one item inside
* This will have %{number} items inside
Translated strings (english=>english for the sake of this example):
* This will have one item inside
* This will have %{0}%{number} items%{1} inside
---
Notes:
* I'm not sure if and to what extent this may clash with existing
i18n syntax or semantics. I hope it doesn't contain fundamental
problems that cannot be solved with minor modification. Ofcourse,
turning double square brackets into a magic token presents a
problem in itself but that can be solved in the usual ways;
either with escaping or by equipping the blocktrans-tag with
a boolean "i really need verbatim double-square-brackets
in here"-parameter. Last not least the square brackets
can obviously be anything. Square, curly, dots,
dashes.. whatever.
* The square brackets basically exclude parts of the string
from translation. Other template substition (such as {% url %})
should still be performed on the excluded parts.
The so excluded parts are then, after translating the
remaining string, re-substituted into that, at the
marker positions (%{0}, %{1} etc.), in order of
appearance.
sorry, i hope that last sentence is somewhat legible.
i kinda struggled here! ;)
* Parsing of this syntax should be fairly trivial.
Both in code and (most importantly!) for the human
reading the template.
* As a pleasant side effect this can still function properly
even in the case when no translated string is found and django
has to fall back to the translation token itself.
* I think this should deal naturally with variations in
sentence structure.
* This obviously ties the translation strings very closely
to the order of "[[..]]"-tokens in the template markup.
This could be avoided by offering named tokens and there
may indeed be use-cases for that. Very wierd use-cases I guess,
but still use-cases...
Well, I deliberately left it out above to keep the example simple.
* For kicks, one could think about translating even the "excluded"
strings separately. Although I can't imagine a use-case
for this that couldn't be solved in a better way...
Just as the other participants in the thread you cited I'd be very
glad if this, or something similar, could get into django asap.
And ofcourse I'm open to all comments and discussion.
(does this even make sense or did I manage to totally
mess up something critical...)
-mark
Mark Green
On Sun, 2007-11-18 at 04:33 +0100, Mark Green wrote:
> ---
>
> Template:
>
> -
> {% blocktrans with value|filter as number %}
> This will have [[<a href="{% url %}">]]one item[[</a>]] inside
> {% plural %}
> This will have [[<a href="{% url %}">]]%{number} items[[</a>]] inside
> {% endblocktrans %}
> -
>
> Translation strings:
>
> * This will have one item inside
> * This will have %{number} items inside
>
> Translated strings (english=>english for the sake of this example):
>
> * This will have one item inside
> * This will have %{0}%{number} items%{1} inside
This is wrong, the first translated string should read:
* This will have %{0}one item%{1} inside
Ofcourse the original string would still have worked
but there would be no hyperlink.
-mark
alain D.
I agree that my proposed syntax was a little bit horrible ... but I
really wonder if it can be different.
Your syntax is interesting but :
- I'm not sure it's really "djangoic" in the sense that it introduce
a new way to declare markup '[[' and ']]'
- the other problem I see is that it exposes the translator to the
"remains" of the markup because of the %{0} and %{1} in the string to
translate... the whole idea is to prevent the translator (who only
wants do deal with translation) from seeing anything of this ...
Actually, my syntax was more of less adapted from the zope/plone
syntax : see my original posting for a complete example
http://groups.google.com/group/django-developers/browse_thread/thread/c88b582fa4764aaa
Thanks for starting the conversation anyway ...
-alan
Jacob Kaplan-Moss
> {% blocktrans with value|filter as number %}
> This will have [[<a href="{% url %}">]]one item[[</a>]] inside
I stopped reading here. Anything that involves adding more syntax to
the template language gets a reflexive -1 from me. Our goal is to keep
the syntax as simple as possible.
Jacob
Mark Green
Hi Jacob,
replying to you first because your comment is shorter.
As explained in the mail my primary goal was the same
as yours, to make the syntax as simple (and readable)
as possible. Maybe I'm just coming in from a different angle...
It's just an idea and it may very well have problems.
But dismissing the syntax as more complex when it solves
the task with 8 additional chars where the alternative
takes 8 additional *lines* doesn't sound fair to me.
Yes it's syntatic sugar but in my eye the added
"complexity" is so minor in contrast to the
better readability.
Well, I'll continue this in my reply to Alain
who raised similar concerns.
-mark
Mark Green
On Sun, 2007-11-18 at 02:01 -0800, alain D. wrote:
> Hi,
>
> I agree that my proposed syntax was a little bit horrible ... but I
> really wonder if it can be different.
>
> Your syntax is interesting but :
> - I'm not sure it's really "djangoic" in the sense that it introduce
> a new way to declare markup '[[' and ']]'
Well, as said, the brackets could be anything.
Could be {{ }} or %{ } if those fit better. But yes, it is a
new way to declare markup, if only inside a "blocktrans"-tag.
My primary goal was to preserve (my) sanity by keeping the template
code readable. Just imagine your example in everyday use. It may
be more "djangoic" but it feels like dropping a scatter-bomb
into the template to me...
> - the other problem I see is that it exposes the translator to the
> "remains" of the markup because of the %{0} and %{1} in the string to
> translate... the whole idea is to prevent the translator (who only
> wants do deal with translation) from seeing anything of this ...
Yes, you have a strong point there.
I'd argue that it's worth the tradeoff but others
will ofcourse disagree.
My rationale is that translators would usually be smart
enough to understand and apply the concept after a quick
briefing. It's not like you throw a .po file at your
newly hired translator without further notice.
In any case they already need to know what ${variable}
tokens are. I think the step up to ${0}, ${1}, .. is merely
a matter of explaining "please insert them in the
equivalent spots as in the translation source".
One could also add some simple validation code that
raises a meaningful error message when the expected
tokens are missing in a translated string.
But honestly, I cannot think of a real-world example where
the token transfer could get so complicated as to raise
serious problems...
Furthermore I'm not entirely sure that the alternative is
without flaws either. I'm not a linguist but I wonder if arbitrarily
splitting up the strings and translating the parts independently
may introduce problems of its own, in some languages?
> Actually, my syntax was more of less adapted from the zope/plone
> syntax : see my original posting for a complete example
> http://groups.google.com/group/django-developers/browse_thread/thread/c88b582fa4764aaa
Saw it and well, didn't impress me. It's the java way and some
people seem to like it, just as some people like java. I'm not
one of these people, that's why I'm using django. :-)
I jumped in so decidedly because I wouldn't like to see django
going the way of most java frameworks in terms of verbosity here.
Keeping template complexity down seems more important to me
than saving my translators one trivial extra-step. YMMV.
-mark
Malcolm Tredinnick
On Mon, 2007-11-19 at 00:22 +0100, Mark Green wrote:
>
> On Sun, 2007-11-18 at 02:01 -0800, alain D. wrote:
> > Your syntax is interesting but :
> > - I'm not sure it's really "djangoic" in the sense that it introduce
> > a new way to declare markup '[[' and ']]'
>
> Well, as said, the brackets could be anything.
> Could be {{ }} or %{ } if those fit better. But yes, it is a
> new way to declare markup, if only inside a "blocktrans"-tag.
A lot of your post is still implicitly trying to justify your new syntax
choice. Find another way. Your proposed syntax doesn't look like Django.
I'm also not in love with Alain's proposed syntax, which is why I
haven't responded so far in this thread. We still need some design work
here. I have a gut feeling that something based around {% with %} --
making some extensions to that tag -- should make this sort of thing
possible. I think Alain's on the right track, but the syntax needs work.
Some guiding principles (that everything else follows already):
- The portions that are being abstracted out should be
represented as Django template variables ("{{ foo }}") if we
need to refer to them in templates (so far that hasn't come up,
but it might and I'm trying to be comprehensive).
- Pulling out portions for special treatment (such as URLs)
should be done with template tags. That could mean either block
tags (things with beginning and end markers) or inline tags that
take the critical information as arguments.
- The msgids in the PO files must look like normal python
strings. So the replacement text must look like "%(foo)s". This
is really important because it means that "msgfmt
--check-format" (which is what our compile-messages.py runs)
will pick up errors such as omitting any required parameters.
Also the Python code that does the template rendering can do
things like
ugettext(msgid) % value_dict
to fill in the blanks because it's already in the right format
for Python to parse.
Using these guidelines, the resulting template will still look like a
Django template so things will look "natural". Syntax highlighting
plugins for various editors will still highlight the Django code
correctly.
However there's also the aim that templates should still be basically
readable. The drawback with Alain's original proposal is that there's
more markup than content and it's not really easy to scan your eye over
even a complete sentence without having to mentally parse the template
language. Compare this with the current blocktrans tag: everything
vaguely complicated is pulled out initially into the blocktrans tag ("{%
blocktrans with foo|bar as baz %}"). The translated text is left free
from translation tags with the odd reference to {{ baz }} inside, making
it fairly readable for the template author, again.
That's why I'm wondering if we can come up with an extension of the
"with" tag or something similar to pull all the necessary bits and
pieces out front somehow and get it out of the way of the actual
content.
[...]
> Furthermore I'm not entirely sure that the alternative is
> without flaws either. I'm not a linguist but I wonder if arbitrarily
> splitting up the strings and translating the parts independently
> may introduce problems of its own, in some languages?
Absolutely, for the fully general case. Almost everything you can
imagine will go wrong when doing localisation does go wrong. Even
relatively simple things like dates are unbelievably difficult to get
right in internationalisation without driving the original programmers
insane with awkward constructs (we haven't completely solved that one in
Django yet). However, in practice, you don't need to handle arbitrary
breakup and recombinations. The splitting is done by a human, normally
at the word level. If splitting multiple words at once, translators
might sometimes come back and say "this doesn't work in language XYZ"
and then you either have to change the original markup (possibly
including the markup in the msgid so that the translators can work at a
lower level) or make do with awkward phrasing in some locales.
I think it's great that this conversation is happening again. We haven't
found the right markup yet, but the problem seems to be understood by a
couple of people at least. Keep talking about it and coming up with
ideas.
Malcolm
--
Plan to be spontaneous - tomorrow.
http://www.pointy-stick.com/blog/
Mark Green
>
> On Mon, 2007-11-19 at 00:22 +0100, Mark Green wrote:
> >
> > On Sun, 2007-11-18 at 02:01 -0800, alain D. wrote:
> [...]
> > > Your syntax is interesting but :
> > > - I'm not sure it's really "djangoic" in the sense that it introduce
> > > a new way to declare markup '[[' and ']]'
> >
> > Well, as said, the brackets could be anything.
> > Could be {{ }} or %{ } if those fit better. But yes, it is a
> > new way to declare markup, if only inside a "blocktrans"-tag.
>
> A lot of your post is still implicitly trying to justify your new syntax
> choice. Find another way. Your proposed syntax doesn't look like Django.
Well, yes. Explicitly even ;-)
I still don't fully agree that allowing some (optional!) magic
syntax inside a "{% blocktrans %}" would be such a bad thing.
But if that's the opinion of the powers who drive django forward
then I certainly won't start a djihad over it. ;-)
And I must admit that I'm not happy with the stupid
%{0} markers either - but they were part of the package...
> I'm also not in love with Alain's proposed syntax, which is why I
> haven't responded so far in this thread. We still need some design work
> here. I have a gut feeling that something based around {% with %} --
> making some extensions to that tag -- should make this sort of thing
> possible. I think Alain's on the right track, but the syntax needs work.
>
> Some guiding principles (that everything else follows already):
>
> - The portions that are being abstracted out should be
> represented as Django template variables ("{{ foo }}") if we
> need to refer to them in templates (so far that hasn't come up,
> but it might and I'm trying to be comprehensive).
>
> - Pulling out portions for special treatment (such as URLs)
> should be done with template tags. That could mean either block
> tags (things with beginning and end markers) or inline tags that
> take the critical information as arguments.
These two bullets give me headache.
I fiddled a lot with this but using full blown tags has always
killed readability for me. Littering the HTML with "{% blocktrans %}" or
even short "{%btr%}"-stuff just didn't work out. It basically began
to hurt once you couldn't fit a single line into a single line anymore.
> [...]
> That's why I'm wondering if we can come up with an extension of the
> "with" tag or something similar to pull all the necessary bits and
> pieces out front somehow and get it out of the way of the actual
> content.
I thought about that but it lead me to my special syntax
because, well, look at the options:
---
{% blocktrans with value|filter as number
exclude '<a href="%{url}">' and '</a>'
%}
This will have <a href="%{url}">%{number}s items</a> inside.
{% endblocktrans %}
---
or:
---
{% blocktrans with ... '<a href="%{url}>" as 0 and '</a>' as 1 %}
This will have %{0}s%{number}s items%{1}s inside.
{% endblocktrans %}
---
Nothing to write home about.
> [...]
> > Furthermore I'm not entirely sure that the alternative is
> > without flaws either. I'm not a linguist but I wonder if arbitrarily
> > splitting up the strings and translating the parts independently
> > may introduce problems of its own, in some languages?
>
> Absolutely, for the fully general case. Almost everything you can
> imagine will go wrong when doing localisation does go wrong. Even
> relatively simple things like dates are unbelievably difficult to get
> right in internationalisation without driving the original programmers
> insane with awkward constructs (we haven't completely solved that one in
> Django yet). However, in practice, you don't need to handle arbitrary
> breakup and recombinations. The splitting is done by a human, normally
> at the word level. If splitting multiple words at once, translators
> might sometimes come back and say "this doesn't work in language XYZ"
> and then you either have to change the original markup (possibly
> including the markup in the msgid so that the translators can work at a
> lower level) or make do with awkward phrasing in some locales.
Agree'd. Unless there are some very strange cases then I guess Alain's
way of splitting up the string is really the better. Which leaves us
at finding a syntax that's somehow readable *and* djangoic.
Urgh. :)
> I think it's great that this conversation is happening again. We haven't
> found the right markup yet, but the problem seems to be understood by a
> couple of people at least. Keep talking about it and coming up with
> ideas.
I fear I'm reaching the bounds of my creativity.
Nonetheless I still think this is a problem very worth solving.
So if anyone can come up with anything feasible, please tune in!
-mark
Wolfram Kriesing
I was following this thread, since I also think a solution is needed
here, badly!
I think Alain's initial solution is the best until now, and closest to
what is needed, but true, its tooo complex.
I don't have a final solution but may be one step ahead ...
I know the big problem here is to make simple syntax for a complex
topic and possibly some special cases.
Imho blocktrans should allow tags etc inside, i am always again
struggling with this ugly "blocktrans with" syntax, its over complex,
hard to maintain and also pretty bad to read (as long as I don't have
syntax highlighting for django templates :-))
The problem
------------------
I want the following text to be i18n'ed
"Received on 24. Aug. 2007 from Alex (married since 1992)"
But all usernames in our system are links that are generated with a
tag, like so:
<a href="{{ user.url }}" {% userlink user.id %}>{{ user.name }}<a/>
You can see the difficulty coming :-), actually just as discussed in this thread
So actually I would need to put my code to be translated like this
inside a blocktrans:
{% blocktrans %}
Received on {{ message.created|date }}
from
<a href="{{ user.url }}" {% userlink user.id %}>{{ user.name }}
(married since {{ user.married|year }})<a/>
{% endblocktrans %}
Lets make it work
-------------------------
* Step 1 to a nicer blocktrans might be to replace the "with" (that is
currently still needed) by a nicer _optional_ syntax, like this
{% blocktrans %}
Received on {{ message.created|date as date }}
from
<a href="{{ user.url }}" {% userlink user.id %}>
{{ user.name as username }}
(married since {{ user.married|year as married_since }})
<a/>
{% endblocktrans %}
this names the variables in the place where they get used, so in the
translation string they appear named
* Step 2, may be encapsulate the stuff you don't want the translators
to touch, the same way variables get used
{% blocktrans %}
Received on {{ message.created|date as date }}
from
{{ '<a href="{{ user.url }}" {% userlink user.id %}>' as link_open }}
{{ user.name as username }}
(married since {{ user.married|year as married_since }})
{{ '<a/>' as link_close }}
{% endblocktrans %}
Finally the translatable string will be:
Received on %(date)s
from
%(link_open)s
%(username)s
(married since %(married_since)s)
%(link_close)s
PROs, the advantage in this, imho
1) all variables and blocks stay in the position
2) the template stays readable, since the order of content remains
3) you just need to apply "as" keyword behind all kinds of
4) It keeps the sentence intact, the nesting inside can be as deep as
it wants, the semantics of the string can stay intact and are
maintained by the translator completely
5) translation is not maintained in chunks, as Alain's first solution
unfortunately would
CONs
1) you have logic in the translation string, since the a-href tag got
split up and if the translator puts them wrong or forgets i.e. the
link_close the entire template might be screwed - BUT see PRO 4
So actually no real solution either, but I hope this discussion comes
to a solution.
my 2 cents
Wolfram
--
cu
Wolfram
alain D.
First, I'd like to thank all people involved in this discussion for
the quality of the insightful remarks and reactions they made on my
first proposed syntax.
I'm trying to imagine improvements to my proposed syntax based on
the comments here ... unfortunately, I always find good reasons not to
change the syntax ... here is the overview of my thoughts about that,
referring to the various remarks made so far.
- regarding the problem that the translation is maintained in
chucks : if not then there is the presence of logic in the translation
string, which is not possible I think. If you agree on that, it means
that the translation _has_ to be maintained in chucks
- regarding the fact that the syntax is too complex, I think this is
due to the new tag : {% insideblocktrans %} in my syntax. The problem
is that, even if my example uses a link, one could think of many other
ways to use it : for instance to simply 'highlight' part of a
dynamically translated string (with <strong> for instance) so I see a
necessity to let the user have full control of what is inside the
logic that will be sort of 'injected' into the translated parts.
That's why I can't manage to see any way to use the {% with %} tag as
suggested ...
-alain
Wolfram Kriesing
> chucks : if not then there is the presence of logic in the translation
> string, which is not possible I think. If you agree on that, it means
> that the translation _has_ to be maintained in chucks
This nails the main problem imho.
That is simply the decision that has to be taken.
And for the sake of semantics and allowing _better_ translations, by
not tearing up strings that logically belong together I think this
logic in the template is what you have to sacrify.
May be some post processing or a tool can ensure the correctness of
the translation.
> - regarding the fact that the syntax is too complex, I think this is
> due to the new tag : {% insideblocktrans %} in my syntax. The problem
> is that, even if my example uses a link, one could think of many other
> ways to use it : for instance to simply 'highlight' part of a
> dynamically translated string (with <strong> for instance) so I see a
> necessity to let the user have full control of what is inside the
> logic that will be sort of 'injected' into the translated parts.
> That's why I can't manage to see any way to use the {% with %} tag as
> suggested ...
>
> -alain
>
>
> >
>
--
cu
Wolfram
Mark Green
> [...]
> * Step 2, may be encapsulate the stuff you don't want the translators
> to touch, the same way variables get used
> {% blocktrans %}
> Received on {{ message.created|date as date }}
> from
> {{ '<a href="{{ user.url }}" {% userlink user.id %}>' as link_open }}
> {{ user.name as username }}
> (married since {{ user.married|year as married_since }})
> {{ '<a/>' as link_close }}
> {% endblocktrans %}
>
> Finally the translatable string will be:
>
> Received on %(date)s
> from
> %(link_open)s
> %(username)s
> (married since %(married_since)s)
> %(link_close)s
>
I'm very +1 on this. Probably not too surprising as it's
quite similar to what I proposed. :-)
> PROs, the advantage in this, imho
> 1) all variables and blocks stay in the position
> 2) the template stays readable, since the order of content remains
> 3) you just need to apply "as" keyword behind all kinds of
> 4) It keeps the sentence intact, the nesting inside can be as deep as
> it wants, the semantics of the string can stay intact and are
> maintained by the translator completely
> 5) translation is not maintained in chunks, as Alain's first solution
> unfortunately would
>
> CONs
> 1) you have logic in the translation string, since the a-href tag got
> split up and if the translator puts them wrong or forgets i.e. the
> link_close the entire template might be screwed - BUT see PRO 4
>
> So actually no real solution either, but I hope this discussion comes
> to a solution.
I fully agree. As stated earlier I think keeping the template readable
is much more important than saving the translator a (very minor!)
extra-step.
More arguments (some of them are just yours, repeated in
different words):
* The extra-work (or "extra knowledge") for the translator is
really minimal. The translator, unless familar with the templates,
is already working with a blackbox anyways. He already needs to know
that there is a token "%(username)s" and to put it in the right place.
The additional mental work of realizing that some parts need to be
wrapped up in two other tokens would be an absolute no-brainer for
any of the translators that I have worked with in the past...
* It should be easy to let django verify the translations
and warn about suspicious entries (i.e. where tokens are missing).
* Translation usually happens only once while a template needs to
be maintained (and will often undergo changes) over a long time.
Another hint that template readability should take precedence.
* The translation string doesn't need to be broken up.
Treating it as one string is definately preferable ("WYSIWYG").
* I like how Wolfram's syntax still *allows* to break up and re-use
parts of the string when appropiate. There is no reason that all
tokens have to be defined inline in the template. Some could just
be references to existing tokens. Furthermore his syntax could
even gracefully degrade to my syntax for people who don't need
named tokens. Leave out the "'"s and the 'as identifier' and you
end up exactly there (only using curly brackets instead of square).
I honestly think we have the syntax part nailed by now.
There is no way to make it any more readable without sacrifying
functionality. If anyone thinks otherwise: Please pick up
the challenge! :-)
-mark
Will Hardy
This is a really impressive solution. An extra idea:
adding a {% as variable_name %}{% endas %} or {% as variable %}{%
endas variable_name %}
Example:
{% blocktrans %}
Received on {{ message.created|date as date }}
from
{% as link_open %}<a href="{{ user.url }}" {% userlink user.id
%}>{% endas link_open }}
{{ user.name as username }}
(married since {{ user.married|year as married_since }})
{{ '<a/>' as link_close }}
{% endblocktrans %}
PROS:
* keep things clean if the tag code gets complicated, long or quotey.
* all the same benefits that """ provides in python
CON:
* adding unnecessary tags is a distraction
Cheers,
--
Will Hardy
m: +49 177 392 89 26
e: wi...@willhardy.com.au
w: http://www.willhardy.com.au
alain D.
Trying to sum up the discussions so far I would say that Wolfram's
syntax seems to be the preferred one : i.e. letting the logic go into
the translated string but keeping the strings to translate in one bit.
I wasn't that in favor of this solution at first but I confess I'm
much more convinced now.
I must say that I like that I like Will Hardy's proposition because
it avoid the "undjangoic" mixing of tags {{ '<a
href="{{ user.url }}" {% userlink user.id %}>' as link_open }} that
was present in Wolfram's syntax (i.e. '{{' inside '{{')
I would just replace {% as link_open %} [...] {% endas link_open %}
by {% as link_open %} [...] {% endas %} and not allow {{ '<a/>' as
link_close }} as proposed by Will Hardy (to avoid many different
syntaxes for the same thing)
So this would make the syntax like this :
{% blocktrans with message.created|date as date and user.married|year
as married_since and user.name as username %}
Received on {{ date }}
from
{% as link_open %}<a href="{% url userlink user.id %}">{% endas %}
{{ username }} (married since {{ married_since }})
{% as link_close %}<a/>{% endas %}
{% endblocktrans %}
Then the string to translated would be :
What do you say ?
-ad
Wolfram Kriesing
Wolfram
--
cu
Wolfram
klipstein
Wolfram Kriesing
{% blocktrans %}
Received on {{ message.created|date as date }}
...
this removes the "with-as" stuff from the blocktrans completely
to increase the readablitiy of the entire block and not squeeze all
the variables in at the opening blocktrans
wolfram
--
cu
Wolfram
Wolfram Kriesing
is there some kind of follow up to this topic
or is it simply dead?
wolfram
--
cu
Wolfram