Hi,
On Fri, 2007-11-16 at 02:11 -0800, alain D. wrote:
> Hi,
>
> 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"
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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
