I'm using the ibtool to localize my nibs. I run the following command:
ibtool --generate-strings-file MainMenu.strings en.lproj/MainMenu.nib
I then add the generated .strings file to the xcode project so that I can reference and edit it later.
When I do that, if I select the .strings file in xcode, it displays a bunch of upside question marks and garbage. However, if I choose not to add the file and manually open it using xcode, it reads the file perfectly.
I can only guess that ibtool is encoding the file in an unreadable xcode format.
If I open file .strings file in xcode, copy the contents to the clipboard, close the file, add the .strings file to xcode, replace its garbage contents w/ the contents in the clipboard, and then save the file, its fine. I also notice doing that will reduce the size of the .strings file by half.
Any guidance would be appreciated.
Thanks!
Yes, somehow XCode fails to auto-detect the encoding of the generated file which is UTF-16 as required by specification. But when you add the generated file to XCode you have the option of choosing the character encoding (it defaults to UTF-8). There should be a dropdown for this right below the "Copy items into destination groups folder" checkbox. Just select UTF-16 and you should be fine. You can also choose the encoding in which XCode opens the file at any later time. To do this just right-click the strings file, select "get info" and you should get a drop down list of encodings.
Related
I have a .strings file that is localized in a number of languages. I'd like to add it to my Xcode project. How do you get Xcode to correctly reference the files? I've tried
dragging the english version of the .strings file (found in English.lproj) to Xcode and hoping it would automatically pick up the other localized versions of the file -- it doesn't.
dragging all 5 localized versions of the .strings file (found in English.lproj, es.lproj, etc.) assuming Xcode would create a single file reference with the various localized versions -- it crashes.
dragging each of the .lproj folders to Xcode hoping it would figure out that the file in each of the folders is all the same file, but localized -- nope
dragging the English version of the localized .strings file to Xcode, then add a localization that already exists -- Xcode warns that it will overwrite the file, but doesn't give the option to use the existing file.
UPDATE: Submitted a bug report to Apple: #10181468.
The simplest way as of Xcode 4.6 is to drag localization file (.strings file, not the folder it's located inside of) from Finder to the Xcode project tree. Be accurate and drag to the top of .strings group, not to the bottom or inside of the group as the latter makes Xcode crash.
Add the original file (only the file, not the .lproj folder) then make it localizable, add all languages you want, xcode will create .lproj folders and duplicate your original file for each language.
After you can overwrite each file duplicated by your already translated file (either the file if it have the same name or content).
Don't forget to set the format of the original file to UTF-16 when you add it.
After upgrading to iphone xcode 4.1 build 4B110F all of my localizable.strings files are showing up as gibberish in the xcode editor. I created these files using UTF-16. I can not find a way to tell the editor that they are UTF-16. I am able to view the Localizable.strings files by viewing as a property list, but if I view them as Source Code, I see gibberish. I like to translate the entire localization.strings file and paste it into the editor. I don't want to have to cut and paste one line at a time in the property editor. There should be some way to tell xcode to show the file as UTF-16. Does anyone have any ideas?
I tried removing the files and re-adding them. I used to get prompted for the UTF type, but it does not do this any more.
You can find the text encoding setting for a file in the Utility area of Xcode 4.1. The utility area is the right-handside lateral area.
In the utility area, look for and select the first pane, named "File Inspector".
There, you will find the text encoding in the "Text Settings" block. Expand if necessary using the triangle.
I had this same problem. I was able to work around it (without much actual investigation) by simply opening the previous string files in TextWrangler, then copy from TextWrangler and paste into XCode4's view of the string file. Things seem to be working fine as a result.
To fix XCode 4.1 UTF-16 encoding issues:
1: Open the file you want to change
2: Put your cursor into the file, which will give the editor focus (VERY IMPORTANT).
3: Proceed to look under the Utilities Pane (very far right) for Text Settings and use the Text Encoding drop down to select UTF-16 or whatever other encoding you want.
If you forget step 2, and only highlight the file in the Project Navigator, you will not see encoding options.
I am learning how to localize the strings in my project and I am using Xcode 4.
I have generated the base Localizable.strings file, and I want to import this file, changing its encoding from utf-16 to Unicode utf-16 so that the text in the file is readable within xCode. If I strate import this file, when I select it within xcode, the text shows up as gibberish.
In Xcode 3 when you drag the Localizable.strings into your project, the dialog box which appears gives you the option to change the text encoding, but this is not the case in Xcode 4.
Does anyone know a way around this?
Maybe this can help you Objective C/Xcode 4: Encoding Problem with Localizable.strings files
These kind of errors can happen if you copy and paste content within Xcode or from external files in your localization files. The consequence is that the encoding of the file changes to for example Western (Mac OS Roman). The Localizable.strings file should be in UTF-16 though.
Solution
1.
Like in the picture below, navigate in Xcode to the Localizable.strings location and open it so that you can see all the languages you are supporting.
Left-click on the language file the causes the build error.
Make sure your Utilities View is showing in Xcode. Activate on the button at mark 1 in Picture below.
In the Utilities View select the File Inspector. (Small Logo that looks like Page)
Under Text Settings change the encoding to UTF-16(Marked as 2 in the picture above). The Drop-Down might be grayed out but you can click on it anyways. Click on "Convert" on the Popup.
That's it your project should now compile again.
The "Text Settings" for my Localizable.strings files don't have the option of changing the encoding like XCode 3. However, I found if I simply restart Xcode 4, it reinterprets it correctly (UTF-16).
Sometimes Xcode displays the warning, even if the file contents are UTF-16, but the file is somehow interpreted as UTF-8. iconv usually says that it can’t convert the file in this case. Converting the file in Xcode to UTF-8 and then converting it back again to UTF-16, like Edmar suggested, solves this problem. The warnings are gone.
To make sure that nothing got broken during the conversion, recheck the whole strings file.
After changing the encoding, and re-executing the genstrings command to regenerate the localize string, things should work.
View -> Utilities -> Show File Inspector
Change Text Encoding in the file inspector utility view.
I have a project with two Info.plist files (one for each target). In the second Info.plist, when I add a field it shows the internal name instead of the English name. For example UISupportedInterfaceOrientations instead of "Supported Interface Orientations".
Also, when I click on the dropdown list to see all options, some of the options that are available in the first .plist file are not in the second (eg CFBundleIconFiles). The two problems are really the same thing (anything which shows the internal name does not appear in the dropdown).
The Bundle Verion is 1.1 in both files, the CFBundleInfoDictionaryVersion are both the same, as are the plist version and the DTD.
What's stopping the second plist from giving me these options? Thanks.
alt text http://img.skitch.com/20100708-ctia2e6yfwgd7twdnepryidayr.jpg
Xcode has a couple of different editors to show the contents of plist files. One of them is the generic plist editor, which shows the names of the keys without translation. The plist editor can also be in the specialized Info.plist mode, where it knows about the structure of this special type of plist file and translates keys to english.
I don't know how Xcode decides which editor to use, so the following is just guessing: I assume Xcode looks into the selected target to check the path to the Info.plist file and if it is the edited file, uses the specialized editor. So if you have one target selected, but open the other targets Info.plist it might use the generic editor instead.
Xcode also manages file types for each file in the project. You can override Xcode's automatic guesses by opening the file's settings (click on the file in the outline view and press command-I). Maybe there's a file type to identify Info.plist files.
As a last resort, you can always open the file by right clicking it in the outline view. In the context menu from "Open as ..." you can choose how to open it. I usually use "Source Code File" since I like to see the original XML.
Typically, there are times when not all options are shown. If you know it is supposed to exist, you can just add the key (via copy/paste) from the XML file of the other info.plist. I normally just open it up as XML and work in that mode (which gives non-English names).
All keys can be found here: http://developer.apple.com/iphone/library/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html
In the latest XCode, it has been converting everything automatically to English names for me though even when I try to paste as a non-English name in the property list editor.
Short Answer
Select iPhone Info.plist from the View > Property List Type menu.
Explanation
This actually has nothing to do with the plist file itself. It's how Xcode (via the Property List Editor) presents the file.
You can test this by, in Finder, making a copy of a correctly-displaying plist file. Open the copy in the Property List Editor (usually the default application). The copy usually won't display the English names (until you change the Property List Type).
Xcode will remember the type you select and save it in the .xcodeproj file.
For some reason I cannot get the Settings.bundle to recognize my additional languages. I must be missing something obvious, but I just cannot figure it out. Here's what I've got:
Project Structure in XCode:
Root.plist file:
Root.plist file http://img227.imageshack.us/img227/571/screenshot20100624at334.png
French Root.strings file
french Root.strings file http://img121.imageshack.us/img121/571/screenshot20100624at334.png
From everything I've read, I believe the project structure is right. The StringsTable in the Root.plist matches the name of the individual .strings files, and the Key for each item in the Root.plist has a match in the .strings files as well.
Why don't I see French text in my settings when I change the default iPhone language?
Thanks in advance!
For me, the problem was leaving off a semi-colon!
In localizable.strings, you get a runtime error if you omit the ";", but in Root.strings, you don't get any warnings, you can run it fine, but it just won't work!
So double-check to make sure you punctuate each key:value pair with a semi-colon!
I'll go ahead and answer my own question since I solved the problem myself through testing and failing. Hopefully this will help someone else in the future.
First, I think my Root.plist file may have been corrupted. I'm not exactly sure why, but I completely deleted the Settings.bundle, and re-created it to be sure.
Second, and perhaps most importantly, the main issue was the "key" in the root.strings file didn't match to the "key" field in the Root.plist, it actually matches the "Title" field.
Once I made those changes to the Root.strings file, it all started to work.
All you have to do is keep (or Add, if it's not there) "Strings Filename" in the Root.plist, after your settings.
Then, add Value "Root" (or, the name of your file and the translations) to make the created lang.lproj translations functional.
In my case, it appeared as if "Strings Filename" was set to "Root" in the Property List View of Root.plist, but when viewed the file in Source Code View, it was actually "StringsTable" pointing to "Root". The solution is to add another entry where "Strings Filename" points to "Root". (I also tried deleting the previous entry, but then it stops working, so you need both.)
In Xcode 5 there is still no obvious way to localize the Settings.bundle.
The problem
Xcode doesn't allow you to localize a file that is only shown because it is a file inside a folder that's directly shown in Xcode (hence the blue folder icons in the tree).
The Solution:
right-click the Root.strings file and select "Show in Finder"
List item
move the Root.strings file one folder up, so that the en.lproj folder is empty and the
Cmd-Drag the Root.strings file is next to the Root.plist.
delete the now empty en.lproj
go back to Xcode, notice that the tree will reflect the changes you now made
cmd-drag the file in the tree outside to outside the settings-bundle, so that it appears next to your source-code.
Do not copy the file
a dialog will appear asking you what to do with the file.
DO NOT select the checkbox to copy the file (you need this to be a reference)
DO NOT select a target to include the strings-file (the settings.bundle is already assigned to the correct target)
in the file inspector you can now choose to localize the file and to add languages to the localizations. The files will be placed correctly inside the settings.bundle and the tree will automatically reflect these changes, too.
After some repeated tries to activate localization,following steps worked for me:
Close xcode
Drag and duplicate the settings bundle onto the desktop (or wherever)
Open bundle contents
Drag Root.strings into
the en.lproj folder
Duplicate the en.lproj folder and rename to
whatever language you want (using 2-letter code ie fr.lproj)
Replace the original settings bundle with the new one(without
opening xcode).
Now Open xcode and the new files and folders
should be there
Now delete the older app and run xcode,Works fine in simulator and on device.
NOTE:Closing xcode,updating of duplicated setting bundle outside xcode and replacing updated back only will help.