USE_L10N results in faulty javascript code in GeoDjango with some locales

[Benjamin Wohlwend]

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.

[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".

[Benjamin Wohlwend]

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 %}

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

[Sayane]

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

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

[anonymous]

Possible same problem #13881

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

[jbronn]

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

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

[Benjamin Wohlwend]

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.

[Benjamin Wohlwend]

Implementation of {% noloc %} template tag

[Jannis Leidel]

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

[Jacob]

Milestone 1.3 deleted