Hi, still without any success I can’t recreate the ui tests that will highlights the string in the screenshot like it’s shown in WWDC 2019 - 403. I even submitted feedback via Feedback Assistant 3 months ago. FB12284285 https://developer.apple.com/videos/play/wwdc2019/403/ I would love to see this finally works with string catalogs. Thanks

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?

Our application should support locales for Albanian and Albanian(Kosovo). Xcode creates sq.lproj and sq-XK.lproj folders accordingly Everything works fine in xcode, but if we upload to appstore we always see this warning. I tried specifying other names for sq-XK to match https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/LanguageandLocaleIDs/LanguageandLocaleIDs.html aln, sq-RS, sq-KV, sq-KS, sq-Latn-XQ. The varning was always present. Is there any way to get rid of it? WARNING ITMS-90176: "Unrecognized Locale - The locale used in localization directories at ("Payload/{AppName}.app/base.lproj") are invalid. iTunes supports BCP47 but not the UN M.49 specification. Refer to the Language and Locale Designations guide for more information on naming your language-specific directories."

I'm a translator working with an xliff file type. My client is having issues importing the xliff file into xcode. My issue is I'm on windows and they're on macOS. How can we convert the xliff file into an xcloc file type?

When the "Use compiler to Extract Swift Strings" is set to true, it extracts strings from the frameworks i have imported as well. How can i avoid this?

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:

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

I have been suffering for several months because the language information in the App Store is not displayed properly. We are developing with Unity. The '.lproj' file was created through Project>Info>Localization. I also wrote CFBundleLocalizations for InfoPlist. It still doesn't reflect, what is the reason? Please help.

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 ...

Hello, I need help because I have not succeeded to fix the following issues: ITMS-90738: Invalid purpose string value - The “NSLocationAlwaysAndWhenInUseUsageDescription” value for the NSLocationAlwaysAndWhenInUseUsageDescription key isn’t allowed in “SuperNewsV2UIKit.app”. Your app’s code references one or more APIs that access sensitive user data, or the app has one or more entitlements that permit such access. The Info.plist file for the “SuperNewsV2UIKit.app” bundle should contain a NSLocationAlwaysAndWhenInUseUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. For details, visit: https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/requesting_access_to_protected_resources. ITMS-90683: Missing purpose string in Info.plist - Your app’s code references one or more APIs that access sensitive user data, or the app has one or more entitlements that permit such access. The Info.plist file for the “SuperNewsV2UIKit.app” bundle should contain a NSLocationWhenInUseUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. If you’re using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required. For details, visit: https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/requesting_access_to_protected_resources. There is actually what I have done and I don't understand yet why the issue is not fixed after uploading on App Store Connect: Main info.plist: Info.plist (disabled) Localizables, I use the new String Catalog: Note: NSLocationWhenInUseUsageDescription is needed on localizables, even after replacing with NSLocationAlwaysAndWhenInUseUsageDescription, my location feature on map won't work, even for asking user permission. Can you help me please to fix this issue ? Documentation has not helped me to fix the issue after applying the recommendations. Thanks in advance.

What's the right way to implement key equivalent matching that handles non-Roman/Latin layouts? E.g. pressing Cmd+Option+C in a Greek layout produces an NSEvent with chars="ç" unmodchars="ψ", neither of which is going to match a key equivalent of Cmd+Option+C by simile comparison, yet performKeyEquivalent on a button with that exact key equivalent returns YES and activates the button. How would someone replicate that? [NSEvent charactersByApplyingModifiers:] also reports "ç", and so does UCKeyTranslate. Yet the Keyboard Viewer shows a modifier layer with "c", not the "ç" that the event reports:

I have a complex project with > 10 targets, 14 pods and have issues with exporting localizations using Xcode 15. All my targets build in both DEBUG and RELEASE mode. It is only when I try to export localizations that it breaks. The error is always cannot find UIKit/UIKit.h. Cleaning the project and deleting derivedData folder has not worked for me. It would be ideal if I could do an export localization for a specified target only.

