Is it time to update the commonly accepted genealogical standards for dates and places?

Gordon Collett

Current genealogical standards as I have heard them but never seen in print are to enter dates and, in particular, place names as they were at the time of an event. I propose that it is time to revise this standard usage.

Background:

• Family Tree is a worldwide, wiki-style, open edit system.
• The number of languages for the FamilySearch website and FamilyTree have recently been greatly expanded.
• Contributors to Family Tree from many different countries are working on common ancestors.
• As more contributors see that Family Tree is available in their native languages, they will be more inclined to use that feature and work in their native language.
• Standards for data entry, not to be confused with FamilySearch “standardization” of data items, are intended to promote consistency and appropriate uniformity in recording genealogical data.

Problem:

• Since current genealogical standards do not address multiple language speakers working in the same tree, they do not address which language should be used in that common tree.
• Contributors tend to enter and edit data in their own native language.
• When contributors from different countries are working on the same individual, the data in Family Tree can be changed repeatedly and rotate between several different languages. 
• The Display Data component of a date or place is designed to stay as entered by a contributor and not be translated based on the website language setting in order to not lose or corrupt the contributors data.

Suggestion:

The current genealogical standard should be updated to state that places and dates should be entered as they were at the time of the event and in the language used at the date and place of the event.

Rational:

• If this revised standard came into broad use in Family Tree, then any user in any country would enter a date or place name in the language of the event.
• Repeated editing of a date or place just to change the language would not occur.
• Researchers would increase their research skills by quickly becoming very familiar with basic dates and place names in the language of their countries of interest.

Reply To The Objection: “I don’t know the language.”

• If a contributor does not recognize a date or place name as shown in a language other than his or her own, hovering over the date or place name as it stands causes a “tool tip” to appear and show the standardized version of the data which will be in the language to which the website is set.
• If a contributor does not know the proper form for a date or place name, changing the web site language to the language of the event will allow the contributor to type in the data in his or her own language and use the list of possible standardized versions to convert it to the proper language

Reply To The Objection: “The program should translate all dates and places to my language.”

• This might at some point be a feasible alternative but does not at this time exist in Family Tree. Current design of Family Tree is to maintain, uncorrupted, the data entered by a contributor and to link this Displayed Data to the closest equivalent standardized form. This allows greater detail, more precision, and greater accuracy than a strict adherence to a website maintained list of required standardized versions of dates and place names. This unique design of Family Tree has great benefits that should be preserved.

Gordon Collett

Example:

Ole Johnsson was born 5 May 1850 at the tenet farm Klubben which is part of the farm Digernes in the community of Stord, Hordaland, Norway. Assume I do not know the Norwegian style of date entry and do not know what parts of the place name are already in Norwegian and which are in English. If I set the website to Norwegian and start to enter the name, the forms in the drop down menu will be in Norwegian so I can see how to enter them.

For the date, the vast majority of the time the standardized version will be suitable so I can just click on it to enter the date in Norwegian.

For the place name, very frequently I will want to enter more information than is contained in the standardized version. By typing out the full place name, I can see what parts need to be changed to Norwegian and revise what I am entering to use that.

When I change the website to English or any other language, the standardized values change to that language so if I cannot read the Norwegian, I can either hover over the data items on the detail page or open the editing box to see the translated equivalent.

If I know the Norwegian form for the date or place I want to enter, I can type that in directly independent of what language the website is set to use.

Paul W

Whilst you make many worthwhile suggestions, Gordon, I wonder if this issue can ever be be satisfactorily addressed?

The problems with standardisation exist even without the language aspect, of course. They are also connected with how, or from what document, a record has been indexed. For example, if (in your case) whether a record has been indexed from its original Norwegian or, perhaps, an English transcription.

Obviously, some inputs are made by users on the basis of personal knowledge and documentation, rather than FamilySearch sources, so this is a factor that could affect the format of the input.

I know you are emphasising the problem created, say, by users working / inputting in one language and other users establishing the most accurate equivalent (of that place name / format) in another language, but (as I know you realise) the problems with standardisation go well beyond that.

There are difficulties over the display name, in particular - whereby it appears to have standardised perfectly correctly (i.e. no data warning flag), but when checked, the "hidden" standardised place name transpires to be a place (of similar name), but located thousands of miles from where the event actually took occurred.

You concentrate on the place name issue (apart from where there is the issue of, say, months being recorded in different languages), but I find standardisation of dates an important issue with records I deal with. I have mentioned the double-dating issue (with English records) previously. Maybe I make too much of a fuss over this, but the year where this issue comes into play is probably frequently a year "out" from how it appears in both indexed records (compared to the original document) and in the way it can be inputted by a user and subsequently standardised by the program. This, in itself, would be a thoroughly complex issue to address to the satisfaction of the user (who wants to know/see the genealogically accepted standard recorded) and the indexing instructions laid down by FamilySearch project managers, requiring the indexer to record everything as written.

