Comment 16 for bug 2060769

> setting LANG=C when executing any subprocess should mitigate the presence of non-utf8 anyway

This alarmed me so I looked deeper but I think it's just a mistake and should say UTF-8. But then I noticed:

> + always pass C.UTF8 as the language when calling a subprocess
> To be extra careful, we are setting LANG=C.UTF-8...

And the code:

> + set_lang = {"LANG": "C.UTF8", "LC_ALL": "C.UTF8"}

Is it UTF8 or UTF-8? This led me down a rabbithole.

On a Xenial system `locale -a` reports C.UTF-8 and en_GB.utf8 as available, but not C.UTF8.

On a Noble system `locale -a` reports C.utf8.

So I guess it's all fine and will be treated as equivalent, including back all the way to Xenial. But I wonder if there's a way to test for this.

And now that I'm thinking about it, perhaps we want to set LC_ALL instead of LANG?

Sorry I didn't notice this in my previous review. I was focused on the SRU specifics and not thinking about it from a general review perspective.

Anyway, I think it's all fine, so accepting. I only mention the above in case it identified an area needing attention to someone else.