Hi! I am currently working on unit conversion in my project, and I've been using in the UI system titles provided by the MeasurementFormatter. I'm unsure if this is their expected usage, but this is very convenient for localization. However, I've noticed a few potential errors in the MeasurementFormatter.string(from unit:) method values for some units within the UnitVolume class. Imperial and metric options of some units could have the same title, which should be wrong because they have different coefficient properties from which we can be sure they are different units. Here is a code example with the potentially wrong duplicate titles: import Foundation func title(for unit: Unit) -> String { let formatter = MeasurementFormatter() formatter.unitStyle = .long return formatter.string(from: unit) } // 1 title(for: UnitVolume.teaspoons) // "teaspoons" title(for: UnitVolume.imperialTeaspoons) // "teaspoons" // 2 title(for: UnitVolume.tablespoons) // "tablespoons" title(for: UnitVolume.imperialTablespoons) // "tablespoons" // 3 title(for: UnitVolume.pints) // "pints" title(for: UnitVolume.imperialPints) // "pints" // 4 title(for: UnitVolume.fluidOunces) // "US fluid ounces" title(for: UnitVolume.imperialFluidOunces) // "US fluid ounces" // 5 title(for: UnitVolume.quarts) // "US quarts" title(for: UnitVolume.imperialQuarts) // "US quarts" I suppose examples 1-5 should have different titles. It seems the correct values for such a situation are: title(for: UnitVolume.gallons) // "US gallons" title(for: UnitVolume.imperialGallons) // "gallons" I would be grateful if you could tell me where I can report or get some information about this.

Hello, When I use xcstrings in my app, and I have my scheme's localization debugging enabled (when it renders all caps for any non-localized text). Prior to converting to xccstrings, my app shows non caps text for everything. After I convert to xcstrings, some of my app shows caps text for some items. I can see the keys in the xccstrings that I expect, so I do not think it is a bug in the conversion. Could it be a bug in the renderer somehow? FB13261276 Thanks! -- Greg

If I convert my SPM from .strings to .xcstrings it will fail to build when using swift build. It builds from Xcode 15. My UI code uses bundle: .module so the localized strings are found properly. See https://github.com/bolsinga/site/pull/685 for the change (as well as the action log). Does SPM build somehow not know that .xcstrings in a Resource directory make the build a "bundle build"? I filed FB13261704 Thanks!

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?

App was rejected with: Guideline 2.3 - Performance - Accurate Metadata We were unable to locate some of the features described in your metadata. > Specifically, “Languages: English and Portuguese (PT and BR).”. My app is indeed localized in these three languages, tested and working. The app automatically adapts its language to match the user's iOS system language settings. Isn't this enough? I replied to the rejection saying this, but I find it hard to believe that the reviewer didn't change the iOS system language settings. Is it possible, or is it something else? Also, do I need to press the "Add For Review Button" so he can see my reply? Thank you.

Hi, does anyone know if it's possible to change the language from within the code/application so that the change also reflects in the settings in preferred language section?

I'm trying to add Localizable strings to translate push notifications on the device side. This works fine when adding different languages (ex: German), however I'm running into issues when trying to add a Localizable file for en_US. The default is set to the en file. I've tried setting my phone's language and region to en_US and US, as well as building my app and editing the scheme in XCode to use en_US as the locale but the notifications always get translated using the default en file, and not the en_US file. My goal is to have a separate notification translation for en_US vs for any other English locale but I'm stuck here. Any ideas would be appreciated!

I've spent 3 days moving localization from my older project to my new project and converted to Strings Catalog. When I tried to export, I got the Unable to build project for localization string extraction error. Read about that and the workaround seems to be to set Localisation Export Supported to NO, which I did. I worked once and now it refuses to export and complains about missing targets, which I had to remove from the export process as recommended. WTH? Or, at some point it complained about a missing Swift Package. wwdc2023-10155