-
-
Notifications
You must be signed in to change notification settings - Fork 181
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
Simplify language chooser #328
Simplify language chooser #328
Conversation
- Allows usage of i18n_patterns with prefix_default_language=False - Change templatetag from simple tag to an inclusion tag - Reduces complexity by relying on Django's behavior in the set_language view: it will translate any url passed as 'next'. This behavior has been present since Django 1.9. - Remove individual forms for each language Fixes fabiocaccamo#327 Reference: django/django@aa5ab11
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #328 +/- ##
=======================================
Coverage 97.34% 97.34%
=======================================
Files 38 38
Lines 414 414
=======================================
Hits 403 403
Misses 11 11
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
@julianwachholz thank you very much for this cool PR, I will test an review it as soon as possible! |
@julianwachholz sorry for the late answer, I finally had some time for testing/reviewing this PR. You made some great optimizations, so it's my intention to merge this PR. However, the PR doesn't solve #327, if I don't prefix default language ( At this point, considering that your refactoring looks right to me, it seems to be more a Django I look forward to your feedback. |
@julianwachholz any update? |
I will look at it soon but I'm on vacation this week. 🙂 |
@fabiocaccamo after retracing your steps I found the culprit: the |
@julianwachholz the check you added is very useful indeed, thanks! Unfortunately, this is not the cause of the problem I reported, because I already have |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the check you introduced, I expect to see all tests to fail because there is not django.middleware.locale.LocaleMiddleware
in tests.settings.MIDDLEWARE
, but some tests succeeded anyway.
Thank you for the demo.zip, @fabiocaccamo. I checked it out and wasn't able to produce an error using it. Both with The tests for Django <= 3.1 are passing because the package doesn't have a Because the language picker is optional, I removed the check and it will now fail silently on misconfiguration and require users to set it up correctly as the documentation describes. |
warnings.warn( | ||
"Language chooser requires 'django.middleware.locale.LocaleMiddleware' " | ||
"in your MIDDLEWARE to work.", | ||
stacklevel=1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn’t 1 the default value? Is it correct here? (to determine: check what file and line of code is shown as the origin of the warning in the output)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it's the default. The linter was complaining it wants it explicitly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two notes:
- that sounds like a bad linter, or strange configuration
- the point is that stacklevel=1 is very rarely useful, it’s more common to see stacklevel=2 so that the user code with the problem is shown in the traceback
@merwok have you the possibility to double-check this? |
In the meantime, I've come across a bug in the current version where it would redirect me to a URL like |
@julianwachholz how does it happen? Could you submit a PR with test and bugfix for this too? |
I haven't been able to reproduce it with my changes. Fixing it in |
Can't you fix it in this PR? |
It is fixed in this PR |
ah ok sorry, I didn't understand, I thought it was a new bug. |
Sorry I could not test or answer when you asked Fabio – my projects all use LocalMiddleware so I wasn’t in a state to reproduce the problem noted. |
@merwok no problem, don't worry. |
name: Pull request
about: Submit a pull request for this project
assignees: fabiocaccamo
Describe your changes
Reference: django/django@aa5ab11
Related issue
#327
Checklist before requesting a review