Proposal to change location field style use

+25 votes
2.7k views

Recently in the Data Doctor Google Email Thread the topic of locations came up.  In several threads over time in G2G and on project lists the subject of using current locations as well as "what they used" came up.    Ales recently commented in response to a discussion on the Data Doctor's list:  Semicolon would be useful to separate old and modern locations in a single field. We could enter Old location; Modern location in the field. It would be easily parsable by computers. But to do that, we would need to set up a "standard" through several discussions in G2G.  

So following that logic,   I propose the standard be changed to

Location fitting what they used ; modern location name

If someone does not have an idea of what to use for what they used the form would be ; modern name

For locations where the old name and current are the same, only one name would need to be entered.  The Semicolon version is to clarify when old names are not easy to find or research.  Or when the country changed like happened in Europe often with wars and treaties. Alsace Lorraine / Elsass Lothringen is a well known example.  All the German Duchy designations and change of ownership are other good examples.  

Red ink used only to show off the semicolon that is used to parse the location for easy sorting and searching.  

I also understand from the Data Doctor email that some projects are using () [] to do something similar so we would ask that they also conform to the new proposed method.  

This should help with many of the empty location fields or fields where a current country name is used out of its time frame.  It should help with accuracy of where the person is coming from.  

Other threads of possible interest:  

https://www.wikitree.com/g2g/1118751/location-field-style-guidelines

https://www.wikitree.com/g2g/1061161/use-of-the-dash-in-a-location-data-field

https://www.wikitree.com/g2g/959895/enter-coordinates-the-location-field-for-someone-who-died-sea?show=959895#q959895

https://www.wikitree.com/g2g/251374/gps-link-to-goggle-maps-com?show=251374#q251374

https://www.wikitree.com/g2g/374444/proposed-additional-current-location-fields-added-profile?show=374444#q374444

https://www.wikitree.com/g2g/877441/locations-genealogy-should-primary-making-policies-profile?show=877852#a877852

https://www.wikitree.com/g2g/1098996/should-use-original-county-names-current-county-names-right?show=1099049#c1099049

edited to insert missing word "have" and a few other typos.  

Adding clarification from notes I have seen posted here or gotten via direct email.  

It has been suggested that instead of current location name a GPS be allowed after the semicolon.   I am adding that as an option.  You will need to scroll down to see that option.  

A number of people have suggested a new field should be added for including a current or modern location.   I am adding that as a new option.

I am also adding a new option to create a specific place in the bio to add current or modern location.   You will need to scroll down to ffind them.   It will take a few minutes to add them.

in Policy and Style by Laura Bozzay G2G6 Pilot (824k points)
edited by Laura Bozzay

Ok thanks sorry I do a lot of my WikiTree reading “off hours” in my phone 

I grabbed that page link for other folks if they want to see it:

https://www.wikitree.com/wiki/Heinrich-398

GPS locations are too exact and change every few feet -- there would be hundereds of thousands that could all be in a major city such as NYC, LA, London, or Tokyo.

Let's keep GPS numbers out of location fields. Likewise the 6-8 number strings we see appearing in Canada and elsewhere. I doubt you will see a sign at the edge of a city that says "Welcome to  ######"
I've decided to vote against using GPS coordinates in location fields. Why make any change to a system that works today? In my example [[Heinrich-398]] the proposal "Old location; Current location" already works. The birth location is a bit long and clumsy but that's a rare problem.
Gottlob's death location is simply "Siegersdorf, South Australia" and the pin takes you to the correct area.

Sometimes the location pins work surprisingly well. One of Gottlob's grandsons was born in a locality called "New Mecklenberg". The German name was changed during the first world war. In this example the pin ignores the name change and still takes you to the correct birth location. https://www.wikitree.com/index.php?title=Heinrich-515
Leandra has presented an example where location names are misleading:
https://www.wikitree.com/wiki/Parker-27391

The place of death "Little Adelaide" is not inside the City of Adelaide. Following the semi-colon, I've added the words, near "near Highbury Street". The pin works!
There is currently only one Highbury street within the entire metropolitan area. It might not work with a street name that exists in various suburbs.

Yes, I was never in favor of entering the coordinates.    I would rather have text that triggers a look up table with stable standardized coordinates that trigger the map.   I would look into using the system Wikipedia uses.  They have coordinates on almost if not all location names now.  

I know there are databases that are freeware that a lot of shippers and others use to get standardized coordinates.  

To me the coordinates are better as a back end process so multiple entered names can be linked to the same coordinates like we do using Google Earth.    It does not matter is someone calls a place Sucht, Lothringen, Germany OR  Soucht, Moselle, France they map to the same coordinates.  

@Leandra, I agree with your comment. I was trying to keep the example as simple as possible.
If more Highbury Streets were created in South Australia, writing the modern location as "near Highbury St.,Prospect, South Australia" works.
@Thomas -- this isn't about whether we are using GPS locations in the location fields (which has been discussed in other G2G threads).

This is specifically a proposal about putting both the location used for the time period of the person (which is the WikiTree use) and adding a current location to help make it easier to place that person on a current map or look for documents about that person.  The "new" or "current" location would be separated from the old by a semi-colon.

Editted:  And apologies to Thomas and others, I now see that Laura has added a GPS option to this proposal.  

Ignore my comment at will.

