Encoding problem in Mail notifications

geometalab / osmaxx

OpenStreetMap Arbitrary Excerpt Export - Get the OpenStreetMap data you want in the file format you need

http://osmaxx.hsr.ch/

MIT License

26 stars 3 forks source link

Encoding problem in Mail notifications #771

Open LoremoCH opened 7 years ago

LoremoCH commented 7 years ago

Die Mail Benachrichtigungen von osmaxx haben ein Encoding Problem. Umlaute wie ä/ö/ü im Namen des Exportes (wie hier Süddeutschland) funktionieren hingegen. Getestet habe ich nur mit G-Mail (Web sowie Andorid App) und Thunderbird.

This is an automated email from osmaxx.hsr.ch

The extraction order #315 "Schweiz und Südeutschland" has been processed and is available for download:
- Garmin navigation &amp; map data: https://osmaxx.hsr.ch/media/osmaxx/outputfiles/somefile.blabla

View the complete order at https://osmaxx.hsr.ch/exports/ (login required)

Thank you for using OSMaxx.
The team at Geometa Lab HSR
geometalab@hsr.ch

das-g commented 7 years ago

Ich nehme an, du meinst das &?

LoremoCH commented 7 years ago

Ja.

das-g commented 7 years ago

While we could avoid this with an {% autoescape off %} block in the affected template(s), that would be an IMHO semantically wrong approach, as it'd imply that we know the result is HTML-safe, while it in fact emphatically isn't;—we're just not using the rendered string in a plain text email thus why it doesn't have to be HTML-safe. Instead, I'd like to control the (not-)escaping from a part of the code where I know about this usage, rather than in the template itself, which could at least theoretically also be used in an HTML context where escaping would be necessary.

Controlling this elegantly at render-time (which is the one place where it can be seen how the resulting string will be further used in subsequent code) becomes possible in Django 1.10, by using a separately set up template engine that has the autoescape option set to False.

Thus, let's update to Django 1.10 before tackling this.

das-g commented 7 years ago

Status report:

The update to Django 1.10 is done: #790
The bugfix (WiP commit 8dda7f54cbc76e17f529b40675ada0a147b2d851) is held back for now, because it breaks django-crispy-forms. I've re-opened Django issue #27359 because of that and hope for replies that indicate how libraries can be fixed to work with django projects that configure multiple template engines of the same backend.

das-g commented 6 years ago

From Django 2.0 on, Engine.get_default() will return the first DjangoTemplates engine. This is how Template() gets the Engine it'll use (if none is passed as argument), so that crispy-froms that uses this shouldn't fail anymore when several engines are present.

Thus, we can attempt that fix again after upgrading to Django ≥ 2.0.