-
Notifications
You must be signed in to change notification settings - Fork 122
refactor: change lang selector logic #493
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
base: master
Are you sure you want to change the base?
Conversation
Thanks for the pull request, @dcoa! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. Where can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #493 +/- ##
==========================================
+ Coverage 91.22% 94.25% +3.02%
==========================================
Files 5 6 +1
Lines 57 87 +30
Branches 19 23 +4
==========================================
+ Hits 52 82 +30
Misses 5 5 ☔ View full report in Codecov by Sentry. |
0ae49f6
to
3845c7f
Compare
3845c7f
to
bd327ad
Compare
bd327ad
to
7ec5478
Compare
Hi, @brian-smith-tcril I has wondering if you can have a look to this proposal or if should I tag someone from product before the technical review? |
Sorry for the extended delay in response! I think this is a change we do want. I also know that there is a similar feature implemented in Assuming this PR and the implementation in |
I think there's a question of whether or not we want to be adding a new flag. If we don't mind a new flag this PR is good to go from a product perspective, but if we want to make this the default experience for any site that has multiple languages, you'd want to make a product ticket. |
@arbrandes I think your opinion here is valuable, understanding you have a better panorama of the current state of the frontend new architecture. What do you think about this proposal and the alignment with |
Friendly ping on this, @arbrandes |
@arbrandes any opinion in this topic? |
Hi @dcoa, I’ll be leaving some comments on your code for further discussion, and i really would like to @arbrandes to take a look at this as he has a better understanding of the entire project. Thank you for your hard work and contributions! |
{config.ENABLE_FOOTER_LANG_SELECTOR && ( | ||
<div className="mb-2"> | ||
<LanguageSelector | ||
options={config.SITE_SUPPORTED_LANGUAGES} | ||
username={authenticatedUser?.username} | ||
langCookieName={config.LANGUAGE_PREFERENCE_COOKIE_NAME} | ||
/> | ||
</div> |
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.
I think it might be cleaner to handle some rendering logic validation inside the component, along with fetching the options, username, and langCookieName there.
}; | ||
const getLocaleName = (locale) => { | ||
const langName = new Intl.DisplayNames([locale], { type: 'language', languageDisplay: 'standard' }).of(locale); | ||
return langName.replace(/^\w/, (c) => c.toUpperCase()); |
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.
return langName.replace(/^\w/, (c) => c.toUpperCase()); | |
return langName.charAt(0).toUpperCase() + langName.slice(1); |
I see that this line capitalizes the string. A more straightforward implementation without regular expressions might be better for this task. I'll leave it up to you.
}); | ||
}); | ||
|
||
it('should disp,ay the language icon and modify the label according to the screen size', () => { |
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.
it('should disp,ay the language icon and modify the label according to the screen size', () => { | |
it('should display the language icon and modify the label according to the screen size', () => { |
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.
I suggest adding docstrings to this file methods to improve readability.
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.
I suggest adding docstrings to this file methods to improve readability.
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.
I would like you to take a look at this PR, you might find it interesting as it proposes a new frontend-platform
module to handle the language change logic based on your changes.
Hi @dcoa, I've tested the final version of the component using Please see the attached video demonstrating the behavior: translations-not-working.mp4After the change, everything seems to work fine: translations-working.mp4However, please note that while the translations do update, they are only applied partially. Many sections of the platform are still not configured to receive the Given this, the most robust solution might be to force a full page reload when updating the language, ensuring that all parts of the application reflect the new language settings. What do you think? |
try { | ||
if (username) { | ||
await patchPreferences(username, { prefLang: selectedLlocale }); | ||
await postSetLang(selectedLlocale); | ||
} else { | ||
getCookies().set(langCookieName, selectedLlocale); | ||
} |
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.
try { | |
if (username) { | |
await patchPreferences(username, { prefLang: selectedLlocale }); | |
await postSetLang(selectedLlocale); | |
} else { | |
getCookies().set(langCookieName, selectedLlocale); | |
} | |
try { | |
getCookies().set(langCookieName, selectedLlocale); | |
if (username) { | |
await patchPreferences(username, { prefLang: selectedLlocale }); | |
await postSetLang(selectedLlocale); | |
} |
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.
I thing the real problem is there are 2 cookies one is being updated the second one not, I will check if I can replicate the behavior and understand why that is happening. In any case, your suggest is good.
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.
The suggested change creates a new cookie instead of changing the default one, because of that is not the best solution for the described problem.
I could identify that the described problem is only present in learning (that make sense for the iframe - django based does not change at runtime as react does).
Description and motivation
This PR refactors the lang selector logic recognizing its significance for multi-language instances.
The Open edX platform previously featured a configurable language selector in both the header and footer. However, after transitioning to microfrontends, this feature is only partially implemented in the footer. It requires passing a list of supported languages and a change function, necessitating additional modifications even when using the footer slot.
This PR change the dropdown and add the user preference update endpoint.
Proposal
Convert this component in a slot so could be installed in the header as well and give them the operators the option to use the language selector in the header or footer.
How to test
const config = { ENABLE_FOOTER_LANG_SELECTOR: true, SITE_SUPPORTED_LANGUAGES: ['es', 'en'], };
2025-01-13.21-07-20.mov