FamilySearch introducing errors

[Steve Hayes]

FamilySearch has been plugging standardised place-names, which is not
a bad idea but has now gone too far -- their software triest to
automatically substitute "standard" place names for non-standard ones,
but in the process it often inserts a place name that is entirely
wrong and misleading, wand will ruin the usefulness of their
collaborative family tree.

See

<https://hayesgreene.blogspot.com/2021/10/familysearch-introducing-errors.html>

or

https://t.co/a8XuL86WsA

[Ian Goddard]

Post by Steve Hayes
FamilySearch has been plugging standardised place-names, which is not
a bad idea but has now gone too far -- their software triest to
automatically substitute "standard" place names for non-standard ones,
but in the process it often inserts a place name that is entirely
wrong and misleading, wand will ruin the usefulness of their
collaborative family tree.

FamilySearch have a long history of mangling places. From the errors
I've seen it appears that batches of records from multiple places must
have been entered without changing the place name on the data entry
screen and any QA procedure has failed to trap it.

This casual attitude seems to have affected search. It's a while since
I used FS until recently when I found that the 1st search page has been
dumbed down. I entered a name, place (Holmfirth) and year (1911),
looking for the 1911 census date. There would likely have been one
record that fully matched. The search returns pages of hits for the
name and county. None of the initial hits have either year or place.
About 2/3 or the way down we finally get the subject: it's his death
registration in 1911 but the place name in Huddersfield, the
registration district. The combination of name, year and place, the one
and only fully matching hit, appears one up from the bottom of the first
page.

I was using search engines that worked properly - including the ability
to include NOT terms - in the mid '80s. Nowadays any search engine I've
used (including Google, Bing and Amazon) seems to be based on quantity
of output, not specificity. (FreeBMD and its relatives are an
honourable exception.) It might be reasonable to allow a margin of
place and date but at least make the effort to order the results in
closeness of match to the search terms.

[Steve Hayes]

On Fri, 29 Oct 2021 09:48:08 +0100, Ian Goddard

Post by Ian Goddard

Post by Steve Hayes
FamilySearch has been plugging standardised place-names, which is not
a bad idea but has now gone too far -- their software triest to
automatically substitute "standard" place names for non-standard ones,
but in the process it often inserts a place name that is entirely
wrong and misleading, wand will ruin the usefulness of their
collaborative family tree.

FamilySearch have a long history of mangling places. From the errors
I've seen it appears that batches of records from multiple places must
have been entered without changing the place name on the data entry
screen and any QA procedure has failed to trap it.

Yes, indeed. There have been transcrtiption errors, where someone has
transcribed a parish register and gone on to transcribing another
parish, without changing the name of the parish on the entry form. It
is the kind of error where it might be qute easy to do a batch
correction.

But what I am talking about here is not a human error of a fallible
transcriber, but a deliberately introduced software error, which would
be much more difficult to trace and correct.

Here is an example:

Mount Fenning
England and Wales Census, 1841
Name: Mount Fenning
Event Type: Census
Event Date: 1841
Event Place: Chichester St Martin, Chichester, Sussex, England, United
Kingdom
Event Place (Original): St Martin, Essex, England
County: Essex
Parish: St Martin
Residence Note: Copping'S Buildings
Sex: Female
Age: 9
Age (Original): 9
Birth Year (Estimated): 1832
Birthplace: Essex
Page Number: 12
Registration Number: HO107
Piece/Folio: 344/24
Affiliate Record Type: Institution
Affiliate Image Identifier:
GBC/1841/0344/0453&parentid=GBC/1841/0001424136
Household Role Sex Age Birthplace
Mount Fenning Female 9 Essex
Mary Fenning Female 45 Essex
Mary Fenning Female 25 Essex
John Fenning Male 20 Essex
Sarah Fenning Female 16 Essex
Thomas Fenning Male 13 Essex

When I copy this event to my own family tree, it does not copy the
original event place, but the spurious Chichester one.

I hope the people at FamilySearch will soon correct this software bug,
but until they do, people who use FamiloySearch should be warned that
they need to treat every place name as suspect.

Ancestry.com have long done this kind of thing, but it is new on
FamilySearch.

[Graeme Wall]

Post by Steve Hayes
On Fri, 29 Oct 2021 09:48:08 +0100, Ian Goddard

Post by Ian Goddard

