diff --git a/report.json b/report.json
index 8ffbea28..a3467467 100644
--- a/report.json
+++ b/report.json
@@ -3624,7 +3624,6 @@
"w3c/W3CLifecycleEventsBundle",
"w3c/W3CPasswordStrengthBundle",
"w3c/w3process",
- "w3c/wai-about-w3c-process",
"w3c/wai-about-wai",
"w3c/wai-accessibility-principles",
"w3c/wai-act-quickref",
@@ -3650,7 +3649,6 @@
"w3c/wai-easy-checks",
"w3c/wai-eo-online-learning",
"w3c/wai-eval-overview",
- "w3c/wai-eval-standards",
"w3c/wai-eval-tools",
"w3c/wai-evaluation-tools-list",
"w3c/wai-fundamentals-overview",
@@ -6653,7 +6651,6 @@
"w3c/voiceinteraction",
"w3c/w3c-track-2019",
"w3c/w3c-website-redesign-html",
- "w3c/wai-about-w3c-process",
"w3c/wai-about-wai",
"w3c/wai-accessibility-principles",
"w3c/wai-arrm",
@@ -6674,7 +6671,6 @@
"w3c/wai-easy-checks",
"w3c/wai-eo-online-learning",
"w3c/wai-eval-overview",
- "w3c/wai-eval-standards",
"w3c/wai-evaluation-tools-list",
"w3c/wai-fundamentals-overview",
"w3c/wai-home",
@@ -8933,6 +8929,10 @@
"repo": "w3c/device-posture",
"error": "gh-pages branch review is not required"
},
+ {
+ "repo": "w3c/deviceorientation",
+ "error": "main branch review is not required"
+ },
{
"repo": "w3c/did-core",
"error": "main branch review is not required"
@@ -9799,7 +9799,7 @@
}
]
},
- "timestamp": "2024-05-07T00:17:49.129Z",
+ "timestamp": "2024-05-08T00:18:31.998Z",
"repos": [
{
"id": "MDEwOlJlcG9zaXRvcnk4MTAyMTg2MA==",
@@ -34191,7 +34191,7 @@
},
{
"pattern": "main",
- "requiredApprovingReviewCount": 1,
+ "requiredApprovingReviewCount": 0,
"requiredStatusCheckContexts": [],
"isAdminEnforced": false
}
@@ -88264,7 +88264,7 @@
"body": "# Code of Conduct\n\nAll documentation, code and communication under this repository are covered\nby the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/).\n"
},
"readme": {
- "text": "# Verifiable Credentials for ReSpec\n\nThis ReSpec extension enhances the \n[Verifiable Credential](https://www.w3.org/TR/vc-data-model/) \nexamples in your specification.\n\nThe [Verifiable Credentials](https://www.w3.org/TR/vc-data-model/) \nextension to the [ReSpec](https://respec.org/docs/#abstract) \ndocument authoring environment enables authors to express simple \nexamples of [credentials](https://www.w3.org/TR/vc-data-model/#abstract) \nin their specification which are then enhanced by this extension to \nshow the digitally signed forms of the credential. An example of the \noutput of this extension is provided below (this extension adds the\ntabs seen in the image below):\n\n\n\n# Usage\n\nTo use this extension, include the following line in your ReSpec file:\n\n```html\n\n```\n\nNote that there might be releases later than the one listed above. \nCheck this repository's [tags](https://github.com/digitalbazaar/respec-vc/tags) \nfor all known releases.\n\n# ReSpec Markup\n\nTo use this extension, you must add the `vc` class to your examples\nand optionally provide a digital proof verification method (e.g., \na URL to a public key) via the `data-vc-vm` attribute.\n\n```html\n\n{\n \"@context\": [\n \"https://www.w3.org/2018/credentials/v1\",\n \"https://www.w3.org/2018/credentials/examples/v1\"\n ],\n \"id\": \"http://example.edu/credentials/3732\",\n \"type\": [\"VerifiableCredential\", \"UniversityDegreeCredential\"],\n \"issuer\": \"https://example.edu/issuers/565049\",\n \"issuanceDate\": \"2010-01-01T00:00:00Z\",\n \"credentialSubject\": {\n \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n \"degree\": {\n \"type\": \"BachelorDegree\",\n \"name\": \"Bachelor of Science and Arts\"\n }\n }\n}\n\n```\n"
+ "text": "# Verifiable Credentials for ReSpec\n\nThis ReSpec extension enhances the\n[Verifiable Credential](https://www.w3.org/TR/vc-data-model/)\nexamples in your specification.\n\nThe [Verifiable Credentials](https://www.w3.org/TR/vc-data-model/)\nextension to the [ReSpec](https://respec.org/docs/#abstract)\ndocument authoring environment enables authors to express simple\nexamples of [credentials](https://www.w3.org/TR/vc-data-model/#abstract)\nin their specification which are then enhanced by this extension to\nshow the digitally signed forms of the credential. An example of the\noutput of this extension is provided below (this extension adds the\ntabs seen in the image below):\n\n\n\n# Usage\n\nTo use this extension, include the following line in your ReSpec file:\n\n```html\n\n```\n\nNote that there might be releases later than the one listed above.\nCheck this repository's [tags](https://github.com/digitalbazaar/respec-vc/tags)\nfor all known releases.\n\n# ReSpec Markup\n\nTo use this extension, you must add the `vc` class to your examples\nand optionally provide a digital proof verification method (e.g.,\na URL to a public key) via the `data-vc-vm` attribute.\n\n```html\n\n{\n \"@context\": [\n \"https://www.w3.org/2018/credentials/v1\",\n \"https://www.w3.org/2018/credentials/examples/v1\"\n ],\n \"id\": \"http://example.edu/credentials/3732\",\n \"type\": [\"VerifiableCredential\", \"UniversityDegreeCredential\"],\n \"issuer\": \"https://example.edu/issuers/565049\",\n \"issuanceDate\": \"2010-01-01T00:00:00Z\",\n \"credentialSubject\": {\n \"id\": \"did:example:ebfeb1f712ebc6f1c276e12ec21\",\n \"degree\": {\n \"type\": \"BachelorDegree\",\n \"name\": \"Bachelor of Science and Arts\"\n }\n }\n}\n\n```\n\n# Development\n\n```sh\n$ npm i\n$ npm run build # build and watch index.js changes\n$ npm run start # serve this directory\n```\n"
},
"w3c": {
"contacts": [
@@ -112872,7 +112872,7 @@
"owner": {
"login": "w3c"
},
- "isArchived": false,
+ "isArchived": true,
"homepageUrl": "",
"description": null,
"isPrivate": false,
@@ -112958,15 +112958,7 @@
"license": null,
"codeOfConduct": null,
"readme": {
- "text": "[](https://app.netlify.com/sites/wai-about-w3c-process/deploys)"
- },
- "w3c": {
- "contacts": [
- "slhenry"
- ],
- "repo-type": [
- "article"
- ]
+ "text": "> [!IMPORTANT]\n> This repository has been archived 7 May 2024.\n>\n> [How WAI Develops Accessibility Standards through the W3C Process](https://www.w3.org/WAI/standards-guidelines/w3c-process/) is now edited in the [wai-website](https://github.com/w3c/wai-website) repository.\n"
}
},
{
@@ -115846,7 +115838,7 @@
"owner": {
"login": "w3c"
},
- "isArchived": false,
+ "isArchived": true,
"homepageUrl": "",
"description": null,
"isPrivate": false,
@@ -115912,15 +115904,7 @@
"license": null,
"codeOfConduct": null,
"readme": {
- "text": "[](https://app.netlify.com/sites/wai-eval-standards/deploys)"
- },
- "w3c": {
- "contacts": [
- "slhenry"
- ],
- "repo-type": [
- "article"
- ]
+ "text": "> [!IMPORTANT]\n> This repository has been archived 7 May 2024.\n>\n> [Evaluation Standards Overview - ACT & EARL](https://www.w3.org/WAI/standards-guidelines/evaluation/) is now edited in the [wai-website](https://github.com/w3c/wai-website) repository.\n"
}
},
{
@@ -140813,7 +140797,7 @@
"body": "# Code of Conduct\n\nAll documentation, code and communication under this repository are covered by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/).\n"
},
"readme": {
- "text": "# Web of Things (WoT) Profile\n[](https://twitter.com/W3C_WoT)\n[]( https://stackoverflow.com/questions/tagged/web-of-things)\n\nGeneral information about the Web of Things can be found on https://www.w3.org/WoT/.\n \n---\nThis repository is for discussion and development of the \n**[Web of Things (WoT) Profile](http://w3c.github.io/wot-profile/)** deliverable.\n\nThis specification serves two purposes:\n\n- It defines a generic **Profiling Mechanism** which\nprovides a mechanism to describe a profile in an unambiguous way.\nThis mechanism can be used to define additional profiles.\n\n- In addition it defines a **set of profiles** of the Thing Description \nfor use with selected protocols. The WoT Profile Specification formalizes\nthe results of several plug-fests that were conducted by the WoT\nInterest Group and of tests that were conducted as part of the\ndevelopment. It is expected that additional profiles for thing\ntemplates and other protocols will be defined in the near future.\n\nDevices that constrain their use of the Thing Description to the Profiles defined by the \n**WoT Profile Specification** can **interoperate other out-of-the-box**.\n\nA rendered version of the WoT profile specification is available at: [WoT Profile](http://w3c.github.io/wot-profile/)\n\nMotivation:\n\nThe [W3C Web of Things Architecture](https://www.w3.org/TR/wot-architecture/) and \n[Web of Things Thing Description](https://www.w3.org/TR/wot-thing-description/) \ndefine a powerful mechanism and a format to describe myriads of very\ndifferent devices, which may be connected over various protocols. The\nformat is very flexible and open and puts very few normative\nrequirements on devices that implement it.\n\n\t\t\nHowever, this flexibility de-facto prevents interoperability, since,\nwithout additional rules, it allows implementers to\nmake many choices that do not provide guarantees of\ncommon behavior between implementations.\n\nThese rules have to be prescriptive, to ensure that compliant\nimplementations satisfy the semantic guarantees, that are implied by\nthem. We call this set of rules a **Profile**.\n\nWoT Profile work is conducted as part of the WoT architecture TF, \nplease see https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf\nfor more information and call logistics.\n"
+ "text": "# Web of Things (WoT) Profile\n[](https://w3c.social/@wot)\n[](https://twitter.com/W3C_WoT)\n[]( https://stackoverflow.com/questions/tagged/web-of-things)\n\nGeneral information about the Web of Things can be found on https://www.w3.org/WoT/.\n\n---\nThis repository is for discussion and development of the\n**[Web of Things (WoT) Profile](http://w3c.github.io/wot-profile/)** deliverable.\n\nThis specification serves two purposes:\n\n- It defines a generic **Profiling Mechanism** which\nprovides a mechanism to describe a profile in an unambiguous way.\nThis mechanism can be used to define additional profiles.\n\n- In addition it defines a **set of profiles** of the Thing Description\nfor use with selected protocols. The WoT Profile Specification formalizes\nthe results of several plug-fests that were conducted by the WoT\nInterest Group and of tests that were conducted as part of the\ndevelopment. It is expected that additional profiles for thing\ntemplates and other protocols will be defined in the near future.\n\nDevices that constrain their use of the Thing Description to the Profiles defined by the\n**WoT Profile Specification** can **interoperate other out-of-the-box**.\n\nA rendered version of the WoT profile specification is available at: [WoT Profile](http://w3c.github.io/wot-profile/)\n\nMotivation:\n\nThe [W3C Web of Things Architecture](https://www.w3.org/TR/wot-architecture/) and\n[Web of Things Thing Description](https://www.w3.org/TR/wot-thing-description/)\ndefine a powerful mechanism and a format to describe myriads of very\ndifferent devices, which may be connected over various protocols. The\nformat is very flexible and open and puts very few normative\nrequirements on devices that implement it.\n\n\nHowever, this flexibility de-facto prevents interoperability, since,\nwithout additional rules, it allows implementers to\nmake many choices that do not provide guarantees of\ncommon behavior between implementations.\n\nThese rules have to be prescriptive, to ensure that compliant\nimplementations satisfy the semantic guarantees, that are implied by\nthem. We call this set of rules a **Profile**.\n\nWoT Profile work is conducted as part of the WoT architecture TF,\nplease see https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf\nfor more information and call logistics.\n"
},
"prpreview": {
"src_file": "index.html",
@@ -154746,7 +154730,7 @@
"body": "Please find the code of conduct at https://github.com/WebAssembly/meetings/blob/main/CODE_OF_CONDUCT.md.\n"
},
"readme": {
- "text": "[](https://github.com/WebAssembly/stack-switching/actions/workflows/ci-spec.yml)\n[](https://github.com/WebAssembly/stack-switching/actions/workflows/ci-interpreter.yml)\n\n# spec\n\nThis repository holds a prototypical reference implementation for WebAssembly,\nwhich is currently serving as the official specification. Eventually, we expect\nto produce a specification either written in human-readable prose or in a formal\nspecification language.\n\nIt also holds the WebAssembly testsuite, which tests numerous aspects of\nconformance to the spec.\n\nView the work-in-progress spec at [webassembly.github.io/spec](https://webassembly.github.io/spec/).\n\nAt this time, the contents of this repository are under development and known\nto be \"incomplet and inkorrect\".\n\nParticipation is welcome. Discussions about new features, significant semantic\nchanges, or any specification change likely to generate substantial discussion\nshould take place in\n[the WebAssembly design repository](https://github.com/WebAssembly/design)\nfirst, so that this spec repository can remain focused. And please follow the\n[guidelines for contributing](Contributing.md).\n\n# citing\n\nFor citing WebAssembly in LaTeX, use [this bibtex file](wasm-specs.bib).\n"
+ "text": "# Stack-Switching Proposal for WebAssembly\n\nThis repository is a clone of\n[`WebAssembly/spec`](https://github.com/WebAssembly/spec/). It is meant for\ndiscussion, prototype specification, and implementation of a proposal to add\nsupport for stack-switching.\n\nThere are currently two active stack-switching proposals: Typed Continuations\n(aka WasmFX) and Bag of Stacks. Documentation about each proposal is available\nin separate directories of the `main` branch of this repository (as detailed\nbelow).\n\nIn order to minimise future difficulties merging upstream, the two\ncorresponding extensions to the reference interpreter will be\nmaintained in separate branches (as detailed below).\n\n## Typed Continuations Proposal\n\n* See the [explainer](proposals/continuations/Explainer.md) for a high-level\n summary of the proposal.\n\n* See the [overview](proposals/continuations/Overview.md) for a more formal\n description of the proposal.\n\n* See the [examples](proposals/continuations/examples) for Wasm code for\n implementing various different features including lightweight threads, actors,\n and async/await.\n\n* An\n[implementation](https://github.com/WebAssembly/stack-switching/tree/wasmfx) is\navailable as an extension to the reference interpreter. It is accesible from the\n`wasmfx` branch.\n\n## Bag of Stacks Proposal\n\n* See the [explainer](proposals/bag-o-stacks/Explainer.md) for a high-level\n summary of the proposal.\n\n* An extension to the reference interpreter will be made available in the\n`bag-o-stacks` branch in due course.\n\n\nOriginal README from upstream repository follows.\n\n--------------------------------------------------------------------------------\n\n[](https://github.com/WebAssembly/stack-switching/actions/workflows/ci-spec.yml)\n[](https://github.com/WebAssembly/stack-switching/actions/workflows/ci-interpreter.yml)\n\n# spec\n\nThis repository holds a prototypical reference implementation for WebAssembly,\nwhich is currently serving as the official specification. Eventually, we expect\nto produce a specification either written in human-readable prose or in a formal\nspecification language.\n\nIt also holds the WebAssembly testsuite, which tests numerous aspects of\nconformance to the spec.\n\nView the work-in-progress spec at [webassembly.github.io/spec](https://webassembly.github.io/spec/).\n\nAt this time, the contents of this repository are under development and known\nto be \"incomplet and inkorrect\".\n\nParticipation is welcome. Discussions about new features, significant semantic\nchanges, or any specification change likely to generate substantial discussion\nshould take place in\n[the WebAssembly design repository](https://github.com/WebAssembly/design)\nfirst, so that this spec repository can remain focused. And please follow the\n[guidelines for contributing](Contributing.md).\n\n# citing\n\nFor citing WebAssembly in LaTeX, use [this bibtex file](wasm-specs.bib).\n"
},
"w3c": {
"group": [
@@ -175586,7 +175570,7 @@
"body": "# Code of Conduct\n\nAll documentation, code and communication under this repository are covered by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/).\n"
},
"readme": {
- "text": "# \n\n# Welcome to the WICG Proposals Repo!\n\nThis is the WICG proposals repo, a place for well-formed ideas to start their incubation\njourney. Plan to use this repo's [issue tracker](https://github.com/WICG/proposals/issues)\nfor submitting and discussing new proposals much like\n[Discourse threads](https://discourse.wicg.io/) were used previously. Discourse will remain\na good home for less well-formed ideas to germinate, for early explorations, and for other\ndiscussions. But if you have a well-formed idea, you may skip Discourse and start an issue\nhere. Think of Discourse as the potential destination for earlier, less-well-formed concepts,\nand this repo's issue tracker for more crystalized proposals.\n\nPlease note that all proposals in this repo (including those in separate markdown documents)\nhave no official status in the WICG as incubations.\n\n## Evolving from Discourse\n\nPreviously, we used [Discourse discussions](https://discourse.wicg.io/) for anything that \nwasn't an official incubation (i.e., an incubation with its own repo). That forum was host\nto all discussions, early explorations, suggestions, and proposals for the web platform. \nThe goal was to help establish our community where those who participated in developing \nweb standards and those who didn't have the time but still wanted to influence/advance the\nweb could mingle and share ideas. In short, bringing together the broadest possible \ncommunity of interested developers to give and receive feedback. Our goal was largely \nsuccessful.\n\nAs time passed, the developer ecosystem shifted. We now see that GitHub has a larger \ncommunity of web developer interest than ever before, is the primary host of specification\ndevelopment for major web standards organizations and has great tools and integration for\nproject and issue management. We also see an opportunity to provide more direct guidance\non how to start an incubation, by creating this dedicated home for future incubations to\nbe proposed that is distinct from other ideas, explorations, and discussions about the web \nplatform.\n\nThis proposals repo will meet these changing needs. Here in GitHub you can easily extend your\nexisting repo and issue monitoring techniques to keep track of what's being proposed.\nAdditionally, this gives us a chance to clarify the WICG process for starting new incubations:\nrather than ask that proposals for new incubations be started on Discourse (intermingled with\nall other Discourse conversations), instead well-formed ideas should be filed as issues here in\nthis repo, making it clear that these proposal issues intend to begin life as an incubation.\nOur expectations for evaluation of new proposals remains the same: as soon as sufficient interest\nis shown in the proposal's issue thread (notably from potential implementers), the WICG chairs\nwill enable a team of editors to manage the proposal, and those team members can begin work in\na new repo or move ownership of an existing GitHub repo to WICG. For more information about the\nevaluation and incubation process, see\n[the admin repo's README file](https://github.com/WICG/admin/blob/gh-pages/README.md).\n\nWe continue to recommend that our community participate in Discourse for less well-formed ideas\nto germinate, for early explorations, and for other discussions. As these ideas, explorations,\nand discussions mature, they may form into a proposal which should then be filed as an issue in\nthis repo.\n\n## What does a proposal look like?\n\nA proposal outlines a particular problem or challenge on the web and offers a potential concrete\nsolution. Without being too prescriptive, you know you've got a proposal when you can articulate\na specific way (procedurally, algorithmically, declaratively) that a new or current web technology\nsolves an existing problem or challenge. If the problem is unclear, or the potential solution is\ntoo abstract you're not quite there yet.\n\nFor example, this is not a proposal:\n\n> \"Websites have lots of bugs because they don't get updated or because browsers change their \n> behavior over time. There should be a universal way for users to report bugs to websites so that \n> they get fixed.\"\n\nInstead, a proposal might be:\n\n> \"Websites have lots of bugs because they don't get updated or because browsers change their \n> behavior over time. One way to solve this is to create an experience in the browser that allows\n> users to record a set of steps that reproduce the problem, and then standardize the format for\n> these replay instructions, and provide an API to allow sites to capture this feedback or an HTTP\n> header to post this feedback back to their site. Below I describe the proposed format and API...\n> ``\" \n\n## Proposals in issues vs. separate markdown documents?\n\nIf you would like to make a proposal as a separate markdown document (if for example, it was\ndeveloped in a separate repo) you are welcome to link to it from the proposal issue; just provide\na bit of high-level context on the problem and proposed solution in the issue as well.\nAlternatively, if you'd like to use the proposal repository itself to host a separate markdown\ndocument, you are welcome to submit a PR for itโ we still ask that you file an issue to track\nyour proposal and provide context as previously mentioned. This will make it easier for our entire\ncommunity to use the issue tracker to search through all proposals.\n\n## Getting Started\n\nIs your proposal unique? Head over to the [issues list](https://github.com/WICG/proposals/issues)\nand search for it; if it was suggested by someone else give it your support with a ๐ or leave a\ncomment. If you don't find anything there, consider starting a new issue. (You are also welcome\nto visit [Discourse](https://discourse.wicg.io/) and search there as well, especially while this\nrepo is first getting populated). \n\n## Search proposals by category\n\nThe proposals are grouped by category (as discussions are on Discourse):\n\n| Label | Short description | Discourse category |\n|-------|-------------------|--------------------|\n| **[APIs](https://github.com/WICG/proposals/labels/Category%3A%20APIs)** | All proposals about JS APIs. | [APIs](https://discourse.wicg.io/c/apis/6) |\n| **[HTML](https://github.com/WICG/proposals/labels/Category%3A%20HTML)** | HTML-related proposals (not only the HTML standard but any markup-related ideas). | [HTML](https://discourse.wicg.io/c/html/10) |\n| **[CSS](https://github.com/WICG/proposals/labels/Category%3A%20CSS)** | CSS-related proposals. | [CSS](https://discourse.wicg.io/c/css/8) |\n| **[Uncategorized](https://github.com/WICG/proposals/labels/Category%3A%20Uncategorized)** | Proposals that don't fit into any other existing category. | [Uncategorized](https://discourse.wicg.io/c/uncategorized/1) |\n| **[Meta](https://github.com/WICG/proposals/labels/Category%3A%20meta)** | Proposals/ideas/discussions about this proposals repo, its organization, how it works, and how we can improve it. | [meta](https://discourse.wicg.io/c/meta/3) | \n| **[JS](https://github.com/WICG/proposals/labels/Category%3A%20JS)** | JS language proposals. | [JS](https://discourse.wicg.io/c/js/18) |\n| **[Security](https://github.com/WICG/proposals/labels/Category%3A%20Security)** | Proposals with a focus on web security, client-side protections, improved site security, etc. | [Security](https://discourse.wicg.io/c/security/21) |\n| **[Protocols](https://github.com/WICG/proposals/labels/Category%3A%20protocols)** | Proposals for anything relating to protocols such as HTTP, Web Sockets, & JSON-based protocols. | [protocols](https://discourse.wicg.io/c/protocols/14) |\n| **[WASM](https://github.com/WICG/proposals/labels/Category%3A%20WASM)** | Proposals for the WebAssembly language. Also consider reviewing [the WebAssembly Community Group's issue tracker](https://github.com/webassembly/spec/issues). | [asm.js](https://discourse.wicg.io/c/asm-js/16) |\n| **[Architecture](https://github.com/WICG/proposals/labels/Category%3A%20Architecture)** | For proposals related to web architecture or architectural components. | [Architecture](https://discourse.wicg.io/c/architecture/13) |\n| **[Media & RTC](https://github.com/WICG/proposals/labels/Category%3A%20Media%20%26%20RTC)** | For Media (video/audio) and Real-Time Communications proposals. | [Media and Real-Time Communications](https://discourse.wicg.io/c/mediartc/20) |\n| **[Web Components](https://github.com/WICG/proposals/labels/Category%3A%20Web%20Components)** | Proposals for web components. Also consider reviewing [the webcomponents incubation issue tracker](https://github.com/w3c/webcomponents/issues) | [Web Components](https://discourse.wicg.io/c/web-components/9) |\n| **[Web Apps](https://github.com/WICG/proposals/labels/Category%3A%20Web%20Apps)** | Proposals related to bringing App-like behavior to the web | n/a |\n\nTo help bridge Discourse discussions with those happening in this repo, we plan to setup an automated\nsystem to notify the Discourse community when new proposals are started in this repo.\n\n"
+ "text": "# \n\n# Welcome to the WICG Proposals Repo!\n\nThis is the WICG proposals repo, a place for ideas to start their incubation\njourney. Plan to use this repo's [issue tracker](https://github.com/WICG/proposals/issues)\nfor submitting and discussing new proposals much like the now archived\n[Discourse threads](https://discourse.wicg.io/) were used previously.\n\nPlease note that all proposals in this repo (including those in separate markdown documents)\nhave no official status in the WICG as incubations.\n\n## What does a proposal look like?\n\nA proposal outlines a particular problem or challenge on the web and offers a potential concrete\nsolution. Without being too prescriptive, you know you've got a proposal when you can articulate\na specific way (procedurally, algorithmically, declaratively) that a new or current web technology\nsolves an existing problem or challenge. If the problem is unclear, or the potential solution is\ntoo abstract you're not quite there yet.\n\nFor example, this is not a proposal:\n\n> \"Websites have lots of bugs because they don't get updated or because browsers change their \n> behavior over time. There should be a universal way for users to report bugs to websites so that \n> they get fixed.\"\n\nInstead, a proposal might be:\n\n> \"Websites have lots of bugs because they don't get updated or because browsers change their \n> behavior over time. One way to solve this is to create an experience in the browser that allows\n> users to record a set of steps that reproduce the problem, and then standardize the format for\n> these replay instructions, and provide an API to allow sites to capture this feedback or an HTTP\n> header to post this feedback back to their site. Below I describe the proposed format and API...\n> ``\" \n\n## Proposals in issues vs. separate markdown documents?\n\nIf you would like to make a proposal as a separate markdown document (if for example, it was\ndeveloped in a separate repo) you are welcome to link to it from the proposal issue; just provide\na bit of high-level context on the problem and proposed solution in the issue as well.\nAlternatively, if you'd like to use the proposal repository itself to host a separate markdown\ndocument, you are welcome to submit a PR for itโ we still ask that you file an issue to track\nyour proposal and provide context as previously mentioned. This will make it easier for our entire\ncommunity to use the issue tracker to search through all proposals.\n\n## Getting Started\n\nIs your proposal unique? Head over to the [issues list](https://github.com/WICG/proposals/issues)\nand search for it; if it was suggested by someone else give it your support with a ๐ or leave a\ncomment. If you don't find anything there, consider starting a new issue. (You are also welcome\nto visit [Discourse](https://discourse.wicg.io/) and search there as well, especially while this\nrepo is first getting populated). \n\n## Search proposals by category\n\nThe proposals are grouped by category (as discussions are on Discourse):\n\n| Label | Short description | Discourse category |\n|-------|-------------------|--------------------|\n| **[APIs](https://github.com/WICG/proposals/labels/Category%3A%20APIs)** | All proposals about JS APIs. | [APIs](https://discourse.wicg.io/c/apis/6) |\n| **[HTML](https://github.com/WICG/proposals/labels/Category%3A%20HTML)** | HTML-related proposals (not only the HTML standard but any markup-related ideas). | [HTML](https://discourse.wicg.io/c/html/10) |\n| **[CSS](https://github.com/WICG/proposals/labels/Category%3A%20CSS)** | CSS-related proposals. | [CSS](https://discourse.wicg.io/c/css/8) |\n| **[Uncategorized](https://github.com/WICG/proposals/labels/Category%3A%20Uncategorized)** | Proposals that don't fit into any other existing category. | [Uncategorized](https://discourse.wicg.io/c/uncategorized/1) |\n| **[Meta](https://github.com/WICG/proposals/labels/Category%3A%20meta)** | Proposals/ideas/discussions about this proposals repo, its organization, how it works, and how we can improve it. | [meta](https://discourse.wicg.io/c/meta/3) | \n| **[JS](https://github.com/WICG/proposals/labels/Category%3A%20JS)** | JS language proposals. | [JS](https://discourse.wicg.io/c/js/18) |\n| **[Security](https://github.com/WICG/proposals/labels/Category%3A%20Security)** | Proposals with a focus on web security, client-side protections, improved site security, etc. | [Security](https://discourse.wicg.io/c/security/21) |\n| **[Protocols](https://github.com/WICG/proposals/labels/Category%3A%20protocols)** | Proposals for anything relating to protocols such as HTTP, Web Sockets, & JSON-based protocols. | [protocols](https://discourse.wicg.io/c/protocols/14) |\n| **[WASM](https://github.com/WICG/proposals/labels/Category%3A%20WASM)** | Proposals for the WebAssembly language. Also consider reviewing [the WebAssembly Community Group's issue tracker](https://github.com/webassembly/spec/issues). | [asm.js](https://discourse.wicg.io/c/asm-js/16) |\n| **[Architecture](https://github.com/WICG/proposals/labels/Category%3A%20Architecture)** | For proposals related to web architecture or architectural components. | [Architecture](https://discourse.wicg.io/c/architecture/13) |\n| **[Media & RTC](https://github.com/WICG/proposals/labels/Category%3A%20Media%20%26%20RTC)** | For Media (video/audio) and Real-Time Communications proposals. | [Media and Real-Time Communications](https://discourse.wicg.io/c/mediartc/20) |\n| **[Web Components](https://github.com/WICG/proposals/labels/Category%3A%20Web%20Components)** | Proposals for web components. Also consider reviewing [the webcomponents incubation issue tracker](https://github.com/w3c/webcomponents/issues) | [Web Components](https://discourse.wicg.io/c/web-components/9) |\n| **[Web Apps](https://github.com/WICG/proposals/labels/Category%3A%20Web%20Apps)** | Proposals related to bringing App-like behavior to the web | n/a |\n\n\n## Evolving from Discourse\n\nPreviously, we used [Discourse discussions](https://discourse.wicg.io/) for anything that \nwasn't an official incubation (i.e., an incubation with its own repo). That forum was host\nto all discussions, early explorations, suggestions, and proposals for the web platform. \nThe goal was to help establish our community where those who participated in developing \nweb standards and those who didn't have the time but still wanted to influence/advance the\nweb could mingle and share ideas. In short, bringing together the broadest possible \ncommunity of interested developers to give and receive feedback. Our goal was largely \nsuccessful.\n\nAs time passed, the developer ecosystem shifted. We now see that GitHub has a larger \ncommunity of web developer interest than ever before, is the primary host of specification\ndevelopment for major web standards organizations and has great tools and integration for\nproject and issue management. We also see an opportunity to provide more direct guidance\non how to start an incubation, by creating this dedicated home for future incubations to\nbe proposed that is distinct from other ideas, explorations, and discussions about the web \nplatform.\n\nThis proposals repo will meet these changing needs. Here in GitHub you can easily extend your\nexisting repo and issue monitoring techniques to keep track of what's being proposed.\nAdditionally, this gives us a chance to clarify the WICG process for starting new incubations:\nrather than ask that proposals for new incubations be started on Discourse (intermingled with\nall other Discourse conversations), instead ideas should be filed as issues here in\nthis repo, making it clear that these proposal issues intend to begin life as an incubation.\nOur expectations for evaluation of new proposals remains the same: as soon as sufficient interest\nis shown in the proposal's issue thread (notably from potential implementers), the WICG chairs\nwill enable a team of editors to manage the proposal, and those team members can begin work in\na new repo or move ownership of an existing GitHub repo to WICG. For more information about the\nevaluation and incubation process, see\n[the admin repo's README file](https://github.com/WICG/admin/blob/gh-pages/README.md).\n"
},
"w3c": {
"group": [
@@ -178902,7 +178886,7 @@
},
"codeOfConduct": null,
"readme": {
- "text": "# Explainer for the Web Translation API\n\n_This proposal is an early design sketch by the Chrome translate API team to describe the problem below and solicit feedback on the proposed solution. It has not been approved to ship in Chrome._\n\nBrowsers are increasingly offering language translation to their users. Such translation capabilities can also be useful to web developers. This is especially the case when browser's built-in translation abilities cannot help, such as:\n\n* translating user input or other interactive features;\n* pages with complicated DOMs which trip up browser translation;\n* providing in-page UI to start the translation; or\n* translating content that is not in the DOM, e.g. spoken content.\n\nTo perform translation in such cases, web sites currently have to either call out to cloud APIs, or bring their own translation models and run them using technologies like WebAssembly and WebGPU. This proposal introduces a new JavaScript API for exposing a browser's existing language translation abilities to web pages, so that if present, they can serve as a simpler and less resource-intensive alternative.\n\n## Goals\n\nOur goals are to:\n\n* Help web developers perform real-time translations (e.g. of user input).\n* Help web developers perform real-time language detection.\n* Guide web developers to gracefully handle failure cases, e.g. translation not being available or possible.\n* Harmonize well with existing browser and OS translation technology ([Brave](https://support.brave.com/hc/en-us/articles/8963107404813-How-do-I-use-Brave-Translate), [Chrome](https://support.google.com/chrome/answer/173424?hl=en&co=GENIE.Platform%3DDesktop#zippy=%2Ctranslate-selected-text), [Edge](https://support.microsoft.com/en-us/topic/use-microsoft-translator-in-microsoft-edge-browser-4ad1c6cb-01a4-4227-be9d-a81e127fcb0b), [Firefox](https://support.mozilla.org/en-US/kb/website-translation), [Safari](https://9to5mac.com/2020/12/04/how-to-translate-websites-with-safari-mac/)), e.g. by allowing on-the-fly downloading of different languages instead of assuming all are present from the start.\n* Allow a variety of implementation strategies, including on-device vs. cloud-based translation, while keeping these details abstracted from developers.\n\nThe following are explicit non-goals:\n\n* We do not intend to force every browser to ship language packs for every language combination, or even to support translation at all. It would be conforming to implement this API by always returning `\"no\"` from `canTranslate()`, or to implement this API entirely by using cloud services instead of on-device translation.\n* We do not intend to provide guarantees of translation quality, stability, or interoperability between browsers. These are left as quality-of-implementation issues, similar to the [shape detection API](https://wicg.github.io/shape-detection-api/). (See also a [discussion of interop](https://www.w3.org/reports/ai-web-impact/#interop) in the W3C \"AI & the Web\" document.)\n\nThe following are potential goals we are not yet certain of:\n\n* Allow web developers to know whether translations are done on-device or using cloud services. This would allow them to guarantee that any user data they feed into this API does not leave the device, which can be important for privacy purposes. (Similarly, we might want to allow developers to request on-device-only translation, in case a browser offers both varieties.)\n* Allow web developers to know some identifier for the translation model in use, separate from the browser version. This would allow them to allowlist or blocklist specific models to maintain a desired level of quality.\n\nBoth of these potential goals are potentially detrimental to interoperability, so we want to investigate more how important such functionality is to developers to find the right tradeoff.\n\n## Examples\n\nNote that in this API, languages are represented as [BCP 47](https://www.rfc-editor.org/info/bcp47) language tags, as already used by the existing JavaScript `Intl` API or the HTML `lang=\"\"` attribute. Examples: `\"ja\"`, `\"en\"`, `\"de-AT\"`, `\"zh-Hans-CN\"`.\n\nSee [below](#language-tag-handling) for more on the details of how language tags are handled in this API, and the [appendix](#appendix-converting-between-language-tags-and-human-readable-strings) for some helper code that converts between language tags and human-readable strings.\n\n### For a known source language\n\nIf the source language is known, using the API looks like so:\n\n```js\nconst canTranslate = await translation.canTranslate({\n sourceLanguage: \"en\",\n targetLanguage: \"ja\"\n});\n\nif (canTranslate !== \"no\") {\n const translator = await translation.createTranslator({\n sourceLanguage: \"en\",\n targetLanguage: \"ja\"\n });\n\n console.assert(translator.sourceLanguage === \"en\");\n console.assert(translator.targetLanguage === \"ja\");\n\n const text = await translator.translate(\"Hello, world!\");\n const readableStreamOfText = await translator.translateStreaming(`\n Four score and seven years ago our fathers brought forth, upon this...`);\n} else {\n // Use alternate methods\n}\n```\n\n### For an unknown source language\n\nIf the source language is unknown, the same APIs can be called without the `sourceLanguage` option. The return type of the resulting translator object's `translate()` and `translateStreaming()` methods will change to include the best-guess at the detected language, and a confidence level between 0 and 1:\n\n```js\nconst canTranslate = await translation.canTranslate({ targetLanguage: \"ja\" });\n\nif (canTranslate !== \"no\") {\n const translator = await translation.createTranslator({ targetLanguage: \"ja\" });\n\n console.assert(translator.sourceLanguage === null);\n console.assert(translator.targetLanguage === \"ja\");\n\n const {\n detectedLanguage,\n confidence,\n result\n } = await translator.translate(someUserText);\n\n // result is a ReadableStream\n const {\n detectedLanguage,\n confidence,\n result\n } = await translator.translateStreaming(longerUserText);\n}\n```\n\nIf the language cannot be detected, then the return value will be `{ detectedLanguage: null, confidence: 0, result: null }`.\n\n### Downloading new languages\n\nIn the above examples, we're always testing if the `canTranslate()` method returns something other than `\"no\"`. Why isn't it a simple boolean? The answer is because the return value can be one of three possibilities:\n\n* `\"no\"`: it is not possible for this browser to translate as requested\n* `\"readily\"`: the browser can readily translate as requested\n* `\"after-download\"`: the browser can perform the requested translation, but only after it downloads appropriate material.\n\nTo see how to use this, consider an expansion of the above example:\n\n```js\nconst canTranslate = await translation.canTranslate({ targetLanguage: \"is\" });\n\nif (canTranslate === \"readily\") {\n const translator = await translation.createTranslator({ targetLanguage: \"is\" });\n doTheTranslation(translator);\n} else if (canTranslate === \"after-download\") {\n // Since we're in the \"after-download\" case, creating a translator will start\n // downloading the necessary language pack.\n const translator = await translation.createTranslator({ targetLanguage: \"is\" });\n\n translator.ondownloadprogress = progressEvent => {\n updateDownloadProgressBar(progressEvent.loaded, progressEvent.total);\n };\n await translator.ready;\n removeDownloadProgressBar();\n\n doTheTranslation(translator);\n} else {\n // Use alternate methods\n}\n```\n\nNote that `await translator.ready` is not necessary; if it's omitted, calls to `translator.translate()` or `translator.translateStreaming()` will just take longer to fulfill (or reject). But it can be convenient.\n\nIf the download fails, then `downloadprogress` events will stop being emitted, and the `ready` promise will be rejected with a \"`NetworkError`\" `DOMException`. Additionally, any calls to `translator`'s methods will reject with the same error.\n\n### Language detection\n\nApart from translating between languages, the API can offer the ability to detect the language of text, with confidence levels.\n\n```js\nif (await translation.canDetect() !== \"no\") {\n const detector = await translation.createDetector();\n\n const results = await detector.detect(\"Hello, world!\");\n for (const result of results) {\n console.log(result.detectedLanguage, result.confidence);\n }\n}\n```\n\nIf no language can be detected with reasonable confidence, this API returns an empty array.\n\n### Listing supported languages\n\nTo get a list of languages which the current browser can translate, we can use the following code:\n\n```js\nfor (const language of await translation.supportedLanguages()) {\n let text = languageTagToHumanReadable(lang, \"en\"); // see appendix\n languageDropdown.append(new Option(text, language));\n}\n```\n\nThis method does not distinguish between languages which are available `\"readily\"` vs. `\"after-download\"`, because giving that information for all languages at once is too much of a [privacy issue](#privacy-considerations). Instead, the developer must make individual calls to `canTranslate()`, which gives the browser more opportunities to apply privacy mitigations.\n\n## Detailed design\n\n### Full API surface in Web IDL\n\n```webidl\n[Exposed=(Window,Worker)]\ninterface Translation {\n Promise canTranslate(TranslationLanguageOptions options);\n Promise createTranslator(TranslationLanguageOptions options);\n\n Promise canDetect();\n Promise createDetector();\n\n Promise>> supportedLanguages();\n};\n\n[Exposed=(Window,Worker)]\ninterface LanguageTranslator : EventTarget {\n readonly attribute Promise ready;\n attribute EventHandler ondownloadprogress;\n\n readonly attribute DOMString? sourceLanguage;\n readonly attribute DOMString targetLanguage;\n\n Promise<(DOMString or ResultWithLanguageDetection)> translate(DOMString input);\n Promise<(ReadableStream or StreamingResultWithLanguageDetection)> translateStreaming(DOMString input);\n};\n\n[Exposed=(Window,Worker)]\ninterface LanguageDetector : EventTarget {\n readonly attribute Promise ready;\n attribute EventHandler ondownloadprogress;\n\n Promise> detect(DOMString input);\n};\n\npartial interface WindowOrWorkerGlobalScope {\n readonly attribute Translation translation;\n};\n\nenum TranslationAvailability { \"readily\", \"after-download\", \"no\" };\n\ndictionary TranslationLanguageOptions {\n required DOMString targetLanguage;\n DOMString sourceLanguage;\n};\n\ndictionary LanguageDetectionResult {\n DOMString? detectedLanguage;\n double confidence;\n};\n\ndictionary ResultWithLanguageDetection : LanguageDetectionResult {\n DOMString? result;\n};\n\ndictionary StreamingResultWithLanguageDetection : LanguageDetectionResult {\n ReadableStream? result;\n};\n```\n\n### Language tag handling\n\nIf a browser supports translating from `ja` to `en`, does it also support translating from `ja` to `en-US`? What about `en-GB`? What about the (discouraged, but valid) `en-Latn`, i.e. English written in the usual Latin script? But translation to `en-Brai`, English written in the Braille script, is different entirely.\n\nTentatively, pending consultation with internationalization and translation API experts, we propose the following model. Each user agent has a list of (language tag, availability) pairs, which is the same one returned by `translation.supportedLanguages()`. Only exact matches for entries in that list will be used for the API.\n\nSo for example, consider a browser which supports `en`, `zh-Hans`, and `zh-Hant`. Then we would have the following results:\n\n```js\nawait translator.canTranslate({ targetLanguage: \"en\" }); // true\nawait translator.canTranslate({ targetLanguage: \"en-US\" }); // false\n\nawait translator.canTranslate({ targetLanguage: \"zh-Hans\" }); // true\nawait translator.canTranslate({ targetLanguage: \"zh\" }); // false\n```\n\nTo improve interoperability and best meet developer expectations, we can mandate in the specification that browsers follow the best practices outlined in BCP 47, especially around [extended language subtags](https://www.rfc-editor.org/rfc/rfc5646.html#section-4.1.2), such as:\n\n* always returning canonical forms instead of aliases;\n* correctly distinguishing between script support (e.g. `zh-Hant`) from country support (e.g. `zh-TW`); and\n* avoiding including redundant script information (e.g. `en-Latn`).\n\n### Downloading\n\nThe current design envisions that the following operations will _not_ cause downloads of language packs or other material like a language detection model:\n\n* `translation.canTranslate()`\n* `translation.canDetect()`\n* `translation.supportedLanguages()`\n\nThe following _can_ cause downloads. In all cases, whether or not a call will initiate a download can be detected beforehand by checking the return value of the corresponding `canXYZ()` call.\n\n* `translation.createTranslator()`\n* `translation.createDetector()`\n\nAfter a developer has a `LanguageTranslator` or `LanguageDetector` object created by these methods, further calls are not expected to cause any downloads. (Although they might require internet access, if the implementation is not entirely on-device.)\n\n## Privacy considerations\n\nThis proposal as-is has privacy issues, which we are actively thinking about how to address. They are all centered around how sites that use this API might be able to uniquely fingerprint the user.\n\nThe most obvious identifier in the current API design is the list of supported languages, and especially their availability status (`\"no\"`, `\"readily\"`, or `\"after-download\"`). For example, as of the time of this writing [Firefox supports 9 languages](https://www.mozilla.org/en-US/firefox/features/translate/), which can each be [independently downloaded](https://support.mozilla.org/en-US/kb/website-translation#w_configure-installed-languages). With a naive implementation, this gives 9 bits of identifying information, which various sites can all correlate.\n\nSome sort of mitigation may be necessary here. We believe this is adjacent to other areas that have seen similar mitigation, such as the [Local Font Access API](https://github.com/WICG/local-font-access/blob/main/README.md). Possible techniques are:\n\n* Grouping language packs to reduce the number of bits, so that downloading one language also downloads others in its group.\n* Partitioning download status by top-level site, introducing a fake download (which takes time but does not actually download anything) for the second-onward site to download a language pack.\n* Only exposing a fixed set of languages to this API, e.g. based on the user's locale or the document's main language.\n\nAs a first step, we require that detecting the availability of translation for a given language pair be done via individual calls to `canTranslate()`. This allows browsers to implement possible mitigation techniques, such as detecting excessive calls to `canTranslate()` and starting to return `\"no\"`.\n\nAnother way in which this API might enhance the web's fingerprinting surface is if translation and language detection models are updated separately from browser versions. In that case, differing results from different versions of the model provide additional fingerprinting bits beyond those already provided by the browser's major version number. Mandating that older browser versions not receive updates or be able to download models from too far into the future might be a possible remediation for this.\n\nFinally, we intend to prohibit (in the specification) any use of user-specific information in producing the translations. For example, it would not be permissible to fine-tune the translation model based on information the user has entered into the browser in the past.\n\n## Alternatives considered and under consideration\n\n### Streaming input support\n\nAlthough the API contains support for streaming output of a translation, via the `translateStreaming()` API, it doesn't support streaming input. Should it?\n\nWe believe it should not, for now. In general, translation works best with more context; feeding more input into the system over time can produce very different results. For example, translating \"ๅฝผๅฅณใฎ่ฉฑใ่ใใฆใ้ฉใใ\" to English would give \"I was surprised to hear her story\". But if you then streamed in another chunk, so that the full sentence was \"ๅฝผๅฅณใฎ่ฉฑใ่ใใฆใ้ฉใใใญใใ้ใใ\", the result changes completely to \"Upon hearing her story, the surprised cat ran away.\" This doesn't fit well with how streaming APIs behave generally.\n\nIn other words, even if web developers are receiving a stream of input (e.g. over the network or from the user), they need to take special care in how they present such updating-over-time translations to the user. We shouldn't treat this as a usual stream-to-string or stream-to-stream API, because that will rarely be useful.\n\nThat said, we are aware of [research](https://arxiv.org/abs/2005.08595) on translation algorithms which are specialized for this kind of setting, and attempt to mitigate the above problem. It's possible we might want to support this sort of API in the future, if implementations are excited about implementing that research. This should be possible to fit into the existing API surface, possibly with some extra feature-detection API.\n\n### Flattening the API and reducing async steps\n\nThe current design requires multiple async steps to do useful things:\n\n```js\nconst translator = await translation.createTranslator(options);\nconst text = await translator.translate(sourceText);\n\nconst detector = await translation.createDetector();\nconst results = await detector.detect(sourceText);\n```\n\nShould we simplify these down with convenience APIs that do both steps at once?\n\nWe're open to this idea, but we think the existing complexity is necessary to support the design wherein translation and language detection models might not be already downloaded. By separating the two stages, we allow web developers to perform the initial creation-and-possibly-downloading steps early in their page's lifecycle, in preparation for later, hopefully-quick calls to APIs like `translate()`.\n\nAnother possible simplification is to make some of the more informational APIs, namely `canTranslate()`, `canDetect()`, and `supportedLanguages()`, synchronous instead of asynchronous. This would be implementable by having the browser proactively load the information about supported languages into the main thread's process, upon creation of the global object. We think this is not worthwhile, though, as it imposes a non-negligible cost on all global object creation.\n\n### Separating language detection and translation\n\nAs discussed in [For an unknown source language](#for-an-unknown-source-language), we support performing both language detection and translation to the best-guess language at the same time, in one API. This slightly complicates the `translate()` and `translateStreaming()` APIs, by giving them polymorphic return types.\n\nWe could instead require that developers always supply a `sourceLanguage`, and if they want to detect it ahead of time, they could use the `detect()` API.\n\nWe're open to this simplification, but suspect it would be worse for efficiency, as it bakes in a requirement of multiple traversals over the input text, mediated by JavaScript code. We plan to investigate whether multiple traversals over the input are necessary anyway according to the latest research, in which case this simplification would probably be preferable.\n\n## Stakeholder feedback\n\n* W3C TAG: to be requested\n* Browser engines:\n * Chromium: prototyping behind a flag\n * Gecko: to be requested\n * WebKit: to be requested\n* Web developers: Chrome has received private enthusiasm for such an API, and is working on gathering public evidence of such enthusiasm.\n\n## Appendix: converting between language tags and human-readable strings\n\nThis code already works today and is not new to this API proposal. It is likely useful in conjunction with this API, for example when building user interfaces.\n\n```js\nfunction languageTagToHumanReadable(languageTag, targetLanguage) {\n const displayNames = new Intl.DisplayNames([targetLanguage], { type: \"language\" });\n return displayNames.of(languageTag);\n}\n\nlanguageTagToHumanReadable(\"ja\", \"en\"); // \"Japanese\"\nlanguageTagToHumanReadable(\"zh\", \"en\"); // \"Chinese\"\nlanguageTagToHumanReadable(\"zh-Hant\", \"en\"); // \"Traditional Chinese\"\nlanguageTagToHumanReadable(\"zh-TW\", \"en\"); // \"Chinese (Taiwan)\"\n\nlanguageTagToHumanReadable(\"en\", \"ja\"); // \"่ฑ่ช\"\n```\n"
+ "text": "# Explainer for the Web Translation API\n\n_This proposal is an early design sketch by the Chrome translate API team to describe the problem below and solicit feedback on the proposed solution. It has not been approved to ship in Chrome._\n\nBrowsers are increasingly offering language translation to their users. Such translation capabilities can also be useful to web developers. This is especially the case when browser's built-in translation abilities cannot help, such as:\n\n* translating user input or other interactive features;\n* pages with complicated DOMs which trip up browser translation;\n* providing in-page UI to start the translation; or\n* translating content that is not in the DOM, e.g. spoken content.\n\nTo perform translation in such cases, web sites currently have to either call out to cloud APIs, or bring their own translation models and run them using technologies like WebAssembly and WebGPU. This proposal introduces a new JavaScript API for exposing a browser's existing language translation abilities to web pages, so that if present, they can serve as a simpler and less resource-intensive alternative.\n\n## Goals\n\nOur goals are to:\n\n* Help web developers perform real-time translations (e.g. of user input).\n* Help web developers perform real-time language detection.\n* Guide web developers to gracefully handle failure cases, e.g. translation not being available or possible.\n* Harmonize well with existing browser and OS translation technology ([Brave](https://support.brave.com/hc/en-us/articles/8963107404813-How-do-I-use-Brave-Translate), [Chrome](https://support.google.com/chrome/answer/173424?hl=en&co=GENIE.Platform%3DDesktop#zippy=%2Ctranslate-selected-text), [Edge](https://support.microsoft.com/en-us/topic/use-microsoft-translator-in-microsoft-edge-browser-4ad1c6cb-01a4-4227-be9d-a81e127fcb0b), [Firefox](https://support.mozilla.org/en-US/kb/website-translation), [Safari](https://9to5mac.com/2020/12/04/how-to-translate-websites-with-safari-mac/)), e.g. by allowing on-the-fly downloading of different languages instead of assuming all are present from the start.\n* Allow a variety of implementation strategies, including on-device vs. cloud-based translation, while keeping these details abstracted from developers.\n\nThe following are explicit non-goals:\n\n* We do not intend to force every browser to ship language packs for every language combination, or even to support translation at all. It would be conforming to implement this API by always returning `\"no\"` from `canTranslate()`, or to implement this API entirely by using cloud services instead of on-device translation.\n* We do not intend to provide guarantees of translation quality, stability, or interoperability between browsers. These are left as quality-of-implementation issues, similar to the [shape detection API](https://wicg.github.io/shape-detection-api/). (See also a [discussion of interop](https://www.w3.org/reports/ai-web-impact/#interop) in the W3C \"AI & the Web\" document.)\n\nThe following are potential goals we are not yet certain of:\n\n* Allow web developers to know whether translations are done on-device or using cloud services. This would allow them to guarantee that any user data they feed into this API does not leave the device, which can be important for privacy purposes. (Similarly, we might want to allow developers to request on-device-only translation, in case a browser offers both varieties.)\n* Allow web developers to know some identifier for the translation model in use, separate from the browser version. This would allow them to allowlist or blocklist specific models to maintain a desired level of quality.\n\nBoth of these potential goals are potentially detrimental to interoperability, so we want to investigate more how important such functionality is to developers to find the right tradeoff.\n\n## Examples\n\nNote that in this API, languages are represented as [BCP 47](https://www.rfc-editor.org/info/bcp47) language tags, as already used by the existing JavaScript `Intl` API or the HTML `lang=\"\"` attribute. Examples: `\"ja\"`, `\"en\"`, `\"de-AT\"`, `\"zh-Hans-CN\"`.\n\nSee [below](#language-tag-handling) for more on the details of how language tags are handled in this API, and the [appendix](#appendix-converting-between-language-tags-and-human-readable-strings) for some helper code that converts between language tags and human-readable strings.\n\n### For a known source language\n\nIf the source language is known, using the API looks like so:\n\n```js\nconst canTranslate = await translation.canTranslate({\n sourceLanguage: \"en\",\n targetLanguage: \"ja\"\n});\n\nif (canTranslate !== \"no\") {\n const translator = await translation.createTranslator({\n sourceLanguage: \"en\",\n targetLanguage: \"ja\"\n });\n\n console.assert(translator.sourceLanguage === \"en\");\n console.assert(translator.targetLanguage === \"ja\");\n\n const text = await translator.translate(\"Hello, world!\");\n const readableStreamOfText = await translator.translateStreaming(`\n Four score and seven years ago our fathers brought forth, upon this...`);\n} else {\n // Use alternate methods\n}\n```\n\n### For an unknown source language\n\nIf the source language is unknown, the same APIs can be called without the `sourceLanguage` option. The return type of the resulting translator object's `translate()` and `translateStreaming()` methods will change to include the best-guess at the detected language, and a confidence level between 0 and 1:\n\n```js\nconst canTranslate = await translation.canTranslate({ targetLanguage: \"ja\" });\n\nif (canTranslate !== \"no\") {\n const translator = await translation.createTranslator({ targetLanguage: \"ja\" });\n\n console.assert(translator.sourceLanguage === null);\n console.assert(translator.targetLanguage === \"ja\");\n\n const {\n detectedLanguage,\n confidence,\n result\n } = await translator.translate(someUserText);\n\n // result is a ReadableStream\n const {\n detectedLanguage,\n confidence,\n result\n } = await translator.translateStreaming(longerUserText);\n}\n```\n\nIf the language cannot be detected, then the return value will be `{ detectedLanguage: null, confidence: 0, result: null }`.\n\n### Downloading new languages\n\nIn the above examples, we're always testing if the `canTranslate()` method returns something other than `\"no\"`. Why isn't it a simple boolean? The answer is because the return value can be one of three possibilities:\n\n* `\"no\"`: it is not possible for this browser to translate as requested\n* `\"readily\"`: the browser can readily translate as requested\n* `\"after-download\"`: the browser can perform the requested translation, but only after it downloads appropriate material.\n\nTo see how to use this, consider an expansion of the above example:\n\n```js\nconst canTranslate = await translation.canTranslate({ targetLanguage: \"is\" });\n\nif (canTranslate === \"readily\") {\n const translator = await translation.createTranslator({ targetLanguage: \"is\" });\n doTheTranslation(translator);\n} else if (canTranslate === \"after-download\") {\n // Since we're in the \"after-download\" case, creating a translator will start\n // downloading the necessary language pack.\n const translator = await translation.createTranslator({ targetLanguage: \"is\" });\n\n translator.ondownloadprogress = progressEvent => {\n updateDownloadProgressBar(progressEvent.loaded, progressEvent.total);\n };\n await translator.ready;\n removeDownloadProgressBar();\n\n doTheTranslation(translator);\n} else {\n // Use alternate methods\n}\n```\n\nNote that `await translator.ready` is not necessary; if it's omitted, calls to `translator.translate()` or `translator.translateStreaming()` will just take longer to fulfill (or reject). But it can be convenient.\n\nIf the download fails, then `downloadprogress` events will stop being emitted, and the `ready` promise will be rejected with a \"`NetworkError`\" `DOMException`. Additionally, any calls to `translator`'s methods will reject with the same error.\n\n### Language detection\n\nApart from translating between languages, the API can offer the ability to detect the language of text, with confidence levels.\n\n```js\nif (await translation.canDetect() !== \"no\") {\n const detector = await translation.createDetector();\n\n const results = await detector.detect(\"Hello, world!\");\n for (const result of results) {\n console.log(result.detectedLanguage, result.confidence);\n }\n}\n```\n\nIf no language can be detected with reasonable confidence, this API returns an empty array.\n\n### Listing supported languages\n\nTo get a list of languages which the current browser can translate, we can use the following code:\n\n```js\nfor (const language of await translation.supportedLanguages()) {\n let text = languageTagToHumanReadable(lang, \"en\"); // see appendix\n languageDropdown.append(new Option(text, language));\n}\n```\n\nThis method does not distinguish between languages which are available `\"readily\"` vs. `\"after-download\"`, because giving that information for all languages at once is too much of a [privacy issue](#privacy-considerations). Instead, the developer must make individual calls to `canTranslate()`, which gives the browser more opportunities to apply privacy mitigations.\n\n## Detailed design\n\n### Full API surface in Web IDL\n\n```webidl\n[Exposed=(Window,Worker)]\ninterface Translation {\n Promise canTranslate(TranslationLanguageOptions options);\n Promise createTranslator(TranslationLanguageOptions options);\n\n Promise canDetect();\n Promise createDetector();\n\n Promise>> supportedLanguages();\n};\n\n[Exposed=(Window,Worker)]\ninterface LanguageTranslator : EventTarget {\n readonly attribute Promise ready;\n attribute EventHandler ondownloadprogress;\n\n readonly attribute DOMString? sourceLanguage;\n readonly attribute DOMString targetLanguage;\n\n Promise<(DOMString or ResultWithLanguageDetection)> translate(DOMString input);\n Promise<(ReadableStream or StreamingResultWithLanguageDetection)> translateStreaming(DOMString input);\n};\n\n[Exposed=(Window,Worker)]\ninterface LanguageDetector : EventTarget {\n readonly attribute Promise ready;\n attribute EventHandler ondownloadprogress;\n\n Promise> detect(DOMString input);\n};\n\npartial interface WindowOrWorkerGlobalScope {\n readonly attribute Translation translation;\n};\n\nenum TranslationAvailability { \"readily\", \"after-download\", \"no\" };\n\ndictionary TranslationLanguageOptions {\n required DOMString targetLanguage;\n DOMString sourceLanguage;\n};\n\ndictionary LanguageDetectionResult {\n DOMString? detectedLanguage;\n double confidence;\n};\n\ndictionary ResultWithLanguageDetection : LanguageDetectionResult {\n DOMString? result;\n};\n\ndictionary StreamingResultWithLanguageDetection : LanguageDetectionResult {\n ReadableStream? result;\n};\n```\n\n### Language tag handling\n\nIf a browser supports translating from `ja` to `en`, does it also support translating from `ja` to `en-US`? What about `en-GB`? What about the (discouraged, but valid) `en-Latn`, i.e. English written in the usual Latin script? But translation to `en-Brai`, English written in the Braille script, is different entirely.\n\nTentatively, pending consultation with internationalization and translation API experts, we propose the following model. Each user agent has a list of (language tag, availability) pairs, which is the same one returned by `translation.supportedLanguages()`. Only exact matches for entries in that list will be used for the API.\n\nSo for example, consider a browser which supports `en`, `zh-Hans`, and `zh-Hant`. Then we would have the following results:\n\n```js\nawait translator.canTranslate({ targetLanguage: \"en\" }); // true\nawait translator.canTranslate({ targetLanguage: \"en-US\" }); // false\n\nawait translator.canTranslate({ targetLanguage: \"zh-Hans\" }); // true\nawait translator.canTranslate({ targetLanguage: \"zh\" }); // false\n```\n\nTo improve interoperability and best meet developer expectations, we can mandate in the specification that browsers follow the best practices outlined in BCP 47, especially around [extended language subtags](https://www.rfc-editor.org/rfc/rfc5646.html#section-4.1.2), such as:\n\n* always returning canonical forms instead of aliases;\n* correctly distinguishing between script support (e.g. `zh-Hant`) from country support (e.g. `zh-TW`); and\n* avoiding including redundant script information (e.g. `en-Latn`).\n\n### Downloading\n\nThe current design envisions that the following operations will _not_ cause downloads of language packs or other material like a language detection model:\n\n* `translation.canTranslate()`\n* `translation.canDetect()`\n* `translation.supportedLanguages()`\n\nThe following _can_ cause downloads. In all cases, whether or not a call will initiate a download can be detected beforehand by checking the return value of the corresponding `canXYZ()` call.\n\n* `translation.createTranslator()`\n* `translation.createDetector()`\n\nAfter a developer has a `LanguageTranslator` or `LanguageDetector` object created by these methods, further calls are not expected to cause any downloads. (Although they might require internet access, if the implementation is not entirely on-device.)\n\n## Privacy considerations\n\nThis proposal as-is has privacy issues, which we are actively thinking about how to address. They are all centered around how sites that use this API might be able to uniquely fingerprint the user.\n\nThe most obvious identifier in the current API design is the list of supported languages, and especially their availability status (`\"no\"`, `\"readily\"`, or `\"after-download\"`). For example, as of the time of this writing [Firefox supports 9 languages](https://www.mozilla.org/en-US/firefox/features/translate/), which can each be [independently downloaded](https://support.mozilla.org/en-US/kb/website-translation#w_configure-installed-languages). With a naive implementation, this gives 9 bits of identifying information, which various sites can all correlate.\n\nSome sort of mitigation may be necessary here. We believe this is adjacent to other areas that have seen similar mitigation, such as the [Local Font Access API](https://github.com/WICG/local-font-access/blob/main/README.md). Possible techniques are:\n\n* Grouping language packs to reduce the number of bits, so that downloading one language also downloads others in its group.\n* Partitioning download status by top-level site, introducing a fake download (which takes time but does not actually download anything) for the second-onward site to download a language pack.\n* Only exposing a fixed set of languages to this API, e.g. based on the user's locale or the document's main language.\n\nAs a first step, we require that detecting the availability of translation for a given language pair be done via individual calls to `canTranslate()`. This allows browsers to implement possible mitigation techniques, such as detecting excessive calls to `canTranslate()` and starting to return `\"no\"`.\n\nAnother way in which this API might enhance the web's fingerprinting surface is if translation and language detection models are updated separately from browser versions. In that case, differing results from different versions of the model provide additional fingerprinting bits beyond those already provided by the browser's major version number. Mandating that older browser versions not receive updates or be able to download models from too far into the future might be a possible remediation for this.\n\nFinally, we intend to prohibit (in the specification) any use of user-specific information in producing the translations. For example, it would not be permissible to fine-tune the translation model based on information the user has entered into the browser in the past.\n\n## Alternatives considered and under consideration\n\n### Streaming input support\n\nAlthough the API contains support for streaming output of a translation, via the `translateStreaming()` API, it doesn't support streaming input. Should it?\n\nWe believe it should not, for now. In general, translation works best with more context; feeding more input into the system over time can produce very different results. For example, translating \"ๅฝผๅฅณใฎ่ฉฑใ่ใใฆใ้ฉใใ\" to English would give \"I was surprised to hear her story\". But if you then streamed in another chunk, so that the full sentence was \"ๅฝผๅฅณใฎ่ฉฑใ่ใใฆใ้ฉใใใญใใ้ใใ\", the result changes completely to \"Upon hearing her story, the surprised cat ran away.\" This doesn't fit well with how streaming APIs behave generally.\n\nIn other words, even if web developers are receiving a stream of input (e.g. over the network or from the user), they need to take special care in how they present such updating-over-time translations to the user. We shouldn't treat this as a usual stream-to-string or stream-to-stream API, because that will rarely be useful.\n\nThat said, we are aware of [research](https://arxiv.org/abs/2005.08595) on translation algorithms which are specialized for this kind of setting, and attempt to mitigate the above problem. It's possible we might want to support this sort of API in the future, if implementations are excited about implementing that research. This should be possible to fit into the existing API surface, possibly with some extra feature-detection API.\n\n### Flattening the API and reducing async steps\n\nThe current design requires multiple async steps to do useful things:\n\n```js\nconst translator = await translation.createTranslator(options);\nconst text = await translator.translate(sourceText);\n\nconst detector = await translation.createDetector();\nconst results = await detector.detect(sourceText);\n```\n\nShould we simplify these down with convenience APIs that do both steps at once?\n\nWe're open to this idea, but we think the existing complexity is necessary to support the design wherein translation and language detection models might not be already downloaded. By separating the two stages, we allow web developers to perform the initial creation-and-possibly-downloading steps early in their page's lifecycle, in preparation for later, hopefully-quick calls to APIs like `translate()`.\n\nAnother possible simplification is to make some of the more informational APIs, namely `canTranslate()`, `canDetect()`, and `supportedLanguages()`, synchronous instead of asynchronous. This would be implementable by having the browser proactively load the information about supported languages into the main thread's process, upon creation of the global object. We think this is not worthwhile, though, as it imposes a non-negligible cost on all global object creation.\n\n### Separating language detection and translation\n\nAs discussed in [For an unknown source language](#for-an-unknown-source-language), we support performing both language detection and translation to the best-guess language at the same time, in one API. This slightly complicates the `translate()` and `translateStreaming()` APIs, by giving them polymorphic return types.\n\nWe could instead require that developers always supply a `sourceLanguage`, and if they want to detect it ahead of time, they could use the `detect()` API.\n\nWe're open to this simplification, but suspect it would be worse for efficiency, as it bakes in a requirement of multiple traversals over the input text, mediated by JavaScript code. We plan to investigate whether multiple traversals over the input are necessary anyway according to the latest research, in which case this simplification would probably be preferable.\n\n## Stakeholder feedback\n\n* W3C TAG: \n* Browser engines:\n * Chromium: prototyping behind a flag\n * Gecko: \n * WebKit: \n* Web developers:\n * Some comments in [W3C TAG design review](https://github.com/w3ctag/design-reviews/issues/948)\n * Some comments in [WICG proposal](https://github.com/WICG/proposals/issues/147)\n\n## Appendix: converting between language tags and human-readable strings\n\nThis code already works today and is not new to this API proposal. It is likely useful in conjunction with this API, for example when building user interfaces.\n\n```js\nfunction languageTagToHumanReadable(languageTag, targetLanguage) {\n const displayNames = new Intl.DisplayNames([targetLanguage], { type: \"language\" });\n return displayNames.of(languageTag);\n}\n\nlanguageTagToHumanReadable(\"ja\", \"en\"); // \"Japanese\"\nlanguageTagToHumanReadable(\"zh\", \"en\"); // \"Chinese\"\nlanguageTagToHumanReadable(\"zh-Hant\", \"en\"); // \"Traditional Chinese\"\nlanguageTagToHumanReadable(\"zh-TW\", \"en\"); // \"Chinese (Taiwan)\"\n\nlanguageTagToHumanReadable(\"en\", \"ja\"); // \"่ฑ่ช\"\n```\n"
},
"prpreview": {
"src_file": "index.bs",
@@ -184279,7 +184263,7 @@
"href": "https://api.w3.org/groups/wg/webappsec/charters"
},
"active-charter": {
- "href": "https://api.w3.org/groups/wg/webappsec/charters/460"
+ "href": "https://api.w3.org/groups/wg/webappsec/charters/502"
},
"join": {
"href": "https://www.w3.org/groups/wg/webappsec/join"
@@ -184293,7 +184277,7 @@
},
"type": "working group",
"start-date": "2011-09-07",
- "end-date": "2024-04-30",
+ "end-date": "2026-04-30",
"fullshortname": "wg/webappsec",
"repos": [
{
@@ -186989,7 +186973,7 @@
"href": "https://api.w3.org/groups/wg/webauthn/charters"
},
"active-charter": {
- "href": "https://api.w3.org/groups/wg/webauthn/charters/457"
+ "href": "https://api.w3.org/groups/wg/webauthn/charters/501"
},
"join": {
"href": "https://www.w3.org/groups/wg/webauthn/join"
@@ -187003,7 +186987,7 @@
},
"type": "working group",
"start-date": "2016-02-08",
- "end-date": "2024-05-13",
+ "end-date": "2026-04-30",
"fullshortname": "wg/webauthn",
"repos": [
{