Recent change in Hungarian indexes removed data and made search function unusable
Hi there! I have used FS for years now, but I never had to report an error before, so I hope I'm doing it in the correct spot.
Indexed Hungarian church records in the past used to utilize the Western name order ("First - Middle - Last"), contain the full date of christening (as in Hungary, this corresponds closely with the date of birth), event place (including separate parishes within the same city or town), sex, and parents' name.
I noticed that there were a few recent changes. Many records now use the Eastern name order ("Family name - Given names"), which is correct for Hungarian records - this is a welcome change. I also see that all "event place" info has been replaced by standardized places, which is also a positive change, as long as it is possible to still see the origin of the record - so far, it is, listed under "Event Place (Original)". In the new "Event Place", the name of the country is also represented in Hungarian now "Magyarország" as opposed to "Hungary", which, to me, is a neutral change.
However, some negative changes also occurred that cause problems. The least annoying at the moment is that female records have all been changed, every girl baptism is listed as "Sex: Male" now. The worse one is that all baptismal dates are now missing the month and day, only the year can be found. This means that instead of creating accurate profiles for relatives on the world tree with a few clicks as before, now every document has to be inspected separately in order to find out the actual birth/baptismal date. In some cases, the family name of the child is now also missing, even on records where they were there previously. Lastly, I am unaware why, but the search function seems to have ceased working with these records as they did before. Maybe this is due to the new name order, the missing complete dates, the changed country name, or something else, I'm not sure. This is also reflected in hints: people that had 10+ hints for me before, now have none or very few.
Examples:
https://www.familysearch.org/ark:/61903/1:1:X8DY-BZG
This one (Haushoffer Catharina) is a typical example of the error: incomplete date of baptism, and a girl showing up as "male".
https://www.familysearch.org/ark:/61903/1:1:XX3D-5YT
This one (Anna Radits) is similarly incorrect now, but it's also an example for the missing family name. I remember this one to be correct in the past.
https://www.familysearch.org/ark:/61903/1:1:XXHF-MML
This record (Rozalia Asztalos) seems to be completely unaffected by the changes as of now.
I would like to know if this will be corrected in the near future. I love spending my extra time with genealogy, but sadly, these changes make further research really hard / impossible.
I hope the issue is temporary and that maybe my question helps to locate the error. I would like to thank everyone at FamilySearch for all the work put into this website - FS has progressed very rapidly in the years I've used it, and I love to see it grow!
Answers
-
Ugh. It looks like FS has run a "standardization" process on some -- but not (yet) all -- of the Catholic baptism index entries, and as usual, the process mostly Got It Wrong. It replaced whatever was in the gender field (probably either "n" or "l") with the alphabetically-nearest gender (although interestingly, it does not seem to have done so with "f", possibly because the non-equivalence was explicitly called out in the algorithm?), and it standardized the dates by dropping all of the parts that it couldn't easily parse.
It also seems to be applying Hungarian name order totally without regard to the fact that better than three-fourths of the records are actually in Latin, resulting in stupidities like "Kovats Georgius".
The dates we can fix, piecemeal, but the gender field is not editable, and we can do nothing about the presentation of the names or the missing surname field. Yes, the records seldom explicitly list a child's surname, but omitting it from the index makes the records effectively unfindable, because the search algorithm assumes its presence.
FamilySearch, please roll back these changes. They have resulted in serious data loss and corruption.
1 -
Julia, thank you so much for confirming the issue! I'm glad I'm not the only one who noticed. You are also correct that it made the search function unusable for me.
Although I must say I'm actually content with the Hungarian name order being used for all Hungarian records. I'm not bothered by the "Kovats Georgius" type entries as I would have to fix the name anyway when I apply them to the world tree. (One thing that would be absolutely stellar is if when adding such records to the tree by creating a new person, FS would create that person automatically set to the Hungarian name order, eliminating the need to do it manually with every single one.) However, no matter our preference on name order, this issue is just a mild annoyance for some. The lack of dates, family names, wrong sex, etc. are actual errors hindering the use of FamilySearch until corrected in some fashion.
0 -
The index-based profiles on Family Tree are old, legacy data. They are no longer being generated, so the corruptions to the index will only affect the hinting system that normally offers up the index record corresponding to the profile.
I don't think the hinting algorithm is set up to ignore gender, so the profiles based on the now-corrupted part of the index likely will no longer have Record Hints for attaching the relevant source citation. The errors will not affect profiles that have already had the source attached, except for making it harder to verify the name and date when looking at the Sources tab.
(The profiles were imported from FamilySearch's previous system(s), which had no procedures for combining entries; this explains all the duplicate parents associated with these "auto-profiles". There's some sort of LDS voodoo explaining why it's mostly the female baptisms that have profiles.)
0 -
Oh, I know that those are legacy data. I may not have used the correct terminology. What I meant is the option when I add a new family member to a person based on a hint or a record I found. For example, I find a record of a child with the parents I already have on the tree. Through "Review and Attach", I attach the record to the parents, then I create a profile for the child who did not have one previously. When I do that, even if the record uses the Hungarian name order, the child still gets created with the Western name order, and I have to set it manually if I want to change it. I think it sort of defeats the purpose of this change - but I would not be complaining as long as the old functionality still worked.
You are also correct about hints, many of them have disappeared now due to the error.
As for the LDS voodoo, it likely has something to do with how ordinances were done (as you can only do those for people with an FS ID, and I believe that has been the case for a long time).
1 -
It's a bit disappointing that there is no acknowledgment or any communication from FamilySearch regarding this. Is there any way to send direct feedback or report an issue?
1 -
@István Jamrik there is a Feedback tab on the right side of each record. You have the option to report specific issues on a record or a broader issue about the site.
1 -
Thank you! I will give it a try.
1 -
Thank you for reporting this issue. We apologize for the problems it is causing you. It is being sent to another department. They will contact you if they need any further information, and hopefully let you know if it is anything that can be fixed in the near future. We do know that there are a lot of things being worked on, and some of them take a long time to fix.
0 -
We tried searching the whole collection for the example you gave with the missing surname. We did not find the desired result when looking for Anna Radits 1861.
We did find it when we searched for Anna 1861 with father Radits:
We did not find it when searching for Anna Radits 1861 with father Radits:
Knowing that there is a problem, it is possible to find the desired result, but nobody would know to do that.
Were there other odd things you noticed when searching?
0