No one seems to want the one simple thing I need in entering location....A location view that hold more characters so I can easily view the end of the line.
Example: Jürges-17, The Archive file I am using for the source lists the location as:  Isernhagen HB.  When I start to type a suggested loction comes up--but the text box is not big enough to show the end which is import.  Hovering for a second shows the different ways the location can be shown--but you cannot see the most important part until after you make your selection--the date at the end.
If the location date (in my case) is before or after 1866 will show if the record  or individual lived in Hanover, or Prussia.
simply, i wish the "LOCATION" field be expanded so it extends far enough to see most of the longest locations so I can click on "Hanover" rather than Prussia before I hit enter.  99% of the profiles I enter were from "the kingdom of Hanover" (1814-1866 are the correct dates.

I read most of the answers 

Location fields being too short has been my biggest problem over the years as a Data Doctor. It is hard to make a decision when you do not have all the information -- particularly the years the place name is being used for.

What is the problem? Curiously I'm happy with status quo. I've found that I can add a modern location to historic family record names and it works for me.

The more common form is to put a modern name inside brackets. In my family example I've given Ober-Ochelhermsdorf, Schlesien, Preußen (Ochla, Lubusz Voivodeship, Polska). Seems to me a common solution, but harder to implement.
Seems like a good question for the technical experts.
 

15 Answers

+35 votes
 
Best answer
If you agree with the proposal please vote here as a YES
by Laura Bozzay G2G6 Pilot (824k points)
selected by Living Ford
Yes; I agree both would be helpful in location field
This would be a simple solution to a problem though database the input field will need to be longer.
I agree but only if the old name can be added as some county boundaries here in the United States changed and when they changed the records stayed in the original county with new records being created in the new county after its formation.  If a person is not aware of a boundary change and only sees the current county name they may not know to check records in the original county.   This is especially important when checking early records.
What is the whole thread about? That the historically correct name and the modern/current name stand side by side separated by the semicolon that shows where the historical name ends and the modern name starts. And no, you don't *have to* type in both versions of the name.
@Jelena, some people could have have read the original proposal differently. I did not read the proposal as "must have a semi-colon". I think it's great if any historic location name is recognisable today. Nothing more required.
I saw the semi-colon as a useful addition to clarify major changes of names, countries and languages. It is extremely useful to me.
I totally agree and support this proposal 100%
I vote yes. 100% agree with the proposal.
Great idea! County boundaries have changed markedly in England in the past 100 years and cities which once sat nicely within the confines of a county (e.g. Manchester, Lancashire) are now large Unitary Authorities outside of the county structure. London has gone from a City of a square mile in medieval times to swallowing up parts of most of the surrounding counties (and in the case of Middlesex, the whole of it!)

This will neatly show where our forebears thought they lived and where we can find it on a map now.
I donot see the proposal! If the proposal is to keep the original placename as it was at the time of birth, marriage, death of the profiled person, PLUS somehow add a space for the modern-day placename or coordinates, then I vote ''YES". I would not vote YES to any proposal to do away with the original placename in favour ot the contemporary equivalent, for i have spent lots of research-time trying to get the original names as accurate as possible: and i have many german ancestors, whose placenames changed nearly every generation.
I respectfully disagree with using a semicolon ";" as a field separator for historic vs. modern locations.  Many projects already use Parentheses ( and ) or Brackets [ and ] - either or both of these are much easier for most readers to understand and why not just make their use "standard" (we can have both - no need for a "one size fits all" here)!

I also disagree with GPS coordinates as not everyone works with those or with a device that can find them easily.
+65 votes
If you disagree please vote NO here
by Laura Bozzay G2G6 Pilot (824k points)
There is just too much potential for confusion and visual clutter.
I think introducing a coding element into the location fields will prove useful to a small minority of users who know about it and understand it.  Everyone else will either continue entering locations as usual (correctly or incorrectly), or misunderstand and misuse the semicolon.  This change, in my opinion, would probably result in a significant increase in the amount of cleanup/correction work needed on the tree, so I don't support it.
I want to address the concept of confusion.

https://www.wikitree.com/wiki/Space:Data_Doctors_Report_2020-10-11#Suggestions   if you scroll down to see the location suggestions (700s) there are 10s of thousands of them.  Many are specifically related to time periods.  

If above the location fields on the profile page we insert a simple explanation that says:

Option to enter time period location ; modern location or both.  Insert a semicolon between historic name and/or modern location name.    

I think that would be clear and would help us have at least one working name.   Often people are not geo historians and have no idea what the historic name is.  If people are using Family Search, Find A Grave, and many other compilations they do not always have accurate historical names.  

We are not making this a requirement.  We are offering it as an option to those who feel it will help them create profiles with a higher level of accuracy.  

Many areas of Europe have had anything but stable government and this results in a lot of name confusion.  

We think this will help clear up a lot of the confusion and it will give Data Doctors a simple way to fix some of the location suggestions.  Inserting a semicolon can help clarify if a historic or modern name was used.

While I agree it would be very valuable to have a way to enter & search both the historical and modern names, I fear that doing it all in one data field is going to make the places on the profile look very cluttered and confused.

If we're going to make a major change like this, I would think it would be more logical to create a separate place field.

If this proposal was implemented, will you have a team to check all existing and newly added place fields for consistancy? You say, "Location fitting what they used ; modern location name". So who goes and changes the many million place fields? Do we end up with our Suggestions having a needed edit on every single profile? 

Ales should answer this.  My thinking is that if you have an incorrect historic name and a correct modern name or vice versa an informational suggestion not a warning type would be generated like the other profile improvement ones that are optional to even see.

If you only have one location like today and it is incorrect then a warning suggestion like the current 700s would be generated.  

The object here is to get at least one good location on a project.  This is optional to use.  So no one is being asked to go back over all the existing profiles.   If someone wants to do that for the ones they manage it is an option.
Bobbie's comment caused me to wonder whether we would soon be seeing Suggestions to add the other place name to all of our one-name location fields?
We do not need more data fields for location and the use of two locations separated by a semi-colon would be very confusing to both WikiTree members and WikiTree visitors (who would not be familiar with why the location was being recorded that way.) Use the location field for the place name as it was when the event (birth, death, marriage) took place. Use the biographical narrative to describe where the "old location" would be located today if you want or need to make that association. Locations, what geopolitical division they are a part of, and the boundaries of locations change too often to have a location field for a "current" location which may change tomorrow. Just my opinion.
Laura, you certainly have managed to provoke a lively debate.  I agree with Herbert Tardy and Bobbie Hall above:  It would certainly be useful to have a means of including both historical and current place names in the data, but I just don't think the semicolon method is the right means.  It would be too obscure for the average WikiTree user.
I agree with others above. I think this would lead to massive confusion and lots more errors. The order would be entered in random and have to be fixed. If it is important to have both original and modern names (I don't believe that it is necessary) shouldn't it include ALL names the location was known by? It could become a slippery slope.
Many of the locations I clean up that are not correct for the time frame actually had a drop down list with the applicable years included and yet still the wrong location was chosen.
I'm very sympathetic to the idea behind this proposal, but I share others' concern that it would result in a place field that's too complicated to be successfully implemented by an ordinary WT user.  If we tried to do this and it resulted in massively confused place fields on numerous profiles, that would be worse than not attempting the improvement at all.

I vote No. 

The reasons are as others have mentioned: coding, confusion and complications will not help the average WT user. We haven’t defined “modern” either. Would we allow multiple, successive “modern” place names? I have met someone whose grandmother lives and lived in the same house all her life, but lived in 6 different countries.

I do not think GPS coordinates, or Lat/Lon from a map, are a good idea either. GPS coordinates change over time as tectonic plates move, and I’m interested in the long haul. The way that GPS coordinates (strictly, WGS84) are calculated, most accurate results occur in the USA. See also https://xkcd.com/2170/ 

So I prefer the existing policy of ‘the name they used‘, I.e what was on the source. That is a long term stable solution. Modern variants can be addressed in Categories and the Bio. I would be happy to revisit when Time becomes a first class citizen of the geospatial world.

At first it seemed like a good idea, but the location field is trying to serve too many incompatible purposes for a simple fix this way.  Current or modern location won't always be current in the future; so it won't be of much help to future genealogists.  Latitude and longitude seems like a better idea, but in some cases that is too precise -- that specifies a circular region around a point, but what lat/long coordinate should be used for an irregular historical region? The center of that region could be far from the actual birth/death/marriage event location, whose lat/long may not otherwise be known.  It's a complicated problem for which a simple "fix" will only introduce more complication.  We need to think more about the sometimes incompatible purposes of the location fields, which include at least (1) helping to find records from the time of the event that still exist, (2) helping to find grave sites and sites of marriages and births -- which may help toward purpose 1, and (3) attempting to record the historical political jurisdiction in which the event occurred.  Latitude/longitude would be useful for purpose (2).  "Modern" political jurisdiction could be helpful for purpose (1) -- indicating where archived records may be stored now.  Historical political jurisdiction may also be useful for purpose (1) -- indicating where old records might be found, perhaps in museums, that haven't been moved to archives elsewhere.

It's actually even more complicated in that political and religious jurisdictions may overlap with resulting uncertainty over where archived records might now be found.  And burial sites may differ considerably from the actual locations of deaths, but we often use grave sites as surrogates for locations of deaths, just as baptismal records are often used as surrogates for locations and even for dates of births.
GPS coordinates do change some over time but very slowly. All coordinate systems are subject to this problem. GPS (or GLONASS, GALILEO, BEIDOU, etc.) all use some standard reference framework. The International Terrestrial Reference Frame (ITRF) is one such. These reference systems are revised regularly For really long term accuracy you would have to know which satellite or ground based system was used and the date on which the location was determined. No one is going to do that and in some cases you can't know since the latest chips will switch systems to the strongest signal.
I agree with my fellow WikiTreers who have voted No on this proposal, and for many of their stated reasons.

Just the very fact that we have old and new names for locations should tell us that location names continually change and new names would themselves become old names that would then need to be update to the newer new names.

Clearly that is too confusing and time consuming to be of benefit in the long run.
No. Visually it is very distracting, I had to look at the example a couple different times before I even saw where the semi colon was.

All the notes you want can be added elsewhere about complicated places so this is about searchability. I only recently learned how to use reference tags (which are great) and editing some of my profiles that have them I can get visually lost sometime if the citation is long but when you look at the finished profile page there is a simple citation and it is clean and easy to look at so if there is some way to do that in the location field so that it looks clean on the profile but searches the "hidden" data that is what I would go for.
Lindy think of what shippers use now.  They are maintained by lookup tables so if a name changes, it is a universal change in the software.  So the database the tech team would use is maintaining all those changes and because we have tied them to coordinates of some type that works with that software the new correct current name displays.

Nelda,

“...Use the location field for the place name as it was when the event (birth, death, marriage) took place. Use the biographical narrative to describe where the "old location" would be located today if you want or need to make that association. Locations, what geopolitical division they are a part of, and the boundaries of locations change too often to have a location field for a "current" location which may change tomorrow. Just my opinion.

I agree! I was going to comment myself until I read your response. Thank you.

Agree that this problematic in WikiTree, but using one field to store what is essentially 2 different pieces of information seems to be wrong direction. It would seem a solution in this areas should involve two fields.
I can't imagine trying to implement this for locations in Canada, Quebec and Ontario in particular where the same place had several historical names within a single person's lifetime.
It seems like there are two reasonable ways to to handle the old name vs. current name issue. Either add a field for the current name, or, as published genealogical works would do, add the current name in square brackets following the name at the time of the event/record within the biography. Adding more stuff to the location field will complicate that field unnecessarily for beginners and casual users of wikitree (the vast majority of users, I suspect) and lead to more work for the data doctors in cleaning up all the errors generated.

replying to Laura's reply to me:

Is your proposed format to be integrated into the drop-down locations menu?

If not, how would any universal location name update be integrated into a profile that already has data in the location fields, other than by manual editing?

Ales had mentioned making changes to the dropdiwn menu yo be more in concert with the tables used for generating suggestions so in time yes.
I vote No, simply because I don't see the need for, or the point of, a modern place name in older or medieval profiles.
Though an admirable atempt, I still consider this a workaround in place of a proper API targeted at WikiTree's actual needs.
While we discuss guidelines What is an API? I am sorry I do not understand your comment.
Hi Steve, From Louis's comment, I gather that our WikiTree Programming Interface needs more definition.
Small point in interesting debate. What is an API? Totally meaningless to me. My broader point is to acknowledge that Wikitree users don't have the same language and experience.
API is an application programming interface.  It deals with how data is gathered and used.  That is a simple explanation for a series of  complex coding steps.  

https://en.wikipedia.org/wiki/API#:~:text=An%20application%20programming%20interface%20(API,the%20conventions%20to%20follow%2C%20etc.
Thank you Laura. Yes, Steve..API is a programming interface. Sorry, I was otherwise engaged. I have been completing some IT courses so I knew what API meant, however it is easily googled.
No, keep it simple make use of the biography for location discussion

Fixed typo
I find it hard to think that adding structure of this kind within a single field is helpful.

My views are doubtless coloured by the fact that most of the profiles I work on are English. Places have changed their full names, but generally in the middle: so, for example, Abingdon, Berkshire, England (in 1750) might be Abingdon, Oxfordshire, England, United Kingdom in 2020. Putting both of these in one string is verbose and (IMVHO) unhelpful: "Abingdon, Berkshire, England; Abingdon, Oxfordshire, England, United Kingdom" does little to help identify the place or identify the people/events associated with it.

My view (and this is, I accept, the view of someone living in a place with rather little linguistic or political change) would be: "modern names in historical structures". I'm not really interested in minor (or even major) spelling variations from past records. So it does nothing for me if people write Bensington for Benson or Stadham for Stadhampton (two Oxfordshire villages that have changed their names.) It hides information if those "historic" names are used, but it can be worked around with categories if people insist. But putting Abingdon in Oxfordshire in 1750, 1850, or 1950 does seem to be a historiographical problem: the problem being that if you don't understand the historical structures, you are unlikely to understand the records associated with those structures.

Of course, political and linguistic changes are real and do have real implications that need sensitivity. So I understand the general adherence to "their names". I would be very inclined to leave things as they are.
This seems even more confusing to me and I'm sure will cause additional suggestions to be developed.
Natalie: I suppose my reason for supporting "no change" rather than " I have a better idea" was I didn't want to cause additional suggestions.
... but I will add one more reason for no change.

There are lots of alternative text we might present (including GPS coordinates). I am frequently confused by localised historic country names with which I am not familiar. In order to provide translations, it is a common practice to store one string and use that to look up alternative, translated, versions of the text. Would that not be a more effective way of dealing with this: no need for an indefinitely large set of database fields; just one translation for each place name string, lots of presentation strings could be provided. It would still mean no change to the existing field.
Building in extra logic or meaning to data fields is a really bad idea no matter how well-intentioned.
+13 votes
If you are unsure or want to offer some modification to the proposal please vote here.  For changes please add a new answer.
by Laura Bozzay G2G6 Pilot (824k points)
@Leandra and Laura: I could add more confusion to the Silesia-topic, but Silesia was Prussian only from 1742 onwards. Before that, to be exact from 1526 to 1742, it was Habsburgian, so it belonged to Austria. And before 1526 it belonged to Bohemia.

To add to Aleš' comment: My Serbian grandma was born in Austro Hungary, got her second child (1920) in the Kraljevstvo Srba Hrvata i Slovenaca. The next child (1928) was born in the Kraljevina Srba Hrvata i Slovenaca. My mother was later born in Belgrade, which belonged to the Kraljevina Jugoslavija which was ended by surrender to the German occupation in Apr 1941. Then there was founded still during the occupation the Demokratska Federativna Jugoslavija which was succeeded by the Federativna Narodna Republika Jugoslavija. In 1963, the country got a new name: Socijalistička Federativna Republika Jugoslavija which stayed until Slovenia, Croatia, Bosnia and Macedonia got their independence. And in 1992, the two remaining republics of the SFRJ founded the Savezna Republika Jugoslavija. Only in 2006 the country got its current name: Republic of Serbia. And the Belgrade part of my family always lived in Belgrade.

To anyone who is interested in history, this is a story worth telling. The children within a single family were all born within the same house but a different country. The upheaval and rapid change the family would have experienced is lost in a location field.
And still, the ADDITIONAL modern name in the location field makes it easier to look for a town. Remember, the proposal is NOT to kill the historical place name, but to facilitate the possibility to find the places TODAY.

And no, my family did not experience much upheaval. They lived for 47 years in one house, moved then to a flat in the same street and lived there for 49 years. Only two years ago my relative moved out there in another flat nearby.
One doesn't have to move house to experience upheaval. With the country changing so rapidly, so too is the government, and the way people are required to interact with the government. Many laws are changing rapidly too as different nations take power.

Sorry, but from FRNJ in 1949 to 1980 there was only one leader in Yugoslavia. It was Josip Broz Tito. The changes until 1990, when Slovenia as first of the republics got its independence were only bureaucratical ones. 

got its independence were only bureaucratical ones.

Why is the above text showing up in this light color? 

I don't know
It was pasted from some web page with style. To make it a normal text, select it and click Remove formatting button (2nd from the end) while editing the post.
Leandra you entered the Thorngate Prospect response under comments at the top
+14 votes
I want to delay a vote for 90 days.
Speaking for myself, I like this proposal to bridge historic locations with modern names.
Yes, it works for me but there will be many different contradictory cases. I'd like to spend 90 days listening to the problems before casting a vote.
by Steve Thomas G2G6 Pilot (117k points)
24 hours after my request to listen. I've seen some great comments.
90 days seems like a long time.   Most of these go for a couple of weeks and then are closed down.  For the tech side I would defer to Ales and the Tech team.  I have total confidence they would figure out how to make this work or Ales would not have offered it in the Data Doctor thread.
Normal is two weeks. The tech team could make this work but that is from an engineering perspective. From a usability perspective it still adds complexity that is problematic. The technical aspect is the trivial part of the problem.
Cheers Doug. You have hit a good point. The technical aspect is minor. First up is agreement about what you want.
Modern computers are wonderful for storing information, with huge capacity to sift and sort. My answer to the meaning of everything has been written before: "101010 (42)" In the proposed format to bridge gap between different languages. 101010;42
+9 votes

While I agree to the concept of added modern information in the data fields, current name of place is not the solution; GPS should be used. Here's a quick example, totally made up, but that will illustrate my point.

A profile for an ancestor was created in 2012. That ancestor was born in 1897 in Foedosia, Crimean Peninsula, USSR. As I enter the current location name (in 2012), I enter Foedosia, Crimea, Ukraine

But today, 2020, that current location name is incorrect, it should read Feodosia, Crimean Peninsula, Federation of Russia

Don't quote me on technicalities of the proper name of the location, I might be off by a mile or 2 or a year or 2. The point being that even TODAY, place names change. I was born in Verdun but today, that's Montréal... and I'm not that old. Place names will always change. Wars, political events within a country (or state or town), etc.

Therefore, GPS coordinates to indicate location today is the way to go. Those will never change!

Edit to fix a typo

by Andréa Boudreau G2G6 Mach 6 (64.0k points)
No, where do I do that? What would prompt a user who is unaware of the policy to change the language?
If you go in Edit-mode the "Language" field is just above the Birth Date field. There you can change the language of the profile.
Jelena, I know I don't have to use the suggestions on the drop down list. My ancestors were in locations that are not on the list at all. I have no yellow box in the top right corner advising that I don't have to use those names. None of that negates the fact that when people are presented with suggestions, and they are unaware of the policy, it is very normal behaviour to go with the suggestions. I am not the slightest bit surprised that people are confused over location names. This proposal will add to the confusion. It is human nature that people try to use apps without reading all of the associated documentation. Even if they do read it, they may not remember all of it.
Isn't it better for a profile to have a location at all (if I have a clue of where a person was born or died) than to have no location because "Urgh, I don't know what the correct location is for the time when my relative lived, so I better don't type in anything at all."? I think it is, and this is why "Edingen, Hesse, Germany" is better than no location at all. And just this is why I favor this proposal. Yes, to type "Edingen, Hessen-Nassau, Preußen, Deutsches Reich" for a profile of 1873 is the ideal, but the (WikiTree-)world isn't ideal. I still think to allow both versions of locations (historically correct and modern) is an improvement. As Laura said, it is mainly to fill the location fields where people shy off of filling the location fields because they don't know what the correct historical version of the location is.
Ok I have found it now. I have never encountered any questions or instructions about this field before. So I clicked on the help button and it took me to this page. https://www.wikitree.com/wiki/Help:Language_Selection

After advising that the preference is to use the name that was in use at the time, in the person's own language, just below that it says

"Don't worry too much about which language to use".

I now realise that I have yet to see a profile for an Australian Aboriginal person that uses the Aboriginal name for the location.
I think some cases are better explained in the biography because a meaningful explanation will not neatly fit into the location field. What should be used in the location field for the current name when the place no longer exists?
then you use only the historical name ending with the semicolon and don't write anything else after it. This is now an analogy to the only use of modern place names starting with the semicolon.
I really like the idea of having lat/lon available in addition to the place naming options, either as a separate field or in the current field. My great-grandparents were married in a chapel that has been knocked down to build a new road. The chapel and road it was on no longer exist. The current pin next to the location field just takes you to the town, but I would like to record where in the town it was. Lat/Lon would let me do that.
But following the discussions I see there are around a dozen versions which all show different results for the same location. This would cause even more confusion than simply using "historical location name; current location name".
In my mind the user would enter the name.  Then following the example of Wikipedia the system would display the coordinates in a standardized format.  That display could be next to the field or on the map it would also trigger... map would still be accessed by clicking on the map toggle.
+1 vote
NEW OPTION USE GPS INSTEAD OF CURRENT LOCATION  iF YOU LIKE THIS VOTE YES HERE.IF NOT THE ORIGINAL NO CAN STILL BE USED.  IF YOU VOTED NO ALREADY YOU NEED DO NOTHING. IF YOU WANT TO USE GPS VOTE YES HERE.
by Laura Bozzay G2G6 Pilot (824k points)

I don't need examples I have German (well I guess they would be Prussian) ancestors I know the struggle. This question isn't about function it's about format. Many of the place names where this would be most beneficial (and I fully agree it is beneficial) are long, the separation of the two places with a semi colon makes for a messy and distracting appearance which is why I commented and voted under the no section.

My response specifically about the coordinate option isn't about it's merit. Let's have a way to enter coordinates and have a backend function that can group profiles by location and search by geographic area. Sure there will be some slight errors with the actual coordinates and a lot more human error in the inputting but it should be a function. 

In the formatting aspect though I don't see it working. How does going Oldenburg, Prussia; 53.255815, 8.095072 help the standard user. While I know how someone going to enter coordinates into it would work (clearly I just used a real example), the question becomes how would another person know to search for them?

Nearby coordinates would be 53.260591, 8.047873, it's not far away but will the search know that? What is the threshold? Plus most of the people giving the feedback right now are the diehards; the standard user simply fills out the profile form and doesn't know anything about formatting. We hope they read the guides and become diehards but we also aren't holding our breathe.

As a site function geo tagging should 100% exist and have integrated functionality but coordinates shouldn't be entered via the location section after a semi colon. That is what I don't see working.

Exactly why the first pass was to use a modern name.  We can define modern as 1900 on as most of those locations are assigned to coordinates.  Wikipedia is an example.   In my mind the coordinates are a back end process.   If that is what people want to enter, ok they go to the look up table and presto the current name is displayed.  Maintenance would be a function of the database used.  Just like shippers use now.   Many of those are a modest cost or in shareware from what I am told.  What my intent with this proposal is to allow the use of the name they used and another name be it coordinates or modern name that function together.  Display would be the name not the numbers but the numbers could also be displayed if we decide we want that just like Wikipedia does today.  There is a little map link now.  My thinking is that the coordinates would trigger the map to the right location. My guess is that most of the place names used in WikiTree are within 25 to 50 miles or kilometers of where the  family actually lived as many of the records are church records and not birth records.  Churches were scattered.  People who lived in cities are going to be a bit more accurate than rural ancestors.

Leilani,

I couldn't agree more. Let's say that someone types in a coordinate of where one was actually born, and those coordinates do not match with a city or place name. Also, if someone just transposes two numbers after the decimal point, it could end up being a long ways off. I was born about 7 miles from where the coordinates for my home town fall. In your example (Oldenburg, Prussia; 53.255815, 8.095072) if you transpose just two digits to 53.255815, 8.905072, you end up 30 miles away. And then there's Mercy Prence, who I just stumbled upon (I will leave this for a few days before I fix it).  She was born in Plymouth Colony... but not where the location icon indicates. I wonder how many people have looked at this and never noticed. Obviously someone picked the wrong Plymouth from the dropdown, but still, people are human and we all make mistakes from time to time. Someone not familiar with places may take those bunch of numbers (26.0324874, -80.1494317) as being correct because they may not know any different.

EDIT: I stand corrected.... This is a Google Maps issue...This apparently is still an issue with the location "pins" for historic locations. Apparently if Google Maps doesn't have a current equivalent place name, it will default to a place close to the user's location, or even say it cannot locate the location such as with "Wampanoag Tribal Lands". As mentioned in the original post, Plymouth Colony, as well as several other locations have this issue. See more at https://www.wikitree.com/g2g/949590/plymouth-colony-shows-up-with-incorrect-google-map-location?show=949590#q949590

With using GPS coordinates, I am mostly worried about the various notations. Template CategoryInfoBox Cemetery has a possibility to enter coordinate for the cemetery. You can have a look at what was entered here in column U https://docs.google.com/spreadsheets/d/11XXJMy5-pN6rHJ2Tnx5pIi1cJ1LZR9ufJ90XJu9rZMg/edit#gid=76606774 A lot of these coordinates are copied from FindAGrave so the mayority is formated the same way. 

42.7924995, -88.4689026

But some aren't like:

Lat: 41° 53' 30"N, Lon: 72° 40' 22"W

489,326,858,263,075

2490075

41 deg 24 min 5 sec N Lat. 90 deg 45 min 46 sec W Long.

Latitude: 38.6306, Longitude: -80.8628

N 32° 55.481 W 107° 19.212

N 36° 14.633 W 104° 15.536 / UTM: 13S E 566584 N 4011253

After correcting locations almost all week, I cannot possibly imagine how 250K+ current WikiTree members will put in a GPS location when we can't even spell countries (or their abbreviations) or states/provinces correctly.

Yes you are correct Ales, These are all different ways to express location coordinates. One of the problems with decimal degrees for example is that they are often expressed as 42.7924995, -88.4689026, but could also be 42.7925, -88.4689 (less accurate) or even 42.7925, -88.4689026 depending upon who listed them out initially and the way they are "rounded off".  One of the big problems people have is converting Decimal Degrees to Degrees, minutes, seconds (Lat/Long), or as in your last example Decimal degrees/minutes. 

UTM is another whole animal of it's own and is a bit difficult to teach correctly. The "E" stands for Easting and the "N" stands for Northing The numbers indicate how far within the 13S You go to the east, and then how far you go to the north. The more numbers, the higher the accuracy. If I remember correctly, the six digit numbers for North and East take you to a one meter square.

I'm wondering about this:

"Requests for an additional field have gone on for a while.  And honestly, I doubt that is ever going to happen."

Why is that? And it's a serious question on my part.

If you go back through a number of threads on G2G (I included some of the ones in the opening to the proposal) you can see where this concept in one form or another has been discussed, and discussed, and discussed.  So given the fact that a new field will require more back end work from what others have said, it seems to be the case.  If it was easy to do I would think with the number of times it has been brought up it would have been done.  You don't see a lot of new fields being added to the profile page. So the past points to that speculation.  I would love to be proved wrong.   I would do a happy dance if I am wrong.
Then perhaps a proposal specifically suggesting an additional place field for each event (birth, marriage, death) needs to be brought forward. If it garners enough attention and approval from the membership, then the Tech side can advise if it's feasable.
Reading Chris's response on this thread I think he is getting with Ales to look at the issues and the possible solutions.  

I was going to give that a chance to happen then ask if we should do a synopsis of this or if they have decided on a course of action.
+7 votes

While I like the idea overall, there are a few issues that need to be discussed. I'm a firm believer in the KISS rule (keep it simple...) And as I have seen in many of the answers and comments, many people are overthinking this.  Instead of using what you suggested, I would go with Original Location Name ; Current Location Name. This simplifies the argument of what is considered "Modern". "Original" location would be at the time of birth, and "Current" can be described as at the time you create or modify the profile.

I strongly disagree with those that want to use GPS or any type of coordinates in these fields.  There are just too many systems out there and too many ways to express coordinates.  Do you use Decimal degrees, Decimal degrees/minutes or Degrees/Minutes/Seconds? Does everyone know the difference between latitude and Longitude? What about using Universal Transverse Mercator coordinates? How many decimal places do you carry this out to - three, four, five....?  When do you use the minus (-) sign?  Is this from a handheld GPS, or is it from Google Earth? What is the projection for your coordinates (WGS-84, WGS-72, NAD-83, ETRS89, etc.)? GPS or Glonass?

As you can see, there are just to many variables that become very confusing to the average WikiTree user. And not everyone has access to the tools needed to get the coordinates correct. And then there's typos.... I don't know how many times I've tried to locate a place and the coordinates fall in the middle of an ocean!

If you want to include coordinates, I suggest putting it in the text somewhere, including how they were derived.

All in all, I think this could be a very useful addition to WikiTree, as long as we keep it simple and straight forward.

Hope this helps!

by Ken Parman G2G6 Pilot (117k points)
Ken to me the  current or modern names and coordinates work together like shippers use now.  There are extant look up tables.  So if someone enters the name it triggers the coordinates that trigger the little map link that is there now.  If they enter coordinates because they have them, it triggers the place name which displays.  There are ISO standards and that is what most people are using in any international setting.  So I think we can look to our Tech Crew to make a great decision of what to use to accomplish this.  I don't think we need to debate that.   For me the debate is can we change the style guide to allow if someone want to use it the addition of a modern name.  I define modern as from 1900 on as I think all of those have been tied to coordinates now ala what you see in Wikipedia.
Laura,

I just want to keep things simple for those that enjoy contributing to WikiTree, but may not have as much knowledge of coordinates and I do understand the little location icon on the profile pages. But this is done behind the scenes, and asking your average person to try to figure this out is just asking for trouble. Yes, a lot of people understand what coordinates are, but there's also a lot of people that don't. I am simply suggesting keeping this in the background as it is now.

As far as the modern era goes, I still recommend using the current place name over modern. If we agree that the modern times run from 1900 through today, there are several places which have changed four or five times during that period. So I could pick whichever one I remembered as long as it was in use during modern times. So as an example, I could pick Kiev, Kiyev, or Kyev as the city, and Russian Empire, USSR, or Ukraine as the country. That's why using the current name is the best and most accurate (as it stands today), and might make folks think about using the most recent convention. So the correct location for this example would be Kyev, Ukraine.
This is true. I never thought about the different formats when I previously expressed support for coordinates. I agree it would end up as a mess.
Just to play devil's advocate, here is an example from my own database of a location:

Was: Clapboard Trees, Dedham, Suffolk County, Massachusetts Bay Colony, New England

Current: Westwood, Norfolk County, Massachusetts, United States

Would you have all of this in the data fields?

Clapboard Trees, Dedham; Westwood, Suffolk; Norfolk; Massachusetts Bay Colony; Massachusetts, New England; United States

Agree, this could get quite long! 

Clapboard Trees, Dedham, Suffolk County, Massachusetts Bay Colony, New England ; Westwood, Norfolk County, Massachusetts, United States

And I'm sure there are longer ones out there...

In most location databases the word county is not included just like words state and country are not used.  New England is understood from Massachusetts Bay Colony. So you could shorten it a bit and still be understood.
+10 votes
NEW OPTION. Add new field to collect current or modern names.
by Laura Bozzay G2G6 Pilot (824k points)
This would be a good option but I think the proposal is getting  too complicated with too many options. I would suggest collecting the data and making a revised proposal next week once you've collected data and analyzed the comments.
I would like to leave it open for a day or two to allow some reaction to the two new options.
Ultimately I think this is so far the best option but it is not the simple solution that was originally suggested and would require back end work.
Laura, I think letting it go a week would be good.

There are always tradeoffs between backend work and usability. As a site that encourages everyone, I would think usability should take precedence over expediency. As a Mentor, I am always explaining some of the non-intuitive stuff we already have and some users never quite get it and just wander away. Adding more non-intuitive stuff won't help.

Doug a question...

If above the field it says:

Please enter the historic location name as shown in the records and if you want to enter a modernname from 1900 to present day insert a semicolon after the historic name and enter the more modern name that area is known by.   

Example:  Alsace and Lorraine were French then German then French.  So a name that was in Germany at time of birth or death would be written as shown below to show both version at birth and new version.   (I discussed French naming traditions with Isabelle Rassinot Martin earlier so am using an example from what we think we should be following.  )  

Sucht, Lothringen, Germany ;   Soucht, Moselle, France

So this display would quickly let a researcher know the person was born when Lorraine was under German rule and today you would find the records in Moselle.  

So if the directions are spelled out and an example given how is that going to be non intuitive?

Wikitree encourages the use of cousin bait. How will those cousins view a profile in this format? Will they instinctively know what the author was trying to do, or would they be confused? Not everyone is familiar with the history of these areas. I don't find that intuitive at all. If I already knew the different names for that location then I would probably recognise what all of it means, but otherwise no. There is a risk that WT is viewed as a mess by potential new members who don't know how the field is being used.
My guess is that most people being targeted by cousin bait are less familiar with the historic names,  Most of the Geni, My Heritage, and Ancestry and Geneanet profiles are not using correct historical names and that sems to be what most people are looking for...   so we are in the minority by having the use what they used standard to begin with.

I understand you do not want to do this.  It is clear.  But a number of your arguments just support why what we do now is not working well either.
It "might" help on data entry but then the same information would have to be displayed on every location field.  It is still a non-intuitive way to do things. No one thinks of locations in pairs like this. I also feel that the data entry screen is already too crowded.  A separate field that only appears when it is selected would be better. Then there is the public display. The same descriptive text would need to be above every location field. I say every location field because they aren't all always there.  On really long locations the display would potentially wrap  over 4 or 5 lines.  

There are a lot of ramifications to making changes and they all need to be examined. Such changes ripple through other parts of the system.

For a user interface, the first rule has to be keep it simple. This is not a simple solution from a user perspective.
I agree that what we do now is not working well. That doesn't justify implementing a solution that clearly won't be a solution for all scenarios, and is also likely to create more confusion.
I agree with Doug. I have many years of experience teaching people to use software. The user interface needs to be kept simple, especially when the goal of the site is to allow people to just jump straight in and start uploading their relatives' profiles.
Just a thought... Would the use of aka (also known as) work somehow?
This is the right answer - much more intuitive than a semi-colon.
I feel that I should apologise to everyone that is still reading this and asking themselves: What's the Problem? Well, in some small corner of Wikitree world there's some people that are dealing with country border changes and language changes.

I agree with Ken and Ian. I'm used to giving a historic name like Bethanien then adding a modern name (also known as Bethany) in brackets.
+2 votes
NEW OPTION ADD SPECIFIC PLACE IN BIO TO COLLECT CURRENT OR MODERN NAME

Suggest we use just under or above == Biography == A new section == Current or Modern Location ==.  Name of location most likely thought to be that place is entered first  in brackets.  Then, after that any explanation can be added.   

Hopefully this is able to be searched and parsed.  I will ask Ales.
by Laura Bozzay G2G6 Pilot (824k points)
edited by Laura Bozzay
There is a small problem with this option in terms of searchability. I used an earlier of example of Oldenburg as a place name, well it also happens to be some peoples last name and there are many other examples of this. So if you are trying to find profiles connected to just the place you don't want to get bogged down with results of people who have the name.

A location search field works because it is limited in scope and isn't including information entered in other fields but by adding additional location info in the body of the profile you don't have the same limitations.

It's a great place to put all the information that can help other people in their research but not as helpful when it comes to a basic search.
My concern with this option is that it will never get done.  And that means we continue to have issues for our international members that are not getting addressed because people who don't need it oppose it.  

There is never a perfect world and I was hoping people who are not affected by it would allow it because it is wanted by people who are having issues without it.  

The searchability function in the bio has its own issues and is not as specific on the search form as data in a field.  That is why Ales came up with the semicolon solution.  Because it works with computers, uses a specific data field, and it can be parsed and data mined.   

We have people who are not entering people into WikiTree because they can't figure out the locations as they were used by their ancestors.  So ultimately it becomes WikiTree's loss if we continue to not listen to needs being expressed by non English speaking groups.  

We saw this as a way to get something into the field so people researching could have a fighting chance of looking in the area the person creating the profile believed their ancestor came from.  It is no more problematic in accuracy than what people are entering today and may improve accuracy because of the plethora of duplicate location names in some countries.

Can there be errors? Of course, humans make mistakes, but if they know their family came from what today is called Germany but then was called France or Austria or a Duchy name, it still helps modern researchers.   Or if they think their family was German but that location is now Poland or Hungary or some other place, having the modern name helps.  

Really just looking for a way to help people who are struggling with border and name changes that happened so often it is daunting to even try to determine what they used.   And most of the old records I have seen do not include a full name of a location.  I have yet to see one that says Holy Roman Empire in any language although that extended to 1806!  Church records rarely stated the country or the county or region.  And you can't assume because the record is in say Metz that is where the people lived because church records for towns close to the German border were filed in Metz prior to Moselle being created.  

This is not about people being lazy and not wanting to research.  It is about areas that had such turmoil that the research is extremely hard to do to use what they used.  So what we want is the option to use a more current location name in the hopes of being more accurate for knowing where to continue to research.   Putting that in the bio field does not work well with search engines that are going to display the name field that includes a location name the researching person has no idea is what they used.  Most people who do genealogy are not professionals.  They are people who just want to document what they know of their families.  Most of us are not geohistorians.  Some of us spend a lot of time researching these things and we know from experience it is harder the farther you go back.
This would be possible only if it would be entered as a Template. Like

{{BirthPlaceModern|Ljubljana, Slovenija}}
Thanks Ales,  I had not gotten my email out to you yet.  You saved me that step!

{{BirthPlaceModern|Ljubljana, Slovenija|Q437}}

This is an interesting suggestion, but many profiles have multiple locations e.g. for Birth, Marriage, Death and various residences. Would they all be grouped under one == Location == header?

An existing practice of original location with current or more recent name in [square] brackets wherever appropriate in the Bio would also be the same as widespread editorial practice for textual documents. I prefer this.
+15 votes

I think it's clear from the course of this conversation that there really is no easy solution to this issue.

Our community seems to have come up with a viable method that works fairly well to tackle the complexity of naming places, though: 

  • Enter what you know about the original location name in the location field. 
  • If the location has changed over time, explain it in the biography. (And maybe take advantage of our One Place Studies to add even more insight.)
  • As more is learned through research and additional sources, the location field can be modified and made more accurate, as can the description in the biography.

Education of our members is key and we are all given plenty of opportunities to learn how to use a field. The help symbol  is given very clearly next to each field, and we need to encourage members (new and old) to use the information available.

Incidentally, the Location Fields help page gives this additional helpful tip: 

If you're unsure of the name in the native language, look it up on Wikipedia. Every place page will say in the first line what the name is in each of the official languages of that country,

Anyone can use that tip to refine a location that has been entered incorrectly on an Open profile.

Finally, as those who are frequent flyers on WikiTree know, we are always going to have members with varying degrees of interest, different availability of time to invest, and different levels of skills. We need to accept what a member has to offer, and those of us with the interest, time and skills can improve on it if needed.

ETA: Corrected attribution for Location Fields Help page content.

by Julie Ricketts G2G6 Pilot (481k points)
edited by Julie Ricketts
Where did Chris come up with a solution? I can't find that post.
Jelena --

I should have phrased that as "the community," but Chris wrote the Help page: https://www.wikitree.com/wiki/Help:Location_Fields#Location_Field_Style_Guide

I've corrected my post.

The standard of using "their conventions" has been around since 2012.
Julie, I know that "their convention" is the standard here. What we want is an *additional* possibility to *also* type in the current name of a town, because that would people give a possibility to fill in a location name *although* they still don't know what "their convention" was. In Germany there are so many little duchies that I often have to check German Wikipedia, and it often takes more time than only two minutes and overread the current article. As I said further down in the thread, to have someone type in "Edingen, Fürstentum Solms-Braunfels, Heiliges Römisches Reich" for a profile of 1762 or as accepted but not desired alternative "Edingen, Principality Solms-Braunfels, Holy Roman Empire" would be ideal, but in the not ideal WikiTree-World even "Edingen, Hesse, Germany" in a former empty location field is an improvement.
I share a similar view to Jelena. The proposal to also add the current location is very useful to me. It is very convenient for me to use the attached pins at the end of the location guides. They serve to follow quickly an individual life story from birth, marriage to death. They are very handy to compare quickly the localities of people that may have lived closely to each other. Having this information accessible at the top of a profile is much better than burying it inside the biography.
If you want to see who lived close to each other, you can obtain that from the old names.
Sorry Leandra. Old names don't work for me. The old names are hard to find in my example. The country borders and languages changed. That is exactly why I like a pin to the current location name at the top of a profile.
I can see what this proposal is trying to get at and why. That makes sense to me. Locations are confusing as hell in some places.

But for me at least I have a few qualms.

1) I think it’s messy and could be quite long and I like the cleanliness of a separate field with its own explanation to keep things tidy.

2) for new users, casual users, visitors it could be confusing. From what I’ve seen on the web this would be a very unique format. We have many issues to start with in getting location fields correct, I don’t think further complicating requirements will lessen errors.

