Opened 9 years ago

Closed 9 years ago

Last modified 6 years ago

#3804 closed (invalid)

Filter for translation instead of block

Reported by: boxed@… Owned by: hugo
Component: Internationalization Version: master
Severity: Keywords:
Cc: waylan@… Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


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.

Change History (11)

comment:1 Changed 9 years ago by Simon G. <dev@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

comment:2 Changed 9 years ago by mtredinnick

  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:3 Changed 9 years ago by mtredinnick

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.

comment:4 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by mtredinnick

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.

comment:6 Changed 9 years ago by 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.

comment:7 Changed 9 years ago by boxed@…

  • Component changed from Internationalization to Documentation

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

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.

comment:8 Changed 9 years ago by adrian

  • Component changed from Documentation to Internationalization

comment:9 Changed 9 years ago by anonymous


comment:10 Changed 9 years ago by mtredinnick

  • Resolution set to invalid
  • Status changed from reopened to closed

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

comment:11 Changed 6 years ago by mark0978

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

Note: See TracTickets for help on using tickets.
Back to Top