An intake form is a conversation with someone trying to access a service. Translating the field labels is only part of that conversation. Instructions, choices, validation messages, attachment requirements, and the confirmation email all affect whether a client can complete the task. Start with the journey a person takes, then prepare the text and test the finished form.

Map the complete journey

For a settlement agency, community organization, or professional service, the journey may start on an information page and continue through an eligibility explanation, booking form, and appointment email. List those steps in order. Include any downloadable form or instruction sheet that staff send afterward.

  • Page title and short explanation of the service.
  • Field labels, examples, help text, and dropdown options.
  • Required-field indicators and error messages.
  • Upload instructions and confirmation messages.
  • Follow-up emails and directions for getting help.

Clarify the questions before translation

Ask the service team what each answer is used for. A field called “status” could mean the stage of an application, employment status, or something else entirely. Replace that ambiguity in the source with a specific question. Identify which questions are required and which are optional; do not let the translated wording change that distinction.

Keep examples separate from the requested information. If a date format is required, show the format beside the field. If an organization name is optional, make that clear instead of forcing individual clients to invent an answer. These decisions belong to the form owner and should be settled before the language versions diverge.

Provide context for every string

Send a text export with stable field identifiers, screenshots, and an explanation of conditional questions. A translator needs to know whether “Other” reveals a new field and whether “Continue” saves information or merely opens the next step. Keep identifiers and submitted system values unchanged while translating the labels users see.

For example, a service dropdown may store the value “housing_support” while displaying different wording in English, French, and Arabic. Ask the developer to confirm that each language submits the same intended value and sends the request to the correct team.

Keep labels accessible and test Arabic in context

W3C’s form guidance explains that controls need labels associated with them so assistive technology can identify their purpose. Give the translator both visible labels and any separate accessible names. Do not assume translated placeholder text provides the same function as a label.

For Arabic, test names, telephone numbers, email addresses, and reference codes together in the actual form. Right-to-left text and left-to-right identifiers can behave differently when combined. Ask the developer to verify direction handling; a correct sentence in a document is not proof of a correct interface.

Run a realistic completion test

  • Use fictional test data, including a long name and an address with accents.
  • Trigger required-field errors and conditional “Other” fields.
  • Check that keyboard navigation and labels still work in each language.
  • Submit through a test environment and inspect the confirmation and staff notification.
  • Confirm who will update all language versions when the source form changes.

Have someone unfamiliar with the form follow the translated instructions without coaching. Record the points where they hesitate. Linguistic review, functional testing, and accessibility testing answer different questions; plan responsibilities for each before launch.