Check who a German approval message says acted

A translated message can be grammatically fluent and still tell the recipient that they performed an action they did not perform. That is a workflow error expressed through language. Reviewing the words alone will miss it if the reviewer cannot see the event, its actor and the audience receiving the message.

This worked example uses a fictional supplier review application. The technical decision is stored correctly. The error occurs when a German notification addresses a coordinator as though the coordinator had approved the specification. The investigation keeps the business record intact and repairs the meaning of the message.

Establish the event before judging its wording

Request Q-46 contains specification revision R-4. Technical reviewer Mara König, account A-17, has approved that revision for the organization's defined technical-review step. Coordinator Leon Weber, account C-9, receives notifications so he can arrange the next internal task. He does not hold the technical approval role.

The event record contains the request, revision, actor, action and time. The recipient list is a separate configuration. In the fictional inspection, those values are:

The German notification currently says: “Sie haben die Spezifikation freigegeben.” Leon reads “You have approved the specification,” even though his role is coordination. The message also omits the revision and the kind of approval. These omissions make it harder to compare the notice with the application.

The developer first checks the stored event and its relationship to R-4. They are correct. Changing the actor in the database to match the recipient would make the history false. Changing the recipient to the reviewer would remove a notification the coordinator needs. Neither action repairs the actual defect.

Find the assumption inside the template

The application uses one message for both an immediate confirmation shown to the acting reviewer and an email sent to other interested staff. The original context was “tell the person what they just did.” The notification context is “tell another person what happened.” Reusing the second-person sentence across those contexts creates the wrong attribution.

The message specification is revised to identify its purpose, event fields and audience. The actor variable means the person recorded on the event; the recipient is used for delivery and any salutation. The revision is the one attached to that event, not whichever revision happens to be current when the message is later viewed.

This is why translators need complete messages and meaningful variable descriptions. Microsoft's contextual-metadata guidance describes supplying the use and meaning of strings and placeholders. W3C's discussion of composite messages explains the problems caused by assembling reusable fragments. Neither source determines the organization's approval rule; that comes from the responsible business owner.

Write the complete corrected message

The approved fictional notification becomes:

“Mara König hat Fassung R-4 der Spezifikation zu Anfrage Q-46 technisch freigegeben. Sie erhalten diese Nachricht zur Koordination des nächsten Schritts. Eine kaufmännische Freigabe ist damit nicht verbunden.”

The message names the actor, the revision and the technical nature of the decision. It explains why Leon receives it and prevents the notice from being read as a commercial approval. The wording is reviewed as a complete message rather than as interchangeable pieces such as “approved,” “by” and a name.

The project also decides which actor information may be shown to this audience. A public or external notice might require an approved role label rather than a person's name. That is a separate content and access decision. The example's internal audience is authorized to see the named actor; the same assumption should not be carried into every notification channel.

Test the distinction, not just the corrected sentence

The isolated review retains Q-46/R-4 and sends the prepared message to C-9. The receiving record shows C-9 as the recipient, while the rendered message identifies A-17 as the actor. The approval history remains unchanged. Leon can identify the reviewed revision and the next coordination task without believing that he made the decision.

A second fixture uses reviewer A-22 and coordinator C-12 on Q-47/R-2. Its message names A-22, carries R-2 and reaches C-12. This catches a repair that merely hard-codes Mara's name or reuses the first request's revision. A reviewer receiving their own notice is also tested: naming that reviewer remains accurate even when actor and recipient happen to be the same account.

The unknown-actor case is deliberately different. A historical event on Q-48 contains no verified actor. The message must not fill that gap with the recipient's identity. In this exercise it says that a technical approval is recorded for the named revision but that the approving person is not identified in the available record. It directs the coordinator to the responsible reviewer before relying on that history for the next release decision. The missing attribution remains an issue to resolve, not a grammatical inconvenience to hide.

Record the acceptance boundary

The review record contains the template purpose, approved German wording, event fields, recipients and contrasting fixtures. Acceptance confirms the messages for those cases and the preservation of their histories. It does not certify every translation or prove that all historical events have complete attribution.

For your own system, select a message containing “you,” “we” or an implied actor. Place its actual event and recipient beside the text. Ask the language reviewer to explain who acted, on what, and what the reader is expected to do next. If those answers differ from the record, repair the message context before polishing individual words. Workflow application work can make that relationship explicit across the interface and its notifications.