I am getting the following Error pointing one of my Xib. This happens after running in Xcode 10. Please help me on this.
Companion strings files can only be specified for base-localized
documents. The output path directory does not end with Base.lproj.
The localisation workflow has changed in Xcode 10. You can find a lot of Videos about it here.
In your specific case the problem is that Xcode does not support localisable strings in combination with xib files without base localisation anymore. You will have to convert the strings to a "interface builder cocoa touch xib". You can change this in the interface builder and Xcode will automatically convert the file.
Related
Situation:
We use XCode exporting/importing tools to generate localizable files for our translators. This was going fine in XCode 8. Since we updated to XCode 9 we see a couple of problems.
Problems:
When exporting a localization via Editor-->Export for localization...-->Development language only, it doesn't include NSLocalizedString() key/values as it should according to this documentation: When you export localizations, Xcode searches your code for the macros and includes the strings files in the exported localization file for translation.
Comments that are added to the Localizable.strings development-language file seem to be non-existent in the export .xliff file.
When importing a translated .xliff file, XCode seems to delete all the comments that are in the file. It gets replaced by "(No Comment)"
Configuration:
XCode 9.0 (9A235)
Dev language: NL
Localized languages: Base, NL, DE, BE, LU
Objective-C & Swift hybrid project
What I've tried:
I have tried looking at XCode 9 documentation or changelog to see what has changed in Localization, though nothing I can find mentions this change
I can get my NSLocalizedString() strings to show up in the export when I first generate the development Localizable.strings file manually, by using the commandline command find ./ -name "*.m" -print0 | xargs -0 xcrun extractLocStrings -o . (I run it a second time for .swift files as my project is a swift/objc hybrid). Then combine the results, which let my strings show up in the export, however without comments, which are needed as guides for translators.
Question:
Is this an XCode 9 bug? Did I miss any documentation or new feature/option for localization exports/imports? Are there workarounds?
This is an older question, but I had this same issue with Xcode 10.
The solution is to simply place the strings files (e.g. InfoPlist.strings) in the same folder as plist.info. Only then are existing translations included in localization exports.
Previously I had them in a dedicated "Localizations" group. While this works for the localization itself (i.e. when running the app), localization exports seem to only include translations from existing strings files that are "near" plist.info.
What fixed both importing and exporting for me was turning off Base Internationalization by unchecking Use Base Internationalization under Project > Info > Localizations. I set all my translations in code, so I don't need it enabled for my .storyboard and .xib files.
Previously, when it was enabled, the "Localizable.strings (Base)" file didn't have anything in it, but Xcode 8 still seemed to work properly by using what was in my "Localizable (English)" file when exporting. For Xcode 9, if I had the source text in Localizable (Base) then exporting worked fine, but I still had problems with importing.
I am using Xcode 9.4.1.
I finally found the reason of the issue.
The issue exists because Xcode never saved files in the encoding it promised.
There are two places to set text encoding, one is "Default text encoding", which including a "convert existing files on save" checkbox.
There is also a file specified "Text Encoding" on each file when you open it. If you don't specify the text encoding on the file, the "Default text encoding" is used.
However, Xcode never saved the file as it promised. For example, if you choose a file specified text encoding, say to "UTF-16", an alert window shows with "Cancel", "Reinterpret", "Convert".
As the alert said, if you chose convert, Xcode would convert the file to the encoding. However, it didn't.
So when you exporting the translations, the file is opened with the encoding it never converted to and ignored.
You can verify that by these steps.
choose a source file.
change it to another text encoding.
in the alert window, choose convert
in Xcode, right click the file and choose Show in Finder.
quit Xcode.
open the file with another text editor that can deal with text encoding, mine is BBEdit.
in BBEdit, choose file -> save as
Now you can see, that the file is not saved in the encoding as it promised.
Solution
The solution is easy. For files that you specified the text encoding, keep it saved in the encoding that it specified. You can do that with other editors, like BBEdit, by save as and choose the right encoding.
For those files that are not specified text encoding. Be sure them are saved as "Default text encoding". If not, change the "Default text encoding" so you won't need to change each file.
After attempting to localize a project (originally created in Xcode 6) I am seeing an obscure error in the debug navigator.
Steps performed
Enable Base Localization
Add strings file for an additional language (Portuguese)
Edit the scheme to changing the Application Language and Application Region to Portuguese (Brazil) and Brazil respectively.
Result
"The file “Main.strings” couldn’t be opened because there is no such file."
When attempting to select the file I am presented an alert.
"The document "Main.storyboardc" could not be opened. Interface Builder cannot open compiled nibs."
As a sanity check I created a new project with the same setup (using NSLocalizedString) and ran through the same steps listed above. I provided alternate translations for the additional language, then built and ran the project which worked as expected presenting the alternate translation of strings.
Environment
Xcode 7.1.1 (7B1005)
OS X 10.11.1 (15B42)
I have already attempted following this answer but the question and answer don't quite apply to the issue I'm seeing.
I'm at a loss here. Any advice?
What do the error and alert indicate?
Why does one project (created with Xcode 6) fail when attempting to localize and yet a brand new project (created with Xcode 6) succeed?
I faced the same issue while on a project that was also created on Xcode 6. I resolved the issue in following way without compromising on localization of storyboard file:
Import the XLIFF for localized language (in my case, it was French)
Try to run the app, it will show the mentioned error
Now, right-click on storybook file and click on “Show in Finder”
From the directory location, move out the .storyboard file from Base.lproj folder
Now go back to Xcode, and remove the storyboard file (only reference)
Now, drag the .storyboard file from its new location into the project
Now, add localization from ‘File Inspector’ for .storyboard file. You can use existing .strings file for localization
Everything should work fine now.
I never found a solution to this problem by using Main.strings. Instead I kept all translatable content in classes allowing me to rely solely on Localizable.strings.
Remove app from device, clean & build your project.
I have two questions
Have any tutorial for localizing iOS app to support multiple language with app not using storyboard?
I doing my app without storyboard, I localized it by created Base.lproj folder in my project direction, copy .xib to it, and added language in Project->Info->Localization.(I tested successfully on demo) but with my app when I build and run on simulator my app doesn't update according to setting language on simulator, it only update when I rebuild. Anyone could give me a reason or doubtful questions?
When you localize resources in your Xcode project, you don't need to copy anything: Xcode does everything for you. If you start copying things here and there, you might get lost, and files might not even get copied to your app bundle.
What you need to do is:
1/ Reference all languages in your Xcode project
2/ Create a new "Strings" file in your project using Xcode, call it "Localizable.strings", and create localized versions of it through Xcode, using the "Localization" pane in the File inspector
3/ Once you have created multiple versions of your Strings file, enter a sample string that you will test in your app, like:
"HELLO_STR" = "Hello, world";
in your English version, and
"HELLO_STR" = "Bonjour tout le monde";
in your French version.
Then in your application startup code, add this line:
NSLog(#"%#", NSLocalizedString(#"HELLO_STR", nil));
The message logged in your console should now correspond to your device or simulator language setting.
4/ You now need to add all localized strings to your Localizable.strings files.
5/ As for the XIBs, it works exactly like the Storyboards: you can ask Xcode to create a localizable version of all your XIBs. They are copied and bundled by Xcode in much the same way as the strings file we already built in steps 1-4. It is better to do that once you have "finished" designing your interfaces, because any subsequent modification to one localized XIB version will have to be repeated in all other localized versions.
Good luck.
I have the following file structure for localization.
A.xib
->A.xib (Base)
->A.strings (Spanish)
->A.strings (English)
Since it is "Use Base Internationalization". We can expect to have only one xib file and required strings file for the localization.
But, soon as i convert this strings file to .xib (where for each language we have .xib file. This was the case before Base Internationalization). Things start working the iOS simulator and device responds to such changes.
Note:- I had also tried to reset the simulator , clean and created the build but no success.
Don't know why localization fails when I use .strings file for localization.
Any help appreciated for a , small bug consuming more time on Xcode IDE and eating up development time.
In Xcode 6 you need to select "Use Auto Layout" in order for the strings file to be used. There is a known problem if you do the following:
1)Your storyboard or XIB uses size classes.
2)The base localization and build target are set to Universal.
3)The build target is for iOS 7.0
You can use the Localizable Strings to generate a localized XIB file automatically through Xcode, which is what you need to do if you do not enable Auto Layout.
It's a bug in Xcode.
All you have to do is to convert the Localizable Strings file to an Interface Builder file.
You can do that under the Localization section on the interface builder's file properties.
I'm localizing an app for the first time, and only need to localize my "Localizable.strings" file. To set that up I created the file, then selected it and pressed the "Make localized..." button and it let me add an English localization (I haven't added any other languages yet).
To my surprise, with Xcode 4.4, doing that also automatically localized these files, moving them into the "en.lproj" folder:
InfoPlist.strings
MainStoryboard.storyboard
I don't need or want to localize the storyboard file, as there's nothing in it that's language based... and as far as I know, I don't need to localize InfoPlist.strings either (unless I decide to localize the app name?).
So, how do I unlocalize a file?
I see there's an option for "Use base internationalization" which from my understanding would use a base main storyboard rather than localizing it. That sounds like what I need, but according to the Xcode 4.4 release notes that won't work on iOS projects:
The Use Base Internationalization setting in the project editor works
only on Mac products for deployment on OS X v.10.8 and later. Xcode
must also be running on OS X v.10.8 or later. This setting is not
supported on iOS projects. 11712855
https://developer.apple.com/library/mac/#releasenotes/DeveloperTools/RN-Xcode/_index.html
Thanks for any help.
If you select a file and look at the info for that file. Under the "General" tap there is a section for localization with a +/- for the various languages. Just remove all the languages from there and it will no longer be localized.