Hebrew and Russian Wikipedias each have a nifty gadget that will generate extra autocomplete results that can catch “wrong-keyboard” input. Wrong-keyboard input happens when, for example, you have the US English keyboard enabled, but you type as if you expect Russian Cyrillic. So you could get ,jutvcrfz hfgcjlbz on the screen when you meant to type богемская рапсодия.
The way the DWIM (“do what I mean”) gadgets work is that if autocomplete gets fewer than 10 results, they do the transformation, and tack on any additional results, up to 10 total.
On Hebrew Wikipedia, you can see it action by typing tufk in the upper corner search box—you get one Latin result (“Turkish Airline”) and then a bunch of Hebrew results, starting with “אוכל”. (On Hebrew Wikipedia, DWIM is enabled by default. On Russian Wikipedia it must be turned on in preferences. This makes it easier to illustrate some things with Hebrew, some with Russian.)
As is, it works well in the top corner search, but not on the search on the main Special:Search page. It’s easier to play around with it on Russian Wikipedia because it is off by default and you can load any version of it you want in the Javascript console. The code for the Russian version is here. (The code for the Hebrew version, which has the same main process but loads a little differently, is here.)
I think DWIM might have once worked on the main Special:Search input box—where it would still be equally useful to have, as well as being more consistent across different parts of the UI. In the Russian gadget code, if you add the selector [name=search] to the list in the variable $searchBoxes, it sort of works, but not actually correctly.
For a Russian example—assuming you've enabled the gadget (“Показывать дополнительные подсказки в «малом» поле поиска при использовании неверной раскладки” in your preferences) or loaded the code in the console—ehfk gives one Latin suggestion ("EHF") and then a bunch of Cyrillic ones, starting with “Урал”.
What goes wrong in the main search box is that it does the wrong-keyboard updates, but the old results are there, too! It’s easiest to see with a query that gets 10+ results (and thus no wrong-keyboard results), like John, where you can see both sets of results—the gadget-generated black text results are on top, more closely spaced together, while the OOUI blue text results, more widely spaced, are poking out below the other list.
This screenshot shows the modified set of selectors in the Javascript console, along with the gadget results overlaid on the OOUI results.I tried digging into the OOUI code to figure out how to insert/replace results in the right element, but I just got lost. I’m not up on Javascript mixins or OOUI, or even the mechanism of the DWIM code, so I have no idea where to go next.
Is there is some obvious way to make the code do the right thing for the Special:Search main search input box?
A working hack might be good enough right now. A proper way to access and modify this functionality via OOUI would be great. Perhaps the solution requires more fundamental work on OOUI to make that possible.