Django i18n internationalized urls middleware (feature proposal). Related to ticket #24122, and commit #aa5ab1

[Karol Majta]

Hi,

Firstly I would like to say hi to everyone, since this is my first post in this group :)

To the point; I was really glad to see behavior of `set_language` view fixed in changelog of Django 1.9, however in my opinion it only solves half of the problem with internationalized urls and browser's locale. It's definately a desired behavior, that the view now redirects to page in proper language, however it still does not solve the problem, that internationalized urls cannot be safely shared between users. Consider a scenario:

1. Pablo (Spanish) enters www.example.com/ola/ which renders him a welcome page "Ola!".

2. He copies the url and sends it to Greg (English)

3. Greg enters given url and hits a `404 Not Found` page because his browser's locale is set to English, and English route is `/hello/` not `/ola/`

In my opinion proper behavior would be to allow Greg to see the Spanish version of webpage (urls were designed to be share'able in the first place...).

I am the author of https://github.com/karolmajta/django-robust-i18n-urls which I used as drop-in replacement for Django's `set_view` (now working properly), and to provide sane behavior for newcomers to the page via a middleware. This middleware can be reviewed here: https://github.com/karolmajta/django-robust-i18n-urls/blob/master/src/robust_urls/middleware.py

In essence, in case `404 Not Found` would be normally returned, the middleware kicks in, and tries possible languages. If it finds a match it will show the result to the user and set his language for the session. Otherwise it will just return 404.

I described the problem and my solution some time ago at http://blog.karolmajta.com/robust-internationalized-urls-for-django/

Please let me know if you see my use case valid (i know I am not the only person that was hit by this weird behavior) and if you would see it as a useful addition to django's core.

Best,

 Karol

[Shai Berger]

Hi,

I am no i18n expert, but IMO your approach to internationalized urls is
problematic; you make it possible that a given URL shows completely unrelated
contents to different users based on their language preferences. You provide a
guessing solution for the case that the translated URL doesn't exist, but what
if it exists and just points to a different page? As a trivial example, "je" is
"I" in French, but (singular, informal) "you" in Dutch. What page is
www.example.com/je ?

So, I think that internationalized URLs must include a language indicator. If
your Pablo sends www.example.com/es/ola to his friend Brian, when the
middleware sees Brian's preferences it can redirect to
www.example.com/en/hello. There's no need to guess anything.

My 2 locally appropriate sub-units of currency,

Shai.

[Karol Majta]

I think you are correct. The way urls are structured in my example is wrong,

and while they come from real-life "customer requirement" there is no need to encourage

this sort of stuff.

Best,

 Karol