Automatic translation of standardized dates and place names
Some profiles in my tree have dutch or french dates or place names. Because I work with the site in english, I try to change the dates and place names so that the display value is also in english. I thought I was doing some cleanup work but it seems not.
As mentioned in the following discussion (https://community.familysearch.org/en/discussion/comment/601909#), the display value does not change with the language of the site, even when it is standardized in one language. Would it possible, when the date and place name is standardized, that also the display values would automatically translate to the language of the site?
Answers
-
I think @Gordon Collett has discussed what happens in that situation in a past post. Apologies, Gordon, for tagging you if my memory is faulty.
0 -
Yes, I've been involved in discussions about the topic before. Basically, @Loïc Baert , although FamilyTree is FamilySearche's database and not a collection of user's individual databases, they leave it up to us users to enter our family data in the language and format we wish to use.
Various users have various opinions of how to do this with the main question being does a user enter names, dates, and places in the user's language, in the language of the country of the event, or the language that the person would have used. For example if an English speaking user is adding a place in France to the profile of a German ancestor, should it be entered in English, French, or German? There are no rules that I have ever run across.
The method that FamilySearch has chosen, is to maintain exactly what a user enters for the displayed place name and to provide a translation in the linked standard for whatever language the user has the website set to. This also allows users to enter more precise and complete names than what the places database will ever contain.
For example, if I have a person born at the tenant farm of Klubben which is part of the farm Digernes which is located in the community of Stord, Vestland, Norway in 1830, the correct historically precise way to enter this is: Klubben, Degernæs, Stordøen, Søndre Bergenhus, Norge. When I enter this and link it to the appropriate standard with the website set to Norwegian then change to English, German, and Chinese this is what I see in the data pop-up view or in the tool tip when hovering over the place name :
With each change in the website language setting, the standard is being translated but the original entry by the user is being preserved.
This achieves two goals: 1) Do not change user entered data. 2) Allow users to read information, as far as possible, in their own language.
The importance of the first goal is shown in this post by a very disappointed user:
Also, as I tried to explain in my reply to your previous post that you referenced above, all four of my examples here are correctly and properly standardized. The displayed data is a separate data item from its linked standard. You can see the four different standards in their four different languages in my examples that all link to my richer, more complete, and more accurate displayed place name.
3 -
Thanks @Gordon Collett your clear explanation was what I recalled.
0 -
Thank you @Gordon Collett for the clear explanation. I understand that for very specific location, the original display value does not to be changed and the standardization takes good care of that.
I'm speaking about general dates and places names. When someone who speaks Italian enters a date in Italian on a Belgian person page, it will be displayed in Italian which is more difficult for me to research this person because I do not speak Italian. I need to click on the vital information to see the standardized data in English. Like the example shown by @AnneLoForteWillson in the original post, those display dates and place names could also easily be translated to make it easier for each researcher in their own language. I see it as a tug of war where nobody has the correct answer for the display values even though the standardized values have the correct answer.
I hope you see my point as well.
0 -
Yes, I do understand your point of view and as I mentioned, there are several different opinions floating around out there as to the best way to enter information and FamilySearch has to do their best to navigate these and find a compromise between all of them for all the various languages the website uses. I think their current solution is well done.
To switch from explaining what FamilySearch does and to declare what I think they should do, I think they should make their dual place name entry system just as obvious as possible by always showing both the user entered Display value and the translatable linked standardized version along with having the text of the standardized version and a more information or help icon next to it be an active link to the Places database.
I would love it if the next version of the profile page details tab looked like this when the Detail View slider was off and on:
with Digernes, Stord, Hordaland, Norway and the ? icon linking directly to here: https://www.familysearch.org/en/research/places/?focusedId=606034
But getting back to your comments, since you do not speak Italian, one could argue that it is even more important for a date to appear as 25 guigno 1910 no matter what language you have the website in because when you go to research this person in Italian records that is what you need to be looking for. You are not going to find "June" anywhere.
(Images taken from FamilySearch's beta site and edited in Photoshop. No production data was harmed in the making of the final images.)
4 -
@Gordon Collett I came across Italian dates and place names on Belgian and French persons. Another possibility is to choose the language of the website itself (menu items and "Birth" etc.) and display values (actual date and place names) separately.
So I can, if I wish, set the language of the display values to Italian if I want to research Italian records but with the rest of the site in English so I know how to navigate the site.
The system asks always to add standardized data in the vital fields, so it can be translated. Any additional information on specifics on the vital field can be added as a note.
0 -
"The system asks always to add standardized data in the vital fields, so it can be translated. Any additional information on specifics on the vital field can be added as a note."
That is a common misconception. The system always asks us to link the data we enter to a standardized form that may well be less complete and less accurate. My examples are all correctly standardized. There is absolutely no need to hide additional information in a note when the system is purposely designed to have full information entered where it belongs.
My full explanation of this feature of Family Tree, although a bit outdated as far as appearance, can be viewed here if your are interested:
2 -
@Gordon Collett Thank you for sharing this video, I learned a lot from it. The most important thing is that I do not need to standardize the place name when there is no error message as the system linked it to a standardized place name. What about place names that conflict with the dates? Do they need to be changed, even if there is no actual error?
Given the new insights that I got from your video, it would indeed be great if we could see a detail view as you suggested.
0 -
If I might add an observation here - this appears to be one of those cases where certain display values could easily be translated, but others can't, and it's pretty much impossible to find the dividing line.
For instance, if I had a display date starting with "Monday", it ought to be easy for the software to translate that into "Lundi" as the system moves into a French version. But other examples might not be as simple. For instance, suppose I had directly quoted the day from the source and wrote it in Latin? Hmm. Less obvious what the translation should be.
Another favourite example of mine is in relation to German placenames - I don't think I've done this on FamilySearch but certainly have done so on my own PC, where I've written out display names (or their equivalent) in a mixture of English and German. I will always enter the country as "Germany" because "Deutschland" is just too pompous if the data isn't leaving my machine. The level below is a bit changeable - I probably write "Bavaria" not "Bayern", but I don't promise consistency. Below that, I tend to use the German names (because there aren't that many small towns in Germany with English names) and I definitely insert German place types for a couple of good reasons: Firstly it would be a shame to pass up the use of words like "Regierungsbezirk", and secondly because some of the English translations are flaky indeed. Better to leave "Kreis" in its original German than mess about with all the different suggestions, half of which are variations on "district".
But, if repeated on FS, what that could do is result in a mess as the software assumes that "Kreis" is in English or if not, it leaves it as "Kreis" then translates it into the English word "district" the next time I see my own input that's been translated into wholly English even though I never wrote it thus.
3 -
"What about place names that conflict with the dates? Do they need to be changed, even if there is no actual error?"
This gets into the workings of the Data Quality Checker, what needs to be done for program routines to work properly, what is nice to take care of to improve a profile if you have the time, information, and inclination to do so, and the various sources of errors.
Do you have a specific example of a name - date conflict that is not an error?
I'll mention a couple that demonstrate five types of errors that I can think of that might get flagged either by the current version of the Data Quality Checker or a later one as they continue to improve it.
A) Error on a profile.
Another user recently was asking about information on a profile he was working on that was flagged as an error. He had entered Germany for the birth place of a woman born about 1850. This was flagged as an error because Germany did not exist as a country until 1871.
The choice here is to just ignore and dismiss the flag and say using Germany is good enough or to determine the correct name for when she was born and use that instead. This decision is up to the individual users who work on the profile.
B) Error or reasonable variation in a Source.
Say the user mentioned above determine that the place the woman was born was in Prussia. So he changes her birthplace to Prussia. This will take care of the date conflict error. However, there are several early 1900 census record sources on her profile that state she was born in Germany because where she was born was Germany at the time of the census. This will introduce a new error flag pointing out the conflict between Prussia and Germany. In this case the profile is just fine and it is the source that has a problem. In this situation, the Data Quality conflict flag should just be dismissed with a reason statement that there really is no conflict, just a difference in how the census recorded information.
C) Error or incompleteness in the Places Database.
There are many small villages in Germany in the Places Database that do not have an entry for pre-1871. For example, Abens ( https://www.familysearch.org/en/research/places/?focusedId=12323188 ) has no standard to use for before 1871. If you have family living in that village in 1850 you can correctly enter it as Abens, Freising, Bavaria but there is no way I can find to get any standard on it other than the post 1871 standard.
This can only be corrected by sending in a request to the Places Authority team to add the proper historical time periods for Abens.
D) Error in standardization
As can be seen in the Places database, the Auganes farm was in Kinsarvik municipality until 1868. Then it was in Ullensvang municipality from 1869 to 1912. Then back in Kinsarvik from 1913 to 1963. Then back for good in Ullensvang from 1964 to today.
If I correctly enter a birth place of Auganes, Kinsarvik, Hordaland, Norway for 1860 but link it to the 1913 to 1963 standardized version, this will get flagged as an error even though it looks perfectly fine. The only way to clear the error flag is to go back and change the linked standard to the identical appearing Unknown to 1868 version.
E) "Errors" that are really just accepted standard practice.
In my examples in my posts above, I kept using Søndre Bergenhus for the county. Neither I nor anyone I have run across actually use that. We all use Hordaland for the county even though that was not its name until 1919. Even the Norwegian National Archives uses just Hordaland in cataloging its online records. All of FamilySearch's historical record databases of indexed records use Hordaland uniformly even before 1919.
The county's entry in the Places database is structured so that using Hordaland does not result in a Data Quality Score time - place inconsistency or error flag. It also allows Søndre Bergenhus if there is ever anyone that wants to use the historically accurate name instead of the anachronistic name.
This just all points out that place names are complicated, the Places database which contains the standardized place names used in Family Tree is incomplete, and the Data Quality Checker is in its infancy.
1 -
Maybe I stated it a bit wrong: in some cases there is a data conflict but it doesn't show up clearly op the person profile page. Here is an example:
You only see the conflict when clicking on the birth information or when the quality score is available. It would be better to have an error showing up in the Research Help section as other data problems.
0 -
I have an idea to "solve" the tension between the display values and the standardized values but please correct me if I'm wrong or if it is too far-fetched.
As mentioned in your video, the standardized version of place names and dates is important for hinting purposes and in approximately 98% of the cases there is only one correct standardized date and place for each person in the tree (the same as a parent-child relation).
By showing the standardized value as the default value instead of the display value, people will have the dates and place names in their language of choice based on the settings of the website.
Because of the strenght of the dual system, people could choose to divert from the standardized value by adding more information (the first example in your video at 10 minutes). That value cannot be overridden by other users but will show up as a second line on the person page (see following frustration already mentioned above)
The person who added more specific information could choose to be informed when the standardized value is changed, so maybe the person can also change the additional information if desired (like following a person page). The person who changes the standardized version could also send a message to the user who added more information.
Many profiles on the family tree fall I think into the second example of you video. In such cases, the standardized version is complete enough.
I have another question concerning standardization but it not about date and place names. Many profiles have their surname fully capitalized. Is it ok to change it from "SMITH" to "Smith", even if it is not your relative?
1 -
Interesting thoughts about alternate ways to solve the conflict between what is most helpful for users to see and what the program needs for computations. We are told that helpful insights posted here do make it to the engineers even if not posted to the Suggest An Idea section. Maybe the next update to the profile and other pages will pull in various insights and user ideas to make progress on this whole issue.
Regarding changing SMITH to Smith, that is fine. Having the last name in all caps was the required standard for submissions to FamilySearch back in the early 1900s when paper forms had just a single line labeled Name and it could be difficult to tell when the first names ended and the last names started. Family Tree contains everything submitted to FamilySearch since 1894 and you can still run across some old records that have not been edited by users to update this. Since the opening of Family Tree in 2012 FamilySearch has been encouraging dropping the practice.
You will also run across records using another old standard of putting a / to separate the first and last names. That needs to be removed.
Now a type of editing that FamilySearch does want done but can start stepping on the toes of older genealogists if those toes are particularly sensitive also comes from the days of their being only a single line for Name. The old practice was to squish every name a person ever had into a single line and sometimes even include their occupation. So if you had a woman who was a nurse with maiden name Elizabeth Jones with nicknames Betty and Nellie who married first Mr. Smith then Mr. Stevens, you might find an old submission that got imported into Family Tree with her main name as: Nurse Elizabeth "Betty" "Nellie" Jones Smith Stevens. These names need to be split out and all but one moved to Alternate Names and the occupation put in the Occupation spot. If the original submission was from 1940, you are unlikely to have anyone complain. If it was from last week by someone who is still using 1940-standards, you should probably try to message them first and discuss the problem.
3 -
Regarding your Data Quality Score example. I could speculate they are trying to find a balance between pointing out potentially conflicting information without getting too annoying or overwhelming. They may also be trying to hide potentially trivial concerns or potentially complex problems from casual or inexperienced users by only having the quality scores visible if you actively go hunting for them.
I assume you have investigated that particular flag but for others reading your post and wondering what the conflict is, I'll mention it here so they don't have to go look for it. Going to the Places database at https://www.familysearch.org/en/research/places/?focusedId=420204&text=genval there is information that prior to 1977 the place name should be entered as Genval, Brabant, Belgium.
I know nothing about Belgium place names and divisions, but can see in Wikipedia that the province of Walloon Brabant was created in 1995 when the province of Brabant was divided into three small provinces. Also mentioned in a different article is that Rixensart as a municipality was created from merging the former municipalities of Rixensart, Rosières, and Genval. I would assume, based on the Places database entry, that this was in 1977 although the Wikipedia article does not mention that.
Now I would have the question, was the municipality of Genval just the village of Genval? Or is the Places database incomplete? Should there be both the village and a larger municipality with the proper pre-1977 name being Genval (the village), Genval (the muncipality), Brabant (the province), Belgium? If so, then a request would have to be made to the Places Authority team through the link on the Places database page to improve the place name.
This all gets into another long running debate among genealogists as to whether to enter place names as they were at the time of the event or as they are today. With the data quality flag system, FamilySearch has definitely given a strong argument in favor of using the historical name even though as I discussed above, some exceptions are incorporated in the system. To give another example of an exception, the country of Norway has only one historical time period for all of its history and does not have not separate time periods for every time it was traded between Denmark and Sweden.
3 -
Do I need to leave a reason statement if I change the surname from "SMITH" to "Smith"? The change does not add, change or remove information. Sometimes there is already a reason statement in the box.
0 -
No, because you are not really changing anything. I also do not leave a reason statement if all I am doing is changing the name language template from Other or English to the correct language. the language template feature being expanded from a very short list to its current 45 options is a relatively recent change and so most names outside the United States and England are wrong. Fixing that is a very low priority, however, and I only do so if in the name editing box for some other reason.
1 -
@Loïc Baert - we have had discussions in the past that suggest many of us have ambivalent and / or inconsistent attitudes towards reason statements. In my view, a reason statement should come when and where the source record is attached to the profile - the reason by the side of the event (or whatever) is probably redundant given that the values tend to be immediately visible when the edit icon is clicked. So "reasons" are, in my view, overdone and I see no reason to explain a change of case - it should be obvious.
As you state, you may be obscuring something more important - particularly if the "reason" isn't a reason as such but is a note of a different intent.
1 -
@Gordon Collett mentions:
… To give another example of an exception, the country of Norway has only one historical time period for all of its history and does not have not separate time periods for every time it was traded between Denmark and Sweden …
Oh yes, that's actually another aspect that is conveniently ignored. 😉
To ask with my tongue in my cheek - If Norway is a country throughout its history, can it be part of Denmark or Sweden? Or how about Finland - was that part of Sweden or Russia at various times?
If Norway is Norway and never has anything after "Norway" in its placenames, can we please do the same for England (which is a country) and dispense with "United Kingdom" as the last element of English placenames? (Grin…)
4
