Intent to Extend Experiment: Translator API

[Nathan Memmott]

Contact emails

dom...@chromium.org, fer...@chromium.org, kenji...@chromium.org, ay...@chromium.org, mem...@chromium.org, chris...@chromium.org

Explainer

https://github.com/WICG/translation-api/blob/main/README.md

Specification

https://webmachinelearning.github.io/translation-api

Summary

A JavaScript API to provide language translation capabilities to web pages.

Blink component

Blink>AI>Translate

TAG review

https://github.com/w3ctag/design-reviews/issues/948

TAG review status

Issues addressed

Origin Trial Name

Translator API

Chromium Trial Name

TranslationAPI

Origin Trial documentation link

https://developer.chrome.com/docs/ai/translator-api

WebFeature UseCounter name

kTranslator_Create

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

Reason this experiment is being extended

There has been an overhaul to the API shape in the spec that we're currently implementing. We'd like to continue the OT to get feedback on the new API shape once it's ready to evaluate.

Substantial progress has been made in the following areas:

• Draft spec: the spec is now complete.

• TAG review: the tag review is complete.

• Signals requests: other browsers have not yet made any progress on these.

• Outreach for feedback from the spec community: we've discussed this API a few times at Web ML Community Group meetings. Additionally, feedback from the internationalization spec community was helpful in resolving https://github.com/webmachinelearning/translation-api/issues/11 .

• WPT tests: we now have some basic WPTs for invalid inputs and a single success case.

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

Only supported on desktop platforms during the Origin Trial period.

Is this feature fully tested by web-platform-tests?

No

We have some web platform test coverage for this feature (https://wpt.fyi/results/ai/translator?label=experimental&label=master&aligned), 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 about://flags

translation-api

Finch feature name

TranslationAPI

Requires code in //chrome?

True

Tracking bug

https://issues.chromium.org/issues/322229993

Measurement

kTranslator_Create

Estimated milestones

Origin trial desktop first	131
Origin trial desktop last	136
Origin trial extension 1 end milestone	138

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).

At this point all known proposed changes have been incorporated into the specification and implementation.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5172811302961152?gate=5155440738172928

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

Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9ArjjD0u%3DpFs1W_5%3DcMk49JXs5ObQ15dNHCHt3TKSW3g%40mail.gmail.com

[Alex Russell]

Thanks for filing an extension request.

Some questions that weren't clear from the above:

• Is this extension going to involve breaking changes? I saw the TAG's feedback from last year had API shape suggestions, so curious to know if it's evolving further in this extension
• Has there been developer feedback to date? Are you able to summarize it here?
  
• Why an extension, not an I2S or sunset?

Best,

Alex

[Domenic Denicola]

Hey Alex, I hope these help!

On Tuesday, April 15, 2025 at 3:21:34 AM UTC+9 Alex Russell wrote:

Thanks for filing an extension request.

Some questions that weren't clear from the above:

• Is this extension going to involve breaking changes? I saw the TAG's feedback from last year had API shape suggestions, so curious to know if it's evolving further in this extension

We made a lot of breaking changes to the API over the course of the existing origin trial, actually. That included aligning with the TAG's preferred API shape, changing the capabilities-testing API surface, and some more minor ones like censoring download progress. So if you were concerned about the possibility of lock-in, I think we're working hard to avoid it!

For the 137-138 extension request, we plan a couple more, namely restricting from cross-origin iframes (but with a permission policy to delegate back), and removing worker support. But the main goal is to get feedback on the now-more-stable API shape, since things have settled down a bit and developers will be more able to build on what we have.

 

• Has there been developer feedback to date? Are you able to summarize it here?
  

Kenji (cc'ed) may be able to share more, but some of what I can link to include generally-positive quantitative feedback gathered via surveys, and a couple devs sharing their use cases on the GitHub.

 

• Why an extension, not an I2S or sunset?

As mentioned above, we'd like a few more milestones for developers to give us feedback on the newly-stable API shape before we ship. We're hoping to ship soon, though!

[Kenji Baheux]

On Wed, Apr 16, 2025, 10:13 AM Domenic Denicola <dom...@chromium.org> wrote:

Hey Alex, I hope these help!

On Tuesday, April 15, 2025 at 3:21:34 AM UTC+9 Alex Russell wrote:

Thanks for filing an extension request.

Some questions that weren't clear from the above:

• Is this extension going to involve breaking changes? I saw the TAG's feedback from last year had API shape suggestions, so curious to know if it's evolving further in this extension

We made a lot of breaking changes to the API over the course of the existing origin trial, actually. That included aligning with the TAG's preferred API shape, changing the capabilities-testing API surface, and some more minor ones like censoring download progress. So if you were concerned about the possibility of lock-in, I think we're working hard to avoid it!

For the 137-138 extension request, we plan a couple more, namely restricting from cross-origin iframes (but with a permission policy to delegate back), and removing worker support. But the main goal is to get feedback on the now-more-stable API shape, since things have settled down a bit and developers will be more able to build on what we have.

 

• Has there been developer feedback to date? Are you able to summarize it here?
  

Kenji (cc'ed) may be able to share more, but some of what I can link to include generally-positive quantitative feedback gathered via surveys, and a couple devs sharing their use cases on the GitHub.

A more recent snapshot of the quantitative feedback was shared at BlinkOn: bit.ly/blinkon-2025-builtin-ai (slide 34).

We also have direct engagement with partners ready to launch various features enabled by this API, sometimes in conjunction with the Language Detector.

Finally, I haven't checked the latest OT sign ups numbers but we were already order of magnitude above a typical OT which suggests lots of interest in what this API enables.

Overall, the feedback has been very positive and we hope that these last refinements will further increase developers' satisfaction.

[Alex Russell]

thanks for this. LGTM