Validation error in Slovak: question about URL language code sniffing

[Ryan Kaskel]

Hi all,

I ran my project's tests today using the new beta and was surprised
when one innocuous-looking test failed because the expected English
validation error string didn't match the returned Slovak equivalent.

It turns out that this view is accessible with URL whose path begins
with "/sl/". Ticket #11585 [0] and its associated commit [1] (which
are fairly old) changed
django.utils.translation.get_language_from_request by adding the
get_language_from_path hook. Since my site uses the LocaleMiddleware,
this change activates the Slovak language for the request. Validation
errors and other available translated strings end up being in a
language I don't really want to use.

What are people's thoughts on this? I know the URL is a poor one and
luckily I'm not really affected because humans don't directly access
them, but it seems like a backwards incompatible change that isn't
well documented.

It would be great to be able to pass a keyword argument to
get_language_from_request telling it to not call
get_language_from_path. That way I could override
LocalMiddleware.process_request and fall back to the old language
detection mechanism.

Perhaps there is a simple solution I'm missing.

Best,
Ryan Kaskel

[0] <https://code.djangoproject.com/ticket/11585>
[1] <https://code.djangoproject.com/changeset/16405>

[Anssi Kääriäinen]

On Feb 17, 8:55 pm, Ryan Kaskel <d...@ryankaskel.com> wrote:
> Hi all,
>
> I ran my project's tests today using the new beta and was surprised
> when one innocuous-looking test failed because the expected English
> validation error string didn't match the returned Slovak equivalent.
>
> It turns out that this view is accessible with URL whose path begins
> with "/sl/". Ticket #11585 [0] and its associated commit [1] (which
> are fairly old) changed
> django.utils.translation.get_language_from_request by adding the
> get_language_from_path hook. Since my site uses the LocaleMiddleware,
> this change activates the Slovak language for the request. Validation
> errors and other available translated strings end up being in a
> language I don't really want to use.

To me this seems like a release blocker. Django can't suddenly start
changing language because of some URL prefix, it is backwards
incompatible as seen by the above.

I created a ticket for this and marked it as a release blocker. I
attached a patch which disables language activation based on url-
prefix if i18n_patterns isn't used in root urls. This way the language
activation takes place only if you use i18n_patterns, that is, you are
actually using the feature.

The ticket is #17720. Please help by reviewing it! If full review
feels daunting, just do some of the following:
- check that this solves your issue
- check that the docs do not need changes

Add a comment describing your findings. Especially the first item
would help a lot!

- Anssi