Post not yet marked as solved
Yes, thank you. I will try to rename Localizable.strings files in subprojects and use them as table arguments.
Post not yet marked as solved
How can I submit a feature request to support a new language on iPhone (keyboard) and is there any place I can see which languages will be added in the future? Thank you
Post not yet marked as solved
The Text and Button elements in SwiftUI are automatically localisable. Text(Hello World!) or with a variable let hello = LocalizedStringKey(Hello) Add Localizable.strings to your project. English Hello World! = Hello World!; Hello = Hello; German Hello World! = Hallo Welt!; Hello = Hallo;
Post not yet marked as solved
I encounter a frozen screen and then the app just quits and restarts after 2-3 seconds. Does that generate a crash report? If so, please post it here. See Posting a Crash Report for advice on how to do that. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Post not yet marked as solved
I followed the advice from one of the latest WWDC videos on how to handle localization and in my app I launch Settings of my app when the user wants to change the app language (not system language). The user can then select one of the available languages that my app is localized for. The localization part works well, but sometimes it happens that when I click the < My app button in the leading, top corner or just navigate back to my app, I encounter a frozen screen and then the app just quits and restarts after 2-3 seconds. I don't need to preserve any state when the user changes the language, but I would certainly like to prevent this freeze from happening. The desired behaviour would be that the app restarts once the use changes the app language. I use SwiftUI as the UI framework. I use the following code to open the Settings of my app for the user: UIApplication.shared.open(URL(string: UIApplication.openSettingsURLString)!) How can I achieve that?
Post not yet marked as solved
Thanks for you answers. I had to delete the localization resources for the languages that weren't ready yet and now it works as expected.
Post not yet marked as solved
Ok, so I understand the high-level reason Base Localization is used in an app, the problem it solves, and the ultimate goal it's trying to achieve. But I don't understand the real meaning of the concept of Base. What is it exactly? I've got several questions Question 1: Is it called Base Localization? Base Internationalization? Just Base? Are all these synonyms? I will use the term Base Localization for the remainder of this question. Question 2: Yes/No Question: Is Base Localization really a localization? If the answer is YES: Question 2.1: Then why does this answer say that it's not? Is the answer right or wrong ? (That forum contains very good explanations, but I want to be strict with the meaning of Base) Question 2.2: See the images below. Why does it get grouped with other 'real' languages (Spanish, French...)? In which country is the Base language spoken? (I know that's an ironical question, but it's to make my point clear). If the answer is NO: Question 2.3: If I create a new app from scratch in Xcode
I am trying to localize an iOS app that also ships an App Clip. The main app and the App Clip share many (but not all) of the same localizable strings. Using Product -> Export Localizations..., I can generate a .xcloc file that contains all the localizable strings found for each of these two targets. However this results in a large number of strings being duplicated. For example, if I have a file with Text(bla bla bla) that is included in both the main app and the app clip, the string bla bla bla appears twice in the xcloc: once under MyApp and once under MyAppAppClip What is the recommend workflow when you need to localize multiple targets that share strings? Ideally I'd like to be able to send a simple set of files off to the translation and then import the results without having to manually copy arounds strings. Do I need to split all the shared code out to a shared package instead of just including shared code files in both targets?
Post not yet marked as solved
Hi, Our situation is as follows: We have a Dutch app(Also one product page - Localization: Dutch) that can be downloaded by anyone in any country. The current app has a unique name and can be found and downloaded in every country. Now we want to change the app name but we see that the name we want to use has already been taken up by some languages/regions. What happens if people search for our new app name in a certain region/language, but the name has already been claimed in that region/country. Can our customers find our app? I am therefore curious about the behavior that arises when someone searches for our new app name that is already taken in a certain region Kind regerds,
One of the possible values of the forecast property conditionCode is sleet. But according to wikipedia this term refers to multiple, quite different weather phenomena. Some harmless and other potentially hazardous. What type of weather does sleet refer to in the weatherKit API?
Post not yet marked as solved
How about dust then? Does it refer to dust storms?
Post not yet marked as solved
Today I ran into the same problem, is there already a solution for this problem?
Post not yet marked as solved
Try manually renaming your lproj folder from sq-XK.lproj to sq_XK.lproj. You should quit Xcode before doing this to ensure you don't have the project open in any capacity.
Post not yet marked as solved
Sorry for the late Reply (somehow I wasn't notified about your answers). @Claude31 I test on a real device. Thanks for the link. Unfortunately, the provided solution is nearly the same compared to what I have already tried with Locale.preferredLanguages above. @Frameworks Engineer To obtain the device language is a product management requirement to derive next steps in the app localization process.
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.
