How to Build and Run a Volunteer Translation Team That Lasts

A language team is a small organisation. It has a purpose, a membership, a way for newcomers to enter and a way for experienced people to take on more. Most volunteer translation efforts have none of these things — they have a spreadsheet, an enthusiastic person, and roughly eighteen months before that person burns out and the locale silently goes stale.

We have started, rescued and occasionally buried a fair number of these teams. What follows is what has actually worked, including the parts that took us several failures to learn.

Why volunteer teams fail

Almost never because of a shortage of willing translators. The failure modes are remarkably consistent:

• The bus factor of one. One person holds all the context, all the terminology decisions and all the platform permissions. When they leave, the locale freezes.
• No route in. A newcomer arrives, finds three thousand untranslated strings, no glossary and no way to ask a question, and quietly leaves. Nobody notices they came.
• No route up. A capable contributor translates for two years, never gets more responsibility, and drifts away out of boredom.
• Invisible work. Nobody is credited, nobody is thanked, the release notes name only the developers. Volunteers do not need payment; they do need to exist in the record.
• Broken string freezes. The team translates 400 strings the week before release; a developer merges a copy change on release day and invalidates half of them. Do this twice and your team is gone.
• Review as gatekeeping. A reviewer who rewrites everything without explanation teaches nothing and drives people away faster than any technical obstacle.

Every one of these is a structural problem with a structural fix. None of them is solved by finding more enthusiastic people.

Start with a charter, not a spreadsheet

Before recruiting anyone, write down four things for the locale. It takes an hour and it is the difference between a team and a mailing list.

1. Scope. Which projects and which components this team is responsible for — and explicitly, which it is not.
2. Roles. Who is the lead, who can review, who can merge. With names, not job titles.
3. Standards. Formal or informal register, the glossary location, the style guide, how terminology disputes get settled.
4. Rhythm. When the team meets or checks in, when string freezes happen, what the release cadence is.

Publish it in the repository. A newcomer should be able to read it in five minutes and know exactly what they are joining.

The reviewer ladder

Flat teams do not retain people. The structure that has worked for us has four rungs, and movement between them is based on reviewed work rather than time served.

Rung	Can do	Typical entry point
Contributor	Translate; everything reviewed before it ships	Day one
Reviewer	Approve others' strings; propose glossary entries	~500 accepted strings, low correction rate
Team lead	Own glossary and release readiness; settle disputes	Sustained reviewing plus willingness
Mentor	Onboard one newcomer at a time	Optional at reviewer level and above

Two details matter more than the shape. First, the criteria for each rung are written down and public — nothing corrodes a volunteer community faster than promotions that appear to be about favouritism. Second, moving up is offered rather than applied for. Many excellent reviewers would never put themselves forward; being asked is what gets them there.

Onboarding: the first four weeks decide everything

Our retention data is unambiguous. Contributors who are paired with a mentor in their first month are roughly three times more likely to still be active a year later. Not more productive in that month — more likely to still be there.

The structure we use:

• Week one. The mentor introduces themselves personally, points at the glossary and style guide, and hands over ten deliberately low-risk strings. Nothing user-facing and critical; nothing ambiguous. The goal is one successful loop, not output.
• Week two. The mentor reviews everything and explains every change — including the ones that are preference rather than error, labelled as such. This is the single highest-value hour anyone in the team spends.
• Week three. The newcomer works independently on a real batch. A reviewer still signs off, but the mentor steps back.
• Week four. Their work ships, and they are named in the release notes. That specific moment — seeing your own name attached to software other people use — is what converts a trial contributor into a member.

The mentor commitment is roughly two hours across the month. It is not a large ask, and it is worth stating plainly to mentors that this is the highest-leverage thing they can do for the team.

How to review without driving people away

Reviewing is a teaching activity that happens to produce corrected strings. The habits that distinguish reviewers people want to work with:

• Say why. "Changed to X" teaches nothing. "Changed to X because the glossary fixes this term and consistency matters more than reading flow here" teaches a rule that prevents ten future corrections.
• Separate error from preference. If the translation is correct but you would have phrased it differently, say so and leave it. Rewriting acceptable work as a matter of taste is the fastest way to lose a contributor.
• Review promptly. A string reviewed within two days feels like collaboration. The same string reviewed three weeks later feels like an audit.
• Disagree in public. Terminology disputes belong on the string, visible to the team, with the resolution written into the glossary and the reasoning recorded. Private resolution means the same argument recurs every six months.
• Praise specifically. "Good catch on the plural form in string 214" lands. "Great work!" does not.

