Bug: Source Linker handling multi-part surnames while attaching source to a new person

Mark Dixon

I have repeatedly encountered a bug in FamilySearch source linker page. I am working a lot with Dutch people, who have multi-part surnames like the one illustrated in the attached screen shot.

In this case, when I clicked the + button for Willem van de Geijn, only part of his surname shows in the Add to Family Tree pane.

Some other times, only the final part of the surname comes across to the Add to Family Tree pane, missing such prefixes like “van de.”

Such omissions don't always happen, but often enough to be an irritant and cause of inaccurate information being put into FamilySearch.

Would you please report this to the engineering team? I haven’t added Willem on this source linker page in case you would like to see if it occurs in your environment.

I am using Chrome Version 150.0.7871.49 on macOS Tahoe 26.5.2.

Thanks,

Mark Dixon

sc woz

I will send this up the line to an expert in this area. Thanks for reporting it.

Mark Dixon

I have repeatedly encountered a bug in FamilySearch source linker page.  I am working a lot with Dutch people, who have multi-party surnames like the one illustrated in the attached screen shot. In this case, when I clicked the + button for Willem van de Geijn, only part of his surname shows in the Add to Family Tree pane. Some other times, only the final part of the surname comes across to the Add to Family Tree pane, missing such prefixes like “van de.” Such omissions don't always happen, but often enough to be an irritant and cause of inaccurate information being put into FamilySearch. Would you please report this to the engineering team?  I haven’t added Willem on this source linker page in case you would like to see if it occurs in your environment.   I am using Chrome Version 150.0.7871.49 on macOS Tahoe 26.5.2. Thanks, Mark Dixon

Gordon Collett

This doesn't look like a record or collection problem.

Where does he report a programming error in the function of the Source Linker?

Lars van Ravenzwaaij

@Mark Dixon This is not a bug, but a concept of a lot of Dutch databases, which FS cannot handle. FS only knows a first name and a surname. Dutch databases often use first name, surname prefix and surname. Surname prefixes are van, van de, de and so on.

In this case the Rotterdam archives uses this 3 field system also:

Other Dutch databases uses the 2 field system, just like FS does. And there can also be a patronymic name part. This too is often a separate database field in Dutch databases.

So FS often uses the surname prefix as surname or it leaves the surname prefix out or it leaves the patronymic part out. This is what you're seeing.

BTW: the Dutch (and also German) surname prefix is always (!) written with small letters, they are not capitalized. This is different from Flemish where they are indeed capitalzed. I always have to correct this error often made by american users.

And, the surname prefix ist part of the surname, not of the first name. This too is a common error made by american users. The patronymic name is part of the first name (only if there is also a surname, if not it is the surname). Both in case when a 2 field system is used.

Mark Dixon

Thank you for the explanation.

It would seem to me that FS could at least guess which parts of the name go in each of the two fields, rather than just dropping data.

Mark Dixon

Thank you.

Here is another example:

Lars van Ravenzwaaij

@Mark Dixon The city of Utrecht is using the same db software as the city of Rotterdam. 😉

I encounter this on a daily basis not only on FS but also with a variety of Dutch and German medical and other software applications. Even the programmers in the Netherlands and in Germany are not consistent in how to handle surname prefixes. There are even more methods of doing this: e. g. [Lars] [Ravenzwaaij, van] or [Lars van] [Ravenzwaaij].

With the father FS leaves the surname prefix out. Bottom line therefore must be, it's nearly impossible for FS to solve this. I have learned to live with this and enhance the entry manually.

BTW: In your example you can see a common problem with the place name algorithm as well. Utrecht is not only a city, but also a province. So Utrecht, Netherlands needs to be changed (manually) to Utrecht, Utrecht, Netherlands. The same applies for Groningen, Groningen, Netherlands. Groningen also is a city and a province. Both Utrecht and Groningen are the capital cities for the respective provinces.

BTW2: You are my 11th cousin twice removed. 😂😂

Lars van Ravenzwaaij

system error

FlyFisher53

@Mark Dixon Mark, I am looking into which department would be right place to report this. I will follow up with this post when I get an answer.

maryellenstevensbarnes1

@FlyFisher53 you may need to fill out a Records Issue Form so the problem can be properly routed thru FS