Should translators be coders?

Specialization is the key. You will never ask a dentist to fix your car, or a plumber to write a poem to your sweetheart. You may do it of course, but the result you’ll get can be somewhat “discouraging”. Still, when it comes to the translation industry, the situation is quite the reverse. Translators are often offered tasks they haven’t – and aren’t meant to have – skills to cope with. I don’t know why this is happening, but this was actually the thing which happened to me this month.

I translate games to Russian. At the beginning of May I was approached by a video game publisher with an offer. They’ve shown me quite an interesting turn-based strategy, which was really worth to be translated – it had cool mechanics, pleasant graphics, etc. Actually, I fall in love with it. (You know, we the Russians, love strategies… that’s why we shall dominate the world someday, ha-ha).

So, we discussed the price and the details, and confirmed our willingness to work together. I asked them to give me the game text in EXCEL, said “see you” and switched to other important activities… Three weeks later I received the game text. It was seven JSON files.

We’ll make it clear now – I’m not against of diversity. All the file formats: DOC, PDF, JSON, LUA, XLS, PPT and sometimes even SDLXLIFF have equal rights to be translated. But promoting diversity should be a common cause for both translator and developer, because handling JSON files is not an easy task – even with Okapi filters.

When I applied Okapi filters and OmegaT parsed the files, I saw the text. And it frightened me. The text was split into blocks, consisting of three elements: a string identifier, a localized string of German text, and a string with the English source text itself. So, I’ve got quite a mess to deal with.

The challenges

I faced three challenges. First of all, I had to calculate the word count. A simple task, but I had to use my grey cells. If you look at the image, you’ll see that it’s only the third segment which has the English source text. The only thing I had to do – was to copy the strings to EXCEL from OmegaT and to remove the two strings in each block. That’s how I’ve got the word count. The only thing I feared was… what if I missed something, somewhere in all this JSON code? Alas, there was no way to check this.

My second challenge was to translate the English source text only (and to skip German text and string indetifiers). Quite a simple task. I already had the English strings exported to my EXCEL file, which meant that I could translate this very file first. Then, with TM saved to OmegaT, I could open the original JSON file and use my translation memory to instantly translate the English source text. And when it’s done, I could check the JSON file for missed strings.

However, the third challenge was impossible. When I looked at the JSON file, I realized that each block had a separate string for each language. It was like this:

And to make a Russian localization, I had to add a third string with Russian translation to each block:


“english” : “source text” //the source text

“german” : “translated text” //translated German text

“russian” : “translated text” //translated Russian text A simple script could help me… but I’m not a coder. And doing the job manually… well, no, thanks.


I honestly told the client about the challenges, as well about how much should they pay me for handling their JSON files. And I’m still waiting for their answer.

It’s my firm position that each side of localization process should do their job. Translator should translate the text, and developer should provide the text in a suitable form (let alone implementing the localization).

I advise game developers to listen to what translators ask from them, as well as to do their part of the job properly. This is the only way to translate a game.