The Translator’s Technology Toolkit: 13 Core Skills

Translator technology skills form a broad field covering everything in a translation job that lies outside the language itself. Being able to open the file, extract the text correctly, draw on earlier translations, keep terms consistent and make sure the delivered file behaves in the same way as the source all belong to this field.

Contents

These skills are usually referred to by the name of a single piece of software. Yet tool names change and the skills remain. Someone who understands how a translation memory works applies the same logic whichever program they use.

Below we have gathered this field under thirteen headings. The list is not quoted from any standard; it is a grouping of our own, drawn from the tasks met in everyday translation work, and it is ordered for ease of reading.

Why think of it as a toolkit?

The toolkit analogy is useful because a carpenter does not use every tool on every job. In the same way, a translator does not bring all thirteen skills into play on every project. What matters is knowing which tool is needed when the work arrives.

The second benefit is that it makes gaps visible. When the skills are not listed, a translator does not notice their own gap; faced with a file format, they turn the job down and explain the reason to themselves as not liking software. In most cases, though, the problem is that one single operation is unknown to them.

The third benefit has to do with the order of learning. The skills come in layers that build on one another. For someone who does not understand file formats, translation memory remains an abstract concept. Skip a step in the sequence and the learning stays superficial.

The fourth benefit is on the client side. Knowing which skills a supplier has also determines what work you can give them. A file that arrives as a scanned PDF calls for a different skill set from one that arrives as plain text.

The thirteen core skills

We have ordered the list from the first skill to the last, following the path a file takes from reaching the translator to being delivered.

1. Operating system and file management: folder structure, extensions, backup.
2. Advanced use of a word processor: styles, tracked changes, field codes.
3. Spreadsheet use: for term lists and multilingual strings.
4. File format literacy: PDF, XML, HTML, XLIFF and the logic of tags.
5. Turning a scanned document into editable text with OCR.
6. Setting up, updating and maintaining a translation memory.
7. Reading match rates and interpreting the analysis report.
8. Building a termbase and holding consistency across the project.
9. Turning old translations into a memory through alignment.
10. Running automated quality checks and being able to sift the warnings.
11. Assessing machine translation output and carrying out post-editing.
12. Source research: using corpora, parallel texts and reliable dictionaries.
13. Data security: deciding which text may go into which environment.

File and format skills

The first five items on the list look unrelated to translation. In practice this is the stage of a project that loses the most time. If the source file is broken, the translation never even starts.

The most common problem is scanned PDFs. In these files the text is in fact an image; it cannot be copied, counted or taken into a memory. OCR gets past this obstacle but is not flawless; in Turkish texts, dotted letters and the apostrophe are often corrupted, so the OCR output has to be checked against the original by eye.

The second problem is tags. Web content and software source files are full of formatting tags. Moving a tag to the wrong place breaks the page or stops a button working. Understanding the logic of tags does not call for writing code; it calls for recognising what must not be touched.

The third problem is the word processor itself. Documents formatted by hand without styles produce needless segment breaks when they are taken into translation tools. In a document where the headings have been made with capital letters and spaces, the tool does not see the heading as a separate sentence. A clean source file is half the translation.

The fourth problem is numerical and tabular data. Multilingual strings held in spreadsheets vanish silently when they are written into the wrong column. When working on files of this kind, preserving the row identifiers is a more critical operation than the translation itself.

Memory and terminology skills

The group running from the sixth item to the ninth is the core of translation technology. A translation memory stores sentences translated earlier and offers them up when a similar sentence comes along. A termbase, for its part, holds consistency at word level.

The value of this group is directly related to the repetition rate of the text. According to industry measurements, the proportion of entirely new words in translation projects is around 59 per cent; the remainder can be reused in some form (DePalma 2012). Seeing that share requires reading the analysis report.

The alignment skill turns old translations sitting in the archive into something valuable. Source and target text are matched sentence by sentence and converted into a memory file. This operation usually calls for manual correction; automatic alignment needs more intervention in languages such as Turkish, where sentence boundaries shift.

This group has its risk too. Relying too heavily on the memory can lead to not questioning whether the suggested translation fits the context. Bowker (2005) calls this blind faith in the translation memory. The skill is not accepting the suggestion but being able to reject it when necessary. Memory maintenance is therefore as important a habit as using the memory: once a faulty translation has entered the memory, it repeats itself on every new project.

Machine translation and security skills

The last group holds the skills at the centre of the current debate. Assessing machine translation output requires telling where the output is reliable and where it is not. A fluent but wrong sentence is more dangerous than a broken and plainly wrong one.

