Post not yet marked as solved
Indeed it's very annoying. Trying to solve this same issue for a few days already. Apparently the only solution is fall back to the old approach reacting on keyboard related notifications etc.
Post not yet marked as solved
I've got the same problem. Is there still no solution to this yet? This is a very common use case, and any time someone wants to use keyboardLayoutGuide with a scroll view, it no longer becomes feasible.
Post not yet marked as solved
Thanks. Is that documented somewhere?
Maybe only date-time formats, etc., trigger the notification but language changes don't? Exactly. Formatters and other objects that can refresh their data directly using Locale.current or Locale.autoupdatingCurrent are expected to be able to do so when they receive currentLocaleDidChangeNotification. However, when you change the Device Language or the App Language, not every app is currently able to dynamically update their UI Layout, which is why the app is terminated and relaunched for such events.
Dear Experts, NSLocale has a notification NSCurrentLocaleDidChangeNotification and a property autoupdatingCurrentLocale (A locale which tracks the user’s current preferences). These suggest that an app should be able to detect when the user changes their language preference while running, or when it is resumed from the background. In practice, when I change language in the Settings app (either globally or just for my app), the app is terminated by iOS and restarts with new locale. Is this the expected behaviour? I am wondering if there is something I need to do to advertise that the app can adopt language changes without restarting, or something. Maybe only date-time formats, etc., trigger the notification but language changes don't?
Post not yet marked as solved
Thanks for the suggestion... I realized that I should have use setLocalizedDateFormatFromTemplate() in the original post for reproducing the issue. I think its just not picking from the abbreviated section that you provided as even the simplest format like below results in a trimmed word (not the complete month name as in the monthNames -> format -> abbreviated section) let dateFormatter = DateFormatter() dateFormatter.locale = Locale(identifier: ur) dateFormatter.setLocalizedDateFormatFromTemplate(MMM) print(dateFormatter.string(from: Date())) // Expected: جولائی // Actual: جول I tried with the other variant of Locale identifier such as ur_IN and ur_PK as well
Post not yet marked as solved
Try using dateFormatter.setLocalizedDateFormatFromTemplate(yMMMd) to get the best format for the locale rather than an explicit one. As for the abbreviated form, those come from sources like https://github.com/unicode-org/icu/blob/70d308731ae01a4187fe49f7ae1c8e1ad1570be6/icu4c/source/data/locales/ur.txt#L1073C1-L1074C1
Post not yet marked as solved
Using Swift's DateFormatter class, how does it convert abbreviated date format to languages that don't support abbreviated month names e.g. Urdu For Example, the following code doesn't return the correct Urdu translation for abbreviated Month format. let dateFormatter = DateFormatter() dateFormatter.dateFormat = MMM d, yyyy dateFormatter.locale = Locale(identifier: ur-IN) let date = Date() let formattedDate = dateFormatter.string(from: date) print(formattedDate) // Expected: جولائی ۱۲, ۲۰۲۳ for Jul 12, 2023 // Actual: جول ۱۲, ۲۰۲۳
Post not yet marked as solved
If you want this to be seen by the folks who have the power to enact change, I recommend that you put it an enhancement request. Include as many details as you can. For example, right now I’m not even sure what platform you’re talking about (iOS vs macOS, for example). Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Post not yet marked as solved
As a classical Arabic, student, learning the Arabic lanaguage, using the English keyboard is a big part of our journey. I hope Apple, can add a keyboard that is English(Arabic), because using the English alphabet is a big part of us students, learning the foreign language for pronunciation and writting/reading skills. Thankyou for considering!
Post not yet marked as solved
To test things further, I've created a custom keyboard layout (attached), with the following mappings: +----------+--------------+--------------------+----------+ | Key code | Physical key | No modifiers layer | ⌘ layer | +----------+--------------+--------------------+----------+ | 7 | x | e | c | +----------+--------------+--------------------+----------+ | 8 | c | a | b | +----------+--------------+--------------------+----------+ | 9 | v | c | d | +----------+--------------+--------------------+----------+ Testing with an NSButton with .keyEquivalent = @c and .keyEquivalentModifierMask = NSEventModifierFlagCommand, I'm observing: Pressing the c key alone, or with ⌘, does not trigger the button, so the logic in NSButton does not seem to be based on the key code of the event (8) Pressing the x key alone does not trigger the button, but pressing ⌘x does, so the logic does seems to match on NSEvent.characters Pressing the v key alone does not trigger the button, nor does pressing ⌘v, so the logic does not to
Post not yet marked as solved
Thank you for your reply. I've observed the switch to a Latin/English-like layout (using Accessibility Keyboard) when pressing ⌘ for the Hebrew layout. The question is how an implementation of performKeyEquivalent would correctly account for and support this? Based on the performKeyEquivalent documentation here, and the Handling Key Events documentation here, the implementation should check the unmodified characters of the incoming events: You should extract the characters for a key equivalent using the NSEvent method charactersIgnoringModifiers. The implementation should extract the characters for a key equivalent from the passed-in NSEvent object using the charactersIgnoringModifiers method and then examine them to determine if they are a key equivalent it recognizes. Which naively would be something like: - (BOOL)performKeyEquivalent:(NSEvent *)event { if (event.modifierFlags & NSEventModifierFlagCommand) { if ([event.charactersIgnoringModifiers isEqualToString:@c]) return YES; } return NO; } But this
Post not yet marked as solved
On non-Latin keyboard layouts, the ⌘ layer switches the keyboard to a Latin/English-like layout. E.g. pressing ⌘ switches ב into C. You can observe this behavior in Accessibility Keyboard. This non-Latin layout ⌘ switch does all the work here. For non-Latin layouts, keyboard localization (menu-only) would be only used here for some special characters like ⌘[ or to switch arrow keys based on the UI directionality. I encourage you to add input methods like Hebrew in System Settings › Keyboard and run tests within your app to make sure events are caught. Also, based on the shortcut you want, catching via the key code instead of the key character may be best.
Post not yet marked as solved
Based on these Swift docs and this forum thread, keyboard shortcuts / key equivalents are expected to be declared based on a US English layout. As an application developer, you may then rely on the auto localization provided by allowsAutomaticKeyEquivalentLocalization, (for menus) or localize your key equivalents manually (menus and other controls with key equivalents). But how does AppKit handle non localized key equivalents when faced with a non-US English keyboard layout? In particular, with a Hebrew layout active, the C key unmodified produces ב, but when modified with ⌘ produces c. Does AppKit compare the key equivalent ⌘c to the modified or un-modified char of the event, or both? Or is there more to this logic? E.g. does it also try to match the incoming event against a US-English layout, even if not active at the moment? The use-case here is implementing performKeyEquivalent for a custom control, where the documentation says: You should extract the characters for a key equivalent using the NSEvent meth
Post not yet marked as solved
When exporting localizations from the UI via Product > Export Localizations... the configuration of the currently active scheme is used. You can change this in the scheme editor: Edit Scheme... > Run > Build Configuration and confirm that the correct configuration is being used in the build log below the target being built. When exporting localizations from the CLI, the default configuration is used. Code-signing is not enabled when building for localization export / import, so it's likely not an issue with certificates that are only used for Release builds If I had to guess, there is a compilation error that's preventing the the build from succeeding. Keep in mind that when building for localization—all targets are built for all destinations.
