Translation file naming conventions that prevent delivery mistakes

Most delivery mistakes we see are not translation mistakes. The text is fine. The wrong file went out. Translation file naming conventions are the cheapest fix for that whole class of error, and they are the piece of project hygiene agencies keep postponing because it looks like admin rather than work. It is not admin. A file name is the only metadata that travels with a document through email, ZIP archives, download folders and a client's own filing system. It is also the only thing a tired project manager reads at seven in the evening before hitting send.

The delivery mistakes a naming scheme actually prevents

Four failures account for nearly everything we have watched go wrong at the delivery step, and all four happen after the translation itself is correct.

The wrong language goes to the wrong client. An agency we worked with ran an employee handbook into German and Dutch for two subsidiaries of the same group. Both translators returned a file called Handbook_translated.docx. The project manager filed them in separate folders, which felt like enough. At delivery she had six attachments across two emails and took the German one out of the Dutch folder. Linguistic review had been done properly, on the right files, in the right folders. Nobody reads document contents at attach time. They read names.

A superseded draft goes out. The reviewed version and the pre-review export sit in the same folder with names that differ by a word nobody ever agreed on.

The client's own file gets overwritten. You return a translated file carrying the same name as the source, the client saves it into the folder the source came from, and the source is gone. That one produces an unpleasant email about three weeks later.

A file arrives unidentifiable. document (1).docx in a mailbox, from a freelancer who downloaded it out of a browser window. Somebody has to open it to find out what it is, and when two of them land the same morning, somebody has to open both.

None of this is caught by a QA report or a spell check. It is caught by the name, or it is caught by the client. Our pre-delivery file checklist covers the content side of a handoff. Naming is the layer underneath it, and it does its work before the checklist is ever opened.

What good translation file naming conventions carry, and in what order

Five fields do the job for most document work: a client or project code, something that identifies the source document, the language pair, the production stage, and a version number. In that order, with a separator that is not a space.

ACME_handbook_en-US_de-DE_rev_v03.docx

The order is not cosmetic. File names sort as strings, and sorting is most of what a convention buys you. Put the client code first and everything for one client groups together in any folder, any mail client, any archive listing. Put the language pair after the document identifier and all target languages of one document sit next to each other, so a missing one shows up as a visible gap instead of something you have to count. Put the version last and the newest file for a given document and language lands at the bottom of the list.

The field people leave out is the source language. handbook_de turns ambiguous the moment a client sends work in both directions, which most corporate clients eventually do. Writing en-US_de-DE costs eight characters and removes the question permanently.

Dates are optional and often harmful. If you use one, use ISO 8601 (2026-10-27) so it sorts correctly, and put it after the version rather than in front of it, or the name will group your files by day instead of by document. We usually skip it. The filesystem already keeps timestamps, and a date in a name drifts away from what the file actually is by the second re-export.

Resist the urge to encode everything else. Word counts, translator initials, PO numbers and deadline flags belong in the project record, not the name. Every field you add is a field somebody has to get right, and a convention only works while people can reproduce it from memory. Five fields is roughly the limit for that. On batch work across many files the discipline matters more rather than less, because the name is the only thing separating fourteen near-identical deliverables.

Language codes: pick a standard and stop improvising

Use BCP 47 tags. That means an ISO 639-1 two-letter language code, an optional ISO 3166-1 alpha-2 region, and a script subtag where the script is what differs: de, de-AT, pt-BR, pt-PT, zh-Hans, zh-Hant, sr-Latn. BCP 47 also fixes the casing for you, which matters more than it sounds: language lowercase, script in title case, region uppercase, as in zh-Hant-TW.

Here is what improvising costs. A sixty-file product documentation set, Chinese for two markets, one in the mainland and one in Taiwan. The team used CN and TW as tokens. Those look sensible and are in fact region codes rather than language codes, so nothing in the name said which script was inside. Halfway through the project a new coordinator read CN as "Chinese" rather than "mainland" and eleven files in the Taiwan batch came back Simplified. The error was invisible in the file list, because both token sets were plausible. zh-Hans and zh-Hant name the thing that actually differs between the two deliverables.

Improvised abbreviations also collide with each other. Once ger, de, DE, German and GER all appear in one project folder for the same language, your sort no longer groups anything, and a script or a grep over that folder silently misses files rather than failing loudly.

One caveat. Clients arrive with their own codes, usually inherited from a CMS or an ERP that predates your project, and those codes are frequently wrong by any standard. Do not fight it. Use the client's codes in the delivery name and your own in the internal name, and write the mapping down once so nobody has to rediscover that GE means German in that account.

Version and stage markers that survive three review rounds

Zero-pad the version number. v01, not v1, so that v10 does not sort before v2 the first time a file goes through ten rounds.

Then add a stage token, because a version number alone does not say what state the text is in. Five short tokens cover document work without overlapping: mt for raw machine output, pe for post-edited, rev for bilingual review complete, qa for a QA pass complete, del for what was actually delivered. The del copy is the one that saves an argument eight months later, when a client quotes a sentence back at you and you need to know whether it was ever in the file you sent.

