So, this is Google Translate built running locally in Chrome? I wonder if it is a small/degraded model or limited languages? Otherwise, how is it not a simple way around the paid Google API?
Of course it's already shipped in Chrome, and now Chrome pretends that its own Chrome-only API is somehow standard. Expect people on HN to blame other browsers for not shipping this.
I've been pleasantly surprised by the last few conversations about this type of thing that I've seen. It seems like people are pretty sick of Chrome's IE proclivities.
The W3C is not a prescriptive standardization body. It doesn't have any regulatory power giving it any teeth to go after vendors acting in bad faith. So the W3C process is descriptive and encourages a period of competitive divergence in implementations. It is only after the early adopters have hammered on the features and figured out which parts they like best that a Web API can then start to get standardized.
Basically, the 'translate this' button you see on Twitter or Instagram next to comments in foreign languages. This API would make it trivial for all developers to add that to their web apps.
If this API will be implemented in next few years, there will be browsers who hold up the world in progress.
Linguist have enough many users, so we could expose this API for client side code, and users with browsers where Translation API is not implemented yet, could install Linguist and sites who uses Translation API would works fine. Translation API calls would proxy by Linguist and preferred translator module would be used.
If it's a HTML attribute, then you can only use it with DOM elements, with no control about when it runs.
Instead, a JS API gives more flexibility and control.
Besides, I think the "lang" attribute is supposed to signal what the language of the text inside that element is, not what it could/should be. So even if going with attributes would be the way forward, a new one would need to be created.
The is no guarantee when it will be garbage collected. For large local models that use a lot of resources they should be unloaded as soon as possible to allow other programs on the computer to use the resources.
Can we please NOT autotranslate the web? I have yet to find a site where the quality of autotranslate does not make me stop using that site. I was already irritated when google started to show me de.wikipedia.org articles adespite me explicitly searching for the english article name. Then came Etsy, where the autotranslate quality was so bad I stopped using the site altogether.
The good news is that if the browsers offered this natively, websites wouldn't need their own implementation of this. And if it's in the client (the browser), you're most likely gonna be able to turn it off globally, just like how you like it.
Worst case scenario a user-script/extension could monkey patch it out, but probably clients will let you disable it.
Rather, it's an API developers can use to add inline translation to web apps.
For example, under a comment in your app, you can (a) detect the language, and (b) if it's different from the current users/browsers language, offer to translate it with a small link (c) if the user clicks the link, the content is translated to their language.
I was excited that Firefox finally exposed its local translations as API, but it's Chrome-only (still?). Will be nice for userscripts, for example to replace Twitter's translation button that hardly ever works
So, the browsers have to provide some means for choosing the desired translation engine (add-on API maybe?) and this is a standard API which all of the providers should implement.
sfmz|8 months ago
const translator = await Translator.create({ sourceLanguage: 'en', targetLanguage: 'fr', });
await translator.translate('Where is the next bus stop, please?');
ks2048|8 months ago
troupo|8 months ago
- it's experimental
- the "specification" is nowhere near a standards track: https://webmachinelearning.github.io/translation-api/
Of course it's already shipped in Chrome, and now Chrome pretends that its own Chrome-only API is somehow standard. Expect people on HN to blame other browsers for not shipping this.
jazzypants|8 months ago
moron4hire|8 months ago
The W3C is not a prescriptive standardization body. It doesn't have any regulatory power giving it any teeth to go after vendors acting in bad faith. So the W3C process is descriptive and encourages a period of competitive divergence in implementations. It is only after the early adopters have hammered on the features and figured out which parts they like best that a Web API can then start to get standardized.
sandstrom|8 months ago
Basically, the 'translate this' button you see on Twitter or Instagram next to comments in foreign languages. This API would make it trivial for all developers to add that to their web apps.
greatgib|8 months ago
vitonsky|8 months ago
If this API will be implemented in next few years, there will be browsers who hold up the world in progress.
Linguist have enough many users, so we could expose this API for client side code, and users with browsers where Translation API is not implemented yet, could install Linguist and sites who uses Translation API would works fine. Translation API calls would proxy by Linguist and preferred translator module would be used.
Any thoughts about it?
RockRobotRock|8 months ago
sandstrom|8 months ago
Safari/webkit is positive (though no official stance yet):
https://github.com/WebKit/standards-positions/issues/339#iss...
pwdisswordfishz|8 months ago
Why not just use the lang= attribute as it was intended, then let the user select text to translate as they wish?
diggan|8 months ago
Instead, a JS API gives more flexibility and control.
Besides, I think the "lang" attribute is supposed to signal what the language of the text inside that element is, not what it could/should be. So even if going with attributes would be the way forward, a new one would need to be created.
tempodox|8 months ago
rhabarba|8 months ago
Raed667|8 months ago
I assume every browser will do the same as on-device models start becoming more useful.
tempodox|8 months ago
seabass|8 months ago
charcircuit|8 months ago
lynx97|8 months ago
diggan|8 months ago
Worst case scenario a user-script/extension could monkey patch it out, but probably clients will let you disable it.
sandstrom|8 months ago
Rather, it's an API developers can use to add inline translation to web apps.
For example, under a comment in your app, you can (a) detect the language, and (b) if it's different from the current users/browsers language, offer to translate it with a small link (c) if the user clicks the link, the content is translated to their language.
lofaszvanitt|8 months ago
minus7|8 months ago
troupo|8 months ago
Bacause it was, is, and will be Chrome-only for the forseeable future: https://news.ycombinator.com/item?id=44375326
indeyets|8 months ago
right?
mediumsmart|8 months ago
pabs3|8 months ago
nachomg|8 months ago
eeee11|8 months ago
eeee11|8 months ago
lofaszvanitt|8 months ago
curtisszmania|8 months ago
[deleted]