[tags:internationalization,localization]

97 results found

Post not yet marked as solved
4 Replies
2.5k Views
On IOS there is 2 ways to select app language : settings-general -language settings - your app - language if an app require authorisation for localisation like requestWhenInUseAuthorization , the displayed text is always in the language specified by the general language setting. Setting the required string in InfoPlist.strings is not enough and there may be a problem in iOS : once can check this with the Apple official Weather App installed by default on iPhone. How to reproduce : Set your device (general-language) in English. set WeatherApp( settings-weather-language) in French. set weatherApp Location to ask next time. start weather app it will ask for permission with a message in English while all other part of app are in French. I tested with other languages and it is still the same. This may finish in Apple refuse an app in AppStore review process with that « user may expect to have authorisation dialog in the language they choose for the app», but there is nothing that can be done as even Apple Software
Posted
by
Post not yet marked as solved
4 Replies
Has your app actually been rejected for this? That would almost certainly be a mistake by App Review. I have various apps on my phone here that behave exactly like this (location prompts in device language) as expected. (I don't think my anecdotal evidence falls under the rule of “past review performance is no guarantee of future results” because in this case it’s behavior provided by the system that is working exactly as designed.)
Post not yet marked as solved
4 Replies
@MobileTen : The problem is that Apple can refuse an app for this problem which not under developer responsibility.
Post not yet marked as solved
4 Replies
Works as expected. The system alert is governed by the OS not the application preference.
Post not yet marked as solved
1 Replies
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.
Post not yet marked as solved
2 Replies
Do you mean to try like this? If so, it does not work either. let formatter = DateFormatter() formatter.calendar = .autoupdatingCurrent formatter.locale = .autoupdatingCurrent formatter.timeZone = .autoupdatingCurrent formatter.setLocalizedDateFormatFromTemplate(dMMyyyy) let myText = formatter.string(from: Date()) By the way, for dMMyyyy and dMMMMyyyy, I can use the already pre-defined styles like .short and .long and formatting works fine with those styles. However, for dMMMM template, there is not any pre-defined style.
Post marked as solved
3 Replies
2.1k Views
I have a full screen list and want to use the new keyboardLayoutGuide constraint, but by default it uses the safe area inset. How can I disable this so my list goes all the way to the bottom of the screen when the keyboard is not shown? NSLayoutConstraint.activate([ collectionView.topAnchor.constraint(equalTo: view.topAnchor), collectionView.bottomAnchor.constraint(equalTo: view.keyboardLayoutGuide.topAnchor), collectionView.leadingAnchor.constraint(equalTo: view.leadingAnchor), collectionView.trailingAnchor.constraint(equalTo: view.trailingAnchor) ])
Posted
by
Post marked as solved
3 Replies
usesBottomSafeArea is a new property introduced in iOS 17 to address this. Watch Keep up with the keyboard for more info. view.keyboardLayoutGuide.usesBottomSafeArea = false NSLayoutConstraint.activate([ collectionView.topAnchor.constraint(equalTo: view.topAnchor), collectionView.bottomAnchor.constraint(equalTo: view.keyboardLayoutGuide.topAnchor), collectionView.leadingAnchor.constraint(equalTo: view.leadingAnchor), collectionView.trailingAnchor.constraint(equalTo: view.trailingAnchor) ])
Post not yet marked as solved
4 Replies
2.5k Views
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.
Posted
by
Post not yet marked as solved
1 Replies
711 Views
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!
Posted
by
Post not yet marked as solved
3 Replies
915 Views
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
Posted
by
Post not yet marked as solved
2 Replies
852 Views
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.
Posted
by
Post not yet marked as solved
2 Replies
Yes, thank you. I will try to rename Localizable.strings files in subprojects and use them as table arguments.