Post by Steve Hayes
FamilySearch has been plugging standardised place-names, which is not
a bad idea but has now gone too far -- their software triest to
automatically substitute "standard" place names for non-standard ones,
but in the process it often inserts a place name that is entirely
wrong and misleading, wand will ruin the usefulness of their
collaborative family tree.

FamilySearch have a long history of mangling places. From the errors
I've seen it appears that batches of records from multiple places must
have been entered without changing the place name on the data entry
screen and any QA procedure has failed to trap it.

Yes, indeed. There have been transcrtiption errors, where someone has
transcribed a parish register and gone on to transcribing another
parish, without changing the name of the parish on the entry form. It
is the kind of error where it might be qute easy to do a batch
correction.
But what I am talking about here is not a human error of a fallible
transcriber, but a deliberately introduced software error, which would
be much more difficult to trace and correct.
Mount Fenning
England and Wales Census, 1841
Name: Mount Fenning
Event Type: Census
Event Date: 1841
Event Place: Chichester St Martin, Chichester, Sussex, England, United
Kingdom
Event Place (Original): St Martin, Essex, England
County: Essex
Parish: St Martin
Residence Note: Copping'S Buildings
Sex: Female
Age: 9
Age (Original): 9
Birth Year (Estimated): 1832
Birthplace: Essex
Page Number: 12
Registration Number: HO107
Piece/Folio: 344/24
Affiliate Record Type: Institution
GBC/1841/0344/0453&parentid=GBC/1841/0001424136
Household Role Sex Age Birthplace
Mount Fenning Female 9 Essex
Mary Fenning Female 45 Essex
Mary Fenning Female 25 Essex
John Fenning Male 20 Essex
Sarah Fenning Female 16 Essex
Thomas Fenning Male 13 Essex
When I copy this event to my own family tree, it does not copy the
original event place, but the spurious Chichester one.
I hope the people at FamilySearch will soon correct this software bug,
but until they do, people who use FamiloySearch should be warned that
they need to treat every place name as suspect.
Ancestry.com have long done this kind of thing, but it is new on
FamilySearch.

One I came across was my gg-grandfather's christening at St Thomas
Charterhouse, Clerkenwell (now demolished). The Family Search index
shows it as St Thomas, Virgin Isles!

[Steve Hayes]

On Sat, 30 Oct 2021 08:38:07 +0100, Graeme Wall

Post by Graeme Wall

Post by Steve Hayes
When I copy this event to my own family tree, it does not copy the
original event place, but the spurious Chichester one.
I hope the people at FamilySearch will soon correct this software bug,
but until they do, people who use FamiloySearch should be warned that
they need to treat every place name as suspect.
Ancestry.com have long done this kind of thing, but it is new on
FamilySearch.

One I came across was my gg-grandfather's christening at St Thomas
Charterhouse, Clerkenwell (now demolished). The Family Search index
shows it as St Thomas, Virgin Isles!

Another good example of the kind of thing I am talking about.

[knuttle]

Post by Steve Hayes
On Fri, 29 Oct 2021 09:48:08 +0100, Ian Goddard

Post by Ian Goddard

Post by Steve Hayes
FamilySearch has been plugging standardised place-names, which is not
a bad idea but has now gone too far -- their software triest to
automatically substitute "standard" place names for non-standard ones,
but in the process it often inserts a place name that is entirely
wrong and misleading, wand will ruin the usefulness of their
collaborative family tree.

FamilySearch have a long history of mangling places. From the errors
I've seen it appears that batches of records from multiple places must
have been entered without changing the place name on the data entry
screen and any QA procedure has failed to trap it.

Yes, indeed. There have been transcrtiption errors, where someone has
transcribed a parish register and gone on to transcribing another
parish, without changing the name of the parish on the entry form. It
is the kind of error where it might be qute easy to do a batch
correction.
But what I am talking about here is not a human error of a fallible
transcriber, but a deliberately introduced software error, which would
be much more difficult to trace and correct.
Mount Fenning
England and Wales Census, 1841
Name: Mount Fenning
Event Type: Census
Event Date: 1841
Event Place: Chichester St Martin, Chichester, Sussex, England, United
Kingdom
Event Place (Original): St Martin, Essex, England
County: Essex
Parish: St Martin
Residence Note: Copping'S Buildings
Sex: Female
Age: 9
Age (Original): 9
Birth Year (Estimated): 1832
Birthplace: Essex
Page Number: 12
Registration Number: HO107
Piece/Folio: 344/24
Affiliate Record Type: Institution
GBC/1841/0344/0453&parentid=GBC/1841/0001424136
Household Role Sex Age Birthplace
Mount Fenning Female 9 Essex
Mary Fenning Female 45 Essex
Mary Fenning Female 25 Essex
John Fenning Male 20 Essex
Sarah Fenning Female 16 Essex
Thomas Fenning Male 13 Essex
When I copy this event to my own family tree, it does not copy the
original event place, but the spurious Chichester one.
I hope the people at FamilySearch will soon correct this software bug,
but until they do, people who use FamiloySearch should be warned that
they need to treat every place name as suspect.
Ancestry.com have long done this kind of thing, but it is new on
FamilySearch.

