Language used for place names?

+10 votes
222 views
I notice that in profile "Arkel-27"; that Johan IV was born in Gorinchem, Zuid Holland, Netherlands

Zuid Holland is Dutch for South Holland.

Netherlands is English for Nederland.

I'm thinking all parts of place name should be in the same language?

I want to start adding my ancestors into WikiTree; but feel this question will need to be answered first!
WikiTree profile: Jan IV van Arkel
asked in WikiTree Help by Frank Bax G2G3 (3.5k points)

4 Answers

+12 votes
 
Best answer
Yes, all parts of the place name should be in the same language as we state on the location fields style guide here:

https://www.wikitree.com/wiki/Help:Location_Fields

Mistakes do happen! Many of us are monolingual and struggle to work in the languages of our ancestors. This is a great thing for our data doctors to tackle on existing profiles. I think the language selection field has been a great addition.
answered by Karen Tobo G2G6 Pilot (110k points)
selected by Rubén Hernández

>>You do not need to accept any of the place name suggestions. 

Problem not selecting from the list is then it will be just a text string with no connection to Family Search place db and GPS location etc... ==> difficult to locate it on a map....  ==> someone has to redo the work,.... when maps are supported....
 

It's true - it's definitely better to use the database and submit corrections.
Thank you for that explanation, Magnus.  I didn't know there was a further use for those dropdowns.  I almost always need to edit them, though, because they do not contain the correct country names over Canadian history i.e. Nouvelle-France, Quebec Province, Bas Canada).  Do the links still work if they've been edited?

@Cindy and then you get the problem

  1. Should the "correct name" be
    1. in the location box and you miss the connection to the Family Search name db
    2. should you take what is best match in the family search db
      1. and add the "correct" name(s) n the bio.....

Feels WIkitree need to agree on a direction/ update guidelines.... or at least be clear what the consequences are....

If Wikitree will support maps I guess Aleš can do some "bot" that fix most of the mess but not everything....

 

 

  1.  
What would be your suggestion be for a policy change Magnus?  I agree the current policy just causes more confusion than clarity.
+4 votes

Best would be support for all languages....

I guess use what is suggested from the Family Search Box is a good start

 

Languages fast gets complex so I guess Wikitree will not support all

answered by C S G2G6 Pilot (267k points)
edited by C S

Wikidata is now adding more tools to better support adding structures

Example

+1 vote
This seems as if it will be a never-ending battle until we add alternate data fields, i.e., "historical place-name," and "modern place-name."

The WikiTree guidelines state: "Applied to locations, this [use their conventions instead of ours] means using place names in native languages and using the names that people at the time used, even if they now no longer exist."

IMHO, knowing the historical place-name is vital. That's the canvas on which genealogy is painted: history, society, and geography. We need to know original place-names, their etymologies, and how those names and associations and political demarcations changed over time.

Conversely, telling me only a 13th century place-name as used at the time may give me no clue where in the world that place is today, and it certainly can't be used--among an almost infinite number of perturbations--for digital mapping capabilities.

I think Magnus has said this before: we need both. Two location fields.

It's not just that modern naming and geolocation and GPS gives us the ability to quickly find what we're looking for. Without that digital standardization we'll never move toward revelationary data: real-time heat maps of population density by surname; patterns of nuclear family movement; even ancient DNA-suggested ancestral habitats. All things critical to One-Name Studies.

