Overhaul availability testing and add expected language options #22
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
I'm becoming more convinced this is correct. I will try to add those changes on this branch, first in the explainer, then the spec. |
These solve the problem discussed in webmachinelearning/prompt-api#29 and #16. They provide a mechanism for web developers to tell the browser to download additional material to support additional languages, and for web developers to get early errors if they know they will be trying to use a language that isn't supported. It also clearly separates input, context, and output languages, with a requirement on how the output language is produced by default (match the input). This removes the languageAvailable() API, folding it into createOptionsAvailable(). Further work might remove the AISummarizerCapabilities object altogether, since now it's mostly a wrapper around the single createOptionsAvailable() method.
domenic
force-pushed
the
language-settings
branch
from
491322d to
f2f79d4
Compare
domenic
changed the title
This was referenced Dec 12, 2024
Open
aarongable
pushed a commit
to chromium/chromium
that referenced
this pull request
Dec 13, 2024
Add CoreOptions dictionaries with new tone|format|length enums. Add factory availability() methods and helpers with skeleton impls. Update and expand some test coverage. Update API shape to better match latest explainer updates: https://github.com/WICG/writing-assistance-apis webmachinelearning/writing-assistance-apis#22 TODO: Expand chrome/browser/ai/ai_[re]writer_unittest.cc coverage: - Add AIRewriterTest RewritePlainText and RewriteMarkdown. - Add AIWriterTest coverage for tone, format, length options. Bug: 380088820, 382596381, 382615217, 380239468 Test: Shape better matches explainer and naive impl WAI. Change-Id: I7e6c569adf30c6324038b7ee8738a4689c2b2838 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6071867 Reviewed-by: Brad Triebwasser <[email protected]> Auto-Submit: Mike Wasserman <[email protected]> Reviewed-by: Will Harris <[email protected]> Reviewed-by: Clark DuVall <[email protected]> Commit-Queue: Clark DuVall <[email protected]> Cr-Commit-Position: refs/heads/main@{#1396042}
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.
DO NOT MERGE YET AS THE SPEC IS NOT FULLY UPDATED, JUST THE EXPLAINER
Add options for
expectedInputLanguages,expectedContextLanguages, andoutputLanguage. 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 accompanyingAI*Capabilitiesclasses. The reasoning is as follows:Those classes had three APIs:
available,createOptionsAvailable(), andlanguageAvailable().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 intocreateOptionsAvailable(). But then, we can note that theavailableproperty 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 tocreate()is supported.This was previously done via
(await ai.apiName.capabilities()).createOptionsAvailable(). We instead expose it viaawait 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 tocapabilities(), for later sync access. Now we can just retrieve the relevant information during the call toavailability().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.
Preview | Diff