It suggests “O meu”;
Diz is according to European Portuguese rules. Anyway, this is more of a style rule than a grammar rule, so you can ignore it if you prefer.
It says “pás” is informal language.
Is 2) a false positive or can it somehow be improved not to be triggered in a sentence such as the above?
Due to the priority system, the word will not be tagged as informal when misused, but a special rule for “pá” has been added as well. This is the first false positive I see with it, but it should reduce them even further.
I could not reproduce this on my latest build. Only for the second line (1.1. Name).
I have been fiddling with this rule recently, because I found this type of false positive, so it should be fixed now on yesterday’s build. Anyway, I found that the decimal number was also triggered and it has also been improved.
SEND_END detection regression, may be the reason behind some false positives in this situations.
This is not a problem because wrongWordinContext takes priority. Every word can change the interpretation of the sentence completely (specially in disambiguation mechanisms), so we can’t safeguard against it.
Anyway, anyone can change line 20477 to <exception postag_regexp='yes' postag='(N.|[ADP]..|V.....)[FC].*|SPS.+'/></token>
in their copy if they find this is a common error in their wirtting.
You are going to murder me… but I found another issue… there is a dash issue in dates, please see the attached image (I tried to attach an .ODT but it is not supported… which is strange because it worked before?)
It complains about the dash in the first date: “20170326” but not in the one at the end of the page.
No problem, errors happen. I have seen inconsistant behaviour between LT-server, LT-standalone and LT-LibreOffice before, and there is even a bug I filed related to it. Sentence segmentation method is different.
I have looked into the code already regarding that, but that is an issue that requires more time to solve than what I am willing to spend on it, at the moment.
If the error is too specific, try to just delete the segment and rewrite. Nothing can be done regarding special characters or special formats, specially on LO. For example:
I was on Facebook and saw this mistake:
“Temos de por em prática tudo o que aprendemos!”
I was thinking about creating a rule that suggests “pôr” but I was wondering if the rule should be created to match the words “POR EM” or if there are more matches to be checked.
This can be very useful.
I believe that the best is to added a simple rule (detect both “de por” and “por em”) and correct after checking the regression tests. I can’t recall any exception, but they are bound to exist.
+Title: Beja
+Line 1, column 44, Rule ID: POR[1]
+Message: Substitua por 'pôr'.
+Suggestion: pôr
+A sua importância é atestada pelo facto de por lá passar uma das vias romanas.
+ ^^^
+
Should I remove the “de por” rule or is there a way to improve it?
Great question.
Seems like a false positive to me, though that made me have doubts about it too, since it does make logical sense to use ‘à’ for time expressions.
After today’s regression test results (that should be very verbose due to the NO_VERB rule correction) I will try to confirm and fix it.
This false positive is very misleading and needs to be addressed.
