How should a very small software company translate project requirements, backlog decisions, test records and release handover documents when the client and developers work in different languages? Teams searching for ISO/IEC 29110-5-1-2:2025 translation guidance are usually trying to prevent a precise operational failure: a requirement changes meaning between a signed agreement, a developer's task, a test case and a customer's acceptance record. This guide shows how to keep that chain traceable without importing the bureaucracy of a large organization.
ISO/IEC 29110-5-1-2:2025 provides software-engineering guidelines for the generic Basic profile for very small entities, covering project management and software implementation. The official ISO scope concerns a single product developed by one team and excludes safety-critical software. It supersedes an older 2011 technical report. This page explains translation and documentation around the public scope; it does not reproduce the standard's protected text or claim that adopting a particular template constitutes certification.
The practical answer is to give each approved requirement a stable identifier, distinguish client requests from accepted changes, connect tests to the requirements they check, and preserve release status separately from development progress. The discussion starts with definitions and a worked project map, then moves through realistic multilingual handoffs, review questions and a learning plan for teams that have limited staff but still need dependable evidence.
The scope of this translation problem
This is a subject-specific educational companion about software project management and implementation in very small entities. It is written for small software teams, product owners, clients, developers, testers and software localization leads. The core evidence is small-team software project and release records. The consequences of a mistranslation can extend beyond style: requirements fidelity, reliable test evidence and responsible acceptance of delivered software. The applicable source record, approved local procedures, professional competence and actual legal requirements take priority over illustrative sentences in this guide. No sample here is a production instruction, design approval, clinical judgement, legal determination or claim of ISO certification.
The public ISO catalogue identifies ISO/IEC 29110-5-1-2:2025 and its scope. This article interprets that publicly described subject independently and explains how to manage multilingual meaning, not the copyright-protected clauses of the standard. Readers should obtain the controlling standard and relevant project-specific documents where decisions depend on exact requirements. A reference to an ISO edition is not proof that a company, product, individual or document meets it. Throughout, constructed examples deliberately show how to distinguish observation from inference, intention from completed action, and document possession from authorization.
The source-to-target decision map
- Identify the actual reader and the decision that the translated passage may influence.
- Collect the source document, revision, governing reference and supporting records before editing language.
- Mark every identifier, quantity, unit, condition, exception, timestamp, role and unresolved statement.
- Translate the technical meaning into plain, readable target-language sentences without adding authority.
- Ask the software project owner and authorized client representatives to resolve technical ambiguities; do not treat the translator as an engineer or approving official.
- Perform independent language and technical review, then release a dated translation with a traceable query log.
The quality target is not a word-for-word mirror of the original syntax. It is an equivalent decision boundary. If the source allows two interpretations, the target should not silently pretend there is one. If a field is unknown, do not fill it from apparent common sense. If the source record has changed, control that change instead of altering the historical translation without explanation. Those three habits make technical localization safer and far easier to maintain when suppliers, customers and reviewers use different languages.
1. A small team still needs accountable decisions
Small-team informality can help delivery but cannot replace knowing who approved a scope change or release. This distinction becomes especially important when a record leaves the people who created it. A reader may see only one translated sentence, without the source document, accompanying table or operational context. Treat the term as part of a structured assertion: who performed the action, which object was involved, what evidence exists and what limitations prevent a broader conclusion. Translating isolated dictionary entries cannot answer all four questions.
Translating everyone agreed disguises whether a decision is documented and authorized. A good quality review should state what a fluent but overconfident translation would cause the target reader to infer, then compare that inference with the supported meaning. Where two words appear close in English, record why they are not interchangeable in this specific field. Precision is not the same as jargon: explain the concept in everyday prose, but keep a stable term in controlled labels, tables and forms.
Try this: Record a clear decision-maker and a dated artifact for every material approval. Put the result in a terminology decision register with a source example, preferred target wording, forbidden or misleading alternative, reviewer and revision date. Review one adjacent sentence and one associated data field to confirm that the choice works beyond the heading. If the right translation depends on a source fact that nobody can verify, retain a transparent query rather than inventing the fact.
2. Requirements are claims about intended behaviour
A requirement describes the behaviour or condition that a product must meet, not merely a feature name. This distinction becomes especially important when a record leaves the people who created it. A reader may see only one translated sentence, without the source document, accompanying table or operational context. Treat the term as part of a structured assertion: who performed the action, which object was involved, what evidence exists and what limitations prevent a broader conclusion. Translating isolated dictionary entries cannot answer all four questions.
A translator may turn could allow into shall allow, or omit an exception. A good quality review should state what a fluent but overconfident translation would cause the target reader to infer, then compare that inference with the supported meaning. Where two words appear close in English, record why they are not interchangeable in this specific field. Precision is not the same as jargon: explain the concept in everyday prose, but keep a stable term in controlled labels, tables and forms.
Try this: Keep modal verbs, actors, triggers and acceptance conditions explicit. Put the result in a terminology decision register with a source example, preferred target wording, forbidden or misleading alternative, reviewer and revision date. Review one adjacent sentence and one associated data field to confirm that the choice works beyond the heading. If the right translation depends on a source fact that nobody can verify, retain a transparent query rather than inventing the fact.
3. Project plans name work and constraints
Milestones, dependencies, deliverables and constraints tell the team what is planned and what remains uncertain. This distinction becomes especially important when a record leaves the people who created it. A reader may see only one translated sentence, without the source document, accompanying table or operational context. Treat the term as part of a structured assertion: who performed the action, which object was involved, what evidence exists and what limitations prevent a broader conclusion. Translating isolated dictionary entries cannot answer all four questions.
Replacing estimated completion with committed delivery creates an unintended promise. A good quality review should state what a fluent but overconfident translation would cause the target reader to infer, then compare that inference with the supported meaning. Where two words appear close in English, record why they are not interchangeable in this specific field. Precision is not the same as jargon: explain the concept in everyday prose, but keep a stable term in controlled labels, tables and forms.
Try this: Keep planning status distinct from contractual obligation. Put the result in a terminology decision register with a source example, preferred target wording, forbidden or misleading alternative, reviewer and revision date. Review one adjacent sentence and one associated data field to confirm that the choice works beyond the heading. If the right translation depends on a source fact that nobody can verify, retain a transparent query rather than inventing the fact.
4. Baseline is not today's latest draft
An approved requirements baseline gives the team a specific reference version for implementation and tests. This distinction becomes especially important when a record leaves the people who created it. A reader may see only one translated sentence, without the source document, accompanying table or operational context. Treat the term as part of a structured assertion: who performed the action, which object was involved, what evidence exists and what limitations prevent a broader conclusion. Translating isolated dictionary entries cannot answer all four questions.
The newest shared file may not be the approved baseline. A good quality review should state what a fluent but overconfident translation would cause the target reader to infer, then compare that inference with the supported meaning. Where two words appear close in English, record why they are not interchangeable in this specific field. Precision is not the same as jargon: explain the concept in everyday prose, but keep a stable term in controlled labels, tables and forms.
Try this: Preserve version, approval status, change request ID and effective date. Put the result in a terminology decision register with a source example, preferred target wording, forbidden or misleading alternative, reviewer and revision date. Review one adjacent sentence and one associated data field to confirm that the choice works beyond the heading. If the right translation depends on a source fact that nobody can verify, retain a transparent query rather than inventing the fact.
5. Traceability connects meaning across artifacts
A requirement should be locatable from its source through work products and relevant tests. This distinction becomes especially important when a record leaves the people who created it. A reader may see only one translated sentence, without the source document, accompanying table or operational context. Treat the term as part of a structured assertion: who performed the action, which object was involved, what evidence exists and what limitations prevent a broader conclusion. Translating isolated dictionary entries cannot answer all four questions.
A translation that renumbers or merges requirements breaks that navigation. A good quality review should state what a fluent but overconfident translation would cause the target reader to infer, then compare that inference with the supported meaning. Where two words appear close in English, record why they are not interchangeable in this specific field. Precision is not the same as jargon: explain the concept in everyday prose, but keep a stable term in controlled labels, tables and forms.
Try this: Keep stable requirement IDs and map language-specific titles separately. Put the result in a terminology decision register with a source example, preferred target wording, forbidden or misleading alternative, reviewer and revision date. Review one adjacent sentence and one associated data field to confirm that the choice works beyond the heading. If the right translation depends on a source fact that nobody can verify, retain a transparent query rather than inventing the fact.
6. Implementation is not acceptance
A developer can report a change merged while integration tests or client checks are still pending. This distinction becomes especially important when a record leaves the people who created it. A reader may see only one translated sentence, without the source document, accompanying table or operational context. Treat the term as part of a structured assertion: who performed the action, which object was involved, what evidence exists and what limitations prevent a broader conclusion. Translating isolated dictionary entries cannot answer all four questions.
Calling merged code delivered or approved creates false completeness. A good quality review should state what a fluent but overconfident translation would cause the target reader to infer, then compare that inference with the supported meaning. Where two words appear close in English, record why they are not interchangeable in this specific field. Precision is not the same as jargon: explain the concept in everyday prose, but keep a stable term in controlled labels, tables and forms.
Try this: Distinguish built, merged, verified, deployed and accepted. Put the result in a terminology decision register with a source example, preferred target wording, forbidden or misleading alternative, reviewer and revision date. Review one adjacent sentence and one associated data field to confirm that the choice works beyond the heading. If the right translation depends on a source fact that nobody can verify, retain a transparent query rather than inventing the fact.
7. Testing records observations, not optimism
A test report needs inputs, expected outcomes, actual outcomes and a defensible result. This distinction becomes especially important when a record leaves the people who created it. A reader may see only one translated sentence, without the source document, accompanying table or operational context. Treat the term as part of a structured assertion: who performed the action, which object was involved, what evidence exists and what limitations prevent a broader conclusion. Translating isolated dictionary entries cannot answer all four questions.
A phrase such as works fine is not a substitute for traceable evidence. A good quality review should state what a fluent but overconfident translation would cause the target reader to infer, then compare that inference with the supported meaning. Where two words appear close in English, record why they are not interchangeable in this specific field. Precision is not the same as jargon: explain the concept in everyday prose, but keep a stable term in controlled labels, tables and forms.
Try this: Translate expected and observed outcomes into separate controlled fields. Put the result in a terminology decision register with a source example, preferred target wording, forbidden or misleading alternative, reviewer and revision date. Review one adjacent sentence and one associated data field to confirm that the choice works beyond the heading. If the right translation depends on a source fact that nobody can verify, retain a transparent query rather than inventing the fact.
8. Defects and enhancements are different
A defect violates an existing requirement; a new wish may be an enhancement requiring scope review. This distinction becomes especially important when a record leaves the people who created it. A reader may see only one translated sentence, without the source document, accompanying table or operational context. Treat the term as part of a structured assertion: who performed the action, which object was involved, what evidence exists and what limitations prevent a broader conclusion. Translating isolated dictionary entries cannot answer all four questions.
Misclassifying both as bugs can conceal a new delivery obligation. A good quality review should state what a fluent but overconfident translation would cause the target reader to infer, then compare that inference with the supported meaning. Where two words appear close in English, record why they are not interchangeable in this specific field. Precision is not the same as jargon: explain the concept in everyday prose, but keep a stable term in controlled labels, tables and forms.
Try this: Link the report to the original requirement and classify the requested decision. Put the result in a terminology decision register with a source example, preferred target wording, forbidden or misleading alternative, reviewer and revision date. Review one adjacent sentence and one associated data field to confirm that the choice works beyond the heading. If the right translation depends on a source fact that nobody can verify, retain a transparent query rather than inventing the fact.
9. Product configuration has an identity
A test result belongs to a specific build, environment and dependency configuration. This distinction becomes especially important when a record leaves the people who created it. A reader may see only one translated sentence, without the source document, accompanying table or operational context. Treat the term as part of a structured assertion: who performed the action, which object was involved, what evidence exists and what limitations prevent a broader conclusion. Translating isolated dictionary entries cannot answer all four questions.
Translating a report without its version identity implies that later builds passed old tests. A good quality review should state what a fluent but overconfident translation would cause the target reader to infer, then compare that inference with the supported meaning. Where two words appear close in English, record why they are not interchangeable in this specific field. Precision is not the same as jargon: explain the concept in everyday prose, but keep a stable term in controlled labels, tables and forms.
Try this: Preserve commit/build ID, platform and test-environment notes. Put the result in a terminology decision register with a source example, preferred target wording, forbidden or misleading alternative, reviewer and revision date. Review one adjacent sentence and one associated data field to confirm that the choice works beyond the heading. If the right translation depends on a source fact that nobody can verify, retain a transparent query rather than inventing the fact.
10. Handover is a structured transfer
A release package may include executable artifacts, instructions, limitations and open issues. This distinction becomes especially important when a record leaves the people who created it. A reader may see only one translated sentence, without the source document, accompanying table or operational context. Treat the term as part of a structured assertion: who performed the action, which object was involved, what evidence exists and what limitations prevent a broader conclusion. Translating isolated dictionary entries cannot answer all four questions.
A translated release announcement can promise readiness where supporting documents are missing. A good quality review should state what a fluent but overconfident translation would cause the target reader to infer, then compare that inference with the supported meaning. Where two words appear close in English, record why they are not interchangeable in this specific field. Precision is not the same as jargon: explain the concept in everyday prose, but keep a stable term in controlled labels, tables and forms.
Try this: Create a delivery checklist accepted by the actual customer representative. Put the result in a terminology decision register with a source example, preferred target wording, forbidden or misleading alternative, reviewer and revision date. Review one adjacent sentence and one associated data field to confirm that the choice works beyond the heading. If the right translation depends on a source fact that nobody can verify, retain a transparent query rather than inventing the fact.
11. Clients need plain language without lost detail
Technical terms should be explained, but not simplified until the conditions disappear. This distinction becomes especially important when a record leaves the people who created it. A reader may see only one translated sentence, without the source document, accompanying table or operational context. Treat the term as part of a structured assertion: who performed the action, which object was involved, what evidence exists and what limitations prevent a broader conclusion. Translating isolated dictionary entries cannot answer all four questions.
Overfriendly localization can turn a documented limitation into a marketing assurance. A good quality review should state what a fluent but overconfident translation would cause the target reader to infer, then compare that inference with the supported meaning. Where two words appear close in English, record why they are not interchangeable in this specific field. Precision is not the same as jargon: explain the concept in everyday prose, but keep a stable term in controlled labels, tables and forms.
Try this: Pair accessible explanation with exact IDs, settings and known constraints. Put the result in a terminology decision register with a source example, preferred target wording, forbidden or misleading alternative, reviewer and revision date. Review one adjacent sentence and one associated data field to confirm that the choice works beyond the heading. If the right translation depends on a source fact that nobody can verify, retain a transparent query rather than inventing the fact.
12. Scope exclusions must remain visible
The ISO generic Basic profile publicly excludes safety-critical software projects. This distinction becomes especially important when a record leaves the people who created it. A reader may see only one translated sentence, without the source document, accompanying table or operational context. Treat the term as part of a structured assertion: who performed the action, which object was involved, what evidence exists and what limitations prevent a broader conclusion. Translating isolated dictionary entries cannot answer all four questions.
Repackaging the guide as a universal method for high-criticality systems misrepresents its scope. A good quality review should state what a fluent but overconfident translation would cause the target reader to infer, then compare that inference with the supported meaning. Where two words appear close in English, record why they are not interchangeable in this specific field. Precision is not the same as jargon: explain the concept in everyday prose, but keep a stable term in controlled labels, tables and forms.
Try this: State the boundary plainly and seek appropriate domain-specific requirements where relevant. Put the result in a terminology decision register with a source example, preferred target wording, forbidden or misleading alternative, reviewer and revision date. Review one adjacent sentence and one associated data field to confirm that the choice works beyond the heading. If the right translation depends on a source fact that nobody can verify, retain a transparent query rather than inventing the fact.
Twenty worked translation decisions
These scenarios are deliberately constructed teaching examples, not quotations from ISO or from actual shipments, project files, product certificates or field logs. In each one, the proposed wording must be adapted to the relevant target language and approved by the authorized subject specialist. The exercise is to preserve what a competent reader is justified in believing, rather than to memorize an English synonym.
Case 1: Functional requirement
Illustrative source situation: REQ-014: The user can export an invoice only after a successful authorization check. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: Only after is a condition, not an incidental phrase. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Keep actor, authorization condition and export action in one traceable target requirement. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. The translator should ask what the original document actually proves. A noun can name a physical object, an activity, an administrative state or an engineering judgement. Those are not free alternatives. Before choosing a target-language expression, locate the source evidence, the responsible person and the moment at which the statement became true. If any of those are absent, mark the question rather than allowing an elegant sentence to manufacture the missing facts.
Evidence and reviewer test: Check both signed requirement and authorization test. Read the target independently, without the source alongside it. What would a competent operator believe had already happened? What would they still need to verify? A release-worthy sentence must not turn a future intention into a completed event, or hide the distinction between a recorded fact and a decision. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 2: Optional preference
Illustrative source situation: The user may choose a compact display after logging in. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: May here describes an available product option rather than a regulatory permission. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Translate it as optional capability without turning it into a mandatory step. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. A multilingual recipient may never see the original document. This is why neutral wording matters more than rhetorical confidence. Spell out the actor, object, action, condition and document version. Preserve qualifiers such as observed, estimated, pending, subject to, and verified only when they appear or are established by the underlying record. The goal is not literal word order; it is an equally defensible reader inference.
Evidence and reviewer test: Confirm UX specification and acceptance test. Check temporal scope carefully. An observation at one time or on one sample does not establish a continuous state for an entire journey, build, lot or site. Add a date or location only when the source supports it; otherwise preserve the gap as an open question for its owner. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 3: Scope request
Illustrative source situation: Client requested offline mode; approval of change CR-09 remains pending. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: Requested does not mean accepted or contracted. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Preserve pending approval and the separate change ID. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. One practical way to test the translation is to reverse the decision. Give a reviewer only the target passage and ask what operation is permitted, what status is settled, and what additional evidence would still be needed. Compare those answers with the actual source. The mismatch reveals how a small shift in modality, scope or technical category can become a costly downstream misunderstanding.
Evidence and reviewer test: Review issue log and signed scope baseline. Translate the controlling noun and condition before polishing style. A common language word can refer to several regulated objects or states. If two interpretations are possible, quote the original phrase in the query log and request a ruling from the responsible technical reviewer. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 4: Acceptance criterion
Illustrative source situation: Given a valid token, saving a draft returns confirmation within five seconds. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: Time, condition and observed response are all independently testable. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Keep five seconds and token validity explicit. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. A useful localized record should survive a handover to somebody outside the translation project. Store the approved terminology, unresolved query, source version, named technical reviewer and exact supporting artifact. That packet lets a future colleague distinguish an accepted translation from an assumption. The separate evidence trail is especially important when a new edition, instrument reading or contract requirement later changes how the original material is interpreted.
Evidence and reviewer test: Match criterion against instrumented test record. Run a source-navigation test: could another reviewer open the named document, locate the cited record and recover the original number, qualifier or decision? If not, the sentence may be readable but is not yet sufficiently auditable for a multilingual operational handoff. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 5: Requirement identifier
Illustrative source situation: REQ-021 was renamed for readability but retained its original identifier. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: A new title must not erase traceability. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Keep REQ-021 stable and translate display label separately. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. The translator should ask what the original document actually proves. A noun can name a physical object, an activity, an administrative state or an engineering judgement. Those are not free alternatives. Before choosing a target-language expression, locate the source evidence, the responsible person and the moment at which the statement became true. If any of those are absent, mark the question rather than allowing an elegant sentence to manufacture the missing facts.
Evidence and reviewer test: Check requirements index and history. Read the target independently, without the source alongside it. What would a competent operator believe had already happened? What would they still need to verify? A release-worthy sentence must not turn a future intention into a completed event, or hide the distinction between a recorded fact and a decision. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 6: Task assignment
Illustrative source situation: Developer A is assigned implementation; tester B is responsible for independent verification. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: An assigned coder is not automatically the verifier. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Preserve role separation and current responsibility. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. A multilingual recipient may never see the original document. This is why neutral wording matters more than rhetorical confidence. Spell out the actor, object, action, condition and document version. Preserve qualifiers such as observed, estimated, pending, subject to, and verified only when they appear or are established by the underlying record. The goal is not literal word order; it is an equally defensible reader inference.
Evidence and reviewer test: Review work board and test plan. Check temporal scope carefully. An observation at one time or on one sample does not establish a continuous state for an entire journey, build, lot or site. Add a date or location only when the source supports it; otherwise preserve the gap as an open question for its owner. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 7: Estimate versus commitment
Illustrative source situation: Delivery is forecast for week 8, subject to integration results. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: Forecast and subject to mark uncertainty. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Keep the dependency without presenting a guarantee. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. One practical way to test the translation is to reverse the decision. Give a reviewer only the target passage and ask what operation is permitted, what status is settled, and what additional evidence would still be needed. Compare those answers with the actual source. The mismatch reveals how a small shift in modality, scope or technical category can become a costly downstream misunderstanding.
Evidence and reviewer test: Check approved project plan and client correspondence. Translate the controlling noun and condition before polishing style. A common language word can refer to several regulated objects or states. If two interpretations are possible, quote the original phrase in the query log and request a ruling from the responsible technical reviewer. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 8: Configuration baseline
Illustrative source situation: Tests ran on build 1.4.2 with database schema 6. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: A passed result cannot be generalized across every build. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Preserve exact build and schema identifiers. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. A useful localized record should survive a handover to somebody outside the translation project. Store the approved terminology, unresolved query, source version, named technical reviewer and exact supporting artifact. That packet lets a future colleague distinguish an accepted translation from an assumption. The separate evidence trail is especially important when a new edition, instrument reading or contract requirement later changes how the original material is interpreted.
Evidence and reviewer test: Review CI run and test environment record. Run a source-navigation test: could another reviewer open the named document, locate the cited record and recover the original number, qualifier or decision? If not, the sentence may be readable but is not yet sufficiently auditable for a multilingual operational handoff. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 9: Observed failure
Illustrative source situation: Expected HTTP 200; observed HTTP 403 during role-check test. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: Expected and actual cannot be combined into success wording. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Keep each response code and the failed condition explicit. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. The translator should ask what the original document actually proves. A noun can name a physical object, an activity, an administrative state or an engineering judgement. Those are not free alternatives. Before choosing a target-language expression, locate the source evidence, the responsible person and the moment at which the statement became true. If any of those are absent, mark the question rather than allowing an elegant sentence to manufacture the missing facts.
Evidence and reviewer test: Check raw test log and linked issue. Read the target independently, without the source alongside it. What would a competent operator believe had already happened? What would they still need to verify? A release-worthy sentence must not turn a future intention into a completed event, or hide the distinction between a recorded fact and a decision. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 10: Bug classification
Illustrative source situation: Saving an empty mandatory field violates requirement REQ-032. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: The behaviour contradicts an existing requirement rather than adding new scope. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Describe the defect against REQ-032. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. A multilingual recipient may never see the original document. This is why neutral wording matters more than rhetorical confidence. Spell out the actor, object, action, condition and document version. Preserve qualifiers such as observed, estimated, pending, subject to, and verified only when they appear or are established by the underlying record. The goal is not literal word order; it is an equally defensible reader inference.
Evidence and reviewer test: Review requirement text and reproduction steps. Check temporal scope carefully. An observation at one time or on one sample does not establish a continuous state for an entire journey, build, lot or site. Add a date or location only when the source supports it; otherwise preserve the gap as an open question for its owner. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 11: Enhancement request
Illustrative source situation: Client would like multi-currency filtering not included in the agreed baseline. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: A wish is not a defect under the existing acceptance terms. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Label it as enhancement pending change control. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. One practical way to test the translation is to reverse the decision. Give a reviewer only the target passage and ask what operation is permitted, what status is settled, and what additional evidence would still be needed. Compare those answers with the actual source. The mismatch reveals how a small shift in modality, scope or technical category can become a costly downstream misunderstanding.
Evidence and reviewer test: Check baseline and change request. Translate the controlling noun and condition before polishing style. A common language word can refer to several regulated objects or states. If two interpretations are possible, quote the original phrase in the query log and request a ruling from the responsible technical reviewer. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 12: Test coverage
Illustrative source situation: Test suite covers valid input but does not yet cover expired tokens. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: Coverage claims must retain exclusions. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Explain the untested condition without saying all authorization was verified. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. A useful localized record should survive a handover to somebody outside the translation project. Store the approved terminology, unresolved query, source version, named technical reviewer and exact supporting artifact. That packet lets a future colleague distinguish an accepted translation from an assumption. The separate evidence trail is especially important when a new edition, instrument reading or contract requirement later changes how the original material is interpreted.
Evidence and reviewer test: Inspect test matrix. Run a source-navigation test: could another reviewer open the named document, locate the cited record and recover the original number, qualifier or decision? If not, the sentence may be readable but is not yet sufficiently auditable for a multilingual operational handoff. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 13: Merged not released
Illustrative source situation: Feature branch merged into main; no production deployment has occurred. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: Code status and customer-visible deployment differ. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Say merged, not released or live. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. The translator should ask what the original document actually proves. A noun can name a physical object, an activity, an administrative state or an engineering judgement. Those are not free alternatives. Before choosing a target-language expression, locate the source evidence, the responsible person and the moment at which the statement became true. If any of those are absent, mark the question rather than allowing an elegant sentence to manufacture the missing facts.
Evidence and reviewer test: Check version-control log and deployment record. Read the target independently, without the source alongside it. What would a competent operator believe had already happened? What would they still need to verify? A release-worthy sentence must not turn a future intention into a completed event, or hide the distinction between a recorded fact and a decision. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 14: Release candidate
Illustrative source situation: Build 2.0 RC1 passed smoke tests; regression testing is incomplete. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: Passing a limited test is not full acceptance. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Name candidate state and incomplete regression scope. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. A multilingual recipient may never see the original document. This is why neutral wording matters more than rhetorical confidence. Spell out the actor, object, action, condition and document version. Preserve qualifiers such as observed, estimated, pending, subject to, and verified only when they appear or are established by the underlying record. The goal is not literal word order; it is an equally defensible reader inference.
Evidence and reviewer test: Read actual test report and release criteria. Check temporal scope carefully. An observation at one time or on one sample does not establish a continuous state for an entire journey, build, lot or site. Add a date or location only when the source supports it; otherwise preserve the gap as an open question for its owner. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 15: Open limitation
Illustrative source situation: Offline synchronization may duplicate drafts when the connection returns. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: A known issue must not be euphemised into a harmless cosmetic detail. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Keep the conditional risk and affected function clear. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. One practical way to test the translation is to reverse the decision. Give a reviewer only the target passage and ask what operation is permitted, what status is settled, and what additional evidence would still be needed. Compare those answers with the actual source. The mismatch reveals how a small shift in modality, scope or technical category can become a costly downstream misunderstanding.
Evidence and reviewer test: Check known-issues list and user documentation. Translate the controlling noun and condition before polishing style. A common language word can refer to several regulated objects or states. If two interpretations are possible, quote the original phrase in the query log and request a ruling from the responsible technical reviewer. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 16: Customer sign-off
Illustrative source situation: Customer accepted delivery of documentation, but software acceptance remains outstanding. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: Documentation receipt is not product acceptance. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Keep the two sign-offs separate. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. A useful localized record should survive a handover to somebody outside the translation project. Store the approved terminology, unresolved query, source version, named technical reviewer and exact supporting artifact. That packet lets a future colleague distinguish an accepted translation from an assumption. The separate evidence trail is especially important when a new edition, instrument reading or contract requirement later changes how the original material is interpreted.
Evidence and reviewer test: Verify signed delivery and acceptance records. Run a source-navigation test: could another reviewer open the named document, locate the cited record and recover the original number, qualifier or decision? If not, the sentence may be readable but is not yet sufficiently auditable for a multilingual operational handoff. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 17: Dependency record
Illustrative source situation: Library version 3.1 requires runtime version 18 or later. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: A version dependency changes whether a customer can install the software. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Retain numbers, minimum bound and component names exactly. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. The translator should ask what the original document actually proves. A noun can name a physical object, an activity, an administrative state or an engineering judgement. Those are not free alternatives. Before choosing a target-language expression, locate the source evidence, the responsible person and the moment at which the statement became true. If any of those are absent, mark the question rather than allowing an elegant sentence to manufacture the missing facts.
Evidence and reviewer test: Compare manifest and installation test. Read the target independently, without the source alongside it. What would a competent operator believe had already happened? What would they still need to verify? A release-worthy sentence must not turn a future intention into a completed event, or hide the distinction between a recorded fact and a decision. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 18: Security note
Illustrative source situation: Secrets must not be included in diagnostic logs. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: A prohibition must remain prohibitive in translation. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Retain must not and the affected artifact. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. A multilingual recipient may never see the original document. This is why neutral wording matters more than rhetorical confidence. Spell out the actor, object, action, condition and document version. Preserve qualifiers such as observed, estimated, pending, subject to, and verified only when they appear or are established by the underlying record. The goal is not literal word order; it is an equally defensible reader inference.
Evidence and reviewer test: Confirm security requirement and log redaction tests. Check temporal scope carefully. An observation at one time or on one sample does not establish a continuous state for an entire journey, build, lot or site. Add a date or location only when the source supports it; otherwise preserve the gap as an open question for its owner. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 19: Rollback plan
Illustrative source situation: Rollback is available only before database migration step M-3. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: Only before restricts the valid recovery window. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: Preserve the point of no return explicitly. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. One practical way to test the translation is to reverse the decision. Give a reviewer only the target passage and ask what operation is permitted, what status is settled, and what additional evidence would still be needed. Compare those answers with the actual source. The mismatch reveals how a small shift in modality, scope or technical category can become a costly downstream misunderstanding.
Evidence and reviewer test: Check migration runbook and rollback test. Translate the controlling noun and condition before polishing style. A common language word can refer to several regulated objects or states. If two interpretations are possible, quote the original phrase in the query log and request a ruling from the responsible technical reviewer. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Case 20: Final handover
Illustrative source situation: Release package includes build 2.2, administrator guide and three unresolved low-severity defects. The translator should first mark the source statement’s actor, object, condition, status and measurement or identifier, wherever present. A bare phrase detached from this surrounding information may look familiar but be insufficient for an operational decision.
Meaning at risk: Incomplete deliverables and known issues remain facts after translation. This is not a cosmetic difference. When a target-language reader treats the sentence as evidence for software project management and implementation in very small entities, an apparently small substitution may change what they regard as complete, permitted, rejected or still unresolved. Keep the material qualifier visible, even when an idiomatic translation has to change the original sentence structure.
Recommended rendering decision: List exact package components and unresolved issues. The exact final words depend on the target language and the source record, but the decision boundary should remain the same. A useful localized record should survive a handover to somebody outside the translation project. Store the approved terminology, unresolved query, source version, named technical reviewer and exact supporting artifact. That packet lets a future colleague distinguish an accepted translation from an assumption. The separate evidence trail is especially important when a new edition, instrument reading or contract requirement later changes how the original material is interpreted.
Evidence and reviewer test: Compare deliverable manifest and sign-off record. Run a source-navigation test: could another reviewer open the named document, locate the cited record and recover the original number, qualifier or decision? If not, the sentence may be readable but is not yet sufficiently auditable for a multilingual operational handoff. Record the approved phrase alongside the evidence reference so a future revised document does not reintroduce the same ambiguity.
Building a translation packet that can be reviewed
Start with a source register. For each document, identify an owner, date, revision, language, approval status and location of any supporting records. Do not assume that the newest document in a shared folder is the controlling edition. An unsigned revision may be a draft; an older issue may govern the historical event that is being described. The translation should tell the reader which is which. A stable file identifier is often more useful than a long descriptive filename, especially when titles are translated into several scripts.
Next, build a concept-based glossary. Do not add terms only because they appear frequently. Prioritize the terms that change decisions: material or product identity, scope, limits, authority, acceptance state, uncertainty, units and actions. For each entry, keep the source expression, a definition drawn from the authorized context, an example sentence, candidate target forms, the chosen form and a reason for rejecting misleading alternatives. This is where the Vocabulary Learning Hub can help readers learn close word meanings; it is not a substitute for project approval.
Maintain a question log. A high-quality question identifies exactly what cannot be decided from the available record. Instead of asking whether a translation sounds right, ask whether a described state was measured or merely planned, whether an approval applies to one specimen or a whole batch, or whether a date refers to an event or a report. Attach the supporting paragraph, field ID or screenshot and the decision consequence. Ask for an answer from the person who owns the underlying facts, not merely the most fluent speaker.
Give the technical reviewer a two-column comparison and a short decision checklist. The reviewer checks technical equivalence and missing conditions; the language editor checks clarity and consistency for the intended audience. Those are related but separate responsibilities. If a sentence is readable yet materially ambiguous, the reviewer should be able to return it as blocked rather than being pressured to approve the entire document. Preserve comments, resolved queries and final signed release records.
Finally, perform a simulated handover. A colleague who has not attended the translation meetings receives the finished target-language packet and must identify the controlled object, status, next action, decision owner, evidence source and limits of the conclusion. If the colleague cannot reconstruct these without guessing, the packet is incomplete. This test is especially valuable when the actual reader is far away in time, discipline or language from the author.
Frequently asked questions
Is ISO/IEC 29110 only for large software companies?
No. This guideline is expressly directed at very small entities and a Basic profile. In practice, the safe method is to identify the governing record and explain what its language supports. Make the scope and any unresolved questions visible in the target text or its controlled review notes. A good reader should be able to locate the source without knowing the translator personally.
Is the 2011 edition the current guide?
No. The public ISO catalogue lists the 2025 International Standard as replacing the old 2011 technical report. In practice, the safe method is to identify the governing record and explain what its language supports. Make the scope and any unresolved questions visible in the target text or its controlled review notes. A good reader should be able to locate the source without knowing the translator personally.
Does the Basic profile cover safety-critical projects?
The standard's public scope explicitly excludes safety-critical software. In practice, the safe method is to identify the governing record and explain what its language supports. Make the scope and any unresolved questions visible in the target text or its controlled review notes. A good reader should be able to locate the source without knowing the translator personally.
Can a task marked done be translated as client accepted?
No. Completion of an internal task is a different status from documented client acceptance. In practice, the safe method is to identify the governing record and explain what its language supports. Make the scope and any unresolved questions visible in the target text or its controlled review notes. A good reader should be able to locate the source without knowing the translator personally.
Why should requirement IDs remain unchanged?
They connect a source agreement, implementation work, tests, defects and delivery evidence. In practice, the safe method is to identify the governing record and explain what its language supports. Make the scope and any unresolved questions visible in the target text or its controlled review notes. A good reader should be able to locate the source without knowing the translator personally.
Can teams translate only the user interface?
They may localize the interface, but cross-language project accountability also depends on records and requirements. In practice, the safe method is to identify the governing record and explain what its language supports. Make the scope and any unresolved questions visible in the target text or its controlled review notes. A good reader should be able to locate the source without knowing the translator personally.
What if the client rejects a translated requirement?
Reopen the underlying requirement decision, record the discrepancy and get authorized approval of the corrected baseline. In practice, the safe method is to identify the governing record and explain what its language supports. Make the scope and any unresolved questions visible in the target text or its controlled review notes. A good reader should be able to locate the source without knowing the translator personally.
Does a successful smoke test prove release readiness?
No. It proves only the cases and build actually tested, subject to known limitations. In practice, the safe method is to identify the governing record and explain what its language supports. Make the scope and any unresolved questions visible in the target text or its controlled review notes. A good reader should be able to locate the source without knowing the translator personally.
Four-week practice programme for translators and readers
Week 1 — Establish terminology. Choose ten actual anonymized document fields from small-team software project and release records. Write down each field’s purpose, relevant unit or identifier, and the decision that could be changed by a mistranslation. Compare related words and write a short plain-language explanation of why they differ. Do not translate sensitive live data in an unsecured worksheet. The deliverable is a controlled glossary with one source-supported example for each important term.
Week 2 — Translate evidence, not confidence. Use five constructed practice statements from this article and rewrite them for a real target-language audience. Mark whether each describes a fact, plan, open query, estimate, instruction, completed authorization or observation. Have another reader independently identify those categories from the target version alone. Any disagreement belongs in a query list, not in unrecorded stylistic debate.
Week 3 — Reconstruct the handover. Take a mock set of linked documents: source register, one technical table, one revised notice, one decision and one receiving acknowledgement. Keep all identifiers consistent while changing the prose into natural target-language wording. Ask an independent reviewer to locate the exact source for three decisions. If the reviewer must search by memory, revise the traceability information rather than adding more prose.
Week 4 — Audit and refine. Select the three errors most likely to mislead an end reader. Build a checklist to detect them before publication. Test it against two intentionally flawed translations and record why the flaws matter. Then prepare a one-page release note with source versions, unresolved queries, technical sign-off and the date of the approved target text. This turns translation practice into a repeatable professional process.
Final release gate
Before publishing a translation in small-team software project and release records, use an eight-point audit: identity, quantities and units, spatial or temporal anchors, scope qualifications, actor and authority, observed versus inferred states, document version and resolvable source links. Reject any sentence that converts a claim into a guarantee, a test into a certification, an instruction into an option, a local observation into a universal conclusion or a pending action into a completed one. These are semantic errors even when the grammar is perfect.
Release can have three honest outcomes: approved, approved only for a restricted purpose, or blocked pending information. Mark those states in the project log. If information is missing, publish no invented answer. When source material later changes, create a new controlled translation and retain the historical version as appropriate to the recordkeeping rules. This is how a small, well-explained specialist page contributes to trustworthy translation without pretending to be another broad master system.
Official reference and connected learning
Official edition and public scope: ISO/IEC 29110-5-1-2:2025 — ISO catalogue, checked 6 November 2026. Consult the actual standard and the locally applicable controlled documents before an operational decision. This independent article neither reproduces paid ISO clauses nor claims ISO approval.
For the canonical world-facing architecture, see Master Art of Translation — the protected translation master (EDKSG-TRANS-MASTER-WORLD-000). For word meaning, close synonyms and conceptual learning, use the Vocabulary Learning Hub. For how context, reference and sentence structure carry meaning across languages, use How English Works — Translation and Meaning Across Languages. This article is a bounded specialist branch of those resources, not a competing general translation hub.