Reputation: 2787
Often in our iOS projects we have multiple supported languages. They are stored in standard .string files that look something like:
/* News section */
"news_title" = "News";
"ok_button_title" = "Ok";
This file can of course just be mailed to a non-technical translator who's told "Just replace the stuff to the right with the equivalent text in French". This is not always easy for them to understand, they might open the file in wordpad.exe and save it in a strange format, or generally mess up the file.
How have others solved these problems? Are there tools available that can help?
This might not be unique to iOS development - I suppose Rails, C#, Java developers have the same challenge?
Upvotes: 0
Views: 905
Reputation: 181
I've developed an online tool called lokaligo.com. It can handle iOS and Android projects, and allows you to invite your own translators.
It can also take screenshots automatically on iOS.
Upvotes: 0
Reputation: 2809
You may consider DMLocalizedString for your future iOS+Android project. Currently the source is for iOS only, but I believe that making the Android version is pretty easy.
Upvotes: 0
Reputation: 181
There are recommended translation agencies on the apple dev site, some of them offering integrations with the dev environment. Check out tethras.com for example - http://kb.tethras.com/localizing-your-ios-app.
Spreadsheets are another option, but you should include descriptions or where the strings are used and screenshots too, as context is everything in translation! Any length restrictions should be included (+30% expansion over English for longer strings, 200% for short, etc) and instructions on how to deal with tokens should also be included. Avoid sending them anything with code embedded as it risks being broken and ups the testing requirement.
Upvotes: 0
Reputation: 16031
I think you maybe misunderstood the strings file format. I should look more like this, with a comment for each string to be localized, as shown in the localization guidelines, i.e.
/* Error string used for unknown error types. */
"ErrorString_1" = "An unknown error occurred.";
Make sure you fill out the comment field of NSLocalizedString()
with descriptive text, thats where the comment comes from.
This page looks helpful: https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPInternational/Articles/NotesForLocalizers.html
You should use the genstrings
tool to generate the strings file for you.
Upvotes: 0
Reputation: 276
This problem is definitely not unique to iOS - it is related to software localization in general, and I am in charge of this in a software company. This means:
We use a CAT tool to do this (CAT = Computer-Aided Translation). In our case, it is SDL Passolo, but that is just an example. Previously we had a different tools, and the feature and workflow were almost identical.
CAT tools are designed to make sure that the source file format is preserved during translation. Passolo will, for example, read Windows resource DLLs or Java Properties by default. It will extract the stuff that needs translation and make sure everything else (string IDs, for example) is write-protected. My version of Passolo wouldn't automatically recognize the iOS format, but I could easily define a set of rules for these files using regular expressions.
In addition, in case of an update, I just import the new source files and the tool highlights new and changed strings in different colors and allows me to filter for them. Everything else is automatically pre-translated. This is called a translation memory.
We have Windows clients with ten thousands of strings and there are updates several times a year. While we may have had linguistically bad translations, updates werde always done quickly and we never ever had broken target files or functional problems due to localization.
The downside is: these tools are not cheap (though things have improved a bit and in our case, the investment payed off really fast). If you don't want to buy a CAT tool yourself, make sure you work with an agency or a translator who is using these tools.
You may wish to check out http://www.proz.com, and on CAT tools: http://wiki.proz.com/wiki/index.php/Category:CAT_tools.
Upvotes: 0
Reputation: 3058
We worked with a spreadsheet file, which we sent to the translators. And the translator simply adds a column with the translated texts. See example file below:
http://members.home.nl/bas.de.reuver/files/multilanguage.zip
Alternatively, you could use Google docs spreadsheet which is even easier to share online.
Upvotes: 0
Reputation: 12713
https://www.transifex.com/ can handle iOS files. As can other plattforms like this.
Upvotes: 1
Reputation:
If a translator can't understand "Just replace the stuff to the right with the equivalent text in French", he should probably not be working as a translator. This is just fine. At most, tell them explicitly to use a text editor and not a word processor - i. e. Notepad or Gedit or TextEdit is applicable, Word, OpenOffice Writer and Pages isn't.
Upvotes: 0
Reputation: 89549
There's a lot of information to be found at Apple's "Introuction to Internationalization Programming Topics" page and it can be a little intimidating, but it would be worth your while to skim through there at least somewhat.
Yes, localizing your app might be as simple as changing string files from one language to another, but some languages can explode a couple words into a sentence or radically alter the appearance of a dialog (in which case the actual xib might need to be modified in order to look proper on that language -- thankfully you have language specific resource folders with language specific xib files that you can drop into the Resources area of your app package, etc.). So you need to be familiar with the potential issues and gotchas that might pop up when you add in additional languages.
Upvotes: 0