A device can be set by the user to prefer a certain language as its primary language. You might like the text in your app’s interface to respond to this situation by appearing in that language. This is achieved by localizing the app for that language.
Localization works through localization folders in your project and in the built app bundle. Every resource in one of these localization folders has a counterpart in the other localization folders. Then, when your app goes to load such a resource, it automatically loads the one appropriate to the user’s preferred language. For example, if there’s a copy of MainWindow.nib in the English localization folder and a copy of MainWindow.nib in the French localization folder, the latter will be loaded as the app launches on a device on which French is the preferred language. So the two copies of MainWindow.nib should be identical except that all the text the user will see in the interface should be in French in the French version.
This approach solves the problem for resources that are physically loaded, such as nib files and images and sound files, but it doesn’t deal with strings generated from within your code, such as the text of an alert message. Surely you don’t want your code to consist of a bunch of massive
if clauses every time there’s text to display. The problem is solved through the use of a strings file. A strings file is a specially formatted text file whose file extension is .strings; by default the name of the file ...