Intent to Experiment: Language Detector API
Domenic Denicola
Contact emails
dom...@chromium.org, fer...@chromium.org, kenji...@chromium.orgExplainer
https://github.com/WICG/translation-api/blob/main/README.mdSpecification
None yet, although we're excited to start writing one during the trial.Summary
A JavaScript API for detecting the language of text, with confidence levels.
Blink component
Blink>AI>Language DetectionTAG review
https://github.com/w3ctag/design-reviews/issues/948TAG review status
Issues open: "satisfied with concerns", mainly around naming.Risks
Interoperability and Compatibility
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.
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:
Ergonomics
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.
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
Our main goal for the origin trial is to get feedback on model quality and performance when faced with real-world use cases from developers. For example, we are interested in how often multilingual input is provided and what developers expect for such cases (https://github.com/WICG/translation-api/issues/13).We also expect to get some feedback on the API shape (which will likely evolve throughout the trial), and how limiting the current architecture's ability to only run after page load is.
Ongoing technical constraints
None.
Debuggability
Basic tooling suffices
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
YesIs this feature fully tested by web-platform-tests?
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 language detection. APIs to mock the results might help here.
Flag name on chrome://flags
language-detection-apiFinch feature name
LanguageDetectionAPIRequires code in //chrome?
FalseMeasurement
kV8LanguageDetector_Detect_MethodEstimated milestones
| 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 |