Hi,
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
On Nov 19, 2007 2:59 AM, Mark Green <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-11-19 at 11:38 +1100, Malcolm Tredinnick wrote:
> >
> > 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
>
>
>
>
> >
>
--
cu
Wolfram
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
