Which brackets in place name fields are allowed?

Question

As we all know WikiTree is having issues with staying true to it's policy of keeping to historical names (i.e. Nieuw Amsterdam up to the moment that the city was renamed New York - just one of the countless), and the autofilling of place names on the creation or editing of profiles. A source such as Family Search will give the (birth) place the location of the repository and [modern day] province, whilst the actual location would be an old general administrative district such as Tulbagh, some 200 miles away. So when WikiTreers create new profiles, WikiTree automatically will select "Cape Town, South Africa". 

One issue with this is that as far as I know the first mention of this place was a 125/135 years after it's founding as a settlement. Until around 1785 it was known by a variation of names including Caep de Goede Hoop, the name now agreed on in our Dutch Cape Colony (1652-1806) project. 

When the actual birth place is before that date then (but also until the British 'officially' annexed the former Dutch colony and renamed the town Cape Town) de Caep de Goede Hoop, we have entered the following in the place name fields: de Caep de Goede Hoop (Cape Town), Dutch Cape Colony

We are phasing out the use of square brackets in location name fields, because they create data base errors. What is the policy on round brackets such as ( )? And if the use of round brackets is a problem too, what is the solution to the correct naming of historical place names in the data field? (I'm really only considering answers or suggestions of place data fields; any suggestions of explanation of the historical context of location names in tens of thousands of biographies will be disregarded - my concern is with the data fields themselves).

That is where we are having issues.

Answer 1

I believe the parentheses (or round brackets) also cause a data suggestion (error).  However, Aleš or Emma would be better able to address that error.

If the project has determined that the place name should be the historical name (current name), country, then you or someone else in the project could ask if this could be an exception.  That way, the suggestion (error) would not occur for profiles using that location and wouldn't need to be marked false error.  Aleš usually requests a start and end to the time period for using that location.  That way, any profile using that location outside of the time period would be marked in error.

Apologies to Aleš and Emma for causing them more work.

Answer 2

Perhaps a similar error report that is used for Northern Ireland, can be generated so that all the incorrect locations can be fixed - https://www.wikitree.com/wiki/Space:DBE_612

Answer 3

I was very frustrated by the historic locations as it was causing me unecessary work and difficulties in matching profiles. I am a bit more sanquine about it now. I consider that the proiles only use is as an indexing system nothing more. The historic addressing works but a location needs checking. If it doesn't nail down the location it is of little use. With a slight re think on the location you use can work wonders. I am checking each of my locations pressing the google link and seeing where it lands. If it's the wrong country or locality it really needs a rethink! For instance my grandparents marriage was in a church now demolished. Google landed somewhere totally different no where near where the marriage took place.a removal of the church name to the biography and replacing with the historic locality instead solved the problem without compromsing the idea of historic addressing. An index is no use if it doesnt work ! Most of the US addresses I have checked work out fine historic or not.  A heck of a lot of duplicates could be avoided if common sense prevailed.

Comments

Use common sense?    I don't think that's allowed.

Answer 4

I think an ideal solution would be to have separate fields for historical and current place names. But that would be a major change to WikiTree, and I don't believe the current/latest GEDCOM spec supports it.

Answer 5

Here we go again. This problem pops up every few weeks for a different country and is never really solved. The problem is really bad in pre 1900 middle Europe.

The solution (mentioned many times in the past) is to go to a GPS location with a look-up to the date/name. This could get it down to a street address or farm and show us what family lived next door. Would it not be nice to see all of the same sur-names in a 50 mile radius?

I've spent many hours correcting these errors in the past and come back the next month and there are more of the same errors created. So I have given up on this problem until a better solution is found.

Comments

"So I have given up on this problem until a better solution is found."

This seems to be a recurring theme - for many topics.  Is there some sort of a committee that takes these changes under advisement?