generated from explainers-by-googlers/template
-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we include translation with an unknown source language? #1
Comments
1 task
My opinion is do both ahhaha I'm working with this right now, but using the window.ai modus operandis. and from a dev perspective it is interesting to :
I would also suggest personification as a parameter for the translator agent.
|
I can't really understand your examples, as they seem to be using some syntax other than JavaScript. |
domenic
added a commit
that referenced
this issue
Jul 26, 2024
There are two major motivations for this change: * Splitting translation and language detection into separate APIs, to reflect what we've learned from prototyping. * Aligning better with other built-in API proposals, including future ones, by using shared patterns. This notably removes translation from an unknown source language, closing #1. It also adds AbortSignals and destroy() methods.
domenic
added a commit
that referenced
this issue
Jul 26, 2024
There are two major motivations for this change: * Splitting translation and language detection into separate APIs, to reflect what we've learned from prototyping. * Aligning better with other built-in API proposals, including future ones, by using shared patterns. This notably removes translation from an unknown source language, closing #1. It also adds AbortSignals and destroy() methods. This also removes the tentative proposal for language tag handling, instead pointing to discussions in #11.
Merged
domenic
added a commit
that referenced
this issue
Jul 26, 2024
There are two major motivations for this change: * Splitting translation and language detection into separate APIs, to reflect what we've learned from prototyping. * Aligning better with other built-in API proposals, including future ones, by using shared patterns. This notably removes translation from an unknown source language, closing #1. It also adds AbortSignals and destroy() methods. This also removes the tentative proposal for language tag handling, instead pointing to discussions in #11.
Closed by #15. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is an open question discussed in this part of the explainer. The current proposal includes the ability to translate without specifying a source language, in which case the return type of
translate()
andtranslateStreaming()
will change to include the detected language.The alternative API is to require the web developer to specify the source language. If they don't know it, they can use the language detection part of the API first, and then separately use the translation API.
Both approaches have some precedents:
One factor to note is that bundling together language detection with translation requires the implementation to make a single best-guess at the source language. Whereas, separating the steps allows the detection step to return multiple possibilities, and then the developer can choose what to do with that information.
The text was updated successfully, but these errors were encountered: