Are you a project owner, project manager, or developer? Follow these 6 simple rules to avoid common mistakes in localization projects.
Freelance localization specialist or big localization agency?
Unless you are a multinational corporation with dedicated purchasing departments and processes, hiring a freelancer to localize your website or app is a great idea. Especially when you run a startup or a small-to-medium-sized business.
Working with a freelancer:
- cuts costs (no middlemen = no fees)
- saves time and effort (lets you bypass some of the agency processes)
- is more personal (and personalized)
However, there are some pitfalls I’d like to help you avoid.
1. Always Hire a Professional Translator
Never assign a translation or localization project to a member of your team, be they a web developer or a marketing specialist. Even if they speak the target language, they simply… can’t translate. Just as a translator can’t write code.
They wouldn’t be able to tackle all the issues localization faces, such as picking the right tone of voice, recognizing cultural nuances, or creating claims and puns.
Therefore you may want to recruit:
- a native speaker (or a person with near-native skills, perfectly familiar with the cultural, social, and business context of the target country)
- someone with copywriting skills and with demonstrated experience in transcreation, copywriting, or marketing translation
- a tech-savvy person, familiar with interface design tools, SEO, UX, keyword tools, work-sharing tools, testing tools, etc.
It’s like chasing a purple squirrel, huh? It doesn’t need to be. Prioritize: choose two to three top skills most crucial for your project. Being a native speaker solves nothing if your translator has zero knowledge of website architecture or can’t handle project communication.
Hiring a meticulous proofreader to collaborate with your translator is always a good idea.
2. Start With the Brand
Already picked a translator? Let them see the bigger picture:
- Introduce your brand. Have a brand book or a style guide? Show them!
- Explain what your company/product name stands for. Ask for tips: is it suitable to translate it or leave it as is? Will it sound funny, ridiculous, or obscene when translated? Any unwanted connotations? Any competitive products or services of the same name in the target country?
Most of you have probably heard of the legendary Dombås and Godis Skum, but brand localization fails happen in real life, too! Recently, a client of mine confessed that they failed to do some research before hitting the Polish market with their B2C app. Its Polish name has that undesirable aura of the oldest profession in the world and customers get confused… but it’s too late to localize.
3. Waterfall or Agile?
As long as your project consists of one localized product, you’re on the safe side. Still, think your strategy through and:
- prioritize (website or mobile app first?)
- schedule (translation ➝ proofreading ➝ QA testing ➝ fixing ➝ QA testing ➝ launching)
While smaller localization projects usually implement the waterfall methodology, you’ll probably rely on the agile if your company develops several interconnected products. That may complicate things.
Just a quick example:
Web App #1 and #2 are two different products, but they are bound together by their landing pages and user accounts. Moreover, Web App #1 has a mobile version, while Web App #2 has its own dedicated product site, consisting of a user guide, subscription options, corporate blog, etc. (with screenshots from the app).
Since your team develops its products on the go, the localization project recurs in cycles, too. But make sure you maintain a logical workflow within each cycle. When a new feature comes to light, start with WA #2, then go to WA #1, continue with MA #1, and finish the process with PW #2.
Unless you enjoy splurging your money on endless re-translating, let your translator know how many products you intend to have localized and what they share in common!
4. Mind the Input
Unless your website is really small (a few pages), resist the urge to put all the content in one massive file. Rearranging phrases in alphabetical order is a big no-no, too, as it kills the natural context of the site.
Instead, divide source text into separate files, each covering a specific part of your website/app:
- homepage
- products/services section
- contacts
- user notifications
- user account section
- forms
- messaging
Discuss the file format with your localization specialist.
Time invested in prepping the input file(s) considerably decreases the time spent on testing (see paragraph 6).
5. Never Use Google Translate
Happens all the time. Once the translation is put on the website, a developer realizes that some CTA buttons, URLs, or pieces of content in the target language are still missing. It’s easier to hit Google Translate than contact the Human Translator, isn’t it?
Then the HT tests the website and stumbles upon a nonsensical phrase, thinking, “I must have been out of my mind writing this one.”
Rummaging through a website/app in search of those scattered mistranslated phrases is like looking for a needle in a haystack: even if you do find it, it hurts and takes a lot of time to boot. Time the translator is paid for.
So, if you are an IT person reading this, I suggest that once you come across some missing content, make a list of un-translated expressions and send it to the translator/proofreader instead of translating it on your own, so they don’t need to double- and triple-check everything they had written before.
6. Get It Tested
At least twice. I’m not talking about UX testing, A/B tests, etc. Language testing and proofreading the implemented content is a must.
The translator/proofreader hunts for and gets rid of:
- typos, grammatical errors, stylistic errors, etc.
- mistranslated phrases (context is everything)
- un-translated, passed-over phrases or pages
- obscure, clunky, or vague formulations
- inconsistencies in terminology, style, or tone of voice
- fluff
- content overflowing its dedicated space (a button or tab)
- broken internal or external links
Language testing gives the localized website a nice finish and makes it work.
Are you ready for your next localization project?
Feel free to message me if you need some help with it.