New translations MFE not used in latest Tutor

[insad]

Two days ago I upgraded my Tutor installation to the latest version (13.1.5).
Around 25 days ago, the translations for es-419 in frontend-component-header were (finally) updated, as you can see here:

openedx/frontend-component-header/blob/3ab658ffa0a11340e3a9028f9e3a0e9e6bf15c65/src/i18n/messages/es_419.json

But still header items in Tutor mfe are all in English (title beside the logo and the items in the righthand dropdown), even as my language preference is Spanish.

So I copied the generated frontend code for the account MFE to a local folder on the server to inspect it, and the new translation file hasn’t been picked up by Tutor (see screenshot).

Maybe I’m doing something wrong?

[regis]

Unfortunately, the account MFE installs a pinned version (2.3.0) of the frontend-component-header: frontend-app-account/package.json at 257e425fd911ff7b6d6d4aaabaa6490ce7579fbb · openedx/frontend-app-account · GitHub

This version does not come with the newer translations: frontend-component-header/es_419.json at v2.3.0 · openedx/frontend-component-header · GitHub

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.

Instead, I recommend that you add custom translations to the account MFE: GitHub - overhangio/tutor-mfe

[insad]

Latest commit 94b3f19 on Sep 17, 2019

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.

But thanks, I’ll try to use my own translations…

[insad]

Hi Regis,

Created an “/env/plugins/mfe/build/mfe/i18n/header/” folder, and copied the “es_419.json” file from “frontend-component-header/src/i18n/messages at master · openedx/frontend-component-header · GitHub” there. After that I rebuilt the mfe images and restarted tutor as per instructions, but without any result.

Searching in the tutor code, I can’t find anywhere that “i18n-merge.js” is being invoked, so this shouldn’t be a suprise. Am I missing something?

[regis]

@insad

Created an “/env/plugins/mfe/build/mfe/i18n/header/” folder

The i18n folder should be named according to the name of the mfe that you want to modify: GitHub - overhangio/tutor-mfe: This plugin makes it possible to easily add micro frontend (MFE) applications on top of an Open edX platform that runs with Tutor.
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.

@insad

Searching in the tutor code, I can’t find anywhere that “i18n-merge.js” is being invoked, so this shouldn’t be a suprise. Am I missing something?

The i18n-merge.js script is called here: tutor-mfe/tutormfe/templates/mfe/build/mfe/Dockerfile at 0ed49fe7c66be380236276642ad1f5778bf5eb11 · overhangio/tutor-mfe · GitHub

[insad]

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 could solve the header (and footer) es-419 translation problem with the following plugin:

name: mfe_settings
version: 0.1.0
patches:
  mfe-dockerfile-post-npm-install: |
    RUN npm install '@edx/frontend-component-header@npm:@edx/frontend-component-header@latest'
    RUN npm install '@edx/frontend-component-footer@npm:@edx/frontend-component-footer@latest'

[ghassanmas]

@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[1].

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.

[1] frontend-app-account/index.jsx at 97164959515477ebc95399d031129be1e633b8ce · openedx/frontend-app-account · GitHub

[insad]

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.

[ghassanmas]

@insad

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:

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.

@insad

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.

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.