3) if it’s optional and only some people use it the inconsistency really irks me that some profiles will have these long multiple location fields and others won’t.

That’s my rather anal two cents haha.

thanks very much for putting forward the proposal!
+7 votes
I probably don't understand the ultimate goal of your proposal, but it seems to me you are wanting some sort of back-office database/coding that can match the old location names to their current names so we can find them using the map icon. Perhaps we already have that, to some extent. But I would expect the "mechanics" of such a feature would be solely at the discretion of our Tech Team and would not require a change to our current location-field guidelines.
by Lindy Jones G2G6 Pilot (253k points)
Thanks Lindy. I don't really understand the goal. I'm quite happy that with the Status Quo. The existing system works for me. I can write the historic location for BMD as I see in my family records then with a semi-colon divider give the current name and map pin to the location. What is the problem that needs to be fixed?

The current proposal is to make official the use of a method to distinguish historic from current place names and so far the options are

In the location field:

  • historic place name ; current place name
  • historic place name ; coordinates
In the body of the profile
  • subsection ==location== followed by a place template {{BirthPlaceModern|example}}
Or to add an entirely new location field for current place names.
This is so users can search using either name and then the right profiles will show up in the results. Steve if you are already using historic place name ; current place name just know that most people are not as it is not an official recommendation and this proposal is to make it official.
Yeah. But, something has been lost in translation.
Thanks Leilani, yes that is where we are at the moment.  It came out of two different discussions.  One was in the Data Doctors and the other in the Germany Project. The discussions were not about the same thing but had similar overtones.  Ales indicated that using a semicolon works with computers and is able to be parsed.  The Germany Project has a real need to have current names as an option.  Some of these places changed names so often even very knowledgeable native Germans have trouble figuring it out.   I saw this as a way of helping with the Germany issue and it would also help with other areas of the world that experience a lot of location name changes.  As I said above (somewhere) I was going to leave this open for about a week and then do a synopsis. But you have done a good job of where we are.  The only thing I would add is that we would do this for Birth, Marriage, and Death.  So if we create a Location subhead and use templates because Ales said only templates would work, then we would need one for Birth as shown in the example, replace birth with Marriage and then with Death to cover  other events.
Hi Leilania and Laura,

