Skip to content
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

Merged

Conversation

julianwachholz
Copy link
Contributor


name: Pull request
about: Submit a pull request for this project
assignees: fabiocaccamo


Describe your changes

  • 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

Reference: django/django@aa5ab11

Related issue
#327

Checklist before requesting a review

  • I have performed a self-review of my code.
  • I have added tests for the proposed changes.
  • I have run the tests and there are not errors.

- 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
@julianwachholz julianwachholz marked this pull request as ready for review October 20, 2023 07:29
@codecov
Copy link

codecov bot commented Oct 20, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (1c1945c) 97.34% compared to head (266810f) 97.34%.

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           
Flag Coverage Δ
unittests 97.34% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@fabiocaccamo
Copy link
Owner

@julianwachholz thank you very much for this cool PR, I will test an review it as soon as possible!

@fabiocaccamo fabiocaccamo self-requested a review November 1, 2023 11:51
@fabiocaccamo fabiocaccamo added bug Something isn't working enhancement New feature or request labels Nov 1, 2023
@fabiocaccamo
Copy link
Owner

fabiocaccamo commented Nov 1, 2023

@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 (prefix_default_language=False), when I switch to the default language using the language chooser, I land to the current url that still includes the default language prefix (http://localhost:8000/en-us/admin/ instead of http://localhost:8000/admin/) (wrong) and the resulting page is a 404 error page (correct).

Screenshot 2023-11-01 at 12 40 14

At this point, considering that your refactoring looks right to me, it seems to be more a Django set_language bug.

I look forward to your feedback.

@fabiocaccamo
Copy link
Owner

@julianwachholz any update?

@julianwachholz
Copy link
Contributor Author

@julianwachholz any update?

I will look at it soon but I'm on vacation this week. 🙂

@julianwachholz
Copy link
Contributor Author

@fabiocaccamo after retracing your steps I found the culprit: the set_language view needs the LocaleMiddleware installed when using it like this. So I added an additional check for it.

@fabiocaccamo
Copy link
Owner

fabiocaccamo commented Nov 15, 2023

@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 django.middleware.locale.LocaleMiddleware in my demo.zip settings.MIDDLEWARE list.

Copy link
Owner

@fabiocaccamo fabiocaccamo left a 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.

@julianwachholz
Copy link
Contributor Author

Thank you for the demo.zip, @fabiocaccamo. I checked it out and wasn't able to produce an error using it. Both with prefix_default_language=True and prefix_default_language=False.

The tests for Django <= 3.1 are passing because the package doesn't have a default_app_config in __init__.py (automatic AppConfig discovery was added in 3.2). So I think this is a different bug related to the Django versions supported by django-admin-interface.

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.
As a small addition I added a runtime warning that only shows up when the language chooser is enabled.

warnings.warn(
"Language chooser requires 'django.middleware.locale.LocaleMiddleware' "
"in your MIDDLEWARE to work.",
stacklevel=1,
Copy link
Contributor

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)

Copy link
Contributor Author

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.

Copy link
Contributor

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

@fabiocaccamo
Copy link
Owner

However, the PR doesn't solve #327, if I don't prefix default language (prefix_default_language=False), when I switch to the default language using the language chooser, I land to the current url that still includes the default language prefix (http://localhost:8000/en-us/admin/ instead of http://localhost:8000/admin/) (wrong) and the resulting page is a 404 error page (correct).
Screenshot 2023-11-01 at 12 40 14
...
Unfortunately, this is not the cause of the problem I reported, because I already have django.middleware.locale.LocaleMiddleware in my demo.zip settings.MIDDLEWARE list.

@merwok have you the possibility to double-check this?

@julianwachholz
Copy link
Contributor Author

In the meantime, I've come across a bug in the current version where it would redirect me to a URL like /en-gb/en-gb/.... This is fixed in my branch which I'm currently using in our production system.

@fabiocaccamo
Copy link
Owner

@julianwachholz how does it happen? Could you submit a PR with test and bugfix for this too?

@julianwachholz
Copy link
Contributor Author

I haven't been able to reproduce it with my changes. Fixing it in main doesn't seem useful to me if it would be overridden with the changes from this PR?

@fabiocaccamo
Copy link
Owner

Can't you fix it in this PR?

@julianwachholz
Copy link
Contributor Author

It is fixed in this PR

@fabiocaccamo
Copy link
Owner

ah ok sorry, I didn't understand, I thought it was a new bug.

@fabiocaccamo fabiocaccamo merged commit b393c11 into fabiocaccamo:main Dec 5, 2023
45 of 46 checks passed
@merwok
Copy link
Contributor

merwok commented Jan 4, 2024

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.

@fabiocaccamo
Copy link
Owner

@merwok no problem, don't worry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

3 participants