Full UPPERCASE Spellchecks

Development
1

We have recently implemented a rule (thanks Languagetool!) to be able to catch UPPERCASE typos, for example: “I WANT TO PAINC THIS IN RED”. Here goes:

fsa.dict.speller.ignore-numbers=false
fsa.dict.speller.ignore-all-uppercase=false
fsa.dict.speller.ignore-camel-case=false
fsa.dict.speller.ignore-punctuation=true
fsa.dict.input-conversion=` ’ , ’ ’ , ‘ ’ , ´ ’
fsa.dict.speller.convert-case=true

The rule is working, however, suggestions appear to be mixed case:

                "Pain",
                "Paint",
                "Panic",
                "Pains",
                "Paine",
                 etc.

I was wondering if there is a way to keep suggestions in Full Uppercase: PAIN, PAINT, PANIC, etc.
:capital_abcd:

Thank you :slight_smile:

2

Hi all,

After latest 4.0 release, English won’t pick Uppercase errors anymore :frowning:

IT DOESNT MOTTER:
YOURE PART OF THE GWAME.

Missing apostrophe is detected, but not the other 2 typos.
Uppercase errors get flagged for other languages such as Portuguese for instance:

por UP

I just added this on the Rule Editor, perhaps we can fix it?

**** GWAME YOU ARE PART OF THE GWAME. YOU ARE PART OF THE GAME.

Thank you!

3

Sorry, the rule gets clubbed:

UP rule
UP rule.png2700×614 111 KB

4

This is not related to LT 4.0, it has always(?) been the case. The reason is that there’s no entry fsa.dict.speller.ignore-all-uppercase=false in en_US.info (source). As other people have wondered about the current behavior before, should we change it? The drawback is that less common acronyms like “PMN” or “OCA”, which are not in the dictionary, will be considered incorrect.

5

It would also increase the false positives for onomatopoeia.

EG:
His competitor had spun himself a score of 98, so Joseph spun the wheel as hard as he could.
##TRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR-T-T-T-T-T-T-T-T-T-T-T-T-T-T-T-T-T-T-T-T-T-T-T-T-T-T-T-T-TICK-TICK-TICK-TICK-TICK-…##
‘Come on! give me a 100 or even just a 99!’ Joseph ‘asked’ from the wheel.
##… TICK… TICK… TICK… TIICK… TIIICK… TIIII-…##
'NO! Don’t rest on…!'
The game-host announced his score as “97… Sorry Joseph, but that puts you out of the game. Fred, care to join me for the final round?”

6

@SkyCharger001

Useful things cause false positives. If they are well designed, they cause as little as possible.

I couldn’t find an easier little picture to show it, but this should be good enough. Change ‘healthy’ by ‘correct’ and ‘sick’ by ‘misspelled’.

7

unfortunately English (or almost any language) is not well designed when it comes to false positives.

8

This was relative to tests. Even the best linguists and grammarians make general rules that have exceptions. One exception is a false positive.
What we can do is to reduce the bell curves overlap by improving rules, but there will always be false positives in every test (Languagetool rule). Specially, when we are dealing with especially designed examples, outside the purpose of any grammar checker, like:

One day, I will draw a simpler picture.

9

it’s clear that you don’t know what false positive means.
a false positive is not an exception to a rule, it is a situation where something that is not a match is mislabeled as being a match. (a common cause of false positives is improper simplification of a rule, but your ‘definition’ switches cause and effect around)

10

I have changed that now, for en-US and all other English variants. The next snapshot will also check all-uppercase words.

11

Thank you Daniel!

We have tried updating the API in our system but the rule won’t work. 12

Perhaps we should reinstall?

12

It should work when you use the latest daily build: Index of /snapshots/

13

Thanks again very much!