For a long time Applingua differentiated in price between languages. Those which had a Latin script were set at one price. These included European languages like Spanish, French and German, as well as other non-European languages written in Latin script, such as Turkish and Indonesian. And languages with a different script, like Arabic, Hindi and Chinese, were set a different price.
It won’t come as a surprise that the non-Latin script languages were set at a higher price. They even included some European language, such as Russian, Greek and Croatian, which use a different script.
You’re probably wondering why? Well, it largely came down to a few things:
- Script Compatibility
Handling these scripts was often more of a challenge in the past, particularly trying to get platforms and documents to recognise the characters.
- Software Compatibility
These languages often have features which are very different to English, such as more than one plural (Russian), no spacing between words (Chinese) and right-to-left text (Arabic). The vast majority of apps in the world are created in English and for an English-speaking audience or at best for a European/American audience. As a result, these apps haven’t been prepared for these kinds of languages, which makes the task of localization much more difficult.
- In-house Expertise
Initially our training, testing and proofing of these languages was far greater as we’re not familiar with the languages in-house. Among the Applingua team, we speak a total of 8 languages in our office, but unfortunately not Arabic or Chinese (yet!).
Despite the issues above, the world is becoming more internationalized and globalized. This means more software is being prepared by internationalizaton engineers for the world beyond the USA and Europe. As a result, software localization is becoming easier, particularly for the non-Latin script languages.
No more challenges?
Well, no. There are still plenty of challenges which need to be overcome in localization, particularly in right-t0-left languages. However, some of the other challenges are definitely getting easier.
One of our favourite examples of this is languages which have numerous plurals. Take Russian, for example, where there is the singular word, the 2 to 5 plural, and then the plural for anything above 5. Compared with English, this is immensely complex, as English just has singular and plural. But now you can build 3 versions of a word: Singular, Few (useful for the 2 to 5 plural) and Many (all other plurals).
Now while this has been addressed, other linguistic issues remain far from sorted, including grammatical case, but we’ll save that for another blog post.
Overall, however, localization is becoming easier and quicker. So there’s less of a need to distinguish between non-Latin script languages and those with a Latin script.
Any other reasons?
Businesses often have to make decisions based on market forces and finances, rather than on their beliefs or ethics. Here at Applingua we don’t believe any language is more important than any other. That is one of the main reasons why differentiated rates didn’t sit so well with us. However, due to the additional challenges outlined above, we had to set different prices.
Now a lot of those challenges have been overcome, we can now go with what we feel is right: universal rates across all languages.
What’s the new rate?
The new rate is 0.18USD/word. This makes us cheaper than several other localization agencies out there, who charge more and are still differentiating rates between languages. It also makes calculating your project really easy: just multiply the number of words by 0.18USD and you have the project cost.
Really, that simple?
Yes, it is! And to make things even better, we also remove duplicate strings! Now, this is something which might be a little harder for you to calculate on your own, as you’re counting the number of words, but we work on the basis of strings. So, if you have repeating strings, such as “Tap Here” or “Submit”, we won’t charge you more than once for these strings.
This means when you submit your project to us, you’ll have a good idea of how much it will cost, and when we send you the official invoice, nine times out of ten you’ll be in for pleasant surprise when you see the prices is lower than you expected.
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.
Here at Applingua we often get asked what the localization process involves. Localization is generally very much the same from translation agency to translation agency, whether it’s an app, a game or a website being localized. However, there might be some small differences from company to company. For example, not all agencies offer testing within the translation fee – here at Applingua testing is an integral part of what we do, so there’s no extra cost for testing.
So, let’s take a look at the steps involved in localizing your product:
1. Prepare for localization
Before any app, game or website can be translated, it needs to be prepared for localization. This could be in the way you organise your Xcode project, or installing translation plugins for wordpress.
2. Decide on which languages
This is of course one of the most important decisions and we can often provide advice on this. Check out our previous post on the top most translated app languages. Essentially, you have to consider carefully the following:
- Where you have demand from: countries where users are asking for your product to be translated is probably a good sign of its potential success in that country once localized
- Where you can profit from: at the moment, your app isn’t available to those who speak on Chinese, for example, so once it’s translated, could you potentially have access to a market of over a billion people?
3. Send us everything
Once you’ve prepared the strings for localization and decided on the languages, send them to us either in an e-mail (firstname.lastname@example.org) or using our Quote Form and we’ll put together a quote for you based on the number of words and the number of languages.
Applingua Top Tip: at Applingua we don’t charge for duplicates, so if you have any strings which appear more than once, you’ll only be charged for one translation – not all agencies do this, so we’ll definitely save you some money this way!
When providing us with the necessary files, it’s also a good idea to give us information about the following:
- The name of your product and your company name – these are often different
- A brief description of your product: what it does, who it is for and which platform it will be available on i.e. iOS, macOS, Android etc
- A link to the product website – this can often give translation invaluable insight in to the product and how it works, which can directly affect the translations
4. Approve the estimate
We’ll send you over an estimate of the entire cost of the project with a proposed time-scale. Clients often wonder how long a translation project will take. Well, how long is a piece of string? It just depends on the number of words. As a rule of thumb, I’d recommend calculating around 1 day for every 400-500 words. This is just for the translation itself – the whole process will take more time. But if you have a project which is 800 words, we’d expect the translators to take about two days to translate that, plus a day or two for testing and signing off.
When we send you over the estimate, we’ll also include the most asked question at Applingua: Would you like us to proceed? If you’re happy to go ahead, just hit the reply button and type “yes” – this is really important, sometimes people think we’ll go ahead with the translation, but we need a 100% confirmation from the client before we start anything. That way we make sure you’re definitely happy with the cost of the project.
The project is then assigned to our translators. Sometimes they’ll need clarification on issues such as context or specialist words, so we might be in touch with a few queries. Otherwise, the translators localize the product into their language. Once the translations are all done, we’ll send the localized strings back to you.
At Applingua we value the importance of testing. We see it as an integral part of the localization process. Translators work with strings when localizing, so they don’t see the overall product. This is why testing is so important. This way the translator can see the product in use and can check the translation fits the context of the product.
During the testing process, there might be some changes made, but once they’re done, the product is good to go. We’ll send it back to you, ready for you to release!
A final thought…
When translating an app or a game, it’s easy to forget that these come with App Store Descriptions, a website and Support Documentation. For your customers to have the full experience, they’ll also need access to these in their language, so make sure you plan to have these translated as well. This also might save you a lot of time responding to e-mails in foreign languages asking for supporting and help.
At Applingua we’re big believers in the role education and training play in the localization industry. As part of our drive to raise standards, we’ve started offering guest lectures at universities to graduates on MA translation courses, specialist localization courses and computer sciences programmes, including games design.
Last week we spoke at Newcastle University in the School of Modern Languages. Around 100 students attended the guest lecture. The students were predominantly from the Translation Studies MA programme, with some from other programmes and even undergraduate courses.
As the programme covers all aspects of translation, including the fundamentals of localization, we decided to give the students a talk which gives them invaluable insight into the essentials of app translation.
Being an app translator
Translating documents isn’t the same as translating an app. To work in app localization, you need to understand this, especially if you’re going to tackle some of the challenges head-on. One way you can prepare yourself for the world of app translation is by getting acquainted with smartphones, tablets and apps. You’d be amazed how translators come to us who don’t own a smartphone and never use apps.
Lack of context
One of the biggest challenges working in this industry is the lack of context given when translating. Unlike when translating a book or a document, apps aren’t translated inside the app: you don’t get to see what surrounds a word or phrase. This is because the developers have had to extract all the words displayed to the user from the code of the app and then give them to the translator to translate. So, for example, image you’ve been given the word print to translate. There’s nothing else, just this single word. You have to determine whether it means the verb to print, a command like print! or the noun a print as in a photo. The first step to figuring this out is understanding what the app does and knowing how such apps work. For example, if it is an instagram-like app, then print will probably be the noun.
In app development, software engineers don’t write out every possible line of text the end user will see – that would take up too much time. Instead, they write out chunks of text and then use code to bring them together. The following is a common example:
from %@ to %@
The symbols just mean something else can go in that place. The question you have to ask yourself is what could it be? You probably won’t know the answer until you see the finished product, but you can use your knowledge about the app to make an educated guess. If it’s a travel app, could these placeholders be destinations, airports, train stations or even dates?
Alongside the 3 areas above, the talk introduced the students to a wide variety of essentials when localizing an app. This included:
- Numbers, times and dates
- Cultural considerations, colours and gestures
- Technical issues, screen size and line division
- Tone, register and voice
Would you like us to speak?
Whether you run university courses in games design, localization engineering or translation studies, or you run Professional Development courses for an organization, we’re happy to help in any way we can. If you’d like us to come and speak at your institution, drop us a line on email@example.com
It’s been a long time since we shared what are our Top 5 requested languages are at Applingua and how they compare with the Top 5 languages taken from the Top 10 apps on the Apple App Store at the moment.
In this post we will reveal what our most requested languages have been in 2016, compare those to what we find in the Top 10 of the App Store this October, and finally help you choose the best languages for your app.
Choosing the right languages for your app
We’re often told that choosing which languages to translate your app into is a difficult decision. Most app developers have little market knowledge or experience with languages to know which to choose. Our reply is always the same: each app is unique.
Don’t let this dishearten you, however. Here are some simple strategies you could use to decide on the appropriate localisations for your app or game.
1. Where is there demand?
If your app is already on the App Store, check where you are getting downloads from. Choose from the top countries here around 3-5 languages in your first round, 5-10 in the next round (if there is a return on investment).
2. What are your competitors doing?
Check out what your competitors are doing and choose the same… or, alternatively, take a risk and choose completely different languages. Sometimes you can Capture the Flag before your competitors do in new markets.
3. What are the biggest potential markets?
China is huge, we know that, but what about Japan, Indonesia, India, Brazil? They’re also big markets now, especially for Android and free/freemium iOS apps.
4. What is everyone else doing?
Sometimes you just have nothing to base your decision on, so just choose the Top 5 we suggest below. There’s never any guarantee whether a localization will bring you a return on investment, but if your app is good and growing, we’d like to hope these Top 5 languages will bring rewards.
The App Store Top 5 Languages
The App Store now has three main Top Apps lists: Top Paid, Top Free and Top Grossing. These are obviously the blockbusters of the App Store, and it’s common to find multiple localizations for each app.
For this reason, it’s difficult to pick just 5, as many languages are joint second and third.
4= Traditional Chinese
5= Simplified Chinese
1= Simplified Chinese
1= Traditional Chinese
2 Traditional Chinese
3= Simplified Chinese
The Applingua Top 5 Languages
1 Simplified Chinese
3= Brazilian Portuguese
4= Traditional Chinese
One final point of reference could be the set of languages Apple localize their software such as Podcasts app and iTunes into.
The Apple list of languages is long, but for reference, here they are: Arabic, Catalan, Croatian, Czech, Danish, Dutch, English, Finnish, French, German, Greek, Hebrew, Hindi, Hungarian, Indonesian, Italian, Japanese, Korean, Malay, Norwegian, Polish, Portuguese, Romanian, Russian, Simplified Chinese, Slovak, Spanish, Swedish, Thai, Trad Chinese, Turkish, Ukrainian, Vietnamese