nFS & temple ready place standardization

In the past, temple ready has "standardized" places for my ancestors thus:

• moved pre-Germany Hamburg from Europe to the USA (YIKES!!)
• plopped my Lithuanians into a different century by deciding that they were in the USSR

New FamilySearch continued this process by removing data from my great-grandfather's birthplace which was Precinct C, Seward County, Nebraska, but shows up as Nebraska. While this is not as drastic a change as the previous examples, it gives the appearance that I submitted it as "Nebraska" and that no better detail was available.

So, in addition to combining duplicates due to the manner in which the older databases were established, I also have to combine (although the consultant used a different term) myself as the submitter and "dispute" places randomly revised for no apparent reason. As a researcher, if I were extending my tree and found the above information which was then disputed by the submitter, I'd have serious concerns about the quality of that person's research.

Are there any plans to restore data to the original submission or fix this in some other manner?

scion wrote:In the past, temple ready has "standardized" places for my ancestors thus:

• moved pre-Germany Hamburg from Europe to the USA (YIKES!!)
• plopped my Lithuanians into a different century by deciding that they were in the USSR

New FamilySearch continued this process by removing data from my great-grandfather's birthplace which was Precinct C, Seward County, Nebraska, but shows up as Nebraska. While this is not as drastic a change as the previous examples, it gives the appearance that I submitted it as "Nebraska" and that no better detail was available.

So, in addition to combining duplicates due to the manner in which the older databases were established, I also have to combine (although the consultant used a different term) myself as the submitter and "dispute" places randomly revised for no apparent reason. As a researcher, if I were extending my tree and found the above information which was then disputed by the submitter, I'd have serious concerns about the quality of that person's research.

Are there any plans to restore data to the original submission or fix this in some other manner?

newFamilySearch does not change any submitted information. What you are seeing is the combining results or standardized place names. When we combine multiple submissions, newFamilySearch can only display some of that information in the pedigrees and summary views. If you go to the Summary tab you can select which data is to be displayed. If no one has gone to the Summary tab and selected what informtation is to be displayed, then the default data will be sorted and you will see what ever is sorted to the top. The other possibility may be that you are seeing a standard place name displayed. If a standarad place name is displayed and it is not the place you submitted, then your place name should still show up in the details. The new standard place name function is a work in process and will improve over time. It attempts to find a standard place from the information submitted to display. You can go to FamilySearch Labs and look at the Standard Finder and leave feedback there on places you feel need to be updated. Your feedback is helpful so go there and leave feedback. I would also recommend leaving feedback at newFamilySearch.

Yes, it does. I know what I submitted: Precinct C, Seward County, Nebraska. FS shows Seward County, Nebraska
nFS shows Nebraska
Not only was my original submission changed with FS, it was changed again with nFS.
The submitters are me & me.

scion wrote:Yes, it does. I know what I submitted: Precinct C, Seward County, Nebraska. FS shows Seward County, Nebraska
nFS shows Nebraska
Not only was my original submission changed with FS, it was changed again with nFS.
The submitters are me & me.

Was the submission to the Ancestral File? Some merging was done in the Ancestral File. Those records were added to nFS.

A place name is normally: city, county, state, country

nFS uses the Standard Finder. I'm not sure how your submissions got to nFS, if it came from an incorrect database or from the original submission to that database. But I'm sure it will try to standardize the name. This is important - not because it standardizes the text, but because it connect to a site ID. It helps when other comparisons are made. It doesn't have to try and match the text - it looks in it's database of place IDs. So it understands that your location is part of "newbraska" or even part of "каттышкан штаттары" (United States).

Just for fun I tried to submit "Precinct C, Seward County, Nebraska", but the closest I could come up with is "Seward, Nebraska, United States". A little digging suggested that "Precinct C Election Precinct, Seward, Nebraska, United States" is the correct place.

Nope. It was on the time appropriate atlas that I read when researching that family. Farmland & prairies lacking towns were identified as Precinct A, B, etc. Changing submitted information makes the database even more unreliable than it was.

I have no desire to go through everything I have ever researched every time the church software changes it to see what is new and fix it. My family is an absolute mess on nFS. Furthermore, the links that I did on it do not show up for my first child to log on & view it.

scion wrote:Changing submitted information makes the database even more unreliable than it was.

Not standardizing it makes it unsearchable. There is more then one way to spell a simple thing like the name of a country. Text comparison doesn't fly for a world-wide system.

