New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: cms.views
- set request language according to request.LANGUAGE_CODE
#7610
base: develop-4
Are you sure you want to change the base?
feat: cms.views
- set request language according to request.LANGUAGE_CODE
#7610
Conversation
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. |
Please can someone help we on how to write tests for this. I think this is vastly covered by current tests:
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. |
@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:
|
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 👍 . |
I'll work on this, not immediately, but the time will come. |
ci: Merge develop-4 into release/4.1.x
Fix: modal.scss dark-mode compatibilitiy
fix: Remove publish/draft reference from grouper admin message
* Fix css glitch * Update translations source fill which was missing strings * Add migration for page content verbose name
@vasekch I'd love to put this in the next release candidate. Do you think you'll come around to doing the tests? |
* [4.1.0rc4 release process] Building locales * [4.1.0rc4 release process] Bumped version to 4.1.0rc4 * [4.1.0rc4 release process] compilemessages * [4.1.0rc4 release process] compiling new static files * [4.1.0rc4 release process] updating latest docs * Update CHANGELOG.rst * Update 4.1.0.rst --------- Co-authored-by: Github Release Action <info@django-cms.org>
* Fix css glitch * Update translations source fill which was missing strings * Fix: en locale
* Fix css glitch * Update translations source fill which was missing strings * Fix: en locale * Fix typo * Fix: typo: occured -> occurred * undo mo change
Update from upstream
Include language in page cache key, the same as is in v3.11
@vasekch can you quickly comment on the last commit? |
cms.views
- set request language according to request.LANGUAGE_CODE
cms.views
- set request language according to request.LANGUAGE_CODE
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? |
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.
@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 get_placeholder_cache_key by referencing a function in settings.CMS_PLACEHOLDER_CACHE_KEY_EXTRA as string formatted for import_module. This is needed when some session setting change page content (e.g. currency), otherwise cache is mixed.
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
develop-4