Can I take a few paces back to ask again "What is the problem your are trying to fix?"
Hi Steven,  We have areas of the world where it is very hard and some people even say impossible to use the required "use what they used" because the names change  so frequently and there are not good resources for what names were actually used by them.  

One example is what we call Germany.  And if you have paid attention to the nationality of those advocating for this, members who deal with Germany a lot are saying we need this.    

In a moment of interesting synchronicity, there was at the same time a discussion in the Data Doctors about issues with locations and what should and should not be allowed in terms of moving things to suggestions.  Several members gave examples of what some projects are doing because of the confusing naming patterns that exist where they live.  So Ales made the comment that inserting a semicolon works with computers, would allow a user to set off for searching because it can be parsed, any changes you would make to a field like a location.  In fact if you go back through this feed he gave an example of how this would help in terms of where he lives.  

The idea is that this would be an option for those who are saying we have a problem and the current direction does not solve our issue but complicates it.   

Recently I had 2 people from the same country, both with a great deal of knowledge and both with sound reasoning disagree about what an area should be called at that moment in time.  Both were also natives of the area.   So even highly educated natives are having problems because where they are living the names of where they or their ancestors lived changed so often it is very hard to know what that location should be called in a moment in time.  The actual records do not reference a region, a country, a state or province.  You are lucky if you get a town name..  And most of these records are written in Latin and are church records.  It is important to realize that churches were not in every town so often people travelled a great distance to have a child baptized.  So town name is not really where they lived.    

