Code

Opened 3 years ago

Closed 3 years ago

#15767 closed Bug (invalid)

DecimalField is not aware of locale (in admin)

Reported by: Semmel Owned by: nobody
Component: Forms Version: 1.3
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

We are using a German locale right now and noticed in the admin that DateField is locale-aware while the DecimalField is not. DateField displays the date using 'd.m.Y' while also accepting an input that way. For the DecimalField DECIMAL_SEPARATOR and THOUSAND_SEPARATOR need to be switched for display and input.

While looking at the code I noticed that there is indeed some code for a locale-aware display and input for DecimalField. There also is a variable localize that's always False. Is there a reason why this is disabled by default? How do I enable it?

Since parts of the admin are accessed by normal users and the only language is German so far, there has to be a way to change this for the admin.

Attachments (0)

Change History (4)

comment:1 Changed 3 years ago by carljm

  • Component changed from Uncategorized to Forms
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed
  • Type changed from Uncategorized to Bug

See http://docs.djangoproject.com/en/dev/topics/i18n/localization/#format-localization

Localization of form fields has to be explicitly enabled per-field; you can use a custom ModelForm and the form attribute of ModelAdmin to do this in the admin.

Please ask "how-to" type questions on the django-users mailing list or in IRC; file a ticket when you are certain that you have found a bug in Django.

comment:2 Changed 3 years ago by Semmel

  • Easy pickings unset
  • UI/UX unset

The documentation doesn't say anything about this problem - in fact it sounds like it should work as i expect it to work:

Django will also use localized formats when parsing data in forms.

Now this sounds like it should also work in admin. But i doesn't - and there's nothing in the admin docs about it.

And a custom ModelForm/ModelAdmin just won't cut it - i don't want to redefine my whole admin just because of some missing localization.

By the way: This is some real world problem. I have users that are just using the frontend with numbers like they're used to (because i've set localize to true). Now some of them are using the admin too and are complaining why they have to type in the same numbers using English formatting.

On a side note: I don't really understand why i have to explictly set localize when USE_L10N is already set to True. That doesn't make sense to me.

comment:3 Changed 3 years ago by Semmel

  • Resolution invalid deleted
  • Status changed from closed to reopened

I'll reopen this ticket because I still think it's a bug and it's really annoying especially for non-english users.

To summarize this in one sentence: There should be an easy way to allow localized input in the admin.

comment:4 Changed 3 years ago by aaugustin

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

You shouldn't re-open a ticket closed by a core developer — see the contribution guidelines at https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/:

Please don’t reverse a decision that has been made by a core developer. If you disagree with a decision that has been made, please post a message to django-developers.

Thanks.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.