const translator = await Translator.create({ sourceLanguage: 'en', targetLanguage: 'fr', });
await translator.translate('Where is the next bus stop, please?');
That said, the "simple way around the paid API" problem is something Google has to deal with anyway, because there are a bunch of ways to use Google Translate without paying for it (e.g., the translate.google.com web UI, or the non-JavaScript-exposed "Translate to [language]" feature built into Chrome), and any action that can be taken by a human can in principle also be taken by a script. The only thing to do about it is use secret-sauce server-side abuse detection to block as much of this activity as they can; they can't get all of it but they can get enough to push enough people onto the paid API that the economics pencil out.
- 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.
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.
Let me quote the site for you
--- start quote ---
This specification was published by the Web Machine Learning Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
--- end quote ---
> So the W3C process is descriptive and encourages a period of competitive divergence in implementations.
That is exactly opposite of how the w3c standardization process works
> 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.
Yes, and until then this work is not supposed to be enabled by default
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.
Any thoughts about it?
Safari/webkit is positive (though no official stance yet):
https://github.com/WebKit/standards-positions/issues/339#iss...
> The spec assumes a certain form of translation backend, exposing information about model availability, download progress, quotas, and usage prediction. We'd like to minimize the information exposure so that the implementation can be more flexible.
reads to me as Chrome once again trying to export itself verbatim as a "standard" and Mozilla pointing out that that's not really applicable to others.
Also the WebKit post seems to raise somewhat similar arguments but on the basis of fingerprinting/privacy problems.
Why not just use the lang= attribute as it was intended, then let the user select text to translate as they wish?
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.
I get that this is one more brick in the wall that teams like LadyBird will have to maintain, but as a web developer I do think more Web API features is generally a good thing, as it makes it easier for smaller shops to implement richer functionality.
I assume every browser will do the same as on-device models start becoming more useful.
Last time I looked I wasn't able to find any easy to run models that supported more than a handful of languages.
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.
Bacause it was, is, and will be Chrome-only for the forseeable future: https://news.ycombinator.com/item?id=44375326
right?