Take the name Neustadt.  Today there are over 24 of them in what we call Germany.  Remember that Germany as a country did not exist until 1871.  Up until 1806 it was a series of kingdoms or duchies under the Holy Roman Empire with a few banding together to form unions or Confederations that came and went.   So the modern names have tried to differentiate which Neustadt it is,  That would help a researcher know where they actually need to look for records..

Using what we have now works for a great many people and they see no need to change what we have.  But I believe the group saying we can't do this or it is really hard and it stops people from joining and using WikiTree.  I know for a fact many of my own European cousins prefer to use other sites because they allow modern location names and have generally fewer rules.   Believe me I have tried to get them to join us here because these are generally college professors, town historians, genealogists who work within cultural heritage institutions.   One of them I finally got to join is the President of a UN World Heritage site.  And he understands why people are asking for this ability.  He is the author of several genealogy books and has given lectures at many museums and libraries and well known businesses.  He has said to me, to  really research in Europe you need to know where someone lived because the records are not centralized.  You have to go to the small towns.  If you have no idea where that is you can't research your relative.  You need to know what the record itself says but also where that is today.  

So I do not think the people asking for this are making it up or making a mountain out of a mole hill.  They say they need a way to collect both names and I believe them.  So when I saw what Ales said I took that idea back and said, would ths work and they were enthusiastic about it.  So I posted it.  As other approaches were given I added those because I am looking for consensus of what we might be able to do.  

