On Oct 30, 2022, at 4:16 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2022-10-30 13:57, Guy Harris wrote:
That statement may also hold true for some other UN*Xes.
My impression is that users of NetBSD, OpenBSD etc. are less likely to run into this problem, because they don't have the complication of configuration issues inherent to macOS's brew-based system that is combined with automatic migration and multiple-architecture binaries and libraries.
The statement to which I was referring is
Unfortunately, a downside of macOS not providing an implementation of the gettext API (the first implementation of which was, I think, in Solaris) is that zic by default lacks internationalization support on macOS.
I.e., the only *BSD on which you'll get internationalization by default is NetBSD; the others won't give you libintl out of the box, just as macOS won't - you'd have to install it yourself. So you'll get $ echo "Ceci n'est pas une pipe." | LC_ALL=fr_FR.utf8 zic - "standard input", line 1: input line of unknown type $ echo "Ceci n'est pas une pipe." | LC_ALL=fr_FR.UTF-8 zic - "standard input", line 1: input line of unknown type with the built-in zic, just as you will with the zic that ships with macOS, and you'll get that with a zic you compile from source unless you have installed libintl. (And you'll probably also need a version of the tzcode that has .pc files and installs them. I'm not seeing any files with translations for "standard input" or "input line of unknown type" in the current Git repository for tz.) I.e., I'm not seeing "versions of zic that a user builds from source, on a system with libintl installed, will, by default, now lack internationalization support on macOS" as a change that will, in practice, disadvantage many people.