I reported Korean IME bug to QT Bug report. Please refer to below link. https://bugreports.qt.io/browse/QTBUG-136128?jql=text%20~%20korean%20ORDER%20BY%20created%20DESC But, QT reponsed me like follwing. Thank you for reporting. However, this issue seems like a known issue with apple's Korean IME. There are many threads in Korean community about the same problem with Non-Qt apps. If this issue is a really Qt issue, feel free to open it again. Is there any workaround to fix this IME bug ? Thanks, Ted

MacOS system settings allow the user to select one of a number of number formats. My app behaves differently depending on the format (taken from the system Locale), so I need to test every combination. Thus far I have been successful at creating Locale objects with various identifiers that map to the different formats, like: let westEuropeanLocale = Locale(identifier: "en_DE") However, I can't find a locale that maps to using . as a decimal point, and space as a thousands separator, even though it's a standard option (3rd in this list): Any suggestions on how to create a test for this number format?

I'm having troubles converting my string catalog to symbols because for partly translated languages there is no fallback to the reference language. Let me give you an example. Example Assume an app that supports two languages: English and Japanese. The app is very simple and has only two strings, using symbols in a String Catalog: Key: .helloWorld → “Hello World!” Key: .info → “Information” Case 1: No Japanese translations If I launch the app in Japanese and neither string is translated, English is used as a fallback. The UI shows: “Hello World!” “Information” This is exactly what I would expect. Case 2: Only one string translated Now assume I translate only one string into Japanese: .helloWorld → “こんにちは世界” When I launch the app in Japanese now: .helloWorld correctly shows “こんにちは世界” .info shows info, not “Information” So instead of falling back to English, the key is displayed. This issue does not pop up when I don't use symbols. Because then, my SwiftUI Text elements contain the English ideal text as a (kind of) key. I assume for commercial apps all strings are always translated into all supported languages. But this is not the case for apps where translations happens through crowd translations. Check the following link. There you will see that only English (reference language) and German (my native language) are 100% translated. Others will follow over time. https://poeditor.com/join/project/J2Qq2SUzYr For now, I guess I'll have to avoid symbols. Or is there a better way to handle this?

If you add a new string in your app (for example String(localized: "contact_support_message", defaultValue: "Please contact support")), then later you change that default value and rebuild, the string catalog updates to match as expected. But once that string is translated, changing the default value in code and rebuilding does not update the catalog. You seemingly have to go manually change the default value for English in the catalog to match the code (which marks the translation as Needs Review). Is there a better way? Or is there a way to determine what strings have default values in code that do not match the catalog values to see if any were missed as wording was tweaked over time?

