[UA-EAI] What problem does this solve: transcribing foreign-script email addreses

[Asmus Freytag (c)]

On 8/17/2021 4:16 PM, John Levine wrote:
> On Tue, 17 Aug 2021, Asmus Freytag (c) wrote:
>>> I still have no idea what problem people are trying to solve here. ...
>
>> It's very simple. The sender's name is one of the elements you use to 
>> manage your mail collection.
>>
>> You use it to scan the list of headers to find what you want, if. You 
>> use it to search (and you usually don't have to cut&paste to be able 
>> to do a search). You type the from name (or part of it) when you want 
>> to send a message that's not a reply. And so on.
>
> So far so good.
>
>> All of these tasks become more difficult if you can neither pronounce 
>> nor type a name. Adding a transcription to the friendly name enables 
>> this without requiring the sender to maintain an account with a 
>> "non-native" user name.
>
> There's a whole lot of assumptions here about what might or might not 
> be in the From header comment already and how helpful a transcription 
> might be, or for that matter, how it's supposed to work in the other 
> direction, e.g., the address is in Greek and I speak Korean.
>
> Like I said, we consistently find that our intuitions about what is 
> good user interface are wrong.

I would start with the case where there is no friendly name, or the 
friendly name does not contain any characters in the user's script. That 
way, if there's a friendly name that manually circumvents the issue, you 
don't try to override it.

And, where a friendly name shows a real user's name in a foreign script, 
you have a number of choices.

If the part before the @ is in ASCII, you could echo that in comment, 
otherwise you could transcribe the foreign script part into Latin 
(whatever).

Ideally user interfaces would be as flexible as social media posts where 
you can select whether to see a translation independently for every 
single post, but you get to work with what you have.

But just because e-mail predates these services, isn't apriori a reason 
not to find a way to augment e-mail in similar ways to how social media 
have been augmented.

A./


>
> Regards,
> John Levine, john.levine at standcore.com
> Standcore LLC
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ua-eai/attachments/20210817/9aaa6152/attachment.html>