Opened 4 years ago

Last modified 3 years ago

#17753 new Bug

Internationalizing URL Patterns Redirect should be 404

Reported by: jaddison Owned by: jezdez
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

Description

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.

Change History (5)

comment:1 Changed 4 years ago by jaddison

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Severity changed from Release blocker to Normal

Modified the severity to Normal.

comment:2 Changed 4 years ago by aaugustin

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 4 years ago by aaugustin

  • Severity changed from Normal to Release blocker

comment:4 Changed 4 years ago by aaugustin

  • Owner changed from nobody to jezdez

comment:5 Changed 3 years ago by jezdez

  • Severity changed from Release blocker to Normal
  • Triage Stage changed from Unreviewed to Accepted

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