On Mon, 2007-11-19 at 19:11 +0100, Wolfram Kriesing wrote:
> [...]
> * 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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
