Skip to content
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

Closed
domenic opened this issue Apr 10, 2024 · 3 comments
Closed

Should we include translation with an unknown source language? #1

domenic opened this issue Apr 10, 2024 · 3 comments

Comments

@domenic
Copy link
Collaborator

domenic commented Apr 10, 2024

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() and translateStreaming() 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.

@MuraraAllan
Copy link

MuraraAllan commented Jul 19, 2024

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 :


const translator = await translator.create({
  sourceLanguage: <strlang || languageList><translator.identifiedSourceLanguage><browser.language><browser.intlLanguage>
  targetLanguage: <strlang || languageList><browser.languageOption2>
});
Which would allow : 
.translate("browsers have so many interesting stuff going on this days")
outputs "browsers tem tanta coisa interessante acontecendo nesses dias".
.translate("text", {
  sourceLanguage: <opt><translator.identifiedSourceLanguage><browser.language><browser.intlLanguage>
  targetLanguage: <opt><browser.languageOption2>,
})

I would also suggest personification as a parameter for the translator agent.

.translate("text", {
  sourceLanguage: <opt><translator.identifiedSourceLanguage><browser.language><browser.intlLanguage>,
  targetLanguage: <opt><browser.language>, \n
  outputs: "adopt awesome_translation_agent; reproc(<awesome_translation_agent outputs exclusively in JSON;" - inference over the inference. Totally just "shots there"
})

@domenic
Copy link
Collaborator Author

domenic commented Jul 20, 2024

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.
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.
@domenic
Copy link
Collaborator Author

domenic commented Jul 26, 2024

Closed by #15.

@domenic domenic closed this as completed Jul 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants