Skip to content

Commit 7bb4764

Browse files
Update README.md
1 parent 2870e45 commit 7bb4764

File tree

1 file changed

+17
-17
lines changed

1 file changed

+17
-17
lines changed

README.md

Lines changed: 17 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ Web applications can also benefit from such proofreading capability. This propos
99

1010

1111
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).
1313
3. Error Explanation: Annotates each error with a plain language explanation
1414

1515
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
1818

1919
Our goals are to:
2020

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.
2222
* 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.).
2424
* Enable progressive enhancement, so web developers can gracefully handle varying levels of user agent support.
2525

2626
The following are explicit non-goals:
2727

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

3131
## Use cases
3232

3333
* Proofread and suggest corrections to user messages in chat applications
3434
* Proofread and help polish email drafting
3535
* Catch errors and provide corrections during note-taking
3636
* Proofread a comment to a forum/article/blog
37-
* Provide high quality 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
3838

3939
## Examples
4040

@@ -106,13 +106,13 @@ const proofreader = await Proofreader.create({
106106
### Testing available options before creation
107107
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).
108108

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

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

113113
The method will return a promise that fulfills with one of the following availability values:
114114
`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.
116116
`downloading`” means that the implementation supports the requested options, but it will have to finish an ongoing download before it can do anything.
117117
`available`” means that the implementation supports the requested options without requiring any new downloads.
118118

@@ -138,7 +138,7 @@ if (supportsOurUseCase !== "unavailable") {
138138
```
139139

140140
### 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:
142142

143143
```js
144144
const proofreader = await Proofreader.create({
@@ -192,7 +192,7 @@ dictionary ProofreadResult {
192192
}
193193
```
194194
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.
196196
197197
```js
198198
dictionary ProofreadCorrection {
@@ -212,7 +212,7 @@ Not all correction types here will be applicable to all languages, and in the fu
212212
213213
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.
214214
215-
Example usage of the output to highlight error in input:
215+
Example usage of the output to highlight an error in input:
216216
217217
```js
218218
let inputRenderIndex = 0;
@@ -232,7 +232,7 @@ for (const correction of corrections) {
232232
inputRenderIndex = correction.endIndex;
233233
}
234234

235-
// Render rest of input that has no error.
235+
// Render the rest of the input that has no error.
236236
if (inputRenderIndex !== input.length){
237237
const unchangedInput = document.createElement('span');
238238
unchangedInput.textContent = input.substring(inputRenderIndex, input.length);
@@ -314,17 +314,17 @@ However, due to technical limitations of the on-device language model, generatin
314314
315315
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.
316316
317-
### Interaction with other browser integrated proofreading feature
317+
### Interaction with other browser-integrated proofreading features
318318
319319
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.
320320
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.
322322
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.
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.
324324
325325
### Customization with user-mutable dictionary
326326
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.
327327
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.
329329
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

Comments
 (0)