Glitch in the Source Linker
Glitch in the Source Linker. The Source Linker is a wonderful tool. It allows the easy addition of new people into Family Tree (FT). But there is a glitch that sometimes occurs during this process of adding new people. This glitch may occur in different ways, but one way that can be easily replicated is when the source linker is working on marriage records for the Netherlands. These marriage records might add up to six new people into FT, the bride, the groom, and the parents of both the bride and the groom. When a new person is added into FT, and that new person is listed in the source with three parts to their name, given name, patronymic name, and surname, the Source Linker sometimes has a glitch where it messes up the names from the source, when it prepares the new name to be added to FT. It sometimes moves the patronymic name into part of the surname field. This patronymic name should be listed in the given name field. This can be seen when working on Elisabeth Pieters de Haan Female 20 February 1836 - Deceased LVFN-4H6.
If you look up Elisabeth in FT, you will see that she is listed with no parents. However, she has a source, where her parents are listed. She is listed with three sources, and one of those sources is for her marriage in 1858. This source shows the message: This sources has not been attached to all people found in the record. This is one of the amazing tools of the Source Linker. However, for Elisabeth, when you click on the link to UNFINISHED ATTACHMENTS, you encounter the glitch mentioned above. The next screen shows the Add for each of the parents of Elisabeth. But when you click on the Add link, to add her father, the Source Linker shows her father, added with incorrect names, that are different from the names found in the source, see below:
The same glitch can be seen when adding in the record for the mother of Elisabeth. In the past, we have implemented a work around, before completing the Add to Family Tree, where we copy the patronymic name from the Last Name field, and paste it into the First Name field, and then delete the errant name from the Last Name field, and then complete the Add to Family Tree. We have done this for hundreds of other cases. However, it would be far better to fix the glitch in the Source Linker. For anyone who looks at this example, please do not force the work around. We might need the case set up as it is so the engineers can replicate the problem. We will also add this write up to the Memories for Elisabeth.
Answers
-
I suspect this has nothing to do with the Source Linker and everything to do with how the records were indexed. Probably the only way to fix this would be to re-index the entire collect and change what as entered as first names and what was entered as last names.
I would not call what you have been doing in the past a work around but rather proper procedure. Very rarely have I ever created a record from the source linker that has not required significant editing afterwards. The indexing process just does not make very good Family Tree profiles.
1 -
Gordon Collett ✭✭✭✭✭
I have not seen many problems with the indexing process as you described above. In my experience, the process has been very good, especially with records indexed from the Netherlands, and especially with the example shown for this original post. If you look at the example from the original post, and look at the detail page for Elisabeth Pieters de Haan Female 20 February 1836 - Deceased LVFN-4H6, and look at the source for her marriage in 1858, you can easily see that her father’s name was indexed as Pieter Hattums de Haan. This Pieter was not found in FT, so the Source Linker shows Add. But when you click on Add, the Source Linker then mangles the name Hattums, and places it into the middle of the last name field, with a resulting last name of de HattumsHaan. This is surely a source linker problem and not an indexing problem. It would be good if this problem were not hidden under some fictitious indexing problem, so it can be escalated to the engineers who could then look at the problem.
0 -
Records are indexed with first and last names. Looking at the resulting records in the current format, you cannot see how this was done. For example, with Pieter: https://www.familysearch.org/ark:/61903/1:1:QL5P-HQKP the record looks like this:
You can't tell what the program is viewing as the first name or the last name.
However, when you search for this same record, If you search with Pieter Hattums as the first name, you do not get any results:
If you move Hattums to the last name field, the record shows right up:
This shows that the record was indexed as first name: Pietter, last names: Hattums de Haan. And that is all the source linker can work with. It cannot move parts of the last name to the first name field and should not.
Now why the source linker rearranges the parts of the last name is another question. It really should not be doing that and the engineers do need to fix that.
0 -
We appreciate you bringing this problem to our attention. The issue has been submitted for investigation. We will get back to you as soon as we have an answer. Thank you so much for your kindness and patience while this is being addressed.
0 -
@jlwestra When I try to attach her parents I get different name options than you posted above. Is this correct now? (link https://www.familysearch.org/search/linker?pal=/ark:/61903/1:1:QL5P-HQKX&id=LVFN-4H6)
0 -
Thank you for checking into this problem. It appears that the logic has been changed since the problem was first reported in April 2023. The problem occurs when the Source Linker finds a new person to be added into FT, and that new person is listed in the source with three parts to their name, given name, middle name, and surname. And according to the notes from Gordon Collett, the Source Linker is likely driven by how that source was indexed. In the Dutch records, the middle name is more than just a middle name, it is a patronymic name that shows the given name of the father of the new named person. This patronymic name should be listed in the given name field. When the source was indexed, the indexer might have incorrectly put the patronymic name into the surname field, or worse yet, mixed into the middle of the surname field. The logic that seems to have been changed since the problem was first reported in April 2023, is that, since the record may not have been indexed correctly, that the Source Linker will just ignore that patronymic name completely and not add it in as a part of the new person's name. You can see this with the mother of Elisabeth in the example above. The source clearly states that the mother of Elisabeth was named: Sieuke Eelkes Buwalda, but the source linker defaults to Sieuke Buwalda, completely ignoring the patronymic name Eelkes that was spelled out in the source. I've encountered hundreds of these situations in the past few months, and I have had to manually add in the patronymic name each time I add any new person into FT who has the three part name. That is better than it was in the past when the patronymic name was incorrectly added to the surname. There I had to add in the patronymic name to the given name, as well as delete it out of the surname. For the mother of Elisabeth in the example above, her name was Sieuke Eelkes Buwalda, and we know that her father was named Eelke Buwalda.
0 -
Thank you for describing the naming intricacies. This is not my area of research. I appreciate the new info. I have escalated the problem. Hopefully we can find a solution.
0 -
@jlwestra Disclaimer- I am a genealogist, not an engineer, so I hope I have understood the reply and relayed their information correctly. I have been told that what shows in the source linker depends on which fields were used in the indexing process for each project. I guess that name fields varied between different projects for different countries and languages. If we change it for one collection it may mess up other collections.
Personally, I would add the person and then go back their details tab and make any adjustments that are needed based on the naming patterns for the area. I would also add the name as an alternative, just so it is documented, but with a notation about the differences.
1