The purpose of review is not to produce a perfect string. It is to produce a translator who writes the next string correctly without being reviewed.

— from our reviewer handbook

Recognition is infrastructure, not decoration

Volunteers are paid in visibility, learning and belonging. Treat those as deliverables with owners, the way you would treat a build pipeline.

• Names in the release notes. Every release, every contributor, spelled the way they want it spelled. Automate the list generation so it never gets skipped under deadline pressure.
• A public contributors page. With roles and locales. People link to it from job applications; we have had several contributors tell us it directly helped them get hired.
• Commit attribution. Where the workflow allows, translations land with the translator as author rather than a bot.
• Reachable milestones. First accepted string, first review, first release, first thousand strings. Mark them somewhere the team sees.
• Real thanks from maintainers. A message from the project's lead developer to a translator lands differently from one from the localization coordinator. Ask maintainers to do this occasionally; most are glad to.

Protect the string freeze like a release blocker

A string freeze is a promise: after this date, source text does not change, so translation work cannot be invalidated. Breaking it is the most reliable way we know to lose volunteers, because it converts someone's evening into wasted effort — and they were not being paid for that evening.

What has worked:

• Publish freeze dates in the same calendar as code freezes, not in a separate document only translators read.
• Make a string change after freeze require the same approval as a code change after freeze. Same process, same friction.
• When a freeze must be broken — occasionally it must — announce it before it happens, name exactly which strings changed, and apologise. Translators are reasonable about genuine emergencies and unforgiving about silent ones.
• Track freeze breaks as a metric. A team that breaks freeze three times a year has a process problem it can see.

Terminology disputes and the code of conduct

Two people who both speak a language fluently will disagree about the right word, sometimes fiercely, often for reasons that go beyond linguistics — regional variation, professional background, generational usage. This is normal and needs a process rather than a personality.

1. The disagreement is raised on the string, in public, with reasoning.
2. Anyone in the team can add evidence — corpus usage, what comparable products do, what the user base actually says.
3. If it does not resolve in a few days, the team lead decides.
4. The decision goes into the glossary with its reasoning, so the next person who wonders finds an answer rather than reopening the argument.
5. The decision can be revisited with new evidence, but not simply re-argued.

Separately, have a code of conduct with a named contact who is not the team lead — because sometimes the problem is the team lead. Ours reduces to: assume good faith, critique the translation rather than the translator, and remember that for most people in the room, English is not their first language either.

Measuring whether the team is actually healthy

Percentage translated is the metric everyone tracks and it tells you almost nothing about the team. A locale at 100% maintained by one exhausted person is in far worse shape than one at 70% with four active contributors and a mentor.

What we watch instead:

Signal	Healthy	Worrying
Active contributors	3 or more in the last 90 days	1 — the bus factor problem
Review latency	Under 3 days median	Over 2 weeks
Newcomers retained	Over half still active at 3 months	Under a quarter
Reviewer count	At least 2 who can sign off	1, or the lead reviews their own work
Freeze breaks	Rare and announced	Routine
Glossary changes	Steady trickle	None for a year

A dormant glossary is a particularly good early warning. It usually means nobody is asking questions, which usually means nobody new is arriving.

Plan for the lead leaving, because they will

Every team lead eventually steps back — a new job, a child, a change of interest, simple fatigue after years of unpaid coordination. Teams that survive this have done three things in advance:

• Documented the tacit knowledge. Why terms were chosen, which strings are politically sensitive, which maintainer to ask about what. If it only exists in the lead's head, it leaves with them.
• Spread the permissions. At least two people can merge, administer the platform and cut a release. Sole ownership of an account is a single point of failure.
• Named a deputy. Someone who already does part of the job and would not be starting cold.

And when a lead does step down, thank them publicly and specifically. Volunteers who leave well often come back; volunteers who leave feeling unnoticed never do. Retirement should be a normal, honourable state in your team's structure — not a disappearance.

None of this is complicated. It is simply the ordinary work of running a small organisation, applied to a group of people who are not paid and can leave at any time. That last constraint is exactly why the structure has to be better than the one a paid team could get away with.

---