GNOME Bugzilla – Bug 212305
EAddress conduit mishandles multiple first names
Last modified: 2013-09-13 12:31:35 UTC
Description of Problem: I have families of people entered in my Palm as First name: First1 and first2 Last name: Last When I import them from the pilot (using the EAddress conduit over IrDA with setting "Merge from pilot"), they show up as First: First1 Middle: and Last: first2 Last Steps to reproduce the problem: 1. Create new test entry on pilot 2. Sync to evolution How often does this happen? This seems to be 100% reproable for me (out of a whopping sample size of 2) Additional Information:
I've seen this as well. However, I believe the ONLY way to fix this is not to try to convert multiple first names into a first name and middle name; the only way this will work is based on the following. Both directions demonstrated. Palm Side Evo Side --------- -------- Given Names => First Name (nothing) => Middle Name (empty) Last Name => Last Name Palm Side Evo Side --------- -------- Given Names <= First Name + Middle Name Last Name <= Last Name This, of course, demonstrates a deficiency in Evolution. Namely, nearly every application I've seen has discounted the idea of using "Middle Names" as a component of a name. Besides the fact that it is not always possible to determine exactly what the middle name should be (due to compound first names, multiple middle names, etc.), cultural variations make it impossible to assume that most of the people in the world even have names that can be talked about in such terms. The fix above should work, but has the necessary deficiency that if you have a name "First Middle Last" on Evolution, sync it to the palm, where it becomes "First Middle, Last", change it on the palm to become "First Foo, Last", and then sync it back to Evolution, it will become "First Foo, Last" (i.e. an empty middle name). This I believe is a necessary evil. I strongly suggest that Evolution change its name structure to eliminate middle names. As an aside (and a case study), consider the genealogical format GEDCOM (www.gedcom.com), which long ago decided that it was hopeless to assume that you can do anything with a name other than, perhaps, denote a substring of it that should be considered a "surname" (used for searching and sorting). (By the way, this also applies to name prefixes such as "Sir" or "General" and suffixes such as "II" and "Jr."). I consider this to be a serious usability problem with the address conduit; unless this is fixed I consider the conduit to be almost completely unusable. Please consider fixing this for 1.0! Thanks.
I believe this is actually a parsing error on the part of the addressbook as discussed with Chris L.
Naw. Address conduit should use ECard directly to set the name so as to not make ECard parse it.
But this same problem affects full names typed in the contact editor, so I feel it should be fixed at the source.
That's a separate bug. You're right that blah & blah should work for names typed in the contact editor, but this won't fix the problem if the persons first name is, for instance, Mary Jane. I'll file a separate bug for that.
I've corrected things for the pilot with clahey.
So I will actually mark this resolved.
*** bug 269342 has been marked as a duplicate of this bug. ***