On Mon, Jul 05, 2021 at 10:57:21AM +0100, Chris Clayton wrote: > > This isn't what I expected as you have a locale "en_US.utf8" which I > > understand is the same thing as "en_US.UTF-8", which is one of the > > locales tried in 'gdt' in tp/Texinfo/Report.pm. > > That's not a surprise to me. My system was created by me using the Linux From > Scratch guidance. > I freely admit that I was all at sea when it came to which locales I was > likely to need, so I tried this, that and > t'other and when I found a setup that seemed to suffice, I quit while I was > ahead. > > That was years ago and I've learned alot in that time. However, "good enough > is good enough" and "if it ain't broke, > don't fix it" where maxims I applied throughout most of my 30+ year career in > IT. Now it's broke, so I've regenerated > the locale stuff on my system to include en_US.UTF-8 and the texinfo-6.8 now > completes without error.
That is useful to know but also frustrating as it implies there is a difference between en_US.utf8 and en_US.UTF-8 and I don't know what that is. I've got en_US.utf8 on my system when I run "locale -a" but that test passed for me. All I can think is that something might have gone wrong when you installed the locales. > So it's close to a case of PEBKAC. It might, howver, be an idea for the test > to be skipped if none of the locales it > requires to succeed are present. > > Thanks for your help. Yes I agree, if we can't make the test pass in the case that no locales are installed. It's a frustrating problem as we aren't using the locale information for the user, we are using it for a document that is being produced that could be in a different language. Whatever locales the user has installed should be irrelevant. Some time I will look over the gettext documentation again and try to see if there is a better way of doing this. A quick fix would be to downgrade the bundled libintl-perl to the version used for Texinfo 6.7 but that would remove some other fixes and improvements.
