#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: | no | UI/UX: | no |
Description
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 by , 14 years ago
Component: | Translations → Internationalization |
---|
comment:2 by , 14 years ago
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 by , 14 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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 by , 14 years ago
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 models.py:
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.
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...