EH> Thanks for sharing that!
EH> Would you be interested in donating that to the contrib area for
EH> analyzers? The topic of normalizing accented characters has come up
EH> often lately. I noticed you already put the Apache license at the top
EH> of the code.
No problem, it was intended for th
On Apr 2, 2005, at 7:01 AM, Sven Duzont wrote:
EH> Could you share that filter with the community?
Of course, the code is in the attachment
Thanks for sharing that!
Would you be interested in donating that to the contrib area for
analyzers? The topic of normalizing accented characters has come up
Hello,
EH> What about handling BooleanQuery's nested within a BooleanQuery?
EH> You'll need some recursion.
thanks for all hints, i've re-coded the method to handle nested
BooleanQueries
EH> Could you share that filter with the community?
Of course, the code is in the attachment
>> // The fi
On Apr 1, 2005, at 11:07 AM, Sven Duzont wrote:
EH> I presume your analyzer normalized accented characters? Which
analyzer
EH> is that?
Yes, i'm using a custom analyser for indexing / searching, ti consists
in :
- FrenchStopFilter
- IsoLatinFilter (this is the one that will replace accented
char
EH> I presume your analyzer normalized accented characters? Which analyzer
EH> is that?
Yes, i'm using a custom analyser for indexing / searching, ti consists
in :
- FrenchStopFilter
- IsoLatinFilter (this is the one that will replace accented
characters)
- LowerCaseFilter
- ApostropheFilter (in
On Apr 1, 2005, at 8:09 AM, Sven Duzont wrote:
Since wilcard queries are not analyzed, how can we deal with accents ?
For instance (in french) a query like "ingé*" will not match documents
containing
"ingénieur" but the query "inge*" will.
I presume your analyzer normalized accented characters? W
Hello Erik,
Since wilcard queries are not analyzed, how can we deal with accents ?
For instance (in french) a query like "ingé*" will not match documents
containing
"ingénieur" but the query "inge*" will.
Thanks
---
sven
Le jeudi 31 mars 2005 à 17:51:25, vous écriviez :
EH> Wildcard terms si
Ernesto De Santis writes:
> Hi Erik
>
> Ok, in PrefixQuery cases, non analyze is right.
>
It creates the same problems.
'example*' should find 'example' but does not if 'example' is stemmed
to 'exampl' and you don't analyze the prefix query.
>
> You search "example" and obtain x results.
> You
On Mar 31, 2005, at 12:26 PM, Ernesto De Santis wrote:
Hi Erik
Finally, my name spelled correctly. :))
Ok, in PrefixQuery cases, non analyze is right.
But you think that non analyze in WildcardQuery is right?
Do I think its right? That's just the way it is. Whether that is
right or not I don
Hi Erik
Ok, in PrefixQuery cases, non analyze is right.
But you think that non analyze in WildcardQuery is right?
You search "example" and obtain x results.
You search "ex?mple" and don't obtain any result.
This is correct for you?
It is difficult to analyze wildcard queries in lucene code?
Ernesto
Wildcard terms simply are not analyzed. How could it be possible to do
this? What if I search for "a*" - how could you stem that?
Erik
On Mar 31, 2005, at 9:51 AM, Ernesto De Santis wrote:
Hi
I get an unexpected behavior when use wildcards in my queries.
I use a EnglishAnalyzer develope
Hi
I get an unexpected behavior when use wildcards in my queries.
I use a EnglishAnalyzer developed with SnowballAnalyzer. version 1.1_dev
from Lucene in Action lib.
Analysis case:
When use wildcards in the middle of one word, the word in not analyzed.
Examples:
QueryParser qp = new Qu
12 matches
Mail list logo
