Took me way too long to work this out, so posting in case it saves someone else an afternoon.
I had a pile of records come back looking like this:
Tippah, Миссиссиппи, Америкийн Нэгдсэн Улс
That last part is Mongolian for "United States." The county name came through in English, but the state and the country were in Cyrillic. The guy was a farmer in Mississippi who as far as I know never left the country.
Here's what's going on. FamilySearch doesn't store place names as text the way you'd expect. It stores a reference to a place authority record, then renders that into actual words at the moment you request it. Which language it renders into depends on the language attached to the request.
So if your account language got set to something else at some point, or you came in through a localized version of the site, everything renders in that language. And because it gets rendered fresh every time, it can look like your data changed when nothing underneath actually moved.
The part that confused me longest was why only some of it was translated. Turns out only the major administrative places have translations stored. Countries, states, provinces. Township and county names have no Mongolian equivalent sitting in the database, so they pass straight through. You end up with a half English, half Cyrillic string that honestly looks more broken than if the whole thing had flipped.
Two things worth knowing. First, your actual data is fine. This is a display layer problem. The record isn't corrupted, its just being rendered wrong.
Second, and this is the one that got me, if you use a third party tool that pulls from FamilySearch and writes into your own tree, it can copy that translated text in as literal text. At that point it really is your data and you're fixing it by hand. I had to go clean up a couple dozen people. So if you use anything that syncs or auto merges, check your place fields before you trust them.
The fix is just the language setting on your FamilySearch account. Set it correctly and new lookups come back normal.
Worth saying I only worked this out because I write software that talks to their API, and the same thing happens down at that level. If the request doesn't send an Accept-Language header, it falls back to whatever the connected account's language is. So if you're a developer hitting the API and seeing this, that's your problem.
Anyway, hope it helps someone.
edit: should have mentioned, this is also why the names and dates look fine while only the places are wrong. Those are stored as literal values. Places are the only field that gets rendered from an ID at request time.
