Localize place names and dates in Family Tree for better UX
Collaborating contributors who use different language interfaces are experiencing a frustrating user experience (UX) problem due to incomplete language localization.
The attached 2 screen shots of the same profile Edit Birth box illustrates the problem. Briefly: Contributor X standardizes dates and places in the German interface, that is using German localization. Contributor Y using the English language interface sees the dates and places still in German, and furthermore the interface suggests the dates and places need to be standardized into English. Checking several other language interfaces, the same lack of appropriate language localization appears to be everywhere.
The provision of language localization of dates and place names is a major reason why it is important to standardize these data. The current lack of this language localization is causing unintentional edit warring and bad feelings between contributors.
What should happen: standardized dates and place names appear (are displayed) in the language localization selected by the person viewing Family Tree, and the "standardized" icons, the calendar and map pin, appear in the editable text fields across all language interfaces to Family Tree. As an example, a standardized date will appear as expected in each language:
English: 1 December 1814
Italian: 1 dicembre 1814
German: 1. Dezember 1814
Russian: 1 декабря 1814 г.
The problem here actually is that the date and place name are standardized but (1) the user interface is misleading and (2) the standardized date and place name are not language localized.
A helpful Helper assured me a post here will be seen by FT engineers. Cheers!
Comments
-
This is a complex topic that has been brought up multiple times through the years. I's sure the engineers are trying to come up with a way to handle this type of situation. However, I do want to correct one statement you made and your illustration. In your second image, you can see by the green check mark and the terms Standardized Date and Standardized place that both items are correctly standardized as FamilySearch uses the term. Nothing there needs to be changed.
In Family Tree, all dates and places are stored as two data items, the displayed data and the standardized version of that data. If they are the same, they are displayed in the same box as your first illustration shows. If they are different, but correctly entered, they are displayed in two boxes as your second illustration shows. The displayed data is what was typed in to be displayed. The standardized version, as your second illustration shows, is always language localized.
The calendar icon and map location icon do not indicate whether the display data is standardized or not. Only the presence or absence of the green checkmark does that. They only indicate whether the display data is identical to the current language localized standardized version or not.
0 -
I will double down on the comment that the user interface (UI) is misleading. Very misleading.
Arguably the date and place name in my example are not language localized. The screen shot of the English site shows the date and place name are not in English.
Maintaining the argument that the data are language localized requires forcing the hints pull-down menu to serve double duty: depending on context, it is either "this is how the date might be standardized" or "this is the language localization, in your selected language, of the standardized date."
How can users not be deeply confused by this? The confusion is built in to the UI.
0 -
Oh, yes, I agree, the UI is confusing and has been ever since Family Tree opened with its unique double data entry system for dates and places. I think it is a great feature in that it allows the dates and places to include more accurate and complete data than an artificial standard. But it can be very confusing when first encountered and I think this confusion was made worse when FamilySearch introduced the calendar and map location icons which give unmerited extra weight to the standardized versions.
Regarding language localization, I both agree with you and disagree with you. It depends on which data you are talking about. The Display Data (the upper text box when both are shown) is never changed from what a contributor enters and at this point is never language localized. The Standardized Data (the lower text box when both are shown) is always language localized.
Adding to the confusion, you can only see the standardized value easily when the edit box is open and the Display and Standardized version are different.
If the edit box is closed, you can only see the Standardized version by hovering the mouse pointer over the Display data. If the edit box is open and the Standardized version is the same as the Display data, the Standardized version is not shown, instead you just get the icons.
0 -
Here is how it works on a person's detail page.
English:
Norwegian:
The programming challenge is probably how to translate the contributor entered data correctly without losing or corrupting the correct information the contributor entered. The above place name is actually made up of five unique elements, so you would think it would be possible to parse through the name and translate those portions that are exactly equal to the standard while leaving alone those that are different than the standard or not present in the standard. But, at this point at least, this is not done.
By the way, just for completeness, I do want to mention why I like this double data entry. It allows one when needed to enter a place name in a historically accurate spelling variant as found in the records at the time of an event while still showing everyone what place this corresponds to like this:
0 -
By the way, the green check and "Standardized Place" is generally in error. I think it is broken. Here is an example, where the Birthplace very clearly is not standardized.
0 -
The markup by @Gordon Collett proves my point. The dates and place names were standardized by a contributor on the German wiki, and on the English wiki they appear non-standardized.
Back-channel I have been informed this thread has been escalated to the engineers. So I have reached my goal here.
0 -
The example you give above is correctly standardized.
In FamilySearch, "standardize" does not mean "enter a name in one and only one way exactly as we tell you to." It means "enter a place name any way you want then link it to a reference value text substitute for the latitude and longitude so we know what you mean."
This non-standard use of the them "standard" is a very powerful feature of Family Tree that allows us to enter full, precise, complete place name information for research accuracy while still allowing that correct place name to be linked to the best possible geographical dot on the globe. We may be able to specify the exact square inch while the practical limitations of the Places database many limit that designation to something between an entire country and several square miles.
This great feature allows us to correctly make entries like this:
There really is nothing broken that needs to be fixed. What could be improved would be translating parts of the displayed place name which exactly match the standardized version when the website language is changed while not touching any additional information included in the displayed place name.
A lot of the not very pretty standardized display names like your example of "of Fort Ann Washington, N.Y." are direct imports from older database. This was not entered by a person into FamilyTree as can be seen by the May 2012 import date. April/May 2012 is when Family Tree first opened with its collection of records imported from the IGI, Ancestral File, Pedigree Resource File, and a few others if I recall correctly. This entry just hasn't been cleaned up yet. You probably won't see many times when someone enters a place name in this format these days.
By the way, "of Fort Ann Washington, N.Y.," except for the missing comma, is entered in the suggested standardized fashion of about 20 years ago.
0 -
Trying to stay on topic here...
The topic of this post is consistency in the language localization system on Family Tree to avoid confusion about whether dates and place names are, or are not, standardized.
This post was made to ensure a case report reaches the attention of the engineers. The case was submitted in the case report system, which is being de-commissioned, and FS staff there wanted to be sure the case did [not] get dropped on the floor.
0 -
This issue is again causing me problems as I work with records in other languages.
I need to know when a standard date or place name has been actively selected by another contributor, including any contributor who is not using the English language interface.
Upvotes of this post would be appreciated.
0 -
If there is no red exclamation point, a standard date or place has been selected. It really is that simple.
The Standard text will be converted into the language selected by the user. The Display text will always stay as originally entered. The Standard text can be seen by hovering the cursor over the Display text. The Display text is always visible on a person's detail page.
In the Edit box, both the Display text and the Standard text are shown when they are different. If the Display text and the Standard text happen to be the same, only one field is displayed even though the program still maintains the two separate data fields. Forcing the Display text and Standard text to be the same is not necessary, a waste of time, and can cause loss of data in the Display text field. Not only that, as soon as the language is changed they will be different again anyway.
1 -
Hi,
I am grateful for all these comments. I know it has been a while and I dream of future feature that will allow us to make a better use of our time on familysearch as I still have to spend a day and sometimes more to check the changes that have been done to, most of them, DIRECT family line. This week only, they were 31 changes and 25 of them where changes due to language difference from English to French for vitals and no added benefits, just change of word from an English spelling to a French spelling. The person that is doing these changes is probably a "far away" "removed" cousin and must be thinking that because these ancestors are in his country, Switzerland, in the French part, he wants the dates and country place in French. Many messages have been sent to him in French from me and my direct cousin. This far away cousin may not know about these messages on his account or may just ignore them.
Hoping the day come soon when I will be able to spend that day adding real information such sources and memories instead of checking if they are actually real changes and things that really need to be reserved.
By the way, it is interesting to note that when someone is doing a merge, the information that were entered in the system by me with an explanation, this note showing the name of the person that has made the merge instead and did not made the research and does not have the source document.
0 -
By the way, it is interesting to note that when someone is doing a merge, the information that were entered in the system by me with an explanation, this note showing the name of the person that has made the merge instead and did not made the research and does not have the source document.
In my opinion the labels on the Reason note fields are misleading. They say "Reason This Information Is Correct" and arguably they should replace the word Information with Edit or Change. The Reason statement applies properly to the current edit; it is not a place to permanently record sources or analysis. (Although there is permanence of a sort in the Change Log.)
I often move information I find in Reason statements into Source entries or Notes.
0