Whether I am drifting away from the main reasons you have raised this topic or not, I believe my comments (and many others that have been made in the past about suitable / most appropriate formats of place names or dates, based on a particular point in time) show this whole area if fraught with problems that make a response from FamilySearch to the whole issue, well, almost impossible to implement, to the satisfaction of either its users or in order to adhere to any strict "genealogical standards".

In summary, you make excellent points regarding the issues with multiple languages, but the problems with the current way both dates and place names end up being standardised in Family Tree goes way beyond that.

Paul W

Gordon

After re-reading your comments, I should perhaps apologise for drifting away from your main "language" issue.  However, as you have given this topic the title, "Is it time to update the commonly accepted genealogical standards for dates and places?" I have let my own comments stand, to illustrate the general problems (in FamilySearch adopting a more satisfactory way to standardise dates and places) really extend much further than purely language-related issues.

Gordon Collett

Thanks for you thoughts. All were very pertinent to this very complex topic of how data is entered. And even narrow topics need to be seen in their wider context. I did intend that this discussion cover just standards, however, not standards or standards, and just one small standard at that.

Let me explain.

There are standards, i.e. commonly held ideas about best practices in research and recording information such as entering a woman with her maiden name, entering last names in all capital letters, not including "United States" for places there, not entering County after the name of counties, and entering place names as they were at the time of the event being recorded.

These are usually enshrined in dusty tomes that no one has actually read but held as gospel, until they aren't.

There are standards, i.e. rules for data entry that are usually due to constraints of the particular form being used such as when PAF required that one have no more than four parts to a place name and that each part must be 16 characters or less. Another example is the requirement in some systems to enter a three letter abbreviation for names of months because that is all there is room for.

These are usually enforced by the form just refusing to work or downright crashing if they are not followed.

There are standards, i.e FamilySearch's textual representations of something Julian Date Numbers and of latitude and longitude. They really should have been called something else like "simplifed versions" or "computer recognized equivalents." Using the term "standard" has led to massive confusion with people thinking that FamilySearch is saying "This is how you have to enter information" whereas it is obvious when you really study how these are implemented that Family Search is really saying "Enter your data anyway you want to, please just tell the program what you mean by linking what you want to enter to something equivalent or inferior that the program can understand." This does entail people knowing what is going on in the program and checking that what they told the program they mean is really what they intended and not a place thousands of miles away.

The goal of my proposal is not to solve all the problems with data entry that can be found in FamilySearch and in Family Tree, but just to suggest a way for Ole Johnsson's great-great-granddaughter in the United States and his great-great-grandson in France and his great-great-grandson in Brazil to quit changing his birthplace from English to French to Portuguese to French to Portuguese to English to French but just let it stand in Norwegian and go and do something worthwhile with their research time.

Adrian Bruce1

" in the language used at the date and place of the event"

"just let it stand in Norwegian"

I'm not sure how these two aims work out if we find an English (say) record of a Vital Event in Germany (say). Perfectly possible if we are looking at British-based newspaper reports of "expats". Seems to me that there is a possibility of people thinking about the second aim who will expect that data to be in German, while others will be looking at the source (produced in the UK) and thinking of the first aim, who expect the same event, from the same source, to be in English. (From personal experience, most of my British newspaper reports on "expats", tend to be deaths and - to a lesser degree - marriages).

This would suggest to me that the language of the source should be the driving force - and if there are multiple sources in multiple languages, then priority should be given to any source in the local language.

And using the language of the source, rather than the language of the locality, could be really important in cases such as the English language newspapers produced in India reporting primarily on news of interest to "Europeans".

DavisGGardner

I would like to have the Danish version of Copenhagen come up as the standard place name when I type in Copenhagen into the place field. The reason for this is that I have trouble entering the special characters in Danish and would prefer for my Danish ancestors to have their standard place names appear as they were written while they were alive.

Similarly if my Brazilian friends trace their ancestors to London, England, I feel that the English version of the place name be used, rather than the normal way Brazilians refer to the capitol of England: Londres.

I have two children born in Okinawa while I was in the Air Force. I would prefer to have the option of choosing a standardized romanization of the place name, as well as the name available in Kanji, or Katakana, however the people of Okinawa listed the place name prior to reversion (when the US returned ownership of Okinawa to Japan).

Gordon Collett

DavisGGarner, it's easy to do what you are requesting right now.

Just go to the bottom of the page on any FamilySearch page and set your language to Danish while working on your Danish ancestors. Then when you open the edit box and start typing in Copenhagen, the Danish version will show in the drop down menu:

Just click in the menu to enter that form without needing to type Ø:

Then go back and complete the place name as needed:

This time clicking on the full place name, not the shortened "standardized" version:

When you change back to English, the displayed place name stays in the proper Danish:

If you are not fully comfortable working in Danish, you can work in both languages simultaneously. The language setting is apparently a browser cookie, not an account setting. Open FamilySearch in two different browsers, such as Safari and Firefox. Put the windows side by side. Set one to Danish and leave the other in English. You can compare text as needed and you can jump back and forth between browsers as needed:

