What should I get translated?
Quick app localization checklist:
- App bundle
- XIBs (unflattened)
- Image resources with text (background content)
- Include any plugins and additional frameworks if present
- App Store description
- App Store keywords
- Changelogs (optional)
- Help files / documentation (optional)
- App website (optional)
Localizing your app naturally starts with the app itself. When it comes to OSX apps there’s quite a bit to think about. If you’re sending directly to a translator (not Applingua) then you need to think about extracting the strings in your XIB files into plain text .strings files. You can use the command line IBTOOL to do this, or use one of the many apps out there (iLocalize, nibTranslate) to simplify matters. Don’t forget framework and plugin resources!
Once you have all your .strings together, make a text file with image text. Often applications have background images with text like “Welcome” or “What’s new”. These are often left out. You know your app best, so go through your resources folder, weed out the text and type all these words into a text file for translation.
Round up of OS X .app files:
- IBTOOL your en.lproj resources to XIBs. Extract to .strings
- Don’t forget Plugins and Frameworks
- Make a note of all image text to send to translator
(Or use Applingua, we do all of this for you. Just send us the .app with unflattened XIBs)
iOS Applications are actually quite a bit easier. Most iOS applications reference all their strings from Localizable.strings. This makes it incredibly easy to just drag out this text file and send it to your translator.
Round up of iOS .app files:
- Localizable.strings from your en.lproj resources folder
Next up are your peripheral files. Most apps aim to be on one of Apple’s App Stores, so you need to be thinking about the App Store Description and the Keywords. Send these to your translator in plain text. It’s a good idea to review your descriptions before sending them off – do you want the quotes from “MacWorld Magazine” translated too? Leave them if yes, remove them if no.
This leaves documentation and supporting server side PHP/HTML documents. Over the years OSX applications especially have become bloated with documentation, a result of painful support tickets. These HTML files can often reach 4 times the word count of the app itself pushing costs through the roof. The question is, do you need to get them translated?
In my experience, no. Documentation is often a result of GUI mistakes you’ve made in the past. App developers are getting so good at UI that apps often explain themselves. Think about documentation before sending it off. There’s nothing wrong with not doing it, assessing demand and reviewing your choice in the future.
Finally, if your app uses server-sides to pull in latest news or information, think about getting this translated. It’s not the best experience for a French user to have downloaded your app because the App Store says it’s in French only to find that the tabs are but the content isn’t.
Round up of Peripheral files:
- App Store Description
- App Store Keywords
- Help Files / Documentation (Optional – read above)
- Supporting Server-Side HTML/PHP (Optional – read above)
There you have it. Package all these up and send them off to your translator.
Several have asked about changelogs. It’s very unlikely you’ll want to return to your localizer every time you submit a maintenance update. Those who are interested in changelogs may go as far to make the effort to run it through Google Translate if they don’t understand English. Our advice at present (and is always subject to change depending on Apple’s own future requirements) is to only translate the changelog if it’s a major update with marketing features.
We’d really appreciate it if you could rate this post to let us know how useful you found it! :) Thanks!