Translating a specification document into English

Shall, should, may: the backbone of an English specification

In a specification, every verb carries weight. English-language specifications (ISO standards, engineering documents, international tenders) rely on modal verbs with fixed meanings: shall for a mandatory requirement, should for a recommendation, may for an option, can for a capability. Many source languages are looser. In French, doit, devra and a plain present tense can all state the same obligation; in Spanish, deberá and debe are used interchangeably.

• Le logiciel doit exporter les données au format CSV. → The software shall export data in CSV format.
• A recommendation such as French devrait → The interface should offer a dark mode. (not binding)
• A source sentence in the plain present (the application displays a dashboard) is often an obligation in the original. In English, displays reads as a description; the expected form is shall display.

Some organisations prefer must to shall, which they find old-fashioned. The choice matters less than consistency: an English-speaking engineer who sees shall, must and will alternate will wonder whether the requirements carry different weights. This is the first thing to check in the translation.

English conventions: spelling, numbers, dates and local terms

Settle the variety first. A specification for a UK supplier uses optimise, licence (noun), programme (for a project); a US recipient expects optimize, license, program. Mixing both in one document looks careless.

• Numbers: most continental European sources use a decimal comma and a space or full stop for thousands. In English, 1 250,5 kg or 1.250,5 kg becomes 1,250.5 kg. In a tolerance table, a slip here changes the value.
• Dates: 05/03/2026 means 5 March in the UK and 3 May in the US. For milestones, prefer 5 March 2026 or ISO 2026-03-05.
• Document types and roles: local terms rarely map one to one. German distinguishes the client's Lastenheft (requirements specification) from the contractor's Pflichtenheft (functional or technical specification); French MOA and MOE are usually rendered as client or project owner and prime contractor, recette as acceptance testing. Any acronym left untranslated should be spelled out at first use.
• Plurals: English has only two forms, singular and plural. A field written 1 user(s) should read 1 user / 2 users, or keep user(s) in a template.

English text is usually 10 to 15% shorter than French, so requirement tables translated from French tend to gain room rather than overflow.

What Manuce returns, and what it does not do

Your specification is handled by Dédale, Manuce's technical specialist engine. A typical document of around 6,000 words (about 20 pages) is delivered within minutes.

• Accepted formats: Word, PDF, PowerPoint, Excel, plain text, Markdown, HTML, RTF and CSV. The file comes back in its original format, layout included: requirement tables, numbered headings and headers stay where they were.
• Instant quote on upload, based on the exact word count; English is charged at the base rate (×1 coefficient).
• Free sample: one paragraph of your file translated at the chosen level before you pay, so you can judge how obligations and your domain terms come out.
• Files remain available in your customer area.

What Manuce does not do: it cannot read scanned PDFs (images with no selectable text); it does not take glossaries or terminology instructions; and it does not provide sworn or certified translations. If a tender or contract requires a version certified by a sworn translator, you will need one. For a document going to a supplier or partner, the Professional level is suitable; Premium adds a cross-review after the most advanced engine.

Preparing the file and checking the result

1. Freeze the version: accept or reject tracked changes and remove internal comments before uploading, so you do not translate a draft.
2. Upload the source file rather than an exported PDF: a Word file is easier to finish in English (cross-references, table of contents to refresh).
3. Note what must not change: requirement IDs (FR-042, NFR-007), module names, standard references (EN ISO 9001). Check them in the free sample, then in the full translation.

After delivery, check first:

• consistent use of shall and should across all requirements;
• figures in tables (decimal separators, units);
• milestone dates, with no day/month ambiguity;
• the table of contents and cross-references (see section 4.2), to be refreshed in Word;
• ID prefixes in the source language, such as French EXF (functional requirement): they can stay, but a short key helps English readers decode them.

In practice

1. Freeze the specification: resolve tracked changes and remove internal comments.
2. Upload the file (Word preferred) for an instant quote on the exact word count.
3. Read the free sample: obligations rendered as shall, domain terms, requirement IDs.
4. Run the translation, then check figures, dates, cross-references and shall/should consistency.