Abandoning the original place-names, however, is something we do at the peril of our past. For example, I added a note today to Plantagenet-2 (https://www.wikitree.com/wiki/Plantagenet-2), Edward I "Longshanks" of England. The profile states the death as 7 July 1307 in "City of Carlisle District, Cumbria, England."

There was no County Cumbria until 1974, enacted by Local Government Act 1972. At that time the historic County Cumberland's former area was combined with Westmorland and parts of Lancashire and the West Riding of Yorkshire to form the new county of Cumbria.

I think we need it both ways. We need the oldest, most period-appropriate date designation, and we need the contemporary, most-approximate GPS coordinate.

We can do both.
answered by Edison Williams G2G6 Pilot (151k points)

What about "modern place name" and

"historic place name (if different)"

Or should that be "historical"???

Pat

 

The data field presently in WikiTree is intended for the historic place name at the time the individual lived, which ought never to change.  "Current place name" is going to change over time, so if a new data field is created for current place name, it ought to be keyed to the GPS coordinates so that when the current place name is changed -- as happens somewhere in the world every day -- the new name would automatically appear, because what's actually in the computer is the GPS coordinates.  If "current place name" isn't keyed to the actual GPS coordiantes in it, you'll never know whether it's truly current or not!

@Jack Day the family Search place database connect can handle

  • Historic names
    and
  • GPS location
    and
  • When it was valid.....

Blue is what you add in the WikiTree field and select from the list

Brown is what you find in the Family Tree place database 

 As I said earlier I think the WikiTree implementations UI could be better see G2G 508323#a508323

You wouldn't need another field.  You could put a pseudo-link in the existing field, eg [[Place: USA/MA/Essex/Salem]], or just [[Place: Salem-123]], and use it where available.

The simplest implementation would simply replace it with a display string for all purposes.

But there's no limit to what else you could do with it.
+2 votes
The place name in the data field should be the place name that the person in the profile would have used, and in the language the person used.
answered by Jack Day G2G6 Pilot (211k points)
That is what the recommendation is and it is one of the worst decisions made at the implementation of wikitree.  It creates a situation where people are insisting on names which are unintelligible to the vast  majority of wikitree users.  It defeats the entire purpose of the location field which is tell the reader where in the world something happened.  This is an area where common sense has been lost.
Joe, people have been born in places that no longer exist -- here's a list of towns flooded by reservoirs.  https://en.wikipedia.org/wiki/List_of_flooded_towns_in_the_United_States.  But they were still born in that town.  They weren't born in a reservoir.

I have come to the same conclusion as Joe.Far better to use as far as possible the modern term and then use the historic in the text. I don't think it really causes a problem  in the case of  desserted/no longer existing  settlements we would use the name that it is generally used eg https://en.wikipedia.org/wiki/List_of_lost_settlements_in_the_United_Kingdom ( I have 19th C direct ancestors born in a village on that list , no problem in finding it on a map as the location is given)

How about this  profile? https://www.wikitree.com/wiki/Toulouse-11

Hows your Occitan?

1) He should probably be called   Ramon (lo) Coms de Tolosa  https://www.s-gabriel.org/names/ramon/occitan/occitan_r.html

2) Born in Sant Gili? . Languedoc is a modern term so incorrect. It's between Nimes and Arles so probably just be at the edge of the County of Tolosa . (what's county in Occitan?)  https://upload.wikimedia.org/wikipedia/commons/d/db/Map_en_county_of_Toulouse_1154.jpg

3) He died in Tolosa

Unfortunately there are also towns called Tolosa in Spain, Portugal, Argentina and in Texas https://en.wikipedia.org/wiki/Tolosa

If we implemented the rules fully, it would add to confusion; and invetitably  duplication . (this profile  is probably the best amongst the Toulouse profiles I've looked at. The others are full of anachronisms, because many people don't know where the places are today, let alone if historic terms were used  )

What about if we go further?  The more elderly of my French neighbours speak amongst themselves in a Patois (in many respects nearer Occitan than French)  Their 19th C grandparents would have spoken little French and the villages would have been known by them with  their Occitan names.(some now have these on their town/ village signs) . An Averyronese Patois dictionary suggests that in 1851, out of a French population of just under 36,000,000, there were only 18-19 million that spoke correct French, 14 million spoke a form of Occitan patois, other languages spoken included 'German' and Breton.

https://archive.org/stream/dictionnairepat00lettgoog#page/n6/mode/2up

 

One of the causes of the problems in this discussion is the use of the display field as a data field.

If we had a separate data field accessible only in edit mode, many of these problems would go away.  Have a data field in edit mode labeled "GPS Coordinates or proximate modern town name"?  No problem.  Choose from a list designed by someone else?  No problem.  Do everything in English regardless of what langauge the person actually spoke?  No problem.  It's not for display, it's just to make the computer provide better service.

