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
On 2024-10-24 05:33, Domenic Denicola wrote:
Thanks Yoav!
Unfortunately there was a slight miscommunication within the team
about the timeline, and the actual goal is M131-M136, possibly
slipping to M132-M137. Very sorry about that!
It sounds like 1 milestone plus or minus is not a big deal in general,
but if you or someone else were able to give an explicit LGTM for that
timeline, that would set our minds at ease.
-Domenic
On Thu, Oct 24, 2024 at 12:43 AM Yoav Weiss (@Shopify)
<yoavwe...@chromium.org> wrote:
LGTM1 to experiment M132-137 (give or take an off-by-one error)
On Tuesday, October 22, 2024 at 11:16:49 PM UTC-7 Domenic Denicola
wrote:
Contact emails
dome...@chromium.org, fer...@chromium.org,
kenjibah...@chromium.org
Explainer
https://github.com/WICG/translation-api/blob/main/README.md
<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
Blink>AI>Translate
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EAI%3ETranslate>
TAG review
https://github.com/w3ctag/design-reviews/issues/948
<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.
I agree there's relatively high degree of risk here. As you
mention below, there are open questions regarding the tradeoff
between usefulness, user experience and privacy and where we want
to draw that line.
This is exactly why I think it's important to experiment with this
and understand what the right balance is.
Gecko: No signal
(https://github.com/mozilla/standards-positions/issues/1015
<https://github.com/mozilla/standards-positions/issues/1015>)
WebKit: No signal
(https://github.com/WebKit/standards-positions/issues/339
<https://github.com/WebKit/standards-positions/issues/339>)
Web developers: Positive
(https://github.com/WICG/proposals/issues/147
<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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
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
<https://issues.chromium.org/issues/322229993>
Measurement
kV8LanguageTranslator_Translate_Method
Estimated milestones
Origin trial desktop first
132
Origin trial desktop last
137
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
<https://github.com/WICG/translation-api/issues/11>.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5172811302961152?gate=5068777028059136
<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
<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
<https://chromestatus.com/> and edited by hand.
--
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+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-sJFwO6WZxZFu8_4nAvpW7OPyWi2yqqMFcQSXreiUtDg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-sJFwO6WZxZFu8_4nAvpW7OPyWi2yqqMFcQSXreiUtDg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d790761a-0134-4ad2-b821-633c9a80e2c6%40gmail.com.
