In the following doc:
http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPInternational/Articles/LanguageDesignations.html
it's mentioned that
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.
I don't quite understand this. Does it mean that the name of .lproj directory cannot contain any region code?
But at least I know that iOS accepts zh_TW.lproj, zh_CN.lproj. How about en_GB.lproj and en-GB_GB.lproj? Or it only knows en.lproj?
This simply means that iOS would support only two digit language codes (e.g. en.lproj, es.lproj etc.). Whereas Mac OS X will support the format Language_Region (e.g. en_GB, en_US etc.).
I think that information is outdated. They must not have updated the Mac development docs when the iOS changes were made.
When you're creating your Localizable.strings or Project.plist file, you will create one per language or language-dialect. Just create the ones you need.
If you're using Xcode 4, be sure to show the "Utilities" (View-->Utilities-->Show Utilities) when the Localizable.strings or Project.plist file is selected. It will have a Localization section that makes adding these easy.
UPDATE: As of iOS 8 you can now use any language or region in iOS.
Apophenia is correct. Although iOS has 30 languages that it will recognize as .lproj folders, it won't accept any regional codes, so telling it fr-CA won't get you French Canadian, but rather will simply use your French or English strings. The only exception to this rule is Chinese, which should be zh-Hans for Simplified Chinese and zh-Hant for Traditional Chinese.
You should always use the two-letter code for the language (en.lproj, fr.lproj, es.lproj, de.lproj, and so on).
There is a complete (and updated) list of the current supported languages and language codes for both iOS and iTunes here:
http://www.ibabbleon.com/iOS-Language-Codes-ISO-639.html
Note that the iTunes App Store has a different list of supported languages, which makes the chart linked to above very handy!
Related
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Localization of icon and default screen in iPhone
As my question already says, I want to have 2 different application icons.
If for example english is the native language on the device I want it not only to have a different app name but also a different icon.
So is that actually possible?
According to apple documentation, you can do it.
An iOS application should be internationalized and have a
language.lproj folder for each language it supports. In addition to
providing localized versions of your application’s custom resources,
you can also localize your application icons and launch images by
placing files with the same name in your language-specific project
directories. Even if you provide localized versions, however, you
should always include a default version of these files at the
top-level of your application bundle. The default version is used in
situations where a specific localization is not available. For more
information about localized resources, see “Localized Resources in
Bundles.”
This info was extracted from here:
https://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html
You can do it, if you want too... just click on your icon file (consider Icon.png) now simply click on the ‘+’ in that ‘Localization’ pane on the right.
Add languanges that you want to provide support. Consider you have English And Spanish language support, add those two languages. It will create ‘en.lproj’ and ‘es.lproj’.
Now just see those directory, you can see both directories have their own copy of Icon.png. So just replace that image and make sure new file has same name as the replaced one.
Now Run it. And check by changing language in Setting>International>Language
Basic thing is based on language it will check if localization is available for that particular resource, if it exists it will be used.
No, you can't have localized app icons
Sorry, I was very wrong, it is possible. I was quite sure but my information obviously was very outdated :).
where in an XCode project does it set "InfoPlist.strings" as the filename to use for locationalization?
Just trying to understand how XCode pulls things together here. For example to set the app name specifically I can change this in "AppName_plist-Info.plist", however if I go localization it seems it then has to be set via the "InfoPlist.strings" files.
I can see in XCode where it specifies the "AppName_plist-Info.plist" file name, in the Target/BuildSettings/Packaging information area, but I don't see mention of "InfoPlist.strings", so how does Xcode/IOS know to override what is in "AppName_plist-Info.plist" based on what's in "InfoPlist.strings"?
Xcode doesn't really override the name, it creates localizations in your apps bundle. iOS will look for the name of the app in de localization folder to which the language of the system is set.
These files have pre-determent names, thus you can not set them.
All the localized files will be for example in bundle.app\en.lproj for english or bundle.app\nl.lprojfor dutch.
I'd like to localize my application with the following pattern:
Localize all strings (say English, French and German (don't mention the war!))
Localize some images in some languages (say just English and French)
I can localize the strings without issue. My problem is that when I add the German strings, the other resources that are localized into English and French attempt to find a German version. I don't want to provide a German version (trying to avoid too many superfluous images as they bulk up the size of the app).
Can anyone suggest a way of telling the application not to bother looking for a German version of the images.
My problem isn't adding languages, it's ignoring them under certain conditions. I don't want to include a German version of "a.png", but I do want to include a French version of "a.png". When the user's language is set to German, I'd like it to select the default language which is English.
Having had the same issue I want to follow up on this as the suggested resolution did not work exactly as quoted.
My setup is 3 localized languages, de, en, fr. The .lproj folders Xcode created are thus named
en.lproj
de.lproj
fr.lproj
I have a graphical button with "start" on it that needs localization from english to french but not to german (as it is the same word).
My "Localization native development region" was set to "English", which must have been the default (maybe a while back, the project has been a wip for quite a while).
The button did not show up on german devices. Switching to "EN" or any of the suggestions from Xcode ("United Kingdom", "United States of America") did not resolve the issue.
The solution was simpel. The string in the "Localization native development region" needs to exactly match the (native language).lproj string. So setting it to "en" it finally resolved the issue.
Hope this helps whoever stumbles upon this question.
iOS (and Mac OS) should always fall back to the app's default language. If you don't include the image.png in the de.lproj resources folder, the app should use the en.lproj/image.png file in its place.
Look for key: "Localization native development region" in the Target > Info pane of Xcode. Make sure that says EN.
I don't have that much experience but as far as I'm concerned, your program should just look for the german image, find nothing and then try to load the english image instead.
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
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.
I don't understand the problem.
You can perfectly have two different NIBs, for France and Canada (french), as it's supported by Xcode.
Simply add new localization for your file(s):
Then use a view controller to load the NIB, with the initWithNibName method. The correct one will be used, depending on the device language settings.
In my project, I need to support the Korean language. How is it possible - can anyone explain briefly with example, whether it is possible or not?
It's certainly possible.
You just tell Xcode to add a Korean localization to any of your application's localizable resources that need to change for that language. (Localizable resources include strings files, xib files, and potentially any images containing text.) Xcode will create a copy of your existing English resource, which you can modify and replace with a Korean-language equivalent.
Then when your application is run on a device with Korean set as its preferred language, iOS will automatically use the Korean resources intead of the English ones to present the application's user interface. If you have used good localization code practices (such as using NSLocalizedString to reference strings you present in the user interface) you shouldn't have to change any of your code to support different languages.
Check this guide on how to localize your apps for iPhone: http://www.icanlocalize.com/site/tutorials/iphone-applications-localization-guide/