Hi Matthew,
>> Just curious because I do not know about this: >> Where should the user add custom abbreviations in order to get >> recognized by the breakiterator? >> Is there already sth. like that or is this a kind of proposal of yours? > > Tools, AutoCorrect, Exceptions has a list of abbreviations. If OOo > were to have been used for splitting the sentences, this list might > have been useful. Since the consensus seems to be to pass whole > paragraphs to the grammar checker, this list probably isn't relevant > any more. I see. I confirmed with the maintainer of the auto-correction that this list could be accessed by the breakiterator. But currently it does not take advantage of those abbreviations and the implementation needs to be change to allow for this. Thus it is likely to be sth. for the 'nice-to-have' list. I miss to see why the relevance of this depends upon a whole paragraph being passed on to the grammar checker or not... > If there are to be two types of grammar checking -- real-time with > underlining and a separate task for checking the whole document -- > then I think it will be sufficient for the whole-document check to > start at the beginning of the document. Is there something like a explicit whole-document-check in the UI? Do you want sth. different from the automatic checking (which actually migt start anywhere but is probably preferred to start in the current visible text) and interactive checking? Interactive checking should always start at the cursor position (or maybe at the begin of the paragraph where the cursor is in). I'm willing to give up on starting in the current visible text area for automatic checking though. But I wonder if someone will complain that this was already better implemented for spell checking later on. > I suppose that there could be > an option about whether to start at the current text insertion point > or the beginning of the document; personally, I'd probably want to > check the whole document once I'd finished writing it, so wouldn't > use this extra option. That is I guess you would not want to activate automatic checking and when you are finished just like to jump to the top of the document and start interactive checking there. Correct? >> BTW: Do we all agree that it is sufficient to have that comment in the >> language of the sentence being checked only? >> That is if we have for example a French UI and check some English text >> the comment should be only in English. And if the next sentence would be >> German the comment will now be in German. >> >> Otherwise it will probably get rather complicated here... > > Good point, which I hadn't thought of. If someone writes, say, a > latin grammar checker, should the comments be in latin? I suppose > that the UI language could be passed as a parameter to the grammar > checker, which could choose to ignore it or to return comments in > that language if it knows how. This would be possible. Do we like to introduce this extra functionally or will it be only a not much useful feature at all since one should know the languages to be checked in order to be capable to make the corrections. > When people add extra spell checkers, they are trying to reduce the > number of correct words that are incorrectly marked as mistakes, for > example by adding a medical dictionary. So it makes sense that a word > is OK if it is found in any of the spell checkers' dictionaries. > > Conversely, I would think that people would add extra grammar > checkers to catch more errors (much like having more than one virus > scanner on a PC). Users should understand that doing this will affect > performance. I think that all of the grammar checkers should be > called, regardless of whether each finds any errors. I see the reasoning. So i just like to ask anybody else: Is there some objection to this? Or can we list this one as 'agreed upon by community'? > I don't think that the "be" --> "is" change should be shown to the > user twice, if we can avoid it. Perhaps the first grammar checker in > the list should take precedence when the same error is found more > than once (the other option would be to merge the comments they > return, but I think this would be messy). > > We also need to think about what happens to the underlining when > several potential errors overlap (whether their source is one or more > grammar checkers). For example, if a whole sentence is marked for > some reason (for example, for being a fragment) then this will hide > any other errors that occur within it. Given the state of UI and core we can only have one type of underlining. > I take your point, but subscribe to the 'do the simplest possible > thing that works' approach. Various complications are bound to arise, > and will be caught earlier and will be more easy to fix under an > incremental approach rather than a big-bang model. Agreed. That's why we agreed with Bruno to have him implement a dummy prototype of the planned integration model. In order to be able to toy around with it a bit and thus maybe find some problems, and last but not least to verify that our planned approach is actually functional and the API living up to the task. > I don't think we should be in too much of a rush with this. The worst > thing we could do would be to rush out a solution that people try, > don't like and switch off. Once you've lost people in this way, it's > hard to win them back. +1 I hope that we can use the dummy prototype to check if people will be happy or not. Of course it wont' refined in detail. For example I won't bother about comments like "the dialog is to small" or "the button should be else where"... ;-) Regards, Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
