-
Notifications
You must be signed in to change notification settings - Fork 153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
7556 localized numbers #9439
7556 localized numbers #9439
Conversation
There are no references to this template anywhere in the repo. I found this because this would have been a location to use `unlocalize` and I wanted to open a test page while making the change. Since this template is unused, I can not test it. And since it is unused, it also seems unnecessary to keep around. If we miss it in the future, we can restore it from git.
This reverts commit 47867e9. Guess I missed that this is implicitly used by the BanneredCampaignPage model. Ups.
2ad10a0
to
ce8f1d6
Compare
I could not find a more appropriate place in the docs, so I put it in the README.
@fessehaye @danielfmiranda @TheoChevalier @kevinhowbrook Tagging all of you for visibility. This is probably something we all need to keep an eye out for going forward. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for going through all this @tbrlpld!
I also suspect disabling USE_L10N
would have broken the date localization (blog post publication dates, for instance), so this seem to be the right (albeit painful) way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the tag Tibor! will keep an eye out for this moving forward like you mentioned, also, kudos for updating the readme 👍 approved!
Description
It was previously observed that numbers entered into the template have been localized broadly. As a response we had turned off the
USE_THOUSAND_SEPARATOR
setting. But, this still left the decimal separators to be localized (e.g. the German locale would use a comma instead of a dot). This can lead to issues when the values are inserted into the template for computational use, rather than enduser consumption (think values of inline scripts and style, but also HTML attributes likewidth
andheight
on theimg
tag). It would be possible to deactivate that feature withL10N = False
, but that is not a future proof change since the setting will be deprecated in Django 4.0 and ignored starting with Django 5.0.Therefore, we will need to make sure that when ever we insert a value (especially float values) into the template for programmatic use, that we use the
unlocalize
filter to make sure the format of the numbers follows English standards and is interpretable in a programmatic way.See also: https://docs.djangoproject.com/en/4.1/topics/i18n/formatting/#controlling-localization-in-templates
Link to sample test page:
Related PRs/issues: #7556
Checklist
Tests
Is the code I'm adding covered by tests?Changes in Models:
Did I update or add new fake data?Did I squash my migration?Are my changes backward-compatible. If not, did I schedule a deploy with the rest of the team?Documentation: