7

In Windows, string parsing in the command-line is a crapshoot, both for Batch and PowerShell. Essential command-line tools like fsutil and 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 csrutil tool.
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.

Giacomo1968
  • 53,069
  • 19
  • 162
  • 212
seagull
  • 5,426
  • 7
  • 29
  • 40
  • What does this mean: “How aggressive are Apple in internationalising terminal output?” Seems like the opposite question of the title: “Is the macOS Terminal only ever in English?” The title is clear and understandable, but “How aggressive are Apple in…” is a bit confusing because it implies that Apple is either aggressive or passive in their efforts to get non-English language options into the Terminal. Is your goal to simply have it _all_ be in English so scripts don’t break in other locales? Or something else? – Giacomo1968 Mar 05 '22 at 02:52
  • 1
    @Giacomo1968 I am simply asking how much internationalisation I should expect from Apple-forged command-line tools. My background is in Windows, where (at least) the German release of the software could be said to be "very aggressive" with its internationalisation, hindering string searching. Aggression in this sense is not a bad thing; perhaps a word like "comprehensive" or "rigorous" would have been more appropriate. – seagull Mar 05 '22 at 21:34
  • You don't need a German device to try macOS in German, a typical macOS installation includes all the translations. You set the preferred language(s) in the Language & Region panel in System Preferences.app – alexkent Mar 18 '22 at 18:20

1 Answers1

9

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 $LANG or $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.

seagull
  • 5,426
  • 7
  • 29
  • 40
jvb
  • 3,065
  • 1
  • 16
  • 18
  • This is an excellent answer. How certain are you that any tool (in this instance csrutil) will have all languages' strings embedded within it and that there are not separate tools available? – seagull Mar 04 '22 at 12:11
  • 7
    Hmm, I don't know how macOS does this, but on Linux and BSDs the translations wouldn't be present in the binary itself, but e.g. in separate `.po` files (if the program uses gettext/NLS, which many CLI apps do). Still, it is indeed better to explicitly request `LC_MESSAGES=C` than hope the translation situation doesn't change... – u1686_grawity Mar 04 '22 at 12:12
  • There is still possibility for an external translation layer... - aah, @user1686 has the details, thank you. But changing the locale hopefully should overcome that. – jvb Mar 04 '22 at 12:13
  • Would you be willing to edit/re-post your answer to accommodate that information? I'm not sure how to request `LC_MESSAGES=C`. – seagull Mar 04 '22 at 12:27
  • 1
    absolutely yes, one moment please! – jvb Mar 04 '22 at 13:27
  • Thank you very much. Do you know how I'd do the opposite to test? For example, I'm trying `env LC_MESSAGES=de_DE.UTF-8 ping 8.8.8.8` but it's just giving me the messages in English. Is this because I'm misusing the command or because `ping` doesn't give localised output? – seagull Mar 04 '22 at 14:11
  • 3
    @seagull You’re using the environment variable correctly, it’s just that most of the CLI tools on macOS just don’t have translations. Apple is very much a _GUI first_ company in terms of their mentality, they assume that normal users will never touch the terminal or CLI, so they don’t really do much to make it nice for interactive usage. – Austin Hemmelgarn Mar 05 '22 at 00:22
  • That's a very diplomatic way to word similar opinions for Apple and their "software" that I have, @AustinHemmelgarn. Thanks for the clarification. – seagull Mar 05 '22 at 02:19