Post-editing is not ordinary proofreading. How much intervention there will be is defined at the outset. Light post-editing aims at comprehensibility, full post-editing at a publishable text. The two differ in the time they take and in what they cost.

The thirteenth skill is less a technical skill than a matter of judgement. Whether a text can be entered into a free online engine depends on the confidentiality status of that text. The terms of use of free services may carry broad licence rights; the worldwide licence wording in Google’s 2016 terms is a frequently cited example (Novović 2017, p. 202).

Some tools warn the user about this. memoQ, for instance, shows a warning dialogue about sending content containing personal data to external engines (Pietrzak and Kornacki 2021, p. 25). Reading the warning is a skill in itself.

How is skill level measured?

To gauge a translator’s technology level, talking through concrete tasks is more reliable than looking at a list of certificates. The table below separates three levels.

Level	What they can do	Typical limit
Basic	Translates and delivers a ready-made project handed to them in the tool	Turns the job down when a broken file arrives
Intermediate	Sets up their own project, manages the memory and the termbase, reads the analysis report	Struggles with complex tagged formats
Advanced	Prepares files, aligns, writes quality check rules, designs the workflow	Subject expertise is still needed separately

The table is not a hierarchy but a matching tool. For a short one-off document, the basic level may be enough. A product catalogue that is updated continually, on the other hand, calls for the advanced level.

The most practical way to gauge the level is to ask a single question: what was the last technical problem you ran into, and how did you solve it? If the answer contains a concrete file, a concrete error message and a concrete solution, the skill is real. If the answer stays at the level of generalities, the list may simply have been memorised.

The Türkiye context

In Türkiye, most translation and interpreting programmes and translation studies programmes include a translation technology course; but because the course lasts a single semester and depends on the availability of a laboratory, the depth of practice varies from programme to programme. Graduates often go on learning on their first real project.

The technical problem most often met in the local workflow is that official documents circulate as scanned PDFs. In notarised work the original document is on paper; the digital copy is usually an image. OCR and the skill of rebuilding formatting therefore occupy a more central place in the Türkiye market than might be expected.

The agglutinative structure of Turkish also changes the order of the skills. Termbases can struggle with stem matching because of inflectional suffixes; when a term list is being prepared, root forms and common suffixes therefore have to be thought through together.

On the data side, the KVKK ties the thirteenth skill directly to a legal obligation. The environment in which documents containing personal data are processed is no longer a matter of preference but a matter of contract. This article is for general information only and is not legal advice.

What does this mean for you?

These thirteen skills determine how much work your supplier will leave on your hands. A supplier weak in technology skills will do the translation but leave the formatting to you; the price difference you thought you had gained turns into hours of your own team’s time.

When assessing a supplier you can look at the following: do they want your source file in its original format, or do they expect you to copy and paste the text? Do they provide an analysis report for your repetitive content? Who keeps the term list? When you ask for the memory file, can you get it?

The answers to these questions make a difference on the second and third project rather than the first. With repeating content, consistency and cost both improve thanks to the memory that has built up. We have summarised how we work on our services page; if you would like to see which skills your own files call for, you can share a sample document through the quote form.

Frequently asked questions

Do you need to know programming to be a translator?

No. But regular expressions, a basic grasp of tag logic and a knowledge of file formats make the work markedly easier. These are not programming; they are skills at the level of literacy.

Which translation tool should I start learning?

It makes sense to learn the most widespread tool family on the market; in the case study, SDL Trados holds a 43.3 per cent share and memoQ 29.1 per cent. But because the logic is shared, everything after the first tool is learned quickly.

Do technology skills improve translation quality?

Not directly. They improve consistency and delivery speed, and they free up time for quality. No tool will correct the mistake of a translator who has misread the source text.

How can I tell what a translation supplier’s technology skills are like?

Look at whether they want your source file in its original format, whether they keep a memory and a term list, and whether they explain in writing where your data is processed.

Sources

• Pietrzak, P. and Kornacki, M. (2021). Using CAT Tools in Freelance Translation. London: Routledge Focus, pp. 25, 83; Table 6.2.
• Bowker, L. (2005). Productivity vs Quality? A Pilot Study on the Impact of Translation Memory Systems. Localisation Focus, 4(1), pp. 13-20.
• Novović, A. (2017). Confidentiality Issues in Machine Translation. Hieronymus, 4, pp. 195-210.
• DePalma, D. (2012). Translation Productivity Benchmarks. Common Sense Advisory report.