Ask / Submit
5

names of imported fb contacts don't have particles [not relevant]

asked 2013-12-26 01:32:01 +0200

tiemen gravatar image

updated 2014-01-23 04:31:55 +0200

MattVogt gravatar image

In Dutch and many other languages, surnames can have particles like 'de' or 'van'. These particles are not synced when importing from Facebook, so a name like Peter de Jong would be imported as Peter Jong.

edit retag flag offensive reopen delete

The question has been closed for the following reason "question is not relevant or outdated" by molan
close date 2017-02-09 12:46:30.917973

Comments

I think this question would better gather all the attention it needs, if it was rephrased something more like

Contacts in the People app are treated incorrect, when the persons last name consists of more than one string-of-text, either due to the last name having one or more particles, or the full last name consisting of more than one name (with or without hyphens).

and not be limited to Facebook contacts.

similar question
@darius' "Wrong Names and Surenames on People app."

but also
@jonathanarcher's "Bug: Unable to add contact with name similar to existing one"

phle ( 2014-02-11 13:58:50 +0200 )edit

1 Answer

Sort by » oldest newest most voted
1

answered 2013-12-26 12:00:12 +0200

MattVogt gravatar image

Yes, this is a known limitation. The data received from the facebook-chat IM roster does not provide any breakdown of the name tokens - we just receive a single datum: 'Peter de Jong'. Those three tokens are then allocated according to a rule for the phone's locale, which will most likely see them allocated as 'firstname', 'middlename', 'lastname'. So the surname prefix token will have been applied as a middle name.

We considered adding a list of common tokens that would be processed as prefixes to a surname, such as 'van', 'de', 'van't', 'van de', 'van der' and so forth, but since we wouldn't know the origin of the incoming name, we could only apply rules to the name from the phone's locale. Any case where a token was misallocated to the surname would be considerably more confusing and difficult to locate than one where the prefix was lost from the surname.

Any alternative suggestions appreciated...

edit flag offensive delete publish link more

Comments

(related question?)
I got a Facebook message in "Messaging" from one person (M... F... J..., whom I chat with now and then), but it looked as if it came from another person (M... J..., whom I don't speak to that often). MFJ has two surnames, and M&J is exactly the same as MJ's.
(cont.)

phle ( 2013-12-26 16:17:15 +0200 )edit

(cont.)
What's weird, though, is that "F... J..." is correctly labelled as "Last name" in "People" (and I haven't edited it, it was imported from Facebook as such).

phle ( 2013-12-26 16:19:13 +0200 )edit

In Dutch, French and German, particles are always written in lower case, (at least when part of a full name: 'Peter de Jong', but 'mister De Jong') so maybe it's an idea to check for an initial capital letter? That would indicate it's an extra first name, double last name or middle name.

tiemen ( 2013-12-26 21:13:15 +0200 )edit

@tiemen - that would help raise the probability of getting correct results, but unlikely to actually resolve the basic problem.

MattVogt ( 2013-12-27 00:11:04 +0200 )edit
1

@phle - so you have a facebook-chat contact named, say, 'Mick Fleetwood Jones', and another separate contact named 'Mick Jones'? Then I would suspect that 'Mick Fleetwood Jones' has been parsed as 'Mick Jones' (middle name 'Fleetwood') and subsequently aggregated together with the person 'Mick Jones'. If you look at the Person record for 'Mick Jones' and look at the Links page, you will probably see two Facebook contacts. You can unlink one of them, and then work out which one needs to be changed to 'Fleetwood Jones'.

I have come to the conclusion that all people should be allocated a SHA-1 hash identifier at birth :)

MattVogt ( 2013-12-27 00:16:16 +0200 )edit

Question tools

Follow
1 follower

Stats

Asked: 2013-12-26 01:32:01 +0200

Seen: 177 times

Last updated: Dec 26 '13