Peter Johnson

hi @vesameskanen there has been a lot of discussion about alternate names and internationalization over the last year or so, the main points of contention remain: 1) data translations do...

Yes I think this is a good idea. The `name.$LANG` fields predated the language detection middleware and that's the only reason it hasn't been done. There was also an issue...

I have been looking at the elasticsearch docs for `multi_match` queries again recently for another feature and I found them to be very capable and configurable.

Also worth mentioning that this thread is pretty old and some of the concerns from 2+ years ago are either solved or less relevant.

I'm going to put my name on this to track it but I probably won't have time to do a PR in the near future. @mihneadb if you'd like to...

I don't think that is correct, `multi_match` does support `fuzziness` and also `phrase` but not both at the same time. > Also, accepts analyzer, boost, operator, minimum_should_match, fuzziness, lenient, prefix_length,...

As for where to start, I would suggest having a look at the queries which are being generated, you can use the `?debug=true` flag on the [compare app](https://pelias.github.io/compare/#/v1/search%3Fdebug=true&lang=ru&text=%D0%A2%D1%80%D0%B0%D1%84%D0%B0%D0%BB%D1%8C%D0%B3%D0%B0%D1%80%D1%81%D0%BA%D0%B0%D1%8F%20%D0%BF%D0%BB%D0%BE%D1%89%D0%B0%D0%B4%D1%8C), if you...

There's actually two ways that alternative names are specified in Pelias, there are the `name.*` fields which we currently don't query on, these fields contain the proper name of the...

Can we please start with a list of like 10 failing test cases? From there we can investigate further and map out a plan.

We would want to maintain the existing query logic for now (and not change too much in one PR) So if a query type is `phrase` it should stay as...