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