Filter for translation instead of block

[boxed@…]

I suggest using filters for translation of strings instead of special blocks. This is much more flexible, so instead of {% filter title %}{% trans "add message" %}{% endfilter %} you can get {{ "add message"|trans|title }} The filter to do this is really simple:

def trans(value):
    return translation.gettext(value)
register.filter('trans', trans)

The make-messages tool needs to be updated to handle this though.

[Malcolm Tredinnick]

This is only a space-saver in the relatively rare case when you want to translate a single variable's content. Translation strings should normally be extracted in blocks of text so that translators have some context to work with and because translations are not made on a word-by-word basis. Working on a block basis for internationalising content is the right thing to do here. I don't see any value in also including this filter.

If you have a more realistic example that requires this that doesn't make things any harder for translators, please bring it up on the django-developers list where we can discuss it. We're not going to include it as "another way to do something", though -- it would have to fix a problem that isn't already solved.

[Malcolm Tredinnick]

Whoops... I jumped the gun here. My brain read "blocktrans" everywhere. Moving back to "design decision needed" because I want to think about it some more.

[boxed@…]

Well, I'm gonna comment anyhow :P The problem I keep getting is that I get link texts and titles for pages that are essentially the same string, but with different cases, and it doesn't map cleanly across languages either.. in english there's title case, which doesn't exist in swedish so there "Add Message" and "Add message" becomes the same string. It makes more sense in these cases to use my suggestion and user |capfirst for links and |title for titles, and then have the actual handling of these differences in the i18n layer.

[Malcolm Tredinnick]

We can't have l10n-aware versions of filters like "title" -- it would be ridiculously large amounts of work and not even necessarily possible to get correct. That is why I want to think about this, because I don't want us to encourage false expectations.

[boxed@…]

Well the point of my thinking is to be able to have some kind of declarative process, because there are many cases where the one single string or word is the same in English, but needs to be two different strings in another language for example.

[boxed@…]

Well it turns out that there is support for {{ _("some string") }} which does exactly what I mean AND is supported by make-messages.py.

To reflect this I have changed the component of this issue to "documentation", since all that was really needed was for this _() syntax to be said to be supported in the templates.

[anonymous]

kjk

[Malcolm Tredinnick]

Looks like this is a non-issue, since the _() support in templates is already in the i18n docs.

[Mark Jones]

I'd like to add this link to some documentation that covers how to use this with other filters

​http://docs.djangoproject.com/en/dev/topics/i18n/internationalization/#other-tags