Translating a Technical Site with AI: Keeping the Glossary, Numbers, and Promises Aligned

Before you start: what you will finish with, who this is for, tools, prerequisites, and what this version adds

This guide shows how to translate a technical site with AI without drifting on glossary terms, numbers, support hours, limits, or commercial promises. The goal is not a polished translation in the abstract; it is a repeatable workflow you can use on product pages, service pages, support content, and technical marketing copy.

You will finish with:

• a complete simulated source sheet in Italian;
• a controlled IT/EN glossary with more than 8 terms;
• a copy-ready prompt for the AI;
• a complete didactic English translation;
• two explicit failure cases with corrections;
• a reusable approval record and final acceptance check.

This workshop-style version goes further than a general explanation: it gives you the source text, the glossary, the prompt, the translation, and the review record in one place. That makes it easier to reuse in real editorial work and aligns well with the idea of governed AI adoption used in Dedaloop’s own Responsible AI and responsible automation approach.

The method also fits the W3C view of localization: translation is not only word substitution, but also correct handling of numbers, dates, times, currency, layout, and other locale-specific elements. See the W3C guidance on internationalization and localization.

If your team already works on processes, documents, or technical workflows, this guide sits naturally beside Strategic IT advisory and governance, Custom software and integrations, and Academy, workshops and R&D: the translation is only useful if the content describing the service stays faithful to what the service actually does.

Audience

• content managers and editors;
• marketing and product teams that must protect promises before publishing;
• teams that want AI to assist translation, not decide meaning.

Tools

• any AI text generator or translation assistant;
• a document editor or spreadsheet;
• a human reviewer who can confirm product meaning.

Prerequisites

• you have one source text to translate;
• you can identify the terms that carry business meaning;
• you can ask product, support, or sales for clarification when a term is ambiguous;
• you are willing to stop publication if a promise becomes unclear.

Provided material

Everything below is simulated for the exercise. Do not attribute it to a real customer, real test, or real implementation.

1. Freeze the rules before you touch the AI

Where to work: in your working document, before pasting any text into the AI.

Write four hard rules at the top of the file:

1. keep the commercial meaning unchanged;
2. keep numbers, units, hours, and limits unchanged;
3. do not invent features, guarantees, availability, or certifications;
4. if a term is unclear, flag it as an open question instead of guessing.

This is the first control point because a technically fluent translation can still be wrong if it changes the promise. W3C’s localization guidance makes clear that content must be prepared for the target locale, not simply rewritten on the fly. Dedaloop’s responsible-AI approach is consistent with that: the review step matters as much as the draft itself. W3C · Responsible AI and responsible automation

Expected result: the team shares the same definition of “must stay true” before translation starts.

If it diverges: stop and align on terminology first. If the team cannot agree on what counts as a promise, a limit, or a feature, the translation is not ready.

2. Prepare the full simulated source sheet

Where to work: in a dedicated block below the rules, so the AI sees one complete source and no missing fragments.

Copy this simulated source sheet exactly as written:

Product name: AtlasEdge Monitor

Short description:
A software platform for tracking requests, response times, and service status for internal teams and external customers.

3 features:
1. Dashboard with request queues and work status.
2. Report export in CSV and PDF.
3. Configurable email notifications for threshold events.

2 numbers with units:
- Log retention: 14 days
- Attachment limit: 25 MB

Support hours:
- Standard support: 09:00–17:30, Monday to Friday

Explicit limit:
- Does not include integration with legacy systems without APIs.

Risk sentence:
- The service includes acknowledgement within 2 business days.

Why this sheet works: it contains every critical element the exercise needs: a product name, three features, two measurable values, support hours, one explicit exclusion, and one sentence that is easy to mistranslate if the glossary is weak.

Dedaloop already published a related article on the same topic, and this guide is designed to be more operational: it adds the full source sheet, the glossary, the prompt, the translation, the mistake cases, and the approval record. See Translating a Technical Site with AI: Keeping the Glossary, Numbers, and Promises Aligned.

Expected result: you have a complete source text with no gaps that would tempt the AI to invent details.

