El jue, 08-06-2006 a las 09:41 +0200, Thomas Lange escribió: > > Hi Santiago, > > > >> Otherwise the implementation would always have to start at the > >> beginning of the paragraph and step through until the current > >> sentence to be checked is found. > >> This would work as well. But maybe we can do it more cleverly... > > > > Think that inside a paragraph that has inter-sentence correspondences, a > > change in only one sentence could easily invalidate a previous sentence, > > already checked and validated. So, probably, you have to re-check a > > complete paragraph when you change a single sentence. > > Really?? > Having a sentence changed and thus invalidating a previous sentence > sounds really troublesome to me! > Should one not expect that the problem could and should be solved only > in the sentence that triggered the issue?
NO. I don't meant that. I was trying to say that the changed sentence could be invalidated by previous sentences in the same paragraph, or it could invalidate other sentences following this changed one. Again, the problem I see, and Daniel Naber seems to agree with this, is that maintaining state information about all paragraphs and sentences, could be complicated. > [...] > >> >> 7-) We are supposing that the smallest unit to be considered (for a > >> >> language) is a sentence. > >> > > >> > This would be true for the grammar checker, not for the API, unless > >> > handling multilingual paragraphs. But the grammar checker's suggested > >> > corrections could involve the replacement of one or more words (perhaps > >> > even a complete sentence, in extreme cases). > >> > >> I'm sorry but I think I did not completely understood the message of the > >> above paragraph. Are you saying if we provide paragraphs in the API but > >> still call the grammar checkers for a single sentence only to (to have > >> it check and displayed in the UI if necessary) you are fine? > > > > No, I mean that OOo should send a complete paragraph to the checker. The > > checker will return to OOo where is the error (position inside the > > paragraph), and possible replacements. > > Does that also implies that it you vote against determining the sentence > to be checked by e.g. means of start index and end index? > Or is it (only) about the need that to allow for identifying and > reporting errors before the starting index? No, I don't vote against it. It will be useless if we can assure that all grammar checkers implement sentence-boundaries detection, as they will have to re-check what OOo suggests as sentence. But there could be cases of simpler checkers that rely on OOo sentence detection capabilities. What I meant was that OOo will always send a complete paragraph, not an isolated sentence. > >> >> 9-) 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 ... > >> > > >> > Again, OOo must provide a paragraph to the grammar checker. The grammar > >> > checker should return nothing when there is no error, or return a list > >> > of wrong sentences inside the paragraph with his associated replacements > >> > (if they exists). > >> > >> I think returning all errors for all sentences in a paragraph is too > >> much. Especially if you also want to provide the suggestions for > >> correction. Providing all errors for a single sentence with one call is > >> the most should be done with one call. Maybe even this should be broken > >> up in several iterations... > > > > I agree here. Perhaps it will be useful to stop at the first error, as > > the paragraph has to be re-checked when you make corrections. > > I think you won't object if I change this to 'provide all errors of the > current sentence' at once. AFAIR this was thought useful mainly because > of possibly overlapping errors. Ok, that's what I meant also. Sorry, my english isn't good enough yet. > >> >> 10-) (Matthew Strawbridge) UI Language could be passed as a parameter to > >> >> grammar checker, which could choose to ignore it or to return comments > >> >> in that language if it knows how. > >> > > >> > This seems correct to me, but again too much fine-grained for this > >> > moment. > >> > >> Sure it is fine-grained. > >> But it is easy to ignore since it is not a 'must be'. ^_~ > > > > I think it was posted in the "must be" section. > > To make sure what I meant here: > There is no problem in having it as part of the API because the actual > single implementation of a grammar checker may choose to ignore this > whereas another may choose to oblige to it. Ok, I get it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
