‘Google doesn’t always have the nuances necessary for correct translation.’ Photograph: Graham Turner for the Guardian’
It’s easy to feel intimidated by the prospect of selling in another language. According to research from the British Council, around three-quarters of British people don’t speak another language well enough to have a basic conversation, let alone sell a product or negotiate a deal. But it’s well worth getting over that language barrier. A recent report from the Department of Business, Innovation and Skills (BIS) found that the UK is losing out on an incredible £48bn a year in lost exports as a direct result of its lack of language skills.
“A lot of SMEs see languages as a cost and it’s absolutely not a cost, it’s an investment,” says Roy Allkin, co-founder of translation company Wolfestone. “We need to change the perceptions that the language barrier is too big to get over, that it’s too difficult to compete with native speakers and that ultimately, everyone out there speaks English – which is absolutely untrue.”
A problem you’re likely to encounter when exporting is getting documents translated – everything from customs forms to your website content. But there are plenty of options. If you don’t want to spend a lot of money initially, or you’re just testing the water in a new country, you could try using students and people on work experience to translate simple texts, as Neil Westwood, co-founder of Magic Whiteboard, has done. Exports currently make up around 20% of their sales, to countries as diverse as Japan, Romania and Mexico.
“We got a lad on work experience from Germany, and he translated our webpage into German for £700,” he says. “We were smaller back then, and we were experimenting with these markets, so we wanted it done cheaply. A Peruvian student I met when I visited my old university, Canterbury, did it in Spanish for £500. We get a lot more enquiries from these markets now.”
Google Translate is free, of course, but it doesn’t always have the nuances necessary for correct translation, says Richard Brooks, founder of translation company K International. “It’s hard enough to find the right words in English if you’re not a communications expert – and expecting a computer to do it might be an expectation too far.”
Westwood found this out when he translated his business cards into Japanese using Google Translate and presented them at a trade show in Tokyo. “I translated ‘clings using static’ as that’s what our products do, and that didn’t translate very well, apparently. They looked puzzled and said ‘who have you got to do this?’ Luckily, we turned it into a laugh, saying we were crazy English people.”
It’s important to remember that just being able to speak a language doesn’t qualify a person – or a computer – to translate it accurately. Relying on the cheapest methods could prove a false economy, particularly when there’s a lot at stake and you need an expert not just in a language, but also in a specific area such as contract law, software development or HR. The next step up is to use a freelance translator or translation agency – but still make sure you check both their credentials and experience. “There’s a common misconception that anyone who can speak more than one language can translate,” says Karin Nielsen, founder of Fluently, an online marketplace which connects companies directly with translators with relevant experience.
“A real translator has six years’ worth of academia behind them to back up their skills. Translating is not easy and that’s why all the translators on our platform have professional translation qualifications. In addition to that, a lot of them have extra qualifications – so we have lawyers, HR people, developers, people with technical knowledge. In order for a translation to be really good, the translator has to have a really good understanding of not just the subject matter but also the brand that they are translating for.”
Support with business communication
There’s help available from UK Trade and Investment (UKTI), which runs the Postgraduates for International Business scheme. This matches postgraduates with language skills who are currently at university with companies who need their skills on a temporary basis. It’s up to the company to specify what help it needs, which could be anything from selling over the phone in a different language to emailing clients or internationalising websites.
UKTI can also assist with more general cultural understanding, which goes hand in hand with language skills. Emma Sheldon is group marketing director of health products company Vernacare, which is currently enjoying success in the Singapore market and is looking to expand further into Asia. A UKTI language and cultural representative came in to look at Vernacare’s business strategy and advise on communication and business etiquette – which can be very different in Asian countries. “For example, the number four is unlucky in China, so just by having that on your phone number you could be putting yourself at a disadvantage,” says Sheldon. “People might not want to ring it.”
Going beyond translating documents to communicating directly, it’s worth looking specifically for new employees with language skills, says David Howden, co-founder of The Tartisan Bakery, which sells tarts with customisable packaging online. It’s only a month old but they’ve already shipped to Switzerland, Germany, Chile, North America and Thailand.
Although he only speaks English, Howden’s partner Jess Morteln is a native German speaker who also speaks Spanish.“We’ve always wanted to export and I don’t believe that as a startup we could have done it without one of us having other languages,” he says.
Sheldon agrees. “When the company is looking to enter a new market, Vernacare will use agencies for interpreting during trips abroad and translating, until there’s a permanent need,” she explains. “Once we know we’re entering those markets, then we start to think about getting multilingual sales and marketing staff who can support us in translation, order taking and suchlike.”
And don’t be afraid to have a go yourself when you meet people face-to-face. “If you can say please and thank you and order a beer, people think you’ve made the effort,” says Allkin. “We think everybody speaks English but it goes both ways – there’s an opinion out there that nobody in the UK bothers to learn languages as we’re arrogant and we think everyone speaks English. Knowing a few words yourself can absolutely make the difference.”
Sign up to become a member of the Guardian Small Business Network here for more advice, insight and best practice direct to your inbox.
Since you’re here …
… we have a small favour to ask. More people are reading the Guardian than ever but advertising revenues across the media are falling fast. And unlike many news organisations, we haven’t put up a paywall – we want to keep our journalism as open as we can. So you can see why we need to ask for your help. The Guardian’s independent, investigative journalism takes a lot of time, money and hard work to produce. But we do it because we believe our perspective matters – because it might well be your perspective, too.
I appreciate there not being a paywall: it is more democratic for the media to be available for all and not a commodity to be purchased by a few. I’m happy to make a contribution so others with less means still have access to information. Thomasine F-R.
If everyone who reads our reporting, who likes it, helps to support it, our future would be much more secure.
Software errors found after the product has been released can cost four to five times as much to fix as the ones uncovered during the design stage. And, for localized products, these costs can be multiplied by the number of target languages. Incorporating localization steps early can reduce costs and save precious nerves.
When a software development team is in the product design phase, it is easy for localization to be overlooked. Development teams are busy gathering user requirements, developing components and testing usability in the source language (most often English) – until the moment when the product manager says:
“OK, this is great! Let’s sell it in 15 countries.”
If localizability hasn’t been built into the product, developers can be hurled into a costly and time-consuming spiral of retrofitting global needs onto a product, delaying global release cycles and creating inelegant, provisional workarounds that add unnecessary complication to both native and international release processes. What seemed like a great idea – to amortize development costs more quickly through global expansion – can rapidly become the source of sleepless nights for both the product manager and the development team.
The ultimate goal of software development for the global marketplace should be to create a “world-ready” application. This process is often referred to as internationalization, and ensures that software can be run anywhere in any language. This means the application should be able to support any locale, any regional time, date or numbering formats, as well as ensuring that the application is ready to be translated into any language, even those using different scripts and alphabets or bi-directional languages such as Hebrew or Arabic.
The key to localizability is the design of software and resources that enable a software localization process that does not require re-engineering or modifying code after translation processes have been completed.
The first step on the road to a “world-ready” application is achieving the clear separation of User Interface (UI) resources from functionality-related resources. The ideal scenario is to achieve this separation using file formats that suit localization teams – enabling both the use of professional translation tools and potential automation, which becomes a key element when developing and localizing in agile environments.
The second step is to be able to measure the success of any localizability efforts. The easiest way to confirm that a product can be easily localized is by running localizability testing tasks.
Function and process
There are typically three interdependent functional teams involved in launching a global product: developers, translators and testers.
As the process flow in Figure 1 illustrates, usability testing takes place prior to the launch of software in its original language, but also after translation. Localization testing can result in two types of issues:
Translation issues can be fixed by getting the linguist to amend the translation. This type of issue usually occurs either because the original translation does not reflect a string’s real meaning in the context of the running application or a string needs to be shortened to match the space available within the User Interface.
Functional issues are issues that need to be routed back to developers that cannot be fixed by making a linguistic change. These can range from bugs introduced due to the translated language to string length issues, which cannot be fixed by reducing the length of a translation or functional issues not apparent in the English build.
Figure 1: A typical software release process
Source: Argos Multilingual
Context is king
It might seem self-evident, but the key to a successfully localized software product is to enable linguists to do the best possible job.
Professional linguists are usually highly qualified: In addition to a degree in translation, they often have many years of professional experience before they specialize in a particular area. But even the best linguists need to have a solid understanding of the original product if they are to produce a great translation.
Reducing the number of functionality issues relating to world-readiness is one of the factors that will allow linguists to get the translation right the first time.
When it comes to giving linguists what they need to do the job correctly, context is the single biggest factor. In software localization, context is king. Provide as much context information as possible, and your product will reap the benefits.
The perfect scenario is a full visualization of the UI during translation, but other elements can also be very helpful:
Meaningful string identifiers can provide additional context information.
Comments from developers can be a great source of information, especially for cryptic UI messages.
Length limitation information. Note that a “number of characters” limitation will work only with fixed-width fonts. When using proportional fonts, the linguist will need to know the actual width of a string in pixels compared with the length limitation.
In cases where localizability has not been built into the development process and where the product manager decides that the product should be sold globally, a developer is often quickly reassigned to produce “translatable” resources. In practice, these developers are very often tempted by easy-looking formats like Excel files, where linguists are expected to insert translations into their language’s column parallel to the English string. Once translation is completed, a developer then needs to copy and paste the translations back into the code. It is worth mentioning that it is rare that these kinds of hurried copy-and-paste operations in an unfamiliar language are done right the first time around!
Figure 2 is an example of such a translatable file in Excel format.
Figure 2: Example of a UI translation file in Excel format
Source: Argos Multilingual
As you can see, the developer has put a great deal of effort into creating the file and has included useful information such as where the string is found and the maximum string lengths. No doubt the developer is very proud of the work and believes that the file will be a great help for translation teams.
Although the file might look cumbersome, the developer has actually done a decent job in this example; it is significantly better than many localization files received even ten years ago!
In reality, though, these formats are not easy to process in a translation workflow, and it is worth getting developers and localization engineers together in order to discuss available options. In most situations, there are better ways to handle the UI files. These days, linguistic technologies are far more advanced and a little forethought can result in a much smoother localization process.
Where should you start? Usually, the best place to begin is the software development framework being used.
Most modern software development frameworks provide tools to extract UI content from code and guidelines on how to create code that can be easily processed for localization. These tools produce files in formats supported by translation tools like .resx, .properties, .po and .ts files.
Processing UI content with translation tools gives linguists access to many advanced features like translation memory, terminology databases and automated quality checks that are right at the translator’s fingertips as part of the translation environment. These features help speed up the production of high-quality translations.
Some frameworks even enable linguists to preview UI while translating. This is usually the best possible scenario – translators see the translation immediately in the right context, they see what type of element is being translated (button, menu item, text field label), and they can see the potential space limitations.
Unified formats for UI translation are a key element to automation of hand-off/hand-back processes in agile workflows. Without automation, agile localization processes can’t integrate with agile development processes, and there is no automation if formats are not clearly defined.
Figure 3 shows a preview generated from an .resx Windows Form by a popular translation tool. As you can see, there is plenty of useful information available for linguists, including the string ID, development comments as well as a preview of the dialog, which will help linguists to understand how a dialog is used, and whether there are any string length limitations.
Figure 3: A Windows Form preview generated from .resx resources
Source: Argos Multilingual
Even custom XML files can be previewed. Because XML files can be easily processed for translation, additional information such as comments about usage or context can also be included for linguists, giving them the best possible chance of getting translations right the first time.
A proactive localizability development model
The problem with incorporating localization late in the development process is that it complicates the process of resolving language-related issues discovered during or after translation, and during localization testing. These issues will probably require some development rework and are likely to happen at a very critical moment in the timeline – right before the release. A study by the Systems Science Institute at IBM found that the “cost to fix an error found after product release was four to five times as much as one uncovered during design.”
For localized products, these costs have the potential to be multiplied by the number of target languages.
If localizability testing isn’t carried out before English approval, each testing team (for the respective target languages) will spend time discovering and reporting the same issues, and will then each have to run regression testing on the same bugs. This can be avoided if localizability testing is brought forward in the product development cycle.
If we modify the earlier process a little – by running localizability testing in sync with usability testing – we can avoid these issues altogether. Figure 4 shows a revised process flow with the inclusion of pseudo-translation testing.
Figure 4: A software release process adapted for localization
Source: Argos Multilingual
This means developers will exchange localizable files with the translation team even before source content is approved.
Introducing pseudo-translation testing helps to identify language-related issues early in the process, so there is still enough time to go back to developers and fix any language-related issues.
Once the source content is approved, it can be translated and tested linguistically, knowing well that the number of issues requiring developer intervention has been minimized because they were already discovered and fixed much earlier in the process.
Pseudo-localization
So what is pseudo-localization? It is a very rapid and cost-effective method of mimicking the effects of the translation process without the costs and scheduling impact of a real translation.
Pseudo-localization simulates the translation of all resource strings, and usually includes:
Replacing some English characters with similar non-English characters.
Adding extra characters to simulate text expansion.
Adding prefixes and suffixes to mark the boundaries of a string.
Using Unicode characters for all resources.
All these changes can be automated, so all UI resources can be modified, using similar patterns that help to identify issues quickly in newly built resources.
Pseudo-translated resources can be used to rebuild an application and test it. It should function in the same way as the original version.
Thanks to the patterns used while pseudo-translating resources, it is easy to detect the following issues:
Strings that were hard-coded and were not moved to the localizable resources.
Strings that were built from other strings by concatenation or replacing some parts of the string – these strings will often fail to work in languages different from the source language.
Any Unicode-incompatible functions that process or display text.
Any other display issues like incompatible fonts, truncated strings or unexpected space limitations.
Code reviews and lessons learned
Just as complex projects should be followed by a post-project review, it is worth closing the development loop by creating and maintaining code development guidelines that include localization-related guidelines. These guidelines should reflect results of code audits and localization process issues that were fixed in the past. For projects with large volumes of code, there are third-party tools that can automate the code review process. What’s more, localization providers will normally be happy to participate in this process too, as it will help them to perform great work the first time around in future projects.
In a nutshell, world-readiness is perfectly compatible with the development process as long as you take steps to bring your localization partners on board early, perform pseudo-translations to test localizability before translations begin, and consider the best format to allow linguists to perform their job.
All this means that everyone can enjoy a peaceful night’s sleep when your product manager asks to sell in multiple locales. You will be able to answer with confidence: “Sure. No problem, let’s do it!”
If you want to make your iOS app more visible and reach new customers this year, you’ll have to step out of your comfort zone. How do you do that? By localizing your app and seeking new customers in different parts of the world. Mobile apps have become global and, by 2020, revenues could exceed $101 billion. If you want a piece of the action in 2017, you’ll need to move fast. Plan for iOS localization that is both universal and local, for every new market you approach.
Why iOS Localization?
The close of 2016 bought some pretty good news for Apple. Despite fierce competition, iOS operating systems still make for the most desirable smartphone in the world. Sales of iPhone 7 reached respectable numbers in almost all countries. So, from China to India, Mexico to Thailand, your next customer could come from anywhere! Get your iOS localization strategy right and your downloads will grow faster than ever.
Just take a look at the App Store and you’ll see that iOS app localization is no longer a strategy to ignore. The most popular apps, including Facebook, WhatsApp, Netflix and Uber, are all localized. With iOS 10’s latest update, localizing your iOS app is now easier than ever before. So, if you haven’t started to prepare your iOS localization process yet, this should be your top priority in 2017.
But, as with so much in life, there’s a right way and a wrong way of localizing your iOS app. You need to have a clear view on the process, so that you can reach as many customers in their native languages as possible. It’s not just about translating your content and adding a nice flag on your icon. You need to get ready to reinvent yourself every time you enter a new market!
The best way of doing this is by avoiding those localization traps that make you spend time and money, without yielding results. To get you started, here are 21 iOS localization traps to avoid in 2017.
1. Creating Your iOS app without thinking about localization
Correct iOS localization means creating a product that’s ready to go global right from the start. When you factor in international expansion from the beginning, rolling out multiple language versions will be much easier. This process is called internationalization. You are basically ensuring that your app is flexible enough to be tailored to any local market. You can stretch the design, change the colors and rewrite the code with ease.
In other words, you should write your app so that it’s easy to translate, even though this will add some initial expense. Separate your text from your code and make sure your programmers use Unicode strings. This is the easiest way to develop an iOS app that can support any language and character. You may not know from the beginning which countries you’re going to target in the future. So, by leaving an open door to modifications, you’ll save time and money when you start the iOS localization processes.
2. Not translating your app’s name when needed
In most cases, it doesn’t matter how cool or interesting a name sounds in English when you take it global. If it isn’t appealing enough for foreigners, there’s no chance your app’s name will sell outside your country.
Your app’s name should be easy to pronounce and recognize. Keeping it short and using clear descriptions of your app is essential. Especially when your products are sold in stores with over 2 million other apps waiting in line! With so many options, customers simply won’t take the time to understand the meaning behind a strange sounding name. They’ll just download something else.
Translating your app’s name is a wise solution, as long as you can keep your brand identity intact. Make sure that the translated meaning is close to your original name, as there’s nothing more frustrating than a misleading app name! The price for this kind of mistake during iOS localization is bad reviews. What do bad reviews lead to? Poor ranking in the App Store.
Before you start to panic, changing a brand’s name isn’t uncommon. Even large companies do it when they switch languages. LinkedIn did it for the Chinese version of their platform, with excellent results. As long as you spend the time to research each individual market, you should be able to come up with a name that will suit their tastes.
3. Using the same icon for all audiences
The average person is exposed to more than 5,000 brand messages and ads every day. Which is an awful lot of competing traffic! How many of these ads and commercial messages get noticed? Around 12. That’s right! 12! With such a miniscule chance for brand visibility, the need to create a strong icon for your iOS app that leaves an impact is higher than ever.
When it comes to iOS localization, your app’s icon plays an important role. People tend to press the download button when they’re charmed by an inviting image, regardless of where they come from. But, keeping the same visual for all markets is risky. Why? Because colors and symbols have different meanings from one country to another.
Of course, any change you make requires significant research and testing. You need to keep your unique identity while still respecting local cultures. Coca Cola had to rethink its logo to sell in China, as the traditional one held no meaning for the locals. Despite translation and use of different symbols, the global manufacturing giant managed to maintain its distinctive features.
You may not have the same kind of budget as Coca Cola, but you can still come up with a flexible plan. Choose an icon without text that uses no religious symbols of any kind. This will save you a lot of trouble when it comes to approaching new audiences.
4. Designing your app for one language only
Your layout may look great in the original version of your app. But you need to consider how it will look when it’s translated to Arabic, French, or Spanish. China has become an important market for iOS apps. So, it’s time to think seriously about creating an appealing design to sell in countries where iOS is particularly popular.
Many languages need more space than English for saying the same thing, as they have different grammar structures and phrases. So, don’t let a nice layout mislead you if it isn’t malleable enough to accommodate foreign text. Keep it practical, or you’ll spend long hours trying to make difficult words and expressions fit the constraints of your original design.
5. Postponing iOS localization
Even if you’re keeping localization in mind from day one, that doesn’t mean much if you’re not doing anything about it. So, make it your resolution to take action in 2017. There’s no better time to start than right now. Every day you delay localizing your app gives the competition more and more opportunity to beat you to the market.
Waiting for important updates, or over-thinking the process are really just excuses. All updates and improvements can still be carried out during the iOS localization process. After all, when you plan for localization from the outset, it’s the easiest way to avoid mistakes.
6. Organizing separate teams within the project
App localization can take weeks, or even months, depending on how fast you move and how willing you are to get involved in the process. Localization is harder if your team doesn’t understand each aspect of your project. You don’t need your translators to be programmers, or your developers to speak several tongues. But, they do need a clear understanding of the role of every person on the team.
Translators often don’t possess much technical knowledge, while programmers usually aren’t aware of cultural differences. Hiring a marketing specialist is a good idea, but you’ll need to use local resources for each market to correctly gauge the audience and new ways of thinking. And you need all these people to come together, if you want things to move smoothly.
Localization requires a lot of teamwork, so be sure to involve all departments. It’s almost like launching your app from scratch, except that you’re doing it for a different audience. And that makes things harder, not easier.
7. Starting without a Localization Manager
Coordinating your localization team is a full-time job. So, if you’re already overloaded with work, you should find someone to oversee the process for you. A good localization manager will work closely with your translators, programmers and engineers. They’ll have a complete view of the project and know how to manage time, budget and resources efficiently. This will free you up to focus on steering your business forward, while remaining in contact with your iOS localization team.
8. Not targeting audiences in each country before starting
Just as you conducted research before launching your iOS app in your country, you’ll need to identify your international buyer personas as well. Find out about potential customers in every new country you intend to launch your app.
What you know about your national audience counts for very little when you go global. Foreigners have different mindsets and buying habits, ideologies and preferences. So, if you want to make them download your app, learn to speak their language like a native.
Correctly targeting audiences is essential for successful app localization. This way, you can send relevant messages to your customers and be sure of higher engagement. If users can easily identify themselves with your product, you’ll increase downloads and positive reviews. This will increase your ranking in local App Stores and generate higher revenue.
9. Using free translation sources to save money
Many small business owners make this mistake, thinking that they can reduce costs. But most of them end up spending more money fixing problems that could have been avoided in the first place.
In 2017, human translation is the only way you can guarantee you’re sending the right message to your clients. Machines can rewrite what you say in any language. But, they lack the ability of keeping the meaning you wish to give to each phrase. In other words, translate by robots and you’ll end up with text that sounds like it was translated by robots.
Your long-studied marketing strategy will amount to nothing if your app’s name and description, or CTA buttons sound odd — or worse — offensive!
10. Not providing your translators with the right context
Working with translators means you’ll have real people choosing the most appropriate words to use depending on each context. So, you’ll need to give them all the details about your app.
Just sending them some texts or strings to translate, without explaining what they’re writing about will create confusion. You’ll end up with a lot of back and forth, making things harder to manage for everyone involved in the localization process.
Translators don’t just convert texts from one language to another. A professional team understands cultural differences, knows about jargon and colloquial phrases, and when to use them to make a difference. They can help you reshape your message to make it sell your product better.
Many translators who provide app localization services are used to working with strings and software. So, by giving them all the information they need, you’ll get the best results possible. This includes uploading screen shots, notes and suggestions, as well as providing them with a list of keywords for your ASO goals.
11. Working without clear goals and deadlines
Even though app localization is a complex process, you should separate the steps and keep track of your progress. If you don’t set clear goals and just wait for everything to be done before evaluating, you risk wasting time and spending extra money.
By allowing your team to work without intermediary milestones, you risk losing control over the process and will delay the launch of your localized iOS app. So, create a localization calendar to follow. This way, you can measure your team’s work while keeping an eye on costs and deadlines.
12. Not using translation management software
If this is your first iOS localization endeavor, you may not know what translation management software is. But that doesn’t make it any less important for your team. By using the right translation management software, you can work efficiently and harmoniously.
No more long email threads and communication errors. Everything they need to know is one click away and they can work easier and faster. The can collaborate on one platform, and even over different time zones. Developers can upload context for translators. Translators can leave explanations. And your localization manager can glean the progress of your iOS localization project with one simple glance.
13. Targeting languages, instead of countries
You’ve translated your iOS app into Spanish and now you feel ready to conquer all of South America. Slow down! Sorry to say this, but that’s the wrong way of going about iOS localization. Each country is different, so keep that in mind when localizing your app. Mexicans use different vocabulary from Argentinians. Customers who live in Costa Rica don’t share the same climate as those in Europe.
Just think about the English language. If you’ve ever shared a conversation with an Irishman, South African, or Australian, you’ll know that even when speaking the same language, there’s a lot of scope for misunderstandings!
14. Ignoring cultural factors
Our vision of the world is made up of clichés. The French love garlic. The Spanish dance Flamenco. Argentinians can’t get enough of eating beef. While there may be some semblance of truth about some of these beliefs, most of what we know about specific countries is actually untrue. Assuming that you know about a culture because you watched a television program about it isn’t going to cut it.
You’ll need to go deeper into the local market to give your customers a positive user experience. Adapt your content to the cultural differences in each country to become successful in local markets. Humor, relationships, etiquette and societal values vary from one region to another. Ignoring these essential differences will almost certainly transform your investment into failure.
15. Skipping marketing localization
Knowing the local market will be a necessary advantage when you launch your app in a new country. iOS localization should involve a marketing expert from day one, to make sure you invest in the right modifications. Translating keywords is better than no strategy at all, but that alone isn’t going to boost your downloads.
You’ll need to see what works in each specific country and optimize your content for each local market. Come up with a flexible ASO strategy, with new descriptions and meta data that work for each individual market and local media.
There are hundreds of new iOS apps in the App Store every day. So, you’ll need to get yours right if you want to get noticed and increase downloads and sales.
16. Underestimating your competitors
2017 is set to take app localization to the next level. Even the smallest developers will localize their apps to increase their revenues. And they’ll find new ways of making themselves known globally. Your competitors are going to be everywhere, so you’ll need to step up to the plate.
You’ll also have to deal with local iOS app developers, who have the advantage of knowing the local market better than you do. So, don’t ignore the competition. Don’t put together a strategy as if you were the only player on the market. Learn as much as possible from your competitors so that you can become better than them.
Make sure your team knows all about different local app stores. What apps are popular, why people download them, how many positive reviews there are and what features generated them. Use all these insights to improve your product and marketing strategy, to get more 4 and 5 stars reviews and increase your position in the App Store.
17. Not translating everything
You’ve probably already realized by now that app localization means more than translating names, descriptions and screenshots. You need to translate and localize everything for your audience. Customers will feel tricked if they download an iOS app with an enticing description they completely understand, only to receive a download that’s only half translated.
You may save money and time by not translating all maps, error messages or feedback requests. But this will soon come back to you like a boomerang, with negative reviews and unsatisfied users. Don’t forget that almost 90% of apps are deleted as fast as they’re downloaded. If yours doesn’t live up to expectations, it will be wiped out of your user’s memory in instants.
18. Not working with a local team
No matter how effective your localization team is, you’ll need a “local touch” to obtain useful feedback. Local experts can easily identify any unnatural sounding words you’ve used during translation. They can also provide you with important advice about how to approach your audience.
Another great advantage when working with locals comes from the fact that you get an accurate idea about legislation. It’s hard to keep track of all legal modifications, especially in countries where new laws don’t make the international news. A local team will always know what’s new in the field and keep you away from unwanted legal issues.
19. Using the same content for all countries instead of encouraging local contributors
When you promote your iOS app, you’ll need content outside of your app. That includes a website and a consistent presence on popular social media channels. You’ll need to customize your content across each different region if you want your brand to resonate in local markets.
So, work with transcreation professionals or local writers who can craft an appealing message, rather than a translated one. This is particularly useful when considering seasonal promotions or local public holidays. This will help you obtain higher engagement from your audience. The key is to maintaining a consistent message in keeping with your brand identity.
20. Not evaluating all costs before starting
Localization isn’t cheap. So, when starting your iOS localization project, make sure you include all expenses, not just what you’ll pay for translators. You’ll need programmers, a local team, testers, and a marketing campaign to promote your app in the new market.
Set a clear cost structure from the beginning. This way, you can calculate a budget and, depending on your resources, decide on the dimensions of your iOS localization project.
21. Launching your app without testing it
Testing may mean additional costs. If you’re working on a low budget and already missing a deadline, you may feel tempted to skip testing. But hoping that all translations and technical details match your standards (and your customers’) isn’t a good idea.
Getting feedback before the actual launch is essential, as there’s no second chance to make a first impression. All your hard work will be in vain if your foreign users download an app that fails to meet their expectations. So, test everything, from texts and customer care, to compatibility with all Apple mobile devices. Fix any problems that appear before your app comes out.
iOS localization is not as complicated as it looks. With the right team and the right tools, you can conquer global markets. The most important thing is to spend less time thinking about it and more time acting on it. Every day you fail to start your iOS localization strategy means more money that will go into someone else’s pockets.
We use cookies to give you the best experience on our website. By continuing to use this website, you consent to our use of these cookies.ContinueRead more
‘Google doesn’t always have the nuances necessary for correct translation.’ Photograph: Graham Turner for the Guardian’