This has been a problem for years, and is why I do not merge data into
my database. For several generation, my family come from one county in
Indiana. As the county changed from wild forest to a fairly large city
things changed. Many times a family is listed in one small community in
one census and another in the next, but they are still on the farm they
were on in the previous census.

Many years ago I standardized my location, to the smallest stable
location. In this county it is townships. I then note the community
in the description part of the location fact. An example: the family
lived in Milan township, and in the Chaberlain community. Since in the
stable community is Milan township, I put that in the location field.
and in the description, Chamberlain. (Today very few people know
Chamberlain existed.)

In my opinion, the location is so that I can go to any current map and
locate where the family lived. In this way when in the area I can easily
travel to that location. If I use the name of community that no longer
exist, I may never find the family farm. The historical location is put
in the description, or a note if the information on the historical
location is to large for the description.

[Ian Goddard]

Post by Steve Hayes
On Fri, 29 Oct 2021 09:48:08 +0100, Ian Goddard

Post by Ian Goddard

Post by Steve Hayes
FamilySearch has been plugging standardised place-names, which is not
a bad idea but has now gone too far -- their software triest to
automatically substitute "standard" place names for non-standard ones,
but in the process it often inserts a place name that is entirely
wrong and misleading, wand will ruin the usefulness of their
collaborative family tree.

FamilySearch have a long history of mangling places. From the errors
I've seen it appears that batches of records from multiple places must
have been entered without changing the place name on the data entry
screen and any QA procedure has failed to trap it.

Yes, indeed. There have been transcrtiption errors, where someone has
transcribed a parish register and gone on to transcribing another
parish, without changing the name of the parish on the entry form. It
is the kind of error where it might be qute easy to do a batch
correction.
But what I am talking about here is not a human error of a fallible
transcriber, but a deliberately introduced software error, which would
be much more difficult to trace and correct.
Mount Fenning
England and Wales Census, 1841
Name: Mount Fenning
Event Type: Census
Event Date: 1841
Event Place: Chichester St Martin, Chichester, Sussex, England, United
Kingdom
Event Place (Original): St Martin, Essex, England
County: Essex
Parish: St Martin
Residence Note: Copping'S Buildings
Sex: Female
Age: 9
Age (Original): 9
Birth Year (Estimated): 1832
Birthplace: Essex
Page Number: 12
Registration Number: HO107
Piece/Folio: 344/24
Affiliate Record Type: Institution
GBC/1841/0344/0453&parentid=GBC/1841/0001424136
Household Role Sex Age Birthplace
Mount Fenning Female 9 Essex
Mary Fenning Female 45 Essex
Mary Fenning Female 25 Essex
John Fenning Male 20 Essex
Sarah Fenning Female 16 Essex
Thomas Fenning Male 13 Essex
When I copy this event to my own family tree, it does not copy the
original event place, but the spurious Chichester one.
I hope the people at FamilySearch will soon correct this software bug,
but until they do, people who use FamiloySearch should be warned that
they need to treat every place name as suspect.
Ancestry.com have long done this kind of thing, but it is new on
FamilySearch.

You have two Event places shown with the correct one as "original".

My guess is that there were several batches of "St Martin" entries
against the location of the first batch, Chichester, and nobody bothered
to change the location at the start of the next batch. The data itself
would contain the actual location and that's been entered as "original".
It really needs a script to go through the database looking for "Event
place (original)" fields, change these to the main event and change the
label on the first "Event place" field to "Incorrect event place entered
due to incompetence".

Really, if data contains an event place and it conflicts with what the
operator has entered it should raise an alert and hold the data in
suspense until it's been checked and a correction entered if necessary
by someone has a grasp of where things are. Not to do so is an obvious
newbie error.

[Steve Hayes]

