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

[Martin J. Dürst]

On 2021-08-18 08:16, John Levine via UA-EAI wrote:
> On Tue, 17 Aug 2021, Asmus Freytag (c) wrote:

>> 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.

And many of us also quite often forget about details when they are 
intuitive enough. The important point here is "From header comment".

In email "addresses" as they are perceived and used by end users, there 
are two internationalization extension points.

The first is the LHS of the actual email address, the part to the left 
of the '@'. This is the main focus of this mailing list, and is the part 
that still needs quite some work in many parts of the email infrastructure.

The second part is what is called "comment" or "display name" in the 
RFCs (see https://datatracker.ietf.org/doc/html/rfc5322#section-3.4). It 
is essentially free text, and can contain a wide range of characters 
already for a very long time. The first RFC explaining how to handle 
non-ASCII dates to 1992 (https://datatracker.ietf.org/doc/html/rfc1342), 
and this was definitely widely available in the late 90s. Some mail user 
agents actually often don't show the real mail address, but only the 
display name.

The first extension point has to be fixed when you register an email 
address (or when you get one from your company,...). The second 
extension point can be changed much more freely, and can essentially be 
different in every mail somebody sends out. Because that's not usually 
done, current user interfaces don't make it very easy, but it's not very 
difficult either. Please search for "change email display name" to see 
how to do it in your mail user agent.

So it's easy to imagine various ways users and user agents can deal with 
the issue at hand:
- Use a display name that contains both non-Latin and Latin letters
   (e.g. "青山太郎 (Taro Aoyama)"). All users can do this already now.
- Make it much easier to change the display name (e.g. have a drop-down
   choice for non-Latin (maybe several) and Latin display names in the
   email composer interface.
- Automatically select from a list of display names to match the
   language or script used in the mail itself, or based on the
   addressee(s) of the mail.

Handling this on the sender side has the advantage that the sender can 
select her preferred transliteration/transcription or maybe another 
preferred form (as an example, many Chinese use Latin given names 
different from their Chinese given names). Because it involves user 
agents, different user agents (incl. webmail systems) can compete in 
this area and learn from each other.

Regards,   Martin.