Open Bug 259289 Opened 20 years ago Updated 2 years ago

Do not fill first and last name when you automatically add outgoing e-mail addresses to an address book

Categories

(Thunderbird :: Address Book, defect)

defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: gonhidi, Unassigned)

References

Details

(Keywords: intl)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040908 Firefox/0.10 Build Identifier: Mozilla Thunderbird version 0.8 (20040910) When in the options menu the "Automatically add outgoing e-mail addresses to an address book" option is set, new addresses are automatically added to the selected address book. For an address in the form "Word_1 Word_2 [...] Word_last <address>" The following fields are filled: Email: address Display name: Word_1 Word_2 [...] Word_last First name: Word_1 Word_2 [...] Last name: Word_last Unfortunately, not all cultures map the display name to the first and last name structure chosen by Thunderbird. For example, in Spain, the last name is inherited from the mother and the father, so the last name would be usually composed of two words; in some asian countries the way one usually writes first the last name and then the first, so again this auto-fill feature would get it wrong. I suggest that only the "e-mail" and "display name" fields are automatically filled in, since I see no way the mechanism can be generalized to include all cultural variants and possibilites. Reproducible: Always Steps to Reproduce: 1. Send a mail to a previously inexistent mail address such as "A B C <D>". Actual Results: In the generated address book entry, the fist name is "A B" and last name is "C". Expected Results: Not fill in the fist and last name fields of the address book.
The steps to reproduce are better expressed as: 1. Send a mail to a previously inexistent mail address such as "A B C <D@E>". This avoids domain name autocompletion which breaks the example.
(In reply to comment #1) > Actual Results: > In the generated address book entry, the fist name is "A B" and last name is "C". > > Expected Results: > Not fill in the fist and last name fields of the address book. Please make this optional. For a lot of users - maybe even the majority - the "last item is the last name" approach works quite well. Removing this will remove functionality. (I myself struggle with the "Add to address book" functionality for exactly this reason, Netscape did it fine (filling first and last name from the displayed name) an Thunderbird does only fill the Display Name, leaving first and last blank. I would like to be able to toggle the old functionality back on...)
I agree with comment 2. The auto-fill of first and last name should be turned back on. It is the responsibility of localization to take into affect the way names are normally handled. This bug can then be integrated into the localization system.
Depends on: 259227
When users use "A B C <D@E>" format, "A B C" does not always represent the name of D@E. Some users like to add company or department name into the format, for example: 1. COMPANY-First Last <D@E> or 2. First Last (DEPT) <D@E>. If my observation is true, the First & Last seperation will be incorrect. When "Automatically add outgoing e-mail addresses" is enabled, one more problem: the same e-mail address will have many entries in the address book. Refer the scenario below: Guy A has an entry for D@E as "COMPANY-First Last <D@E>"; Guy B has an entry for D@E as "First Last (DEPT) <D@E>"; Guy C has an entry for D@E as "First Last <D@E>"; Guy A sends email to Guy B and "COMPANY-First Last <D@E>". Guy B replies the email to all and "COMPANY-First Last <D@E>" will be automatically collected into Guy B's address book. After some communications, D&E will have multiple entries in those address books. I was annoyed with this probelm for a long time. So that I suggest to add a feature to check the duplication before collecting.
Bug 40046 mentions some challenges regarding automatically splitting names.
(In reply to comment #5) > Bug 40046 mentions some challenges regarding automatically splitting names. While doing it "right" in all cases might indeed be problematic, having this functionality for the "standard" case (Latin1, First Last) at least would be very helpful. Could someone please comment whether the current 1.1a contains this funtionality? Let not the "best" retard the good!
Blocks: 259227
No longer depends on: 259227
QA Contact: address-book
Reporter, does the issue still occur with the latest supported 2.0.0.x / Shredder trunk nightlies? (1.5.0.x is now end-of-life and the latest supported Thunderbird version 2 is 2.0.0.16)
Whiteboard: closeme 2008-08-28
(In reply to comment #7) > Reporter, does the issue still occur with the latest supported 2.0.0.x / > Shredder trunk nightlies? > > (1.5.0.x is now end-of-life and the latest supported Thunderbird version 2 is > 2.0.0.16) It still occurs on a non-localized/English installation of Thunderbird version 2.0.0.16 (20080707) running on Mac OS X 10.4 (Intel) when sending mail to "First Middle Last <user@domain.test>" where the given email address is not yet in Thunderbird's address book.
Keywords: qawanted
Whiteboard: closeme 2008-08-28
Assignee: mscott → nobody
Surprisingly, as explained in Bug 40046 Comment 61, while we pre-fill AB fields for the *unattended* scenario (automatical adding for outgoing msgs, this bug), we do *not* pre-fill AB fields for the *attended* scenariio (manual adding of address to AB from msg header pane, bug 40046). As (temporary) objection to this bug, pls note that automatical pre-filling (albeit error-prone in the current implementation) does help to retrieve contacts using composition's autocomplete for recipients. In fact, as long as we have bug 558931, it is crucial that we pre-fill First and Last name (opposed to this bug), regardless of correctness, because otherwise it will be much harder for autocomplete to find matches. In the long run, we probably want pre-fill to be more intelligent for the non-simple and non-Western cases, and perhaps an option to switch pre-filling of First and Last name fields off (somewhat in line with this bug), at least for the unattended (automatical) scenario of this bug.
OS: Windows 2000 → All
Hardware: x86 → All
Depends on: 1000775
Keywords: qawanted
Keywords: intl
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.