Why "final" is the most expensive word in a file name

A fourteen-file Spanish project we were asked to look at after the fact had three candidates for one deliverable: informe_v2 final.docx, informe_v2 final updated.docx, and informe_final_v3_JC.docx. The reviewer had worked on the second. A re-export out of the CAT tool landed as the third, which was newer by timestamp and more final by name, and that is the one the project manager delivered. Roughly forty corrections disappeared. The translator learned about it when the client sent the same comments back a second time.

The rule that prevents this is mechanical: version numbers only ever go up, and a number is never reused. A new round gets a new number even if it only changed one word. Disk space is free and a wasted number costs nothing, while two files with a defensible claim to being the latest cost a review round. "Final" describes a hope about the future, not the contents of a file.

The characters and length limits that break things downstream

No spaces. Spaces break in URLs, in command lines and in scripts, and some older transfer clients still mangle them. Use an underscore between fields and a hyphen inside a field, and you can split a name back into its parts programmatically whenever you need to.

Never use / \ : * ? " < > |. Those are illegal in Windows file names, and the colon has a long history of trouble on macOS.

Non-ASCII characters in names cause two independent problems. The first is Unicode normalization: macOS stores decomposed forms (NFD) while most other systems store composed forms (NFC), so one visible name can exist as two different byte strings and a script matching one will not find the other. The second is ZIP. The format carried no reliable encoding flag for years, so an archive built on a Russian or Polish Windows machine and opened on a Mac produces names like Рчет. We have received deliveries where every file inside was perfect and the archive was unusable. Keep names ASCII and put the local-language title inside the document, where it belongs anyway.

Watch length. Windows applications still hit a 260-character path limit by default, and a long file name plus a deep client folder tree plus an extraction path reaches it faster than you would expect. Around 60 characters is a comfortable ceiling.

Watch case too. macOS and Windows filesystems are case-insensitive by default and Linux is not, so Report_DE.docx and report_de.docx are two files on your freelancer's Linux machine and one file on your Mac, where the second one quietly replaced the first during extraction. Lowercase everything except the codes a standard capitalizes.

Internal names versus the name the client needs to see

Internal names exist for finding and sorting. Delivery names exist for a person who has never seen your convention and should not have to learn it. Treat renaming at delivery as a deliberate step rather than an afterthought.

The best default delivery name is the client's own basename, unchanged, with the target language tag appended. Mitarbeiterhandbuch_2026.docx goes back as Mitarbeiterhandbuch_2026_de-DE.docx. They recognize it on sight, it cannot overwrite their source, and their own filing habits keep working.

There is one case where you should not rename: when the file goes back into a system that references it by name, such as a CMS, a documentation build, a return package for a CAT tool, or a website asset folder. There the name is part of the content and changing it breaks something. Asking first costs one message.

Tooling deserves a look here, because tools rename files without telling you. Browser downloads append (1). Some converters lowercase everything. A number of AI translation services hand back output named after an internal job ID, which means a human has to re-identify every file before it can go anywhere. When we built SnapIntel, preserving the original upload basename on source files was a deliberate decision for this exact reason: it takes DOCX, XLSX and PPTX files, returns the translated document along with a QA report and a neutral source/target XLSX export for any CAT tool, and what comes back is still identifiable rather than renamed to a hash. Whatever you use, run one file through it and look hard at the output name before you build a delivery process on top of it.

Getting freelancers to follow it without a policy document

Nobody reads a naming policy. What does work is one line in the purchase order with a filled-in example rather than a template: "Return as: ACME_handbook_en-US_de-DE_pe_v01.docx". Give the pattern and a real instance of it, and compliance goes up without a conversation.

The second habit matters more: rename on receipt. It takes four seconds, it needs no email thread, and it costs nothing in the relationship. We have watched project managers spend twenty minutes negotiating a file name they could have corrected in four. Build the rename into your intake step and the convention survives contact with a dozen freelancers across five countries, including the ones who will never read the PO.

Agencies working to ISO 17100 have a further reason to care, since the standard expects project records that make a delivery traceable after the fact, and a naming scheme is the cheapest part of that. Check the current text of the standard for what it actually requires of records rather than taking our summary as the scope.

This matters in proportion to how much of your work moves as loose files. If your whole workflow lives inside a TMS that assigns its own file IDs and hands linguists a web editor, most of the above is already handled: the system is the convention, and you only need naming discipline at the boundaries where files enter and leave. For small agencies and nearly all freelancers, though, loose files in email and shared drives are still most of the job.

Start here

Do not write a policy. Do four things instead.

1. Write one example file name for your most common job type. One line, not a document.
2. Put it in your purchase order template, filled in, starting with the next job you send out.
3. Rename everything you receive this week at the moment you receive it.
4. Decide your language codes once, using BCP 47, and list the ten tags you actually use on that same line.

Then wait for the first time you open a folder and notice a gap where a file should be, before the client does. That is the convention earning its keep.