Hiring localization staff: what your first in-house hire should do

Most studios do not decide to hire a localization person. They discover they need one — usually the week a build ships with the previous version's text in one language, or the week a producer works out that they spent three days of a milestone chasing invoices and file handoffs instead of running the milestone.

Up to that point the work has been absorbed. Someone in production emails the vendor, someone in engineering imports the files, someone who happens to speak the language reads a few lines before release and says it looks fine. That arrangement holds for roughly one title and one or two languages. Past that, localization stops being a set of favors and becomes a function — and a function with nobody accountable for it fails in ways that only surface after release.

This article is about the hiring decision itself: which of the several jobs bundled under the word localization you are actually hiring for, how to draw the boundary between the new role and the partners you already use, and what to look for once candidates are in front of you.

Four jobs, one job title

On an org chart, localization usually covers four distinct jobs that happen to touch the same text. They call for different skills, and a candidate who is genuinely strong at one can be weak at the others without that being a flaw in them.

• Coordination — scoping batches, briefing translators, scheduling around text freezes, answering queries, chasing deliveries
• Linguistic quality — producing or judging the target text itself, and holding voice and terminology consistent across a title and its updates
• Localization QA — playing the localized build and reporting what is wrong on screen, which is not the same as what is wrong in the file
• Localization engineering — the export and import pipeline, file formats, encoding, fonts, layout behavior, and the automated checks around all of it

When coordination is missing, nothing looks broken day to day. Work simply goes late, gets duplicated, and arrives with questions nobody answered — and the cost shows up as a language that slips out of a release, not as a defect anyone can point at.

When nobody owns linguistic quality, you are trusting each vendor's own assessment of their work with no way to compare across languages. That is survivable for one language you can read internally and risky for the ones you cannot.

When LQA is missing, text that reads perfectly in a spreadsheet ships clipped, overlapping, or attached to the wrong screen. When engineering ownership is missing, every release includes a manual conversion step that exactly one person understands, which is fine until that person is on leave during submission week.

Your first hire is probably not a translator

The instinctive first hire is a translator — someone who can produce the language you need. It is usually the wrong first hire, for a supply reason rather than a skill reason. Translation capacity is available to buy: freelancers and agencies exist in every language you are likely to want, and you can scale that capacity with your release schedule. Coordination capacity is not purchasable in the same way, because it depends on knowing your game, your build process, and your calendar.

A studio that hires a translator as its entire localization department gets one language covered well and every other part of the job squeezed into the gaps between translation work. The translator ends up scheduling, chasing, and importing files — tasks they were not hired for and often do not want — while the skill you actually paid for sits idle for every language they do not speak.

There is a real exception. A live game with continuous updates, one dominant target language, and a distinctive voice worth protecting is a case where a staff linguist who lives inside the game every day beats any external arrangement, and where the coordination load may be small enough for production to keep absorbing. Recognize that as a specific situation rather than the general rule.

Draw the boundary with your partners before writing the job description

The shape of the role depends entirely on what stays outside the studio. Settle that first; the job description is downstream of it. Five questions decide most of it:

• Who translates — freelancers you contract directly, one agency across all languages, or a different arrangement per language?
• Who judges translation quality, and does anyone inside the studio have the ability to judge it at all?
• Who runs LQA, and on whose builds — yours, a testing partner's, or as part of platform submission?
• Who owns the export and import pipeline and the checks that run on it: this new role, or your existing engineering team?
• Who is accountable when a language slips — the vendor, the new hire, or production?

Two very different roles come out of those answers. If vendors translate and review while your engineers own the pipeline, you are hiring a coordinator whose value is judgment, communication, and control of the calendar. If you intend to bring review and pipeline work inside, you are hiring closer to a hybrid producer-engineer, and that candidate pool is smaller and more expensive.

Neither is the wrong choice. Hiring for one and then quietly expecting the other is, and it is the most common way a first localization hire ends badly.

What the job description has to say

