On 19 May 2014 13:40, Jan Schreiber <jan.schrei...@languagetool.org> wrote:
> Marcin wrote:
> > This is perfect English and you could probably find Jane Austin or
> > Charles Dickens using such constructions.
>
> I think this little discussion reveals a fundamental problem of an Open
> Source grammar checker, and perhaps of grammar checkers in general.
>
>
I think I see your point, and I gave a lot of thinking to it. A grammar
checker (or proofreader, as we call it in our web page) can perform many
tasks and there are some tasks that are virtually impossible to accomplish.
Depending on the user, we may find that there are different scopes.
For instance, I've heard of some users complaining about LT proposing a
different construction while their's was correct. The use case for the tool
in this case, is suggesting alternatives instead of proposing corrections,
but the user takes as a correction.
Other remarkable case is when LT warns about a construction with ambiguous
concordance, i. e. article, noun and adjective should be concordant but
they are not. In Spanish with long phrases this is a hassle, so you raise a
flag just in case -- but some users feel those warnings should not be there.
In summary, it is hard to find the balance of what should be reported and
what not.
*I propose that we consider adding high level filters for different scopes,
like errors, ambiguity and style suggestions*, allowing the users switching
them on an off like we are doing with categories today.
> There are a lot of people around who are well-meaning and intelligent
> and in some way interested in language and grammar, but are not trained
> linguists. This type of person will just take some grammar book (or even
> worse, a style manual) from their shelves and try to translate all the
> rules they happen to find there into LT rules, and they are unable to
> understand what the rule was originally intended to do. Eventually they
> end up doing more harm than good.
>
>
That is of course other very interesting subject. Implementing every
possible mistake is extremely inefficient. This is a learning I got form
the book "Operating Systems" from Andrew S. Tanenbaum. I see also that
looking at many particular cases rather than general ones is also
inefficient.
So the KPI "How many rules do I have in my LT language", linked to "the
more, the better" is a bad one for me. In terms of performance but over all
in terms of maintainability.
Therefore my suggestion is that we discuss KPI in terms of performance and
maintainability rather than in "bring rules to LT" and we set some goals. I
remember there was a nice simplification effort some time ago.
> These are just some thoughts I wanted to share. I'm not sure if I said
> something useful, or if these are just smartass remarks themselves.
>
To me it was quite interesting and refreshing. I think it is healthy to
challenge established practices now an then. Thank you, Jan.
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Languagetool-devel mailing list
Languagetool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/languagetool-devel
