Hi all, I am trying to localise the purpose strings in my Info.plist file, for that I am using the InfoPlist.xcstrings file. In my app I have multiple targets, each with a different display name, the problem that I am facing is that when the InfoPlist.xcstrings file is automatically updated in each build the CFBundleDisplayName is always added to the file which forces me to have just one name for every target. So, I would like to know how others approach this problem and how can I resolve my situation. The ideal solution was that there was a way for me to disable this automatic generation (or at least trigger it by hand) once I have added all the purpose strings that I want to localise in multiple languages. If not, having one InfoPlist.xcstrings per target will also so it, although it will be a little harder to maintain. AFAIK, there's no documentation on the InfoPlist.xcstrings generation, so any help will be very much appreciated. Thank you all in advance

Description of Problem We are exporting strings for localization using the command line tool xcodebuild -exportLocalizations. However, Xcode does not respect the scheme or configuration that we specify. It always builds the Debug configuration. This results in extraneous or incorrect strings being exported, e.g. strings from SwiftUI previews. Note: Exporting strings from within the Xcode IDE respects the selected scheme and configuration. However, exporting from the command line does not. Our real app’s Xcode project cannot export strings from within the Xcode IDE at all, as Xcode always attempts to build our iOS project using the macOS SDK, which obviously fails. So we must use the command line export. Also, a command line export is required for CI/CD pipelines. Sample Code ContentView.swift import SwiftUI struct ContentView: View { var body: some View { VStack { Text("Always") #if DEBUG Text("Debug-Explicit") Text("Debug-Implicit") #else Text("Release-Explicit") Text("Release-Implicit") #endif } .padding() } } // MARK: - Previews #if DEBUG struct ContentView_Previews: PreviewProvider { static var previews: some View { VStack { Text("Preview only string") ContentView() } } } #endif Localizable.strings /* Appears in all builds */ "Always" = "Appears in all builds"; /* Appears in debug builds only */ "Debug-Explicit" = "Appears in strings file but only used in Debug builds"; /* Appears in release builds only */ "Release-Explicit" = "Appears in strings file but only used in Release builds"; Steps to Reproduce Clone this project into a directory on your Mac, but do not open it in Xcode. git clone https://dev.azure.com/slardieri/ReproRepos/_git/ExportRepro Open a Terminal window and cd into that directory. Run the following command to export strings for localization: xcodebuild -exportLocalizations -sdk "iphoneos" -exportLanguage "en" -localizationPath "./ExportRepro Localizations" -project "./ExportRepro.xcodeproj" -scheme "ExportRepro Release" -configuration "Release" Open the generated en.xliff file and observe which strings were exported. open "./ExportRepro Localizations/en.xcloc/Localized Contents/en.xliff" Expected Behavior Based on the Release configuration specified in the command, you should see both the Release-Explicit and Release-Implicit strings, but not the Debug-Implicit or Preview only string. Actual Behavior What you actually get are the Debug-Explicit, Debug-Implicit, and Preview only strings, but not Release-Implicit.

With the announcement of the new Apple Translate app and offline support, are there any URL schemes that we can use in our apps to send text to the Translate app and have it open and translate the sent text?

I have a custom localisation function in my project that enforces the inclusion of the bundle parameter (specifically so that Swift packages are forced to include the Bundle.module value). While migrating to String Catalogs, I noticed that my custom localisation function wasn't being recognised by the automatic extraction that the Swift compiler is doing, but only in my Swift package targets. Is there a way to set something like LOCALIZED_STRING_MACRO_NAMES in Swift Packages?

I have one project where I have XYZ scheme and target. I have Localizable.string under XYZ target for localization. I want to create a ABC target (duplicate of XYZ) and set custom language support for it. Let's say I have english, french and german for XYZ, I want hindi, japanese and chinese for ABC. I did the below steps I went to Manage scheme and duplicated the XYZ (duplicate scheme = ABC). I added new localization file only for ABC (LocalizationForABC.string) and made sure those reflect in File Inspector -> Target (only ABC selected) and also checked in Build Phases -> Copy Bundle Resources (LocalizationABC exists). When I run the ABC target under let's say french, it works fine but when I build the project ABC, and remove french from XYZ, ABC is broken and it only runs in english. Am I missing something here ?

I'm encountering the following error while attempting to archive my app: unable to read input file: fopen({~}/Library/Developer/Xcode/DerivedData/{project name}-gxaapsrbutxnmwderhyslgnfznrl/Build/Intermediates.noindex/ArchiveIntermediates/{project name}/IntermediateBuildFilesPath/{project name}.build/Release-iphoneos/{project name}.build.lproj/Localizable.strings, rb): No such file or directory (2) (in target '{project name}' from project '{project name}') I've anonymized {project name} and {~} in the path for privacy reasons. It seems like the error pertains to not finding the localizable.strings file. Prior to encountering this error, I made the following modifications: Originally, my project used the legacy localizable.strings for localization, but I recently switched to using a string catalog. I added 8 additional languages alongside the existing Base, English, and Korean. I'm writing into the new Localizable.xcstrings file using some python scripts. When I open it in Xcode after pasting, all rows appear correctly. This error occasionally occurred even when I 'run' the app, but clearing derived data and cleaning the build folder resolved it temporarily. However this error happens always when I try to 'archieve' this. Despite copying the project due to difficulty resolving the issue within the project itself, I'm still encountering the same problem. Below are the Build Setting and Build Phases configurations: Build Phases > Compile Sources and Link Binary with Libraries do not include localizable.strings. Build Settings > Localization is set to "Yes" for all. I've tried various methods found online without success, and similar cases are scarce. Please help me resolve this issue.

Hello, I want to use Automatic Grammar Agreement to localise a string in my app, let say "three remaining activities". The string "three" is obtained by using a NumberFormatter with a numberStyle set to .spellOut (so I'm not using an Integer) var formatter: NumberFormatter = NumberFormatter() formatter.numberStyle = .spellOut let formattedCount: String = numberFormatter.string(from: count as NSNumber)! Text("key_with_string_\(formattedCount)") In my string catalog, I have translated the key key_with_string_%@ like this ^[%@ remaining activity](inflect: true), but it does not work. I've tried to add the integer value used by the number formatter in the key key_with_string_%@_%lld but it does not work. Should Automatic Grammar Agreement work normally just by using the formatted string provided by the NumberFormatter? If not, is there a way to specify to use a secondary variable (my count integer) to switch between different categories like one and other automatically? Thanks ! Axel

Hi This issue is present both in previous, current, and beta versions of Xcode When a project has localization in packages, Xcode FAILS to export localization The reason is that when trying to export in this configuration, the compiler will try to export using macOS sdk, but if the package support only iOS of course will not find symbols for frameworks and functions that are scoped only for iOS This behaviour is not changed when the platforms for the package includes ".macOS("99") has I've found as a suggestion online The only way to perform this operation is to run, from CLI the following command xcodebuild -exportLocalizations -localizationPath . -sdk iphoneos -project TranslateTest.xcodeproj -exportLanguage en The problem is that this command will not work when one of the packages contains a macro. The following error will return in CLI if the macro is used (if the package is only imported no error appears) error: external macro implementation type 'MyMacroMacros.StringifyMacro' could not be found for macro 'stringify' I've found online some suggestions from apple folks that says to replace -sdk iphoneos with -destination 'platform=iOS,name=Any iOS Device’ in case your project contains a macro, but this changes nothing in the final result, the export will fail I'm providing a zip for apple in the radar (cannot upload zip here) that contains 3 example project for the 3 cases: A project without any packages that can extract its strings with any mode A project with a package that can only extract its strings only by CLI A project with multiple packages, one of which has a macro, and it can never extract its string This problem affects any possibility to have a modularised application with localisations, macros, and packages. Feedback FB13902424

There must be some rules that determine which set of localized strings of an Apple Wallet pass (.pkpass) is used when the choice is not obvious. For instance, I made a pass with localization folders ko.lproj (Korean) pl.lproj (Polish) zh-Hans.lproj (Chinese). If any of these languages is in my iPhone's preferred languages (Settings... General... Language & Region), then it's easy: the first one on that list is used. But what if the list does not have any of them? When I try, it seems the Chinese localization is chosen by the Wallet app. Without the Chinese localization folder, it is Korean. If I also add ar.lproj (Arabic) then Arabic is chosen. I can't discern any system here. How does Wallet choose the default localization?

Recently we introduced a macro to our workspace. Builds fine inside Xcode, as well as builds fine using xcodebuild. Seemed like everything was working perfectly until we went to export localizations. If we attempt to do it from Xcode itself it will fail as it attempts to build macOS (which is a totally different issue) We have this process automated though so it is being built via command line: This is the exact prompt we're running xcodebuild -exportLocalizations -localizationPath ../output -workspace <workspace>.xcworkspace -exportLanguage en -sdk iphoneos This will do the normal Xcode package/build graph resolution and generation and begin building. Eventually when it hits a use case of the macro it will fail. In each case when it fails it will have something like this: <unknown>:0: warning: compiler plugin not loaded: '<output-path>/<our-macro-package>; failed to initialize <path-to-usage>.swift:29:35: error: external macro implementation type '<our-macro-package>.<our-macro>' could not be found for macro '<our-macro>()' If I go to that output path I can see the macro package executable there. If I look in the build command for the file I can something that looks like this: ... -load-plugin-executable <output-path>/<our-macro-package>\#<our-macro-package> ... If attempt to build, without the -exportLocalizations flag, it works and builds just fine. I'm not sure what's happening here. Has anyone seen this? Macros+export localizations?

I have an app localized to three languages, English is the base language. But the app description in Appstore doesn't mention English, only two others. What's the cause and how to fix it?

Hi, we recently noticed an issue when exporting the localization files from one of our projects. So in the exported .xliff file, there is a string that has been varied into the plural forms of zero, one and other. We had translated them into Japanese. But in the .xliff file, the source element of this string in plural ONE is missing, while the target as well as the others plural strings are showing correct. We've also checked in Xcode (15.3), the content of whether the source or target are there for all the plural forms, as you can see below. The same issue (same string) also exists in Korean and Russian, but not in other languages we support (like German, French, Chinese), which is a bit weird to us. Does anyone have any idea why this is happening and how can we fix it?

We have a workspace with three projects in it. Trying to export localizations for the workspace fails with the "ComputeTargetDependencyGraph failed with a nonzero exit code" error but with no additional information to track down the failure. Here are the exact steps I've tried: Click Menu Bar &gt; Product &gt; Export Localizations &gt; Workspace (the first item in the menu) A few moments later, an error alert pops up that says "Unable to build project for localization string extraction" In the build log tab, it shows this: If I try running xcodebuild -exportLocalizations -localizationPath ~/ExportedWorkspaceLocalizations -workspace &lt;workspaceLocation&gt; -exportLanguage en, the same "ComputeTargetDependencyGraph failed with a nonzero exit code" error message appears. Exporting the three projects individually works great when I go to Menu Bar &gt; Product &gt; Export Localizations &gt; Select one of the three projects instead of the workspace. Has anyone else run into this error? I haven't been able to find any additional build logs that would point to a more concrete error.

Hey, I'm trying the new strings catalog, and I have a script that I would like to run on the xcstrings json. My question is there some documentation on the json format (what keys can it have, and values)? Also, I didn't try it yet, but what if I set for example 50 languages and 1000 localization keys, is that json really scalable? It could grow quite large, would xcode still keep it as one big file, or it would somehow split it into chunks? Would be happy for any info from the dev teams, thanks!

Running on a Core i9 MacBook Pro with macOS 13.4 (22F66) and the Xcode 15 beta. Running "Export Localizations" seems to work fine with smaller projects, but in my larger project, it's not working unless I do a "Clean" first. The way my project is set up is that the main project depends on a few dynamic frameworks built from other Xcode projects which are incorporated into the main project and set as dependencies. What happens is that I'm getting the error "Unable to build project for localization string extraction. See the build logs for failure description." In the logs, I see that the Link (x86_64) step succeeds, but the Link (arm64) step fails, with a Could not find or use auto-linked framework 'MyFramework' message for each framework dependency that's in another Xcode project. This would suggest that the dependencies are being built only for x86_64. If I clean the project, the "Export Localizations" will then succeed, but if I do a regular build again, "Export Localizations" goes back to being broken. What I think is happening is that the "Export Localizations" workflow is using the same binaries as Debug builds, and leveraging any existing Debug builds that happen to exist instead of rebuilding them, but it's also trying to build for all supported architectures whereas a Debug build usually only builds the current one. This, of course, causes a failure to link to dependent libraries/frameworks, since they don't have binaries for the non-active architecture. Is there any way to turn off building for all architectures for the "Export Localizations" workflow? I don't think it's necessary just for localizations TBH.

Dear Apple Developers, I am writing to kindly request the addition of a few missing characters to the Persian keyboard in order to better support the South Azerbaijani language (ISO 639-3 code: azb). South Azerbaijani is a Turkic language spoken by over 30 million people living primarily in northwestern Iran. The missing characters needed for proper South Azerbaijani language support are: ؽ (U+063D ARABIC LETTER GHAIN) وْ (U+0648 ARABIC LETTER WAW, U+0640 ARABIC TATWEEL) ۇ (U+06C7 ARABIC LETTER U WITH SMALL V) ۆ (U+06C6 ARABIC LETTER OW WITH SMALL V) Currently, ؤ (U+0624 ARABIC LETTER U WITH HAMZA ABOVE) is accessible by long-pressing the و key, which is great. However, the other characters are missing. My suggestions would be: Add ؽ to the long-press options for the ی key Add وْ, ۇ, and ۆ to the long-press options for the و key Introducing these few missing characters would greatly enhance the typing experience for South Azerbaijani users and allow for proper rendering of all letters in this language spoken by millions. Thank you for your consideration. I would be happy to provide any additional information needed. This small update would mean a lot to the South Azerbaijani community. Respectfully, Araz Gholami

It looks like Arabic is not supported by BetaBuildLocalizationCreateRequest https://developer.apple.com/documentation/appstoreconnectapi/betabuildlocalizationcreaterequest/data/attributes Is there any way to update this localization programmatically? If not, any timeline when it will be available? The goal here is to add "What's New" notes automatically in CI

I'm working on a large SDK of UI frameworks. We have hundreds of strings and an older implementation that resolves them by looking up the key in the main, then current (module) bundles. This allows clients to tailor strings and provide localisation for locales that we don't support. I want to move to String Catalogs and have a way of doing that with a similar solution using LocalizedStringResource. But this seems pointless as I would like to have client String Catalogs show all strings from dependencies (our UI frameworks). Stepping back a bit, the default API for LocalizedResources and Keys uses the main bundle and has bundle as a property but String Catalogs does not and cannot respect that (highlighted in this post). A possible Apple solution could be storing the module with the string in the String Catalog for that framework then the executable can correctly assess what strings it should include based on its dependencies String Catalogs. I am looking for a way around this? Or any suggestions? I believe it might be possible using a build tool plugin to generate the String Catalog for the clients from its dependency catalogs and this way I wouldn't need any trickery / can use the LocalizedResource API as is (main bundle).

I have a macOS application with a minimum version of macOS 12.0. I need to be able to get the current keyboard region designator. Example: The user selects a input source of English Canadian. What I want as a result of this fact is en-CA locale identifier. I get the current keyboard language with the following code func keyboardLanguage() -> String?{ let keyboard = TISCopyCurrentKeyboardInputSource().takeRetainedValue() let languagesPtr = TISGetInputSourceProperty(keyboard, kTISPropertyInputSourceLanguages)! let languages = Unmanaged<AnyObject>.fromOpaque(languagesPtr).takeUnretainedValue() as? [String] return languages?.first } This returns the language as en, but I don't see how I can get the region from Text Input Sources. I can get the input source id let keyboard = TISCopyCurrentKeyboardInputSource().takeRetainedValue() let idPtr = TISGetInputSourceProperty(keyboard, kTISPropertyInputSourceID)! let id = Unmanaged<AnyObject>.fromOpaque(idPtr).takeUnretainedValue() as? String print(String(describing: id)) This prints com.apple.keylayout.Canadian which points to the Canadian region but is not a region designator. I can possible parse this id and map it to a region designator but first I'm not sure if I will capture all of the regions and secondly what happens if the format of the id changes? If someone can point to the correct API to use it will be much appreciated.

Before iOS 16.1 my app was woking good, if the user set the app language to other language than his device language, my app, widget + extensions all use this language... After iOS 16.1 if user set the app language to other language than his device language, my app works with this language but the widget + extensions works with the device language, not my app language... For Example:     @Environment(\.locale.languageCode) private var userLocal before iOS 16.1 userLocal would be the app local, after iOS 16.1 it return the device local Any idea why Apple did that? is this a bug? How to set the widget language to match my app language now? even set .environment(\.locale, dose not work when use Strings(table: because it's still get the bundle that match device language.