Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#14801 closed (wontfix)

Support for string methods with lazy translations

Reported by: Torsten Bronger Owned by: nobody
Component: Internationalization Version: 1.2
Severity: Keywords:
Cc: bronger@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


Currently, .lower(), .upper(), .format() etc return unicode objects when being called with a lazy translation string. That's a pitty because this way, translators are forced to translate redundant text like "Blog entry"/"blog entry" or "setup 1 operator"/"setup 2 operator". Please implement at least lower, upper, capitalize, and format for lazy translations.

Change History (4)

comment:1 Changed 6 years ago by Łukasz Rekucki

Component: TranslationsInternationalization
Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

As for .format(), see #14174 - it's generally the same problem.

Also, can you clarify a bit more. First you complain about about _("Blog entry").lower() returning unicode. You also complain that this requires having a translation for "blog entry", which isn't true. Unless you are trying to do _("Blog entry".lower()), but then it has nothing to do with the proxy object returning unicode. Or I misread something...

comment:2 Changed 6 years ago by Torsten Bronger

In some places, I need "Blog entry" being translated, in others, "blog entry". Currently, my translators must translate both explicitly. It would be nice if they needed to translate only one of both, and I could write:

blog_entry = forms.CharField(label=_(u"blog entry").capitalize(), max_length=4)

comment:3 Changed 6 years ago by Russell Keith-Magee

Resolution: wontfix
Status: newclosed

I might be missing something here, but doesn't seem like something that is in Django's court. Django just uses GNU gettext for translations. There's a bunch of wrappers around the outside to enable and disable various translation contexts, but the core translation calls (gettext / _()) are proxied directly to gettext. lower/upper etc aren't features exposed by gettext, so they're not features exposed by Django, either.

There's also the issue of what "Upper" means; in a raw python string, "foo".upper() -> "FOO", not "Foo". "foo".capitalize() -> "Foo" but full capitalization rules are locale specific, and aren't even implemented consistently for English.

Marking wontfix, since this appears to be somewhere between an intractable problem and a problem that isn't Django's domain.

comment:4 Changed 6 years ago by Torsten Bronger

Actually it's about applying transformations to a lazy object rather than gettext. I solve this problem currently like this:

def format_lazy(string, *args, **kwargs):
    return string.format(*args, **kwargs)
format_lazy = allow_lazy(format_lazy, unicode)

(BTW, it would be nice if you could use allow_lazy as a Python decorator.)

and then in

    class Meta:
        verbose_name = format_lazy(_(u"Raman {apparatus_number} measurement"), apparatus_number=1)

I found allow_lazy after I had wrote this issue report, which turns it into an enhancement request because I'd still prefer

    class Meta:
        verbose_name = _(u"Raman {apparatus_number} measurement").format(apparatus_number=1)

i.e., if the lazy strings would implement some of the string methods.

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