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. On Monday 26 October 2015 16:23:46 Karol Majta wrote: > 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/robu > st_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
