4 ms·

While this might be useful, be mindful: - it's experimental - the "specification" is nowhere near a standards track: https://webmachinelearning.github.io/tran

by troupo 1y ago

While this might be useful, be mindful: - it's experimental - the "specification" is nowhere near a standards track: https://webmachinelearning.github.io/translation-api/ 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 1y ago
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.
moron4hire 1y ago
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 can then start to get standardized.
- troupo 1y ago
  > 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 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
  - moron4hire 1y ago
    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.
    - troupo 1y ago
      > 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 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.

by troupo 1y ago

jazzypants 1y ago

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.

moron4hire 1y ago

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 can then start to get standardized.

troupo 1y ago
> 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 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
- moron4hire 1y ago
  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.
  - troupo 1y ago
    > 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 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.