-
Notifications
You must be signed in to change notification settings - Fork 124
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
Can't change site to some languages #1052
Comments
FYI @arbrandes @brian-smith-tcril: I'm not sure where's the issue here, but still, the account MFE doesn't recognize some of the languages, and for those who do, the page stays in the previous language unless it's reloaded. This might be a bigger issue, but I think it's a good place to start. |
Looking at the account MFE specifically (https://github.com/openedx/openedx-translations/blob/main/translations/frontend-app-account/src/i18n/messages/)
I assume this is coming from https://github.com/openedx/openedx-translations/blob/main/translations/frontend-app-account/src/i18n/messages/id.json, which appears to have English strings in it
It seems we only have
There is no |
Thank you, @brian-smith-tcril; I understand better now. Do you know what the process is for supporting those languages? At least for the ones listed in the account MFE. |
Also, @brian-smith-tcril: there's a CORS error when changing the language from the account page. You can see it in detail here: openedx/wg-build-test-release#347 (comment) We have a similar cors error in the account MFE when trying to disconnect a TPA account association: openedx/wg-build-test-release#376 (comment) Is this likely related to why the language changes are not reflected immediately but after reloading? When changing the language, the CORS error in the account page also happens in Quince, so the changes are not seen immediately either. |
So... I tested this in the quince sandbox, and it failed: Screencast.from.03-06-24.15.19.59.webmAnd then tested it in one of our internal installations (tutor k8s + other custom configurations for Kubernetes), and it worked, even for français. I'm going to go through our setup to see what I find. |
So I was testing in our quince installation and realized that this only fails when the LMS_HOST differs from MFE_HOST. If they are the same, I can change the languages and the account MFE behaves correctly, because there is no CORS issue (same domain). @cmltaWt0: is that what happens in your installation where you can change the languages? |
@arbrandes @brian-smith-tcril: What do you think about the CORS issue findings? I believe at least some of it might be related to the language not changing immediately but after reloading. |
I haven't done any intensive investigation into the CORS issue but I would assume that it is something that needs to be addressed on the Tutor side. |
I commented on the Tutor issue. As far as I understand, this has nothing to do with Tutor. A side question is: why was this issue no longer considered a release blocker? (on June 4th) |
I believe that is because the issue already existed in Quince making this an existing issue instead of a regression.
Thank you so much for looking into it! That is a great writeup! |
Thank you, @regisb, for sharing your findings. I was looking into step 2, and it turns out Django is responsible for the redirection: https://github.com/django/django/blob/4.2.16/django/views/i18n.py#L45-L62 https://docs.djangoproject.com/en/4.2/topics/i18n/translation/#django.views.i18n.set_language Could this be fixed by sending a |
Great catch Maria! That's what I call some deep digging :) I disagree with your conclusion, though. If I understand correctly, we go through Our "happy path" would be to get a 204 response (line 45). And for that we should remove the This is how we should override the "Accept" header in "normal" Ajax:
I don't know how to do that in react, though. |
Thanks, @regisb. I completely missed that :) |
@arbrandes, I believe what Regis described above is also happening when trying to unlink SSO accounts (issue described here): Which also raises a misleading CORS issue. |
Here's the PR that might solve this: #1139 @arbrandes could you help us take a look? Thanks! |
It seems #1139 fixed this. Closing! |
Thanks for doing all this! FWIW, if you switch to one of the 4 languages @BryanttV identified as still not working because of missing translation files in the PR
the cookie is still set, which has weird effects because there is a small number of translated strings that get picked up. (I noticed this when, without having ever seen this GH issue, i saw the same bug, and I must have left my setting on "French", and then my English page was being set Is there a ticket to either remove the 4 broken languages from the drop down or add the translation files? I didn't see one linked here . No matter what, the current experience is still buggy. |
Expected behavior
Changing the language for the site should make text appear in other languages.
Actual behavior
For some languages, it works, but after reloading the page; for others it doesn't, and it goes back to English.
Steps to reproduce
In a really weird twist, some languages work and some do not!
So a lot of them work, but not all of them. It seems my initial choice of French was sort of lucky here - I might not have realized this was broken otherwise.
Original issue: openedx/wg-build-test-release#347
The text was updated successfully, but these errors were encountered: