Internationalizing URL Patterns Redirect should be 404

[James Addison]

Consider the following settings:

USE_I18N = True

LANGUAGES = (
    ('en', gettext('English')),
    ('fr', gettext('French')),
)

with url patterns as follows:

urlpatterns = i18n_patterns('',
    url(r'^$', 'core.views.index', name='index'),
)

Assuming my system/browser is is set with the en-us locale, if I browse to example.com/ it will redirect to example.com/en/ as expected. If I browse to example.com/en/ or example.com/fr/ it will display the page with no redirects, again as expected. If I browse to example.com/de/ it redirects to example.com/en/de/ - not what I would expect or want.

I believe it should a) simply issue a 404 OR b) possibly issue a 404 by default but allow the user to override this behaviour via a setting to substitute a custom view. The latter would allow developers to have a "this page is not available in this language" along with some custom logic gather user feedback - this might be overreaching for where 1.4 is in the release cycle.

[James Addison]

Modified the severity to Normal.

[Aymeric Augustin]

I'm going to mark this again as a release blocker, because i18n_patterns is a new feature, and I'd like its author to assess whether this is a bug or the expected behavior.

[Jannis Leidel]

While this is certainly an odd situation, we really can't do something about this at this stage of the release cycle. It is technical correct to redirect to /en/de/ if German isn't listed in the list of languages.

This may be fixed by also checking the global list of languages supported by Django, but this will again break if a language is tried that Django itself doesn't support. Introducing a setting just to handle this case seems like a bad idea, too.

The suggestion to make this error handling pluggable seems like a good idea at first, too, but then I realized that we only provide this kind of extensibility for specific HTTP level errors, e.g. handler404, handler500 etc. I'm at loss how we could convince ourselves to make an exception for this use case.

That said, I'm accepting this ticket as a limitation of the current implementation but remove the release blocker label.