Help get this topic noticed by sharing it on Twitter, Facebook, or email.

modification of dates and places.by standardization

It appears that there is going to be an automatic update to Standardize dates and places in Family Tree. Hopefully it does not create any major issues. See new blog entry --- https://www.familysearch.org/blog/en/...

This just posted for information to the many users who follow these threads so there is not surprise.
3 people like
this idea
+1
Reply
  • This is probably in connection with another subtle update I have noticed recently. When entering a place name, it used to be possible to pick the first line of the drop down menu instead of the standard even if the entry matched the standard. The place entry would look like this even if what was typed in matched the standard:



    Now, if what one has typed exactly matches the standard, that first line of choices is the standard and you cannot avoid picking it (you do have alternate choices if the same name have various meanings):



    From the blog post (thanks for posting it, by the way) it sounds like all that will be done is to fix entries that look like this:



    because of this:



    without changing the displayed data.

    This will be good to have done. But the law of unintended consequences will surely be enforced. I predict that within a couple of weeks we will see several complaints here that a map location is way off and it will turn out that the first possible choice for standardization was for a different place than the display text meant.
    • Agreed, I've been working on records with secondary events indexed only by the town name Fischingen (in Hohenzollern, Prussia). For standardized places, the first and third jurisdictions in the drop-down menu for Fischingen are in Switzerland, and the second is in Baden-Württemberg. The correct place is among the fourth through sixth jurisdictions: the civil registration district, the Catholic parish, or the municipality. The update probably won't look that deep.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • I can only hope that the updates will do the following, and ONLY the following:

    1. It WILL NOT AFFECT any existing Display values.

    2. Anyplace that there is not a standardized value assigned (i.e., it has the red "!" as a data problem), it will take the most likely standardized place and assign it to that vital--AGAIN, this WILL NOT CHANGE any existing Display value for that vital! Only the standardized value assigned to that vital will be updated.

    The existing methods for assigning Display and then Standardized values are a little bit problematic. For example I've seen it where if you have a standardized value assigned as a Display name and you modify it to be preceded by some extra information (such as a street number and address), If you just hit "Enter" or "Return" after adding the extra information instead of selecting it from the standard place pulldown, it can occasionally create the data error.

    This is a very subtle behavior that people don't currently notice. In fact, I suspect that it is one of the reasons for many of the red "!" marks that exist. It would make sense to me if this behavior in the user interface was also tweaked to be more stable as part of this update.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • 1
    I think we're going to see an awful lot of complaining about that sort of thing!

    Standardising places is much, much more dangerous than standardising dates. If a date is the same as a standard date then the chances of it not actually that date are vanishingly small. On the other hand if there are multiple possible variations of a place spelling in the standards database I don't think that this should be done.

    I've said before that the best way to approach getting rid of small problems and errors like this is to use the method Openstreetmap has. In other words pull a data dump of the errors, put it on a server and give people the option to work their way through a section of the errors to sort them out by manual fixing. That way the automated systems do what they are best at which is finding and presenting a list of the potential problems and the humans do what they are best which is actually fixing the potential problems or marking them as not a problem.

    Oh and further down in the post history of that blog can you guess what I saw?

    Five things for users to do including 1. Start your family tree. AAAARRRRGGH!!!!!!! How on earth are we supposed to get new users in the right frame of mind and paradigm for using FSFT as a shared system when silly posts like that go up on an official Familysearch blog? It's like the fourth cousin two times removed who is your "ancestor" according to quite a lot of people at Familysearch. No they aren't. They are a collateral line relative. An ancestor is someone who is in your direct line. Everyone else is only a relative and NOT an ancestor.

    Oh and to prove my point about this, guess what the first comment on the article said?

    "I shared my family tree on your site. Another lady wiped out 20 years of research on my Sarah McLemore. I do not have the time nor patience to return and re-enter all that work. She had her Sarah mixed up with mine. I have original documents on my Sarah as well as notes from her baby sister that were preserved for over 100 years written about my family in the 1800s that named all 13children, their spouses and the grandchildren... I will not add any more family to your site until your policy changes where people cannot wipe out your research. I ask that my work/ family tree be removed from your site for that reason. Only parts of it have been taken down. Now people ARE coming to the tree that still has my contact data are copying and reposting inaccurate data on the internet about Sarah. These combined trees should be eliminated where someone can come along and change your data at will!"

    Precisely the sort of post we see so often here where someone has completely misunderstood the nature and purpose of FSFT.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • I am also a little worried how they are going to standardize dates. If e.g. birthday is 3.7.1856, is it going to be 3 July 1856 or 7 March 1856. So how it is decided which one is it going to be, European or American way?
    • view 4 more comments
    • Jason

      It appears from, your response in this post; and, your response in the post for "Standardizing Double Dates" ( https://getsatisfaction.com/familysea... ), a few minutes prior to this post, that you are part of "FamilySearch".

      If such is the case, can you please APPEND that fact to your Name; so that, us 'lowly' Users/Patrons can distinguish from responses in the posts in this Forum between, "FamilySearch" Personnel; and, other 'lowly' Users/Patrons.

      'Thank You' in advance.

      Brett
    • Jason

      After the FIASCO (ie. screw-up; and, mess), when "FamilySearch" tried an "Automated" process of "Deleting" / "Removing" the "Duplicate" ALTERNATE Names; and, finished up not only "Deleting" / "Removing" the "Duplicate" ALTERNATE Names; but, also, ended-up "Deleting" / "Removing" ALTERNATE Names that were NOT "Duplicates", I would hope and expect that "FamilySearch" WOULD take, "... A very conservative approach is being made ...", in any such future "Automated" process.

      I am sorry for being negative; but, some of my direct line Ancestors were those that the non-duplicates "Alternate Names" were "Deleted" / "Removed"; and, to make matters worse, the "Reversion" of those incorrectly non-duplicates "Alternate Names" that were "Deleted" / "Removed", DID NOT, go back to their ORIGINAL state again of the original 'Date' and 'User/Patron'; but, where attributed/accredited with/to the current (much later) 'Date' and the 'User/Patron' as being "FamilySearch" - as you can gather, I am NOT happy about that.

      Brett
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • Heidi,

    Here's what I've seen. When typing in the date you suggested:



    It appears to pick the top of the list for the standardized value assigned:



    This may simply be because the dates to choose from are chronological in order. But it does present you with BOTH legitimate (standardized) dates associated with 3.7.1856.

    As before, it seems to take the top of the list for the default standardized value

    It also seems to get it right with the less ambiguous 1856.7.3 which can be interpreted only one way.

  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • Thank you Jeff, I was afraid of that. In some cases the automatic standardization can give a wrong standard. And standards are those what search engines look for. I have seen in my tree that someone has added dates only with numbers with no standard. I have been correcting them when I come across but now without the red exclamation mark, it is much difficult to find them.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • In reading the blog, this will impact only those dates and places that have the Research Help flag for “Missing Standardized Date,” and “Missing Standardized Location”.

    When FamilySearch FamilyTree started incorporating standardized dates and places almost a decade ago, I asked that a routine be run that if the entered place matched a standardized place, that the system apply the standard that we have had to do manually.

    Of course, those "research help" issues still exist, so it appears that only about 15 percent of those records that have the flag will be impacted, so I doubt that it will impact places, such as what Gordon Collett illustrated above. It will impact the standard only and should have no impact on the entered data.

    The flag will still appear for about 85 percent of those records where the flag has already appeared.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • I posted a question on the blog article about the date question. Maybe we'll get an answer. If dates were ambiguous, maybe they just left them alone.

    I took a look at few more example dates, and it appears that the drop down menu for standardizing is not actually chronological, but rather American style then European style:

  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • All

    It will just turn out to be another, screw-up; and, mess, just like when "FamilySearch" tried an "Automated" process of "Deleting" / "Removing" the "Duplicate" ALTERNATE Names; and, finished up not only "Deleting" / "Removing" the "Duplicate" ALTERNATE Names; but, also, ended-up "Deleting" / "Removing" ALTERNATE Names that were NOT "Duplicates".

    "FamilySearch" made a TOTAL, screw-up; and, mess, of x36 of my Ancestors; before, they finally STOPPED the "Automated" process, after I COMPLAINED.

    The most, unfortunate; and, disappointing, outcome of the whole aforementioned, screw-up; and, mess, was that when the ALTERNATE Names that were NOT "Duplicates", were "Restored", they were NOT restored in/as their ORIGINAL state (ie. 'Date'; and, User/Patron) - they were were restored as/with the current 'Date' and "FamilySearch" - And, as such totally, "UNACCEPTABLE".

    So ...

    That ...

    I hope that "FamilySearch" DOES NOT attempt an "Automated" Process to UPDATE and "Standardise" ANY, 'Date(s)'; and/or, 'Places'; and, just leave the process to us, the Users/Patrons - it will just be a NIGHTMARE.

    "FamilySearch"

    I hope you [ie. your "Official 'FamilySearch" Representatives"] are truly, both, reading; and, taking note; plus, really considering, the posts in this "FamilySearch" ("GetSatisfaction") 'Feedback' Forum.

    Only time will tell.

    Brett

    ps: No, NOT a 'happie cappie'.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • Brett: Yes. We are reading and hear you loud and clear. We are making every effort to only auto-standardize when the standard is obvious. That's why only a minority of the data problems will be fixed.

    Heidi Kuosmanen: No ambiguous dates will be auto-standardized as part of this fix-up.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • Michael

    'Thank You' so much for responding.

    But, regardless of the effort that you [ie. "FamilySearch"] make, there should be NO "Automated" process by the "System" to "Standardise", either, 'Dates'; and/or, 'Places' - history has show/proven that it CANNOT and WILL NOT work properly, without causing some "Damage".

    Just leave the "Standardising" to US, the Users/Patrons.

    If it does not happen (by US); then, that is just fine, it does not happen (too bad about the 'TimeLine'); but, PLEASE "Do Not" attempt to do so.

    It is bad enough that the "System" did not "Standardise", 'Dates'; and, 'Places', properly, in some cases, with the change from "New.FamilySearch" to "Family Tree"; and, worse that over the years when various up-dates/releases that have gone through, that the same did not work properly for some cases; but, if you try AGAIN, you [ie. "FamilySearch"] will ONLY make a BAD situation EVEN WORSE.

    But, if you [ie. "FamilySearch"] are going to go ahead "Blindly", regardless of what the Users/Patrons suggest; then, if you [ie. "FamilySearch"] must, PLEASE ensure that ANY record that is "Changed" by your "Automated" process CAN BE "Reverted" back to its ORIGINAL state (ie. with the ORIGINAL 'Date'; and, User/Patron) - IF you [ie. "FamilySearch"] CANNOT "Guarantee" that such WILL be the case; then, just DO NOT do it.

    Brett
    • view 2 more comments
    • Brett,

      You are applying what happened in the past to the present planned action.

      However, you are correct. Sometimes the best laid plans can (and often do) create major headaches for all of us. In this case, given the parameters, I do not believe that is going to happen.

      However, you do have a valid concern. FamilySearch's track record is anything but perfect for these things. I've run into a recent instances where this is the case and it brought to mind another fiasco, as well, all involving "manufacturing" of data (especially for indexes).
    • See the following discussions for details on index entries: https://getsatisfaction.com/familysea... and https://getsatisfaction.com/familysea....

      I realized that you do have a very valid point.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • Michael

    ps: If you [ie. "FamilySearch"] are going to go ahead "Blindly", regardless of what the Users/Patrons suggest; then, if you [ie. "FamilySearch"] must, also PLEASE ensure that you [ie. "FamilySearch"] NOTIFY "All" the Users/Patrons who have been involved with; and/or, are "Watching", such individuals/person what details have been "Changed"; and, NOT just through the "CHANGES TO PEOPLE I'M WATCH" - I am taking about an "E-Mail"; so that, we (the Users/Patrons) can dispute; and, address/fix such change, if need be; and, be able to "Reverted" back to its ORIGINAL state (ie. with the ORIGINAL 'Date'; and, User/Patron),.

    Brett
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • It appears that the routines have been or are being run. I just came across a record where this took place and the only thing that happened was that the standard was set. It is a record that I had previously used (in newFamilySearch) the beta standards list and had not gotten around to finding all the cases where the flag had existed. Now the problem is resolved.
    • view 8 more comments
    • Tom

      'Thank You' for that info.

      Our 18 Year Old dog, got me up, for a call of nature, we keep him inside overnight these days.

      So, I have been checking for various up-dates need on my computer.

      'Yeah' ... looks like those that I am "Watching" have not been affected ... 'Phew'!

      It is not that I am against "Standardisation" 'per se'!

      It is that, sure, go ahead and "Standardise"; but, DO NOT "Change" the "Details" of the "Data" that was ORIGINALLY input/entered; and, most "Importantly" DO NOT "Change" the "Details" of the ORIGINAL User/Patron and 'Date' entered/input on the "Person/Details" page/screen (or where-ever).

      Sure, record in the "ChangeLog" that "Standardisation" has occurred (through an "Automated" process) and was done (obviously) by "FamilySearch" at that 'Time' - just DO NOT impact upon the "Data" that was ORIGINALLY input/entered or the "Details" of the ORIGINAL User/Patron and 'Date' entered/input on the "Person/Details" page/screen (or where-ever).

      I have a number of records that I input/entered in "New.FamilySearch" that SHOULD have "Standardised" with the changeover from "New.FamilySearch" to "Family Tree"; but, DID NOT.

      And, I know (for a fact) that there are records that I have input/entered in "Family Tree" (since, "New.FamilySearch") that were ORIGINALLY "Standardised" at the time; but, for some (inexplicable?) reason; perhaps, due to some process in the past by "FamilySearch", in an attempt to "Standardise", those records "Changed" to non-standard and got the "Red" 'Exclamation Mark'. I have left many of those records; so as, not to impact on the ORIGINAL 'Date" input/entered.

      So, in essence, I would have been happy with a "Background" process to ":Standardise", that DID NOT impact on the "Details" of the "Data" that was ORIGINALLY input/entered; and, most "Importantly" DO NOT "Change" the "Details" of the ORIGINAL User/Patron and 'Date' entered/input on the "Person/Details" page/screen (or where-ever).

      That is my angst.

      Brett
    • The automated process that is running (I expect it will finish today) is not changing original text for dates or places or anything else. And the most recent change message is also being preserved. So if you had put in a birth date of, say, "6 JUN 1974" with a highly detailed change message then the process would preserve the original text of the date as "6 JUN 1974", add a standard form of that date as "6 June 1974" and keep the detailed change message.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • Just an update on this. Standards has updated about 1/4 of the information as of late yesterday.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • LV9V-LZ1 shows birth place changed by FS June 5, 2019. Still has red exclamation mark.

    LV9V-5RH same as above except change date is June 6, 2019
    • view 3 more comments
    • What the process has/will done/do is to look at each date and place that has the red flag.

      If the date and/or place can be set to a standard where there is no possible ambiguity (in either the entered date and/or place -- or in the standard itself).

      If there was the possibility, the process does not take any action, but I'm left with the impression that it marks the event as having been "touched" (with no action) by FamilySearch. The red flag remains in place.
    • In both of these cases the birth date was standardized and the birth places were not because a match wasn't found with sufficient confidence. The red exclamation marks are still there because the places haven't been standardized. Someone who knows Belgian places will have to look at them. :-)
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • Phil or Michael

    Does any record that is "Changed", by this "Automated" process, by the "System", to "Standardise", 'Dates'; and, 'Places', get recorded in the "ChangeLog" of the individual/person to whom the change applies?

    Brett
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • 1
    Of course it is in the Change Log. That is how Tony knew something had happened. To take from his example above, here is the Change Log:



    This is for the change from:

    Displayed: 25 Jul 1806 - Standard: None

    to

    Displayed: 25 Jul 1806 - Standard: 25 July 1806.

    This does point out something about the Change Log. If you just change the standard, it doesn't look like anything happened.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • Gordon

    'Thank You' for that.

    I have been checking my "Watch List" of "CHANGES TO PEOPLE I'M WATCHING", daily; and, to date, nothing has been listed/surfaced.

    I must count myself "Luck".

    As I have always considered; and, found to be a problem/issue ('pet peeve'), I totally agree with you last sentence/comment.

    And, as such, it is disappointing that it DOES NOT indicate in the "Image" that you have post above, that the "Change" was through/by an "Automated" process to "Standardise" the, 'Date'; or, "Place'; or, both.

    Brett
    • Brett

      The Blog item says, "This will occur for vital and couple relationship conclusions only and will not trigger users’ Watch Ancestor notifications."

      I assume "Watch Ancestor notifications" means the same as "CHANGES TO PEOPLE I'M WATCHING", so you would not necessarily be aware if this process had affected the records of your ancestors / relatives - unless you checked their Change Logs.
    • Phil

      That seems to 'fly in the face' of the way the "Watch List" of "CHANGES TO PEOPLE I'M WATCHING" has been working (in the past); because, in the past, my "Watch List" of "CHANGES TO PEOPLE I'M WATCHING" also displayed "Changes" that were made by (ie. designated to) "FamilySearch".

      I am certainly NOT happy; if, my "Watch List" of "CHANGES TO PEOPLE I'M WATCHING" ... DOES NOT ... included "Changes" that were made through the "Automated" process (by the "System", "FamilySearch") to "Standardise", 'Dates'; and/or, "Places'; even, if ONLY to the "Standard"; especially, if that "Change" IS recorded in the "ChangeLog" for the individual/person; and, of course, appears on the record of the individual/person.

      Brett
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • Standards update is done as of last night. 13 million places and 8 million names were updated.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • Sorry if I've missed something here, but perhaps, Phil, you can advise the future situation regarding clean-ups of this nature. For example, if I enter an ostensibly correct / standard date today, then omit to click on the suggested (identical) standard date below, will this remain with a "No standard is selected" error message / red flag until any future exercise?
    • view 12 more comments
    • Phil

      Sorry if you have misunderstood my comments. My last point referred to the fact that, from the time this exercise was completed, there will now be a further build-up of correctly formatted dates being shown as non-standard, because the identical standard date shown below was not clicked-on before the user "Saved".

      So this exercise will need repeating from time to time or, at some point, the problem will be as bad as it was before.
    • Personally, I truly hope that there NEVER will be another such "Automated" process (by the "System", "FamilySearch") to "Standardise", 'Dates'; and/or, "Places', again.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • So far I have been concentrating on the date aspect of this exercise, rather than the place names. I have just been looking at a few of the June 7, 2019 (FS date display) FamilySearch standards and notice they do not include the United Kingdom suffix for places in England.

    This makes a bit of a mockery of the options given to users when standardising, which shows the United Kingdom suffix should be chosen for post-1801 dates. So if we wish to comply with the FamilySearch standard suggestions, strictly speaking we will need to go back and change details of every post-1801 event ("standardised" by FamilySearch around 7 June 2019) to include "United Kingdom"!

    Think I'm being silly? Not if you consider I have resisted adding "United Kingdom" until the last few months (not least because this adversely effects search routines) and now find - after finally conforming to FamilySearch's "instructions" - it is seemingly not important to add it, after all.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • Further to my comments of 6 days ago, I would be grateful if a FamilySearch employee could confirm the position in relation to those place names that have a standard ending in "United Kingdom" (e.g. post 1801 England places).

    As indicated, I'm sure I have found FamilySearch changes (dated June 7, 2019) where the standard has been set to end with "England" instead of "England, United Kingdom". If the programming has not taken the "1801 factor" into consideration, a huge number of these changes will have been implemented incorrectly.

    If this is the case, like Brett, I will be most annoyed by the results of this exercise - especially when I (and other FT users) have gone out of our way to comply with choosing the most appropriate option from the drop-down list.
    • view 4 more comments
    • I'm quite sure that Paul - like myself - will swear, hand on heart that we've never, ever left a standard place-name empty.

      Mmm.

      Problem 1 is that, of course, it happens. But I also have the idea, possibly totally wrongly, that Problem 2 is that, at some point in the proceedings, FS released some code that "lost" some standard place-names. Now, at what point the names were lost, I've no idea, but it's certainly in my head, rightly or wrongly (you can hear all my excuses for poor memory here) that standardised data was lost as the result of a bug. If it was, then it's entirely reasonable that FS should attempt to fix it. Which is why I've been fairly relaxed about this update.

      So everyone might well have taken care to standardise all their place-names - it's just that some of those values have been lost in transit. And I think that the Change Logs will never show any trace of a lost Standard value because the Change Log would hardly be written when a bug caused data loss.

      Comments and contradictions welcome....
    • There have been SEVERAL times that I thought a Standardized value had been assigned when it had not, resulting in the data error that I missed completely. I've simulated the behavior at that time in the following images.

      Let's say I enter a location that is identical to a standardized value. I automatically get a pulldown list with the value I just entered at the top of the list:


      Now let's say that I select the matching standardized "Selection B" from the above image. I will get the following display where the Display value is the standardized value:


      This shows exactly as you would expect. The standardized value with its map pin shows up as the Standardized Display value for the location. However, If I were to have just hit "Return" or selected the equivalent "Selection A" in my first image, I would have gotten something similar to the following:


      (Note, I have faked these images a bit since I created them using the current software. I'll explain later)

      The last image above illustrates that because I didn't actually select a standardized value from the list, it KEPT THE VALUE I ENTERED as the display value, and automatically assigned it's attempt at a standard value. This is how the software works today.

      However, THIS IS NOT HOW IT USED TO WORK. Originally this used to result in NO Standardized value being assigned which resulted in the red "!" even though the Display value matched a standard value exactly. This is how I frequently wound up with the red "!" even though my Display value matched a standardized value exactly.

      FS has fixed this so that as shown in my last image above, the standardized value is assigned even though you don't specifically select it. It Keeps your display value.

      Now regarding my first image above, the behavior I described is no longer active since FS has fixed that too. If you enter a display value that is an exact match to a standardized one, you will not get the display value and the identical standardized value both at the top of the list. You will only get the standardized value.

      The ability to get an unassigned standardized value now seems to only be possible from the "None of the above" type selection at the BOTTOM of the standards list.

      One final note. Since FS changed this selection mechanism to fix it, the only way I could illustrate it was to fake a match by entering a space character at the end of my Display value. You normally wouldn't get a display like in my first image today since there have been fixes applied.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • All

    Regarding my specific worry that the "United Kingdom" might have been dropped in the process of earlier this month, I am now fairly convinced no "damage" has been done. I agree with the suggestions that the name format has not been changed but this exercise has done exactly what I had hoped for previously.

    Whether the "Non standardized place name" message appeared due to a user not selecting anything from the drop-down menu, or if the problem had origins from nFS days, I had always hoped there would be a way of correcting all those, say, "Alnwick, Northumberland, England" inputs that looked perfectly standardised to me, but still carried the warning message, even though my "amended" entry (effectively a click on the suggested name in the drop-down list) appeared identical to how it appeared before!

    So, if this is all that has happened, I disagree with Brett entirely, because I still had hundreds of examples like this that I needed to manually standardise - so FamilySearch engineers have saved me a considerable amount of unwanted work.

    I am pleased to read the many theories / comments that gasmodels' original post has generated, however, but hope the whole exercise indeed has no deeper implications (that might have led to even more work for users!), as I have probably mistakenly suggested in previous posts.
    • view 1 more comment
    • Paul

      Certainly, disagree with me, most do ...

      But ...

      It is NOT that I am against the "Standardising" of 'Dates' and "Places', per se, to get rid of those 'pesky' "Red" 'Exclamation Marks'; and, I am not even again such being done through a BACKGROUND "Automated" process, by the "System" (ie. "FamilySearch").

      The problem/issue that I have is that in some of the "Automated" processes, by the "System" (ie. "FamilySearch"), have been a fiasco (ie. screw-up; and, mess) with something else, in addition to the matter being addressed/fixed, being wrongly dealt with.

      And, another problem/issue that annoys me the most in these "Automated" processes, by the "System" (ie. "FamilySearch"), is that the details of the original 'User/Patron' and 'Date' entered are not retained; but, are overwritten, with the User/Patron as "FamilySearch" and current 'Date'. Fine, do a BACKGROUND "Automated" processes, by the "System" (ie. "FamilySearch"), that DOES NOT show-up or get recorded in the "ChangeLog"; nor, against the record on the screen/page, that affects the details of the original 'User/Patron' and 'Date' entered.

      But, that is just me.

      I know when I entered the original 'Date' and/or 'Place'; or, even "Changed" a 'Date' and/or 'Place' (in, either, the old "New.FamilySearch"; and/or, later, "Family Tree"), they, either, would have been a standard or acceptable to a standard; and, some of my records now have "Red" 'Exclamation Marks'; so, I agree that some process or processes, in the "System", over time have affect the standard for some such records.

      Brett
    • Brett

      Yes, I do understand (and share) your worries that past exercises like this very often have had unintended, adverse effects - so the same could well apply in this instance.

      The main point I was trying to make is that it appears that the actions (or lack of) of at least one other user appears to had resulted in hundreds of records, in a branch I am working on, carrying the "Missing Standardized Location / Date" error messages.

      Until I started to clear things up, the whole of a Landscape view of this family was covered with red exclamation marks! I'm sure the reason for this was due to him not selecting a standard from the drop-down list before clicking on "Save". So I admit my delight for this adjustment exercise is a very personal one - in that it will save me a lot of work in changing "Alnwick, Northumberland, England" (the place where most vitals events for this family took place over a 100 year + period) to an identical looking (but now "standardised") "Alnwick, Nothumberland, England".

      As I have agreed, past experience shows you (or anyone) should not be criticised for raising concerns about the possible negative results produced by this or similar exercises.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • Jeff Wiseman -

    The assumptions you listed up-thread are correct. The original text for dates and places, which is what is usually displayed, was never touched. And the fix-up only added a standard where the date or place had no standard chosen previously and the choice was "obvious". In no cases did we change the original text or a standard that was previously chosen.

    And I want to assure you that the motivation for this change had nothing to do with any data-loss event. There has been no such event. The problem that motivated the change was that for quite a while the source linker on the website wasn't providing a way to standardize dates and places when they were added from a source. So it wasn't that patrons were failing to enter the standard it was that FamilySearch didn't provide a way to choose the standard. This was an effort to try and alleviate some of the pain caused by that feature omission.
    • view 1 more comment
    • Yes, Michael. This is just the explanation / reassurance we have been waiting for. Thank you.
    • Thanks for the confirmation Michael!

      The issue of how the time/place editing used to function (i.e., resulting in unintended absence of standard values being applied) has not really been discussed here (other than what I brought up). It's really nice to see that nasty little quirk has been recently repaired. KUDOS to the team!
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated

  • 3
    Actually, for what it's worth, the source linker issue hasn't really created a problem specifically for me in the past because of my workflow.

    Whenever I have the source linker up and I attach a source to a person, I always have the person's details page open as well. Depending on what differences exist between the indexed values that will come through the the source linker, and the existing values already recorded for the person's vital, I may just NOT bring the data over in the source linker when I do the attach, and just modify it by hand in the person's details page.

    The reason for this is that the indexed values being shown in the source linker are usually NOT VERY GOOD. They are frequently abbreviated, truncated (i.e., country and/or state missing), ambiguous, or just plain missing details that were actually in the original record.

    For example, the information on a census page usually contains the COMPLETE date that the census data for a specific family was was actually collected, and frequently includes more details of the residence address as well. However, that info is never indexed. For addresses, you usually only get an electoral district number, which is inferior to an actual address which can be pinpointed on a map. The date is usually nothing more than the year of the census. So those details NEVER show up in the data brought over by the source linker even though they can be extremely useful.

    So in ALMOST ALL CASES, after attaching a source, I have to go to the person details page and update the vitals data based on what was in the original source images. Since editing these things from the details page invokes the standardization mechanism, all of the attachments that I've made have always had the standardized times and places scrutinized by me.

    And by the way, this is why it is so excellent that FS does not allow data for a vital to be brought over via the source linker when there is already data in the corresponding vital for the person's record. Usually, when I'm working on the source linker, I have already put a far superior time and place in the person's detail page than will exist in most index records. It would be a real nuisance if that correct detailed information could be easily blown away via someone carelessly using the source linker.

    (Of course, the GEDCOM Compare tool does NOT afford you such protection in that someone can easily blow away anything repeatedly that is already there without any restraints at all. But then that's another continuing problem)
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited sad, anxious, confused, frustrated