My intent is to leave this thread open until Sunday.  Then close it.   Digest what everyone has written and as Doug suggested post a new one.  

So that is the history...   

In its simplest form the problem is...  

We need to find a way that allows a modern location to be picked up easily by a computer for data mining.  This does not equal a simple text search in the bio area as some suggest.  Ales who is one of our Tech gurus here said the only way that would work is to use a template.   Members are using a free form field that allows them to format it anyway they want and do narratives about locations.  That works for one use but not as a field used for parsing data.  
Does that answer your question?
Thanks Laura for all your efforts and explanations.
I have a bit of German ancestry and understand a need to have a link between old location names, as found in my family records and modern location names which can now be in a different country with a different language.
You have answered my question "What's the problem?" in your last paragraphs. I've found the current system workable with a semi-colon. It's given me what I need, so I didn't really understand why the existing system needed to be changed.
I don't use Wikitree for data mining. That probably opens a whole new set of challenges which I was ignorant of. I now understand the need to make a change to this system but not any clearer about what to. I thought the semi-colon bridge was easy to understand, but there's a good number of votes saying "No" it's too complicated.
The use of the semicolon would be new.  It is not part of the existing system per se  It is a work around since there is no new field to capture alternate names.  I say alternate because it could be a name that is current or modern but essentially a name we can tie to standard map coordinates. Once can more or less put a pin in a destination it does not matter what you call it going backwards or forwards in time because it is a marker that says this is where I am no matter what you call me.
+4 votes
I support this proposal. I think this will solve alot of the current issues and confusion around location fields and whether to use old location names or current. Thank you Laura. And all others involved in discussions leading up to this proposal being presented to wikitree's g2g. Awesome job!
by Kylie Haese G2G6 Mach 8 (88.0k points)
+6 votes
Keep it simple

