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.

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?

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

Does Swift/objc provide builtin support for reading/writing xcstrings, like PropertyListEncoder/PropertyListDecoder?

I was wondering why the Text View in SwiftUI is (as far as I know) the only View that accepts a LocalizedStringRessource in its init. Are there better alternatives? I know there is LocalizedStringKey, which works great with SwiftUI Views but is limited if you want to access the localised string in non-UI code. This results in the inconvenient situation of writing code like this: struct LocalizedView: View { let localizedString = LocalizedStringResource("Localize Me!") var body: some View { Text(localizedString) // Does not work // Label(localizedString, systemImage: "questionmark") // Inconvenient Label(String(localized: localizedString), systemImage: "questionmark") } } Best, Chris

Hi Folks, I've been researching how to implement a feature in my ios app that changes the app icon based on the user's location, essentially localizing the app icon. I'm aware of alternateIconName, but I'd like to avoid prompting the user to choose an icon themselves. Are there any other workarounds to achieve this? Thank you, Camron

I have encountered an issue related to the usage of string catalogs in a Swift package. I created a repository for reproduction. https://github.com/atacan/DiscussionStringCatalogPackage The Readme.md file has all the details. Here is a short summary: The Package.swift file's target has resources: [.process("Resources")], and this Resources folder contains a string catalog. The catalog is correctly populated by the compiler, and German translations are added. Text view is using bundle: .module argument. However, when the scheme run options are changed to German, the UI still displays English text. Xcode throws a warning indicating that the German translation for the text is not found in the Localizable table of the bundle and it says (not loaded). Although the bundle contains translations in the Localizable.strings file. Screenshots of the issue are available in the original README file. I am looking for any insights or solutions to this problem.

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 :(

I've a workspace with multiple packages, and due to the a bug in Xcode I cannot export the app localizations using the Xcode GUI tool, but I need to resort on using a command from terminal xcodebuild -exportLocalizations -localizationPath . -workspace &lt;path_workspace&gt; -sdk iphoneos -exportLanguage en One of my packages contains some macros, and I use them from my code without any problem, the code compile But when I try to export localizations using that command, the build fails due to "compiler plugin not loaded" So I cannot use Xcode normal exporting because Xcode bug, and cannot export by running a command due to the macro problem What should I do? It is very discouraging this situation, do you have any suggestion? I've found a similar problem

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 want to make use of String Catalog for some words that show the differences between countries like the USA and Canada. For example, I added both languages to my string catalog and I would like to have: Enter your Zip Code [English] Enter your Providence [English (Canada)] If I run the app without any change in the tables, I see all values shown correctly, but when I make this 1 word change in required field, all other strings start showing their keys instead of base values that are already in English language. What is the easiest way to achieve this using String Catalogs other than copy/pasting all the values from English table to English (Canada) table? I don't want to or need to translate all the strings in the catalog since they are literally the same, all I need is having iterations for some words.

Hi, I'm parsing iOS localization files and during tests with xcode 15 i noticed new lines appear in the xcloc files with LS instead of the usual LF i was used to. Questions: is this the default behavior in xcode 15? Has this changed with this version? is this controllable by any settings? Disclaimer: not a iOS developer here, please pardon any confusions and have patience.

Hi! We added Spanish to the String Catalog. Turned out there are a lot of changes we should make to already localized text. How can we temporarily turn off / disable this language to fix all issues and then turn on Spanish support again? Thank you!

Since Xcode 15.1, when compiling SwiftUI previews (using #Preview macro), strings that are unique to #Preview declarations are getting extracted and processed to the application's localizable strings catalog. In Xcode 15.0.1, this still works as expected and only UI strings from non-preview UI declarations are extracted and processed. Afaik, there is no setting for this in Xcode 15.1 and up. Anyone knows any other solution to avoid our catalog gets muddled with preview strings? I've already been reporting this via the Feedback hub since 15.1, but have had 0 responses from Apple on this.