Top 5 Reasons Why Localization Used to be a Pain
Web or mobile app localization used to be a pain. In all likelihood I am not telling you anything new, either. But why is that? For the longest time, software developers have optimized all kinds of processes in their work (the lastest being version management, which with GIT has been so successful it has entered other industries as well, such as natural sciences, writing and lawmaking).
One aspect that is still treated with a good dose of disdain is localization. If you've used a decent localization management tool (such as LingoHub), you know that most of these fears are vastly overblown. Today, localization is a smooth and easy-to-integrate part of the dev cycle. If you're nostalgic, let's look back at why it used to be a pain.....
Reason #1: Dealing with Files
The main problem used to be emailing files back and forth. You sent resource files to a translators or an agency, and waited for it to get back. You would have to do that for each language, and each part of your application. Emails would land in spam folders, translators might use providers that offered limited storage space, using an email inbox to organize files is also not most convenient. So in the end you resorted to Dropbox, an FTP server… or you sent a DVD?
The secondary (but related) problem was formatting. You either converted the text to Excel sheets before you sent the text, and then had to re-format upon delivery -- or the translator/agency tampered with the formatting, causing errors or rendering the file useless (which can easily happen, for example with indenting in YML files or if word processors are used that changed the text encoding). So in the end it caused lots of work to fix this up.
Reason #2: Lack of Context
Another bother that led to phone calls and more emails was lack of context. Is a certain text segment a text representing a button, a menu entry, a mouse-over text, a label or something else? How does one text fit into other parts of the product, what comes before or after it? Does the translator/agency even have a way to see how the product even looks like? Explaining the context of a product either requires a high degree of work before the translation process (proper documentation, graphics, etc.) or it causes an overhead in repeated conversations between the dev team and the translation team.
Reason #3: Dealing with Versions
Making reason #1 even worse was versioning. An aspect of your application changed, and you end up with a new resource file. You have to sent that to the translator/agency, or just the changes? In the end, which file is the latest, how will you merge it? Had anyone considered the nuisance on part of the translator? What if things go untranslated because in the mix up of all the different versions of a file, nobody could keep track of what really goes on. The amount of trouble different file versions cause is enormous. You can see how products like Google Docs have eased collaborative editing in office environments, this has decreased the amount of competing files sent around within a team.
Reason #4: Collaborating with Teams
As if all that wasn’t enough, multiplied by language, in order to cope with a project more people are involved. Your co-workers, marketing people, front-end developers, one or several translators, reviewers…. how to keep them all in the loop, how to ensure that we don’t run into problems 1, 2 and 3 for each person working on the localisation project? It was tedious. You need to cut down on the email traffic anyway, and where it gets troublesome is when everyone gets put in CC even though not everyone in the conversation is really involved in a certain question. How are roles distributed and can those be implemented technically on a platform in terms of editing privileges?
Reason #5: Scaling
Take all previous reasons together, along with some related trouble you might think of, and multiply those by the number of languages you want to translate your app into, and multiply by the among of people working on your product, or the variations of your app, number of resource files, and so on. Localization used to scale extremely badly.
Getting software localization right
Localizing your mobile or web apps today is a different process from how it was some years ago: tools allow you to integrate, they are collaborative, unnecessary work is automated. File handling is no longer an issue, as tools like LingoHub integrate with your file repositories and let you manage most tasks via API or UI. This also means you can avoid touching files altogether, eradicating the formatting problem completely, as correctly formatted files are imported and exported throughout the whole process. Contextual problems might never be completely solved, but we are getting very close to providing maximum amounts of context to translators. Screenshot attachments, meta information, commenting systems, quality checks, there are a lot of factors that can give translators a better overview of what text will mean in the context of the final product. Versioning is hardly a problem anymore. Take two-way Github sync on LingoHub for example: If there was a change to a resource file in your repository, LingoHub will detect it, notify translators of new text segments. These can then be translated, and the complete resource file will be pushed back to the repository. No sweat. Collaboration is the secret sauce. Once chaotic email traffic is out of the equation, working together on a web-based platform becomes a true godsend. On LingoHub, and that goes for some other tools as well, you would assign various roles to team members, set permissions and see your project nearing completion without major headaches. Project managers have an overview of what is happening, who is doing what, and what the available capacities are. Lastly, scaling. Once above described problems subsede, overhead decreases to a minimum. Now the question is, what if you add team members, translators, additional languages, more modules to your project. Does this increase the organizational burden or will it seamlessly extend your workflow without breaking it? On LingoHub, we experience the latter. Careful planning provided, projects scale easily up (or down), as the platform automates all the overhead tasks that used to make localization such a pain. It's a brave new world!
This blog post was inspired by this one.