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