You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+17-17Lines changed: 17 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ Web applications can also benefit from such proofreading capability. This propos
9
9
10
10
11
11
1. Error Correction: Correct input text by the user
12
-
2. Error Labeling: For each correction made to each error in the input text, label the error type (e.g. spelling, punctuation, etc.)
12
+
2. Error Labeling: For each correction made to each error in the input text, label the error type (e.g., spelling, punctuation, etc).
13
13
3. Error Explanation: Annotates each error with a plain language explanation
14
14
15
15
Note that Labeling & Explanation are independent features that can be either added or dropped.
@@ -18,23 +18,23 @@ Note that Labeling & Explanation are independent features that can be either add
18
18
19
19
Our goals are to:
20
20
21
-
* Help web developers perform real-time proofreading (e.g. of user input) on short phrases/sentences/paragraphs of freeform text.
21
+
* Help web developers perform real-time proofreading (e.g., of user input) on short phrases/sentences/paragraphs of freeform text.
22
22
* Allow web developers to build flexible proofreading UI/UX.
23
-
* Offer higher-level APIs with specific inputs and output formats that can support error labeling and explanations, abstracting away the underlying implementation (e.g. OS feature, language model, etc.).
23
+
* Offer higher-level APIs with specific inputs and output formats that can support error labeling and explanations, abstracting away the underlying implementation (e.g., OS feature, language model, etc.).
24
24
* Enable progressive enhancement, so web developers can gracefully handle varying levels of user agent support.
25
25
26
26
The following are explicit non-goals:
27
27
28
-
* Proofreading for markdown or other formats/syntaxes (e.g. not intended for JS code)
29
-
* Check for consistent style and formatting throughout a userprovided input
28
+
* Proofreading for markdown or other formats/syntaxes (e.g., not intended for JS code)
29
+
* Check for consistent style and formatting throughout a user-provided input
30
30
31
31
## Use cases
32
32
33
33
* Proofread and suggest corrections to user messages in chat applications
34
34
* Proofread and help polish email drafting
35
35
* Catch errors and provide corrections during note-taking
36
36
* Proofread a comment to a forum/article/blog
37
-
* Provide highquality interactive proofreading along with labeling & explanations for the correction when writing documents
37
+
* Provide high-quality interactive proofreading, along with labeling & explanations for the correction when writing documents
The proofreading API is customizable during the `create()` calls, with various options including the language option above. All options are given in more detail in the [later section](#full-api-surface-in-web-idl).
108
108
109
-
However, not all models will necessarily support every language and it might require a download to get the appropriate fine-tuning or other collateral necessary on the first use.
109
+
However, not all models will necessarily support every language, and it might require a download to get the appropriate fine-tuning or other collateral necessary on the first use.
110
110
111
111
In the simple case, web developers should call `create()`, and handle failures gracefully. However, if they want to provide a differentiated user experience, which lets users know ahead of time that the feature will not be possible or might require a download, they can use the API’s promise-returning `availability()` method. This method lets developers know, before calling `create()`, what is possible with the implementation.
112
112
113
113
The method will return a promise that fulfills with one of the following availability values:
114
114
“`unavailable`” means that the implementation does not support the requested options.
115
-
“`downloadable`” means that the implementation supports the requested options, but it will have to download something (e.g. machine learning model or fine-tuning) before it can do anything.
115
+
“`downloadable`” means that the implementation supports the requested options, but it will have to download something (e.g., a machine learning model or fine-tuning) before it can do anything.
116
116
“`downloading`” means that the implementation supports the requested options, but it will have to finish an ongoing download before it can do anything.
117
117
“`available`” means that the implementation supports the requested options without requiring any new downloads.
118
118
@@ -138,7 +138,7 @@ if (supportsOurUseCase !== "unavailable") {
138
138
```
139
139
140
140
### Download progress
141
-
For cases where using the API is only possible after a download, you can monitor the download progress (e.g. in order to show your users a progress bar) using code such as the following:
141
+
For cases where using the API is only possible after a download, you can monitor the download progress (e.g., in order to show your users a progress bar) using code such as the following:
142
142
143
143
```js
144
144
constproofreader=awaitProofreader.create({
@@ -192,7 +192,7 @@ dictionary ProofreadResult {
192
192
}
193
193
```
194
194
195
-
`corrected` is the fully corrected version of the input, while `corrections` contains a list of corrections made, their locations in the original input (e.g. so web developers can create UI to highlight the error), and optionally labels/explanations.
195
+
`corrected` is the fully corrected version of the input, while `corrections` contains a list of corrections made, their locations in the original input (e.g., so web developers can create UI to highlight the error), and optionally labels/explanations.
196
196
197
197
```js
198
198
dictionary ProofreadCorrection {
@@ -212,7 +212,7 @@ Not all correction types here will be applicable to all languages, and in the fu
212
212
213
213
To get an error in the input, use `input.substring(startIndex, endIndex)`. Corrections in the `corrections` list will be organized in ascending order based on the `startIndex` of the correction.
214
214
215
-
Example usage of the output to highlight error in input:
215
+
Example usage of the output to highlight an error in input:
216
216
217
217
```js
218
218
let inputRenderIndex =0;
@@ -232,7 +232,7 @@ for (const correction of corrections) {
232
232
inputRenderIndex =correction.endIndex;
233
233
}
234
234
235
-
// Render rest of input that has no error.
235
+
// Render the rest of the input that has no error.
@@ -314,17 +314,17 @@ However, due to technical limitations of the on-device language model, generatin
314
314
315
315
To address this, we propose to only offer **streaming explanations** asynchronously from the list of corrections (ProofreadCorrection) through a streaming API. Specifically, instead of returning explanations for all corrections at one time, we would return one correction’s explanation at a time as they become available. This way, web developers can provide sooner UI updates to the users to make the experience less jarring.
316
316
317
-
### Interaction with other browserintegrated proofreading feature
317
+
### Interaction with other browser-integrated proofreading features
318
318
319
319
As web developers implement UX around this proofreading API, if users’ browser supports other integrated proofreading features, the UX could get confusing with two features trying to help at once.
320
320
321
-
The [spellcheck](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/spellcheck) attribute from HTML available across browsers might help developers to signal to the browser to turn off its integrated spelling check if it has one. For example, when `spellcheck` is set to `false`, no red underlines/squiggly lines will appear to indicate a spelling error.
321
+
The [spellcheck](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/spellcheck) attribute from HTML available across browsers might help developers signal to the browser to turn off its integrated spelling check if it has one. For example, when `spellcheck` is set to `false`, no red underlines/squiggly lines will appear to indicate a spelling error.
322
322
323
-
For more sophisticated browserintegrated proofreading features, it’s an open question how to address the potential conflicts. For example, for browser extensions, one option is for web developers to detect the presence of certain extensions and then decide the behavior of their own proofreading feature.
323
+
For more sophisticated browser-integrated proofreading features, it’s an open question how to address the potential conflicts. For example, for browser extensions, one option is for web developers to detect the presence of certain extensions and then decide the behavior of their own proofreading feature.
324
324
325
325
### Customization with user-mutable dictionary
326
326
While the proposed Proofreading API corrects user input based on general knowledge, there could be cases where users would prefer to ignore correcting certain proper names, acronyms, etc. For example, the proposed [Dictionary API](https://github.com/Igalia/explainers/pull/37) allows users to add and remove words from the browser’s custom dictionary to address special use cases.
327
327
328
-
The Proofreading API can potentially allow users to specify a custom dictionary, and avoid correcting any words included in the dictionary.
328
+
The Proofreading API can potentially allow users to specify a custom dictionary and avoid correcting any words included in the dictionary.
329
329
330
-
However, in cases where ignoring certain words for correction could potentially change the meaning/structure of a sentence, it could be a bit tricky to proofread with pre-trained language models. Therefore, we are moving forward without integration with custom dictionaries until further exploration and evaluation is done. Nevertheless, we invite discussion of all of these APIs within the Web Machine Learning Community Group.
330
+
However, in cases where ignoring certain words for correction could potentially change the meaning/structure of a sentence, it could be a bit tricky to proofread with pre-trained language models. Therefore, we are moving forward without integration with custom dictionaries until further exploration and evaluation are done. Nevertheless, we invite discussion of all of these APIs within the Web Machine Learning Community Group.
0 commit comments