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

Can't change site to some languages #1052

Closed
mariajgrimaldi opened this issue May 21, 2024 · 17 comments
Closed

Can't change site to some languages #1052

mariajgrimaldi opened this issue May 21, 2024 · 17 comments
Assignees
Labels
bug Report of or fix for something that isn't working as intended release blocker Blocks the upcoming release (fix needed) release testing Affects the upcoming release (attention needed)

Comments

@mariajgrimaldi
Copy link
Member

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

  1. Open up account settings, like https://apps.redwood.demo.edly.io/account/#site-preferences
  2. Click or scroll to "Site Preferences".
  3. Click "Edit" next to "Site language".
  4. Pick a language. I chose French.
  5. Click "Save".
  6. Reload the page.
  7. Notice that the page is still in English and the setting has swapped back to English. (Not sure what happens if your site-wide default is set to something else.)

In a really weird twist, some languages work and some do not!

  • Arabic (العربية) - Works! Including right-to-left. Getting it back out of Arabic was a slight challenge, on account of I do not read Arabic.
  • Bahasa Indonesia - No luck. The preference sticks, but the site does not change.
  • 中文 (简体) (Simplified Chinese) - Works!
  • dansk - Works!
  • Espaõl (Latinoamérica) - Works!
  • Français - No luck.
  • German - Works!
  • עברית (Hebrew) - Works!
  • साइट प्राथमिकताएँ (Hindi) - Works!
  • Italian - Molto bene!
  • Kiswahili - Poa kichizi kama ndizi. (That means it works.) (Technically it means "Crazy cool like a banana", and it's basically the only Kiswahili I know.)
  • 한국어 (대한민국) (Korean, RoK) - No luck. Site does not change, preference does not stick.
  • Português - Works!
  • Türkçe - Works!
  • Українська (Ukranian) - Works!

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

@mariajgrimaldi mariajgrimaldi added the release testing Affects the upcoming release (attention needed) label May 21, 2024
@mariajgrimaldi
Copy link
Member Author

mariajgrimaldi commented May 21, 2024

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.

@brian-smith-tcril
Copy link
Contributor

Looking at the account MFE specifically (https://github.com/openedx/openedx-translations/blob/main/translations/frontend-app-account/src/i18n/messages/)

Bahasa Indonesia - No luck. The preference sticks, but the site does not change.

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

Français - No luck.

It seems we only have fr_CA in the account MFE https://github.com/openedx/openedx-translations/blob/main/translations/frontend-app-account/src/i18n/messages/fr_CA.json

한국어 (대한민국) (Korean, RoK) - No luck. Site does not change, preference does not stick.

There is no ko file in there

@mariajgrimaldi mariajgrimaldi added the bug Report of or fix for something that isn't working as intended label May 24, 2024
@mariajgrimaldi
Copy link
Member Author

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.

@mariajgrimaldi mariajgrimaldi added the release blocker Blocks the upcoming release (fix needed) label May 28, 2024
@mariajgrimaldi
Copy link
Member Author

mariajgrimaldi commented Jun 2, 2024

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.

@mariajgrimaldi mariajgrimaldi removed the release blocker Blocks the upcoming release (fix needed) label Jun 3, 2024
@mariajgrimaldi
Copy link
Member Author

mariajgrimaldi commented Jun 3, 2024

So... I tested this in the quince sandbox, and it failed:

Screencast.from.03-06-24.15.19.59.webm

And 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.

@jmakowski1123 jmakowski1123 added release blocker Blocks the upcoming release (fix needed) and removed release blocker Blocks the upcoming release (fix needed) labels Jun 4, 2024
@mariajgrimaldi
Copy link
Member Author

mariajgrimaldi commented Jun 6, 2024

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?

@cmltaWt0
Copy link

cmltaWt0 commented Jun 6, 2024

@mariajgrimaldi
Copy link
Member Author

@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.

@brian-smith-tcril
Copy link
Contributor

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.

@regisb
Copy link

regisb commented Sep 16, 2024

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)

@brian-smith-tcril
Copy link
Contributor

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.

I commented on the Tutor issue. As far as I understand, this has nothing to do with Tutor.

Thank you so much for looking into it! That is a great writeup!

@mariajgrimaldi
Copy link
Member Author

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 next= parameter when calling setlang here so it redirects to the same page?

@regisb
Copy link

regisb commented Sep 23, 2024

Great catch Maria! That's what I call some deep digging :) I disagree with your conclusion, though. If I understand correctly, we go through next_url = "/" (line 44) because we have request.accepts("text/html") (line 32). See the request headers:

changelang

Our "happy path" would be to get a 204 response (line 45). And for that we should remove the text/html, */* values from the Accept header. I managed to reproduce this with the "edit and resend" feature in Firefox developer console. When we remove these values from the header, we are successfully getting a 204 response.

This is how we should override the "Accept" header in "normal" Ajax:

fetch('/i18n-url', {
    method: 'POST',
    headers: {
        'Accept': 'application/json'
    }
})

I don't know how to do that in react, though.

@arbrandes arbrandes self-assigned this Sep 23, 2024
@mariajgrimaldi
Copy link
Member Author

Thanks, @regisb. I completely missed that :)

@mariajgrimaldi
Copy link
Member Author

mariajgrimaldi commented Oct 7, 2024

@arbrandes, I believe what Regis described above is also happening when trying to unlink SSO accounts (issue described here):

image

Which also raises a misleading CORS issue.

@cmltaWt0 cmltaWt0 added the release blocker Blocks the upcoming release (fix needed) label Oct 10, 2024
@mariajgrimaldi mariajgrimaldi self-assigned this Oct 10, 2024
@mariajgrimaldi
Copy link
Member Author

Here's the PR that might solve this: #1139

@arbrandes could you help us take a look? Thanks!

@arbrandes
Copy link
Contributor

It seems #1139 fixed this. Closing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Report of or fix for something that isn't working as intended release blocker Blocks the upcoming release (fix needed) release testing Affects the upcoming release (attention needed)
Projects
Development

No branches or pull requests

6 participants