How to fix mistakes made by Family Search
I cannot arrange for temple work for three members of my family because Family Search insists that the child was born before the father. The facts indicate otherwise. Father, Thomas Wykes (MZ9P-W1J) was born in 1822; mother, Mary Higgin (MCJG-BPJ) was born in 1824. Son, James Wykes (GVJF-LGT) was born in 1851. The problem is there is no way for me to fix this.
Answers
-
Go to James's profile and hover your pointer over his christening.
A tooltip will come up, showing that the displayed date of "20 July 1851" has been associated with a standardized date of "July 0020". In other words, the computer has been told that he was christened over a millennium before his father.
To fix it, edit the christening: click the pencil and add any character (such as a space) at the end of the date field. This will cause a drop-down to appear with the correct date. Select that correct date and click Save at the bottom corner of the edit pop-up, and your problem should be solved.
4 -
Correction made. Note that PID listed above for James Wykes, GVJF-LGT, is incorrect. Correct PID is GVJF-LG7.
0 -
In case people are wondering how this type of error creeps in, you need to keep in mind that the typed in display date and the linked standardized version are two different items.
It has always been difficult to incorrectly standardize dates, and is now even harder when using the new person pages, but in the old pages, if you type in just the day and month, save, then go back and enter the year and forget to update the standard you will create this kind of error. I would wonder if this can also happen if someone has a slow internet connection and are able to type and save so fast that the standardization routine doesn't get a chance to finish recognizing the date.
July 0020 is what you get if you enter 20 July because the routine does not recognize dates that are just day and month. If there is only one number, it always takes it as the year:
When editing dates and places, it is always important to fully proof-read both the displayed value and the linked standard, which do not need to be the same, to be sure both are correct and entered as intended.
4 -
Yes, this can be cause a lot of confusion. Only yesterday I noticed a Details page where the individual's birth year was shown as 1861 at the top of the page, but as 1857 under his Birth in the vitals section. On closer examination (as Gordon illustrates) I found 1857 shown as the (display) Date of Birth, but 1861 as the Standardized Date.
But I am still unable to replicate this behaviour, however I input my dates! Any ideas on how I can input / overwrite the year as "1861" yet manage to retain / produce an "1857" standardized date (or how the earlier input had produced this effect)?
0 -
Update
After several attempts, I was able to produce the below, but can't get it to work using four figures! That is, I can't get an 1892 or 1897 display date standardized as 1895.
0 -
@Paul W, I can get a different standardized date than the display (including a four-digit year) by first making a change that "legitimately" results in a mismatch between display and background. The example I came up with was to write the month in a different language.
Procedure: first, I edited the month from "May" to "Majus" (skipping the diacritic to make absolutely certain it wasn't in the database quite like this) and clicked outside the box. This resulted in the now-mismatched display and background fields both showing, as desired. Then I edited the year to be off by a decade and clicked the reddish text to keep my typing, resulting in what you see in the screenshot.
In the new process, it is not possible to change the month back to English, however: if I try, the drop-down quite aggressively replaces the standard, no matter what I do or where I click.
1 -
Thanks for that example, Julia. However, I think I might have to rely on the "doyen" of such matters (yes, you know who I mean) to reveal his trick behind getting the standardized date 1895 appear as display date 1897 - or any other 4-digit examples. (Though still can't get why I can get 189 to "work", but not 1892, 1897, etc.)
0 -
@Paul W , I hope whoever you are waiting for for a real answer gets around to providing one.
In the meantime, the first thing I am curious about is the date your incorrectly standardized date was put in. A couple of years ago it was fairly easy to introduce that kind of error when editing a date. If a new date was entered and one clicked outside the text box instead of the new date in the drop down menu, the standard would not update so the standard would still be the old date.
Now, however, it is impossible to type in a date that is identical to the standard and not use the standard unless something glitches while entering the date as I suggested might have happened with the example that started this discussion. It's the situation we ran into with London, England. While I hope they are fixing the place name entry so one always has the choice to link but not use the standard even if the entered text and the standard are identical, I can't think of any time that being forced to use the standard for a date would be a problem. If you type in 5 May 1870 there is really is no reason I can see to not accept the 5 May 1870 standard and use it rather than just linking to the standard.
It is still possible to introduce the error being discussed here if not using identical text and one is not proof-reading carefully. For example:
1) Enter the date:
2) Keep the typed in text and link the standard:
3) Correct the date:
4) Keep the typed in text:
Since there is already a standard, that standard is preserved which is a great feature for being able to tailor the free-form entered text to be exactly what you want it to be, as long as the standard is correct. They have made it so easy to maintain this standard that sometimes the only way to update the standard is to type in the standard, choose it to force the update, then go back and retype what you really want the date to be, such as using a different format as I did here, adding the day of the week, adding a double-date form, or including a named Sunday, holy day, or holiday.
The difference with the current programming for entering a date that is identical to the standard, is that you don't get that first line in the drop down menu that does not have the calendar icon anymore:
That is when your only choice is to use that standard exactly the way it is. But again, there really is not any reason not to and it should minimize standardization errors when entering boring dates.
1 -
This is, if course, just a bit more long winded explanation of Julia’s example.
0 -
Thank you for your response, Gordon. I was about to log out, but thought I'd provide a brief response now.
Yes, that's what one has to do - click outside the box! Here's the evidence - you should just about be able to read the display date in the shaded part of the screenshot:
Very confusing when users do this, of course, as the date at the top of the Details page also shows as 1892 , contrary to the 1895 display / "standardized" one.
Sorry for the rushed response.
0 -
So this still happens on the old pages. My illustration was from the new pages where clicking outside the box like that does not work the same anymore.
0 -
Yes, I thought that is what you were suggesting. It suddenly came back to me that this was the way this behaviour could be produced (i.e. standardized & displayed dates being different due to clicking outside the box), so I immediately tested this after reading your comments and found this is still the case.
0
