Opened 8 years ago

Last modified 8 years ago

#17753 new Bug

Internationalizing URL Patterns Redirect should be 404

Reported by: James Addison Owned by: Jannis Leidel
Component: Internationalization Version: 1.4-beta-1
Severity: Normal Keywords: url patterns, internationalization
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Consider the following settings:

USE_I18N = True

    ('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 it will redirect to as expected. If I browse to or it will display the page with no redirects, again as expected. If I browse to it redirects to - 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.

Change History (5)

comment:1 Changed 8 years ago by James Addison

Severity: Release blockerNormal

Modified the severity to Normal.

comment:2 Changed 8 years ago by 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.

comment:3 Changed 8 years ago by Aymeric Augustin

Severity: NormalRelease blocker

comment:4 Changed 8 years ago by Aymeric Augustin

Owner: changed from nobody to Jannis Leidel

comment:5 Changed 8 years ago by Jannis Leidel

Severity: Release blockerNormal
Triage Stage: UnreviewedAccepted

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.

Note: See TracTickets for help on using tickets.
Back to Top