Even if I am no longer a core contributor or part of the Open edX community, I find myself finding bugs again as we try to import some of our courses to edx.org.
This time, I found a major issue with the frontend-app-learner-dashboard MFE translations. Itās a very similar problem to the one I previously identified with the frontend-app-communications MFE.
Basically, not all string ids in the various messages.js files found in the repository are properly harvested, collected and sent to Transifex for translations.
If you look at the course card on the dashboard, you will see for example that the string āBegin Courseā and other strings remain in English for all languages. You can easily check that by switching languages in edx.org or in your own Open edX instances running Quince for example.
Thatās because the strings in src/containers/CourseCard/components/CourseCardActions/messages.js never made it to src/i18n/messages/fr_CA.json or any other files that would be used for translating various languages in the MFE. Check for the id learner-dash.courseCard.actions.beginCourse and you will not find it in the strings that the Translations Working Group needs to translate in Transifex.
As this is the second MFE for which I report an issue with harvested strings, I would suggest that all MFEs should be checked to make sure all strings are properly harvested, sent to Transifex for translations by members of the community and later used in various instances of Open edX be it on edx.org or in the community.
I am copying @Eden_Huthmacher@brian.smith@omar@arbrandes because they are representatives of the Translations Working Group and the Frontend Working Group and they might need to take a look at this problem that may be recurrent in a few MFEs.
@sambapete I knew it wouldnāt be long until we would find another way to collaborate
Note that edx.org is still very much part of the Open edX community, so in my mind all users, instructors and 2U staff working on edx.org are part of the Open edX community. You can make changes for your courses on edx.org through the Open edX project.
In this case it was really just a side-effect of migrating courses from our Open edX instance to the mothership edx.org.
And absolutely, they are part of the community and the problem I mentioned affects them as much as the community or more because they support multiple languages while some Open edX instances may support only 1, 2 or at most 3 languages.
In the end I am surprised that nobody had noticed this issue when the new learner dashboard was introduced in master and later on in Quince.1
Itās kind of a variant of the frontend-app-discussions problem I flagged last year. But in this case, a few of the strings exists but are not harvested and transmitted to Transifex while others are. Thatās why I believe most MFEs should be looked at to make sure some strings are not left behind in the code and not being sent to Transifex for translations. There might be a global problem at the MFE level for all MFE.
Hi all. Thanks @sambapete for creating this topic and explaining the problem. Actually Iāve faced this issue as well. In addition to some strings missing in Transifex, some are not marked for translation at all. Here is a sample:
The expression āCourse Statusā is not marked as a translation string in the code so it stays the same in all languages. The screenshot above is a side by side comparison between English and Persian.
Strings that are not marked for translations are a different issue than strings that are marked for translations but not harvested, collected and then transmitted to Transifex. Nonetheless, it can be really annoying if your users expect to see strings in their own language.
There are multiple translation mechanisms in Open edX depending if the strings are in code snippets in Python, React or any other programming language. It can unfortunately happen that a hardcoded string like the one for āCourse Statusā pops up from time to time. Sometimes there is an easy solution for it and sometimes it can be more difficult to fix. Believe me, Iāve encountered a few of these problems since installing Aspen way back in late 2014 and early 2015.
Internationalization is not easy, but in general the Open edX project does a good job for the major languages supported by the Open edX community.
I agree that the internationalization work in openedx project is really good. I also appreciate all the effort put into the new learner dashboard MFE. It just has some issues, as almost any software may have IMHO. Hope all the issues get fixed soon
About the āCourse Statusā thing, I created the issue and the PR in github now.
Thanks @omar but this will be insufficient to fix the issue at large.
This will fix the problem with CourseCardActions but not all problems.
The same issue exists in other messages.js files in frontend-app-learner-dashboard.
A full review may be needed.
Look at src/containers/SelectSessionModal/messages.js, ./src/containers/CourseCard/components/CourseCardMenu/messages.js and a few others that are also using StrictDict.
And it may be the case in other directories for that MFE and multiple other MFEs.
I guess the Translations Working Group and the Frontend Working Group should make
As I am no longer a core contributor to the Open edX project, I donāt have the time and I donāt know how long it would take me to make a PR to fix all issues, have it reviewed and implemented to fix all the issues with translations in this particular MFE and maybe in other MFEs. Yes, I am passing the ball to the MFEs owners and/or maintainers.
I donāt know how the community could implement it but a test to make sure that all strings defined in a particular MFE are added to the strings that are sent to Transifex for translations is needed now after what we found with frontend-app-communications previously and now with frontend-app-learner-dashboard. My 2 cents.
@sambapete It is a good idea to run tests and ensure that all strings defined in a particular resource are added to the strings that are sent to Transifex for translations. I can have the TX team perform such tests on the frontend-app-communications and frontend-app-learner-dashboard to start with. @omar can you send me the original source files via email? They will need them to perform such tests.
I donāt know how the community could implement it but a test to make sure that all strings defined in a particular MFE are added to the strings that are sent to Transifex for translations is needed now after what we found with frontend-app-communications previously and now with frontend-app-learner-dashboard.
Iād love if such thing existed. That would save us a ton of time. Iām trying to think if a simple rule to detect such hard-coded strings without reporting too many false-positives and Iām unsure if such thing exists.
You can make changes for your courses on 