Mistakes in Localizable Strings
Did you see the What’s New In International User Interfaces talk at the WWDC 2016? Some of the developments Apple demonstrated made it look like we’re on the cusp of solving most localization and internationalization problems.
It’s fair to say that the announcements in the talk will have been welcomed by Arabic language users: right-to-left texts and images has always been a challenge in localization. Thankfully companies like Apple are now, at last, starting to take the steps to address these issues. Perhaps we will see an increase in the number of iOS and macOS users of Arabic and Hebrew, as platforms become better localized for their scripts. At the moment, many prefer to use English because of the poor localization.
But no matter how far technology takes us in the localization process, there are always going to be those small hiccups and errors. These could be in the actual strings themselves. For example, the dev team uses the wrong string formatter, causing the software to crash. Or the problem could be in the translation. For example, a word left untranslated because the translator thought it was a brand name.
These issues will probably always crop up every now and then. So, if you come across an issue in your localizable strings, how should you proceed?
Coding Issues in Localizable Strings
I know you’ve checked your code, I know it’s been tested, and I know it all works. But trust me, there’s going to be at least one moment when you realize something’s wrong. It’s fine – don’t sweat. Mistakes happen. And when you’re dealing with thousands of lines of code, it’s not only probable – it’s pretty much expected.
In our experience, developers tend to want to correct all issues in all files, including all the localized strings. However, any good localization agency will actually want to fix problems themselves. This way they avoid problems reoccurring again and again in the future
For example, let’s imagine you to change a key, so you make this alteration in the source file (usually English) and then in every localized file. Logically, you think you’re helping the localization agency, and in a way you are, but really you’re just making more work for yourself. Localization agencies tend to operate out of the source file. In fact, all updates are done through the source file. So if you make a change in the source file and send it to the agency, then they will propagate this change is made in all the localized versions.
This way you save yourself time, effort and, most importantly, your localization partner will always have an overview of the master version, avoiding errors unnecessarily cropping up again and again in the future. A small update is a small update, except when you’re dealing with 15 localized versions – in that case it’s a massive update and a there’s greater potential for issues and complications.
Translation Issues in Localizable Strings
When going through your localized strings, you can sometimes come across issues due to the translation. For example, the translator thought Feed should be translated but as it’s being used a branded feature in the app it needs to be kept in English.
Another example is numbered placeholders. Many languages have different a word order to English, so the placeholders have to be numbered so that they appear in the right order in the target language e.g. %1$@, %2$d, %3$@. This only works if you do it for every single placeholder in a string, even for the ones which aren’t affected. The translator has overlooked this, so you change it yourself manually and send it back.
Why do this yourself when you can get professional to do it. Why risk skewing the meaning of the translation by doing this yourself. Get your localization partner to do it – they’re the professionals, they know about language and they’ll make sure it’s correct in future, as you continue working together.
What’s more, like with above, this ensure the localization agency has a good overview of the master version and can reduce the risk of such errors reoccurring.
If ever in doubt…
If you’re ever in doubt and not sure whether you should just go ahead and make changes yourself or pass them on toy our localization partner, then we recommend just asking the localization agency directly. They can advise you on what to do. Remember, your localization partner deals with these things day in and day out, so they know best. They’re the linguistics and know how languages work, including but not limited to the different word orders in other languages.
The moral of the story is give yourself less work and change the source file. Send it back to the localization agency and ask them to update their translated localizable.strings. They’ll send them back to you, altered, corrected and ready to go.