Intent to Experiment: Translator API
Domenic Denicola
Contact emails
dom...@chromium.org, fer...@chromium.org, kenji...@chromium.org
Explainer
https://github.com/WICG/translation-api/blob/main/README.md
Specification
None yet, although we'll be writing one during the experimentation period.
Summary
A JavaScript API to provide language translation capabilities to web pages.
Blink component
TAG review
https://github.com/w3ctag/design-reviews/issues/948
TAG review status
Issues open, primarily around how to name the various API entry points. (The review itself is closed as "satisfied with concerns".)
Risks
Interoperability and Compatibility
This feature has definite interoperability risks, including which languages are available across different browsers, how they are exposed, the quality of translations, and whether developers need the translations to be on-device or not. We can ameliorate some of these through API design, by making it clear that various methods might fail and that a fallback is required. Others, like translation quality, may end up as quality-of-implementation issues, similar to other machine learning-based APIs like shape detection.
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1015)
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/339)
Web developers: Positive (https://github.com/WICG/proposals/issues/147)
Other signals:
Activation
This feature would definitely benefit from having polyfills, backed by any of: cloud services, lazily-loaded on-device models using WebGPU, or the web developer's own server. We anticipate seeing an ecosystem of such polyfills grow as more developers experiment with this API.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Goals for experimentation
We're most interested in feedback on whether the translation quality we can provide is useful to sites. We're also interested in whether the set of languages we provide suffices for web developer use cases.
Regarding the privacy tradeoffs around language pack downloads, we plan to experiment with a variety of approaches during the origin trial, and get feedback on them, in collaboration with the privacy team. Our starting approach is to allow up to three language packs to be downloaded, with restrictions: at least one of the source or destination languages must be in either the user's Accept-Language header, and the other must be a globally-popular language. We may also explore permission prompts to allow more language packs, or redundant downloading of language packs into triple-keyed caches.
We're also interested in the usual feedback about the API shape, which may evolve over the course of the origin trial.
Ongoing technical constraints
None.
Debuggability
During the origin trial, web developers can use chrome://on-device-translation-internals/ to manage language pack installation. And, by setting chrome://flags/#translation-api flag to "Enabled without language pack limit", developers can work around the privacy-focused restrictions during local testing. If the feature is successful, these may eventually graduate into DevTools features.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
No. We will start with desktop, and are working on expanding to Android during the OT period.
Is this feature fully tested by web-platform-tests?
No
We hope to work on web platform tests for this feature, but how much we can guarantee as testable beyond the surface API is unclear. For example, since no specific languages are guaranteed to be supported, it's not clear we can actually test translations. APIs to mock the results might help here.
Flag name on chrome://flags
translation-api
Finch feature name
TranslationAPI
Requires code in //chrome?
True
Tracking bug
https://issues.chromium.org/issues/322229993
Measurement
kV8LanguageTranslator_Translate_Method
Estimated milestones
There is some chance we will slip this milestone, in which case we would expert 133 through 138. We will update the thread if that happens.
Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
A variety of possible API surface changes are under consideration. Additionally, the exact processing of nontrivial language tags (e.g. en-GB-oed, ja-Latn, or en-x-lolcat) is still unclear: https://github.com/WICG/translation-api/issues/11.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5172811302961152?gate=5068777028059136
Links to previous Intent discussions
Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2a9d154a-dc97-495b-afda-ba643712116bn%40chromium.org
This intent message was generated by Chrome Platform Status and edited by hand.
Yoav Weiss (@Shopify)
Contact emailsdom...@chromium.org, fer...@chromium.org, kenji...@chromium.org
Explainerhttps://github.com/WICG/translation-api/blob/main/README.md
SpecificationNone yet, although we'll be writing one during the experimentation period.
SummaryA JavaScript API to provide language translation capabilities to web pages.
Blink component
TAG reviewhttps://github.com/w3ctag/design-reviews/issues/948
TAG review statusIssues open, primarily around how to name the various API entry points. (The review itself is closed as "satisfied with concerns".)
Risks
Interoperability and CompatibilityThis feature has definite interoperability risks, including which languages are available across different browsers, how they are exposed, the quality of translations, and whether developers need the translations to be on-device or not. We can ameliorate some of these through API design, by making it clear that various methods might fail and that a fallback is required. Others, like translation quality, may end up as quality-of-implementation issues, similar to other machine learning-based APIs like shape detection.
Domenic Denicola
Daniel Bratell
I can confirm that 6 milestones is approved, and either 131-136 or 132-137 (and I will even expand that to 133-138 just in case) will be fine. Good luck experimenting!
LGTM
/Daniel
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-sJFwO6WZxZFu8_4nAvpW7OPyWi2yqqMFcQSXreiUtDg%40mail.gmail.com.