Change Details

=== Description In T296671 and T296225 we're changing the search results logic so that instead of showing the redirect page in the search results list, we show the actual page that the redirect points to. One potential downside of this is that people could get confused as to why the top search result doesn't match their search term. For example if someone types "Corn" they will now see "Maize": {F34974364 width=400} === Proposed solution Sometimes we should indicate that the search result is a redirect, for example: {F34974386 width=400} However sometimes we should //not// indicate that the search result is a redirect because it would be redundant, for example: {F34974384 width=400} @TJones provided an initial recommendation for how we might resolve this: >>! In T296225#7702139, @TJones wrote: >> Any ideas how to avoid showing this extra info in cases where it is redundant/unnecessary? > > It depends on how fancy you want to get... > * The simplest approach would be to not show the redirect if the redirect is a substring of the title (lowercasing everything before comparing) > * More normalization than just lowercasing could help, too, such as removing spaces and/or punctuation (then //**QAnon**,// (the title) and //Q Anon// and //Q-Anon// (the redirects) would all be equivalent > * IIRC, Javascript doesn't support Unicode regex shorthand like `\p{L}` or `\p{P}`, so you'd have to be careful with non-Latin scripts > * You also would have to make sure neither the redirect nor the title normalize to the empty string (e.g., //;// is a redirect to //Semicolon//). > * Not 100% sure about the other way around, but if the redirect is longer than the title but the title is a substring of the redirect it would probably be okay to not show the redirect. > * Cases like //Einstein/Einstien/Enstein// are doable, but may be too expensive or complex? (My heuristic would be, if the first letter is the same and the other difference is only a swap or one-character addition/deletion/swap, then hide the redirect. The fastest way (O(n) instead of regular edit distance, which is O(n²)) I can think of to do this is a minimum length of 4 or 5, and then remove matching prefix and suffix and if the remainders are both length < 2, **or** both length==2 and one the reverse of the other. Like I said, maybe too complex—and it may behave oddly with CJK titles. > > So, my recommendation? Remove spaces and dashes from the title and the redirect and lowercase both. If neither is the empty string and one is a substring of the other, then don't show the redirect. It won't be perfect, but it will help a lot.

=== Description In T296671 and T296225 we're changing the search results logic so that instead of showing the redirect page in the search results list, we show the actual page that the redirect points to. One potential downside of this is that people could get confused as to why the top search result doesn't match their search term. For example if someone types "Corn" they will now see "Maize": {F34974364 width=400} === Proposed solution Sometimes we should indicate that the search result is a redirect, for example: {F34974386 width=400} However sometimes we should //not// indicate that the search result is a redirect because it would be redundant, for example: {F34974384 width=400} @TJones provided an initial recommendation for how we might decide when to indicate that the search result is a redirect and when not to: >>! In T296225#7702139, @TJones wrote: >> Any ideas how to avoid showing this extra info in cases where it is redundant/unnecessary? > > It depends on how fancy you want to get... > * The simplest approach would be to not show the redirect if the redirect is a substring of the title (lowercasing everything before comparing) > * More normalization than just lowercasing could help, too, such as removing spaces and/or punctuation (then //**QAnon**,// (the title) and //Q Anon// and //Q-Anon// (the redirects) would all be equivalent > * IIRC, Javascript doesn't support Unicode regex shorthand like `\p{L}` or `\p{P}`, so you'd have to be careful with non-Latin scripts > * You also would have to make sure neither the redirect nor the title normalize to the empty string (e.g., //;// is a redirect to //Semicolon//). > * Not 100% sure about the other way around, but if the redirect is longer than the title but the title is a substring of the redirect it would probably be okay to not show the redirect. > * Cases like //Einstein/Einstien/Enstein// are doable, but may be too expensive or complex? (My heuristic would be, if the first letter is the same and the other difference is only a swap or one-character addition/deletion/swap, then hide the redirect. The fastest way (O(n) instead of regular edit distance, which is O(n²)) I can think of to do this is a minimum length of 4 or 5, and then remove matching prefix and suffix and if the remainders are both length < 2, **or** both length==2 and one the reverse of the other. Like I said, maybe too complex—and it may behave oddly with CJK titles. > > So, my recommendation? Remove spaces and dashes from the title and the redirect and lowercase both. If neither is the empty string and one is a substring of the other, then don't show the redirect. It won't be perfect, but it will help a lot.

=== Description In T296671 and T296225 we're changing the search results logic so that instead of showing the redirect page in the search results list, we show the actual page that the redirect points to. One potential downside of this is that people could get confused as to why the top search result doesn't match their search term. For example if someone types "Corn" they will now see "Maize": {F34974364 width=400} === Proposed solution Sometimes we should indicate that the search result is a redirect, for example: {F34974386 width=400} However sometimes we should //not// indicate that the search result is a redirect because it would be redundant, for example: {F34974384 width=400} @TJones provided an initial recommendation for how we might resolve this:decide when to indicate that the search result is a redirect and when not to: >>! In T296225#7702139, @TJones wrote: >> Any ideas how to avoid showing this extra info in cases where it is redundant/unnecessary? > > It depends on how fancy you want to get... > * The simplest approach would be to not show the redirect if the redirect is a substring of the title (lowercasing everything before comparing) > * More normalization than just lowercasing could help, too, such as removing spaces and/or punctuation (then //**QAnon**,// (the title) and //Q Anon// and //Q-Anon// (the redirects) would all be equivalent > * IIRC, Javascript doesn't support Unicode regex shorthand like `\p{L}` or `\p{P}`, so you'd have to be careful with non-Latin scripts > * You also would have to make sure neither the redirect nor the title normalize to the empty string (e.g., //;// is a redirect to //Semicolon//). > * Not 100% sure about the other way around, but if the redirect is longer than the title but the title is a substring of the redirect it would probably be okay to not show the redirect. > * Cases like //Einstein/Einstien/Enstein// are doable, but may be too expensive or complex? (My heuristic would be, if the first letter is the same and the other difference is only a swap or one-character addition/deletion/swap, then hide the redirect. The fastest way (O(n) instead of regular edit distance, which is O(n²)) I can think of to do this is a minimum length of 4 or 5, and then remove matching prefix and suffix and if the remainders are both length < 2, **or** both length==2 and one the reverse of the other. Like I said, maybe too complex—and it may behave oddly with CJK titles. > > So, my recommendation? Remove spaces and dashes from the title and the redirect and lowercase both. If neither is the empty string and one is a substring of the other, then don't show the redirect. It won't be perfect, but it will help a lot.