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.
On 29/10/2021 09:07, Steve Hayes wrote:
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.
On Fri, 29 Oct 2021 09:48:08 +0100, Ian Goddard
<ianng@austonley.org.uk> wrote:
On 29/10/2021 09:07, Steve Hayes wrote:
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.
On Fri, 29 Oct 2021 09:48:08 +0100, Ian Goddard
<ianng@austonley.org.uk> wrote:
On 29/10/2021 09:07, Steve Hayes wrote:
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.
On Fri, 29 Oct 2021 09:48:08 +0100, Ian Goddard
<ianng@austonley.org.uk> wrote:
On 29/10/2021 09:07, Steve Hayes wrote:
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.
On 10/30/2021 12:54 AM, Steve Hayes wrote:[]
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 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.
Unfortunately the Feedback tab does absolutely nothing useful in terms
of being able to give feedback despite it's offering "specific"
feedback to the page. All it does is get in the way of the scroll bar.
Ian
On Sat, 30 Oct 2021 at 08:51:32, knuttle <keith_nuttle@sbcglobal.net>
[I'd rather switch to top-down - country, state/province/county, place - because then location lists would come in a sensible order (all the
England places together, ditto all the US ones) rather than listing New Jersey, New York, and New Zealand next to each other - but can't,
because in the software I use (Brother's Keeper) the autocomplete
function for locations (F8) currently is only starts-with rather than contains, so I'd have to scroll through all the England places.]
Actually, that's one slight snag with your "use the modern name" policy
- when there's a major border move, and/or completely new county, what
was the modern name ceases to be so, so global changes are needed.
Probably less of a problem in the US as I don't think state boundaries
change much. (I don't know about US counties.)
On Fri, 29 Oct 2021 09:48:08 +0100, Ian Goddard
<ianng@austonley.org.uk> wrote:
On 29/10/2021 09:07, Steve Hayes wrote:
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.
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.)
On 30/10/2021 05:54, Steve Hayes wrote:
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
When I copy this event to my own family tree, it does not copy the
original event place, but the spurious Chichester one.
Looking at the list there are two Event Places, the Chichester one and
Event Place (Original) which is the correct one. This suggests to me
that it has been "corrected" by someone with a limited grasp of British >geography. It may have been a batch correction for the entire census. >Alternatively it might have been yet another artefact of slipshod data
entry and QA given that Chichester comes before Colchester alphabetically.
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!
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.
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.
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.
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.
On Mon, 14 Feb 2022 23:23:54 +0000
Ian Goddard <ianng@austonley.org.uk> wrote:
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.
I use Opera and it works fine.
That was my point. Opera is one of those Chrome derivatives.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 45:29:46 |
| Calls: | 6,648 |
| Files: | 12,197 |
| Messages: | 5,329,774 |