I'm trying to follow the tips in Apple's I18N and L10N Guide. I have a pre-existing project from which I have (long ago) deleted the Base.lproj folder. Why? Because I have no Main.storyboard or LaunchScreen.xib. Both of those things are handled programmatically.
However I do have a large number of subsidiary storyboards, including a WatchKit Interface.storyboard. When I click the + in the Project (not target) Localizations section, Xcode presents a dialog that lists only the Interface.storyboard file. Not any of the many others.
How can I persuade Xcode to help me localize the other storyboards? Can I do this all manually? As usual, I am sure it is my mental model that needs refinement.
This is an example where configuration yields convention. That is, if you customize your folder hierarchy, Xcode can adapt and implement its naming conventions.
Select storyboard file in left pane (Project navigator)
Click Doc icon (File inspector) in right pane
Click Localize...
This will create a new Base.proj folder inside whatever folder holds the storyboard. If you are like me, you have done lots of folder-factoring. Xcode goes along with this.
Then you go back to the Project Localizations section and click + to add locales. Xcode creates extracts the strings from your storyboard and creates new folders for the corresponding .strings files.
I'm currently translating my application (Mac OS X app) into another language. I've done almost all translations, but now I'm stuck on a pretty strange thing:
I have an additional window for the applications settings and translated the GUI elements the same way I did it for the main window. I imported the translations into my project which seemed to work fine because I can use the preview windows, switch the language of the assistant editor to German and see that the dialog will be localized correctly.
But as soon as I run my application (with "German" as language) and open the settings dialog the whole dialog is still in English (the base language).
The settings dialog's XIB file is located in the base.lproj folder and the corresponding .strings file is located in the de.lproj folder (which should be correct as the preview shows the correct translations).
I don't know what's going on and have no clue what might be the issue.
Does someone have any clue?
I'm using Xcode 6.1.1
I found the reason for this issue: Localizing the settings dialog forced Xcode to move it into the Base.lproj folder. But instead of moving the file Xcode just copied it into that folder - so the XIB file for the dialog existed twice and Cocoa used the old one (which was not localized).
After cleaning the build directory and deleting the derived data for the project the localization works fine now.
I've just had a Phonegap/Cordova iPhone app approved for the app store but noticed it claims to be available in a bunch of other languages including Northern Sami. I've found the list of languages in xcode under localizations and tried deleting them but if I restart xcode they re-appear.
I've also tried deleting lproj folders in the resources folders but that doesn't help either.
I'm at a loss to what to do next so any help would be much appreciated.
Here is a step by step guide of how I do it. (Order matters)
First go to the Resources folder in the Phonegap project. Within this folder there are several folders ending in *.lproj. Delete all of them except for en.lproj (Assuming your language is english).
Even though you deleted those files from your hard drive they're still linked in Xcode. Open up your *.xcodeproj and delete all of the folders from the side bar once again.
Normally this should suffice, but if you're still having problems go to the app's project tab (rather than target) and under info you can find and remove all the current localisations.
Oh and btw if this still isn't enough you can look at the details of your app's binary in iTunesConnect to verify if it worked before releasing the app.
We localized a project recently into to 15 languages using Xcode but I noticed when I took the project home the paths to some of the localized files were all hardcoded to the full path of my work mac.
We only localized two files:
InfoPlist.strings
Localizable.strings
We used Xcode to do the localisation as follows.
We added the 15 languages to the whole project.
Then clicked on Localizable.string and in
File Inspector > Localisation > +
clicking + we added it to the 15 languages we set up for the whole project.
Localizable.strings then moved into
en.lproj/Localizable.strings
fr.lproj/Localizable.strings
etc.
We sent
en.lproj/Localizable.strings
to the translators and as each returned we replaced the file in each translation folder.
This was done through Finder not dragging files into XCode (I think, it was a while ago)
To meet deadline I took the project home but when I opened it all the localized files except English were showing red in XCode as if the file was missing.
In finder they were there but I checked File Inspector/Full Path and it was hardcoded to the path of my work mac.
Also the LOCATION drop down was set to ABSOLUTE PATH for the missing files
but is DISABLED so cant change it to RELATIVE TO GROUP.
I noticed the path included a folder with a space so thought maybe this might be the problem though then EVERY file in the project should have problems.
Only way to fix it was tob back up using Finder/Duplicate on each .strings file using Finder.
Then click on Localizable.strings in Xcode (top level/ not individual localization)
Then in File Inspector delete the missing Localizations and re-add it.
This will ask you to replace the existing file (it copies the en.lproj version over it, thats why you need to back up with Duplicate)
so after you need to go back into Finder and put the Duplicate back.
any idea why it happens?
or how to change it easily (Location drop down is disabled).
Any idea why the drop down to set a file RELATIVE TO THE GROUP is disabled.(I presume its because XCode manages the Localisation)
cheers
I'm trying to wrap my head around Xcode's file organization - or lack there of. I can do all I want in project and it looks great with all the "fake" folders and structure. I go look at the file system and boom HUGE mess. I've tried importing files with the Create Folder Reference for any added folder option checked and that works, kinda. I get the structure I want both in Xcode and on the filesystem.
Issues: When I add a file to a folder on the filesystem that is a Folder Reference in Xcode, its not in Xcode when I go look, not even after reloading the project. Files/Subfolders in a Folder Reference can't be moved around in Xcode. When I move them on the filesystem I get red links (can't find the file?) in Xcode.
How do I keep a organized project and filesystem? How can I set up a project to just recognize a folder and show its (current and up-to-date) files and subfolders in my project?
Another issue I seem to run into, if I use a Folder Reference and change a file, the file is not updated in my application unless I do a full clean & rebuild. If I don't use a Folder Reference, all my files are dumped into the Resource folder of the application bundle, not in the nice structure I have in my project.
Should I care at all? Should I just use the fake folders and let everything go everywhere and not care? My application bundle will be a mess, the filesystem will be a mess, but it will all work... I would hope?
Edit:
My biggest reason for wanting an organized filesystem is that the resource files (images, sounds, other datafiles, etc.) are not edited in Xcode. I have to access them in 3rd party apps via the filesystem. If its a mess things are harder to find and maintain in the other 3rd party applications.
Also what happens if I want a structure like the following:
Images/Backgrounds/Name.png
Images/Icons/Name.png
Images/Titles/Name.png
Should I use long filenames rather than folders to organize?
Images_Backgrounds_Name.png
Images_Icons_Name.png
Images_Titles_Name.png
I also wish Xcode automatically kept itself and the file system in sync.
So much so, that I spent an hour doing so manually for a project called acani-iphone on GitHub. Basically, I just moved some of the files around using Finder, creating new folders as I pleased. Then, I switched back to Xcode and saw that the files I just moved were now red (because Xcode was thinking they're where I moved them from and so couldn't find them).
UPDATE: I just figured out that I could've then just clicked on the red group or file, pressed CMD+i (Get Info from the context menu, which you can open by right-clicking on the red file or group), and under the General tab, clicked Choose, then found where I moved the file to in the filesystem. But, I didn't do that, here's what I did instead, which also works:
Then, I just highlighted all the red files in Xcode and pressed command + delete to delete the broken (red) references. Then, I right-clicked on the Group I wanted to add the files to (usually the same group), and clicked Add > Existing Files.... Then, I found the same files in the new spot on the file system. I kept "Copy items into destination group's folder (if needed)" unchecked, I checked the radio button "Recursively create groups for any added folders," and I checked add to target acani if the files I was adding were being used to build the acani iPhone app.
I did the above with like a directory of files at a time. A few times I was more aggressive, adding multiple directories at a time, since I almost always selected the radio button "Recursively create groups for any added folders."
I found out that the files acani_Prefix.pch and acani-Info.plist had to stay in the root file system dir (although there may be settings you can set to allow these files to be elsewhere, like I think you can add a line to acani-Info.plist so that you can move/rename acani_Prefix.pch, but I'm fine with them in the root dir on the file system.
That was annoying to do, and perhaps not even worth the trouble, perhaps procrastination, but going forward, before adding existing files to Xcode, I'll first make sure they're in the place I want them to be on the file system.
OK, so here is how it works:
Xcode doesn't know about any files until you tell it about them. That is, even if you add a file manually in the finder (usually a bad idea) to a folder that contains files in an Xcode project, it doesn't know about them until you "add existing file to project".
The best practice (imo) for adding an existing file (or group of files) to a project (say, some code you just downloaded) is to choose "add existing files" and then "copy items to destination group's folder (if needed)" in the next dialog, if you want your project to have a copy of the files in question, rather than merely a reference to them (there are advantages and disadvantages of both).
Don't worry too much about the naming of folders in Xcode, or where you put things, but try to keep to a standard that makes sense in your environment. For example, I always put the classes I write in "Classes", and have separate folders for any library code i've downloaded for use in the project. I always put images/icons/audio etc in to "Resources".
In short, if you like what's in the project folder to be approximately the same as what's in your project, always add existing files by choosing the "copy items to destination group's folder"
The flexibility in XCode is intentional. It's up to you to decide how you like to organise things.
Should I care at all? Should I just use the fake folders and let
everything go everywhere and not care? My application bundle will be a
mess, the filesystem will be a mess, but it will all work... I would
hope?
IMO no... :) basically. The whole point is that XCode has been designed to give you the best experience of programming. If Apple wanted you to physically organise all your files and folders within the actual filesystem then they would have made it that way.
I don't really understand why you would want to organise all the files and folders in this way anyway? It makes no difference to the running of the application and the "fake" folders (groups) in XCode adequately provide the necessary visual aid for yourself (and others) to navigate through your classes and other resources. Organising it correctly in your filesystem (as you have found) surely just makes things more difficult?
Use Synx.
It rearranges your files on disk to match your Xcode groups. I try to run it before committing any code that changes the Xcode groups, and it keeps the project nice and tidy.
It would be great if Xcode could keep itself and the file system in sync. Unfortunately it doesn't. One reason for wanting it to is so the hierarchy in your SCCS matches the one in Xcode.
I fall back to keeping things organized in Xcode, and leaving the file system separated into not much more than "Classes" and "Resources".
This changed with Xcode 9. From the release notes:
Groups in the Project Navigator are now more closely associated with
directories in the file system. (28612132)
Dragging files between groups in the Project Navigator moves the files in the filesystem and updates any associated SCM working copies.
When a group is connected to folder in the filesystem, creating, renaming, and deleting groups updates the corresponding files and
folders in the the filesystem.
To remove a connection between a group and a folder in the filesystem, select the group, and then open the File inspector and
click on the on the Clear path button (X).
To add or update an association from a file or a folder in the filesystem to a file or a group in the project, select the file or
group, open the File inspector, and drag the corresponding file or
folder onto the Location section in the File inspector.
The new behaviour is available from the 'New Group with Folder' command (which may appear as just 'New Group'), while the old behaviour is available from the 'New Group without Folder' command (which may also appear as just 'New Group'!) The dominant usage amongst any existing groups in the target folder seems to determine which command gets labelled 'New Group'. It's more than a little confusing, but if you are in the habit of choosing one or the other, the idea seems to be that you can just stick with the default 'New Group' command. (See rob mayoff's far more thorough explanation.)
What I do is create a group to represent each folder and then, before adding files to it, in the right panel, first tab, immediately below "Path", there is an icon that allows you to choose the folder. In that folder dialog, I create a folder that matches the group and choose it.
In xcode3, this resulted in new and add files dialogs starting in this path. That made it worth the effort. Xcode4, however, does not respect this setting. Therefore, its questionable whether there is any real value in it. I also wish XCOde would support better file system organization.
Considering that file names must be unique within a project, regardless of groups and folders, there is justification for accepting the flat folder structure default and using groups for IDE convenience. Its difficult to come from other platforms where this is frowned upon.
i feel you and personally cannot NOT care about the actual structure and just rely on workspaces.
what would be really great is a tool that will go over the workspace structure and re-organize the file system accordingly, taking care of any re-naming of folders etc. this would be a classic solution and IMHO should be implemented as an option as we re-organize our project as we move about it.
some issues could be source control though xcode4 works with both git and SVN.