[ https://issues.apache.org/jira/browse/LUCENE-8784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845933#comment-16845933 ]
Namgyu Kim edited comment on LUCENE-8784 at 5/22/19 2:38 PM: ------------------------------------------------------------- Thank you for your reply, [~jim.ferenczi] :D I tried to process only "." character in Tokenizer. Because Korean is a language that can have a whitespace in sentence, but Japanese is not. (Character.OTHER_PUNCTUATION would match more than just the full stop character. => Right. That's a problem. I have to change that part...) JapaneseTokenizer keeps whitespace when using the discardPunctuation option. (example : "十万二千五 百 二千五" (means "102005 100 2005") If we run the JapaneseTokenizer with discardPunctuation=false and JapaneseNumberFilter, we get: {"102005", " ", "100", " ", "2005"}) Of course we can do it with StopFilter or internal processing in other Filter, but is it okay..? Developing a NumberFilter looks much more flexible and structurally beautiful rather than internal processing in Tokenizer. But I have developed like this because of the above problems, how can we handle those spaces? I think there are several ways to handle this problem: 1) Remove whitespace from Punctuation list in Tokenizer. 2) Use a TokenFilter to remove whitespace. 3) Remove whitespace from KoreanNumberFilter. (looks structurally strange...) 4) Just leave whitespace was (Author: danmuzi): Thank you for your reply, [~jim.ferenczi] :D I tried to process only "." character in Tokenizer. Because Korean is a language that can have a whitespace in sentence, but Japanese is not. (Character.OTHER_PUNCTUATION would match more than just the full stop character. => Right. That's a problem. I have to change that part...) JapaneseTokenizer keeps whitespace when using the discardPunctuation option. (example : "十万二千五 百 二千五" (means "102005 100 2005") If we run the JapaneseTokenizer with discardPunctuation=false and JapaneseNumberFilter, we get: {"102005", " ", "100", " ", "2005"}) Of course we can do it with StopFilter or internal processing in other Filter, but is it okay..? Developing a NumberFilter looks much more flexible and structurally beautiful rather than internal processing in Tokenizer. But I have developed like this because of the above problems, how can we handle those spaces? I think there are several ways to handle this problem: 1) Remove whitespace from Punctuation list in Tokenizer. 2) Use a TokenFilter to remove whitespace. 3) Remove whitespace from KoreanNumberFilter. (looks structurally strange...) 4) Just leave whitespace > Nori(Korean) tokenizer removes the decimal point. > --------------------------------------------------- > > Key: LUCENE-8784 > URL: https://issues.apache.org/jira/browse/LUCENE-8784 > Project: Lucene - Core > Issue Type: Improvement > Reporter: Munkyu Im > Priority: Major > Attachments: LUCENE-8784.patch > > > This is the same issue that I mentioned to > [https://github.com/elastic/elasticsearch/issues/41401#event-2293189367] > unlike standard analyzer, nori analyzer removes the decimal point. > nori tokenizer removes "." character by default. > In this case, it is difficult to index the keywords including the decimal > point. > It would be nice if there had the option whether add a decimal point or not. > Like Japanese tokenizer does, Nori need an option to preserve decimal point. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org