Opened 15 years ago

Closed 14 years ago

Last modified 13 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: no UI/UX: no

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.

Change History (19)

comment:1 by Benjamin Wohlwend, 15 years ago

Component: GISTemplate system
Keywords: L10N added

comment:2 by jbronn, 15 years ago

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

comment:3 by jbronn, 15 years ago

Keywords: gmaps added; admin removed

comment:4 by anonymous, 15 years ago

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 by jumpa, 15 years ago

Cc: jumpa added

comment:6 by Benjamin Wohlwend, 15 years ago

Cc: Benjamin Wohlwend 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 by anonymous, 15 years ago

Cc: say4ne@… added

comment:8 by Sayane, 15 years ago

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

Component: GISTemplate system

comment:10 by Sayane, 15 years ago

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

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

Possible same problem #13881

comment:13 by Federico Hlawaczek <fgh@…>, 15 years ago

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 by jbronn, 14 years ago

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 by jbronn, 14 years ago

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

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/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.

by Benjamin Wohlwend, 14 years ago

Attachment: noloc-template-tag.diff added

Implementation of {% noloc %} template tag

comment:17 by Jannis Leidel, 14 years ago

Resolution: duplicate
Status: reopenedclosed

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

comment:18 by Jacob, 13 years ago

milestone: 1.3

Milestone 1.3 deleted

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