Note: groups.io will be down for maintenance on Monday, September 26th, starting at 9AM Pacific Time (4PM Monday September 26, 2022 UTC), for approximately one hour.
Gerriet M. Denkmann
macOS 12.5, Xcode Version 8.3.2 (8E2002)
App with Base Internationalisation; Development Language = English, localised for German.
Target = “TargetName” (probably same as PRODUCT_NAME)
Both InfoPlist.strings (Base) and InfoPlist.strings (German) have:
CFBundleDisplayName = “RealName”;
Activity Monitor shows: “RealName”; as do both:
[NSBundle mainBundle].localizedInfoDictionary[@“CFBundleDisplayName”] and
But Finder shows “TargetName” (if system language = English).
When I log in as a user with system language = German, Finder shows: “RealName” as it should.
I find this very confusing and not quite what I expected.
How can I persuade Finder to always use the value from InfoPlist.strings regardless of system language?
Gerriet M. Denkmann
On 8 Jul 2017, at 20:06, Gerriet M. Denkmann <g@...> wrote:Finder (at least in macOS 12.5) seems to work like this:
When an app.bundle is copied into some folder (and only then), it reads TheApp.app/Contents/Resources/<system language>.lproj/InfoPlist.strings and uses the value of CFBundleDisplayName to display the app’s name.
It never reads Base.lproj, even if the system language = Localization native development region = CFBundleDevelopmentRegion
The problem is that Xcode (obviously unaware of this Finder peculiarity) does NOT allow English as an additional localisation (because the development region already is English; so English speaking computers should just use Base.lproj).
What can be done?
On Jul 9, 2017, at 07:45 , Gerriet M. Denkmann <g@...> wrote:
I’m not sure I understand completely, but I think you’re missing one point.
As with the base localization, which (as you say) means that Xcode treats it as the “localization” for the development language, and you omit the actual localization for that language (English in your example), the Finder AFAIK uses the “unlocalized” bundle file name as the “base” file name. (Because it’s a bundle, it’s actually a directory name, but the principle is the same.)
If you the developer are on an English system, you can change the “base” file name any time you want, after the app bundle is created, by renaming it in the Finder. I do this all the time for my apps, and the final “base” name is nowhere in my Xcode project settings. Again AFAIK, this has *no* downstream consequences for localized non-English systems — as you’ve seen, the original name is irrelevant when the Finder actually applies localization to the name.
If you want to create the app with the desired English name during archiving, rather than renaming it later, then you must change build settings. AFAIK the one that controls the bundle’s file name is “Product Name”. The default value of this setting is “$(TARGET_NAME)”. If you don’t want the target name, you can put anything you want in there, minus the extension.
So, I assume that if you put the desired English name of your app in the Product Name setting, you’ll get the results you want in all localizations.
Gerriet M. Denkmann
On 10 Jul 2017, at 01:13, Quincey Morris <quinceymorris@...> wrote:Here the result of my investigations so far:
1. The file-system-name (shown by ls command) = PRODUCT_NAME.
The PRODUCT_NAME is initially set to $(TARGET_NAME).
Changing the Target Name to: “New name” changes the Build settings to: PRODUCT_NAME = “New name”.
2. The app-menu and the About Panel show “Bundle name".
3. The Finder shows “Bundle display name" but only if:
3a. Info.plist contains Bundle display name = $(PRODUCT_NAME)
3b. <current language>.lproj exists, contains InfoPlist.strings and this has CFBundleDisplayName
The Finder does NOT fall back to Base.lproj for current language = development region (as everybody else does).
I fixed my problem by creating a copy of Bundle.lproj/InfoPlist.strings, putting it into an en.lproj folder and adding this in Xcode to the resources of my app.
Sure I could also (as you mentioned) change the PRODUCT_NAME (which has the additional advantage of file-system-name = Finder-name).
But I don’t like the asymmetry of it:
Change the Finder name for development region: change PRODUCT_NAME in Build Settings
Change the Finder name for any other language: change CFBundleDisplayName in xx.lproj/InfoPlist.strings
On the other hand, if the Finder name is the same for all languages, then using the PRODUCT_NAME is clearly better.
Thanks for your help!
One more thing:
/* Class = "NSMenuItem"; title = "AppName"; ObjectID = "1Xt-HY-uBw"; */
"1Xt-HY-uBw.title" = "AppName";
/* Class = "NSMenuItem"; title = "Quit AppName"; ObjectID = "4sb-4s-VLi"; */
“4sb-4s-VLi.title” = “Quit AppName";
I tried to change this to:
"1Xt-HY-uBw.title" = "$(PRODUCT_NAME)";
“4sb-4s-VLi.title” = "Quit $(PRODUCT_NAME)";
But of course the last line does not work.
Could this work?
There are quite a few place where the AppName is hardcoded: About, Quit, Help (maybe more).
On Jul 9, 2017, at 21:15 , Gerriet M. Denkmann <g@...> wrote:
My guess is that it asymmetric for historical and/or compatibility reasons. There’s also something about the Finder storing a “.Localized…” named file inside the bundle, but I don’t know if that’s still a current thing.
But at least you have a way forward that’s set-and-forget?