You're still in danger of overly-broad hits. When you
try stemming differently into the _same_ underlying
field you get things that make sense in one language
but are totally bogus in another language matching
the query.
As far as lots and lots of fields is concerned, if you
want to restrict your
Thanks Jack! Indeed, very nice examples in your book.
Inspired from there, here's a crazy idea: would it be possible to build a
custom processor chain that would detect the language and use it to apply
filters, like the aforementioned SnowballPorterFilter.
That would leave at the end a document ha
ng
Although my e-book has a lot better examples, especially for the field
redirection aspect.
-- Jack Krupansky
-Original Message-
From: maephisto
Sent: Wednesday, September 11, 2013 8:33 AM
To: solr-user@lucene.apache.org
Subject: Re: Dynamic analizer settings change
Thanks, Erik
-Original message-
> From:maephisto
> Sent: Wednesday 11th September 2013 14:34
> To: solr-user@lucene.apache.org
> Subject: Re: Dynamic analizer settings change
>
> Thanks, Erik!
>
> I might have missed mentioning something relevant. When querying Solr, I
Thanks, Erik!
I might have missed mentioning something relevant. When querying Solr, I
wouldn't actually need to query all fields, but only the one corresponding
to the language picked by the user on the website. If he's using DE, then
the search should only apply to the text_de field.
What if I
I wouldn't :). Here's the problem. Say you do this successfully at
index time. How do you then search reasonably? There's often
not near enough information to know what the search language is,
there's little or no context.
If the number of languages is limited, people often index into separate
lan
