Localization in Swift macOS console Apps.

Just to clarify, "console" is Apple's UI for viewing data from the "unified logging system" and crash reports.

If you want to localize a command-line tool using Apple's localization framework, then you must bundle it in an app. But you can directly run the executable in Contents/MacOS and it will run in the current localization. You can even supply:

-AppleLanguages "(fr)"

on the command line to force a specific language.

All of this might only work if you are actually running a full user session and running the app in Terminal. If you are logging in remotely or something, all bets are off. That's a different environment and sometimes these things won't work.

Some Apple command-line tools get around this by linking to bundled frameworks that are, themselves, localized. I guess you could to that too.

by console, I am referring to a command line tool. My intention was to use the command line tool to test a package I am working on, as the eventual target will be a window app, I may abandon my efforts to localize my command line tool. I am using Swift Testing to unit test the package. I was hoping to hear from someone who had actually done this already.

by console, I am referring to a command line tool.

Yes. I realize that. But use of the word "console" is triggering. It's better to say "Terminal" or "command-line" to minimize the distress of your fellow developer.

My intention was to use the command line tool to test a package I am working on, as the eventual target will be a window app, I may abandon my efforts to localize my command line tool. I am using Swift Testing to unit test the package. I was hoping to hear from someone who had actually done this already.

I'm not sure what you're trying to do there. I do have an app that can operate both normally and on the command line. So I can verify that it does work. But unless you have very specific requirements, and someone paying your bills for you, stay far away from any kind of command line tool on the Mac.

The command line is a radically different environment and is wholly unsuitable for testing a normal app.

If you want to do unit testing, I guess that's fine. You can use the Xcode debugger too. Just be aware that modern versions of Xcode integrate that horrible "console" tool.

Depending on what kind of app you're developing, your development machine may not be an adequate platform for testing at all. You may need a virtual machine to isolate all the systemwide developer modifications. In some cases, you'll need a separate machine that has never run Xcode.

Good luck!

I have managed to wrap a "command line tool" into a .app package and to test my package localization. while this works it's obviously not the idle way to test a package localization. Just waiting to see if I get any more responses from someone who has actually tried to do this. Just to recap, there is nothing special here, just a command line tool with a Localization.xcstrings file that has one sentence both in English and fr-CA.

These two statements are at odds:

there is nothing special here

just a command line tool with a Localization.xcstrings file

Doing this is special because, in general, we don’t localise command-line tools on the Mac. Specifically, the traditional Unix-y way of localising command-line tools [1] is not standard practice on Apple platforms. Rather, Apple platforms use their own mechanism, based on the bundle structure. This mechanism is intended for GUI apps, and you have to jump through hoops to get it to work from the command line [2].

If you’re doing this just for testing, I recommend that you use Xcode’s testing infrastructure. It has options for overriding the language and region.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Rooted in the LANG environment variable.

[2] If you do some spelunking you’ll find a bunch of info about how things actually work, for example, the AppleLanguages environment variable. However, these are considered implementation details, not API.

Thankyou Quinn for your response, I thought it would be easier to write a CLI than a full GUI to test a package. I did manage to write a CLI with a bundle structure and yes, there were many hoops to jump through. but it does work.

I thought it would be easier to write a CLI than …

Yeah, I know what you mean, but recently I’ve moved away from that approach:

• For low-level stuff, I tend to put the test code into a unit test. This is just as easy to debug as a command-line tool, but it has the advantage that, as you exercise various code paths, you build up a corpus of unit tests that ensure that things continue to work in the future.
• For GUI stuff, I lean into Xcode’s preview feature.
• Or just do my experimentation in an target.
• And there’s Xcode’s UI testing support. I don’t use that a lot but, in my defence, UI stuff isn’t my focus.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"