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? And is this kind of problem a rather exotic one or is it likely to run into this every few paragraphs? And is it really a grammatical issue or more an issue of style or controlled language processing. The latter was never meant to be satisfied by the API of a grammar checker. (I'm wondering if we really have to take care of this issue...) Maybe if you could give a example it would prove helpful. >> >> 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? >> >> 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. >> >> 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. Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
