Code

Opened 5 months ago

Last modified 2 months ago

#21544 new Bug

Problem with number format when not using L10N

Reported by: yceruto@… Owned by: Yonel Ceruto
Component: Utilities Version: master
Severity: Normal Keywords: number format
Cc: shai Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

My system at one point tries to display a number in a specific format, for which I use the "floatformat" filter.

My configuration in "settings.py" is:
USE_L10N = False
USE_THOUSAND_SEPARATOR = True
NUMBER_GROUPING = 3

The problem is that the "floatformat" filter uses the "format" utility and this in turn applies the grouping of thousands if L10N is true:

use_grouping = settings.USE_L10N and settings.USE_THOUSAND_SEPARATOR

From the "floatformat" filter I can not force the grouping of thousands, making it impossible to apply this option. Showing my number without the grouping of thousands.

Attachments (0)

Change History (11)

comment:1 Changed 5 months ago by claudep

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

A built-in filter will never allow the full flexibility of the internal formatting API. If you have specific needs, I'd suggest writing your own custom filter, or prepare the formatting of the float value in the view. If you think there might be an obvious way to allow that flexibility, reopen with a concrete suggestion or write the proposal to the django-developers mailing list.

comment:2 Changed 5 months ago by yceruto@…

My proposal is clear here https://github.com/django/django/pull/2015 and I see no reason to make a custom filter when I should show the grouping of thousands according to my configuration, thanks.

comment:3 Changed 5 months ago by yceruto@…

I want to use the grouping of thousands in my numeric formats, for which I use the "floatformat" filter.

My configuration in "settings.py" is:
USE_L10N = False
USE_THOUSAND_SEPARATOR = True
NUMBER_GROUPING = 3

Showing my numbers without the grouping of thousands.

When I check in depth the why, I realize that the grouping of thousands is subject to the value of the Variable settings.USE_L10N:

django/utils/numberformat.py:

def format (...):
...
use_grouping = settings.USE_L10N and settings.USE_THOUSAND_SEPARATOR

Think it would be correct to eliminate the constraint that prohibits the display grouping of thousands, if not L10N used?

comment:4 Changed 5 months ago by yceruto@…

  • Resolution wontfix deleted
  • Status changed from closed to new
  • Version changed from 1.6 to master

comment:5 Changed 5 months ago by yceruto@…

I think the configuration of the variable USE_L10N aims at in this case to determine the format of number and not condition the use of the grouping of thousands.

comment:6 Changed 4 months ago by claudep

The current behavior is documented:
When USE_L10N is set to True and if this is also set to True, Django will use the values of THOUSAND_SEPARATOR and NUMBER_GROUPING to format numbers.
https://docs.djangoproject.com/en/dev/ref/settings/#use-thousand-separator

If suddenly we change the rules, people might unexpectedly see thousands separators, for example in a section where they have temporarily disabled l10n. So the change you proposes is not applicable as is.

I'll let someone else decide if something should/could be done here or simply closed again.

comment:7 follow-up: Changed 4 months ago by yceruto@…

I do not understand why mention the word "unexpectedly"?

It is understood that if I have enabled the thousands separator USE_THOUSAND_SEPARATOR = True and NUMBER_GROUPING > 0 to display all numbers with the pattern:

#THOUSAND_SEPARATOR###DECIMAL_SEPARATOR##

If is enabled or not USE_L10N only determines the "values" ​​of DECIMAL_SEPARATOR and THOUSAND_SEPARATOR according to the current locate set to LANGUAGE_CODE, but if USE_L10N = False then is display the default values.

Why USE_L10N determining use of thousands separator?

https://docs.djangoproject.com/en/dev/ref/settings/#use-l10n
Here not speak of this variable determines the use of the thousands separator.

Please clarify, thanks

comment:8 Changed 4 months ago by yceruto@…

So the following example will not take effect:

USE_L10N = False
USE_THOUSAND_SEPARATOR = True
THOUSAND_SEPARATOR = ','
NUMBER_GROUPING = 3
DECIMAL_SEPARATOR = '.'

You should see 1,000.23
When today really shows 1000.23 due to the problem that I explain above

comment:9 in reply to: ↑ 7 Changed 4 months ago by shai

  • Cc shai added
  • Resolution set to wontfix
  • Status changed from new to closed

Replying to yceruto@…:

I do not understand why mention the word "unexpectedly"?

Because, as Claude mentioned, the current behavior of the code agrees with the documentation. You may have misinterpreted the documentation.

[...]

If is enabled or not USE_L10N only determines the "values" ​​of DECIMAL_SEPARATOR and THOUSAND_SEPARATOR according to the current locate set to LANGUAGE_CODE, but if USE_L10N = False then is display the default values.

That is not what the documentation says.

Why USE_L10N determining use of thousands separator?

https://docs.djangoproject.com/en/dev/ref/settings/#use-l10n
Here not speak of this variable determines the use of the thousands separator.

https://docs.djangoproject.com/en/dev/ref/settings/#use-thousand-separator
Here it does. If it is not clear to you that it does, you may consider suggesting a clarification.

Although Claude was extra-nice about it, in the future, please do not reopen a ticket that was closed as "wontfix" by a core committer. You can take the discussion to the developers list; I note that, in this case, you did that too (https://groups.google.com/d/msgid/django-developers/6a31612c-1052-4b37-bfbb-1c707934dc11%40googlegroups.com) -- but that discussion didn't pick up much steam. You may want to revisit it.

comment:10 Changed 3 months ago by shai

  • Resolution wontfix deleted
  • Status changed from closed to new
  • Triage Stage changed from Unreviewed to Accepted

Important points from discussion:

The documentation for USE_THOUSAND_SEPARATOR implies that it only has effect when USE_L10N is on, and current behavior is correct.
The documentation for NUMBER_GROUPING and THOUSAND_SEPARATOR says (on each of them):

Note that if USE_L10N is set to True, then the locale-dictated format has higher precedence and will be applied instead.

implying that when USE_L10N is False, the values should be used, and the submitter is correct.

So it seems like the documentation is not entirely consistent, and at the very least it should be clarified.

One way to interpret the documentation consistently is: USE_THOUSAND_SEPARATOR is a sort of partial override, indicating that NUMBER_GROUPING and THOUSAND_SEPARATOR should be used even though USE_L10N is on -- in that case the submitter is probably correct, and the line he refers to should be changed from

use_grouping = settings.USE_L10N and settings.USE_THOUSAND_SEPARATOR

to

use_grouping = (not settings.USE_L10N) or settings.USE_THOUSAND_SEPARATOR

Either way, marking as accepted as there clearly is a discrepancy between the code and parts of the documentation. Something needs to be fixed.

comment:11 Changed 2 months ago by timo

  • Easy pickings unset

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new
The owner will be changed from Yonel Ceruto to anonymous. Next status will be 'assigned'
as The resolution will be set. Next status will be 'closed'
Author


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

 
Note: See TracTickets for help on using tickets.