Localization job descriptions are unusually vague as a category, and vague ones attract either vendor-side veterans who will be bored within a year or people who have only ever translated. Specificity is the filter. An outline that works looks something like this:

Role: Localization coordinator (first localization hire)

Context
- 2 titles live, 1 in production; PC and console
- Ships in 6 languages today, 2 more planned next year
- Text lives in engine string tables, exported to CSV for vendors
- Weekly patches; text changes after freeze on roughly every other release

Owns
- Batch scope, schedule, vendor briefing, query handling
- Freeze dates and the exception process for post-freeze changes
- The localized-build check before every submission

Advises (does not own)
- Which languages we add next
- Rates and vendor contracts

First 6 months, realistically
- Document and stabilize the export/import round-trip
- Establish one glossary and one query log across all vendors
- Run the first structured LQA pass on the titles already shipped

Two parts of that outline do more work than the rest. Separating what the role owns from what it advises on prevents the most common early failure, where a coordinator is held responsible for a slip they had no authority to prevent. And describing the first six months honestly matters, because the opening months of a first localization hire are rarely glamorous: they are pipeline archaeology, glossary building, and finding out which languages nobody ever verified.

Be careful with language requirements. Asking for fluency in three languages filters out excellent coordinators and selects for translators, which is the hire you decided against two sections ago. The genuine requirement is usually working fluency in whatever language your team and vendors communicate in, plus enough familiarity with at least one target language to recognize a bad file when one arrives.

What to look for in the interview

The most informative question is to ask a candidate to walk you through one localization round-trip they personally ran, end to end, on a real project. Do not interrupt to steer them. You are listening for whether certain things appear without being prompted:

• Context — what they sent translators besides the strings: screenshots, character notes, a glossary, an explanation of where a line appears
• Queries — that translators asked questions at all, and what happened to the answers afterwards
• Freeze — that text stopped changing at some point, and what was done about the changes that arrived after it
• Verification — that somebody opened the build in each language before it shipped
• Failure — something that went wrong, and what they changed so that it would not recur

A candidate who describes only the file handoff — sent the file, got the file back, imported it — has done the mechanical part of the job and may not know the rest of it exists. That is not disqualifying for a junior hire, but it tells you how much of the function you are still carrying yourself.

A second useful exercise is a short artifact review. Hand over a spreadsheet of twenty translated strings containing a few deliberate problems: a placeholder that changed form between source and target, a line far longer than the UI slot you describe to them, a term rendered two different ways, and a row where the translation is identical to the source. Ask what they would do about each and in what order. The prioritization tells you more than the spotting does.

Finally, ask what they would do if a vendor delivered exactly on time and the text was bad. The answer separates people who manage schedules from people who manage quality. A good one involves evidence, a specific description of what is wrong rather than a general complaint, and a conversation with the vendor — not silent acceptance, and not a unilateral swap that leaves the same problem in place with a different supplier.

Setting the role up so it does not fail quietly

A first localization hire fails in a predictable way: they are made responsible for outcomes they cannot influence, spend a year firefighting, and leave with the same pipeline they inherited. Four things prevent most of that.

• Authority over dates. If the role can request a text freeze but not hold one, the freeze does not exist.
• Access. Builds, the string files in version control, the store back end, and the vendor relationship — all of it, from the first week.
• A reporting line into production. Localization sitting only under marketing tends to cover store pages well and in-game text late.
• Visibility of the budget. Someone who cannot see what translation actually costs cannot make sensible trade-offs about scope.

Give the first ninety days to inventory rather than delivery: what text exists, in which languages, at what quality, produced by whom, verified how. Most studios discover at least one language nobody has ever checked, and one file that has been round-tripping through a lossy conversion for years.

The second hire follows from what that inventory finds. If the problems concentrate on screen — clipped text, the wrong language displayed, whole screens untranslated — the next hire is LQA. If they concentrate in the pipeline — encoding damage, keys drifting apart, imports done by hand — the next hire is an engineer. Hiring in the abstract, before you know which, is how a studio ends up with a localization team that is visibly busy and still shipping the same bugs.