Where does translation fit into your workflow? If it’s tacked on the end or floating on its own somewhere off of the critical path, you might dread arriving at that last step and ordering translation. But what if you could eliminate not only that stress, but also some of the time and money spent translating your product? Incorporating translation earlier in your process is more relevant than ever as we move beyond translating straightforward documents and work with dynamic content on software, websites, and mobile applications.
The word of the day for your development team is internationalization. It’s a long word with different definitions depending on who you’re talking to, but we like to think of it as simply “keeping translation in mind”. It’s like planting the translation seed early in the spring – you may not see any benefits at first, but come summer (say, translation, testing, or even product launch stage) internationalization bears fruit. By integrating principles of internationalization into your workflow from the beginning, you ensure that some of translation’s most frustrating challenges will not seriously disrupt your timeline down the road. Here are the top five content-related strategies you can apply to your next project:
1. Anticipate text expansion. While it’s true that some Asian languages will actually contract your content and save space, you can expect a Romance language like Spanish to expand by 20% or more! This has the potential to wreak havoc on a carefully designed layout in English, be it on a website or PDF. To solve the issue, try to avoid scrunching English together (for example, in small call-out shapes or page margins), instead allowing buttons to expand dynamically, and coaching your graphic designers on the perils of expansion so they know what to expect.
2. Run pseudo-translation before human translation. Pseudo-translation replaces source content with nonsense foreign characters, helping you preview what expansion might do to your interface while also flagging any encoding bugs preventing special characters (like accent marks or umlauts) from displaying correctly. As an added bonus, any strings still in English will stick out like a sore thumb. Then all you have to do is figure out why - were they not linked correctly? Or perhaps they are still written into the page’s code instead of an externalized library? (See below.)
3. Treat English as another locale. Back in the day, your application might have had one version in English, another in Spanish, another in Chinese, and so on. If you updated the English version, guess what, you had to go into the Spanish version and manually find the same content to edit. You can imagine how quickly this got out of hand! There is one simple thing you can do to anticipate growing your application (or website, in some non-HTML cases) in other languages: treat English as just another language option by externalizing it into a locale file, meaning that an English sentence is replaced by a string identifying it. The same string can then be used to pull that sentence in the language selected by the user or the user’s device settings.
If all source content is externalized, you won’t need to modify any file but the locale files when performing basic content updates. You probably already externalize your source at least in part when writing many applications – the key, however, is to have all content externalized, not just some. (By the way, this method works for images as well, allowing you to localize every aspect of an interface to your target audience!)
4. Avoid Concatenation (a.k.a. composite strings). Concatenation is a neat trick to embed variable material within static material in an application or on a website. One example might be, “You are the 100th visitor to this site!”. A common practice in many programming languages is to have three separate strings: “You are the”; “[variable number]”; “visitor to this site!” or a command inserted, “You are the [variable number] visitor to this site!”. It looks great in English. But what about other languages? You will most likely run into languages with totally different rules regarding syntax and word order, not to mention cases that change the spelling of a noun or adjective depending on the content of the sentence! Suddenly, your well-written English shows up garbled in French, and just plain wrong in Polish.
To avoid concatenation, you will need to make sure that each string represents a full sentence or phrase, not a fragment. If you have a limited number of variables, each variable should have its own full string. To solve the example above, you might try: “Congratulations, you are visitor number: [variable number]”. The content of the string stays together and the variable is isolated, leaving little possibility that it will affect the meaning of the sentence it comes after.
5. Context is gold. Reference images, previews of the application, user stories, and other bits of context are invaluable to translators working their way through a long JSON or PO file. The more context the linguist has at the beginning of the project, the less time they will spend puzzling over isolated words, calling with questions, and testing after the translated versions are up and running.
Keep these tenets of internationalization in mind, and you are sure to benefit the next time you prepare a website or piece of software for translation. Not only will it smooth out the entire process, but your developers, linguists, testers, and project budget will thank you.