Glenn Cowan

I agree with the original post, it would be good to update how the standard dates are handled. I was working on a Mexico record (English version of FSFT) and noticed that the date was listed as "17 de septiembre de 1851", so I went in and updated it to "17 September 1851" which is the standardized date. I then viewed the page in Spanish and expected to see the date format change to the Spanish date of "17 de septiembre de 1851", but it stayed as "17 September 1851". I have been updating the Spanish dates I see to the English standard version which is probably annoying all the Spanish speakers to see English dates. I will stop that now, but why have a standard date format that only applies to the language of entry into the field?

To me, the whole point of choosing a standard date format would be to make it easy to 'translate' to other languages. The same idea would apply to place names. I think when I choose "New York, United States" in English, then someone browsing in other languages should see "Nueva York, Estados Unidos" or "New York, États-Unis".

Glenn Cowan

One other comment, this issue actually strikes me as a major usability issue (mainly for non-English speakers). One of the main goals of FSFT is to have one single place where everyone can contribute on the same tree at the same time in their own language. It isn't hard to see that "17 de septiembre de 1851" and "17 September 1851" are the same, but what about "sedmnáct září 1851" or "שבעה עשר ספטמבר 1851"? The longer FSFT is around and the families of the world mix, the more we will have Norwegians working on Greek ancestors or Venezuelans with Cambodians. I personally have worked on Spanish, Portuguese, Chinese, Swedish, German, and Swiss ancestors for myself and others. I speak English and have a university degree, but not everyone has that advantage. Paraphrasing what Gordon said: "just let it stand in [language of the user] and go and do something worthwhile with...research time"

(TLDR: Showing dates in foreign languages hurts usability and collaboration for non-US users)

Gordon Collett

To me, the whole point of choosing a standard date format would be to make it easy to 'translate' to other languages. The same idea would apply to place names. I think when I choose "New York, United States" in English, then someone browsing in other languages should see "Nueva York, Estados Unidos" or "New York, États-Unis".

That is just half of the point of having a standard date and this is accomplished. The standard date always is translated into the language the website is set to. But the standard is not what is shown on the Detail page. What is shown on the Detail page is the date as entered by the user, that is, the Display Date. The standardized version of the Display Date is a separate piece of information that can always be viewed by hovering the mouse pointer over the Display Date.

The other half of the point of having a standard date, is the ability to add additional information to the Display Date.

But to get back to the real point of my original post, what I am suggesting is having an accepted standard for how information is entered which is a completely different topic from the topic of standardizing dates and places in Family Tree. Unfortunately standards and standardizing are often confused and the second is frequently completely misunderstood.

Julia Szent-Györgyi

In a place like Norway, choosing a "language at the time of the event" is straightforward: in the genealogical timeframe, the country has always been Norway, and the local language has always been some version of Norwegian. Orthography and pronunciation may have evolved over time, but that's the only axis of variation.

But what about an event in, say, Pozsony/Pressburg/Prešporok/Bratislava? Whatever the language spoken by the participants, the event place is likely to have been recorded in Latin, as Posonium (or some grammatical variation on same), so we can't use the language of the record as a guide, unless we start doing everything in Latin as well. (The official language of government in the Kingdom of Hungary was Latin until 1844, and Hungarian thereafter. Church registers were considered government records, but their language varied; Lutheran registers were especially likely to be in German, in That Dratted Handwriting, up until the 1870s.)

I have multiple ancestors whose "mother tongue" is unknown: there are arguments for and against them speaking either German or Hungarian on a day-to-day basis. It'd take a complex socio-political analysis of the history of their localities (most of which are now in Slovakia) to determine the most likely language.

I'm perfectly happy to record places and dates in Hungarian or Latin, but I speak the one language natively and have over a decade of experience deciphering the other. If I discovered ancestors in, say, Moravia, I would not be happy trying to translate the register's Latin months into the Czech ones, and if my research ended up in an area that uses the Cyrillic alphabet, I'd be completely at sea.

I sympathize with the impetus for the suggestion of choosing a language and sticking with it. Just yesterday I was working on profiles where a Spanish-speaking contributor had edited a bunch of dates and places to be in Spanish (for events that took place in Hungary and the U.S.). I resisted the urge to undo the changes: the Spanish is similar enough to the English or Hungarian that I can interpret them just fine. But it would be nice to come up with some way of teaching people that they don't need to do that, and a general guideline of "try to use a language that the participants would recognize" might be a good start in that direction.

tl;dr: determining the language used at the time and place of an event is not a straightforward task, so this suggestion cannot be more than a general guideline.

Gordon Collett

As with any "standard" derived by a batch of self-appointed experts with a declaration on the one and only accepted way of doing things who will never be familiar with all possible situations that make all "standards" dubious at best.

I wonder if your new Spanish acquaintance had the website set to Spanish and was endeavoring to get a map pin showing for every location.