Hi! I have defined the following app intent. It returns a result with a dialog to confirm that the intent has been executed. Naturally, that dialog needs to be localized properly. But the String interpolation with the provided format doesn't do that. I specified wide for the width parameter and expect spelled-out unit names. However, in the textual output, Siri always uses the abbreviated unit (e.g. "min" or "s"), in all languages I tested. In the audio output, Siri says "minutes" in English where the textual representation is "min". In German, Siri says "min", so it basically reads the textual representation aloud and that's not quite understandable to the user. struct StartTimerIntent: AppIntent { static let title: LocalizedStringResource = "Start New Timer" static var description = IntentDescription("Starts a timer with a custom duration.") @Parameter(title: "Duration", description: "The duration of the timer.") var duration: Measurement<UnitDuration> func perform() async throws -> some IntentResult & ProvidesDialog { // [code to execute intent goes here] return .result( dialog: .init( full: "\(duration, format: .measurement(width: .wide, usage: .asProvided)) timer started.", systemImageName: "timer" ) ) } } As this SwiftUI-style formatter doesn't seem to work with localization, I tried a different approach with a MeasurementFormatter: extension Measurement where UnitType == UnitDuration { func localized() -> String { let formatter = MeasurementFormatter() formatter.locale = .autoupdatingCurrent formatter.unitOptions = .providedUnit formatter.unitStyle = .long return formatter.string(from: self) } } Usage with String interpolation: "\(duration.localized()) timer started." This works great as long as these two languages are set to the same language on the user's device: [UI language] Settings → General → Language & Region → Preferred Language [Siri langauge] Settings → Apple Intelligence & Siri → Language However, when they differ, even this method doesn't yield correct results. For example, I have my general (UI) language set to English, but my Siri language set to German. Then Siri replies in German, but the unit is formatted in English and Siri speaks it in English, so the result is a messed up sentence that's half German, half English. What is the proper way to localize parameters in dialogs for Siri? How can I make sure that parameters are localized to match Siri's language?

It is vital for Apple to refine its OCR models to correctly distinguish between Khmer and Thai scripts. Incorrectly labeling Khmer text as Thai is more than a technical bug; it is a culturally insensitive error that impacts national identity, especially given the current geopolitical climate between Cambodia and Thailand. Implementing a more robust language-detection threshold would prevent these harmful misidentifications. There is a significant logic flaw in the VNRecognizeTextRequest language detection when processing Khmer script. When the property automaticallyDetectsLanguage is set to true, the Vision framework frequently misidentifies Khmer characters as Thai. While both scripts share historical roots, they are distinct languages with different alphabets. Currently, the model’s confidence threshold for distinguishing between these two scripts is too low, leading to incorrect OCR output in both developer-facing APIs and Apple’s native ecosystem (Preview, Live Text, and Photos). import SwiftUI import Vision class TextExtractor { func extractText(from data: Data, completion: @escaping (String) -> Void) { let request = VNRecognizeTextRequest { (request, error) in guard let observations = request.results as? [VNRecognizedTextObservation] else { completion("No text found.") return } let recognizedStrings = observations.compactMap { observation in let str = observation.topCandidates(1).first?.string return "{text: \(str!), confidence: \(observation.confidence)}" } completion(recognizedStrings.joined(separator: "\n")) } request.automaticallyDetectsLanguage = true // <-- This is the issue. request.recognitionLevel = .accurate let handler = VNImageRequestHandler(data: data, options: [:]) DispatchQueue.global(qos: .background).async { do { try handler.perform([request]) } catch { completion("Failed to perform OCR: \(error.localizedDescription)") } } } } Recognizing Khmer Confidence Score is low for Khmer text. (The output is in Thai language with low confidence score) Recognizing English Confidence Score is high expected. Recognizing Thai Confidence Score is high as expected Issues on Preview, Photos Khmer text Copied text Kouk Pring Chroum Temple [19121 รอาสายสุกตีนานยารรีสใหิสรราภูชิตีนนสุฐตีย์ [รุก เผือชิษาธอยกัตธ์ตายตราพาษชาณา ถวเชยาใบสราเบรถทีมูสินตราพาษชาณา ทีมูโษา เช็ก อาษเชิษฐอารายสุกบดตพรธุรฯ ตากร"สุก"ผาตากรธกรธุกเยากสเผาพศฐตาสาย รัอรณาษ"ตีพย" สเผาพกรกฐาภูชิสาเครๆผู:สุกรตีพาสเผาพสรอสายใผิตรรารตีพสๆ เดียอลายสุกตีน ธาราชรติ ธิพรหณาะพูชุบละเาหLunet De Lajonquiere ผารูกรสาราพารผรผาสิตภพ ตารสิทูก ธิพิ คุณที่นสายเระพบพเคเผาหนารเกะทรนภาษเราภุพเสารเราษทีเลิกสญาเราหรุฬารชสเกาก เรากุม สงสอบานตรเราะากกต่ายภากายระตารุกเตียน Recommended Solutions 1. Set a Threshold Filter out the detected result where the threshold is less than or equal to 0.5, so that it would not output low quality text which can lead to the issue. For example, let recognizedStrings = observations.compactMap { observation in if observation.confidence <= 0.5 { return nil } let str = observation.topCandidates(1).first?.string return "{text: \(str!), confidence: \(observation.confidence)}" } 2. Add Khmer Language Support This issue would never happen if the model has the capability to detect and recognize image with Khmer language. Doc2Text GitHub: https://github.com/seanghay/Doc2Text-Swift

I published several apps in the past that display the correct languages in the App Store, but my newest app, which has English as the default development language in Xcode, displays all languages set in Xcode except English. My other projects seem to be set up in the exact same way, except they display correctly. What could be the issue? Xcode project info: Localizable.xcstrings (English is also fully localized): App Store Connect website: App Store page (my Mac has the primary language set to Italian):

I get a lot of downloads from outside USA but almost no conversion (subscription/IAP) from those countries. Apple App Store does the price conversion based on currency conversion and VAT but it does not take into account that $10 in India or Argentina is a much bigger portion of ones income compared to a US person. Converting all these prices (175 of them) manually is very cumbersome for each subscription tier and for each region.

We have a requirement to manage the shortcuts and hotkeys in our application, and have it to be intuitive and support multi-lingual fully. The understanding that we have currently is that most universal shortcuts and hotkeys on MacOS/iOS are expressed using English/Latin characters’ – and now, when a ‘pure foreign language physical or virtual keyboard’ is the ‘input device’ – we are unclear how the user would invoke such a hotkey. Now, considering cases where other language keyboards have no Latin characters, in these environments, managing shortcuts and hotkeys becomes a rather difficult task. Taking a very simple example, the shortcut for Printing a page is Command/Control + 'P'. This can be an issue on Non English character keyboards like Arabic, where not only are there no letters for P, there is also no equivalent phonetic character as well, since the language itself does not have it. Also – when we are wanting customizability of a hotkey by the user, how would the user express ‘which is the key combination for a given action they want to perform’. So, based on these conditions, in order to provide the most comprehensive and optimal experience for the user in their own language, what is it that Apple recommend we do here, for Hotkeys/Shortcuts support in Pure Languages

Hi - I've tried around 6/7 variants of the Description for 'Localization' and all have been rejected, can someone provide reasons why this one in particular has beenrejected and what may be accepted please? This is my app's description: Premium Subscription Required (14 day free trial) ADHD Acclaim is the daily focus coach built with and for neurodivergent minds. Track energy, capture “wins” in a tap, and celebrate the progress that actually keeps you moving forward. WHY YOU’LL LOVE ADHD ACCLAIM • Energy-level slider suggests quick wins that match how you feel right now. • Beautiful, low-distraction design with bold colour cues and gentle encouragement. • Points, streaks, and confetti moments keep motivation friendly—not overwhelming. • Cross-screen sync means every win appears instantly on Home, Wins, Calendar, and Rewards. CAPTURE WINS IN SECONDS • Scrollable Quick Wins carousel: tap “Add Win” to log a task and cheer yourself on. • Create custom wins with notes, boost level, and schedule options. • Active Wins list shows what’s next; swipe to complete or tidy up with a single tap. MAP YOUR WEEK • Calendar view highlights upcoming or completed wins with easy-to-spot dots. • Filter by day to review achievements or add new wins directly from selected dates. MOTIVATION THAT FEELS GOOD • Earn points for every win, then redeem them for rewards you define—tea break, walk, screen time, and more. • Progress stats surface total wins, energy trends, and milestone streaks without information overload. DESIGNED WITH ADHD IN MIND • Calmer typography, carefully tuned contrast, and purposeful colour accents reduce cognitive noise. • Positive microcopy, lightning-fast interactions, and accessible layouts support focus at any energy level. • Built-in celebration toast and confetti toggle let you control how much excitement you need. FREE TRIAL & PREMIUM Start with a 14-day free trial to explore everything. Stay on the free tier for core win tracking, or upgrade to ADHD Acclaim Premium to unlock unlimited rewards and advanced planning tools. Cancel anytime in Settings—no pressure, just support. SUBSCRIPTION & BILLING • Payment is charged to your Apple ID at confirmation. • Subscription renews automatically unless cancelled at least 24 hours before the end of the current period. • Manage or cancel anytime in your App Store account settings; refunds aren’t provided for unused portions. • Any unused portion of a free trial is forfeited if you purchase a subscription. Need a hand? Reach the team at xxxx —real humans ready to help. https://www.apple.com/legal/internet-services/itunes/dev/stdeula/

Hi, My iOS app's home screen widget content was implemented to base on the preferred language of my main app (e.g. my app has the following preferred language options with this order English, Japanese, Traditional Chinese, Korean, Simplify Chinese). Say the main app is currently using English as their preferred language, I can change the preferred language in the iOS Settings -> Apps -> My App -> Preferred Language. My widget's content will respect to the preferred language option that I selected with only exception if I switch back to English language and my Widget's content won't get updated. The Main app content is always update with respect to the selected preferred language. My app and widget is working without any issue in iOS 18. Other things that I had discovered during my testing under iOS 26, the "first" language appeared in my preferred language always being the issue (e.g. if the first language is Japanese , once I change to other languages and than switch back to Japanese, my widget content won't respect to this but the main app content are ok). Any one has a similar issues regarding the preferred language?

Hi there, I’m having trouble with localization for App Intents used in a configurable widget when the intents are defined inside a Swift Package. The intents appear correctly in the widget configuration UI and function as expected, but the localized strings are not displayed. Instead, the widget shows the localization keys themselves. Setup Xcode: 26.1 iOS: 26 The App Intents are used for a configurable widget Intent is located in a Swift Package The Widget Extension depends on the package AppIntentsPackage setup: // In the package public struct MySharedIntentsPackage: AppIntentsPackage {} // In the widget extension import AppIntents import SharedAppIntents struct WidgetIntentsPackage: AppIntentsPackage { static var includedPackages: [any AppIntentsPackage.Type] { [MySharedIntentsPackage.self] } } What I’ve tried I tested several configurations separately to see which setup allows localization to work: Localizing inside the Swift Package Placed a Localizable.xcstrings file inside the Swift Package. Specified .module for the bundle parameter in LocalizedStringResource initializers. → The widget still displayed the localization keys. Localizing inside the Widget Extension Placed a Localizable.xcstrings file inside the Widget Extension target instead of the package. → The widget continued to show the localization keys. Allowing mixed localizations Added CFBundleAllowMixedLocalizations = YES to the Widget Extension’s Info.plist. → No change; the widget still showed the keys. Problem In the WWDC 2025 session “Get to Know App Intents”, it was announced that App Intents would officially support Swift Packages. However, despite following that guidance, here we have a situation where the localizations do not work and only the keys appear in a configurable widget’s configuration UI. When I move the same App Intent code directly into the Widget Extension target, localization works as expected, but not when the intent remains inside the Swift Package. Question Is localization for App Intents defined in Swift Packages officially supported for configurable widgets? If yes: Which bundle does App Intents use to resolve localized strings? Should the .xcstrings file be placed in the package or in the host extension’s bundle? Or is this a current limitation or known issue? Any clarification or workaround would be greatly appreciated. Thank you.

I was wondering if there are any technical rules where to store the xcstrings file(s) in the Xcode project? Is the source folder most common? From my observations it seems the xcstrings file could be anywhere inside the project folder hierarchy and they still take part in string extraction.

Hello, I'm trying to remove a localization from a String Catalog in a Swift Package. How can I do that? I tried to remove the file and create a new one, but all the languages are back. The only place where I've found a reference to the languages is in Package/.swiftpm/xcode/package.xcworkspace/xcuserdata/user.xcuserdatad/UserInterfaceState.xcuserstate But I don't know how to edit this file to remove a language. Thank you, Axel

Hello, developers! I’m interested in adding my native language and flag to iOS, iPadOS and MacOS. Could you please recommend a solution or provide some valuable advice on how to achieve this? I’d greatly appreciate your assistance. Thanks!

Hi team, I’m developing an iOS app that helps manage and translate multilingual content . The app uses SwiftUI with Localizable.strings and Bundle.localizedString(forKey:). I’m trying to optimize for dynamic language switching inside the app without restarting. I’ve tested various methods like: Text(NSLocalizedString("welcome_text", comment: "")) and some approaches using @Environment(.locale), but the system doesn’t always update views instantly when language changes. Question: What’s the recommended approach (or WWDC reference) for real-time language change handling in SwiftUI apps targeting iOS 18+?

Hi, I have AppShortcutsProvider in my app target(not as a separate extension) to support Siri command. It is working perfectly in English, but I would also like to add a localisation on it as my app supports multiple languages. struct MyShortcuts: AppShortcutsProvider { static let shortcutTileColor: ShortcutTileColor = .grape static var appShortcuts: [AppShortcut] { AppShortcut( intent: NextClassAppIntents(), phrases: [ "What is my next class in \(.applicationName)?", "What's the next class in \(.applicationName)?", "Next class in \(.applicationName)." ], shortTitle: "Next Class", systemImageName: "calendar.badge.clock" ) } } Xcode String Catalog was doing great jobs, It also detected shortTitle automatically and added that to the Catalog. However, I don't see localisation for those phrases anywhere in the String Catalog and when I try to use String(localized: ), compiler gives me an error. How can I properly localise AppShortcutPhrase?

Hi everyone 👋 I’m building an iOS app in Swift where I want to do the following: Record the user’s voice Transcribe the spoken sentence (speech-to-text) Auto-detect the spoken language Translate it to another language selected by the user (e.g., English → Spanish or Hindi → English) Speak back (text-to-speech) the translated text on the same device Is this possible to record via phone mic and play the transcribe voice into headphone's audio?

I'm working on a large multi-platform iOS project (iOS, iPadOS, watchOS, tvOS, visionOS) and have successfully migrated from legacy .strings files to modern String Catalogs (.xcstrings). However, I'm unable to export localizations using xcodebuild -exportLocalizations due to cross-platform framework dependency issues. (Note: I did have AI help me write this question, so apologies in advance for any errors) Project Structure Main iOS/iPad app with multiple extensions watchOS companion app tvOS app visionOS app 49 .xcstrings files successfully migrated across all targets Uses Swift Package Manager for modularization The Problem When attempting to export localizations using xcodebuild -exportLocalizations, the build fails because it tries to build all targets across all platforms, including watchOS targets that depend on third-party xcframeworks that don't include watchOS slices: xcodebuild -exportLocalizations \ -project MyProject.xcodeproj \ -scheme MyApp \ -localizationPath ./export \ -configuration Debug Error: error: While building for watchOS, no library for this platform was found in 'Frameworks/<incompatible>.xcframework'. (in target 'Target') These frameworks cannot be modified to add watchOS support (third-party/legacy dependencies). What Works vs. What Doesn't Works: Building the iOS app through Xcode GUI Fails: Exporting localizations through Xcode GUI (Product → Export Localizations...) Fails: xcodebuild -exportLocalizations with any combination of flags Attempted Solutions (All Failed) Platform-specific destination: xcodebuild -exportLocalizations -destination "generic/platform=iOS" ... SDK constraint: xcodebuild -exportLocalizations -sdk iphoneos ... Excluding architectures: xcodebuild -exportLocalizations EXCLUDED_ARCHS="armv7k arm64_32" ... Build first, then export: xcodebuild build -scheme MyApp -sdk iphoneos && \ xcodebuild -exportLocalizations ... All approaches still attempt to build watchOS targets despite platform constraints. Observations The -exportLocalizations flag appears to ignore -destination and -sdk flags It seems to scan and build ALL schemes/targets in the project regardless of constraints Regular builds (xcodebuild build) work fine with platform constraints Current Workaround I created a Python script that parses .xcstrings JSON files directly and generates XLIFF output, which works but feels like it's bypassing Apple's intended workflow. Questions for Apple Is there a way to limit xcodebuild -exportLocalizations to specific platforms? The documentation doesn't mention any flags for this, and -destination/-sdk appear to be ignored. Why does -exportLocalizations require building ALL targets across ALL platforms? Both the Xcode GUI (Product → Export Localizations) and xcodebuild -exportLocalizations fail with identical build errors, suggesting this is by design. Is there a reason localization export can't be limited to buildable targets? Is the intended workflow to have ALL targets buildable across ALL platforms before exporting localizations? This seems impractical for multi-platform projects with platform-specific dependencies. Are there any build settings or configuration options that can exclude specific targets/platforms from the localization export scan? Is directly parsing .xcstrings files and generating XLIFF an acceptable alternative, or does this miss important metadata that -exportLocalizations would include? Environment Xcode 16.x / 26.x (reproduces on both) macOS Tahoe Project uses String Catalogs (.xcstrings) format Mixed SPM packages and traditional target structure Any guidance on the correct approach for multi-platform localization export would be greatly appreciated. Is this a known limitation, or is there a recommended pattern I'm missing?

For ~8 weeks (10+ support replies) I’ve been unable to switch my app’s Primary Language from en-CA to en-US. App Store Connect shows: “Primary Locale couldn’t be saved because you must first provide all the required screenshots for each version in this language.” State: Default product page has complete iPhone + iPad screenshots for en-US and en-CA (live/approved). Issue began before any CPP existed; I have since removed all CPPs. Error persists, which suggests a stale/ghost CPP localization still being validated, or other issues. Questions: What does “for each version” precisely validate (live / in-prep / historical; default vs CPP)? Can deleted/never-approved CPPs still be validated, and how can they be purged? Anyone seen this after CPP removal—what fixed it? Happy to DM an Apple Staffer the case ID, a HAR of the failed save, and a short screen recording. Thanks! P.S. This has been open for ~8 weeks; I’m seeking an engineering-owned view to identify the specific unmet validator requirement or confirm a product issue. P.S.S. the App Catalog Report for my account is currently returning an empty file (Email) (requested via Apps → … → Reports). If others have seen this recently, is there a workaround - or should I file Feedback?