canXYZ() naming maybe implies boolean return values #19
Comments
domenic
added a commit
to webmachinelearning/writing-assistance-apis
that referenced
this issue
Oct 9, 2024
* Rename from supportsInputLanguage() to languageAvailable(), to match the language detection API. Closes #7. (See also webmachinelearning/translation-api#19.) * Consolidate the various supportsXYZ() methods into a single createOptionsAvailable() method. This avoids the issue noted in webmachinelearning/translation-api#19, aligns us with the "available" suffix, and most importantly, lets a browser signal that it doesn't support certain combinations. (For example, Chrome right now doesn't support some combinations for the writer API.)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In addition to the discussions in #7 and #12 about these methods, a simpler problem is that most people expect that a method starting with "can" to return a boolean value.
Maybe if we went in the direction of #7, "can" would still be an OK prefix. But probably we should pick something different, e.g.
languageAvailable()/languagePairAvailable().The text was updated successfully, but these errors were encountered: