Our product search should be accent insensitive as querying for "jamón" or "jamon" should return all items matching wether "jamon" or "jamón".
We're using Dynamicweb 9.9.6
Our product search should be accent insensitive as querying for "jamón" or "jamon" should return all items matching wether "jamon" or "jamón".
We're using Dynamicweb 9.9.6
Hi Cristina,
You need to set up a custom field type with the UnaccentedWordAnalyzer in the index.
https://doc.dynamicweb.com/documentation-9/indexing/indexing-search/indexes#sideNavTitle1-4-4
When you have done that you should be able to create a new custom field in the index, which should then use the new field type. That way the data in the index will pass through the analyzer, and "jamón" should be stored as "jamon", and the same will happen with your search terms.
I can't say exactly how you make it work with your freetext search, because it depends on the actual implementation, but if you are using a SummaryField for your freetext, you just need to add the "UnaccentedName" field, to your SummaryField.
I hope it answers the question.
Best regards,
Steffen
I understand this works for single fields but what about summary fields?
Hi Steffen:
I need that the search engine of my web page does not take into account the blank spaces.
Following your steps with the DynamicwebCaseInsensitiveWhiteSpaceAnalyzer doesn´t work, im using the 9.9.6 version too.
First, i created a custom field type:
Then i have created a custom field in the index:
Finally, i have modified the query to add the new field.
i have rebuilt the repository again but doesn´t work
Am i doing something wrong? Is a dw 9.9.6 bug?
Thanks,
Jose
Hi Jose,
The Whitespace analyzer does not remove spaces. In fact, there's no analyzer (that I know of) that would do that, because that would also create a long string ("PlacagasCataLCI631WH60cm"), which would not only be meaningless, but would also force you to use the ContainsExtended operator which is bad for performance (and is not even a native Lucene operator).
I would reccomend you solve this having a new field that concatenates the specific set of strings into a search friendly value, based on what the user's search expectation would be (in this case, I would say "LCI321"). Depending on how your data is and your usage of PIM, that can either be done with Concatenation of fields OR an IndexBuilderExtender.
Hope this makes sense.
Nuno Aguiar
Hi Nuno,
Understood. A lot of thanks.
Regards,
Jose
You are welcome
You must be logged in to post in the forum