ERROR - Automatic alteration of data causes placenames to be destroyed beyond reason
The digital record shows:
Event Place Halifax St Ann in the Grove, Halifax, Yorkshire, England, United Kingdom
Event Place (Original) Southowram, Yorkshire, Yorkshire (West Riding), England
Because the original data is still presented, we can tell that the place has been altered and we can make the correction 'on-the-fly' as we attach: except we can't...
because the automatic place name mangler has altered the original, it now has a new starting point to perform another comparison, so when we try to attach it, it gets changed again, the auto-mangler has spotted an even better place name...
so the original place of Southowram now becomes St Ann in the Grove's Church.
Repeated automatic alteration of data is not just wrong: It's farcical.
"Send three and fourpence, We're going to a dance"
I've developed techniques to overcome all this mangling because I'm using a computer so I can use an open text editor window to store place name data, and a progammable trackball and special key combinations to make the edits quickly. How does a tablet user manage ?
Answers
-
@Ashlee C. please
At least the word "original" has been restored. For some time that was missing.
The ones I've been reporting the last few days have gone through multiple iterations of places - as many as 7 distinct places.
0 -
@Re Searching Do you have a link for the record you are looking at?
0 -
@Ashlee C. I'll dig out another unattached one, they're transient, as soon as you've used the linker the data is changed, so there's nothing left to see.
Got one:
0 -
@Re Searching They don't disappear. I've reported dozens, and they don't go away.
0 -
@Áine Ní Donnghaile Sorry, to clarify: 'disappeared' When the linker is used, the place data that was present in the source is summarised, so the original data, in this case "Southowram", is no longer visible. When the record is selected for attachment, the place name in the right hand panel is automatically changed and the resulting place is the wrong one, and no alternatives are presented.
If this is attached 'as is' then the place data from the source record does not appear in the events list in the person record.
Hence disappeared.
Having thought this through, it strikes me that there should be a permanent option to select the original data from the source record. If this is made available, and is easy to select, then contributors could repair the bad place name data as they work. I versus AI
0 -
@Re Searching, regarding "disappearing" — I can't figure out where you're looking to get this impression, because "Southowram" is (currently) just as visible in an attached index entry as an unattached one, and in the former, it's also there in the Sources list of the profile. Is it perhaps presented differently on a phone?
1 -
@Julia Szent-Györgyi I'm sorry that I've caused so much confusion over this. The point I was trying to get across was that the original event place name is not visible during the attachment process, so it cannot be used by the person performing the attachment to copy into the place that will be put into the residence of the event. To compound this, the place gets changed again during attachment, and because there are no alternative places available in the drop down list, the user is stuck with accepting the wrong place or retyping it from memory (or a copy stored elsewhere). In the simplest terms: the place of Southwram that was shown before has now disappeared.
0 -
@Re Searching, no worries: I for one find it fascinating how we all use the same words to speak entirely different languages, sometimes. :-)
I'm too lazy to check right now: has this concatenation of mis-processing been pointed out in the Source Linker group? (The way I see it, it's all part of the same misguided attempt at making Source Linker the decision-maker instead of the user, and could be solved most simply by showing the user everything, instead of the computer-curated partial view that we currently get.)
1 -
@Re Searching I will send this in to be investigated. Thank you for your patience while we work towards a resolution.
1