If information is missing: do not fill it in. Mark it as missing in the review record and continue only with the facts you actually have.

3. Build the glossary before you ask for a translation

Where to work: in a table next to the source sheet, or directly below it.

Copy this glossary as your starting point:

Why it matters: AI tends to pick the most natural English term, not always the safest one. The glossary tells it that “presa in carico” is about receiving or acknowledging a request, not about solving it. That difference is the gap between a faithful translation and an accidental promise.

The W3C guidance supports this discipline: content that will be localized should be structured and prepared in advance, including locale-sensitive elements. W3C

Expected result: every important term has a preferred rendering before the model starts translating.

If a term is ambiguous: do not guess. Add a note such as “confirm with product owner” or “confirm with support team.”

4. Use a prompt that forces the AI to respect the source

Where to work: in the AI interface or translation tool.

Paste this prompt as-is:

You are a technical translator for a company website.

Goal:
Translate the Italian text below into English while preserving commercial meaning, numbers, units, support hours, limits, and promises.

Mandatory rules:
1. Use only the approved glossary.
2. Do not add features, guarantees, availability claims, or certifications that do not appear in the source.
3. Keep numbers and units; if local formatting changes, do not change the value.
4. If a term is ambiguous, list the doubt in a separate “Open questions” section.
5. If a sentence describes acknowledgement or intake, do not turn it into resolution or an SLA.
6. If the source contains an explicit limit, do not soften it.
7. Produce two separate outputs:
   - English draft
   - Open questions / editorial notes

Required output sections:
- Product name
- Short description
- Features
- Numbers and limits
- Support hours
- Explicit limits
- Notes only if needed

How to use it well:

• show the glossary before the source text;
• paste the entire source sheet;
• ask for one English draft only;
• do not ask for “improvements” or “better marketing wording” at this stage.

Expected result: the AI produces a readable English draft without inventing meaning.

If it diverges: do not fix everything manually first. Note where the model changed the meaning, then rerun the prompt with the violated rule highlighted.

5. Check the English draft against the source, not against your memory

Where to work: in a second column or second block of the same document.

Here is the complete didactic English translation expected for the simulated source sheet:

AtlasEdge Monitor is a software platform for tracking requests, response times, and service status for internal teams and external customers.

The platform offers three main features: a dashboard with request queues and work status, report export in CSV and PDF, and configurable email notifications for threshold events.

Logs are retained for 14 days. The attachment limit is 25 MB.

Standard support is available Monday to Friday, from 09:00 to 17:30.

The service includes acknowledgement within 2 business days.

The service does not include integration with legacy systems without APIs.

What to verify immediately:

• 14 days is still 14 days;
• 25 MB is still 25 MB;
• 09:00–17:30 is still the same time window;
• Monday to Friday keeps the original support calendar;
• acknowledgement did not become resolution;
• the explicit exclusion stayed an exclusion.

If your editorial house style uses a decimal format different from the source, the numeric value must still be identical. For example, a source value like 12,5 MB may be formatted as 12.5 MB in English copy if your style guide requires it, but the value itself must not change. That is exactly the kind of locale-aware handling the W3C discussion addresses. W3C

Expected result: the translation preserves meaning, values, and exclusions.

If the meaning changes: mark it as a translation error, not a stylistic preference.

6. Test the two failure modes the brief asks for: SLA drift and invented features

Where to work: in a separate section labelled “Simulated errors.”

Error 1: turning acknowledgement into an SLA

Italian source

The service includes acknowledgement within 2 business days.

Wrong translation

The service guarantees resolution within 2 business days.

Why it is wrong:

• acknowledgement is not resolution;
• guarantees adds a promise that the source does not state;
• the sentence shifts from intake to outcome.

Corrected version

The service includes acknowledgement within 2 business days.

Error 2: turning a limit into a capability

Italian source

The service does not include integration with legacy systems without APIs.

Wrong translation

The service includes full integration with legacy systems.

Why it is wrong:

• it removes an explicit exclusion;
• it adds a capability that is not present;
• it changes the scope of the service.

