Contributing to Translations¶
The following content goes more in-depth than the Overview section to provide helpful information regarding contributing to Translations.
Source Code¶
The primary source code for Translations lives in the following directories:
toolkit/components/translations [browser/components/translations]
Architecture¶
JSActors¶
Translations functionality is divided into different classes based on which access privileges are needed. Generally, this split is between Parent and Child versions of JSWindowActors.
The Parent actors have access to privileged content and is responsible for things like downloading models from Remote Settings, modifying privileged UI components etc.
The Child actors are responsible for interacting with content on the page itself, requesting content from the Parent actors, and creating Workers to carry out tasks.
Remote Settings¶
The machine-learning models and WASM binaries are all hosted in Remote Settings and are downloaded/cached when needed.
Admin Dashboards¶
In order to get access to Translations content in the Remote Settings admin dashboards, you will need to request access in the Remote Settings component on Bugzilla.
Once you have access to Translations content in Remote Settings, you will be able to view it in the admin dashboards:
Dev
Stage
Prod Admin Access¶
In order to access the prod admin dashboard, you must also have access to a VPN that is authorized to view the dashboard. To gain access to the VPN, follow Step 3 on this page in the Remote Settings documentation.
Prod
Pulling From Different Sources¶
When you are running Firefox, you can choose to pull data from Dev, Stage, or Prod by downloading and installing the latest remote-settings-devtools Firefox extension.
Versioning¶
Translations uses semantic versioning for all of its records via the version property.
Non-breaking Changes¶
Translations code will always retrieve the maximum compatible version of each record from Remote Settings.
If two records exist with different versions, (e.g. 1.0 and 1.1) then only the version 1.1 record
will be considered.
This allows us to update and ship new versions of models that are compatible with the current source code and wasm runtimes in both backward-compatible and forward-compatible ways. These can be released through remote settings independent of the Firefox Release Schedule.
Breaking Changes¶
Breaking changes for Translations are a bit more tricky. These are changes that make older-version records incompatible with the current Firefox source code and/or WASM runtimes.
While a breaking change will result in a change of the semver number (e.g. 1.1 ⟶ 2.0), this alone is not
sufficient. Since Translations always attempts to use the maximum compatible version, only bumping this number
would result in older versions of Firefox attempting to use a newer-version record that is no longer compatible with the
Firefox source code or WASM runtimes.
To handle these changes, Translations utilizes Remote Settings Filter Expressions to make certain records available to only particular releases of Firefox. This will allow Translations to make different sets of Remote Settings records available to different versions of Firefox.
Example
Let’s say that Firefox 108 through Firefox 120 is compatible with translations model records in the 1.* major-version range, however Firefox 121 and onward is compatible with only model records in the 2.* major-version range.
This will allow us to mark the 1.* major-version records with the following filter expression:
"filter_expression": "env.version|versionCompare('108.a0') >= 0 && env.version|versionCompare('121.a0') < 0"
This means that these records will only be available in Firefox versions greater than or equal to 108, and less than 121.
Similarly, we will be able to mark all of the 2.* major-version records with this filter expression:
"filter_expression": "env.version|versionCompare('121.a0') >= 0"
This means that these records will only be available in Firefox versions greater than or equal to Firefox 121.
Tying breaking changes to releases in this way frees up Translations to make changes as large as entirely switching one third-party library for another in the compiled source code, while allowing older versions of Firefox to continue utilizing the old library and allowing newer versions of Firefox to utilize the new library.
Language Identification¶
Translations currently uses the CLD2 language detector.
We have previously experimented with using the fastText language detector, but we opted to use CLD2 due to complications with fastText WASM runtime performance. The benefit of the CLD2 language detector is that it already exists in the Firefox source tree. In the future, we would still like to explore moving to a more modern language detector such as CLD3, or perhaps something else.