The problem comes when it is displayed as part of the profile, and someone is born in 1650 in Annapolis, USA, when the town at the time was actually Providence, Province of Maryland.  Or someone is born in the year 300 in London, Middlesex County, England, and you know that if they were born in that location in that time it might have been called Londinium, Britannia.  And if I'm going to take the trouble to work on profiles of that time and place, I should be willing to take the trouble to learn how THEY characterized themselves.

The stuff at the top of a profile is THE first impression that WikiTree gives to any passersby, and because we already use it to enter data for a variety of purposes rather than to be historically accurate, it already sometimes looks like crap to someone passing by.  The display fields should be historically accurate and present the profile in an attractive light.  Anything else should be reserved for edit mode, where what is entered can be designed to be useful to the computer, regardless of how it actually looks!
Good summary .....
But you'd still need to add a lot of place properties to person-profiles.

A place is an object and should have all its properties collected in one place, not repeated in thousands of person-profiles.

All you need to store in the person-profile is the key to the place-profile.
Why?  

I'm concerned with the historical accuracy of facts displayed on an individual profile.  It doesn't matter to me whether the entry on Profile A has any resemblance to the entry on Profile B, so long as both are accurate to the profile and give me important information about the person profiled.  

You would like to do various things with the place-fact, or have your computer do various things with it.  I have no problem with that -- so long as it is done in the back room.  Have a place on the edit page to add anything you want, to manipulate the data in any way desired, I have no problem with it.  

The problem is that we have information display on the front page which is actually serving as a data entry field.  So when I enter the information that I want to be displayed, you are actually trying to use that data and manipulate it digitally.  Silly you.  You need a data entry point for information that will specify what it is to be used for and what form it should be entered in in order for you to use it to best advantage, and that's commendable -- until you start telling me that my information display field, which is important to me for my purpose, is also doubling as your data entry field, and the information I'm entering is not useful for your purposes.

The problem is not with the way I want to display information, and the problem is not what you want to do with information, the problem is that we're trying to use the same piece of entered data for two quite different purposes!.
All you need is another data entry field that asks the question, what is the closest current location to the historical location?  Select from list."  Problem solved.

Joe, people have been born in places that no longer exist -- here's a list of towns flooded by reservoirs. 

This is why I said common sense has been lost.

All you need is another data entry field that asks the question, what is the closest current location to the historical location?  Select from list."  Problem solved.

Or you could enter a usable, recognizable and informative location in the data field, and give the obscure yet historically interesting name written in a language spoken by no one on this site in the biography.

 

As being Wikidata and semantic web addicted

In Wikdata we create new locations when old ones are not "good enough"....

  • A location is an object and can have
    • start date
    • end date
    • followed by
    • replaced
    • part of country xxx
      • start
      • end
    • flag
    • GpS coordinates
    • KML (standard to describe borders of an area....)
    • part of administrative unit
      • start
      • end
    • etc,,,,

You can also ask Open Street Map to show an object tagged with the Wikidata  ID ex.

 

Yesterday in Swedish Wikipedia I added a parish that was not valid when a person lived ==> so then we created a new Wikidata object and added relations to say that this parish was replaced by etc,.. link

Related questions

+12 votes
1 answer
206 views asked Apr 24, 2017 in WikiTree Tech by Mary Diamante G2G6 Mach 1 (16.7k points)
+9 votes
1 answer
+3 votes
3 answers
+4 votes
1 answer
188 views asked Dec 29, 2016 in Policy and Style by Jan Terink G2G6 Pilot (131k points)
+5 votes
2 answers
83 views asked Jul 14, 2015 in Genealogy Help by Rob Ton G2G6 Pilot (271k points)
+6 votes
2 answers
207 views asked May 30, 2015 in Genealogy Help by Justin Stressman G2G4 (4.4k points)
+7 votes
2 answers
90 views asked Nov 22, 2017 in Policy and Style by Bruce Codère G2G6 Mach 1 (16k points)
+13 votes
1 answer

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

disclaimer - terms - copyright

...