3 ms·

This is awesome, but... > This set of requirements posed a number of technological challenges to the team: the translation engine was entirely written in progr

by bogwog 4y ago

This is awesome, but... > This set of requirements posed a number of technological challenges to the team: the translation engine was entirely written in programming languages that compile to native code. We needed a way to streamline the distribution of the project in order to avoid the overhead involved in providing builds compatible with all platforms supported by Firefox — that would be impracticable to scale and maintain. Does Firefox really support so many different platforms and archs that CI builds are unrealistic?

dblohm7 4y ago
(Former Mozilla employee, here) I'm completely speculating, but it's probably a matter of not wanting to complicate iterating on the translation engine by introducing a bunch of cruft from the Firefox build system (which, though it uses GNU make under the hood, is very much bespoke and complicated). Since the translation engine is intended to run on a product that hosts WASM, they might as well just build to that.
jelmervdl 4y ago
The upside of using WASM is that the extension itself can be easily ported to other browsers and platforms. The UI uses Firefox specific APIs but the parts that take the HTML from a page and push it through the translation engine would also work in any Chrome-based browser. (Edit: also free sandboxing of a blob of C++ code that needs to handle arbitrary input from the web!)
andrenatal1 4y ago
The point here is that it simpler to have just one NMT engine in WebAssembly shipped bundled in the extension than runs in all platforms for free, instead of having to support and distribute multiple native builds of the engine that would be sideloaded and communicate with the extension via native messaging. When the project started for example, the engine has incompatible with ARM, which we could just get for free with WebAssembly. The performance penalty of doing that was minimal for the user eyes, and so far we received less than a handful of complains about it. Bundling the entire engine on Firefox was never an option for many obvious reasons.
seba_dos1 4y ago
Only Debian alone builds Firefox for 7 different CPU architectures (12 if you count outdated packages too).

by bogwog 4y ago

dblohm7 4y ago

(Former Mozilla employee, here) I'm completely speculating, but it's probably a matter of not wanting to complicate iterating on the translation engine by introducing a bunch of cruft from the Firefox build system (which, though it uses GNU make under the hood, is very much bespoke and complicated). Since the translation engine is intended to run on a product that hosts WASM, they might as well just build to that.

jelmervdl 4y ago

The upside of using WASM is that the extension itself can be easily ported to other browsers and platforms. The UI uses Firefox specific APIs but the parts that take the HTML from a page and push it through the translation engine would also work in any Chrome-based browser. (Edit: also free sandboxing of a blob of C++ code that needs to handle arbitrary input from the web!)

andrenatal1 4y ago

The point here is that it simpler to have just one NMT engine in WebAssembly shipped bundled in the extension than runs in all platforms for free, instead of having to support and distribute multiple native builds of the engine that would be sideloaded and communicate with the extension via native messaging. When the project started for example, the engine has incompatible with ARM, which we could just get for free with WebAssembly. The performance penalty of doing that was minimal for the user eyes, and so far we received less than a handful of complains about it. Bundling the entire engine on Firefox was never an option for many obvious reasons.

seba_dos1 4y ago

Only Debian alone builds Firefox for 7 different CPU architectures (12 if you count outdated packages too).