Second-try searches that are exact matches (after transformation) for titles or redirects do not elevate those suggestions to the top of the suggestion list.
For example, with the second-try wrong-keyboard suggestions enabled, searching for //ьщысщц// on Russian Wikipedia searches for "Moscow", which brings up plenty of suggestions. However, it does not include the suggestion for "Москва" that you would get if you searched for //Moscow// in the Latin script. ("Москва" has a redirect from "Moscow", which is an exact match to the transformed Latin.)
| Search for //ьщысщц:// {F70840366} | Search for //moscow:// {F70840368} |
In this case, the article for "Москва" is not in the top 10 suggestions for //ьщысщц//.
In general, this is not just an issue for Russian wrong-keyboard suggestions, similar examples exist for Hebrew wrong-keyboard and Georgian transliteration. The issue seems to be that the logic that elevates exact matches in the list of suggestions doesn't have access to the transformed query text.
Possible approaches to the problem include:
* Move the logic to where the transformed data is, or vice versa, so that transformed exact matches are properly elevated.
* This could also fix the //Mõscow// example mentioned below.
* Decrease the penalty given to redirects (this will help for wrong keyboard, but not for transliteration, where titles are being matched)
* Ignore this issue, since it happens in other, unrelated cases.
* For example, searching for //Mosco// on Russian Wikipedia gives the same suggestions as //ьщысщц// because //Mosco// is not an exact match for the "Moscow" redirect. Similarly, searching for //Mõscow// on ruwiki does the same thing, again because the unnormalized query is not an exact match.
* If there are non-transformed matches, do we want a transformed exact match to jump ahead of them? For example, //пщ// is the wrong-keyboard equivalent of //go,// which is the title of the Russian article on Go/Golang. Should that jump ahead of the actual results that start with "пщ"?