If you care about your instrument being in tune, and in tune being a tuning system that compliments your music, I really think you should use Well Tempered. That’s why I made the decision to localize Well Tempered so that it would be native to at least 70% of people with an iPhone or iPad, and then the second language to most of the rest. I thus localized the application to English, French, German, Spanish, Italian, Russian, Chinese, Japanese and Korean.
Thinking about localization, I found two really hard questions:
- Do I localize the name?
- Do I localize the data?
Starting off with the name, Well Tempered could be thought of as a brand name. If a French speaking person reads a review on an English blog and wants to try it out, I really want that person to find Well Tempered. Calling it Bien Tempéré would make that harder.
Then again, the name is based on Bach’s Well-Tempered Clavier, and that name already has a translation to French: le Clavier bien tempéré. And of course, the English name is a translation from German: Das Wohltemperierte Klavier. Keeping the enlighs translated name in German seemed absurd. In other languages, such as Korean, I was told by the translators they would use the English name. So I ended up with a mix: in some languages I kept the name, and in some languages it was translated. I was curious to see what difference it would make.
The data in my app is temperament names and temperament calculations. I was curious whether I should translate all the names, but since I had so many temperaments, where some perhaps had appropriate translations and some did not, I chose not to translate them. I have yet to get any feedback on this from my users, so the question still stands.
Apart from these questions, the translation process was smooth enough. I used Tethras that I already have a good relation with, and I think the level of service I got was excellent compared to the price I paid. After that I wanted to use my network to get musicians who had that language as their native tongue to look over the end product. This didn’t go very well as I still miss hearing back from most people that I asked. If something is amiss in a language, I expect I will hear about it.
I have been impressed by how much effort Apple has put into making iOS accessible to people with disabilities. With them making it so easy to make my app accessible, it was only natural for me to implement this for Well Tempered. Not only would I make sure it was accessible, but I would also make sure the accessibility labels were localized the same languages as the interface in general.
Unfortunately, I was not able to get people with disabilities in my test group - I would really have liked to have more input on this. So I ended up testing it myself, and I shipped something I was happy with for the languages I understand. I really hope to hear back from users with disabilities, preferably in many languages.
A side benefit of making Well Tempered accessible, is that this makes it more easy to make automated tests for it. I have earlier used Calabash a great deal, but for this project I wanted to use UI automation, since I wanted also to use it to prepare my screenshots for the App Store. I had found that I could use snapshot from fastlane.tools to take screenshot based on my UI tests.
If you have ever used UI automation, you’re probably rolling your eyes now, and you would not be surprised to know that this was my biggest mistake. I would make my scripts, and spend a good time making those scripts since I got no feedback from the editor. Not a good experience at all. While working on the script it would lock up midway, and after finishing it, it would not reliably run again. Some runs it would not complete, some it would only take black images.
So instead of getting frustrated and wasting time, I should have made real tests and used that to take images. I would explore going back to Calabash every now and then, but I didn’t get how to change the language of Calabash and how I should write my scripts for an app where also the accessibility was localized, so in the end I ended up without UI tests.
Well, in the end is perhaps overstating it, a little while later Apple released UI testing with iOS 9 and Xcode, so this is what I will be using now. It even allows me to test with localized accessibility labels. :-) And Felix who is behind fastlane.tools is already working on UI testing and screenshots for snapshot. I had a bit of an issue about how to launch my app in different languages, but that has been solved now, so I can build my comprehensive test set that I hopefully can reuse for the UI testing.
Thanks for following me this far. In installment six I’ll cover the launch of version 2.0, and talk about app marketing. Stay tuned!