Given my past experience with MFEs, I’d say it is highly unlikely that the latest version of frontend-component-header is compatible with the Maple release frontend-app-account, so I would recommend against upgrading.
That’s another big problem with MFE … obsolete versions of components, probably same big problems when I want to style them, newer “insights” for styling won’t work for this prehistoric pinned version.
The i18n folder should be named according to the name of the mfe that you want to modify: GitHub - overhangio/tutor-mfe
Thus, your folder should be /env/plugins/mfe/build/mfe/i18n/account/ for the “account” mfe.
And you should do exactly the same for the “profile” and the “learning” MFEs… I realize this is suboptimal, but hey, it’s a solution.
This works perfect for the body of the MFE (e.g. the account MFE where maple.2 release has a lot of untranslated strings for es_419), but still couldn’t tame the header strings. Bit short of time now to find out how to replace the header strings, will try next week to find a solution!
I think this is logical, the MFE build process is taking a pre-built header and doesn’t try to rebuild the same, so it gets stuck with the translations at the moment of freezing that version. Maybe this should be fixed upstream in the respective package.json files…
@insad I ran into simliar trouble recenlty, its a bit tricky to changes the messages, of header/footer because header/footer by themeselves are sepearate apps and thus they have their own messages.
For example in account MFE, the way its initializes is that it would require the messages from 3 places, the actual app, the footer, the header, and then it would merge them togather.
However it merges footer/header (lastest) so if were trying to change header/footer using tutor, (tutor override the actual app) I wouldn’t expect it to work since your changes/tutor changes will be overriden by the order of messages here.
I think one solution would be to change the order and make the actual app messages be the last, (so overriding them with tutor or deafult app message should be possible),
I will check with MFE folks, to see if we change the order, it wouldn’t miss with thier workflow. if they say yes, then we would have to change that for all MFEs, (at least starting with the one tutor uses by default).
Also this would mean as well that those changes, would need to apply for all MFEs (e.g. you would have to add the, in all directory of /i18n/<app-name>/), but I guess we could tweak the merge script a bit of tutor such that it can accept messages, which shall be applied to all MFEs, which is the case for the footer/header.
Sorry, but I absolutely don’t understand your point. MFE header and footer used inside other MFE (like profile, account etc.) are node modules pinned to a certain (old) version, and as such come without or incomplete translations, my plugin simply replaces those old versions by the latest ones:
first the normal npm install runs and installs the frontend-component-header and frontend-component-footer in the version, pinned in the respective package-lock.json that comes with the MFE
then my plugin replaces both frontend-component-header and frontend-component-footer with the latest version
finally the MFE is being built
This build process is repeated for each MFE (profile, account, …), i.e., header / footer are included in each MFE again, there’s not a “common” header / footer somewhere for all MFE.
IMHO this has further nothing to do with the order of the commands in the jsx file you mention. Please correct me, if I’m wrong.
Yes but their translation/messages will be imported separately, and then combined with the app messages.
There is nothing wrong with your plugin, not that I think of.
put my arugments apart, your goal was to change/alter the messages of the header/footer, and to do that you had to fork the header/footer, you weren’t able to do that through tutor way of handeling of i18n of the MFEs, right?
(Correction:, I though you wanted to fork them, turns out you just wanted to update them, still though if MFEs allows extending footer/header would be able to do that without the plugin, sorry for the confusion again)
And to be able to do that with tutor, something has to be changed with MFEs themselves, and to do that effectivily with tutor we better tweak the merge script.
The order of objects indeed does affect the way messages will be used by the consuming app, here is an explict doc about it.
But again I don’t want to get you into hassel or something, you have already resolved it, my reasoning is that there should be a better way to change footer/header i18n, than to fork them, and my post before was about making sense of the requirements that are needed so that can be done.