[
https://issues.apache.org/jira/browse/LUCENE-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174074#comment-13174074
]
Robert Muir commented on LUCENE-3663:
-------------------------------------
Santiago, yeah i think if normalization is successful, you would change the
type to <PHONE> as it was recognized as one.
otherwise when you get the exception, just 'return true' and leave all
attributes unchanged.
in the successful case, besides setting the type, if you wanted you could even
not throw away the PhoneNumber or whatever
but instead put it in an attribute. This way if someone wanted to do more
complicated stuff the attributes are at least available,
but its also useful for things like solr's analysis.jsp just for debugging how
the analysis worked.
> Add a phone number normalization TokenFilter
> --------------------------------------------
>
> Key: LUCENE-3663
> URL: https://issues.apache.org/jira/browse/LUCENE-3663
> Project: Lucene - Java
> Issue Type: New Feature
> Components: modules/analysis
> Reporter: Santiago M. Mola
> Priority: Minor
> Attachments: PhoneFilter.java
>
>
> Phone numbers can be found in the wild in an infinity variety of formats
> (e.g. with spaces, parenthesis, dashes, with or without country code, with
> letters in substitution of numbers). So some Lucene applications can benefit
> of phone normalization with a TokenFilter that gets a phone number in any
> format, and outputs it in a standard format, using a default country to guess
> country code if it's not present.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
