Opened 7 years ago

Closed 4 years ago

#6272 closed New feature (wontfix)

django.utils.translation.ugettext_lazy needs __add__ support

Reported by: Tai Lee <real.human@…> Owned by: nobody
Component: Core (Other) Version: master
Severity: Normal Keywords: ugettext_lazy unicode concatenate
Cc: real.human@… Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by ramiro)

The model fields defined in django.contrib.auth.models (and I assume other parts of django) use django.utils.translation.ugettext_lazy to specify the label (or another property from which the label is derived). The form field objects generated by form_for_* and ModelForm on these models return a django.utils.functional.__proxy__ object instead of a unicode object where ugettex_lazy is not used.

I have a few helper template tags which are trying to alter the form field label with a concatenation, which is throwing an error for form_for_model and ModelForm forms for django.contrib.auth.models.User (and other django/contrib models that use ugettext_lazy).

As the documentation doesn't recommend or require the use of ugettext_lazy in it's examples and tutorials when defining models and forms, this inconsistent behaviour seems less than ideal. If django.utils.functional.__proxy__ could be changed with an __add__ (and other?) methods to behave more like a string/unicode object, that would be good?

Change History (5)

comment:1 Changed 7 years ago by Simon Greenhill <dev@…>

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

comment:2 Changed 7 years ago by ramiro

  • Description modified (diff)

comment:3 in reply to: ↑ description Changed 6 years ago by ramiro

Replying to Tai Lee <real.human@mrmachine.net>:

As the documentation doesn't recommend or require the use of ugettext_lazy in it's examples and tutorials when defining models and forms

This is true, but for the case of models, this is suggested in the I18N docs: http://docs.djangoproject.com/en/dev/topics/i18n/#lazy-translation and further down there is a section devoted to working with this kind of objects (and it included using them in combination with string/unicode objects): http://docs.djangoproject.com/en/dev/topics/i18n/#working-with-lazy-translation-objects.

comment:4 Changed 4 years ago by julien

  • Severity set to Normal
  • Type set to New feature

comment:5 Changed 4 years ago by carljm

  • Easy pickings unset
  • Resolution set to wontfix
  • Status changed from new to closed
  • UI/UX unset

Many magic methods aren't supported by lazy proxies - the solution is if you have something that might be a lazy proxy, coerce it to what you need so you know what you're dealing with. "Blah" + unicode(foo) is not significantly more onerous than "Blah" + foo.

(Also, it appears that foo + "blah", where foo is a lazy proxy, works fine. It's the other direction that doesn't seem to work, so it's really __radd__ that would be needed.)

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