[tags:internationalization,localization]

97 results found

Post not yet marked as solved
3 Replies
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
3 Replies
You can take a look at this video because it gives an example of adding localizations to a SwiftUI project (around 50:00 in the video). https://developer.apple.com/videos/play/wwdc2020/10119/ However, instead of manually dragging .strings files into the project, you can use the export feature of Xcode by clicking on Editor -> Export for Localization... button in the top bar menu.
Post not yet marked as solved
3 Replies
Indeed most string literals that you pass to SwiftUI views and view modifiers are localizable automatically because they take a LocalizedStringKey as an argument. If you are using Editor > Export for Localization… as suggested above, you'll want to use Text objects for your strings so they are included in the exported xcloc. Most/all SwiftUI API that accepts a LocalizedStringKey also accepts a Text. Since you mention Arabic, support for Right-to-Left UI layout should be handled for you in SwiftUI. If you are explicitly specifying frames for your text views, you'll want to make sure your text doesn't clip even in languages that typically end up having longer strings than English. You can find out more about the Export process here - https://help.apple.com/xcode/mac/current/#/devafa3a605f. See all articles under Localize your app.
Post not yet marked as solved
2 Replies
1.2k Views
In our app code, we have a xcworkspace with some projects which build as frameworks or executable bundles. Also we have a main project of the app into this workspace. So all frameworks connected to the main as subprojects. Some of these projects must be localized like a main project. But they have strings files with the same names. For example: InfoPlist.strings and Localizable.strings. And when we export them to localization from Xcode the same name files miss. There is only one into XLIFF file. May be the first of them. I don't know. So all localizable strings from NSLocalizedString() macros through workspace put to one file into the main project. Is it possible to localize all our subprojects with the main project with the Export for localization tool of Xcode?
Posted
by
Post not yet marked as solved
2 Replies
You have a few options. First, from your subprojects, you can pass the bundle argument to NSLocalizedString and pass the correct bundle ID. That will ensure it doesn't try to use the app's main bundle. You could simplify this by creating your own LocalizedString function/macro that automatically does this correctly. /// NSLocalizedString replacement for MyFramework. func MyFrameworkLocalizedString(_ key: StaticString, comment: StaticString) -> String { return Bundle(identifier: com.me.MyFramework)!.localizedString(forKey: (key), value: nil, table: nil) } If you go this route and define your own function, you'll need to add that function name to the Localized String Macro Names build setting. You can also specify custom table arguments to either NSLocalizedString or Bundle if you wish in order to customize the strings file that your string appears in, even within a single bundle.
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.
Post not yet marked as solved
0 Replies
483 Views
Hello. I have just localised my app into two new languages. This is my first attempt at localising, and from what I read, I should expect at least the same or greater amount of downloads/impressions. Everything regarding the app has been localised, such as screenshots, keywords, the main app etc. It's been three days since, and the impressions for unique devices has dropped to about a 1/3 the daily average. I don't understand why this would happen. The app has been localised by a native speaker, so the keywords should be alright, and even so, the app should be ranked normally with the English keywords. Has anyone else experienced something similar?
Posted
by
Post not yet marked as solved
0 Replies
336 Views
Hi All! I've added 3 localizable.strings (de,en,pl) to my app. In one View everything is ok, in the others I can see only keys instead values. Localizable.strings is added to Build Phases/Copy Bundle Resources. In Project Inspector all languages ar marked. I already uninstall app, erased simulator, and clean build folder. Localizable.strings format is ok, I've checked line per line each file (key=value;). There are no empty lines, no comments, no duplicated key/value instances. I've also checked invisible marks. Any ideas how to deal with it?
Posted
by
Post not yet marked as solved
2 Replies
1.3k Views
For the same project, when I exported localisation using Xcode 11 or 12, it results in almost duplicates of phrases compared to Xcode 10. By checking Xliff in an editor, it shows the same phrase in two different locations. e.g. I have a phrase key of Today It shows in two locations 1) en.lproj/Common.strings <- New one 2) {Project}/en.lproj/Common.strings Is there a tutorial or documentation that shows the proper way of setting up localization in a multi-target (main app and extensions) environment?
Posted
by
Post marked as solved
2 Replies
3.1k Views
I have a in-house framework that I share between the main app and the widget. The framework contains some localized strings. These strings show up in correct language in the main app but on the widget they only show up in English. I'm guessing the localized strings from the framework are not getting bundled in the widget extension. Anybody with the same problem?
Posted
by
Post marked as solved
2 Replies
Answering my own question hoping it will help somebody else in the future: Make sure you specify the bundle argument in NSLocalizedString. Otherwise it will default to Bundle.main. You need to use the bundle of your shared framework for the correct strings to be used.
Post not yet marked as solved
2 Replies
The best-practice we recommend here is: Have your framework export a new macro / function ex: FWLocalizedString that calls NSLocalizedStringFromTableInBundle (Objective-C) or the sets the bundle argument in NSLocalizedString (Swift) to your framework bundle Use FWLocalizedString for all localized strings within your framework In your framework target, add FWLocalizedString to the Localized String Macro Names build setting Now, when you export for localization all FWLocalizedString calls will be extracted in the framework target—but not from the application or widget target.
Post not yet marked as solved
2 Replies
I think this comment could help you https://developer.apple.com/forums/thread/661201?answerId=635229022#635229022 The best-practice we recommend here is: 1. Have your framework export a new macro / function ex: FWLocalizedString that calls NSLocalizedStringFromTableInBundle (Objective-C) or the sets the bundle argument in NSLocalizedString (Swift) to your framework bundle 2. Use FWLocalizedString for all localized strings within your framework 3. In your framework target, add FWLocalizedString to the Localized String Macro Names build settingNow, when you export for localization all FWLocalizedString calls will be extracted in the framework target—but not from the application or widget target. I would invite you to file a feedback - http://feedbackassistant.apple.com about this.
Post not yet marked as solved
2 Replies
I tested again, the issue is about multiple targets instead of frameworks (although I wanted to ask something about internal frameworks too) I am adopting Mac Catalyst in our project. For reasons to include different frameworks between iOS and macOS apps, I setup one target for each. So this is where the issue starts... 1) Main app (iOS) exports to {Project}/en.lproj/Common.strings 2) Mac Catalyst exports to en.lproj/Common.strings I confirmed by removing the Mac Catalyst target to export.