Is anybody dealing with the current Source Linker problem when standardizing dates?

Paul W

This issue has been reported (originally on 23 August) at https://community.familysearch.org/en/discussion/99802/source-problem#latest. The problem with the standardized places needing to be standardized again once they get to the person pages persists.

The trouble with reporting problems in "Ideas" is that they are rarely acknowledged, so we don't have any idea if this is being investigated. Would a moderator kindly pass this issue to the relevant section, in order to get it resolved asap?

Please don't advise items like this do not belong in this part of "Community", as the heading reads: "Click here to ask questions, report issues..." etc.

Thank you.

NidaFL

Your question will be forwarded to a specialty team for review and resolution.

You may be contacted by that team if they need to gather more information.

Watch for a tiny red dot to appear next to the small envelope in the upper right portion of your screen that will indicate you have received a private message in regard to this subject

Gordon Collett

Please let the rest of know the status of this since this is a widely reported problem.

Paul W

@Gordon Collett

NidaFL sent me a private message, to which I have responded. As requested, I provided her with an example (URL and place name) which had led to my problem, yesterday.

I would be surprised if it is connected to a specific browser, but I advised her I was using Firefox at the time. I was advised the details I provided would be passed to the appropriate team, who were aware of the problem, but unable to replicate.

As you are aware, there appear to be other issues relating to standardization that have appeared quite recently - i.e., not connected to the source linking process. It appears that place names are being marked as needing standardization if they are not in the the correct format for the period to which they relate - e.g., if the "United Kingdom" suffix has not been added to post-1801 events. However, I cannot prove that is causing the red exclamation mark to appear and, of course, this issue is not related to the one being reported here. (Where the place name has been accepted as okay until it hits the person page.)

Perhaps it would help if specific examples from other users were added here, or in direct messages to NidaFL, who appears to be happy to pass them on.

Gordon Collett

If this will be helpful, here is a specific example with too much detail.

This is on a desktop iMac with macOS 11.5.1 using Safari version 14.1.2 (16611.3.10.1.3):

Starting with this search: https://www.familysearch.org/search/record/results?q.givenName=rakel%20gurine&q.birthLikePlace=sveio&q.birthLikePlace.exact=on&q.birthLikeDate.from=1867&q.birthLikeDate.to=1867&q.fatherGivenName=kristen&q.fatherGivenName.exact=on&f.collectionId=4237104&count=20&offset=0&m.defaultFacets=on&m.queryRequireDefault=on&m.facetNestCollectionInCategory=on

which gives:

I get two records for the person's birth. The two different places are just a quirk of how they were recorded and the indexing.

Now I run through the attaching process:

The date and place name show as standardized just fine. I will go ahead and re-standardized the date so it is in the form I want it:

Returning to the person's page:

I will take care of the next source but do it a little differently in a second post.

Gordon Collett

Starting again from the search page:

This time I am going to leave the date alone but choose a different place:

This time the standardization did carry across as it is supposed to.

Here is a search for Rakel Gurine's younger brother that has his two records from the same collection: https://www.familysearch.org/search/record/results?q.givenName=amund%20kristen&q.birthLikePlace=sveio&q.birthLikePlace.exact=on&q.birthLikeDate.from=1872&q.birthLikeDate.to=1872&q.fatherGivenName=kristen&q.fatherGivenName.exact=on&f.collectionId=4237104&count=20&offset=0&m.defaultFacets=on&m.queryRequireDefault=on&m.facetNestCollectionInCategory=on

These should be attached to: Amund Kristen Amundsen G8X4-G4L. I will leave these unattached for the engineers to follow my exact steps and see if they get the same results. I did absolutely nothing between attaching the two records, no restarts, no quitting and re-opening the browser, no clearing of cookies. I did have to take a half hour break between the two. So unless this has something to do with server load at the time, there was nothing that should have influenced why the first example did not work and the second did other than the difference in my attachment process.

I will also not touch the two custom baptism events on Rakel Gurine Amundsen G8X4-N7G in case there is something underlying them the engineers can trace through that might give information as to what is going on.

@NidaFL, please forward this on to the correct people. Thanks.

Gordon Collett

Well, I just finished attaching a group of about fifteen sources and could not find any pattern to the place problem.

• About half the time overall the place name ended up standardized, the other half it did not.
• If I did not change the place name, about one quarter of the time it would be standardized and the other three quarters not.
• If I did change the place name, about three quarters of the time it would be standardized and the other quarter it would not be.

If there is something determining the outcome, it sure isn't obvious.

dontiknowyou

I too see a lot of fluctuation in this behavior and no clear pattern. I think someone is actively working on the code.

I have seen the problem in several different browsers, and in several versions of one browser. All on the web side. I have not seen this problem with the source linker in the mobile app.