You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Otis Gospodnetic (JIRA)" <ji...@apache.org> on 2008/05/14 08:13:55 UTC
[jira] Closed: (LUCENE-760) Spellchecker could/should use n-gram
tokenizers instead of rolling its own n-gramming
[ https://issues.apache.org/jira/browse/LUCENE-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Otis Gospodnetic closed LUCENE-760.
-----------------------------------
Resolution: Won't Fix
> Spellchecker could/should use n-gram tokenizers instead of rolling its own n-gramming
> -------------------------------------------------------------------------------------
>
> Key: LUCENE-760
> URL: https://issues.apache.org/jira/browse/LUCENE-760
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Analysis
> Reporter: Otis Gospodnetic
> Assignee: Otis Gospodnetic
> Priority: Minor
>
> The SpellChecker.java under contrib/spellchecker currently does its own creation of n-grams while it creates the index to search for alternative spelling suggestions, and then it again creates appropriate n-grams when it receives a query string/word to lookup alternative spelling suggestions for. Very clear sentence, I know.
> I think it might be better if n-gram chomping could be outsourced to n-gram tokenizers that just made their way into contrib/analyzers via LUCENE-759.
> If I see nods or if I don't get any nays I'll go and refactor SpellChecker.java a little bit to allow this.
> SpellChecker has a page on the Wiki: http://wiki.apache.org/jakarta-lucene/SpellChecker
> Thoughts?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org