#21544: Problem with number format when not using L10N
-------------------------------+---------------------------------------
Reporter: yceruto@… | Owner: Jacob Walls
Type: Bug | Status: assigned
Component: Documentation | Version: dev
Severity: Normal | Resolution:
Keywords: number format | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+---------------------------------------
Changes (by Jacob Walls):
* owner: Yonel Ceruto => Jacob Walls
* status: new => assigned
* component: Utilities => Documentation
Comment:
> From the "floatformat" filter I can not force the grouping of thousands,
making it impossible to apply this option.
Forcing thousand separators in `floatformat` was new in 3.2: see
ac6c4260074de43a978e5c6553ef89441e1d6748 (#20601).
So I think we have solved the original use case. Regarding the
documentation inconsistency noted by Shai:
> 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.
The current behavior was created in
10d4094b86721da690fcb3c9bc89b7a0089dfd5c (#13054). See this test:
{{{
@override_settings(USE_L10N=False)
def test_l10n_disabled(self):
...
# We shouldn't change the behavior of the floatformat filter
re:
# thousand separator and grouping when USE_L10N is False even
# if the USE_THOUSAND_SEPARATOR, NUMBER_GROUPING and
# THOUSAND_SEPARATOR settings are specified
with self.settings(USE_THOUSAND_SEPARATOR=True,
NUMBER_GROUPING=1, THOUSAND_SEPARATOR='!'):
self.assertEqual('66666.67', Template('{{ n|floatformat:2
}}').render(self.ctxt))
self.assertEqual('100000.0', Template('{{ f|floatformat
}}').render(self.ctxt))
}}}
Rationale from #13054 discussion:
> I'm inclined to think it is a bug because this hypothetical scenario: An
user has set NUMBER_GROUPING to a value > 0 and USE_THOUSAND_SEPARATOR =
True but sets USE_L10N = False thinking it's a master switch that turns
the locale-aware formatting machinery off. But the floatformat filter
still messes with the part to the left of the decimal separator.
So we have evidence the current behavior is intentional. However,
elsewhere we've been going in the other direction, which makes updating
the docs all the more important.
The approach in #22654 was to respect `THOUSAND_SEPARATOR` and
`DECIMAL_SEPARATOR` even when `L10N=False` for form validation:
bde814142a933bd96c3fa54a64cb1f74a575bb38
504e7782fef74cb78768092780a3476866379c21 (release note)
Unless we want to change `numberformat` a second time (!), and given that
we've enabled the reporter's use case with an option to force thousand
separators in `floatformat`, maybe we should clarify the difference in
behavior in the documentation for these settings? Something like: when
`USE_L10N` is False, these settings are respected only for form
validation, not for the template tag `floatformat`; in that instance, see
<docs about forcing thousand separators in floatformat>.
--
Ticket URL: <https://code.djangoproject.com/ticket/21544#comment:12>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/075.6c961f31dc1e59fb7888e6b05a6a3844%40djangoproject.com.
