Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Translator API

developer.mozilla.org

Post reply on HN
Print view View original

61–70 of 71 posts

Re: Web Translator API

#61

Post by moron4hire »

troupo wrote: post #51
moron4hire wrote: post #24

Earlier quoted context omitted.

This is the W3C standardization process. 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 c…

> This is the W3C standardization process. 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 proces…

You're quoting from their literal, W3C-format working draft, quoting the name of the W3C working group that has been formed to standardized this.

Being "standards track" means the spec is out of draft and has been proposed. It does not mean "we intend to standardize this". It means, "we've put in all of the work to standardize this and are waiting on final acceptance".

I don't know what you mean by "isn't supposed to be enabled by default". There is no mention of when browser vendors may or may not ship features in the standardization process.

Re: Web Translator API

#62

Post by troupo »

moron4hire wrote: post #61
troupo wrote: post #51

Earlier quoted context omitted.

> This is the W3C standardization process. 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 proces…

You're quoting from their literal, W3C-format working draft, quoting the name of the W3C working group that has been formed to standardized this. Being "standards track" means the spec is out of draft and has been proposed. It does not mean "we intend to standardize this". It means, "we've put in all of the work to standardize this and are waiting on final acceptance". I don't know what you mean by "isn't supposed to…

> You're quoting from their literal, W3C-format working draft, quoting the name of the W3C working group that has been formed to standardized this.

The literal "Draft Community Group Report" (and not a working draft) is a literal link to w3c standardization process: https://www.w3.org/standards/types/#CG-DRAFT

Since the words "not on the W3C Standards Track" from the document didn't persuade you, you could go to the actual w3c process and answer a few simple questions:

- is "Draft Community Group Report" a document on a standards track?

- what does it take to get on the standards track?

- what does it take to "put in all of the work to standardize this and wait on final acceptance", and how many steps there are between "Draft Community Group Report" and this stage?

> I don't know what you mean by "isn't supposed to be enabled by default".

For a person who is so confidently talking about the w3c standards process, I'm surprised you don't.

w3c doesn't explicitly state this. Except for the final few stages, all steps in the process contain the following: "Software MAY implement these specifications at their own risk but implementation feedback is encouraged."

However.

Since this is browsers we're talking about, it means that whatever browsers ship enabled by default will remain in the wild forever because people will immediately start depending on that implementation.

Additionally, a standard cannot become a standard until there are at least two independent implementations of a proposed feature. This is to eliminate the possibility to ship purely internal APIs, or depend on a single library/implementor.

So the way to do it, especially for APIs that are nowhere close to being "waiting for final acceptance" is: ship behind a flag, iron out issues and differences, perhaps change the API (and changes to API happen all the time), then ship.

Of course, Chrome shits all over this process and just ships whatever it wants to ship.

Re: Web Translator API

#63

Post by dhx »

jannes wrote: post #46
ameliaquining wrote: post #42

Earlier quoted context omitted.

The article explains that this feature uses a small (up to 22 GB) language model that runs on-device. 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 actio…

So installing Chrome is going to require 22 GB of disk space now?

This sounds off by an order of magnitude? Firefox's local translation models are only 20-70MB per language pair direction (e.g. en-to-fr or fr-to-en).[1] These models are also only released when they reach at least -5% of Google Translate's COMET score.[1] Currently Firefox ships with support for 32 xx-to-en language pairs and 29 en-to-xx language pairs.[1] As the number of language pairs increases, it probably isn't unreasonable for browsers to stop bundling every language pair and instead prompt users to download uncommon models the first time the user wants to use them.

[1] https://mozilla.github.io/translations/firefox-models/

Re: Web Translator API

#64

Post by dveditz_ »

yjftsjthsd-h wrote: post #27
sandstrom wrote: post #21

Earlier quoted context omitted.

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

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 th…

The "exposing information about..." bit in the Mozilla statement is fingerprinting/privacy argument like WebKit's

Re: Web Translator API

#65

Post by moron4hire »

troupo wrote: post #62
moron4hire wrote: post #61

Earlier quoted context omitted.

You're quoting from their literal, W3C-format working draft, quoting the name of the W3C working group that has been formed to standardized this. Being "standards track" means the spec is out of draft and has been proposed. It does not mean "we intend to standardize this". It means, "we've put in all of the work to standardize this and are waiting on final acceptance". I don't know what you mean by "isn't supposed to…

> You're quoting from their literal, W3C-format working draft, quoting the name of the W3C working group that has been formed to standardized this. The literal "Draft Community Group Report" (and not a working draft) is a literal link to w3c standardization process: https://www.w3.org/standards/types/#CG-DRAFT Since the words " not on the W3C Standards Track " from the document didn't persuade you, you could go to th…

> However.

No "however". The W3C is not actually a standards body. They don't get to tell people what to do. The W3C even knows this, even though we all colloquially call these things "standards", they're actually just "Recommendations".

The FCC is a standards body. NIST is a standards body. You go against them, you get fined. Messing with weights and measures is one of two crimes defined in the US Constitution, they both come with the death penalty, and the other one is treason.

That's not the W3C. You go against the W3C, worst case scenario, Apple says, "nah, we ain't gonna do that" and then Web devs don't adopt your feature because they can't run it on one of the biggest platforms: Safari on iOS, the only browser allowed to run on iOS.

What you've just pointed out is the W3C explicitly saying it doesn't mind if browser vendors implement features early. They "MAY" do it. And then they remind everyone the risk is on the vendor if the eventual sta... excuse me, "recommendation", diverges from what does eventually get standardized.

Re: Web Translator API

#66

Post by ameliaquining »

djhn wrote: post #60
ameliaquining wrote: post #49

Earlier quoted context omitted.

The article indicates that it will only download the model over an unmetered connection, e.g., while the phone is connected to wifi.

Seems very backwards for markets where wired/wifi connections at home are nonexistant, 4g/5g is already unmetered and phones are the wifi you connect your devices to.

If you have an unlimited data plan then Android counts that as an unmetered connection and Chrome will download the model over it.

Re: Web Translator API

#69

Post by yjftsjthsd-h »

dveditz_ wrote: post #64
yjftsjthsd-h wrote: post #27

Earlier quoted context omitted.

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 th…

The "exposing information about..." bit in the Mozilla statement is fingerprinting/privacy argument like WebKit's

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

Re: Web Translator API

#70

Post by troupo »

moron4hire wrote: post #65
troupo wrote: post #62

Earlier quoted context omitted.

> You're quoting from their literal, W3C-format working draft, quoting the name of the W3C working group that has been formed to standardized this. The literal "Draft Community Group Report" (and not a working draft) is a literal link to w3c standardization process: https://www.w3.org/standards/types/#CG-DRAFT Since the words " not on the W3C Standards Track " from the document didn't persuade you, you could go to th…

> However. No "however". The W3C is not actually a standards body. They don't get to tell people what to do. The W3C even knows this, even though we all colloquially call these things "standards", they're actually just "Recommendations". The FCC is a standards body. NIST is a standards body. You go against them, you get fined. Messing with weights and measures is one of two crimes defined in the US Constitution, they…

> No "however". The W3C is not actually a standards body.

Oh look. You've stopped claiming that this spec is on the standards track, that the final step is just final acceptance, or that there's an actual standardisation process.

You've now switched to saying that this is not an actual standardization process and to pretending that I said something I never did: that w3c enforces standards.

Imagine if you actually knew anything about what you were talking about and argued in good faith.

Adieu.

Post reply on HN