Adding ; ( {  [ all cause confusion in the search engines when looking for sources

Ales is already working on improving the 'location suggestion' in the menu's let's see what comes up

The biography is the best place to put discussions on locations, where both the then and now can be shown and GPS coordinates added.
by Janet Wild G2G6 Pilot (329k points)

Good.  Thank you, Janet. The location suggestions, as they are now, in the data section of person profiles, for the USA, need to be corrected.  For instance, there has never been (historically) a Greene, Tennessee, nor a Greene, Missouri.  They are now Greene County, Tennessee and Greene County, Missouri.  Historically, each was another named location.  So the question on WikiTree genealogy is where to look for the records today?  So I'd like to use today first; yesterday second:  Current Location Name; Original Location Name.  So Greene County, Tennessee 1796; Greene County Records and Greene County, Missouri 1833; Crawford County, Missouri.  But, only if the historical location 'must' be a part of the click and select.

In summary:  It is not to be lost in my wordiness that dropping the word, County, in the place name in the USA is inaccurate, both today and yesterday.  So please fix what you've got going-on, before adding more to the mix.

+24 votes
Complexity scares me more than it does Ales. Every year WikiTree gets more complex and I long for simplicity. For me, for the infrastructure we have to support, for members. Increasing complexity is almost inevitable in a system like ours, and I am resigned to some, but still I fight it when I can. :-)

Technically speaking, this change would mean adapting our systems for displaying profiles and editing for them, for creating new profiles, for matching and merging them, for comparing and creating through GEDCOMs and WikiTree X, and more. Every system would need updating and would get just a little bit more complex. I also think it would mean taking WikiTree offline while we rebuild the database to allow location names to be longer. This might seem like a small thing in the long run but it's more daunting than most people might assume.

Even more significantly, this might affect, or at least its effects should be considered, in every single place we display a location name. Is the user seeing an old or a current location? Do they need to see both? Do they know which one they are seeing? We'd have to think about this for search forms and search results, index pages, lists, family trees, a ton of display widgets, independent apps using the API and database dumps, and more.

Users would have to understand what they are entering and why. Some new users already have a hard time understanding our historical location names style rule. This would not make things easier to understand. Once over that initial hurdle it might be easier, but that initial hurdle would just be a little higher. (The hurdles a new user faces when trying to understand WikiTree are already very high.)

Some years ago we developed a plan for tackling the issues related to historical place names vs. current place names and location name normalization. Despite its disadvantages we decided to use FamilySearch's Place Names database. It has historical place names with corresponding geographic coordinates. We decided that if members started using the FamilySearch style we could later translate those into current names and coordinates where necessary. It could be done in various places, on the fly or in batches, and eventually used for matching. We didn't know exactly how that would work out, but figured it could be worked out. We haven't fully worked it out.

Many people don't know that even though Ales is a team member most of his work is completely independent. Frankly, I do not understand what he has been doing with place names in regards to normalizing them for his Map Navigator. Ales is a genius and mapping is his professional specialty. I don't presume to know a fraction of what he knows about this stuff, but he and I will talk. Maybe there is something more we can do utilizing WikiTree's relationship with FamilySearch.

By the way, many years ago, when we first started WikiTree, we left room in the database for geographic coordinates. But we have always decided against using them because maintaining them manually and collaboratively alongside manually-entered place names would be too confusing for users. We decided it would be better for us to automatically translate the place names using FamilySearch's database.

Some less ambitious style changes we might consider: We could clarify that if you don't know the historical place name you should enter the current name. With almost everything on WikiTree, some information is better than no information. Then, when you or someone else can add the historical name, you should. We could pair this with a clearer recommendation on when/why/how to explain the location name and how it relates to the current place name in the biography.

Chris
by Chris Whitten G2G Astronaut (1.5m points)
Honestly, even the "less ambitious style change" is better than nothing because it gives people the opportunity to enter at least a location name at all, even if they don't know the historical entity it belonged to. That is especially important for Germany, as we had so many different and small entities that I partly never heard of and only get to know them while I wander through the German Wikipedia trying to discover where a particular town belonged to. So yes, I support the small change. It's better than nothing.

@ Chris - re "when we first started WikiTree, we left room in the database for geographic coordinates. But we have always decided against using them because maintaining them manually and collaboratively" - FYI, I am close to releasing an mapping app (currently added onto Ancestor Listmaker) that uses that approach - ie a location coordinates database collaboratively built by app's users. I'm planning a soft rollout. I'll send you the link when its available, so you can take a look.

Chris, even for those of us in somewhere like New Zealand, the FamilySearch dropdown list is not necessarily helpful because there is no indication of a timeframe. Historically, getting the town right is easy; more detail requires research and sources themselves are not always foolproof. I had wondered if a less ambitious style change could be a radio button with the option of historic or modern name as it might be easier to implement and be more accurate.

I almost always use FamilySearch's Place Names database as with a one name study there is no way I can follow all the different rules from all the different projects, let alone all the changes in historical names. I believe and hope as Chris said later they will translate those into current names and coordinates what ever may be decided. If I get the time frame wrong, that should be able to be corrected in same process from dates that are given for the event. Then everything will be automatically corrected if that happens. Great solution if it happens!!

I did an experiment on a profile without a PM.  I changed birth and death locations to the accurate place names.  Then I checked RootsSearch, FamilySearch, and the results were the same as before, when I used the truncated location names.  It seems FamilySearch can translate the place name with County in it.  Then I checked maps and voila! lovely.

First I changed United States to USA (working right to left), which then left enough room to add the word, county.  I know how I would tackle a database with search/replace, but then I also know I'm not the smartest rabbit on the planet.
Thank you Chris it is good to know all the facts.  The proposal was meant to get all the issues out on the table and I think we did that.  

I have always believed that the coordinates are better as a backend process.  Sounds like some people are working on that.  Which is great news.  

The Family Search Locations are not always historically accurate.  I wish they were it would make this easier since so many people use that as a source.  But I do think they are using something like Wikipedia is using that takes a location and converts it to coordinates.  Why?  Because I can enter a country that did not exist in 1600s and it works.  

This is all great information.  And small changes are still helpful.  Glad you are open to doing something that does not affect the entire system but helps users who are delaying entering profiles because they can't figure out the historical place names.  Some of the areas of the world are easy others are really very hard.  Some areas are completely documented in Family Search and some are only partially covered.  Germany is a great example where some areas are well documented and others are not documented at all.  

Would it be helpful to you to see a spreadsheet we have been working on to try to determine the naming conventions for Germany through time?  It is in its beginning phases.  I am happy to send it to you  I did send a version of it to Ales but it is incomplete.  We have done the overall country, and 2 of the current 16 States.  

Also one of the comments in this long thread was to move the time period to the front of the display field or enlarge the field because some location names are too long to see the time period.  That is  adding to the problem.  

Thank you again for being open to the concept of finding a solution that helps those who are saying this is a problem for them.
Most folks haven't understood this problem.

There remains a problem to resolve, but I don't think a speadsheet is the answer.
Hi Chris,
I am late entry in the location debate.
GPS coordinates was never going to work. My questions were: 1) ISO traceability 2) Intellectual ownership and 3) what happens when satellites are shot out of sky?
My interest in geneology is a bit simpler. I have some family history, written in German. But it is still a bit complicated.

