Localising my app I found the entire process quite un-swift like (i.e. unsafe and unintuitive) and was not the only one, even the great Paul Hudson also thought it a strange implementation. Following a tutorial by Andrii Halabuda (https://www.youtube.com/watch?v=_PBA20ZVk1A) relying on an Enum to reduce errors, I found that the strings needed in the "Localizable.strings" strings file could not be avoided. I have not tried localisation in SwiftUI, I see that it is different, is it easier i.e. can Plists and such be avoided ? Is there any word on deeper integration that is just more like a normal method ?

Hello. I have an app in the app store that I have localized into several languages. But the list of languages that the app supports in the App Store lacks English, which is the main language (and the language I developed the app in). I'm localizing the text by using String with a "localized" key and a defaultValue (in English). I also created a localization string catalog where I added added the values for each key on each language. On Xcode (15.0.1), in the app file, info, localization section I see that all languages are there with green checkmarks, except English which is at the top and is the default language. However, when I build, archive and send the bundle to AppStoreConnect, the Localizations in the Store Information section for the bundle does not include English, and so on the AppStore it looks like the app supports all of the additional languages but it does not list English. I can't figure out exactly what I'm missing. Can anyone help?

I use String Catalog to localize my app (built in English) to Japanese. The app works fine and supports both languages. I have tested on TestFlight, and the live version download from App Store also supports 2 languages. But the display on App Store only indicates Japanese. I have no idea why the number for localized files show 0 for both English and Japanese. The Localization of Japanese works fine. How to fix this?

Is it possible to use a string catalog to localize a settings bundle? Currently, to localize a Settings.bundle, we need to create a folder for each language with a single strings file inside. For example: Settings.bundle en.lproj > Root.strings fr.lproj > Root.strings de.lproj > Root.strings ... Any way to convert that to a string catalog? Thank you

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 tried to migrate to the new localized string catalogs. But after this I can't build the app anymore. The error message stated something about an "old" .string file... but I checked all directories and there are no old .string files... Anybody a hint how to go further? And this is how the directories look after migration ...

I'm trying to display an Int in Hebrew. so for example 123 should display אבג 1 = א 2 = ב 3 = ג I have tried specifying the locale based on a the answer to a different post of mine where the solution was to specify the numbering system in the locale Locale(identifier: "he-IL@numbers=hebr") print(123.formatted(.number.locale(Locale(identifier: "en@numbers=hebr")))) // Output: 123 When setting the same locale for dates it formats properly with Hebrew numbers. However if I do Arabic instead of Hebrew the numbers display properly in arabic the result for this is `` print(123.formatted(.number.locale(Locale(identifier: "en@numbers=Arab")))) // Output: ١٢٣ Below is the code I've tried running in a playground: This is the code I ran in the playground

The Problem: The App Store listing of my app does not show all languages the app is localised in: The Question: How to fix this? A potential reason I could imagine might be, that the App Store looks for the files localised, and Xcode shows 0 localised files in English for my app, because English is my development language and all Strings are in English like that: Text("Reload", comment: "Menu action to reload feed") I really don't want to translate every English word, to English like "Reload" = "Reload". What am I getting wrong here? How can I have the App Store show both supported languages? The current implementation: My app supports two languages and I am using the new String catalog for localising. Both languages work while testing on device and are available from the App Settings in the System settings app to switch between:

We have separated much of our UI into different packages to reduce complexity and compile time. When we recently tested using new .xcstrings string catalogs, we hit an unexpected problem. Strings extracted from SwiftUI components like Text or Button are extracted into the Localizable.xcstrings in the same package, but the default behaviour of Text(_ key:tableName:bundle:comment:) is to use Bundle.main. When the default behaviour of the string extraction isn't to extract to the main app target, this introduces a very fragile system where it's easy to add code that looks localised, but ends up failing lookup at runtime. I don't feel comfortable that we will always remember to define the correct module every time we create a Text. Also, other components like Button doesn't have an init that takes a Bundle, so we would also have to remember that Button(_ titleKey:action:) can now only be used in a package if we make sure that the main bundle contains a matching key. Is there a way for us to make sure that strings are always extracted to the same place as they are resolved against by default? Either by having strings in packages extracted to an xcstrings file in the main app or having Text default to resolving against the module bundle by default?

In stringsdict it was possible to define a format separately from the translation so you could do something like "n_days" which you could pass in an integer and it would return you only "Day" or "Days" without the actual value in it. And it's work great. But now with the strings catalog it seems like the format specifier HAS to be in the value, otherwise it's not recognized. Is there now no way to pluralize anything without having the actual value inside the translation? Cannot infer format specifier for string group because no numerical specifiers were found (en: %d.n_hours)

Is it possible to merge or split a string catalog? It doesn't seem possible now. The workaround i use now is eidting the xcstrings file in TextEdit.

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!

Hello, do the String Catalogs (new in Xcode 15) support Swift Packages? I've tried adding a new Localizable.xcstrings (string catalog) file to my package's resources folder. Great! I then see this screen: All good so far. I then try to go and build my Swift Package... and nothing changes. The string catalog is never populated and I'm left with the same screen as above. So, do string catalogs not support packages at this time or am I doing something wrong? I was really hoping String Catalogs would work and save the day since Export Localizations also does not work for Swift packages that don't support macOS. 😔

String catalog is a great new feature to organize strings in one place. What would you recommend how to handle extracted Strings which need not be translated in different languages

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.

I have added additional localizations into my iOS app. iOS is not available in those languages. So I did as it is suggested that you redirect customers to app settings view UIApplication.openSettingsURLString and there they can select another app language. Unfortunately they do not see language selection if they do not have set at least 2 Preferred languages in General -> Languages & Region. Also it does not matter what languages they have there. If my app does not support those then it still shows all localizations available. Is there somehow to force it? So it would be visible always? Since most people in my country have iPhones only in English but would like to use Apps in their native language.. Since they do not have 2 preferred languages they cant see the selection :(

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.

I am working on an app that pulls data from weatherKit, including the conditionCode property, the content of which is displayed to the user. I wish to localize the data pulled from weatherKit but when pulling data from: weatherkit.apple.com/api/v1/weather/de/{latitude}/{longitude} The conditionCode and other strings is in english. Same is true if the language parameter is set to es, ja or something else. Am I doing something wrong or is localization yet to be supported in weatherKit? I can't find any documentation on this.

I tried to build LocalizedKeyString using String's new Initializer. String(localized: "hello",locale: locale) When I change the language setting of the device, everything works as expected. However, when I try to get the string in a specific language using the specified Locale, I can only ever get the string in .current. String(localized: "hello",locale: Locale(identifier: "zh-cn"))     func getString(locale:Locale) -> String{          String(localized: "hello",locale: locale)     } If you change the display language of the project (or the language setting of the device), the text in Text is always displayed correctly. Text(getString(locale:.current)) However, the code in onAppear print(getString(locale:Locale(identifier: "zh-cn"))) It only displays the same content as Text, but not the specified Chinese. Is it my fault that the new Initializer The understanding is not correct, or the bug of String init(localized keyAndValue: String.LocalizationValue, table: String? = nil, bundle: Bundle? = nil, locale: Locale = .current, comment: StaticString? = nil) FB number: FB9675845

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?