Translating Dates and Places
Now that FamilySearch is available in more languages, has there been any consideration of translating portions of dates and places as possible when the web site language is changed? A few times on this board concerns have been raised that this does not currently happen and has led to users in different countries changing dates and places just to see it in their own language.
For example if I enter the the following when I have the website set to Danish:
Changing the language to English changes just the standardized versions of the data, not the user entered display data, to English like this:
I do feel this is correct and appropriate behavior to preserve the data as originally entered by the most recent contributor. This should not change. However, there is a one to one correspondence in portions of the date and place that have been entered such that they are identical to the standardized versions:
Would it be possible for the version of the data seen on the person's detail page show the corresponding items using the set language like this, without changing what is seen in the editing box?
It could frequently give some interesting combinations of languages that people would have to learn to put up with for the portions of the correct data that are not in the standardized version but they may be more willing to accept that than the current situation. Again, I would stress that the editing box should not change. It should continue to show the original data as entered by the most recent contributor and the linked standardized version in the language set by the current user.
Comments
-
This thread builds on a similar thread I began recently (link below).
I would gladly leave alone a standardized place name entered in another language that has been selected by another contributor. But how am I to know this has been done? In the text entry field (the one at the top of the edit box) why do the calendar and pin appear in only one language interface, not in the others?
The green checkmark beside "Standardized Date/Place" is not a reliable indicator. They appear even when the "standard" is a wildly wrong guess. Perhaps years ago, when the FT gazetteer (place names catalog) was small, it was a useful indicator. Now it usually only means there is some record in the gazetteer that might match the entered text.
0 -
You and I have been discussing this in your post. I'm concerned that we are still talking past one another because we are using different definitions of the same words. I'm trying to stick with the definitions FamilySearch's engineers use. You are using normal, rational English definitions.
For example, you state "The green checkmark beside "Standardized Date/Place" is not a reliable indicator. They appear even when the "standard" is a wildly wrong guess." That depends on your definition of what the green checkmark means.
The green checkmark is a perfectly reliable indicator that the displayed place name has been standardized, i.e. has been linked to a reference standard in the Places database. It has never meant that the display place name has been standardized correctly, i.e. linked to the correct reference standard. When a contributor types in a place name and the dropdown menu appears, he or she is still responsible to pick the correct place name.
If I'm entering a place:
And really mess things up:
I still get a green checkmark. The green checkmark always correctly indicates that the displayed data is standardized. But it has no opinion about whether it is correctly standardized. The computer can't judge that because all it can go by is that I told it this was correct.
To your other point, "why do the calendar and pin appear in only one language interface, not in the others?," the icons indicate the standardized value. If the Display value is identical to the Standardized value, the standardized value is hidden and the icons are put next to the display value. If the display value has more or less information than the standard or they are in different languages, both are shown and the icons show next to the standardized value. The display value is always preserved exactly as entered.
I recently posted a link to a presentation I put together about standardization and how it works in Family Tree. Did you run across it? Is is completely unofficial and only my opinion but I have never run across anything in Family Tree or any statement or presentation from someone from FamilySearch that contradicts what I have put together. Is it a little outdated now but here it is: https://docs.google.com/presentation/d/1jl6M8efrGj6Xe3MP6oyYdfFMXPSPCoJuyrS5xXj7KN8/edit?usp=sharing
If you review it, it might help us use common definitions of terms.
Then to take one more comment regarding standardizing, "But how am I to know this has been done?" It's easy to know. If there is a red exclamation point, it has not been standardized. If there is no mark, it has been standardized.
There are three ways to see if it has been standardized correctly: 1) Hover your cursor over the name and the standardized value will appear. 2) Open the Edit box and check it there. 3) Check the timeline map and see where the map pin is.
0 -
If there is a red exclamation point, it has not been standardized.
I agree.
If there is no mark, it has been standardized.
Based on my own experience of FT, I disagree. My experience is that the data has only a suggested standard until and unless the icon appears in the data field.
This conversation is clarifying for me that you, @Gordon Collett, do not go the extra step I do. So for the benefit of all readers, I will describe that step.
For event dates and place names I examine the sources attached and I edit the date and name. In the case of town(ships) and villages of the same name, for example, I check sources to determine which is correct, edit accordingly, and then select the appropriate standard, if there is one. I select it in a menu that drops down from the data entry field, not in the menu below the green checkmark.
When there is not an appropriate standard in the menu I select "None of the above" and may also go through the process of getting the appropriate standard created. I follow the process mostly for old cemeteries, as the value there is clear to me. I don't care to standardize on enumeration districts or "west part"; those details are on the attached source records and are of little value as search terms.
When I have selected a standard from the menu that matches the edited date or place name field, then and only then is the data standardized.[*] Then an icon appears in the field. And, very often, then FT gives fresh hints that are almost always correct. And when I search FT with the Find menu, results are much more appropriate when I have gone this extra step.
Once I have standardized the data there is an end to bad hints and mistaken attachments of other profiles to the tree(s) where I have taken the time to standardize.
[*] I am an old data scientist with PhD in a field parallel to genealogy. On FT I have created >10,000 person profiles and attached >100,000 sources. Perhaps FT engineers do have a private in-group vocabulary, as Gordon Collett says, but absent clear written concept statements from them I will stick with the usual meanings of technical terms.
0 -
Thanks for the thorough explanation of your views and your procedure. We're making progress.
We agree completely on the meaning of the red exclamation point.
We follow the same process in evaluating sources and determining correct place names. We both find that when a place name is correctly standardized with the closest standard currently availble that " FT gives fresh hints that are almost always correct. And when I search FT with the Find menu, results are much more appropriate when I have gone this extra step. Once I have standardized the data there is an end to bad hints and mistaken attachments of other profiles to the tree(s) where I have taken the time to standardize." Clearly if the standard value is wrong you are going to get bad hints and less obviously you are going to get better hints if you standardize based on, for example, a city, state, and country, rather than just a country.
We pretty much agree that "When there is not an appropriate standard in the menu [it is appropriate to] select 'None of the above....'" However, I maintain that the need to do this is almost non-existent.
The final point which you are misunderstanding and which limits your ability to enter the best information possible, is the fact that Family Tree stores all dates and places with two values even though sometimes only one them of the shows on a person. There is the displayed value which you see on a person's detail page and the standardized value which you only see when hovering over the displayed value with the cursor or in the editing box.
Ron Tanner, project manager for Family Tree, has stated over and over and over again in his on-line question and answer sessions that the displayed value does not need to be the same as the standardized value and that the hint, possible duplicate, and match routines use the standardized value, not the displayed value, and so function properly as long as the displayed value is correctly standardized.. The displayed value can contain as much additional information as one needs. This means that whether or not you see a map location icon on a person's detail page has absolutely no bearing on whether or not the place name is correctly standardized.
Here is a straight forward example for a person born at 1225 North 2550 East in Salt Lake City which is in Salt Lake County in the state of Utah. This can be entered in several different ways in Family Tree including:
- Salt Lake City, SL, UT
- Salt Lake City, Salt Lake, Utah
- Salt Lake City, Salt Lake County, Utah, USA
- Salt Lake City, Salt Lake, Utah, United States
- Salt Lake City, Salt Lake County, United States of America
- 1225 N. 2550 E., Salt Lake City, SL, UT
- 1225 North 2550 East, Salt Lake City, Salt Lake, Utah
- 1225 North 2550 East, Salt Lake City, Salt Lake County, Utah, USA
- 1225 N. 2550 E., Salt Lake City, Salt Lake, Utah, United States
- 1225 North 2550 East, Salt Lake City, Salt Lake County, United States of America
Even the ugliest of these can be correctly, properly, and completely standardized so that the hint, possible duplicate, and match routines work properly even though only one of them will show the map location icon on the detail page.
Correct, proper, complete entry of the standard means this:
It does not mean being limited to this:
These both function identically in Family Tree. The first is just ugly and currently frowned upon. The second has removed appropriate, important information in a misguided quest to make sure every place name on a detail page has a non-required map location pin. When the map location pin icon was first introduced there were long discussions on the getsatisfaction discussion board, a predecessor to Communities, that this exact misunderstanding would arise.
It is this valuable dual-entry system that is confusing you in regards to changing languages since currently only the standard is translated. If the display data is identical to the standard data, only the display data is shown. If the display data is properly linked but different than the standard, including just being in a different language, both the display data and the standard data are shown.
1 -
The reason a proper understanding of the dual data entry system in Family Tree is important, is that the Places database of standard place names will never be complete. For example, the municipality of Haus in Hordaland, Norway currently contains 129 sub-places, primarily villages and farms. This is about half of what should be there. I expect the rest to be there in the relatively near future. Until that time I can standardize to the level of the municipality which is sufficient for hints since historical records are usually only indexed to the level of the municipality.
However, each farm consists of between three to twelve or more sub-parcels. These are not being included in the Places database so of the over 2000 place names needed to properly describe events in Haus, only about 250 will ever be in the database. The dual data entry system allows both the accurate full place name needed for full identification of a person and the incomplete standard place name needed for hints and matching to be entered in Family Tree.
0 -
We agree completely on the meaning of the red exclamation point.
No, @Gordon Collett, we do not agree. Do you know the parable of blind men and an elephant? We each have a different part of the elephant. That we do not agree does not mean one of us is correct and the other is confused. There is no need for you to "correct" my "misunderstanding."
By the way, I think it is totally inappropriate to put a street address on a person's profile, with so much of so many profiles now public on the open web. That detail remains on the historical records and I choose to let it stay there.
The exclamation point "!" has at least 2 meanings:
- There is some error in the data; it needs editing.
- The data has been edited and no suitable choice exists in the standards database.
#2 also means someone is working on profiles from that place/time, so there is a priority need for a suitable choice of standard.
Also, a suggested standard that is correct is far less effective in terms of FT function than correctly standardized data. These two situations are not equivalent. So...
We pretty much agree that "When there is not an appropriate standard in the menu [it is appropriate to] select 'None of the above....'" However, I maintain that the need to do this is almost non-existent.
Here we really do not agree. I find I need to use the standard "None of the above...." at least weekly.
You talk about @James Tanner. According to his personal blog he stepped down years ago. I still read and watch his lessons. They are the best! And I find FT now does not work quite as he described. Do most contributors care? No. Is that a problem? On the whole, no. Perfection is the enemy of progress.
These both function identically in Family Tree.
No, in my experience they do not function identically in Family Tree backend.
Also, they do not function identically for the contributor's purposes. When the icon is missing from the data field, each and every person evaluating or editing the profile has to ask Is the suggested standard correct? and compare the two strings. This is mentally tiring and wastes time too.
0 -
I didn't say James Tanner, I referred to Ron Tanner.
You can watch as many of his recent Q&A as you would like here: https://www.facebook.com/familyhistoryron/ or here: https://www.youtube.com/channel/UCwJDNC5Ehtxqt1o4rs-0AKg
You can also watch his RootsTech 2021 presentations here: https://www.familysearch.org/rootstech/rtc2021/speakers/ron-tanner/en
Regarding your final paragraph, and your concerns, that was the purpose of my other recent suggestion for improving Family Tree at: https://community.familysearch.org/en/discussion/86445/please-consider-updating-an-individual-s-detail-page-to-include-standardized-values#latest
I think I've explained things as well as I can so I'll just end with one plea and one fact:
If you run across a place name that includes the street address for someone's residence at time of birth in 1890 ( It's really not a privacy concern at this point) or a place name that contains more information than the standard, please don't delete it. Someone thinks it is important to have the complete information right there where it is obvious.
And, you should be aware that the places you leave as "No standard selected" will likely be dumped into the Volunteer project at: https://www.familysearch.org/tree/improve-place-names/ and a volunteer will add the standard for you in order to get rid of the red exclamation point. No place name in Family Tree needs to be left with a red exclamation point. At a bare minimum you can enter the country as the standardized version.
0 -
I didn't say James Tanner, I referred to Ron Tanner.
Got it.
place name that includes the street address [...] please don't delete it. Someone thinks it is important to have the complete information right there where it is obvious.
Respectfully and emphatically no. Some reasons:
- Reviewing instances of full addresses attached to profiles, I find most are just default imports of what an indexer entered from an attached historical record. Usually this happens with death records and obituaries. Very often the death record is recent and in some cases I know the family still lives at that address. This can happen even with a death record in 1890.
- Now with more FS indexing being done by algorithm not human, the quality of judgement about whether or not to index a street address is likely to go dramatically down. So it is now even more important than ever to redact street addresses.
- The Find search tool and the FT hints system do not parse street addresses usefully. (I have done tests to confirm this.) Leaving street addresses as-is greatly degrades the quality of search results and hints, resulting in bad edits and much frustration that is mis-directed at hapless contributors who have the great misfortune of making those bad edits.
There may be special circumstances where I may leave a full address as I find it but most of the time I will delete it.
And, you should be aware that the places you leave as "No standard selected" will likely be dumped into the Volunteer project at: https://www.familysearch.org/tree/improve-place-names/ and a volunteer will add the standard for you in order to get rid of the red exclamation point.
Usually what happens is this: I submit the standard for implementation, it gets done within a few days, and the next time I encounter that PID the red exclamation point reminds me to update the place name. So I leave the flag up temporarily. I use it as it is designed to be used. No volunteer has yet come around before I get there to remove the exclamation point.
0 -
Reviewing instances of full addresses attached to profiles, I find most are just default imports of what an indexer entered from an attached historical record. Usually this happens with death records and obituaries. Very often the death record is recent and in some cases I know the family still lives at that address. This can happen even with a death record in 1890.
Now with more FS indexing being done by algorithm not human, the quality of judgement about whether or not to index a street address is likely to go dramatically down. So it is now even more important than ever to redact street addresses.
Keep teaching people to never rely on an index. With automatic algorithms this will be more important than ever. Only use the index to find the original record and enter the actual information, not the indexed information. If you feel having the address is a problem for your relatives, feel free to not put it in but do not edit other people's relatives when those users feel it is appropriate. If you have a serious concern about what another user is doing, message them with advice. I also suspect that people with ulterior motives will not be looking for street addresses in Family Tree. They will be searching obituaries.
The Find search tool and the FT hints system do not parse street addresses usefully. (I have done tests to confirm this.) Leaving street addresses as-is greatly degrades the quality of search results and hints, resulting in bad edits and much frustration that is mis-directed at hapless contributors who have the great misfortune of making those bad edits.
The Find and Hint systems never use the Display text which is where additional information is entered. They strictly use the Standard text. So as long as the Standard is set properly the routines should work just fine. I would be interested in seeing exactly what you tested because you should not have seen any difference if the information is entered correctly. As long as there is no red exclamation point, Find and Hint will work.
1 -
(Comments withdrawn by poster)
0
