I think the "language" issue is a bit of a red herring.
When traveling, things like google searches, weather forecasts and many other services are re-routed to the local service who then impose their local language (and metric) preferences on me by default. All without IDNs.
Indeed, but I would think that multiple IDN names for a web site would imply multiple languages. If they all just redirect to the English language site, that's technically easy, but it also seems like a cruel joke.
Same answer, except that if one name isn't a subdomain of the other, the login and option cookie problems are a lot harder.
Airline sites that direct to local access (with domain in local ccTLD) would have that issue and appear to be able to handle it. Other services do as well - not always without some bumps.
Having done this a few times, my experience is that they generally all redirect to the same site, and there's a button at the top to pick a language, which is usually remembered in a cookie, maybe initialized with a guess from the original name but usually not. Again, one could do that with multiple IDN names, but why bother?
The main difference is that crossing script boundaries makes it impossible for users not native (or competent) in both scripts to relate your aliased names. (Within a script my suspicion is that you wouldn't normally translate domain names without leaving at least a recognizable part, like a language-neutral brand name or abbreviation).
Seems reasonable.
definitely tell you that without loose address matching that matches user expectations, whatever they are, your customers will hate you and decide that your system is unusable.
Totally.
My point was intended to be helpful in pointing out where you might find data to extend loose matching.
I've been wondering if it's worth spinning up an IRTF group to try and collect advice on loose matching and (sort of its inverse) son-of-PRECIS assigning user names that allow characters that users expect, but that won't collide with variants or if non-speakers misenter them as homographs or near homographs. Regards, John Levine, john.levine@standcore.com Standcore LLC