On Sat, 30 Oct 2021 16:23:15 +0100, "J. P. Gilliver (John)"

Do tell them! I did (well, my point was more that, as it obscured the
"thumb", I initially didn't realise the column _was_ scrollable); the
more who tell them, the more chance they'll do something about it. (I
suppose, use the feedback tab to tell them about the feedback tab! I
can't remember how I got to the place where I could - I think it was
that way.)

I haven't seen the Feedback tab for a while. If I had I would
certainly have told them about that.

[Ian Goddard]

It seems to have gone from bad to worse. Of the browsers I regularly
use (I won't use Chrome or its derivatives) only Firefox now works.

This seems to be a recent trend in web-sites: using developers who are,
presumably young, inexperienced and not aware that the web was designed
to provide a universal platform so that users with a wide variety of
platforms could access the same material. Too clever by half so not
clever enough.

A message to all web developers: if your site won't work on the user's
chosen browser it's not the user's fault; it's yours.

[Daniel65]

It seems to have gone from bad to worse.  Of the browsers I regularly
use (I won't use Chrome or its derivatives) only Firefox now works.
This seems to be a recent trend in web-sites: using developers who are,
presumably young, inexperienced and not aware that the web was designed
to provide a universal platform so that users with a wide variety of
platforms could access the same material.  Too clever by half so not
clever enough.
A message to all web developers: if your site won't work on the user's
chosen browser it's not the user's fault; it's yours.

YEAP!! Yeap! Yeap.

[Steve Hayes]

On Mon, 14 Feb 2022 23:23:54 +0000, Ian Goddard

Post by Ian Goddard
It seems to have gone from bad to worse. Of the browsers I regularly
use (I won't use Chrome or its derivatives) only Firefox now works.
This seems to be a recent trend in web-sites: using developers who are,
presumably young, inexperienced and not aware that the web was designed
to provide a universal platform so that users with a wide variety of
platforms could access the same material. Too clever by half so not
clever enough.
A message to all web developers: if your site won't work on the user's
chosen browser it's not the user's fault; it's yours.

Hear! Hear!

[cecilia]

On Mon, 14 Feb 2022 23:23:54 +0000, Ian Goddard

Post by Ian Goddard
It seems to have gone from bad to worse. Of the browsers I regularly
use (I won't use Chrome or its derivatives) only Firefox now works.
This seems to be a recent trend in web-sites: using developers who are,
presumably young, inexperienced and not aware that the web was designed
to provide a universal platform so that users with a wide variety of
platforms could access the same material.

[...]

Many (25?) years ago I was somewhat startled to hear that an optical
disc that I had found listed in the British Library catalogue had
been written for Network Nagigator and the BL no longer had Network
Navigator, so reading it might not work.

[The disc I wanted to look at was written for Internet Explorer, but
the browser turned out to be irrelevant as it was missing!]

[Nigel Reed]

On Mon, 14 Feb 2022 23:23:54 +0000

Post by Ian Goddard
It seems to have gone from bad to worse. Of the browsers I regularly
use (I won't use Chrome or its derivatives) only Firefox now works.
This seems to be a recent trend in web-sites: using developers who
are, presumably young, inexperienced and not aware that the web was
designed to provide a universal platform so that users with a wide
variety of platforms could access the same material. Too clever by
half so not clever enough.
A message to all web developers: if your site won't work on the
user's chosen browser it's not the user's fault; it's yours.

I use Opera and it works fine.

[Ian Goddard]

Post by Steve Hayes
On Mon, 14 Feb 2022 23:23:54 +0000

Post by Ian Goddard
It seems to have gone from bad to worse. Of the browsers I regularly
use (I won't use Chrome or its derivatives) only Firefox now works.
This seems to be a recent trend in web-sites: using developers who
are, presumably young, inexperienced and not aware that the web was
designed to provide a universal platform so that users with a wide
variety of platforms could access the same material. Too clever by
half so not clever enough.
A message to all web developers: if your site won't work on the
user's chosen browser it's not the user's fault; it's yours.

I use Opera and it works fine.

That was my point. Opera is one of those Chrome derivatives.

[Nigel Reed]

On Wed, 23 Feb 2022 15:45:13 +0000

Post by Ian Goddard

Post by Nigel Reed
I use Opera and it works fine.

That was my point. Opera is one of those Chrome derivatives.

I just tried Firefox and it works fine. I could navigate trees and
enter information, do indexing and a few other things. What doesn't
work exactly?