Corrected version

The service does not include integration with legacy systems without APIs.

Comparison record to fill in:

The same discipline is what Dedaloop recommends in its existing article on the topic: protect numbers, limits, and promises, and separate the human review from the machine draft. Translating a Technical Site with AI: Keeping the Glossary, Numbers, and Promises Aligned

Expected result: the team sees the difference between a fluent translation and a faithful one.

If someone calls this “just wording”: stop. On a technical site, wording can change what the service appears to promise.

7. Handle missing data without inventing a stronger promise

Where to work: in the “Open questions / editorial notes” section.

Run a second pass where the AI must list what it cannot know.

Normal case: the glossary is complete, the source is complete, and the translation can proceed.

Missing-data case: imagine the source had only “fast support” with no explicit time, or the term “acknowledgement” was not clarified by product or support.

The AI should not:

• invent an SLA;
• convert a vague phrase into a stronger promise;
• hide uncertainty in polished wording.

Instead, it should produce a note like this:

Open question: In this context, does “acknowledgement” mean receipt confirmation only, or the actual start of work? Confirm with the product owner.

Expected result: the system returns an editorial question, not a fabricated answer.

If the missing field gets filled anyway: block publication and send it back for human review.

8. Run the final acceptance check and save a reusable approval record

Where to work: at the end of the document, or in a short approval sheet.

Use the same final check every time before publication:

1. verify that all numbers match the source;
2. verify that all units match the source;
3. verify that support hours still mean the same thing;
4. verify that limits remain limits;
5. verify that promises have not become guarantees;
6. verify that every open question is resolved or explicitly accepted by the responsible reviewer.

Reusable approval record

Acceptance criteria

The translation is ready to publish only if:

• every numeric value matches the source;
• every unit matches the source;
• no explicit limit has been turned into a capability;
• no capability has been invented;
• no guarantee has been added;
• open questions are either resolved or consciously accepted.

If you split the work into a new session: reload the source sheet, glossary, and prompt before you continue. Do not assume the model remembers the previous context.

Troubleshooting and final test

Problem 1: the AI translates presa in carico as resolution

Reload the glossary and rerun the prompt with the term highlighted. Do not publish until the meaning is fixed.

Problem 2: the AI adds guaranteed, fully, or another extra promise

Remove the added claim and mark the draft as altered meaning, not just edited style.

Problem 3: a value is missing

Do not invent it. Add an open question and ask the responsible person to confirm.

Problem 4: a number changes format

Check that the numeric value is the same before you worry about punctuation.

Problem 5: the draft sounds polished but changes the scope

Return to the approval record. If the service promise changed, the draft is not ready.

Final test you can repeat

Before publishing, read the English draft aloud and compare it line by line with the source sheet. If you can answer “yes” to all of these, the draft passes:

• Did any number change?
• Did any limit become a feature?
• Did any feature become a promise?
• Did any ambiguous term remain unresolved?
• Would a buyer read the same service offer in both languages?

If any answer is “no,” revise the draft before publishing. That is the practical difference between AI-assisted translation and uncontrolled rewriting.

Final note

Use AI to accelerate the first draft, not to decide what the service means. The workflow is simple: freeze the rules, prepare the source sheet, build the glossary, run the prompt, verify the draft, test the failures, and log the approval. That is enough to keep a technical site aligned across languages without inventing benefits that were never promised.

If you want to extend the same method to service pages, product pages, or internal documentation, the next step is to describe the process first and translate second. The translation will be faster, and the final page will stay true to what the business actually does.

Sources

• https://www.w3.org/International/questions/qa-i18n
• https://www.dedaloop.it/en/news/translating-a-technical-site-with-ai-keeping-the-glossary-numbers-5e3d010a/index.html
• https://www.dedaloop.it/en/services/benefit-ai/index.html
• https://www.dedaloop.it/en/services/strategic-governance/index.html
• https://www.dedaloop.it/en/services/software-builders/index.html
• https://www.dedaloop.it/en/services/academy-rd/index.html