This proposal introduces a new JavaScript API for exposing a browser's existing language translation abilities to web pages.
Browsers are increasingly offering language translation to their users. Such translation capabilities can also be useful to web developers. This is especially the case when browser's built-in translation abilities cannot help, such as: - translating user input or other interactive features; - pages with complicated DOMs which trip up browser translation; - providing in-page UI to start the translation; or - translating content that is not in the DOM, e.g. spoken content. To perform translation in such cases, web sites currently have to either call out to cloud APIs, or bring their own translation models and run them using technologies like WebAssembly and WebGPU.
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.
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.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Basic tooling should be sufficient
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.
No milestones specified
--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8n%2BfTnOL502H8D6e2xXWT2zQj_2-gc6_8L4oBh1GWT5A%40mail.gmail.com.
--
Hi Domenic, et al.,This intent came up in the OWP sec review today. We wonder whether there's XSS potential, and how input with plain text interspersed with tags is meant to be handled:Several of the use cases seem to hint at the input being HTML strings (e.g. "pages with complicated DOM"). If the intended input would indeed be HTML strings, and the output is intended to be parsed & inserted into the DOM, then this basically implements a new XSS factory. In addition to the existing re-parsing risks, it would add new ones based on translation (e.g. "<schrift>" turning into "<script>"). The browser's built-in translation functionality can avoid this by only manipulating text nodes; but this would be difficult to replicate in a string-based API.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLnSczrhh2aFMJV3eHWmJA4LBfRFZ2ORcE39o5_%3D-GZJ9w%40mail.gmail.com.
This effort seems worthwhile, and would like to see an explainer that discisses the various API options; that might provide some context for the security conversation.
Ah, thanks. I'd missed that.I don't see any considered alternatives in that doc.
The streaming return value seems like it should, at a minimum, cause us to want to update the setHTML and innerHTML/innerText systems to handle stream assignments.
Also, do streamed translations ever backtrack? E.g., do systems ever produce partial translations that they then change?
Contact emails
dom...@chromium.org, fergal@chromium.org, kenjibaheux@chromium.org