Open danielnaber opened 9 years ago
Also see the discussion at http://www.mail-archive.com/languagetool-devel@lists.sourceforge.net/msg04435.html
For the recursive tags, Laszlo suggests to use the output of the first unmunch as a dictionary for a second unmunch. I couldn't make that work yet in a sensible way (tried with Galician).
Compound support would be needed for a lot of languages. The + side is it accepts words just invented; the - side is it also accpets some wrong words that are technically correct. For all those languages using a huge words list and hunspell dictionary as a filter will render a workable words list. I guess 99.99% coverage would be good enough. With a large corpus as input, it can be done.
To provide a 100% pure Java software, we'd like to switch from Hunspell native code to Morfologik. See http://wiki.languagetool.org/hunspell-support for how to build the Morfologik dictionaries.
Find all affected languages by looking for usages of Hunspell and its sub classes (like HunspellNoSuggestionRule):
AsturianSpanishTagalogThe following might not be trivial to port to Morfologik:
virkar
andtexta
not being recognized by Morfologik, but they are accepted by our hunspell code...)construíu/102,103,104|
-- seems to be caused by "recursive" definitions likeSFX 232 oñer ón/104 poñer
)^
and_
in itsREP
statements, not supported by replacement-pairs in Morfologik yet^
and$
in itsREP
statements, not supported by replacement-pairs in Morfologik yet (see https://github.com/morfologik/morfologik-stemming/issues/38)REP
statements, which might slow down Morfologik too much