A JavaScript API for detecting the language of text, with confidence levels.
This feature, like all built-in AI features, has inherent interoperability risks due to the use of AI models whose behavior is not fully specified. See some general discussion in https://www.w3.org/reports/ai-web-impact/#interop. By providing a high-level API with clear output formats, as well as a capabilities API for detecting what a given browser supports, we believe we can guide web developers toward using the API in an interoperable way that does not depend on the specific models that a given browser or browser version uses.
This API will likely frequently be used in concert with the translator API (https://chromestatus.com/feature/5172811302961152). Our current implementation is tied up with the browser's built-in language detection, which runs on the main thread. Alternative architectures are possible and we're exploring the implications of the current one through the origin trial process.
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
None.
Basic tooling suffices
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 language detection. APIs to mock the results might help here.
Origin trial desktop first | 129 |
Origin trial desktop last | 134 |
Origin trial Android first | 129 |
Origin trial Android last | 134 |
Origin trial WebView first | 129 |
Origin trial WebView last | 134 |
LGTM to experiment 129-134 inclusive, or shifted if you can't start in 129.
That said, I would expect things to change during the experiment, including the name. Like TAG I find including "ai" in the programmer visible symbols to be less than optimal. We don't usually put implementation details in names and "ai" in particular is a term that doesn't tell the developer anything useful.
That said, good luck experimenting and may you get useful feedback from your partners.
/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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-WvH-sxxWndwAWPLF3eEYqeLhXrz-VmZKH4Wxzbpse-Q%40mail.gmail.com.