Make a service request clear in two languages

A customer should understand the same service request whether they read it in English or Spanish. Translating the heading is only a start. The field labels, correction messages, confirmation and next action must describe the same task.

In this Part 3 example, fictional Bridge Repair wants a customer to request a wooden-chair repair. Receiving that request does not book an appointment. Follow the original English/Spanish example, find two copy problems, then use the message map to prepare a specific change in Overskill.

Overskill’s language help distinguishes the language of your prompt from the language of your app’s text. Specify the app language explicitly. That instruction still leaves a practical question: can someone understand the whole journey you built?

Follow one request from choice to receipt

The example has four stages: choose the item, describe and correct it, review the request, then read the receipt. It shows twelve customer-message keys in English and Spanish. Teaching annotations and navigation sit outside that inventory.

This is a fixed illustration. Its “Send request” label does not send anything, and DEMO-R042 is an illustrative ID. The item description is supplied in both languages; no service is translating typed customer text. There is no stored request, appointment or demonstrated Overskill account workflow.

Start with the diagnostic Spanish version. Read it as a customer rather than checking whether every box contains words. When the description is missing, the Spanish error is missing too. The example labels its English fallback visibly. Later, the receipt says “Cita confirmada”—a confirmed appointment—even though the intended result is only a received request.

Both problems interrupt the task. One leaves a correction unexplained in the chosen language. The other changes what the customer believes happened.

Keep missing copy and wrong meaning separate

Give each customer message a stable key. A key lets you discuss the required-field error without calling it “the text under the second box.” Keep the exact source, its revision, the translated text and the source revision that translation corresponds to.

For K07, the English source asks the customer to describe the item before continuing. The diagnostic Spanish value is empty. The corrected example proposes “Describe el objeto antes de continuar.” An English fallback is useful evidence of what is missing; it is not proof that the Spanish task is complete.

K10 presents a different problem. It contains Spanish text, but that text confirms an appointment. The proposed correction is “Solicitud recibida”—request received. K11 then makes the boundary explicit: this is not a confirmed appointment. Review those messages together, not as unrelated translation cells.

Scroll horizontally to compare all columns.

The table describes this fictional copy inventory. It is not a language-quality score or evidence that a customer finished a real request. Download the message-map CSV to inspect every key and Download the filled and blank review card to apply the method to your own task.

Change the promise without leaving an old translation behind

Bridge Repair’s fictional reply policy changes from two working days to three. Only K12’s English source changes. Its retained Spanish text still says “dos días laborables”—two working days—and still refers to source revision 1.

That value is present, but it is stale. The changed-source example keeps the mismatch visible and offers a proposed correction separately: “Te responderemos en un plazo de tres días laborables.” Accept the replacement only after checking that it expresses the intended new meaning. The other eleven source messages did not change; do not mark their translations stale simply because the overall example has a new revision.

For your app, record the affected keys when an offer, response time or instruction changes. Do not invent automatic translation synchronization. A short keyed list is enough to make this review specific.

Read the complete task in the chosen language

Inspect the actual rendered result, including correction and failure states. A translated menu cannot show whether an error remains in another language or a longer label hides the next action on a phone. Follow the task with a keyboard as well as a pointer. Record what happened instead of treating a translated field count as completion.

Keep fixed identifiers separate from display text. The example’s request ID and category ID do not change when its labels change. Decide separately how your app handles text a customer enters; the prepared bilingual item description here does not establish that capability.

Declare the language of the page and of text in another language. W3C’s HTML guidance explains that distinction. A language attribute describes text; it does not translate it or certify its quality. Ask a suitable reviewer to check the wording and intended action, including the confirmation’s limits.

Give Overskill one precise change request

For an existing app, name its actual screen and supply the relevant messages:

On the repair-request journey, provide the supplied English and Spanish labels, required-field message and receipt. A received request must not become a confirmed appointment. Preserve the request and category IDs. Keep missing or outdated wording visible for review. After the change, report which parts of the whole task you tested and which remain untested.

Supply your copy map separately. Use the existing change-request guidance and general usability review for the surrounding workflow.

If a separate build is justified, open the app brief builder, edit its inputs and review the generated brief before choosing Start build. Copy remains a secondary option. The link imports no example or translations. Test the resulting app before asking real customers to rely on it.