Somehow I can't seem to get my localized launch image to work.
In the root of my project folder I have a localized Default#2x.png with both an English and a Dutch version.
Somehow the Dutch version is shown in all situations.
I have other localised files that work all right (Root.strings, Localizable.strings, InfoPlist.strings) when using English language.
I've looked up several related questions, but found no answer. Tried deleting the file all together en adding them again. After localizing the file I added the right picture to the right folder using 'Show in Finder' on the English version.
Other answers suggest that there's another copy of Default#2x.png somewhere that's in the way, but I can't seem to find one.
When I look at my project folder in Finder, some folders seem recursive (repeat themselves) though.
Any help is appreciated.
Launch images can not be localized. See the app programming guide:
All launch images (...) must reside in the top level of your app's bundle directory.
Related
TLDR: Xcode generated storyboards for each language, however I want the "old"(?) *.strings files. How?
I am currently in the process of localising my storyboards. After I enabled everything, Xcode generated another storyboard alongside the original (english) one for me to localise. I was surprised, I expected a Localizable.strings file, like the apple documentation still states as of April 3, 2021:
For storyboard and XIB interfaces, select the user interface files (files with a .storyboard or .xib filename extension). Xcode adds a strings file to the localization folder that contains the text to translate, as well as comments that describe the user interface components. For example, if you add German to an iOS app that uses storyboards, LaunchScreen.storyboard becomes a group containing a LaunchScreen.storyboard (Base) and LaunchScreen.strings (German) file.
I searched around the internet, in apple developer forums, watched both WWDC18 and 19 talks about localisation in Xcode, but did not find a single mention of translated storyboards.
After the initial translation, which works great due to the simplicity of just filling everything in, it gets frustrating however, since every layout change needs to be repeated for every language. This can't be intended, there must be a better way, right? Sadly, I didn't find anything. Even a hint to a piece of documentation regarding these storyboard copies would be greatly appreciated. Thanks!
There are some screenshots of the possibility to convert these two formats via a dropdown, like the third picture in this post. However for me, there is no dropdown next to the language item when I click the storyboard, neither on the group, nor individual base or localised ones:
Is this a bug or am I missing something here? I am using macOS Big Sur 11.2.3 with Xcode 12.4 (12D4e).
Turns out, you need to use the Base Localization feature, the dropdown then appears and you can convert existing storyboards to *.strings files.
I can see that this is a recurring problem with all sorts of Xcode versions. I'm using the latest non-beta build (9.2 9C40b).
I have already localized in Spanish. Doing that involved successful exports and imports of xliff files, with same Xcode. So what changed?
I am now trying to localize to another language. This is a showstopper. Any hints? I have looked through all the posts about previous versions crashing, and have not found anything that works.
(And before you mention it, I am done and over with genstrings. If it exists anymore.)
I've discovered that large .xliff files (more than about 6,500 lines or 1,200 <trans-unit> elements) cause Xcode 10.1 to crash consistently near the end of an import operation.
The work-around is to manually split the .xliff file into two distinct .xliff files, each containing a subset of the <file> elements in the original file. You can then import the two resulting .xliff files into Xcode separately without crashing.
Do not translate "bundle name"
I wanted to translate to Greek Language and every time I was importing xliff files, Xcode was crashing.
I realized that the problem was, that I was also translating "bundle name".
If you did the same mistake, open xliff file, find:
<trans-unit id="CFBundleName">
<source>NameOfYourApp</source>
and delete the line
<target>...</target>
After that everything worked perfect for me!
Here's a workaround. Select your project icon in the Project Navigator. Select Info at top (as opposed to Build Settings). Under Localizations, click the + button and add your new language.
Xcode will create the new .strings files and fill them up with pre-existing translations. (If there are any.) Strangely, for me, some of the new .strings files were filled in with English, some with Spanish.
In any case, you have the new .strings files and can manually paste in the translations for the new language. If your app doesn't have too much user-facing text, this isn't onerous.
But really, with this problem going back to Xcode 4 (!) one would think it would be fixed by now.
it's a late answer I know, and I'm using Xcode Version 10.1 (10B61) already.
In my scenario, I added Chinese Hong Kong (zh-HK) language under Project > Info > Localization and exported successfully then sent to the agency for translations. After few days they sent to me Chinese translated text within. At that point, everything seems correct for me by eye. But I've tried 10 times to import file and it crashes 10 times without exception! Which makes me sick. I use to checked to see the difference between 2 document via Apple's File Merge App. I understand that agency geniuses added few missing <\target> tags. Hmmm, that means while exporting Xcode didn't add for some translations <\target> tag. Interesting...
I removed those unnecessarily translated tags and checked everything was equal in 2 documents except translations of the words to the Chinese language.
Tried to import again. Then BOOM! It works like a charm! I was surprised by this. It's so weird that Xcode never shows me a descriptive message about my mistake. Probably, It's just a parse error for Xcode.
Whatever, I hope this will work for someone else.
Best.
Well, I received this project from a buddy that used to work with me and now I am responsible for it Internalization. I need to transform the language of the app to English, that is currently Portuguese.
Although i was researching for some tutorials but all of them include one step i cannot make. I have noticed there were no files localized in any of the languages, and no folders .Iproj too.
In the info tab > Localizations shows up, in each language added in my "Resources" Tab, "0 Files Located".
as Soon as i click "Use Base Internationalization" or the "plus" button there is no file i can reference it to.
I need to follow with this project and cannot create another one, there is lots of code and configurations that need to stay in this one. Is there any solutions?
Thanks!
PS: StackOverflow won't let me post images yet :(
Have you ever visited this panel?
This is one of those silly simple problems, that is so simple I can't figure out what is causing the problem.
I localized 80 or so images by clicking the image, the localization button and clicking the languages french and chinese and the folders were created. [FYI our app already has string localization implemented and working]. I then copied the translated images into their respective folders.
Now I can click the image's left arrow drop down, then click the french and chinese image and I see a french and chinese version of the image. I then restart the simulator, then change the language to french and run my app and the strings are all in french, but the images I localized are still in english [same with when i try chinese].
Additional info:
my images are in their respective en.lproj, etc folders with no images in the base folder.
When I check "Copy Bundle Resources" the images are shown to exist in the base folder; their is only 1 image referenced per resource; ie. it doesn't explicitly show all different language images.
I've tried ios 5.1 and 6, and both retina and not retina.
It sounds like you have everything set up correctly. I'd recommend testing on an actual iOS device.
In my experience, the simulator is pretty glitchy when it comes to localization. Here are some workarounds, none will work 100% of the time unfortunately:
Set the locale of your Mac to the same locale as inside the simulator
Reset using iOS Simulator -> Reset Content and Settings…
Clear the Derived Data in Organizer -> Projects -> Derived Data
Use Product -> Clean before you rebuild
Submit a bug report about it!
For localization, it's best to test on a device.
Try deleting your app from the device. Do a clean. Then run again. This forces Xcode to copy everything over again, including your new files. Whenever you modify settings bundles or resources, deleting and re-building is best.
I appreciate your help in advance. I have searched high and low for an answer with no luck.
I have an app that uses very specialized sports terms which I store in a plist file. Those terms are then displayed in a UITableView. When the user taps on the skill, a video demo is played. The app works great, but I would very much like to localize it for other languages.
I have gotten the terms translated, and I was hoping I could localize the plist file by making a copy of it and just changing the sport-specific terms in each successive copy of the file, and then put it in its respective language folder. Is this possible and if so, can someone please point me to a good example or tutorial?
So far, I have I have tried to localize the plist file for Russian in Xcode and put it in its own ru.lproj folder, however, then when I run it in the simulator no data appears at all in the UITableView! Without the Russian file, it works fine. So my thought is that somehow Xcode is confusing the plist file because the name is the same, even though it is in a different directory (en.lproj and ru.lproj). The file is called Basic.plist in both directories. This process is totally confusing to me, and from what I gather it shouldn't be that difficult to figure out!
Again, thank you in advance. The localization concept is completely new to me and I am eager to learn it. I am quite sure I understand how the .strings files work with strings that are embedded in code, but I would like to know if it is possible to translate an entire pList file.
A lot of things could be wrong. One possibility is that the plist files don't get copied into the bundle (verify in your target's Build Phases page--it should say Basic.plist with "...in (localization).lproj" written next to it.
If you have manually created the ru.lproj, maybe you copied it in the wrong place, or left the original file in the wrong place (it should now be inside en.lproj). Rather than manually create the file, it's easiest to select the file Basic.plist in XCode and use the Localization control inside File Inspector to add localizations. As Kevin Grant mentions, if this doesn't show your file as having English and Russian, then something is wrong, and you could start again using the + control.
Finally, I'm not 100% sure about this but close enough: I believe your code probably needs to be updated to figure out where to load the plist file from. It it were a .xib or a .strings file, you wouldn't have to do this as this would be automatic and iOS knows to look inside the relevant .lproj folder first (when you load a .xib you only specify its name, not its exact location). But I assume you are loading the plist file through a specific path, therefore the path must now include the .proj folder.
If possible for you, I think a nicer approach to having different plist files per language would be to have just one plist, but instead of displaying the string from the plist you could use it as a key to your .strings file. You can retrieve the localization using the NSLocalizedString macro (which is defined as [[NSBundle mainBundle] localizedStringForKey:(key) value:#"" table:nil]) which will give you the corresponding value in the localized .strings file at run time. Of course this would mean that when you update your plist, you would also have to update your .strings files to match. The good thing is that you wouldn't need to determine the path of the plist for your active language -- with NSLocalizedString, you don't provide a path at all.