hugo wrote:
> If people want translated modules, they need to provide translation
> hooks. The only way out would be to do model introspection additionally
> to the xgettext run - but that's problematic, too. Because you can
> only introspect models that are loaded. But if I for example want to
> create translations, I might just not have a installed and _running_
> django, I might just have a checkout of the subversion tree. So
> introspection is out, too.
I wouldn't say that this totally disqualifies it. If there is really a
big use case for people translating without installing django (which I
find kind of unlikely), a translation bundle can be created with the
extracted po files. This could even be automated as an svn checkin
trigger, so it automatically updates the downloadable translation bundle
with every checkin to svn or on a periodic basis.
> The main problem here is, I need to be able to pull out all translation
> hooks by just inspecting the sourcecode. And so I need explicit and
> unambiguous markers.
>
>
>>5. Similarly, I don't like the changes to the template code.
>
>
> But then there are still the problems about what to do with the inner
> block and possible block tags that are in there. The behaviour of the
> translate tag would be weirdly different from other tags: it wouldn't
> run it's inner nodelists through the template engine, but would first
> pull them together into a string, run that string through the
> translation engine and then reparses the resulting string and run
> _that_ through the template engine. Doesn't sound like an afternoon
> project ;-)
So the way to do this a bit less inefficiently is to have a keyword
argument to parse_until that prevents it from creating the blocktags in
the first place. Instead it just TemplateSyntaxErrors on anything but
plural or endtranslate, and rather than creating variable nodes it
creates the whole thing as a % formattable python string.
Then the xgettext extension can go around the template collecting these
up into a .po file which is the same format as standard python .pos. So
the translaters lose no functionality that normally exists for python pos.
What is different is the variable tags: they can't have filters in them
inside the translate tag.
Thats why I suggest something like:
{%translate file|length as l, file.name|capfirst as name %}
All the things that need a filter applied to them are provided initially.
I agree that the translate tag would act differently than all the other
block tags. Maybe for that reason new markers would be reasonable.
PS The keyword argument should probably be an instance of a class
implementing a certain set of methods. If defined properly, this would
also make your elif tag easily done ;-)
