Top 5 reasons why localization used to be a pain

Web or mobile app localization used to be a pain. In all likelihood, we are 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 latest being version management, which with GIT has been so successful it has entered other industries, 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 remember 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 translators or an agency and waited for them. You must do that for each language and each part of your application. Emails would land in spam folders, and translators might use providers that offered limited storage space. Using an email inbox to organize files is also not the most convenient. So, in the end, you resorted to Dropbox, an FTP server… or 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 quickly 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 the 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 what the product looks like?

Explaining the context of a product either requires a high degree of work before the translation process (style guides, 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 ended up with a new resource file. Do you have to send all 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 the part of the translator? What if things go untranslated because, in the mix-up of all the different versions of a file, nobody can 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, to cope with a project, more people are involved. Your co-workers, marketing people, front-end developers, one or several translators, and reviewers? How to keep them in the loop? How to ensure that we don't run into problems 1, 2, and 3 for each person working on the localization 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 involved in a specific 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 number 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, and 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 solved entirely, but we are getting close to providing maximum context to translators. Context images, style guides, term base, description, and many other Lingohub features can give translators a better overview of what text will mean in the context of the final product.
• Versioning is hardly a problem anymore. Lingohub supports GitHub sync on Lingohub (Git branching as well). If there is a change to a resource file in your repository, Lingohub will detect it and notify translators of new text segments. These can then be translated, and the complete resource file will be pushed back to the repository.
• Collaboration is the secret sauce. Once chaotic email traffic is eliminated, working together on a web-based platform becomes a godsend. With Lingohub, you can create and 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 the available capacities. You can also discuss any question in the Lingohub interface without using the external tools.
• Scaling. Once the above-described problems subside, the overhead decreases to a minimum. Now, what if you add team members, translators, additional languages, and more modules to your project? Does this increase the organizational burden, or will it seamlessly extend your workflow without breaking it? With Lingohub, you shouldn't care about this. The platform allows localization in the CI/CD process to be involved and quickly scales the entire process.