On Wed, 2007-09-12 at 23:10 +0200, Tomas Kopecek wrote:
> Hi,
> I've implemented blocktrans in slightly different syntactical/semantical
> manner. Look at the following examples:
>
> {% blocktrans %}
> text {{var}}
> {{var|filter}}
> {% endblocktrans %}
>
> and plural variant:
>
> {% blocktrans count any_string|length as count %}
> singular variant {{count}}
> {% plural %}
> plural variant {{count|intcomma}}
> {% endblocktrans %}
>
> Briefly it means, that blocktrans accept _only_ 'count var as var_name'
> clause and does not need to declare block variables. Inside block is
> allowed anything, what is allowed in other blocks. So you can use any
> number of filters.
The standard argument against allowing arbitrary constructs inside the
translation block (things like {{var|filter}}) is that translators have
to type that string *exactly* into their translation in order for it to
appear. Since those strings can get quite complex, it's putting a burden
on translators that can be avoided by only allowing simple variables or
aliases in there. Basically, it's a way to reduce errors.
I'm not in favour of allowing more complex stuff inside for that reason.
I don't understand how plural is meant to decide *what* is the thing to
use when deciding if something is plural. Remember that there can be
multiple aliases in a blocktrans block. Unless I'm missing something
(quite possible), it looks like this only works when you have a single
alias in there. Is that correct?
We do need to work out some ways of allowing plural forms a bit more
easily. There was a discussion on this list a few months back where some
people suggested some alternatives, but nothing really pretty fell out,
so there's still work to be done there. However, I'm not sure this is a
solution, either, since it's a bit restrictive.
Regards,
Malcolm
--
Why be difficult when, with a little bit of effort, you could be
impossible.
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 django-developers@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
