Working with the team to support IE11

Fluent
#1

Hello good people of Mozilla l10n!

I work on a team at Autodesk that is trying to use Fluent for upcoming localization work for one of our web apps and have run into something of a speed bump re browser support. Our app’s active user base is ~20% IE11 users, which I know Fluent chose not to include on the list of supported browsers.

We were able to work around this by
A) Configuring our local Babel/Webpack build to process Fluent-related packages
B) Running our own forked version of Core-JS that includes a PR supporting the sticky flag on regexes (we’ve already reached out to the Core-JS team about us working w/ them to land this PR).

My question for the Fluent team is: would you be open to us partnering with y’all to provide guidelines for how to use Fluent w/ IE11 support once that Core-JS PR lands? We’d also love to be a guinea pig for new releases, so we can identify any IE11 issues and try to come up w/ reasonable workarounds, if that was feasible?

2 Likes
#2

Hi @beirnet, yes! We’d like to explore how we could partner with you. We have some initial thoughts around revisiting our build pipeline, mainly in light of a possible switch to TypeScript. This could impact how flexible our support matrix is. Nothing’s decided yet at this point, so your question has great timing. It’s good to learn more about how Fluent is used outside Mozilla.

Would you be willing to chat about this with me and other team members soon? I’ve sent you a message here on Discourse with my contact details.

1 Like
#3

Hi great people!

Same here. I’m working on Coral. We initially started thinking we can get by without IE11 support but some of our users which include large newsrooms have considerable traffic from IE11 users.

I just opened a newer PR on core-js that implements the missing RegExp features for Fluent. Additionally we’re transpiling fluent using babel when running through webpack and also switch the markup parser to use DOMParser instead. These steps allow fluent to run on IE11.

I was wondering if <template> and DOMParser.parseFromString(str, "text/html"); has the same result and if yes maybe we can use DOMParser as a default?

We’re also happy to contribute to smooth things out.

1 Like
#4

We met with @beirnet on the phone and we talked about supporting IE11 in @fluent packages. Here’s a short summary.

  • We don’t plan to extend our current official compatibility strategy to IE11, but we also don’t want to make it harder to add for anyone who’s interested. We’re open to documenting the process on our wiki.
  • There are no plans for any major changes in @fluent packages right now, nor in Fluent Syntax and file format.
  • I’ve started work to clean up our build system (#435), which may impact some edge cases regarding our current compatibility. The intent is to stick to what we have right now, which is roughly ES2017 for our compat builds.
  • I’ve also started looking into rewriting some @fluent packages into TypeScript (#376), which again may have consequences for compatibility. My mid-term plan is to remove Babel as the build dependency, and rely on TypeScript’s target compiler option instead. This could be beneficial to IE11, since TypeScript supports target: "es5".
  • @eemeli’s fluent-compiler might also be an interesting choice for projects with exotic compatibility requirements. It parses Fluent translations into JS functions on buildtime, and while currently it outputs modern JS, it should be possible to transpile it to ES5.

Thank you for the chat, @beirnet!

#5

Nice work, @vinh. It looks like the PR has already been merged!

Re. the markup parser: I’ll take a look at using DOMParser by default, thanks for bringing this up.

@Pike and I have been talking about implementing our own markup parser for a limited subset of HTML (or SGML). This could help with fixing some idiosyncrasies of HTML (e.g. treating <image> and <img> as the same thing, or sometimes not allowing self-closed elements), and would also work well with the planned formatToParts API. It would also make @fluent easier to run server-side, which ties this plan to the topic of compatibility at least partially.

#6

Are there any plans to include fluent-compiler or a similar solution as part of the official @fluent/ package family? To me this compiler approach seems like a no-brainer for the web, but sadly @eemeli’s contribution appears to be somewhat unmaintained and already falling behind in terms of sharing the same API with the relevant @fluent packages.

#7

I spent a couple of thoughts on the js compiler.

I see this as an interesting opportunity, but it’s also not an easy approach. Converting localizer data into executable code needs a secure design.

Hand-written code generators continue to bother me, I’d prefer a design that generated a JS AST and uses a battle tested serializer.

Another thing I recall in @eemeli’s implementation was that generated JS is actually modern JS, and not IE11 old-school stuff :wink:

To the actual question, we don’t have plans to pick up a compiler at Mozilla right now. If someone wants to jump at this, a design doc would probably be a good place to start.

#8

Just piping in briefly here to note that I’ve not forgotten Fluent, and do intend to update fluent-compiler soonish to match the recent updates. I’ve been a bit involved with the v3 update to messageformat and other things recently, but the stack of tasks that’s above Fluent work for me is getting rather small.

And yes, the compiler is rather intentionally producing modern JS. Its output is meant to be transpiled if necessary for IE11 & other environments.

2 Likes