How To Localize an iPhone App - cocoa-touch

I am trying to find a step by step tutorial on how to localize an iphone App. I have english and I'm looking to add french. The documentation is available but it hardly comes close to giving you clear instructions on how to implement it from start to finish.

Below is the step by step walkthrough that I was looking for. It is found Here
Hope it helps all of you as it did m.
This is a guest post by Sean Berry, a developer of math apps for iPhone, iPad, and iPod Touch.
Me Gusta Localization!
Although the English-speaking App Store market is the largest, there are still plenty of other iPhone users in the world and you can greatly increase their user experience by supporting their native language.
The good news is Apple has made it very easy to make your apps work with multiple languages through some API calls and built-in Xcode support. The process of doing this is called localization, and that’s what I’ll be showing you how to do!
In this iPhone app tutorial, you will be localizing a sample app I prepared called iLikeIt which was inspired by the rage comics in Ray’s post about in-app purchases. The app is very simple – it displays some ideal sales data, and when you tap ‘You like?’ a face appears, scales up, and fades away.
But right now it’s English only – so vamos a traducir!
This iPhone app tutorial will be using Xcode 4.6.1, so if you haven’t upgraded already, why not use this as an excuse to do so?
Getting Started
The first step is to download the iLikeIt starter project that we’ll be localizing in this iPhone app tutorial.
Build and Run the app, and you should see the following appear after you tap ‘You like?’:
We have 3 things to localize here:
Text: sales data
UI Element: ‘You like?’ button
and finally the image (it has text!)
Separating text from code
Like most projects, this project has some hardcoded strings in the code. We need to pull all of these hardcoded strings into a separate file so we can localize them.
The way you do this in Xcode is create a “.strings” file to contain all of the strings your projects needs. Then you’ll replace the hardcoded strings with a function call to look up the appropriate string from the “.strings” file based on the current language.
Let’s try this out. Go to File\New\New File. Choose iOS\Resource\Strings File, and click Next, as shown in the screenshot below. Name the new file Localizable.strings, and click Save.
Note that Localizable.strings is the default filename iOS looks for when dealing with localized text. If you don’t use this, you’ll have to specify the name of our .strings file every time.
The format for the strings file is:
"KEY" = "CONTENT";
So for our ‘Yesterday you sold %# apps’ and ‘You like?’ text add in:
"Yesterday you sold %# apps" = "Yesterday you sold %# apps";
"You like?" = "You like?";
Now switch to ViewController.m, and find the viewDidLoad method. Right now it sets the text as:
self.numAppsLabel.text = [NSString stringWithFormat:#"Yesterday you sold %# apps", #(1000000)];
[self.likeButton setTitle:#"You like?" forState:UIControlStateNormal];
We want it to instead read from our .strings file. To do that, change the current line to use a macro called NSLocalizedString as shown below:
self.numAppsLabel.text = [NSString stringWithFormat:NSLocalizedString(#"Yesterday you sold %# apps", nil), #(1000000)];
[self.likeButton setTitle:NSLocalizedString(#"You like?", nil) forState:UIControlStateNormal];
If you’re curious what the NSLocalizedString macro does, control-click on NSLocalizedString and choose Jump to Definition. You’ll find that it’s defined as follows:
#define NSLocalizedString(key, comment) \
[[NSBundle mainBundle] localizedStringForKey:(key) value:#"" table:nil]
So basically, it’s using the localizedStringForKey method to look up the string for the given key, in the current language. It passes nil for the table name, so it uses the default strings filename (Localizable.strings). For full details, check out Apple’s NSBundle Class Reference.
One other thing to note. The macro takes a comment as a parameter, but seems to do nothing with it! This is because instead of manually typing in each key/value pair into Localizable.strings like we’ve been doing, you can use a tool that comes with the iPhone SDK called genstrings to do this automatically (which can be quite convenient for large projects).
If you use this method, you can put a comment for each string that will appear next to the default strings as an aid for the translator. For example, you could add a comment indicating the context where the string is used.
Enough background info – let’s try it out! Build and run your project, and it should say the same text on the main screen just as before. But where’s the Spanish? Now that we’re set up it’s a cinch.
Adding a Spanish Localization
To add support for another language, click on the blue iLikeIt project folder on the left pane, select the Project in the next pane (NOT the Target), and under the Info tab you’ll see a section for Localizations. Click the + and choose Spanish (es).
You’ll see another screen asking you which files you want to localize, keep them all selected and click Finish. It’s ok that you don’t see Localizable.strings yet! We’ll get to it soon.
At this point, Xcode has set up some directories containing a separate version of InfoPlist.strings and MainStoryboard.storyboard for each language you selected, behind the scenes. To see this for yourself, open your project folder in Finder, and you’ll see the following:
See en.lproj and es.lproj? They contain our language-specific versions of files.
‘en’ is the localization code for English, and ‘es’ is the localization code for Spanish. If you’re curious, here’s the full list of language codes.
When iOS wants to get the English version of a file, it will look in en.lproj, but when it wants the Spanish version of a file it will look in es.lproj.
It’s that simple! Put your resources in the appropriate folder and iOS will do the rest.
But wait, what about Localizable.strings? To let Xcode know you want it localized, select it on the left pane, and open the File Inspector in the right pane. There you will see a button labeled Localize, click it, choose English (because it’s currently in English), and finally click Localize.
Now on that right File Inspector panel it shows which languages this file belongs to, add it to the Spanish localization by checking that box to the left of Spanish.
Go back to the left panel and click on the arrow next to Localizable.strings so it shows the sub-elements. You’ll see now we’re working with two versions of this file:
To change the text for Spanish, select Localizable.strings (Spanish) and change the text to read:
"Yesterday you sold %# apps" = "Ayer le vendió %# aplicaciones";
"You like?" = "~Es bueno?~";
Your app is worldly now! Let’s make sure it worked…
To make your simulator show Spanish, go into Settings.app and choose General -> International -> Language -> Espanol.
Delete the app and select Project\Clean to get a fresh build and install. When you build and run you should see:
Locale versus Language
Let’s make that number look better by adding some formatting. Replace this code:
self.numAppsLabel.text = [NSString stringWithFormat:NSLocalizedString(#"Yesterday you sold %# apps", nil), #(1000000)];
With this:
NSNumberFormatter *numberFormatter = [[NSNumberFormatter alloc] init];
[numberFormatter setNumberStyle:NSNumberFormatterDecimalStyle];
NSString *numberString = [numberFormatter stringFromNumber:#(1000000)];
self.numAppsLabel.text = [NSString stringWithFormat:NSLocalizedString(#"Yesterday you sold %# apps", nil), numberString];
Build and Run and the number will be a lot easier to read.
But here’s the thing, in Spain they don’t format their numbers like that. They write “1.000.000″ instead of “1,000,000″, but if you change the iOS simulator’s language to Espanol, you’ll still see commas used to separate the zeroes. The reason being is that number formatting is based on the region/locale, not the language. To see how someone in Spain will see that number, go into Settings -> General -> International and change Region Format to Spanish -> Spain.
When you open up the app again this is what you should see:
We got that functionality for free, just for using Apple’s NSNumberFormatter class! It pays to do things Apple’s way, don’t fight it.
Images
Since we have text in our image we need to localize it. Having some English in an otherwise Spanish app would look amateur.
Select ilike.png and add a localization for Spanish (you’re an old pro at this now!) (if you forgot, select it on the left panel, and in the File Inspector panel on the right, click the Localize button. Then after allowing Xcode to place the default copy into en.lproj, check the Spanish box on the right panel.)
Check out the project folder. ilike.png has been added to the English folder (en.lproj) and then copied to the Spanish folder (es.lproj). To make a different image show up for the Spanish version, we simply overwrite the image in the Spanish folder.
I’ve also included it in the starting project, saved as megusta.png.
Rename it to ilike.png and move it into the Spanish folder (es.lproj), overwriting the copied English version.
Clean and rebuild and you should be done! Switch your simulator to Espanol to see…
Congrats! That’s the bulk of localization.

Related

Is there any way to create and display music notation inside of a codenameone app?

Is there any way to create and display music notation inside of a codenameone app?
For Java generally there are some libraries like for example JFugue that let you write music inside a program. Maybe also display it, i didn't try that out.
There is lilypond, which would work in a desktop environment if you were able to run it to make the pdf after generating the file itself.
I wrote a small app in Android Studio and had to write my own music notation logic and drew it with the help of png files on a Canvas. That worked okay for small musical examples of a clef and around 2-7 notes.
Now i want to do something similar in Codenameone and display at least a clef and some notes inside the app (maybe as an image) - they have to be generated with some random element while the program runs.
It would also be great to be able to write and show more than a few notes, displaying it somehow and maybe also with the ability to have it as a pdf file later.
Is it possible to use something that already exists?
Thanks a lot!

How to sync localized storyboards' strings after modifying storyboard in Xcode 5

I'm just starting to look at IOS Apps' localization in XCode 5 and I've tried to add an Italian Localization:
Xcode 5 automatically generates the Main.strings file with a single entry, for the only label I've put within the Main.storyboard file:
/* Class = "IBUILabel"; text = "Label"; ObjectID = "PeT-4z-NSf"; */
"PeT-4z-NSf.text" = "Etichetta";
If I later modify the Main.storyboard file adding a new button to the view, then how should I tell Xcode 5, if possible, to add missing localization strings to the Main.strings file? Should I add a new entry by hand by looking at the Object ID field in Interface Builder (it works, but I don't know if this is how it is meant to update storyboards' localization)? Can I run something like genstrings on the Main.storyboard file to extract all the labels' text and add the new ones to the localized Main.strings files?
Check out ReMafoX, it's a Mac app that perfectly solves your problem. It can be easily installed and integrated within your project, watch this video for a detailed walkthrough.
Alternatively, if you prefer an open-source CLI tool without a GUI, you can also use BartyCrouch.
Install BartyCrouch via Homebrew:
brew install bartycrouch
Alternatively, install it via Mint:
mint install Flinesoft/BartyCrouch
Incrementally update your Storyboards/XIBs Strings files:
$ bartycrouch update
This will do exactly what you were looking for.
In order to keep your Storyboards/XIBs Strings files updated over time I highly recommend adding a build script (instructions on how to add a build script here):
if which bartycrouch > /dev/null; then
bartycrouch update -x
bartycrouch lint -x
else
echo "warning: BartyCrouch not installed, download it from https://github.com/Flinesoft/BartyCrouch"
fi
In addition to incrementally updating your Storyboards/XIBs Strings files this will also make sure your Localizable.strings files stay updated with newly added keys in code using NSLocalizedString and show warnings for duplicate keys or empty values.
Make sure to checkout BartyCrouch on GitHub for additional information.
The file that Xcode does not update automatically (at least 5.x version didn't) is the app's Localizable Strings. You can build a fresh file from Main.storyboard as follows:
In the project Navigator (the leftmost pane) click on the Main.storyboard file. In the Utilities pane (the rightmost pane) click on Show the File inspector icon. It is the leftmost icon in blue in the image below:
.
On the right pane that will appear, one of the sections will be Localization:
Uncheck the English (Localizable Strings) row and in the window that will pop-up check the Delete localized resource files from disk and click the Remove button (you do not have to check delete, in which case Xcode will ask for a permission to override it when you build it next).
Then check English (Localizable Strings) again to build it from scratch.
Using Xcode 6 the following worked for me:
I changed the localization for a language from "Localizable Strings" to "Interface Builder ..." like suggested at the SO question posted by h.orim. However the setting did not change, it still was set to "Localizable Strings". The next step now is to do that again, so Xcode will find the Storyboard it just created and show a prompt asking if it should be used or replaced. Now click on "Use file" instead of "Replace", otherwise the same will happen again.
Now you should have a localized Storyboard in the desired language. After you now switch back to "Localizable Strings" you will have a file containing all current strings used in the storyboard with your previous translations still in place.
Another way is to do it manually by selecting on the storyboard the field to translate. Go to the "Identity Inspector" and copy the Object ID (something like HP8-op-SmX).
After that, open the storyboard langage file (Main.strings, most cases) and past the Object ID. Depending your needs, you just have to add .text or .placeholder.
"HP8-op-SmX.placeholder" = "My translated placeholder text";
"HP9-op-VvD.text" = "My translated text";
Save, clean & build. It's a little bit painful but can save a lot of time if you only need to translate few things.
You can use a script called UpdatStoryboardStrings for this!Get it here: https://github.com/AppliedIS/iOSL10n
Intructions for use: http://blog.appliedis.com/2013/05/22/localization-of-an-xcode-ios-app-part-2/
With Xcode 6+, ideally developers should not have to manually manage strings files. Use XLIFF export to automatically gather development language strings to send to translators, and then use XLIFF import to update the strings files with translations.
https://developer.apple.com/library/ios/documentation/MacOSX/Conceptual/BPInternational/LocalizingYourApp/LocalizingYourApp.html#//apple_ref/doc/uid/10000171i-CH5-SW9
Another option is to use ibtool --export-strings-file directly.
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ibtool.1.html
There are two options:
Option 1
Xcode can "reload" the file by converting the file to either an [Interface Builder Cocoa Touch Storyboard] file type or a [Localizable Strings] file type.
Select your base storyboard file from the Project Navigator
Find the Localization section in the File Inspector
If your file is currently a [Localizable Strings], change it to [Interface Builder Cocoa Touch Storyboard] or vice-versa.
Xcode should have converted your storyboard to the current version, while preserving your old localization efforts. Here you can change the file back to the original file type if you would like.
Option 2
Use ibtool to extract the strings in your storyboard.
Open the Terminal application
Locate your Base.lproj directory
Use this line to extract the strings:
ibtool MainStoryboard.storyboard --generate-strings-file file_name.strings
After ibtool extracts the strings to file_name.strings, you can copy and paste it to your original .strings file
Tested with Xcode 11, you can simply deselect the language.
Do not delete the file on disk.
And then choose to use the existing file.
The old translations will be kept and the new keys will be added.

How to show document preview in iCloud conflicts sheet in Mac App using NSDocument

I am creating a Mac App, using NSDocument, that stores a custom class of documents to iCloud.
I was able to get the program to store documents to iCloud quite easily by just Code Signing it, Sandboxing it, and adding iCloud entitlements; however, I'm still encountering a problem where when I trigger an iCloud conflict and the program drops down the sheet allowing the user to resolve the conflict the rows in the sheet do not show the small image of the document (like Preview and TextEdit do).
Additionally, when I click on the area where the image should be (it's blank) it opens up a Quick Look window that just displays an image of the Document Icon together with some other information as opposed to a snap shot of the actual file like Preview and TextEdit do.
I have not found any information in Apple's documentation that explains what I need to do to implement the same behaviour as Preview and TextEdit.
So far I've been surprised by how easily I've been able to get all of the functionability of not only the Auto Saves and the Versions browser, but also saving to the Cloud. NSDocument seems to do all of this for the developer (resolving iCloud Conflicts, etc.), as Apple's documents says it does, but again I'm not getting this other behaviour and I don't want to reinvent the wheel by writing code that is not needed.
I'm thinking that the answer might lie somewhere with implementing a Quick Look thumbnail (for the small image in the table in the sheet) and a Quick Look preview for the larger preview of the document when that in the sheet is clicked on, but this seems like a lot of work and I'm afraid of losing some of the other build-in functions of NSDocument if I start "trapping" NSDocument routines up the food chain so to speak.
Has anyone else encountered this problem and found the easiest solution?
Update: Dec. 25/12
I've finally figured out that the problem is I need a QuickLook generator to display both a QL Thumbnail (which shows up in the table in the conflicts sheet) and a QL Preview (which is displayed when a user clicks on the Thumbnail)
I ended up creating the QL generator project, and afterwards creating a workspace which I added my main project and the QL generator project to. After that I added a Copy Files Build Phase to the main project to copy the QL generator into the main Application bundle.

iTunes Connect sends email about a issue with icon file, how to fix?

This is the email:
Dear developer,
We have discovered one or more issues with your recent binary submission for "Bla". Before your app can be reviewed, the following issues must be corrected:
Corrupt Icon File - The icon file 72 x 72.png appears to be corrupt.
Once these issues have been corrected , go to the Version Details page and click Ready to Upload Binary. Continue through the submission process until the app status is Waiting for Upload and then use Application Loader to upload the corrected binary.
I have change the file and re-upload the app, but I got the email again.
As Michael Dautermanm says.
Make sure "compress png's" is turned off in the build settings.
thanks
Can you open the file in Preview, and choose 'Tools' -> 'Show Inspector'? The file may be using some PNG format features that Apple don't like. They want RGB, 8 bit depth, no alpha. See the Custom Icon and Image Creation Guidelines.
For comparison, here are screenshots of the Preview Inspector, showing properties of an icon for an app that was accepted. If you're unsure, post similar screenshots for the properties of your picture.
The "Pixels Per Meter" part may or may not appear. It wasn't there when I first opened some icon files five minutes ago, and now it appears for every PNG I open. Weird.
Edit: also check the icon entries in your 'Info.plist', or the 'Info' tab for your Target. (These are not the same thing, as I just spent several hours discovering. Settings in the 'Info' tab override your 'Info.plist'.) As of the iOS 5.1 SDK, these include Icon file (a string), Icon files (an array), and Icon files (iOS 5) (a dictionary containing at least one dictionary containing an array). XCode seems to add your launch images to this list too. Don't rely on it to keep the list tidy - I have sometimes found outdated filenames in mine.
For further comparison, here's what ended up in the Info.plist of a valid app. Your filenames may be different, as long as they match the resources in your project.
I'm the developer of the app Pillboxie. I have been having the same issue as you, but I believe I may have finally found a solution.
Before proceeding with my suggestion, make sure that your Info.plist and all icon filenames appear exactly as Apple requires. Keep checking the documentation to make sure you're up-to-date, but Dondragmer's recommendation looks correct to me.
I created all my image resources, including app icons, in Photoshop, exporting for web as PNG-24's. Because Pillboxie has numerous images, setting "Compress png's" to YES in the build settings helps me save several megabytes of space. I was getting the same error as you until I tried turning off this compression, as Evaristoyok suggests. However, my app jumped up several mb. I hoped to find a better way.
Tonight I found the following link: article. In it the author suggests to make sure that "Interlaced" is NOT selected in Photoshop when exporting images in the Save For Web & Devices dialog window. I re-exported all icon and launch images with this disabled, and it solved my issue. I was able to submit my app and still leave png compression enabled.

XIB localization in XCode4 drives me crazy?

after many unsuccesfully attempts to sort out the XIB localization in XCode 4, I decided to post an help request here :).
1) I select a XIB file, say MyViewController.XIB.
2) I click the [+] button in the Localization area in right panel but it’s impossible to select the language. After clicking, I don't know why but another resource is selected (for example, another XIB file).
3) In XCode inferface nothing happens but in the filesystem the file MyVieController.XIB is moved (MOVED! NOT COPIED) in the en.lproj folder.
4) I add a new localization (this time I can select the language), say Italian.
5) In XCode interface now I see two “children” of MyViewController.XIB: the english one and the italian one.
6) Another strange thing is that the “main” MyViewController.XIB and its english version point to the same file (in en.lproj folder) so that any modification made in the first is automatically made in the second and viceversa.
Anyone of you has an explanation for this behaviour, that seems very odd to me?
Thanks in advance for your answers,
Marco.
I believe this behavior is intentional and consistent with best practices as far as localization is concerned.
Generally speaking, the top level of the Resources directory is only for XIB/NIBs that are not localized. Once you localize a particular XIB, it should be stored in your primary language folder and any localizations should be stored in the other language folders.
Basically, Xcode is helping you not to create a problem by moving your "main" MyViewController.XIB into the en.lproj folder (which should be whatever you have set as your native development region) as the first step to adding a new language for that file.
OS X (and iOS) are smart enough to use the default language (as specified in the CFBundleDevelopmentRegion a/k/a/ Localization native development region) when a resource doesn't exist in Resources or the currently active language.
If you want to build only French and Italian versions (no English), just make sure that you set the CFBundleDevelopmentRegion to the appropriate language code and the OS will then look in that directory for any resources that are not in the localized bundle.
Once you've set that, Xcode should (but doesn't appear to), put converted files into your requested default directory. A little digging around indicates that by editing your project.pbxproj file manually, you can set the developmentRegion to something other than English (I tested with fr), and that will make Xcode put the localized files in the right location.
I am pretty new to posting answers here, so please don't fire me if this is not the best place for this solution.
While this is not a direct answer to your question "Anyone of you has an explanation..." I feel compelled to answer your topic "XIB localization in XCode4 drives me crazy?" because I was looking for an answer to that very question, and I found that answer elsewhere.
My Problem = after localizing my XIB files in English and French, as outlined in your points 1)-5) my iPhone application would still show only English XIBs instead of French. The French XIBs were created and done properly in Xcode, and it turned out that something else, something unrelated, was causing the problem.
The following solution is borrowed from The Big Nerd Ranch Guide. I do not expect any votes here, all the credit goes to the excellent book from BNR.
There seems to be a glitch in Xcode (according to BNR, and proved to be true in my case) that sometimes Xcode ignores new resource file changes. To solve, delete the application from your iPhone, then choose Clean from the Product menu. This will ensure that the application is rebuilt from scratch. In my case, after doing this, the French XIBs loaded beautifully when expected.