Standardized dates and places do not translate to my language
I have a relative in FamilySearch whose birth date and place were entered by someone using Magyar (Hungarian) as their language, as "1781. augusztus 30." and "Barka, Gömör, Magyarország". If my language is set to Magyar those appear as a standardized date and standardized place.
Normally my language is English, in which case those dates and places still appear as "1781. augusztus 30." and "Barka, Gömör, Magyarország", which are not standardized in English. If I standardized them in English to "30 August 1781" and "Barka, Gömör, Hungary", they will become un-standardized in Magyar. Similarly, standardized English dates and places appear as un-standardized in Magyar.
FamilySearch should automatically translate a standardized date or standardized place entered in one language, into a standardized date and standardized place in another person's language. If this is not done, I foresee the situation where standardized dates and places are changed back and forth between two languages, when they are actually the same date and place. This lack of translation makes it difficult for people who have different languages from collaborating on a family tree. Other words and phrases on the Details page are translated into the user's language, standardized dates and places should also be translated.
Answers
-
@EricPeterson91 Recently there has been much discussion here in Community about standardization of dates and places... your post here brings up some aspects of which I was not aware and do find interesting.
I agree with your Idea that dates and places should translate to the language the user is selected for on the site. I don't know all the complexities which might some into play - including the ability of the browser to translate page languages - but here are some thoughts:
Using your place example Barka, Gömör, Magyarország - I thought I would look it up in the FamilySearch Places database to see if the Alternate Language names are standardized - and therefore should be able to auto-translate to the user selected language setting. I begin with top-level name Magyarország:
Which lists the following English Alternate Names:
Name / Type
Austria-Hungary /Variant Name
Austro-Hungarian Empire /Variant Name
Austro-Hungary /Variant Name
HU /ISO 2L Code
HUN /ISO 3L Code
Hungarian /Demonym
Hungary /Short Name
Magyar /Demonym
Republic of Hungary /Full Name
hungary /Dominant Name
But only 1 English Display Name: Hungary
So the first question I would have for FamilySearch is which Type of Alternate Name is the one the Tree uses to translate to English - Short Name, Dominant Name, Full Name? Or is it the Display Name? My immediate thought would be this is the one displayed for the user language.
Next I moved to the full name place - Barka, Gömör, Magyarország
Which I note does display as Barka, Gömör, Hungary - but which only has Hungarian and Slovak Display Names. I would suspect/ask FamilySearch - is this why you are having this problem? If so this suggests that you should submit an English Display Name - so that the Tree will be able to translate the place in a standardized manner?
You can submit this Improve This Place Display Name request in the Places link above:
I do not know the Calendar/Date standard app so can give no help on the Date standardizing to the user language profile setting - but agree - it should translate as well. The place has the defined Date timeframe as UNKNOWN-1918 so I would not suspect your example with Date in year 1781 should be a problem?
1 -
@EricPeterson91, first a clarification: entering a place or date in English does not make it un-standardized in Hungarian. It may make the (dratted) map pin go away, but the date is still associated with a date entity that the computer recognizes, and the place is still linked to a geocode and one of its associated text labels in the Places database.
Next, an observation: the standardized labels are translated. Hover over the display value to show the database label in the current interface language.
The fact that this translation does not affect the display value is a Very Good Thing, because it means that any extra information I might enter is not erased when the language is changed. (For example, on the Famous Relative's profile, his christening place of "Budapest, Kálvin téri református egyház, Hungary" is linked to the standard "Budapest, Pest-Pilis-Solt-Kiskun, Hungary". I would not want the display to change to "Budapest, Pest-Pilis-Solt-Kiskun, Magyarország" if I set the interface to Hungarian, because that would lose the information about the church. It's enough for the tooltip to change to that.)
Luckily, the translation algorithm does not need alternate names in every language for every place. This is a good thing, given that neither Barka nor Gömör have English names. In fact, the only Hungarian placename that has an English name is the country itself.
When a place has no alternate name in the current interface language, it uses the name in the local language: Warsaw in English, Warschau in German, but Warszawa in Hungarian and Spanish and French, because while the city has a different name in each of those languages, they're not in the database. (This means that a Hungarian user has to learn the city's Polish or English name; Varsó only brings up places in Sweden and Estonia.)
The database is incomplete in other ways, too. For example, "Eperjes, Sáros, Hungary" is not linked with the equivalent location "Prešov, Okres Prešov, Slovakia". (If you only type as far as the S of the county, the Slovak name is still on the drop-down, but after that it goes away.) This unfortunately means that if a Slovak cousin enters it as Prešov, then I have to remember that that's Eperjes; I can't hover over it to get it translated.
2 -
Standardized dates and places do always translate to whatever language FamilySearch is set to use as long as there is a translation available as you can see in the following three examples of standardized dates and standardized places:
As can be seen by the fact that there is no warning stating "Non-standardized Place" under any of these, these are all properly standardized.
All dates and places in Family Tree as stored twice in the database. These are the Displayed data, which appears in the text boxes above in which we can type in anything we need the date or place to be, and the Standardized data which appears below the text boxes, can only be chosen from the drop down menu, and in the case of places must be contained in the Places database.
It is up to the various family members working on a profile to decide among themselves how they want the Displayed data to appear and in what language. It's great that Family Tree allows that flexibility. Then it allows everyone to be able to read the standardized version of the place name in their own language, if available currently on the website, by setting the website to that language then hovering over the text and checking the tool tip that appears.
1 -
So the first question I would have for FamilySearch is which Type of Alternate Name is the one the Tree uses to translate to English - Short Name, Dominant Name, Full Name? Or is it the Display Name? My immediate thought would be this is the one displayed for the user language.
In the Places database, Alternate Names is the list of all the names you can type into Family Tree and have the same place name appear in the drop down menus. There can be an unlimited number of these per language. The Display Name, as the name implies, is the name that will appear in the drop down menu or as the standardized version in Family Tree. There can only be one of these per language. If a language does not appear in the list, the place's local language, as Julia stated, will be used. This keeps the list short because so many languages will use the local language name, particularly for smaller places.
For example, I can type in "the big apple" or any of the other names listed for New Amsterdam when entering a place name in Family Tree and New York City will come up on the list of suggested standardized versions in Family Tree.
The name that is used in the display of the standardized version of what I call the user-entered Display Name (hope that is not confusing) will always be from the Display Names list. When I set the standardized version as "New York City" in Family Tree, the standardized version will appear as New York City whichever language I set the website to except when I set the language to Russian or zh-Hant. Those two languages will show the standard in the language chosen.
You can request that additional Alternate Names be added to the database and you can request that additional languages be added under Display Names with a version of the name for that language.
1 -
I had an image to demonstrate the above but had to edit which risks blocking the image, so here it is:
0 -
@genthusiast , you wrote:
I do not know the Calendar/Date standard app so can give no help on the Date standardizing to the user language profile setting - but agree - it should translate as well. The place has the defined Date timeframe as UNKNOWN-1918 so I would not suspect your example with Date in year 1781 should be a problem?
I think the translation of dates is pretty straight forward.. You only have to to deal with such a small set of words and numbers. And as shown in my examples above, the standardized versions translate just fine. The user entered Display Date, just as with places, is always preserved exactly how the user entered it.
The defined date timeframe for a place has nothing to do with translation of the date. It defines the jurisdictional time period for the next higher place level. In the example of Barka, the date range means that it was founded at some unknown time in the past in Gömör, Hungary, and was in Gömör until 1918. In 1919 it must have been moved from Gömör and put under a different jurisdiction. But the database is incomplete. It does not include whose jurisdiction it has been under from 1919 through today.
1 -
@Gordon Collett The defined date timeframe for a place has nothing to do with translation of the date.
agreed. I was only pointing out that when profile dates are entered - the place should correspond to the display for that timeframe.
Also @EricPeterson91 is stating that English translation of the date is not occurring.
0 -
English translation of the date is occurring, but it doesn't affect the display value. It shows as a tooltip on hover, same as the translation of the standardized place.
(The end date for Barka should really be 1920 or later -- whenever the treaty was actually implemented, which on a practical level might be as late as 1922. It's now Bôrka, Rožňava, Slovakia, but the jurisdictions are not linked in the database. This is true of almost every place in the dismembered parts of Hungary.)
1 -
@EricPeterson91 is stating that English translation of the date is not occurring.
Exactly. FamilySearch has not yet implemented this desirable feature.
This is an issue I have raised here previously. It reflects that language localization does not (yet) extend to the standard places and dates displayed for events that have been standardized. This leads to exactly the confusion @EricPeterson91 describes.
Surely, language localization of dates and places displayed in FamilySearch web and mobile app user interfaces is a major objective of standardization? Examination of the Places gazetteer reveals work toward that objective, but the amount of work still to be done is massive.
The work is also complex. In some regions of Europe a single small village can have official names in several languages. In some cases multiple names were even in contemporaneous use. This plurality remains in the historical record. In Hungary, for example, I have found as many as 4 sets of records of the same families: Church Latin, Hungarian, Czech, and Slovak. FamilySearch seeded Family Tree with profiles for the family members, without attaching the records, so now not only are there the usual many, many duplicate profiles but there is the additional challenge of finding and merging the duplicate villages.
I trust this feature is on the to-do list and in the meantime I try to be patient and usually refrain from re-standardizing dates and places in English.
1 -
In my years of using FamilySearch I have never noticed that a tooltip on hover will show the date or place translated to my language. Now that I'm aware of it, I'll update my suggestions below. I also have further observations using the attach and merge screens. I hope I'm not being to detailed or wordy, just trying to be as clear as possible.
When a Details page (for a person named Maria) in my browser shows a standardized Hungarian date and place for a Birth, the tooltips do show the English translations. This means that the HTML code sent to my computer browser already contains the English translations (to be able to generate the tooltips). The FamilySearch server has already done the translations to create the tooltips. This means that translations could be displayed for the birth dates and places by FamilySearch instead of using a tooltip (which is not intuitive).
Note that the tooltips will not work in the mobile app since there is no mouse pointer. If I pick a Birth in the Android app, the screen changes, but still shows the Hungarian date and place, with an "Edit" button, but not the English translations.
When I attach a source to Maria, and pick Details by her name, the Birth date and place displayed are translated to English, again, the FamilySearch server knows how to do the translations.
Although, if I do a merge to Maria, her birth date and place appear in the Hungarian language. This is inconsistent in comparison to attaching a source to Maria where they are translated to English. If I were to merge a Maria with a standardized English birth date and place into a Maria with a Hungarian birth date and place, which birth would I keep? I would not want to offend the Hungarian user who created a Maria by keeping the English date and place, or to offend the English user by keeping the Hungarian date and place. An English user may not even know that the Hungarian date and place are actually standardized, and may be inclined to replace them with the English values during a merge. This is confusing since the birth date and place of both people were entered as a standardized date and place, but in two different languages. If FamilySearch translated the Hungarian birth date and place to English, I would see no conflict when merging (avoiding confusion), and the Hungarian user would see the date and place in Hungarian and would not be offended.
We know that the FamilySearch server can do the translations which are visible in the tooltip and in the "attach" screens.
Entering a date and place in English does make appear to the user as un-standardized in Hungarian, and vice versa, since there are no icons (even though it may be standardized internally). When I pick Edit for a Birth, a standardized date has a small calendar icon on the left, and a standardized place has a small push-pin icon on the left. If my language is English, and I pick Edit for the birth of Maria, the date "1781. augusztus 30." does not have the icon, suggesting it is not standardized. And "Barka, Gömör, Magyarország" does not have the icon either. After I change my language to Magyar (Hungarian), if I pick "Szerkesztés" (Edit), the Hungarian language date and place do have the icons on the left. In Hungarian, if I edit a date and place (standardized in English), they do not have the icons on the left (but they do in English).
My suggestions are not concerned with alternate names for places (or their end dates), only with translations that FamilySearch already knows how to do as evident by the tooltips (and "attach" screen).
I suggest the following changes:
1) Translate dates and places on a Person page to the user's language and avoid the need to have tooltips (which are not intuitive and not available in the app). The translations are already known in the current tooltip.
2) Translate dates and places on the "merge" page just like they are translated on the "attach" page.
Thanks for your attention.
0 -
This has come up so often of late that I can't keep track whether Gordon or I have already explained this on this thread or not: lack of the icon does not mean that the date or place is not standardized. This is a very common misunderstanding, unfortunately.
If it's not standardized, it will be explicitly marked so, in red.
Another thing that needs clarification, I think, is that the text that appears in the tooltip on hover is not, primarily, a translation. It appears even if you have the interface set to exactly the same thing as the user who entered the conclusion. What the tooltip is actually showing you is the standardized value associated with the display value.
The display value does not, and should not, change. It is and always should be exactly what the user typed, because that's the only way to preserve the benefits of the dual-entry system that FamilySearch uses for dates and places in Family Tree.
1
