Standardized dates in different languages

StefanoBianchi2

Hi all,

I realized that standardized dates are not as 'standard' as I thought. They 'remember' the language in which they are initially written.

I work on different computers, tablets and smartphones, with different language settings (Italian and English). If I add a date from an 'Italian' device, the standardized date is in Italian, while it is in English if inserted from an 'English' device. However, what is inserted in 'Italian' will be shown in Italian also on the English device and viceversa. Therefore, I now have lots of records with mixed English and Italian 'standardized' dates. This is certainly not what I would expect and messes up exported trees, for example, because the format for the dates is not the same for all the tree, and so only one of the two is recognized.

I do think this is something that should be fixed: whatever the language in which the date is inserted, it should be then 'standardized' to a unique internal format, which can then be shown always in the proper language setting. It seems to me the correct way to deal with it.

Am I missing something?

Stefano

Gordon Collett

"Standardization" in Family Tree means that the displayed data is correctly linked to an internal computer representation of that date that can be used in computer routines such as hinting, searching, and looking for duplicates. It has very little to do with how the data is displayed.

The actual "standard" for 3 June 1845 is probably something like the Julian date number 2,395,085.5.

FamilySearch and Family Tree really aren't all that concerned with how the date is displayed or in which language. That is up to the family of the individual in the tree and what works best. As long as 3 June 1845, June 3, 1845, 1845-06-03, 3 juni 1845 are linked to 2,395,085.5, all the routines work just fine.

Likewise for places, as long as a place name is linked to the correct standard it doesn't matter to the computer what is displayed. You think what you are reading as standard for New York City, New York, United States is just that, but really the standard is 40.7142, -74.0060. The displayed text can be New York City, New York, United States or can be New York City, NY, USA; New York City, United States; Empire State Building, NYC, New York, USA or any other style that works best for the situation and as long as that is linked to 40.7142, -74.0060, everything in the program works just fine.

We are left with the liberty of entering the information as we need to. Regarding your English/Italian mix, just decide which language you want to use. If you want to use English, type the date or place in English no matter what your device language setting is. If you want to use Italian, likewise just always type it in that way.

Here, for example is how I would enter a Norwegian date when FamilySearch is set to English:

This is correct usage of Family Tree where "standardized" means "linked to correct internal data representation" but does not mean "only correct way to enter data."

StefanoBianchi2

Thanks Gordon for the reply, but I'm afraid this is exactly what is not actually happening with FamilySearch.

If I enter a date in the numerical format ddmmyyyy, it is correctly recognized by FamilySearch, BUT it is always 'standardized' depending on the language setting. So it will be always translated into something like "11 Gennaio 1900" or "11 January 1900". Now, if I read the record in another language setting, the date will be displayed in the original standardized way, indipendently from what is the current language setting. This is not what I would expect if the date is indeed memorized in a machine-independent format (like a Julian day).

This creates problems, because the date formats are indeed mixed and preserved as they are. So, as far as I understand, it may well be that the dates are "linked to correct internal data representation", but they are not 'standard'. If I export the records, they will show mixed formats for the dates, which depend on how they are originally inserted, and are not transformed to the same standard format. This clearly creates problems when you want to automatically read these record.

My expectation would indeed be that, whatever the format the date is inserted, it is then memorized in a standard format (like a Julian day), which then should be shown depending on the reader's language setting, in a homogeneous way.

Thanks,

Stefano

Gordon Collett

This concept of standardization in Family Tree can be very confusing until two things are made very clear. 1) Programmer’s English is more precise than regular English and often does not use the expected common definitions. 2) All dates and places in Family Tree are stored in two versions. The displayed version and the “standard” version. The displayed version is never changed by the program and can be whatever the user who enters it needs or wants it to be. The “standard” version is the internal version used by all programming routines and when shown is always in the language the website is set to.

I’ll use your example of a date entered as dd-mm-yyyy to show how this works.

Here is the original entry:

The display date is what I entered. The “standardized” version shows below. The green check mark shows that that the date is “standardized” correctly and the two versions are linked correctly.

Here I’ve changed the site to French:

And here to Finnish:

As you can see, the display date is preserved in the form it was originally entered while the “standardized” version is shown in the language the website is set to.

This is the current intent and design of the website. 

Besides the non-standard use of language, one other confusing aspect of the how dates are currently displayed, is that if the display version and the “standardized” version happen to be the same, the page compresses them together, probably to save room, but there are still two pieces of data preserved. If the site language is changed so that they are no longer the same, the two pieces of data are again shown separately.

Here I entered a date in Norwegian while the website was set to English. When I change the website to Norwegian, the display is compressed but both data items are still present as can be seen if I change the website to Swedish which does not use the period after the day:

As far as I am aware, Family Tree is the only genealogical database that uses this double data entry system and if the process that exports the data into another program does not allow for this, I’m sure this would lead to problems. The beauty of the double data system is the flexibility it gives to data entry to allow more complex, complete, accurate, real world data like this:

while still linking to a version the program can use internally instead of the rigid, inflexible, artificial constraints most genealogical databases demand.

StefanoBianchi2

Hi Gordon,

thanks for your detailed answer. However, it seems to me that this is not what's happening in my FamilySearch. These are two snapshots on the website:

In this case, I have the Italian settings. As you can see in the first snapshot, death and burial dates are one in English and the other in Italian. There are no alternate displays, these are what I see on every device. As for the second snapshot, if I want to edit the date, it is always only in the standardised way, which will depend on the language setting of that device. So, it happens I don't have a date that changes accordingly to the language setting and another which is fixed to what I decided when I first entered it.

Of course, the real problem arises when I export these data: both with RootsMagic and the python script fstogedcom, the dates are imported in the same way I see them on the web, so in both languages, depending on how I entered them. And those in Italian are not recognized... So I'm now painfully changing all the 'Italian' dates on FamilySearch...

Stefano

Gordon Collett

What you are seeing is what I am describing. Play around with this, switching back and forth between languages. The key to all this is to realize that you do not need to pick the date or place with the icon next to it.

That is how you decide what form you want to displayed data to have.

StefanoBianchi2

Thanks Gordon, now I understand the key point I was missing.

If I may, I still think this method is confusing and could not be the best option for a shared tree, which is the philosophy of FamilySearch (very different from other websites/software):

-An individual is likely to be shared with more than a user, with different languages. Therefore, I would not expect to see the birth date of that individual in, say, Finnish if that's what the other user decided. This is not a personal tree. I would expect to see the dates in my language settings, not in those of who entered the data. If I see it in Finnish, I may want to change it in Italian, and the Finnish user may want to change it back in their language, and so on. The other solution (just a standardized date displayed with the user's settings) seems to me much more natural.

-I understand FS does not want to be directly involved in exporting the trees, for whatever reason. However, there are ways to do that, and in all the cases I tried this results in exporting the displayed date, not the standardized one, and this create a lot of mess. Again, the other solution would work without issues.

Is there something else I am not considering here?

In any case, thank you very much for your time on this issue.

Gordon Collett

You are right, this can be very confusing. The points you bring up in your last post have been discussed back and forth by users of Family Tree for years with the translation issue being a big part of that.

The huge advantage of the current system is that you can enter a date or place with as much information as desired such as:

Tuesday, 25 January 1845 - Klubben sub-parcel, Digernes farm, Stord municipality, Hordaland county, Norway

and link it to the appropriate but less detailed standard:

25 January 1845 - Digernes, Stord, Hordaland, Norway

Some of the debates have centered around whether the display version and standardized version should both show on a person's detail page and some have been about whether the display version should be scanned and those portions that are identical to the standardized version be translated so you get something like this if the page is set to Norwegian:

Tuesday, 25. januar 1845 - Klubben sub-parcel, Digernes farm, Stord municipality, Hordaland county, Norge.

It will be interesting to see how the site evolves to deal with all these issues over the next couple of decades.