W3C home > Mailing lists > Public > www-international@w3.org > October to December 2016

[ldn] Issue: Use of "inbox" marked as i18n

From: r12a via GitHub <sysbot+gh@w3.org>
Date: Fri, 14 Oct 2016 13:17:20 +0000
To: www-international@w3.org
Message-ID: <issues.labeled-182837168-None-sysbot+gh@w3.org>
r12a has just labeled an issue for https://github.com/w3c/ldn as 

== Use of "inbox" ==
The term "inbox" has a very long history (long before there was a web)
 in the context of email.  It carries very strong semantics, 
especially with regard to what mail delivery servers (MDAs in popular 
email terminology) and Mail User Agents (MUAs), including so-called 
split ones (e.g., POP3 and IMAP4 servers and clients) are allowed tor 
expected to do as well as a sometimes-precise relationship to a "mail 
store".  This is especially important when internationalization is 
involved because those possible actions are expected to include 
language-selection or even automatic translation functions.  While its
 primary use in recent years has been to allow plain-text and 
HTML-formatted versions of a message to be sent together, the 
multipart/alternative content type was introduced precisely to allow a
 mail message to be sent with versions in several different languages,
 with the preferred one selected by the user or her agent.

The relationship between an inbox and a mail store further complicates
 this LDN use because it is plausible to expect that, in some 
implementations, the same object storage mechanism might be used for 
email inboxes (or email message collections from while virtual inboxes
 can be constructed or views or on demand) and for LDN messages.    
One can also imagine the use of LDN to get "you have mail" or 
equivalent  notifications to a user, further increasing to confusion 
between an LDN inbox and an email inbox.

The use of that term with rather different semantics and operations in
 the LDN context and the email context  is an invitation for 
considerable implementer confusion and far greater user confusion when
 it leaks into user-level terminology and documentation.   It, and 
this type of reuse of long-established and made-up, and therefore 
application-specific, terms more generally, should be avoided.

"depository", "container", "store" (perhaps with some prefix term) or 
some other term that does not have a specific and well-established 
meaning on the Internet would be more appropriate.

See https://github.com/w3c/ldn/issues/52
Received on Friday, 14 October 2016 13:17:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:41:11 UTC