Daniel wrote:
> > http://soc-grammar.blogspot.com
>
> > 6-) (Thomas Lange) The checking should stop in the first error found.
>
> For checkers that do real parsing that makes sense, less so for checkers
> that scan for word/part-of-speech sequences.
I agree. The check should not stop at the first error found. I don't
think this is within the scope of the API -- this should just call
the grammar checkers in turn and handle the results. All of the
grammar checkers should be called, regardless of whether each finds
errors. The grammar checkers themselves might wish to stop at the
first error and just return that. But the API must handle the case
that other grammar checkers wish to return a list of errors (as
stated in 10). Many of the grammar 'errors' will actually be
recommendations, and the user may rightly choose to ignore them. We
can't let errors hide one another.
> > 9-) If the grammar checker find an error the complete sentence is marked
> > as it has an error. (Not just a piece of sentence has errors).
> Does that mean the whole sentence would be underlined? I guess not, as
> that wouldn't make sense.
+1 (don't underline whole sentence). If we underlined the whole
sentence, many first-draft documents would be completely covered by
underlining!
However, we do need to work out how to manage the case where two
errors overlap (we need to make it obvious to the user that there is
more than one error there). One approach would be to change the right-
click menu so that it displays at the top level the different
sentence parts with errors, and under these the options for change.
For example, consider the following:
An broken sentence.
~~~~~~~~~~~~~~~~~~~
[whole thing wavy underlined because one of the errors spans the
sentence]
Right-click menu could have the following structure:
An broken sentence.
"Fragment"
No suggestions
Show detailed description
An
"Use 'a' not 'an' before a consonant sound."
Change to A
Show detailed description
Where "An broken sentence" and "An" are at the top level of the menu.
I'm confused by the following points:
> 7-) The API must know how to split paragraphs into sentences, this was
> changed to provide multilingual checking.
> 10-) The API should provide a paragraph (for example) to grammar checker
> and this one should return a list.
> Not in API 1) OpenOffice *DO NOT* provide text blocks (paragraph).
Is the API going to send paragraphs or sentences? Or paragraphs with
embedded markers to show where it thinks the sentence boundaries are?
In addition, should point 10 be extended to mention two levels of
comments (brief and detailed)? There was some agreement with this
suggestion of mine, and grammar checkers will be able to return
nothing for this extra field if they wish.
Here are some specific requirements that seem to be missing from the
blog page at the moment:
* The API shall support many grammar checkers for each language.
* There will be two types of grammar-checking: real-time checks,
displayed as wavy lines in the document, and interactive checks of
the whole document via a dialog box.
* It should be possible to have both spell checkers and grammar
checkers enabled at the same time. If people choose to use grammar
checkers that have built-in dictionaries, they can choose to turn off
the spell checker, but I think the option to have both running should
be there.
Best wishes
Matthew
--
Matthew Strawbridge http://www.philoxenic.com (01353) 663650
Bespoke software development and freelance technical copy editing
{ Write bulletproof code before the shooting starts. }
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
