> 1. Grammar Checker API, now: > > 1. It makes sense working with just one language now; so, foreign > words in the text should be ignored. > 2. The grammar checker should run in a different thread to not block > OpenOffice. > 3. The grammar checker should be able to check inside table cells, > text headers and footers, enumerations and text boxes (Drawing Objects). > 4. The grammar checker should determine end of the sentences, because > it is not so trivial (e.g., abbreviations). So, OpenOffice should just > provide to the grammar checker an entire block of text, like a paragraph.
I agree that determining the ends of sentences is non-trivial. However, I think that this is a good reason to do it once in OOo instead of each grammar checker having to figure it out manually. OOo already maintains a list of abbreviations (ending with .), so presumably this could be used. If the user adds custom abbreviations, these would then automatically be picked up by the sentence splitter, which wouldn't happen if each grammar checker implemented its own. > 5. OpenOffice should be able to replace the wrong sentences. > 6. I think we should create an unified User Interface, for any grammar > checker use it. I vote for the unified UI. If necessary, have an Options button to open a dialog box generated by the current grammar checker, but I think the day-to-day operations of grammar checking should look the same regardless of the back-end tools. > 7. Automatic checking should run in background and marking the wrong > sentences with a wavy line. It could be enabled and disabled, like Spell > Checker. I haven't seen this mentioned explicitly, but I think there should be a menu option Tools, Grammar Check to launch the grammar checker to check through the whole document from beginning to end (as the spell checker can do). Some people would prefer to turn off the wavy lines and just use this mechanism to do the checks, so they are not distracted when they are writing. > 8. The API should provide a paragraph (for example) to grammar checker > and this one should return a list. If there is no mistake in this > paragraph, the list should be empty, else the list should contain: > 1. Where is the mistake in the paragraph (initial index + final > index). > 2. A list of suggestions to correct that mistake (this list can > be empty if checker is not prepared to guess). > 3. A comment about mistake, e.g. what a grammar book should say > about it. It might be a good idea to have two levels of comments -- one brief and one detailed. The view of the detailed portion could then be toggled on and off in the UI. Users could then see at a glance a single sentence describing the problem. If they needed more information, they could expand the view to show the detailed explanation, which might include a more detailed explanation of why the selected text is thought to be an error, examples of correct and incorrect use, and references for further information. > 2. Grammar Checker API, future: > > 1. Let's suppose it's possible to manage several languages in a text > and there is a Language Guessing API. Then, when OpenOffice discover > language of a sentence, it automatically loads grammar checker to > correspondent language. As people have already mentioned, there may be more than one grammar checker loaded for any given language. This is particularly likely for my project: graviax. This tool is much simpler than most of the others -- it uses regular expressions and doesn't attempt to parse the sentences. However, because of this, it is easy for users to update the rules to match their own preferences (for example, publishers could create a rule set for their particular house style). Therefore, I would expect to have two English-language grammar checkers running at the same time: a heavyweight checker that can catch errors like "a red apples" (which is impossible to do reliably in graviax) and then graviax running as well (for example, to highlight cliches). I'm not sure how this would work in terms of squiggly lines. It would be nice if the user could set the colour of the line associated with each tool independently, but that might be overkill. > 2. Optimize memory allocation, input/output and processing. For > example, OOo's spell checker uses a special dictionary, CoGrOO (which is > the > only grammar checker that I know) uses another kind of dictionary; we can > create a unified dictionary but this implies modification in spell checker. > 3. (Marcin Milkowski) Extend the user interface to provide more > parameters to grammar checker, like colloquial, official and etc. This could be dealt with by allowing the user to disable rules (see next point). > 4. Daniel Naber suggests there should be a way to disable the rules. > I think we have to discuss this because this is not a trivial task for a > final user; enable a grammar rule requires at least human language > knowledge > and proficiency. For example M$ Office doesn't allow users to change rules, > OOo's spell checker requires a file edition (a ispell dictionary), without > a > user interface to do it. I think that the inflexibility of the MS Office grammar checker is one of the reasons that lots of people turn it off. They simply don't trust what it says. Many grammar rules (such as using 'that' for restrictive clauses and 'which' for non-restrictive ones) are really recommendations, particularly in British English. The lack of a description in the UI certainly doesn't help either -- people are told that things are wrong, but it is not explained _why_ they are wrong. I hope we can create a grammar checker system that hands control back to the users (so they can turn rules on and off) and actually helps them to improve their writing by showing them where they have gone wrong. My suggestion would be to create the absolute simplest API to start with. Use full stops to determine sentence breaks, even though some of these will be wrong. Just add a menu item and dialog box for working through the whole document -- don't do real-time checking yet. Check whole document against a single grammar checker in a single language. Best wishes Matthew -- Matthew Strawbridge http://www.philoxenic.com (01353) 663650 Bespoke software development and freelance technical copy editing { "A young man with good health and a poor appetite can save up money." -- James Montgomery Bailey } --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
