You REALLY need to fix the standardized placename dropdown automatically inserting wrong places!
When you start typing into a placename field a dropdown list of standardized placenames appears, but it often completely changes with each character you type. Try typing St Josephs one character at a time, paying attention to the way the list changes as you type each character - s, t, space, j, o s, e, p, h
If at any point you happen to click somewhere outside the placename edit box then the standardized placename at the top of the currently inserted list (in this case the Uganda one) is automatically inserted.
I had assumed that it was only me making this mistake until I took another look at this record Walter Baranowski, "Illinois, Archdiocese of Chicago, Cemetery Records, 1864-1989" • FamilySearch . I must have attached this record to Walter Baranowski GKDT-76H a few weeks ago when the event date was incorrectly set to 26 May 0082 because it appears in his source list with the date at the far left showing 82. But the event place was correct. Here's what the record shows today, with all edit histories expanded.
The record has clearly been edited twice since I added it, and in one of those edits the event place was changed from the correct "River Grove, Cook, Illinois, United States" to a ridiculous Zimbabwe location.
The person who made these edits was obviously making well-intentioned corrections, changing the dates from 1st century to 20th century (with an intermediate mistake of changing it to the 19th century).
My guess is that they also started to edit the event place by typing in the cemetery name, realized that they didn't need to do that and, like I do, clicked outside the edit box assuming that would simply cancel the edit.
Answers
-
But it didn't.
0 -
I find that for indexes that use the new index editor, I cannot trust anything that the index detail page says about changes to the index entry. I edit the spouse's name, it puts a drop-down arrow next to the event date, and shows the (corrected) spouse's name as the only entry in that field.
(I'm grateful that at least it's the corrected name that shows; the opposite would be beyond infuriating.)
However, I think you're confusing/conflating two totally different processes when you believe that picking a standard for a Family Tree conclusion does anything whatsoever to the index entry. It doesn't. They're different species. You can connect the one to the other, but changes/choices in the Tree have absolutely no effect on the index. The only thing that affects the index is index editing. (Well, that, and the various bugs and automated processes that have been corrupting the indexed records database for years now.)
(You can access index editing from a profile's Sources list or panel, which no doubt serves to thoroughly confuse many people further.)
2 -
Apologies for being behind the times, but in trying to follow this, I got confused in the data.
Firstly, here's the Index entry, expanded to show the variants (or whatever they are) on the dates and places
Can anyone yet explain the different values for Event Date, Birth year (though this trio clearly follows on from the trio of different event dates) and the different Event Places?
But there is also this screen (which I got to from "View Original Document" on the index record and from Edit on the Index Record):
Simply put - what is this? And how does it link to the Index values?
Is this what the indexer created? Seems unlikely to me because it seems to have more than what's on the image. So is it what the indexer created plus the meta-data?
So should this act as the input to create the index? But then this has a 4-digit year so where do the 1882 and 0082 on the index come from? And how come the Place went from somewhere actually in the Standard Places (River Grove, Leyden ... etc) to somewhere not even on the same continent?
Is this all a work in progress that won't make sense for the next decade?
As I say - apologies for being behind the times, but confused I am.
0 -
@Adrian Bruce1 I encountered a similar confusing issue last week. I had an 1830 census hint for a 3rd GGF. The county was spelled "Clake" instead of "Clarke" on the extract.
When I endeavored to edit, it was spelled correctly on the Edit page.
No evidence of an edit of the county placename.
2 -
@Adrian Bruce1, your second screenshot is the new index editor, and yes, it seems to have been released rather prematurely. It keeps coming up with new-and-better ways to mess up. It has made it impossible to tell what was originally indexed, what corrections people have made (or attempted to make), and what corruption was introduced by a bot or automated process. And, as Áine shows, sometimes its edit-everything capabilities don't actually seem to apply to the index detail page, because the error there is not reflected in the index panel within the editor.
2 -
Thanks to @Áine Ní Donnghaile and @Julia Szent-Györgyi
Hmm. So it is the index editor. I think what threw me off was the fact that I first accessed it via "View Original Document" on the index record rather than the Edit link there. Well, that and the Place value not matching up to the Index record due to it having the "Leyden Township" bit in it.
So add that to Áine's "Clake" error that appears from ??? and I find it difficult to get any plausible understanding of the flow of information involved here to apparently (or do I mean allegedly?) produce the Index Record.
Sigh...
1 -
And, as you can see in Edward's source list, "Clake" is still there. Profile MSL1-YGV:
1 -
@Julia Szent-Györgyi " However, I think you're confusing/conflating two totally different processes".
I obviously didn't put my thoughts clearly, so let me rephrase as briefly as possible.
The snapshot with St Josephs Zimbabwe is simply an example of the underlying problem, which is unrelated to the index editor itself.
The underlying problem is that entering/changing an event place anywhere on the site should require positive selection of the entry from the drop down list. By positive selection I mean clicking on one of the entries, perhaps after scrolling through the list, which is what you usually do, and which works as expected under most circumstances. However, while you're typing a placename an exact copy of what you've typed is the first entry on the list, and it's highlighted (see the st joseph example in the first post). If you've typed the placename exactly as you want it entered, which of course you should if you're copying a field from an original document, then you should click that first entry in the list - this works too, so it's not the problem. The problem is that if instead you click outside the edit box expecting that what you've just typed will be entered (it's the selected item on the list after all) what actually happens is that the second, unhighlighted, entry in the list is entered as the placename. That's the problem I was trying to point out.
0 -
@Adrian Bruce1 "Can anyone yet explain the different values for Event Date, Birth year (though this trio clearly follows on from the trio of different event dates) and the different Event Places?"
I assume that the item at the top of the list (the one that shows if you don't have the edit list expanded) is the most recent edit and the bottom item on the list was the original one. So Event Date was originally entered as 26 May 0015, then changed to 26 May 1815 in a later edit, and finally corrected to 26 May 1915.
I thought that only authorized administrators could make changes to indexes ?
0 -
@kob3203 commented:
I thought that only authorized administrators could make changes to indexes ?
If you look at the top of https://www.familysearch.org/ark:/61903/1:1:Q2HN-4WG7 the edit button is "live" (unlike loads of the indexes I use in British practice). My understanding is that when it is live, anyone can use it in the same way that anyone can update an individual's profile.
If you use that Edit link or the View Original Document link, you end up with this screen which allows access to updating the individual items:
Notice at the bottom right is "Show Change History". If you follow that link, there is just one entry for Place History, viz:
That has a single date of 31 July 2023, which matches the date under Latest Changes on the previous screen. If the Change History for this index is correct (if) then there's been no amendment to the Place after its creation.
So, I know that the arrow says "Expand Edit History" but, according to the Change History, no-one has manually editted that index's place. My only possible conclusion is that these entries behind the arrow have something to do with the automatic placename standardisation, rather than manual updates.
The idea that they give the manual update details is perfectly logical and was, indeed, what I thought at first. But if the edit screen's Change History is correct, then there are no manual update details here so the entries behind the arrow mean something else, and automatic standardisation is the only thing I can think of.
Just to be perfectly clear - assigning an event in "Illinois, Archdiocese of Chicago, Cemetery Records, 1864-1989" to a placename in Zimbabwe is seriously wrong. I just don't think it happened in a manual edit.
2 -
As far as I can tell, the new editor's change log ("Change History") is not operational. What it says has no relation to reality.
I apologize that this is going to sound like I'm starting at Adam and Eve to tell the story of Noah. So. A few years ago, FS decided to change how place and date searches work: instead of the old-fashioned text-string matching that we're all familiar with, place and date fields would instead now be associated with entries in the appropriate database, and searching would be a simple database query. In order to enable that, all of those text strings in the indexed records database needed to be linked up to "standardized" places and dates. Even leaving aside the problem that sometimes (often!), the meaning of a text string is not obvious, and no such association can be made without a whole lot of extra research, the method by which FS decided to create these associations was ... a very bad choice: they simply ran a bot, with no sanity checks or data validation. It corrupted the entire indexed records database, and despite years of clean-up, it is still essentially non-functional for date and place searching.
Mostly independently of, but partially concurrently with, the whole autostandardization mess, we have index correction. This was introduced several years ago with a limited but fairly simple process, where some fields of some collections can be changed by users. The changes do not actually replace anything: the new value is added to the database, but the old value is still there and also searchable. Unfortunately, the process employs a truncated version of the place-standardization process: the transcription of placename fields cannot be corrected, even if that field is correctable, because the process requires the selection of a label from the places database. When the database is incomplete, or when the text string's interpretation is ambiguous, the simple correction to the text string cannot be made.
As I said, this index-correction process is limited: users cannot edit every indexed field with it, and they cannot delete or add fields or entries. Therefore, about a year or two ago (my memory for dates is mostly nonexistent), a new, much more powerful -- but therefore complicated -- process was introduced. It uses the "Images" section's slow-as-molasses image viewer and woefully error-ridden cataloging data, but it allows users to not just change existing index entries and fields, but to add or delete them.
Unfortunately, the new editor was rolled out basically unbaked. (They wanted to use it for the 1950 U.S. Census, I guess.) Some things have been fixed in the past year, but it continues to come up with new and better ways to mess things up. In particular, it seems to be completely unable to speak the same language as the index detail page, or to keep track of changes.
One thing that the new editor appears to get right, though, is placenames: it does not require the selection of a standardized location when you add or change a placename field. But what this means is that somewhere in the background, there has to be some sort of process that associates a value from the places database with the entered text string, and the fact that we can't even see it, never mind change its choices, is Not A Good Thing. And it, like all of FS's attempts at automated anything, appears to be Doing It Wrong.
2 -
@Adrian Bruce1 I see what you mean. Now I'm totally confused ! 🤣
As a test I've just edited the "Date: 26 May 1982" to simply add a highlight - the 'Interment Date 5-26-82' on the image now has a blue highlight, and my change shows up in the change history - apparently I created a field 'Field' and updated a field 'Birth'.
0 -
Thank you hugely @Julia Szent-Györgyi for that. I am considerably better informed now. (Whether I am any wiser, to use the old tongue-in-cheek caveat, I'm not sure.)
Unfortunately, a few of the things you mention seem to be recurring themes for FS:
- they simply ran a bot, with no sanity checks or data validation
- despite years of clean-up, it is still essentially non-functional - I keep using the "Help fix placenames" but they keep coming. At one time, not long after the introduction of that or a predecessor, we appeared to finish off UK place issues - now they are there again. Rhetorical question: Are we making a difference?
- somewhere in the background, there has to be some sort of process that associates a value from the places database with the entered text string, and the fact that we can't even see it, never mind change its choices - yes - lack of transparency again. I might find it easier to explain to people or suggest place corrections if (say) the background placename automation came up with the top choice for the same string in the online Search Places facility
- like all of FS's attempts at automated anything, appears to be Doing It Wrong.
2
