Standardized location on document match not working.
1) Perform a match of a record against a person record.
In the comparison you can add the date and location of an event, say a birth:
- 25/10/1910
- Johannesburg South Africa
Selecting the location gives an automatic list of locations - select a standardized date:
- Johannesburg Transvaall South Africa municipality 1886-1994
Save the match
2) Going back to the tree or person view shows an "!" indicating no standardized location for the birth.
Edit the person record to select the standardized location again.
Please fix step 1.
Answers
-
I just repeated what you have described without any problems.
Sometimes these issues are cookie or browser related. If you have more than one browser installed, try another. Worked fine for me using Firefox. Deleting cookies rarely solves my problems, but that might also be worth a try.
If either suggestion does not work, perhaps you might wish to describe the procedure you are / were undertaking in fuller detail, preferably with screenshots.
1 -
I'm seeing the same problem, but it's intermittent, or may be dependent on the location being added. Here's an example: https://www.familysearch.org/search/linker?pal=%2Fark%3A%2F61903%2F1%3A1%3AMWMT-M4P&id=KCVL-3Q7&hinting=%2Ftree%2Fperson%2Fdetails%2FKCVL-3Q7&icid=fs-hinting
Add the residence, then attach the record. The residence as entered actually registers as standardized, but there's two identically named locations: a "town" and a "villiage" -- I don't know if that factors into the bug. It doesn't matter if you just save it immediately or if you press space and select either of the standardized choices, when you view the Details page, the residence is shown as non-standardized and you have to edit it to correct it.
Here's the same situation where the same workflow can be followed and the bug does not occur: https://www.familysearch.org/search/linker?pal=%2Fark%3A%2F61903%2F1%3A1%3AMDHF-MBN&id=K8ZC-M8D&hinting=%2Ftree%2Fperson%2Fdetails%2FK8ZC-M8D&icid=fs-hinting
0 -
And apparently it's a known bug. There's a couple other posts about it already.
0 -
After writing my comments in October I have since encountered this behaviour on a few occasions.
0