Can't change site to some languages

[mariajgrimaldi]

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]

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]

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]

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]

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]

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.

[mariajgrimaldi]

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]

@mariajgrimaldi Yeap.
LMS: https://axim-mfe.raccoongang.net/
MFE: https://apps.axim-mfe.raccoongang.net/

[mariajgrimaldi]

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

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]

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]

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]

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]

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:

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.

[mariajgrimaldi]

Thanks, @regisb. I completely missed that :)

[mariajgrimaldi]

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

[mariajgrimaldi]

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

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

[arbrandes]

It seems #1139 fixed this. Closing!