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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
