#30134 closed Bug (fixed)
Geodjango js template should use `|safe` for float values to avoid DECIMAL_SEPARATOR ruin the js syntax
| Reported by: | Sassan Haradji | Owned by: | Claude Paroz |
|---|---|---|---|
| Component: | GIS | Version: | 3.1 |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
contrib/gis/templates/gis/admin/openlayers.js should use |safe on float values to avoid DECIMAL_SEPARATOR (and probably other settings in this category) ruin the js syntax by adding unexpected characters instead of dot.
Change History (14)
comment:1 by , 7 years ago
comment:3 by , 7 years ago
| Has patch: | set |
|---|---|
| Needs tests: | set |
It looks to me like {% localize off %} is meant to prevent formatting of the value. Can you add a test that demonstrates how the issue happens?
comment:4 by , 7 years ago
localize off turns off l10n (look at django/templatetags/l10n.py) in my case l10n is already turned off in my settings.
When DECIMAL_SEPARATOR is manually set in settings, localize off has no effect on it, look at this comment copied from line 117 of django/utils/formats.py:
# The requested format_type has not been cached yet. Try to find it in any
# of the format_modules for the given lang if l10n is enabled. If it's not
# there or if l10n is disabled, fall back to the project settings.
fall back to the project settings, means falling back to DECIMAL_SEPARATOR (and other settings in its family). But just cause I set a custom value for DECIMAL_SEPARATOR doesn't mean gis should break on my django admin.
comment:5 by , 7 years ago
I think that for your use case, it would be better to activate l10n for your project and provide a custom format file (https://docs.djangoproject.com/en/stable/topics/i18n/formatting/#creating-custom-format-files). Is there anything preventing you applying this suggestion?
comment:6 by , 7 years ago
I don't know if something is preventing me applying this suggestion or not, I may be able to apply it, but it doesn't change the fact that setting DECIMAL_SEPERATOR should not break js syntax in js templates in no circumstances. Currently settings DECIMAL_SEPARATOR breaks above mentioned js template regardless of the value of L10N (False or True).
comment:7 by , 7 years ago
This may be a documentation issue, we could warn that using the l10n framework and maybe custom format files should be preferred over setting the global DECIMAL_SEPARATOR which cannot be selectively deactivated with l10n filters/tags.
comment:8 by , 7 years ago
If gis is not supposed to work with DECIMAL_SEPARATOR set in global settings file, then this is indeed a documentation issue rather than a bug. But I think there's room for improvement here, current behavior even if documented is counter intuitive, because developer doesn't know necessarily about internals of gis admin panel and doesn't expect setting DECIMAL_SEPARATOR to break it. Documenting this would be appropriate if it were some random php framework, but even if documented this behavior of setting some settings breaks another completely unrelated thing is not something I've ever seen in Django in my +9 years experience with it. I think what would be acceptable is one of these options:
- Remove/Deprecate things like
DECIMAL_SEPARATORin settings completely, if it's not something fully supported lets not have it when there are better alternatives that doesn't break things and do the same job (format files.) - Support
DECIMAL_SEPARATORand similar settings "completely" which means solving the issue described in this ticket and other possible problems settingDECIMAL_SEPARATORmay cause.
comment:9 by , 7 years ago
I would be tempted to go the DECIMAL_SEPARATOR deprecation route, but I may completely miss some real use cases...
comment:10 by , 7 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
I guess the ticket should be accepted, even if the path toward resolution is unclear. I think deprecating USE_L10N and the corresponding formatting settings in favor of locale formatting files would simplify a lot of things, but I'm not knowledgeable enough on the ramifications to put together a proposal.
comment:11 by , 5 years ago
| Needs tests: | unset |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
| Version: | 2.1 → 3.1 |
Fixed here: https://github.com/django/django/pull/10896