Localized project with several targets with localized app names

Question

I have recently merged together 5 of my stand-alone projects into one project to have a common code base. So now I have one project with 5 targets instead.

Each target has the same fileset, except for some files which differ for each target (such as Default.png, and icons files amongst others). My application is translated to 7 languages with English as default. The other languages are: Swedish, Dutch, German, French, Polish and Spanish.
Now I would also like to translate the name of the application depending the language used. For instance, for my Swedish aviation app, the app should be called "Flyget ARN" in Swedish, but for English it should be called "Aviation ARN". All this is not a problem since this is done in the InfoPlist.string, however combining this with the localization of the app Is a problem.

I recently wrote this question: Several localizations yet still showing English only and found out that I cannot combine several .strings files. (see the answer I wrote).

So my question is the following:
How can I have a localized app from a project containing several targets and also localize my applications name without having a DRY-violation (Duplicate code).

Update
This is still an issue, the answers given do not solve my problem.

Festatus

Is there any reason why you don't simply use a script build phase in your Xcode project to programmatically create your InfoPlist.strings from a shared file containing all of your shared localizations and target-specific file containing the string (application name) that needs to be different? – Twice

Answer 1

I cracked this nut in an XCode project which, I believe, tackles the same issue as you have, so hopefully this will help you. The solution contains two targets built from the same codebase (with a different app name) and which are fully localized, including the app's names. (It builds my freemium app called Growth (French: Croissance, Spanish: Crecer) and the paid version called Growth+ (French: Croissance+, Spanish: Crecer+).

I also stumbled on the InfoPlist.string files (which contain only the app's name). I got around the issue through the use of subfolders in my solution, and changing the targets to include the localized set of InfoPlist.strings from the relevant subfolder. Specifically, I have this structure:

    Root
    +-- en.lproj
    ¦   +-- Localizable.strings
    ¦   +-- SomeXib.xib
    +-- es.lproj
    ¦   +-- Localizable.strings
    ¦   +-- SomeXib.xib
    +-- fr.lproj
    ¦   +-- Localizable.strings
    ¦   +-- SomeXib.xib
    +-- OnlyInAppA
    ¦   +-- en.lproj
    ¦   ¦   +-- InfoPlist.strings
    ¦   +-- es.lproj
    ¦   ¦   +-- InfoPlist.strings
    ¦   +-- fr.lproj
    ¦       +-- InfoPlist.strings
    +-- OnlyInAppB
    ¦   +-- en.lproj
    ¦   ¦   +-- InfoPlist.strings
    ¦   +-- es.lproj
    ¦   ¦   +-- InfoPlist.strings
    ¦   +-- fr.lproj
    ¦       +-- InfoPlist.strings
    +-- AppA.plist
    +-- AppB.plist

And the only difference among my targets (other than different preprocessor symbols and different .plist file) is that AppA's build settings includes the InfoPlist.strings files under OnlyInAppA, whereas AppB's build settings includes the InfoPlist.strings files under OnlyInAppB.

The naming convention I used (OnlyInAppA/OnlyInAppB folders, AppB/AppB plist files) is obvious enough to make this a satisfactory approach, in my personal opinion.

Edit:

Please see these two XCode 4 screenshots to see where exactly to find the settings which are changed in the targets.

1. In the target build settings, a different plist file is specified (note: XCode automatically does this for you when you add a new target)

2. In the target build phases, in section Copy Bundle Resources, pick the version of InfoPlist.strings from the relevant OnlyInAppX subfolder (notice the gray text next to InfoPlist.strings on this screenshot--this will show a different location for the other target). You can achieve this by using the +/- buttons and replace the file with the intended one.

Bower

I believe I tried that but it didn't work. Maybe I did something wrong... I am going to try it again this weekend. – Festatus

It seems to be working for me now... using your answer. thnx. – Festatus

Answer 2

If this problem still persist: I have found a solution on how to add multiple InfoPlist.string localized for each target in your project. Please follow these steps:

1. I assume you already have multiple targets.
2. Go to the project folder in Finder.

3. Create a folder specific for each target:

4. Create an InfoPlist.strings file in each folder:

5. Add folders to targets specifying proper (and only!) target for each folder in your project:

6. Remove target dependency for original InfoPlist.strings file for each new target.

7. Localize new InfoPlist.strings files:

8. Build targets and check by changing language settings:

Dyak

The approach seems to be the same as described in accepted answer but has nice step-by-step instruction. Thanks! – Indium

Answer 3

Just keep all the InfoPlist.strings files, under separate paths. Each would only be a member of one target.

Or did I not understand the question?

Tobietobin

Well, that is what I did. Had the InfoPlist.strings file in its own group and in its own folder. The localizable.string file was shared amongst all targets. – Festatus

Is each InfoPlist.strings a member of the appropriate target? When you examine the built target, are the various InfoPlist.strings files in the appropriate localization? – Tobietobin

Does the plutil command verify that the .strings files are valid? – Tobietobin

Haven't checked, but since the app localized the app names and the app does switch the default language if I change it in the Info.plist I would suspect plutil not to complain. – Festatus

Then I must have misunderstood the question. I thought the problem was that your app name was not successfully localizing. What is the problem? – Tobietobin

You understood correctly. The app is not sucessfully localizing according to the system settings on the device. However, I can force the localization by setting the default language to one of the supported languages, but then the whole app will be in that language... again regardless of the system settings. Only the app name settings are changed according to the system settings. – Festatus

Answer 4

I have a similar setup where my the same software supports multiple domains, each domain accesses the exact same paths for various modules (e.g. blog, forums). In order to retain individuality per domain especially when the database service becomes unavailable I retain critical information in files, basically meta information. For localization I would keep a variable retaining each site/project's default language. You could determine the files containing the information to have their own domain or store all the projects in the same file, either way you would want to use that for your ultimate fallback or if you simply lack further public options to any/everyone with lower permissions than you until you implement such options (users being able to override the language option).

Allister

Thank you for you answer... but again.. I don't believe this solves my problem. I neither have to set the language in the app nor should I save all the content in the same file, since that would be a DRY violation. However, I do not really understand what you mean by determine the files containing the information to have their own domain? – Festatus

example1.com.php, example2.net.php, etc for domain named meta files if you keep the information in separate files. The only thing I have ultimately suggested is the master fallback value if something goes wrong to be saved in the meta file. – Allister

ok... I think we are misunderstanding each other. This is not a web project. – Festatus

Answer 5

i have been doing exactly this for my apps.

as i change the default language for the phone, it properly picks up the names in each of my infoPlist.strings files.

but i did this from scratch. i don't know if you will have to back up to get the behavior you want. perhaps save aside your various infoPlist.strings files from any localization folders, then perform the following steps, and then re-insert your contents from your current infoPList.strings files into your newly created files from the following steps.

i am using Xcode 4.3 . the steps:

1) set up the strings you want in for your default language in info-plist.strings. you should end up with a single file:

