While looking at the possibilities of overriding text/messages within an MFE without having to fork/extend the MFE itself I read through some documentation but I was unable to find anything specific to the use case.
Use Case:
The case itself is actually very simple. e.g. What we are looking to do is to just override a text in frontend-lib-special-exams with our own text, that says something different to a user when their Proctored exam has been moved to status Verified. In general, this could be a case to change/override any message(s) within the MFEs.
In the legacy system, while using the edx-proctoring library, this would have been possible to just override the HTML template within our own them and get this whole thing to look how we wanted along with the changed text.
References:
I read through some reference documentation about theming MFEs but I felt like all the options talk about customizing the logos, color schemes, or even fork/create a new package, make your changes and use it as an override to the original one. Iām linking to the documentation links below for the reference of the readers.
First off: hi @arslanashraf, and welcome to the forum!
Now, letās seeā¦ Youāve pretty much identified the biggest current gripe with MFEs: you canāt modify the rendered HTML in any meaningful way without forking. The closest weāve gotten to an alternative, so far, is OEP-48 and its implementation via brand-openedx. But even when adopted by an MFE, that only handles styles and logos, and itās not very straightforward to use.
This is to say that, at least right now, your best bet for changing messages is to fork the MFE (and/or library) and change it to meet your needs. We (as in āthe communityā) will be tackling MFE customizability in the near future, but at this point itās unclear whether weāll ever reach the same level of mutability that Django template overrides provide. (Itās the price we pay for all the other advantages, some of which @kmccormick once listed in human-readable form here.)
@arbrandes Thanks for your detailed response which makes most of the things clear enough. However, the idea of a fork might be useful in cases when someone would be upgrading their edx-platform release to release, but for those who are early adopters and like to run with the master release, the fork will be outdated too often along with possible merge conflicts & need of continuous rebase. (More details can be seen here).
I was thinking of a few things that might increase the context of this post for present/future references. I have a few questions, in general, that might refer to the links provided in the original post of the response you provided.
Looking at brand-openedx still doesnāt provide the functionality for overriding the texts in frontend MFE pages. The question is if we are planning to add that support, is there a timeline on that Or any documentation that might be helpful?
I there was a relatively quick solution to overriding the text/titles at least would that be acceptable upstream? (Please take a look at the idea below)
Idea:
The initial idea is to introduce support for en.json in the frontend-app-learning initially that will override the expected default strings for english language like ar.json or fr.json. We might just add an initial en.json and merge the string from the JSON file to the commonly provided translations themselves that will get merged at the build time.
This idea has initially been explained in detail in This Github Comment for anyone to take a deeper look at what we are planning.
It would also be nice if anyone responding can point out any possible caveats in the above idea?
These ideas need more discovery and vetting, but Iāve considered several ways to do this:
Brand packages
Yes, using brand packages to hold override strings feels like one option. An early design decision of the brand packages was to keep dependencies and JS/JSON code out of them for simplicity and so they didnāt have to have a build process. (See this ADR: brand-openedx/0002-no-dependencies.rst at master Ā· openedx/brand-openedx Ā· GitHub)
We could revisit how strict we want to be and allow brands to export a messages.js file with overrides. Specifically, the ADR is about dependencies more-so than JS code itself, but the latter often results in the former, so we should be careful.
There are two big barriers here:
One is that our frontends may have conflicting message IDs but share a brand - I donāt think this is necessarily easy to solve.
Two is that the brand is also used by traditional/legacy services like edx-platform which have a completely different i18n solution based on .po files.
Build-time JS config
frontend-build and frontend-platform have the ability to take their configuration from a JS file rather than .env environment variables. Weāre not using this yet, though. If we did, however, it would allow us to pass complex data structures in as configā¦ such as an override messages.js file which could be dropped into the directory at build time.
I think brand-based feels more flexible, more complex, but in line with how we want to handle customization in the future. The build-time config idea is in line with our intended approach for allowing overrides of frontend-platform services like analytics and logging. If we want this to be part of a āthemeā, I think getting it closer to the brand makes sense, but I do worry about having override messages for all MFEs in one brand and how we handle conflictsā¦
Hi @arslanashraf . We have a pretty similar case, when we want to update some messages across the MFEs.
Would you mind sharing a few details on how you solved the task in the end?
And if you have any recommendations and hints?
Hey @djoy, I was also wondering, maybe there was any updates to MFE that could help to change messages in an easy way?
Hi @alex_sh - to my knowledge there havenāt been any particular developments here lately, and @arbrandesās suggestion of forking is likely the best option at the moment. I wish I had a better answer.
Heh, yeah, decided to resurrect one, as it seemed the most relevant.
Thanks a lot for the response. Thatās really helpful to narrow the variety of tries. Weāll follow the lead with the fork.
Interesting thing that I hoped to work is adding translations files into the (tutor)/env/plugins/mfe/build/mfe/i18n/<app>/ folder. Unfortunately it works only for non-english files:
new text in fr.json file works (when language switched to French)
new text in en.json or id.json does not work no matter what
Iām curious, if it actually supposed to work for English files too?
I thought I remembered something in Tutor to help with this, but Iām not a Tutor expert by far, so will have to defer to other folks. Paging Dr. @arbrandes, who may remember if thereās a feature here Iām forgetting about.
At that time we actually did solve it by creating a fork and overriding the translations directly in the MFE.
But, We recently got rid of the fork by using another way. So, Open edX has provided a CLI tool openedx-atlas that can be used to override the translations for any MFE at the build time. The readme is quite detailed so that might be additional help in getting started with Atlas.
Thanks for your response. I have already looked at the instructions and tried to follow them. Let me describe the issues and doubts that I faced while following the steps.
$ docker exec -it c53557341134 bash
OCI runtime exec failed: exec failed: unable to start container process: exec: ābashā: executable file not found in $PATH: unknown
Unlike lms container, MFE container does not have bash. And in the atlas document it says that for atlas bash is the requirement.
Atlas prerequisites are git>=2.20.1 and bash .
Also when I try to install atlas through npm I get this error.
$ docker exec -it c53557341134 sh
/srv # npm install @edx/openedx-atlas
sh: npm: not found
Then I tried to install atlas while building the mfe image. I used this tutor plugin for testing.
Then while building mfe image I saw this command running in logs too. When mfe image was built, I restarted all the services and started MFE container but still atlas was not installed in the container.
So, it would be really helpful if you would provide me the guidance about the steps that I might have missed here or performed incorrectly.
Thanks.
