Last modified: 2013-03-06 17:14:39 UTC
In the new search menu, the letter "å" is interpreted as its base letter "a". This means that when I start typing a word including the letter "å", it is interpreted as though I had written an "a". Example: I want to look for the Swedish town "Åmål", and I start typing "Åm": The first hits I get are words beggining with "Am", such as "America", "Amsterdam", "American revolutionary war". In Norwegian, Swedish and Danish, "å" is considered to be a separate letter, and not another version of the letter "a", it therefore doesn't make sense to treat it as an "a". This problem does not occur for the Dano-Norwegian letters "ø" and "æ" (they are not confused with any other letters), but it does occur for the Swedish "ö" and "ä" (which are interpreted as "o" and "a", respectively).
Don't know whether it is the search interface or the backend, but this applies to Finnish as well and probably to more languages too. This kind of normalization can't be done unconditionally for every language. Marking as a bug instead of enhancement.
This happens in the backend, regardless of which skin is being used. Moving from Vector skin to Search.
Let us take the example word "Åmål": In Monobook, the search results would show both "Amal" and "Åmål", in Vector "Amal" and "Åmål" are both rendered as "Amal" in the drop-down menu.
(In reply to comment #3) > Let us take the example word "Åmål": In Monobook, the search results would show > both "Amal" and "Åmål", in Vector "Amal" and "Åmål" are both rendered as "Amal" > in the drop-down menu. That's a duplicate of bug 24237
Entering Åmål on sv.wikipedia.org I get results starting both with A and Å. I don't consider this a bug but rather a feature, e.g. when you don't have access to a localized keyboard - normalization. In case I didn't understand incorrectly, I propose to close this as WONTFIX.
(In reply to comment #5) > I don't consider this a bug but rather a feature, e.g. when you don't have > access to a localized keyboard - normalization. I don't think that's the purpose of this normalization, and it would be the wrong fix for that problem (the correct fix being the UniversalLanguageSelector).
