Home/ Questions/Q 6343209
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T20:23:36+00:00

We might have a need for loading a nib using the results of [NSBundle

  • 0

We might have a need for loading a nib using the results of 

[NSBundle -pathForResource:ofType:inDirectory:forLocalization:]

I thought this would be possible, but all the methods I can find only want the name not leading path info.

We are exploring a way to provide both fr-Fr and fr-CA through one code base. Our client wants a fr-CA translation and we’re afraid we might have another customer that wants a fr-Fr translation. I was thinking we could path to correct nib based on the selected language.

Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The path lookup takes into account the user’s locale preferences. If you provide the proper localization directories (.lproj), the right nib should be loaded by the system.

    Per Apple’s documentation:

    The method first looks for a matching resource file in the non-localized resource directory of the specified bundle. (In Mac OS X, this directory is typically called Resources but in iOS, it is the main bundle directory.) If a matching resource file is not found, it then looks in the top level of any available language-specific “.lproj” directories. (The search order for the language-specific directories corresponds to the user’s preferences.) It does not recurse through other subdirectories at any of these locations. For more details see Internationalization Programming Topics.

    Unfortunately, Apple’s documentation is self-contradictory and incomplete. If you look at “Internationalization and Programming Topics”, section “Language and Locale Designations”, you will find under “Language and Locale IDs” this gem:

    Important: In iOS, the bundle interfaces do not take dialect or script information into account when looking for localized resources; only the language designator code is considered. Therefore if your project includes language-specific project directories with both a language and region designator, those directories are ignored. The bundle interfaces in Mac OS X do support region designators in language-specific project directories.

    This is not entirely true. If you look at Apple’s own applications, you will see that iOS does support some region designations, but only the ones Apple cares about. See for example the list of .lproj directories in a recent Mobile Safari:

    $ ls -d *.lproj
Dutch.lproj/    el.lproj/       pt_PT.lproj/
English.lproj/  en_GB.lproj/    ro.lproj/
French.lproj/   fi.lproj/       ru.lproj/
German.lproj/   he.lproj/       sk.lproj/
Italian.lproj/  hr.lproj/       sv.lproj/
Japanese.lproj/ hu.lproj/       th.lproj/
Spanish.lproj/  id.lproj/       tr.lproj/
ar.lproj/       ko.lproj/       uk.lproj/
ca.lproj/       no.lproj/       vi.lproj/
cs.lproj/       pl.lproj/       zh_CN.lproj/
da.lproj/       pt.lproj/       zh_TW.lproj/

    Notice that two Chinese regions, a British English region, and a Portugal Portuguese region are supported. But none of these solves the problem of fr_CA versus fr_FR.

    For that, let’s look at MobileSafari again. It must implement its own smart lookup, because it has plenty of more finely distinguished StaticBookmarks-xx_YY.plist files.

    So, that’s the solution: Use the locale functions that are still available, and do your own lookup accordingly.

    • 0