LCR Membership Record Place names guidance

Is there any guidance on entering place names into membership records? Particularly, should locations be in English or the local/native language? Are Unicode/accent characters accepted? I apologize if this has been answered elsewhere in the forum, but I couldn't find an answer.

In your location, you are only able to enter locations in English. If you are updating the membership record for a member who was born in a foreign country, you will need to enter the English name of the birthplace.

In non-English areas, the birthplace can be entered in the native script.

Thanks for the response. In general, it seems like for non-US places, I should seek to provide <location>, <2nd level division>, <1st level division> as guided by a resource such as Wikipedia's List of administrative divisions by country? I'm still curious if Unicode/accent characters are accepted in the free-form Birthplace or Marriage Place fields, so long as I'm not switching away from Latin/Roman script (e.g. Cyrillic, Arabic, etc)? I understand the Birth Country, Mission Country, and Marriage Country are drop-downs and locked into a defined set of values. Are the LCR free-form place names getting linked/validated against a place database, such as the FamilySearch Place Database and then localized?

Possible examples for place names:

English:
Mexico City, Federal District
Mexico City, D.F.

Spanish:
Ciudad de México, Distrito Federal
México, Distrito Federal

I'd stick to the "straight ASCII" character set. While I'm sure the systems have been modernized, the old systems were that way.

It seems to me that the "risk/reward" sides on "keeping it simple". While using the accents may be more accurate, the simple version is completely understandable and the most likely to work when automatically translated.

Just for comparison, I input "Mexico City, Federal District, Mexico City, D.F." into FamilySearch, and it simplified it to "Mexico City, Mexico". That's cheating because on the backend, FS "knows" the location and will display it in whatever language needed. I don't know as the membership system is doing anything similar, but I'd take that as a clue.

greenwoodkl wrote:In general, it seems like for non-US places, I should seek to provide <location>, <2nd level division>, <1st level division> as guided by a resource such as Wikipedia's List of administrative divisions by country?

That would be nice. We're at the mercy of the clerk and how he chooses to enter the data, but it's nice to have clerks that try to be thorough with what they put in. We were looking at some example records last week with another team and saw one where the birth place had been entered as "AF". <sigh/>

greenwoodkl wrote:Are the LCR free-form place names getting linked/validated against a place database, such as the FamilySearch Place Database and then localized?

No.

We're at the mercy of the clerk and how he chooses to enter the data, but it's nice to have clerks that try to be thorough with what they put in.

As a newly-set-apart assistant membership clerk I'm trying to clean up some poorly-entered place names, none quite as abbreviated as AF. The issue I'm seeing more often is repetition of country name in the place plus the country dropdown. I do wish there were some more custom report options in LCR to highlight such data quality artifacts but will use MLS for now.

greenwoodkl wrote:As a newly-set-apart assistant membership clerk I'm trying to clean up some poorly-entered place names, none quite as abbreviated as AF. The issue I'm seeing more often is repetition of country name in the place plus the country dropdown. I do wish there were some more custom report options in LCR to highlight such data quality artifacts but will use MLS for now.

You could have your ward clerk create a custom report that shows name, birth place, and birth country. That would give you a pretty easy way to see all of the birthplace info and clean them up.

You can't create the report yourself -- that is limited to bishops and ward clerks.

I had noticed on the Access Table that they could create the reports, but I couldn't see any listed in the menus. I wasn't sure if that meant none have been created or only those with access to create could utilize?

Report access is limited to that group.

So they would create a custom report and only they could access it. Are there export options where they could share the results with me? Otherwise, it seems like a fruitless endeavor to push for a report I can't utilize. It seems that LCR has moved away from many export options that MLS had. I think it would be beneficial for other LCR users to be able to create custom reports within the scope of their access.

greenwoodkl wrote:So they would create a custom report and only they could access it. Are there export options where they could share the results with me? Otherwise, it seems like a fruitless endeavor to push for a report I can't utilize. It seems that LCR has moved away from many export options that MLS had. I think it would be beneficial for other LCR users to be able to create custom reports within the scope of their access.

They could create the report and print it for you. Then you can use it as a checklist to update the membership data as needed. Not as convenient as creating the report yourself, but workable for a one-time exercise, in my opinion.

For reasons not fully disclosed to most of us, the church has limited access to the custom report function. You can always submit feedback on LCR with your logic on why access to the custom report would assist you in your calling, but that's about the best I can recommend.

davesudweeks wrote:For reasons not fully disclosed to most of us, the church has limited access to the custom report function.

If I was a betting man, it would be that getting the "within scope of their access" part to work and fully tested was too resource intensive given the other priorities queued up for the developers.

That's not to say it won't happen, it just has too much competition for attention.

russellhltn wrote:If I was a betting man, it would be that getting the "within scope of their access" part to work and fully tested was too resource intensive given the other priorities queued up for the developers.

That's not to say it won't happen, it just has too much competition for attention.

Oh, I have many ideas as to possible reasons as well, but they are just speculation which will not help anyone so I choose to wait for further news/developments.