@ Chris (Founder and CEO):

2. OK.  So everyplace where I have typed-in the actual Historical Location (in the Data Section), I should change back to the FamilySearch name (with date), so when the update happens, the FamilySearch name (with date) will get updated.  Got it.  Then the actual Historical Location, as I would 'call' it, is added to the Biography (not to the Data Section)?  And, all this is under Promise #2:  Accuracy?

1. From this explanation (above): "Some years ago we developed a plan for tackling the issues related to historical place names vs. current place names and location name normalization. Despite its disadvantages we decided to use FamilySearch's Place Names database. It has historical place names with corresponding geographic coordinates. We decided that if members started using the FamilySearch style we could later translate those into current names and coordinates where necessary. It could be done in various places, on the fly or in batches, and eventually used for matching. We didn't know exactly how that would work out, but figured it could be worked out. We haven't fully worked it out."

Thank you.

I created a new draft of a policy page to clarify our policies on uncertain and modern location names: https://www.wikitree.com/g2g/1132377/almost-location-better-location-style-uncertain-modern-place

B. Britain, I'm sorry to say I don't follow what you're asking, but this may be helpful: https://www.wikitree.com/wiki/Help:Location_Fields#Place_Name_Suggestions
Apology.  I got the cart before the horse.  If you read what you wrote first, then what I wrote should make sense.

Thank you.  I see that teeny/tiny little pin icon now: "You will see a pin icon map.gif next to suggestions."  ...more treasures to explore on WikiTree!

+5 votes

Dear Laura Bozzay,

Thank you so much for this proposal.  You and all the people who gave considered thought uncorked a solution to the problem of where to put boundary changes.  Now 'where to look for (records of) ancestors' is under === Locations ===, under Biography.  Hmmm, maybe that should be Historical Locations?  So it isn't read as just another list of Residences?  Yes, I think Historical Locations.  And thinking continues, with appreciation to you, Laura, and to each and all of the other 'thinkers.'

Sincerely, B.

by Living Britain G2G6 Mach 2 (28.3k points)
Yes great idea.  Historical Locations would be better!

Related questions

+43 votes
20 answers
+13 votes
5 answers
+27 votes
11 answers
+25 votes
11 answers
+40 votes
14 answers
+16 votes
3 answers
341 views asked Feb 5, 2023 in Policy and Style by Gaile Connolly G2G Astronaut (1.2m points)

WikiTree  ~  About  ~  Help Help  ~  Search Person Search  ~  Surname:

disclaimer - terms - copyright

...