←back to thread

Web Translator API

(developer.mozilla.org)
97 points kozika | 3 comments | 25 Jun 25 08:02 UTC | HN request time: 0.626s | source
Show context
RockRobotRock ◴[25 Jun 25 11:20 UTC] No.44375977[source]▶
https://github.com/mozilla/standards-positions/issues/1015
replies(1): >>44376917 #
sandstrom ◴[25 Jun 25 13:10 UTC] No.44376917[source]▶
I honestly don't understand the arguments Mozilla have against it.

Safari/webkit is positive (though no official stance yet):

https://github.com/WebKit/standards-positions/issues/339#iss...

replies(1): >>44377142 #
1. yjftsjthsd-h ◴[25 Jun 25 13:32 UTC] No.44377142[source]▶
I don't know enough to understand the DOM argument, but

> 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.

replies(1): >>44389790 #
2. dveditz_ ◴[26 Jun 25 18:08 UTC] No.44389790[source]▶
The "exposing information about..." bit in the Mozilla statement is fingerprinting/privacy argument like WebKit's
replies(1): >>44393781 #
3. yjftsjthsd-h ◴[27 Jun 25 04:48 UTC] No.44393781[source]▶
Maybe? I read that as more of a compatibility thing; if sites depend on information that Chrome exposes, then it's easy for them to have bugs on browsers that don't expose the exact same information (possibly by way of that information not even existing or making sense for a different implementation).