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…