In Windows, string parsing in the command-line is a crapshoot, both for Batch and PowerShell. Essential command-line tools like
dcdiag return their output in strings which are internationalised to the language of the OS installation, making scriptwriting in a one-size-fits-all capacity almost impossible without factoring in support for every single language’s choice of wording and formatting.
Wherever possible I write in PowerShell (to return objects instead of strings) and use the WMI to return non-localised enumerators I translate myself via lookup tables; there will always be some tools, however, that serve as the only means on a device to gather the information required.
I am now writing a script for macOS invoking (in this instance) the
Like many *nix utilities its output is in string format. Running it produces the following output:
System Integrity Protection status: unknown (Custom Configuration). Configuration: Apple Internal: disabled Kext Signing: disabled Filesystem Protections: disabled Debugging Restrictions: disabled DTrace Restrictions: disabled NVRAM Protections: disabled BaseSystem Verification: enabled This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
Somehow the internet does not contain any knowledge on this subject I could find, so:
How aggressive are Apple in internationalising terminal output?
This is less a question about Bash or ZSH as I know these are always English, but macOS is notorious for creating incompatible Apple-specific forks of POSIX tools; further, as demonstrated above, there are many Apple-developed command-line tools intended for managing macOS systems. Should I assume these will have been translated into at least German and procure a macOS device with the German language installed on it? Or is everything just always in English?
In general, I am asking how much internationalisation I should expect from Apple-forged command-line tools.
Right now, most of those (non-.app) system administration tools are English only. This facilitates parsing of the output.
You can for example try to examine binaries like that:
strings /usr/bin/csrutil | less
in this case, there are no translations present in the binary
You might consider to set
$LC_MESSAGES locale (just locally in your scripts using
env), like in
env LC_MESSAGES=C /usr/bin/csrutil
env will launch
csrutil with the the
LC_MESSAGES environment variable set to “C”, which is a special setting translating to “act as if this program has not been localised”.
This will cause English output for this session but will have no effect on your system in general.