@Bugreporter, the code you linked to is currently only used for as-you-type suggestions, but your mention of page contents sounds like you are looking for matching in fulltext search results, too. Are thinking of one, the other, or both?

There's also going directly to a wiki page if you hit the return key rather than clicking a suggestion (which most people don't realize is another separate process, the Go Feature; I think most people think of that as part of suggestions).

We do have language-specific normalization that we do globally (or nearly globally), but it is usually on a small number of characters (like, a few to a dozen), not something as complex as converting Traditional characters to Simplified. We'll have to look into it carefully in terms of where things need to be done and how expensive they are to do in those particular spots.

@dcausse—Speaking of which, I looked into a few things:

• zhwiki does match traditional and simplified titles in suggestions, and the Go Feature works for both scripts, too.
  • I made sure to pick an article with no T2S or S2T redirects, so I think I tested it properly. (Hitting random I landed on 戈里亚盖 / 戈里亞蓋 / Gauriaguet, which only has one redirect: French "Gauriaguet").
  • I think these are handled by Language Converter, though, so we'd have to figure out how to do it on Commons or other wikis.
    • I think adding tsconvert (see below) to near_match and titlesuggest might do it.. but it may also be too expensive.
    • Could we use Language Converter logic without enabling Language Converter? Futurewise, could we in theory build a profile that does multiple disjoint conversions simultaneously if we wanted to? (For example, Chinese T2S and Serbian C2L.) Hmm.. how would anything like that interact with wikis that already have Language Converter enabled? Sounds complicated... plus Language Converter's T2S and tsconvert agree almost all, but not quite all, of the time.
• For fulltext analysis, tsconvert is a char filter, so tokenization doesn't matter (we are using the ICU tokenizer in most places anyway, so we do often get decent Chinese tokenization).
  • I'm not sure how performant the char filter is, on Chinese or non-Chinese text. Applying it to all of Commons might be slow.
  • There is an extra filter that fixes two errors in the dictionary. I think one error has been fixed, but the other is still there. OTOH, it's only one word..
• Commons does have zh_text, zh_plain, and zh_plain_search in its config so it is doing some Chinese-specific processing. I guess it may only be for descriptions tagged as Chinese?

Add any more ideas, info, or concerns and we can discuss on Wednesday.

We looked into this a bit and doing it properly is a moderate amount of work, so we are putting it in the backlog for the normal prioritization process.