Open edX Summer Challenge: Fix Learning MFE's integration with Browser Plugins for Translations

Development i18n
1

Hi everyone,

TL;DR

See below for information on our inaugural Open edX Summer Challenge, ending July 31st, 2021 that aims to increase localization access for our global learners.

Context

edX’s Teaching and Learning and Community Engineering teams have modernized the Open edX platform’s in-course learner experience, overhauling its frontend technology in the form of a new Learning Micro-frontend (MFE) application. This new MFE was tagged for early community adoption with the Juniper release.

This newly re-platformed experience comes with mobile responsiveness and improved UX and API performance. It also addresses one of our long-term needs of site security concerns by sandboxing user-authored content and code within iFrames.

Problem

One of the tradeoffs that we discovered with embedding content within iFrames is that in-browser plugins for Translations no longer work in the new Learning MFE. For example, while the Google Translate Chrome Extension translated content within course content XBlocks in the old experience, it no longer does in the new experience (see the HTML XBlock and the Problem XBlock below).

Screen Shot 2021-06-14 at 7.48.53 PM
Screen Shot 2021-06-14 at 7.48.53 PM2564×1676 286 KB

2021 Summer Challenge

The technical problem described above is a time-sensitive issue.

In an upcoming Open edX named release, the new learning MFE will be the default learner experience, and the old experience will be deprecated and removed. While we will likely want to fix this in time for December’s Maple release, already, many learners on edX.org are running into this issue. It prevents access to valuable educational content for global learners who leverage in-browser translation tools to navigate the web.

For those of you who love :heart: challenges, do you raise your hand :raised_hand:t3: to solve this one? Can you, this summer (by July 31st), fix the new Learning MFE’s integration with browser-plugins for Translations?

(There’s a stackoverflow article related to this that may - or may not - help you.)

Sign Up

If you are eager to tackle this issue, respond to this post. If you have a functional solution, share it on this thread - it may spark other ideas as well. To get a workable solution merged into the platform, we would connect you with a Core Committer to bring your solution to fruition.

In return, for appreciation of your ingenuity in accepting this challenge and your commitment to addressing the needs of our global learners, you will receive a coveted Open edX Summer Challenge badge and additional recognition.

Nimisha and the Open edX Team

1 Like
2

Looks like its due to cross site. google translator works if iframe point to same domain. I will try some solution.

3

I closely looked into problem and found the following:

Reason: It is happending because of cross site and nothing to do with google translation. Due to cross site, the script is not able to get content of iframe to translate.

Possible Solution:

  1. It works if iframe url belongs to same domain. so if we create url as subdirectory instead of subdomain then problem solve automatically. I don’t know, how hard it is but best solution which may solve many problem which we are not aniticipating yet due to iframe.
  2. Due to cross-site, parent window and iframe window can not communicate directly but both have function postMessage which can be used to pass messages between each other. https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage. we need to play with this to find some solution.
4

@Manish_Hada Great work diagnosing this issue!

MFEs can be deployed to subdirectories instead of subdomains, so this solution could work for small sites. But since it kinda ruins the scalability benefits of MFEs, it’s not a great solution for edx.org and large deployments. But I guess if it’s the only one that works, they could proxy requests to the subdomain-deployed MFEs?

Not sure whether google translate sends the page any signals when it’s been invoked to translate a page. But if it does, maybe we could catch that event and do something with it?

I briefly looked into rewriting the iframe URLs as suggested on StackOverflow, but aside from all the wrappers that Google puts around the translated content, the translate.google.com page has X-Frame-Options: DENY, so it can’t be iframed :frowning:

1 Like
5

Yes, I investigated js file and it’s parameters, it doesn’t provide any event on change lang but if we might bind event externally then we can do something. I changed lang of iframe through postMessage function but still looking into two things:

  1. to bind event on change language.
  2. to change iframe language smoothly without left any strain behind.

yes, doesn’t work :slight_smile: