I have a UITextField with UITextContentType equal to oneTimeCode.
It works as expected if the message is in English and the keyword "OTP" exists.
It doesn't work if the message is in Greek and the keyword "OTP" is translated also in greek.
Is the OTP keyword really needed? Is there any alternative? Which are the keywords for any case? Are these keywords only in English?
Thanks in advance!
Localization
RSS for tagLocalization is the process of adapting and translating your app to multiple languages.
Posts under Localization tag
66 Posts
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I am using Xcode 15 and working on a localised app. I use the new String Catalogs feature which works great for my app. In my app I created some local package like Apple has done it in the Backyard Birds example. However the translations I did in the package's String Catalog won’t be used in the app. What am I doing wrong?
I recently noticed an inconsistency in how languages are represented in Apple’s new Translation API compared to Foundation’s Locale system.
Observation from the Translation API
When retrieving the list of supported languages using:
let availableLanguages = try await LanguageAvailability().supportedLanguages
The results are:
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(uk), script: nil, region: Optional(UA)))
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(zh), script: nil, region: Optional(TW)))
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(ko), script: nil, region: Optional(KR)))
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(en), script: nil, region: Optional(GB)))
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(de), script: nil, region: Optional(DE)))
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(zh), script: nil, region: Optional(CN)))
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(ja), script: nil, region: Optional(JP)))
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(id), script: nil, region: Optional(ID)))
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(nl), script: nil, region: Optional(NL)))
....
Key points:
• The script component is always nil.
• Region codes (CN, TW, etc.) determine the script for languages like Chinese (Simplified or Traditional).
• Other languages (e.g., en-GB, en-US, pt-BR) also rely on region-based identification.
Observation from Foundation Locale (Locale.current.language)
When retrieving the user’s system language setting:
systemLanguageObj = Locale.current.language
I get a different format where the script component is present, but the region may vary based on user settings. This means that mapping between script and region is not consistent between the two APIs, requiring manual handling.
My key questions:
1. Is my current approach correct, or is there a better way to get user language settings that match Translation API identifiers?
2. If no alternative exists, could the Translation API align its language identification method with Foundation Locale to reduce ambiguity?
Any insights or suggestions would be greatly appreciated!
In a project I was using Local Authentication to authenticate a user. When I got a request to support smartcard/PIV token authentication (which Local Authentication does not support), I had to switch to Authorization Services, which works pretty. There's only one issue I have. Local Authentication's evaluatePolicy:localizedReason:reply: requires a reason in the form "<appname>" is trying to <localized reason>. The app is currently translated into 41 languages and I would like to use the localized strings for the AuthorizationEnvironment of Authorization Services as well. The problem is that Local Authentication prefixes the localized string with something like "<appname>" is trying to and Authorization Services does not do this. Is there a way to get this prefix from somewhere so I can manually add it to the (partially) localized string? Any help would be highly appreciated.
Thank you,
Marc
Hey, meanwhile it's a great thing to program apps on the iPad and to be able to load them into the App Store Connect and the App Store.
What about localization in the meantime? When I open the folder en.lproj in sample apps from XCode, then there are two files stored in it:
Glossary.plist (XML) and
Localizable.strings (binary)
Is it correct that XCode creates binary files from the strings? Otherwise, Swift Playgrounds already offers localization in the localized learning content, but i guess the binary files can only be created in XCode?
Our app support English and Traditional Chinese only, so the Xcode config and the app store setting include these 2 languages only now.
However, the support languages displayed at the App Store show our app support Simplified Chinese.
Would like to know is there any config we missed or wrong setting we have done?
Appreciate for any reply or suggestion.
Topic:
App Store Distribution & Marketing
SubTopic:
App Store Connect
Tags:
App Store
iOS
Internationalization
Localization