Overhaul availability testing and add expected input languages for detector #31
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead, we replace them with createOptionsAvailable() for translator, and canDetect() for language detector. Closes #24.
domenic
force-pushed
the
no-capabilities
branch
from
c320383 to
6981c9c
Compare
…r languageDetector
domenic
changed the title
domenic
added a commit
to webmachinelearning/writing-assistance-apis
that referenced
this pull request
Jan 17, 2025
* Add options for `expectedInputLanguages`, `expectedContextLanguages`, and `outputLanguage`. The former two are used for downloading additional material and early errors if the web developer's required input/context languages cannot be supported by the browser. The latter gives clarity about what to do given mixed-language inputs. * Remove the `capabilities()` method and the accompanying `AI*Capabilities` classes. The reasoning is as follows: Those classes had three APIs: `available`, `createOptionsAvailable()`, and `languageAvailable()`. `languageAvailable()` wasn't clear if it was talking about input, context, or output languages. Now that we have explicit options for those three, we could fold language availability testing into `createOptionsAvailable()`. But then, we can note that the `available` property is kind of useless, as just knowing that some possible combination of options/languages is supported is not helpful for any known use case. So, the only real functionality we care about is testing whether a given set of options to `create()` is supported. This was previously done via `(await ai.apiName.capabilities()).createOptionsAvailable()`. We instead expose it via `await ai.apiName.availability()`. This name is a bit clearer, and this design also avoids the complexity where we have to retrieve all the availability information for every combination of options during the call to `capabilities()`, for later sync access. Now we can just retrieve the relevant information during the call to `availability()`. This was previously discussed in webmachinelearning/prompt-api#29; see especially webmachinelearning/prompt-api#29 (comment). Closes #16. See also webmachinelearning/prompt-api#69 and webmachinelearning/translation-api#31.
domenic
added a commit
to webmachinelearning/prompt-api
that referenced
this pull request
Jan 17, 2025
Remove the `ai.languageModel.capabilities()` method and its accompanying `AILanguageModelCapabilities` class. Instead, replace it with: * `ai.languageModel.availability(options)`, which takes the same options as `ai.languageModel.create()`, and returns the corresponding availability. * `ai.languageModel.params()`, which returns the default and max params (currently top-K and temperature). Additionally, add the `expectedInputLanguages` option to `create()` and `availability()`. The addition of this option to `create()` allows the web developer to signal the expected input languages ahead of time, allowing the downloading of additional material, or fast-failing if the additional material cannot be supported. The addition of this option to `availability()` replaces the `(await ai.languageModel.capabilities()).languageAvailable()` method. Closes #29; see especially #29 (comment). See also webmachinelearning/writing-assistance-apis#22 and webmachinelearning/translation-api#31.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add an
expectedInputLanguagesoption to language detector creation API. This allows the browser to download relevant material if necessary, or fail-fast if a language the web developer needs to support is not available.Then, remove the
capabilities()methods and the accompanyingAI*Capabilitiesclasses.For translator, the only useful capabilities API was
(await ai.translator.capabilities()).languagePairAvailable(). We simplify this toawait ai.translator.availability(). This design also avoids the complexity where we have to retrieve all the availability information for every combination of options during the call tocapabilities(), for later sync access. Now we can just retrieve the relevant information during the call toavailability().Also, by unifying on using the same options for
create()andavailability(), we fix ShouldlanguagePairAvailable()accept{sourceLanguage, targetLanguage}instead of two parameters? #24.For language detector, the capabilities supplied both
(await ai.languageDetector.capabilities()).availableand(await ai.languageDetector.capabilities()).languageAvailable(). We simplify this intoawait ai.languageDetector.availability(), which can either take no arguments (emulatingavailable) or take the same{ expectedInputLanguages }argument ascreate()(emulatinglanguageAvailable()).See also webmachinelearning/writing-assistance-apis#22 and webmachinelearning/prompt-api#69.
Preview | Diff