feat: cms.views - set request language according to request.LANGUAGE_CODE

[vasekch]

Description

I'm facing difficulties when using custom middleware for switching languages based on domain name. Inspired by django.middleware.locale.LocaleMiddleware I use request.LANGUAGE_CODE to set language (along with translations etc.)

When a Page is rendered, the language is wrong, first value from settings.LANGUAGES is used. Current code only works with language prefix patterns or it serves default language (being the first one from LANGUAGES, not LANGUAGE_CODE as one would expect).

So I propose to include in main cms.views extra code for language recognition. This is designed to work with built-in LocaleMiddleware and any custom middleware.

If LocaleMiddleware is used, our code for handling language prefix pattern is arbitrary as it does the very same thing.

Checklist

• I have opened this pull request against develop-4
• I have added or modified the tests when changing logic
• I have followed the conventional commits guidelines to add meaningful information into the changelog
• I have read the contribution guidelines and I have joined #workgroup-pr-review on Slack to find a “pr review buddy” who is going to review my pull request.

[vasekch]

I've removed the code that is already included in the LocalMiddleware (detecting language from url prefix).

LocaleMiddleware is part of official instruction for using i18n in Django and we have it by default in the django-cms-quickstart.

[vasekch]

Please can someone help we on how to write tests for this.

I think this is vastly covered by current tests:

• https://github.com/django-cms/django-cms/blob/develop/cms/tests/test_i18n.py
• https://github.com/django-cms/django-cms/blob/develop/cms/tests/test_multilingual.py

New approach in this PR adds possibility to handle languages using custom middleware through Django standard way - using request.LANGUAGE_CODE. It seems bit out of scope to implement custom middleware in the test to proof this.

Any guidance on how this should be tested is appreciated.

[fsbraun]

@vasekch I agree that the conventional behaviour is already tested. A way of testing your generalization would be a one liner middleware that always sets the language to, say, Swedish. The test could check what languages a page would be served in:

• /
• /en/ or /it/

[fsbraun]

I've been looking into why this, so far, has been hard-coded into the CMS but came to your conclusion: It currently is not the "right" way of processing languages. I am not aware of any side effects as of now. If we get this tested, I'd be happy to back the PR 👍 .

[vasekch]

I'll work on this, not immediately, but the time will come.

[fsbraun]

@vasekch I'd love to put this in the next release candidate. Do you think you'll come around to doing the tests?

[fsbraun]

@vasekch can you quickly comment on the last commit?

[fsbraun]

Hi @vasekch ! We'll probably be doing another RC. I'd be happy if we could include this PR. Any hopes to get it over the line soon?

[vasekch]

@fsbraun sorry, no ETA. I'm in the middle of production release preparation agony. I need to make some compromises, like the last commit here. I'll later gladly explain intentions and split this into more sensible PRs, currently it's quite ugly.

Added option to extend page_cache_key by referencing a function in settings.CMS_PAGE_CACHE_KEY_EXTRA as string formatted for import_module.

This is needed when language is moved away from url path, it needs to be provided separately, otherwise cache is mixed.

This is also useful if request contain any other cache differentiators, for example currency in a cookie.