Opened 5 years ago

Closed 4 years ago

Last modified 3 years ago

#13617 closed (duplicate)

USE_L10N results in faulty javascript code in GeoDjango with some locales

Reported by: piquadrat Owned by: jbronn
Component: Template system Version: 1.2
Severity: Keywords: L10N gis gmaps
Cc: jumpa, piquadrat, say4ne@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: yes
Easy pickings: UI/UX:

Description

German is one of the locales which uses a comma as the decimal separator. When this locale is active, template code like this results in faulty Javascript code, e.g:

geodjango.geopoint.setCenter(new GLatLng(47,3690239, 8,5380326), 12);

The problem is not strictly related to GeoDjango, it appears everywhere where templates are used to generate Javascript (or other formats with strict syntax) that contain floats.

Attachments (1)

noloc-template-tag.diff (7.1 KB) - added by piquadrat 4 years ago.
Implementation of {% noloc %} template tag

Download all attachments as: .zip

Change History (19)

comment:1 Changed 5 years ago by piquadrat

  • Component changed from GIS to Template system
  • Keywords L10N added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 5 years ago by jbronn

  • Component changed from Template system to GIS
  • Keywords gis admin added
  • milestone set to 1.3
  • Owner changed from nobody to jbronn
  • Status changed from new to assigned
  • Triage Stage changed from Unreviewed to Accepted

comment:3 Changed 5 years ago by jbronn

  • Keywords gmaps added; admin removed

comment:4 Changed 5 years ago by anonymous

This issue breaks the openstreetmap which is used by the OSMGeoAdmin, when l10n is enabled and the configured language (e.g. de-DE for german) uses a comma as decimal seperator, because the float max_resolution/maxResolution option which is used inside of the javascript code of the admin panel introduces a additional comma. The exact error of the javascript code is the following: "invalid object initializer".

comment:5 Changed 5 years ago by jumpa

  • Cc jumpa added

comment:6 Changed 5 years ago by piquadrat

  • Cc piquadrat added

How about introducing a template tag to temporarily disables L10N? e.g.

{% noloc %}
    <script type="text/javascript">
        var myreal = {{ myreal }};
    </script>
{% endnoloc %}

I'll let the native speakers come up with a better name for the tag ;)

As an ugly workaround, one can use the fact that variables aren't localized if used with "{% firstof %}" (not sure if this is intended or another bug):

{% firstof myvar 0 %}

comment:7 Changed 5 years ago by anonymous

  • Cc say4ne@… added

comment:8 Changed 5 years ago by sayane

Just:

    {{ js_module }}.{{ dom_id }}.setCenter(new GLatLng({{ center.1|stringformat:"s" }}, {{ center.0|stringformat:"s" }}), {{ zoom }});

There is simple workaround. Copy template to yourtemplates/gis/google/google-map.js, change that line like I did, and wait for official fix.

comment:9 Changed 5 years ago by anonymous

  • Component changed from GIS to Template system

comment:10 Changed 5 years ago by sayane

  • Component changed from Template system to GIS

Why somebody changed it to "Template system"? It's not problem of template system, but GIS. I'm reverting it.

comment:11 Changed 5 years ago by piquadrat

Although I didn't change the component to "Template system", I have some sympathies with the anonymous change. IMHO, this is a bug (or an oversight, or a missing feature) in the template system, and the GIS component is affected by the bug. Incorporating a workaround in the GIS JavaScript code may solve the particular issue I did report in the first place. But it doesn't solve the deeper problem that L10N can't be used (bar some ugly workarounds) in a project that outputs strictly structured information through the templating system.

comment:12 Changed 5 years ago by anonymous

Possible same problem #13881

comment:13 Changed 5 years ago by Federico Hlawaczek <fgh@…>

I encounter this problem also. For me, changing the max_resolution from a float to a string solved the problems so far. In options.py use:

class OSMGeoAdmin(GeoModelAdmin):
    ...
    max_resolution = "156543.0339"

Instead of:

class OSMGeoAdmin(GeoModelAdmin):
    ...
    max_resolution = 156543.0339

Haven't thoroughly tried this enough to be completely sure that it solves the problem for OSMGeoAdmin. But seems like a good work around until a nicer solution is in place.

comment:14 Changed 4 years ago by jbronn

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [14341]) Fixed #13617 -- OSMGeoAdmin now works again when USE_L10N (or LANGUAGE_CODE) is set. Thanks, Federico Hlawaczek, for workaround and piquadrat for patch.

comment:15 Changed 4 years ago by jbronn

(In [14342]) [1.2.X] Fixed #13617 -- OSMGeoAdmin now works again when USE_L10N (or LANGUAGE_CODE) is set. Thanks, Federico Hlawaczek, for workaround and piquadrat for patch.

Backport of r14341 from trunk.

comment:16 Changed 4 years ago by piquadrat

  • Component changed from GIS to Template system
  • Has patch set
  • Needs tests set
  • Patch needs improvement set
  • Resolution fixed deleted
  • Status changed from closed to reopened

After consulting Justin Bronn on #django-dev, I'm reopening this issue. I failed to fully describe the problem in my initial bug report. The bug I see doesn't happen in OSMGeoAdmin, but in the template django/contrib/gis/google/google-map.js. I mentioned in comment:11 that I think this isn't really a GIS problem, but a larger problem in the template system and localization. I still think this is the case. I'll attach a patch that implements the {% noloc %} template tag I described in comment:6.

A few comments about the patch:

  • please apply some bikeshed painting to the name of the template tag. I couldn't come up with something better than {% noloc %}, but there's got to be a better name for this functionality out there...
  • I added the {% noloc %} templatetag to django/template/defaulttags.py, but it could be just as well placed in django/templatetags/i18n.py. My reasoning was that the patch touches some core code of the template system (rendering of variables). Furthermore, a template can lead to undesired localized output without ever using template tags from i18n.
  • the patch contains two similar tests. The first test is with all the other template tag tests in tests/regressiontests/templates/tests.py. But this test has a couple of drawbacks. First, I had to introduce a special context variable similar to LANGUAGE_CODE that controls USE_L10N. Second, as far as I see, this test doesn't hit the code path that is taken when TEMPLATE_DEBUG = True. The second test case hits both code paths, but is in a different module than the actual template tag.

Changed 4 years ago by piquadrat

Implementation of {% noloc %} template tag

comment:17 Changed 4 years ago by jezdez

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

Closed in favor of #14181 which has a broader scope for the localization tag.

comment:18 Changed 3 years ago by jacob

  • milestone 1.3 deleted

Milestone 1.3 deleted

Note: See TracTickets for help on using tickets.
Back to Top