As for "Precinct C" vs. "Precinct C Election Precinct", you'd have to take that up with the company that the church purchased the information from.

I beg to differ. The "standardized" places are historically inaccurate, and in the case of moving Hamburg from Europe to the US, just plain wrong. It is not easier to search for a place in an unknown random year, than in the historically accurate place--let alone the wrong continent.

nFS also stripped several of my generations of their surnames (1800's in the US). They had surnames in FS & in my records. How, exactly, does this prevent duplications?

Hey, it even gave me a new spouse who absconded with two of my minor children. Can't delete "unknown" because their is no arrow by this particular "unknown", therefore the instructions to delete him are futile. It also added "unknown" spouses to ancestors who were mysteriously married on the same day as the known individuals.


A system that randomly "corrects" data like this makes a mess.

scion wrote:The "standardized" places are historically inaccurate

For the goal at hand, does it matter if it's historically accurate? Yes, it would be nice to be that way, but it's more important that the location be accurately understood.

scion wrote:and in the case of moving Hamburg from Europe to the US, just plain wrong.

Agreed.

scion wrote:It is not easier to search for a place in an unknown random year, than in the historically accurate place

With standardized places it knows that someone born in the "13 colonies" is at least a place match for someone born in "amer colonies", "United States" or even "شتتهای متحدۀ امریقا".

scion wrote:nFS also stripped several of my generations of their surnames (1800's in the US). They had surnames in FS & in my records.

Different issue. I don't know what happened there. You still haven't answered how your data got into nFS. Your data may not have been in a format that nFS expected.

The data was already on the old FS system.

scion wrote:The data was already on the old FS system.

nFS is a collection of all submissions from everyone for the same person. It is designed to allow us to clean up the records of the Church and prevent duplication of Temple work. Until you or other relatives clean up the files they may have many errors displaying in the system.

The changes to the place names were probably made in Ancestral File prior to being included in nFS if they show different than you submitted them. There are ways to look at the information in nFS and find what happened if you can give us person ID numbers, maybe we can find some answers. nFS retains all information that is added to it in the format it is submitted, it may display a standard place instead of the place submitted but it retains that orignial information in the details.

Part of what you are seeing in nFS are other peoples submissions which have been combined with yours. Those with first names only were likely submitted by others, you just need to go to the summary tab and select the more correct name from the folder to display. Information submitted by others may have been submitted incorrectly.

Standard place names are also designed to identify where records for that locality are located today. Some historical place names may not be in the system yet.

On the subject of links from you back to your dead ancestors, those links will not be visible to any other person, each person will need to add those links back to their dead ancestors in their own accounts. This is done because of privacy laws.

GarysTurn wrote:nFS is a collection of all submissions from everyone for the same person. It is designed to allow us to clean up the records of the Church and prevent duplication of Temple work. Until you or other relatives clean up the files they may have many errors displaying in the system.

And having said that, I don't see what the big deal is. When nFS finally became live in my area, I went in and started making the corrections I've been waiting to make ever since AF was taken off-line for not being Y2K compatible. I had a smattering of "non-standard" place names that caused nFS to spit out a warning, but it seemed to accept the "non-standard" placename regardless.

scion wrote:In the past, temple ready has "standardized" places for my ancestors. . . . New FamilySearch continued this process by removing data from my great-grandfather's birthplace which was Precinct C, Seward County, Nebraska, but shows up as Nebraska.

Just for fun, I added (and have subsequently deleted) an event for one of my ancestors and entered the placename of Precinct C, Seward County, Nebraska. When I clicked Done, nFS complained that I had entered a non-standard placename, but when I clicked Done a second time nFS accepted it anyway.

Additionally, even though the only submitters of this information are you and yourself, you might still have to end up disputing the information because for some of the entries there is probably not a way to link your nFS "Person Identifier" code with the submitter information. For me it seems that nFS HAS appropriately linked me to my Pedigree File submissions, and I THINK it has linked me to my submissions tied to my Ancestral File Number. But some of those submissions happened long enough ago that I really have no way to independently verify whether this is the case. I KNOW that submission I have made that are in IGI are not changeable even though I submitted them. Because I have since come across more complete and acurate information, I have disputed some information in nFS fed from IGI even though I am the original source for the IGI submission.

It's not perfect, but it is now a lot better than it was before nFS came along.

Regarding your son not being able to view the links/information you have added, I have noticed that any information you add to a living individual (as noted by that individual's name being displayed in italics) are only visible to you. This is probably why your son can't see it.

Additionally, even if you know the AFN of a living individual and search by that number for them in nFS, nFS wil list them as "Unknown" or as a restricted record. This is to comply with privacy regulations, and I expect that such entries will remain unviewable until they age out of the system (i.e. the current year is 110 years or more after the birth date listed on that record) or until the privacy laws are changed.

scion wrote:Hey, it even gave me a new spouse who absconded with two of my minor children. Can't delete "unknown" because their is no arrow by this particular "unknown", therefore the instructions to delete him are futile.

The first step to take to get this corrected is to check with your ward clerk since membership data feeds into nFS. The situation you described above reeks of a problem with the membership records in question. If I were a gambling man, I'd bet that somewhere between your "new spouse" and "absconded minor children" there are some variances in the membership record numbers associated with each.

For example, in one ward I was in there were three adult biological sisters. When their elderly mother moved into the ward for a while, I noticed that only one of her daughters showed up on her membership record. Even though on the daughters' membership records she was listed, there were minor variations in spelling and/or birth date that had caused totally different record numbers to be generated for the mother (and also the father) on each of the daughter's records. Once I fixed the daughter's records, mom's record was automatically fixed and her record magically regained her missing daughters.

I expect that you are experiencing a similar situation. I would have the ward clerk verify that your membership record number (as shown on the upper right-hand corner of your IOS) is the same record number listed for the spouse on your wife's record, regardless of the name and birth date listed. I would then have him check the membership records of your "absconded minor children" to make sure that the membership record numbers for their parents match those on yours and your wife's respective IOS's. I'll bet the record numbers either don't match or are missing altogether.

If there are corrections to be made, it would be interesting to see how quickly they populate from MLS to nFS. If they don't show up after a reasonable amount of time, then I would send a message to nFS support about it.

scion wrote:It also added "unknown" spouses to ancestors who were mysteriously married on the same day as the known individuals.

Probably because the spouses are still living and thus subject to privacy regulations since the haven't aged out of the system, or no one has submitted the death information on the "unknown" individual, or it somehow got unattached from the "unknown" individual.

jbh001 wrote:I had a smattering of "non-standard" place names that caused nFS to spit out a warning, but it seemed to accept the "non-standard" placename regardless.

Yes, it will "accept" it, but it will hinder any search utilizing the place name because it's non-standard.

You guys just don't get it. You're thinking like programmers and not like genealogists. The accuracy of the place name is MORE important than the standardization. You don't understand how many hours of research go into finding the exact location, do you?

The difference between "Precinct C, Seward County, Nebraska" and "Seward, Nebraska, United States" is probably around 10 hours of real research. But nobody at NFS really cares about genealogy, they're more concerned about deleting accurate input for the sake of standardization, and never deleting an interminable list of erroneous duplicate entries for the sake of "database integrity".

Removing the exact birth location, the exact church in which one was christened, or the exact cemetery one was buried in makes your database useless. You're willing to sacrifice the validity, accuracy and usefulness of your database for the sake of a place standard? You guys never learn.

Scion has a real, valid point. He's right. You've overlooked some serious problems in NFS. Instead of sending out the moderators to do damage control and tell all the users they're wrong, why don't you take notes, and ask how users would like the program to run. You don't realize that people like Scion, myself, and others who CARE about accuracy are the ones who will save NFS from the same fate that caught up with Ancestral File, Pedigree Resource File, and the IGI - the utter uselesness due to inaccuracy and vagueness. Duplication isn't the only killer.

Well, because none of you have figured out the right response to Scion's post (instead of just telling him he made mistakes and his desire for accuracy is sacraficed for the "greater good" of all those people in Yemen researching Seward County, Nebraska), let me present it:

"Scion, it's possible that NFS' automatic place standardization edited your entries. I understand that it's important to you to include the term "Precinct C" in the place name. This was an unanticipated result, and we're sorry for the many hours of duplicate work this will cause you. Can you propose an idea that will allow us to maintain standard place names, while giving you the flexibility to add more exact place identifiers?"

I'll give you my reply, though I don't know what Scion would propose (you might want to ask).

Keep your list of standardized places. Genealogists use commas to define smaller, more exact place names. If you can't identify a more exact place name, standardize everything to the right of that comma. Keep a list of un-standardized, more exact place names for every larger standardized locality. Thus instead of NFS reacting in the following manner -
[INDENT]User input, or data input from AF, PRF, IGI, VR, etc.:
Precinct C, Seward County, Nebraska

NFS standardizes the input as:
Seward, Nebraska, United States (or in Scion's case, just Nebraska)
[/INDENT]NFS would react in the new manner as such:
[INDENT]User input, or data input from AF, PRF, IGI, VR, etc.:
Precinct C, Seward County, Nebraska

NFS Standardized user input as:
Precinct C, Seward, Nebraska, United States
[/INDENT]where underlined terms are unidentified, unindexed terms that assist in further identification for users, and bold terms are searchable, standardized terms that can be displayed in multiple languages and searched using non-latin characters. A person from Yemen would thus see the returned search as "Precinct C, شتتهای متحدۀ امریقا" (who knows what that really means, but you get the point). If they don't really care about knowing what area of Seward County their cousin Habib lived in, great. If they do, they can do a search for "Precinct C" and find out what it means or where it is. Most other alphabets are using latin characters for some words that don't exist in their language anyway, like "Internet" or "Microsoft", so it wouldn't be out of the ordinary for foreign users.

There you have it, a practical solution - something forgotten in the mad rush to defend NFS from all those blasted users! Genealogists can keep "Old MacGregor Cemetery" in the burial location, and the programmers can get warm fuzzies about standard places. Then, if all the data really is kept somewhere in it's original form like you say it is, you can have the data re-analyzed to bring back all of those incredibly important names of churches, cemeteries, and forgotten towns that programmers could care less about. Scion gets Precinct C, and you get Nebraska. Deal?

Great. Now, before you slip back into the old "programmers and moderators are right, users are wrong" mentality that dominates this forum, take a deep breath and think about whether you really want to alienate the most powerful users NFS will ever have. Real genealogists.

I understand both sides of this issue. I don't know if there is a real solution that will make everyone happy.

From the programmers side they need to lump all the records from the same approximate area into one search group for searches to be able to find the records that people are looking for in a search.

From the researchers side they want to be able to identify right down to the exact historical location of an event. Even right down to the Church where a baptism took place, to a hospital where someone was born, or to a cemetery where some one is buried. All these place details can always be included in the notes since the software requries standardized places for searches, but this solution doesn't seem to satasify everyone.

There have been some provisions that have been made to allow non standardized place names to be entered and stored in details along with a standard place. In this case only the standardized place is displayed in the summaries and pedigrees.

The standardized place routine still needs refining as well and we can all submit feedback to help in that threw the help center in nFS or at FamilySearch Labs in the standard finder project area.

I agree with Alan. A database could be produced of location names with dates - it could even have its own pedigree of a modern place name branching off into all historical place names that would be included. Thus a search for the modern location would iterate through all included historical place IDs. Thus ghost towns could be included in the current county even if they have no modern place name to be linked to. And a specific town that has just been renamed or survived several larger political boundary or name changes could have a list of names paired with dates all sharing a place identifier with the modern equivalent and the system would need to store somehow the equivalent names for certain dates.

I think if historical place names have their own tree-based, pedigree-like system it will satisfy the programmatic need for pulling all records people would look for in a search as well as the genealogical need for accuracy in research. It could serve as an additional help for those who don't have a historical knowledge of what locations they could search for records. i.e. "Click here for additional historical place names for this location." or "Click here for historically-accurate place name for this modern location at the date of this event on this record." As a beginning genealogist myself, I would be more than happy to allow the more advanced genealogists to research historical place names so I don't have to unless needed. While I may agree in general with flattening records, I am hesitant to whole-heartedly agree with flattening the geographical and historical place names in the name of standardization without providing (even a future) solution to not lose important historical data that will lead to further research. Relying indefinitely on user-based lists kept in homes of mapping old place names with modern replaced equivalents in nFS is inefficient and unfortunate if allowed for long.

As for Brad's comment for mixed standard and non-standard place names - Since I am unfortunate enough to be sitting here in Utah waiting for eternity to get my hands on the nFS system (end of rant), I am unable to test any theory in practice. Does the nFS system see non-standardized entries as a two-part deal? Non-standardized + standardized? Could it search on the standardized and ignore the non-standardized while keeping the data, or is it just a hope and dream?

Thank you, Brad Jackman & Alan Wombold. I'm too young to have contributed my own 4 generation sheets in the 1970's, but followed the church directions to contribute often to the AF and of course submitted family to the temple & performed ordinances (each of which creates a separate event). I understand that following past church leadership directions has resulted the need for LOTS of combining, even though I am the only LDS researcher for much of my family until I get back near my Colonial American ancestors.

One thing that would likely decrease issues in what is viewed once someone has done some combining is to default to view the most recent submission. This would reflect changes in the research process. For example:
1989 I figure out that grandpa had 3 siblings, unknown gender
1992 I find out that the oldest is male
1996 further research yields initials TB
1999 his first name is Tom, but no hint of what B stands for
2003 determine that his name is Thomas Benton
The most correct name for him is Thomas Benton LastName. It would help if the latest info for each field of a given person is the automatic default in combining.

Maybe place options need a historical and a corresponding modern location for each event. However, that would require support & cooperation of other software companies for future updates. This would protect the validity of the data, as addressed in the Maine example provided previously.

As for my mysterious spouse, nothing in the directions was helpful because there was no way to select this living "unknown" to do any merging. (I did merge for deceased ancestors with no problem.) The church records (the source) are accurate; I read the printout in provided annually very carefully, even though I have had no new family additions in several years. Someone at nFS support responded to my email by phone and told me that she fixed it.

In my unbiased humble opinion, the long-term end users of nFS are the genealogists and historians who spend years ferreting out details. Those who will mine it for a name to provide a teenager for this week's temple assignment only get involved when compelled to do so by an external source; hence, they won't be concerned about details that they didn't bother to research.

scion wrote:
One thing that would likely decrease issues in what is viewed once someone has done some combining is to default to view the most recent submission.

The current nFS system allows us to select in the summary view the most correct version of a name, date or location. Prior to the Feb 2008 update of nFS we did not have this function and each persons personal submission was displayed as the default. If they did not have a submission the data was sorted and you ended up with the result of a sort. It created a lot of duplication of records because everyone needed to enter the correct name to get it to display. This new feature works much better. Now everyone sees the same information in the pedigrees and summaries and if there is a disagreement there is more incentive to correlate with others.

kgthunder wrote:I agree with Alan. A database could be produced of location names with dates - it could even have its own pedigree of a modern place name branching off into all historical place names that would be included. Thus a search for the modern location would iterate through all included historical place IDs. Thus ghost towns could be included in the current county even if they have no modern place name to be linked to. And a specific town that has just been renamed or survived several larger political boundary or name changes could have a list of names paired with dates all sharing a place identifier with the modern equivalent and the system would need to store somehow the equivalent names for certain dates.

The current system does some of the things you mentioned. There is a database with different versions of the place names but it does not track historical name changes by the year of change. It needs more refining and that is being done. You can see the project at FamilySearch Labs it is called the Standard Finder. You can use the standard finder and submit feedback for improvements even without a nFS account. Example: Draper Utah use to be called Draperville Utah. Enter Draperville Utah into the standard finder and see the results. It shows all the variations of the locality name for you.

A possible solution might be to allow us to display what ever place name we want in the Summary view and still use the standardized place name in the searches.

Many historical place names are already incorporated into the standard finder, however the fact that it doesn't have the historical place name YOU want brings me back to the comma seperated values which contain standardized and non-standardized places.

This would solve the issue for historical place names not included in the database, and also solve the issue of the church name in christenings (VERY IMPORTANT) and the cemetery name in burials (VERY IMPORTANT). When standard finder sees that there are some parts of the name that appear standardized, it standardizes them, but leaves things unaltered to the left of the standard. Hence:

You enter:
Marble Cemetery, Manhattan, New York, NY

Standard Finder recognizes part of it, and standardizes the recognized portion to:
Manhattan, New York, New York, United States

It does not recognize the left-most portion of the place name, and enters it, unaltered, in the place name field to the left of the standardized name:
Marble Cemetery, Manhattan, New York, New York, United States

Anyone searching for an ancestor buried in Manhattan will only have the standard place names (that can be translated into different alphabets, because this seems to be the crux of the issue) to search by. If they search for someone who was buried in Manhattan, they will find this individual, because the standard finder has tagged this individual with the Manhattan place name, even though it doesn't understand the unstandardized portion of the name. Upon viewing the individual, you would see the specific place of burial.

Anyone see any problems with this?

There could even be a process for adopting and translating or transliterating these additional place names and making them standards in their own right.

Right now it's all or nothing. If you enter Marble Cemetery, Manhattan, New York, New York, United States, it is unsearchable by any term. Seems like you should even be able to switch what type of search you are doing - standardized or simple text.

BradJackman wrote:You enter:
Marble Cemetery, Manhattan, New York, NY

Standard Finder recognizes part of it, and standardizes the recognized portion to:
Manhattan, New York, New York, United States

It does not recognize the left-most portion of the place name, and enters it, unaltered, in the place name field to the left of the standardized name:
Marble Cemetery, Manhattan, New York, New York, United States

Anyone searching for an ancestor buried in Manhattan will only have the standard place names (that can be translated into different alphabets, because this seems to be the crux of the issue) to search by. If they search for someone who was buried in Manhattan, they will find this individual, because the standard finder has tagged this individual with the Manhattan place name, even though it doesn't understand the unstandardized portion of the name. Upon viewing the individual, you would see the specific place of burial.

Anyone see any problems with this?

I think this idea is an excellent first step.

One problem I see is this has the potential to add new clutter to the place name database. All it takes is "dedicated genealogist" aunt Mabel to insist that grandpa Joe was born in Louis County, and her equally "serious historian" cousin Marge to insist that grandpa Joe was born in Lewis County. Then multiply that by all the "dedicated genealogists" and "serious historians" that will use nFS, and you end up with the mess that was Ancestral File. It is exactly these kinds of disputes that the Church wanted to get out of the middle of with nFS.

Having said that, I still think that your idea is better than the current system. Perhaps implementing it will lead to an even better solution down the road.

Good points, BradJackman. This would preserve data integrity for the submitter. If the boundaries have changed over time, then a subsequent researcher would be able to follow the work.

I like the solution Rootsmagic is going to add to there new version, adding a place details field where cemetery, hospital, and other location details can be added without interfering with the location field. See their explination of this new feature. It would be a good thing for the entire industry and the Church to follow.

jbh001 wrote:
One problem I see is this has the potential to add new clutter to the place name database. All it takes is "dedicated genealogist" aunt Mabel to insist that grandpa Joe was born in Louis County, and her equally "serious historian" cousin Marge to insist that grandpa Joe was born in Lewis County. Then multiply that by all the "dedicated genealogists" and "serious historians" that will use nFS, and you end up with the mess that was Ancestral File. It is exactly these kinds of disputes that the Church wanted to get out of the middle of with nFS.

If cousin Marge and aunt Mabel want to enter the different county names in the current system, they can, and nothing is standardized. Not to spoil the scenaio, but most genealogists are comfortable with the fact that the spelling of names and places in old records is not standard. Granted, there are some purists who would insist on this. With my suggestion, the system would not standardize all of one, and none of the other (If they insist on avoiding the suggested spelling of the standardized place), it would standardize everything to the right of these "un-standard" places, allowing searches for someone born in Nebraska, or wherever Louis county is, to return results for both places. Currently, it would ignore all of the unstandardized place.

Even in this scenario, I think my suggestion would be a better option.

The differening opinions on this thread lead me to ask, "Why do we need place names anyway?"

There are obviously several answers, and several different uses, I can think of a few:

1) To provide another criteria for determining if two people are different
2) To provide added information for those attempting to duplicate the research and verify facts
3) To give researchers the best locality for finding sources and additional information
4) To determine birth/christening/marriage/death/burial patterns that may support or disprove family associations
4) To give families a sense of history, and allow them to research or visit historic places of their own ancestry

I think in each of these reasons for using place names in genealogy, we would be supported by having parish church names and cemetery names, and other exact locality information. Having standardized places is not a reason for using place names, it is one solution for a problem invented by the lack of genealogical knowledge of NFS developers.

Why are we ruining genealogical research to save a problematic database? Change the database, not genealogical practices!

Adding a details field for a place is exactly what my afore-mentioned suggestion would do - Use the standardized place as far as the database recognizes it, anything more detailed is not standardized, deleted, or altered, it is listed with the place as a more detailed locality than the standardized place. The only difference is mine lists it with the place, easily recognizable, and other suggestions list it in a seperate field. Not much difference if you ask me, I'd be happy with either, although I think my suggestion has less confusion for the end user - all of the standardized/non-standardized decisions are made behind the scenes. It just adds another step for the user to put each locality in a different field. (Although now that I think about it, I have always been against NFS doing things behind my back...)

BradJackman wrote:I think in each of these reasons for using place names in genealogy, we would be supported by having parish church names and cemetery names, and other exact locality information. Having standardized places is not a reason for using place names, it is one solution for a problem invented by the lack of genealogical knowledge of NFS developers.

Why are we ruining genealogical research to save a problematic database? Change the database, not genealogical practices!

Precisely!!