A translated service report can read smoothly while changing a detail that matters. A decimal separator may alter a reading, a part suffix may disappear or a sentence saying a cause is not confirmed may become definite. Preparing a translation therefore needs both language review and a technical comparison against the accepted original.
The proposed process below creates a reviewable translated draft. It does not establish that any particular language pair or specialist term is supported correctly by a provider, and it does not replace the responsible technical person's approval. The practical output is a translation control sheet that protects measurements and identifiers while making terminology and meaning review explicit.
Select the accepted report and the intended reader
Start with the approved source report version, job and equipment identifiers. A draft inspection note and a final customer report may have different wording and authority. The translation should not combine them without a separate accepted editorial decision. Record the target language and the audience's expected level of technical detail.
Ask the customer or responsible coordinator which language is appropriate instead of inferring it from a name or location. The organisation should confirm that a competent reviewer can assess the chosen language and technical subject. If that review is unavailable, record the limitation and use the established alternative communication process.
Keep explanatory rewriting separate from translation. Simplifying a report for a nontechnical reader may be useful, but it can change content. Define whether the job is a faithful translation, an approved plain-language adaptation or both as distinct versions. A translated explanation should not silently become a new technical opinion.
Protect values that should not be translated
Create a locked-field list from the accepted report. Include numeric measurements, units as approved, tolerances and ranges, equipment identifiers, part codes, serial numbers and document references. Preserve leading zeros and suffixes. These strings are not prose to localise creatively.
Decide how display conventions will be handled with the reviewer. If a decimal separator is changed for the target language, the underlying numeric value must remain identical and the chosen convention should be unambiguous. Never let a model infer a conversion between units or currencies merely to make the report feel local.
Source: OpenAI Structured Outputs describes schema-constrained responses. A proposed translation response can require text sections, locked-field references and unresolved terms. Schema shape does not guarantee preservation of values or meaning. Compare the protected fields deterministically with the accepted original and send any mismatch for review.
Use a reviewed terminology register
Build a small term register for the actual report type. Each entry should contain the source term, accepted target term, equipment or subject context, reviewer and approved version. A term with several technical meanings needs context rather than one universal substitution. Include how to handle untranslated manufacturer names or product codes.
Source: Google Cloud translation overview describes translation offerings and glossary support in the Advanced API. That is a capability reference, not proof that an organisation's selected language pair or technical terminology will be correct. The team must check applicable service support and evaluate the accepted terms in its deployment.
Use an unresolved-term list rather than choosing the nearest familiar expression. The reviewer can accept a term, retain the original with an explanation or revise the sentence. Record the decision so subsequent reports use the same accepted meaning without hiding uncertainty behind consistent but incorrect terminology.
Reusable technical translation control sheet
Use this proposed sheet with both the source and translated reports available to the reviewer.
Identity: [Job ID, equipment ID, accepted source version, target language, translation version and reviewer]
| Protected element | Source value | Draft value | Required result |
|---|---|---|---|
| Measurement and unit | [Exact original] | [Exact draft] | Same underlying value and accepted unit |
| Range or tolerance | [Bounds and qualifying words] | [Draft bounds and words] | No changed limit or lost condition |
| Part/equipment code | [Exact identifier] | [Draft identifier] | All characters and leading zeros retained |
| Date/reference | [Accepted original meaning] | [Draft representation] | Unambiguous and linked to original |
| Finding status | [Reported, tentative or approved] | [Draft status wording] | Same authority and uncertainty |
Term decisions: [Source term, accepted target term, context, glossary version and unresolved alternative]
Meaning review: [Negation, conditional statements, responsibility limits, required next step and any safety-critical wording]
Bilingual technical decision: [Accept, revise or hold the exact draft; evidence of corrections and accepted version]
Delivery record: [Approved recipient and version; external send remains a separate authorised action]
The completion check is that protected fields agree, terminology decisions are accepted and the reviewer confirms the full report retains the original meaning. A passed numeric check alone does not establish that the narrative is faithful.
Compare a faithful draft with an altered conclusion
Consider a hypothetical accepted report containing a reading of 7.50 A and part code P-005-B. Its conclusion states that the suspected cause remains unconfirmed pending the specified technical review. The translated draft must retain the value and accepted unit, preserve every part-code character and communicate the same unresolved state.
A draft showing 75.0 A fails the protected-field check. A draft showing P-5-B also fails, because the leading zeros are part of the identifier. The workflow holds that version and sends the exact mismatch to the reviewer. It does not auto-correct and release the report without checking whether other meaning changed.
Another draft keeps the numbers correct but changes unconfirmed to confirmed. The deterministic fields might pass, while the bilingual meaning review fails. This illustrates why both checks are necessary. The reviewer compares the complete sentence and corrects the authority level before approving the revised version.
If the source itself contains an unreadable value or inconsistent code, translation should retain an unresolved item and return it to the source-report owner. It must not use the target-language draft to manufacture a clearer but unsupported original. Duplicate requests for the same source/language/version should link to the existing translation review, while a revised source requires a new comparison.
Keep review and delivery separate
Source: n8n human review documents approval or denial before selected agent tool actions. A delivery tool can use that boundary when configured appropriately. It does not verify a translation's technical meaning or establish the reviewer's language competence. The organisation must supply those controls and the accepted report version.
Evaluate the proposed process with reports containing decimal values, identifier zeros, ranges, negation, conditional instructions and ambiguous terms. Ask the bilingual technical reviewer to identify changes that automatic field checks missed. Record review effort and correction types. Do not assume translation is suitable simply because the output is grammatical or the provider supports a translation operation.
Questions about translated site reports
Can the assistant convert units while translating?
Only under a separately approved conversion rule with deterministic calculation and technical review. The proposed first version preserves accepted units and values. A translation request alone does not authorise conversion, rounding or changes to tolerances. If a second representation is needed, keep the original beside it and verify the relationship.
Is a glossary enough to approve technical wording?
No. A glossary helps apply accepted terms consistently, but sentence context, negation and conditional meaning still need review. A correct noun inside an incorrect conclusion can mislead the customer. The bilingual technical reviewer should compare the full report, not just the term list.
What if nobody can review the target language technically?
Record that limitation and use the organisation's accepted alternative, such as an authorised interpreter or a reviewed source-language explanation. Do not describe the translation as verified. The workflow should hold external release of the unreviewed technical draft rather than treating fluent wording as evidence of accuracy.
If your business needs help defining this process, explore Document processing, the wider AI automation services, and our custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the terms. To discuss your records and approval rules, get in touch.