That’s fair, and I’m glad to hear it, but I think what I’m struggling to understand is the difference between languages:official=* and languages:preferred=* and why both are needed. The proposal says languages:official=* “distinguishes endonyms from exonyms”. To me, this is unfortunate because, although Hoa Thịnh Đốn is technically an exonym for Washington, D.C., this is because of the language’s geographic origin, not due to official government policy. Normally one speaks of exonyms as being used by foreigners, but Hoa Thịnh Đốn is only used by Americans, and particularly by the local residents, never by people abroad.
I guess the two keys are intended to triangulate around a list of names in the “native” language. Is the only difference between the two keys that a language can be “preferred” by common usage while “official” must be codified in law?
There’s probably a limit to how well we can sanitize names to be monolingual. Your example is tricky because French and English have influenced each other so much over the centuries. Not far from me, the street names are all of the form “Rue Bordeaux” and “Rue Le Mans”. These would be valid French names, except they’re actually English names that a real estate developer chose to give a more sophisticated air to the neighborhood.
This happens so frequently in English that most text-to-speech engines would have no problem faking French pronunciations that sound passable to an English speaker. In fact, if my phone tells me to turn onto Rue Paris, I’ll have an easier time understanding roo parriss than roo parree or /ʁy pa.ʁi/. Roo parriss would cause a Parisian to faint, but the more etymologically correct pronunciations would cause me to miss my turn. As you note, perfect isn’t the enemy of the good.
On the other hand, in some parts of the world, there’s a trend to prepend the indigenous name onto the English name. Up in the hills above me, there’s a nature preserve that goes by “Máyyan 'Ooyákma – Coyote Ridge Open Space Preserve”. That’s the full English name, out of respect for the Muwekma Ohlone Tribe. I have very little confidence that a TTS engine would faithfully pronounce this name in an arrival instruction. Once I find out how it’s supposed to be pronounced, I’ll add a name:pronunciation=* tag to hopefully steer these English voices in the right direction.
Language identification would be more important in a place like Hong Kong. There, the streets are all tagged bilingually. If you feed “夏慤道 Harcourt Road” into a TTS engine, it might insert an awkward pause or even produce an error because it isn’t prepared to vocalize text that’s so different from English. It’s also annoying to isolate the problematic text, because the delimiter is a mere space.
The status quo depends on the application to present name:en=* to an English speaker, but in another part of the world, the same behavior would force the user to look for a name that’s only in fine print or not even visible at all. One approach would be to only present name:en=* if the same value appears somewhere in name=*. (“Nerville Avenue” is a substring of “Avenue Nerville Avenue”.) Otherwise, try to present name=*. If name=* doesn’t contain anything that the TTS engine can vocalize, then fall back to name:en=* as a last resort.
As you note, this isn’t perfect. For one thing, what if the user’s language is Japanese, so the default TTS voice has less of a problem parsing CJK text like 夏慤道? The phone could end up saying something like natsu-michi, but I don’t know if the user would really prefer that over a Japanese-accented rendition of hākoto-rodo.