Ah, have to dig deeper then :)

So in the API result the spelling error comes first but in the
editor_plugin.js we iterate backwards and ignore positions we already
covered (code below). Thus the webpage hides spelling error if
overlapped by another rule that's following it.
I guess the code in Chrome extension does iterate forward, here's the
difference.

So we need to figure out how to make them consistent.

I would say for Ukrainian the spelling rule will have lower priority
that many other built-in rules — as many of those will actually
explain why it's spelled wrong (e.g. one rule will tell about Latin
letter inside Cyrillic word that is very hard to recognize visually).
And in Ukrainian the spelling rule is 2nd in the list so the web-page
works nicely with reverse iteration.

In other languages, like English and German I see spelling rule is
added at the end of built-in rules so the order is a bit different.

Whatever order we agreed on is probably not important as long as we
can control it :)

Regards,
Andriy

    // iterate backwards as we change the text and thus modify positions:
    for (var suggestionIndex = this.suggestions.length-1;
suggestionIndex >= 0; suggestionIndex--) {
        var suggestion = this.suggestions[suggestionIndex];
        if (!suggestion.used) {
            var spanStart = suggestion.offset;
            var spanEnd = spanStart + suggestion.errorlength;
            if (previousSpanStart != -1 && spanEnd > previousSpanStart) {
                // overlapping errors - these are not supported by our
underline approach,
                // as we would need overlapping <span>s for that, so
skip the error:
                continue;
            }

2016-05-16 16:12 GMT-04:00 Daniel Naber <daniel.na...@languagetool.org>:
> On 2016-05-16 19:09, Andriy Rysin wrote:
>
>>   public List<RuleMatch> filter(List<RuleMatch> ruleMatches) {
>>     Collections.sort(ruleMatches);
>> ...
>>
>> but I didn't realize we only sort by the error positions so if if
>> positions are exactly the same it's random.
>
> Nice catch, but Chrome and the form on languagetool.org both access the
> same API and if you call it directly at
> https://languagetool.org:8081/?autodetect=yes&text=... you'll see that
> the results seem to be stable. Also see
> http://docs.oracle.com/javase/8/docs/api/java/util/Collections.html and
> search for "stable". So I still think the issue is that both clients
> ignore different rules.
>
> Regards
>   Daniel
>
>
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> Languagetool-devel mailing list
> Languagetool-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/languagetool-devel

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Languagetool-devel mailing list
Languagetool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/languagetool-devel

Reply via email to