Opened 8 years ago

Closed 7 years ago

Last modified 6 years ago

#13617 closed (duplicate)

USE_L10N results in faulty javascript code in GeoDjango with some locales

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


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 Benjamin Wohlwend 7 years ago.
Implementation of {% noloc %} template tag

Download all attachments as: .zip

Change History (19)

comment:1 Changed 8 years ago by Benjamin Wohlwend

Component: GISTemplate system
Keywords: L10N added

comment:2 Changed 8 years ago by jbronn

Component: Template systemGIS
Keywords: gis admin added
milestone: 1.3
Owner: changed from nobody to jbronn
Status: newassigned
Triage Stage: UnreviewedAccepted

comment:3 Changed 8 years ago by jbronn

Keywords: gmaps added; admin removed

comment:4 Changed 8 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 8 years ago by jumpa

Cc: jumpa added

comment:6 Changed 8 years ago by Benjamin Wohlwend

Cc: Benjamin Wohlwend added

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

{% noloc %}
    <script type="text/javascript">
        var myreal = {{ myreal }};
{% 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 8 years ago by anonymous

Cc: say4ne@… added

comment:8 Changed 8 years ago by Sayane


    {{ 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 8 years ago by anonymous

Component: GISTemplate system

comment:10 Changed 8 years ago by Sayane

Component: Template systemGIS

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

comment:11 Changed 7 years ago by Benjamin Wohlwend

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 7 years ago by anonymous

Possible same problem #13881

comment:13 Changed 7 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 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 7 years ago by jbronn

Resolution: fixed
Status: assignedclosed

(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 7 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 7 years ago by Benjamin Wohlwend

Component: GISTemplate system
Has patch: set
Needs tests: set
Patch needs improvement: set
Resolution: fixed
Status: closedreopened

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/, but it could be just as well placed in django/templatetags/ 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/ 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 7 years ago by Benjamin Wohlwend

Attachment: noloc-template-tag.diff added

Implementation of {% noloc %} template tag

comment:17 Changed 7 years ago by Jannis Leidel

Resolution: duplicate
Status: reopenedclosed

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

comment:18 Changed 6 years ago by Jacob

milestone: 1.3

Milestone 1.3 deleted

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