2) now, open up the File Inspector

3) in the inspector on the far right, you can now click the + sign at the bottom of the navigator:

4) once you've chosen your language(s) of interest, they'll show up in your project navigator on the left as follows:

you also can do this for Localizable.strings and other files (such as the index.html in the following example photo):

Satyriasis

Thank you for your reply. I do get the use of the different InfoPlist.strings file, however when I do it "forgets" about the Localizable.strings file. The InfoStrings.plist file exists once for each target (out of 5) but is a different file. The same goes for the localizable.strings but that is the same file for each target. Did you get that working? – Festatus

my experience is that localizable.strings works the same for me. in other words, it's also a file under "supporting files" that has an arrow with a number of localizable strings files. – Satyriasis

True, but combine the two and (at least I) get problems. It will use only one of the two and it will prefer the InfoString... or atleast that how it seems to me. – Festatus

what i'm trying to say is i'm currently working on a project in which both infoPlist.strings and Localizable.strings work in this way. – Satyriasis

Yes, but does the project have several targets for different apps? – Festatus

why do you need multiple targets? by creating the Info.plist with CFBundleDisplayName in it, it will create the app in such a way that when you change the language setting on the phone, the app name will be one thing for english, another for swedish, another for russian, etc. this is a single app. if they behave differently internally based on language, then multiple targets would be necessary … but in that case, i would think you'd want to have a singular Russian-Info.plist that is only in the russian target, a swedish-Info.plist for the swedish target, etc. – Satyriasis

As I mentioned before, the app has a shared code base for the build of several apps. If all the app would be the same, I would agree with you... however that would be pointless. Each app covers a different airport, e.g. JFK, ARN, BMA, MMX, ect. These airports have different maps and data.. thats why. Regardless of my reasons, these are my requirements and I am not going to compromise them "just because". – Festatus

you should still be able to use the single file, and in the target membership portion of the file info, check the target per item. i created a separate target for one of my apps, and in the original target unchecked the target membership for the russian Info-PList.strings file (and they don't have to be the same name), and then in the second target, made the russian info-Plist.strings the only one that is a member of that target. you should be able to use the target membership tab for the localizable.strings as well (or any other localizable resource). – Satyriasis

Answer 6

Try see a iTunesConnect_DeveloperGuide

and see a "Adding a New Localization"

Here you can write a Localized app name for each language

Roulade

Please do explain how iTunes Connect localizations have the slightest to do with getting two different .strings files working within the app? – Festatus

Here a another solution, which not using a two different .strings – Roulade

Its not a solution, iTunes connect is the portal used to publish application to- and maintain application on the appstore, it has completely nothing to do with the application itself or its content... a part from verifying the application upon upload.. of couse. – Festatus