Choose a complete first release

Consider a fictional Budapest cooking school launching online reservations in Hungarian and English, with German, French and Spanish planned later. Its first translation list should include class descriptions, availability, booking fields, error messages, confirmation emails and cancellation instructions. Translate the information people need to make and manage their decision.

Fewer complete languages are often easier for a small team to maintain than five partly translated journeys. The trade-off is delayed access for some customers. Make that decision deliberately: choose the first languages from actual enquiries and available support, then assign the remaining versions a realistic release plan.

Make switching language predictable

Give customers a visible language selector using language names. On a class page, switching language should open the corresponding class, preserve an unfinished booking where practical and avoid silently changing the selected session. If a translation is missing, explain which language is available before sending someone elsewhere.

Give translated public pages stable addresses that staff can share. Google recommends reciprocal hreflang links between localized pages, including each page itself. Ask the developer to check the equivalent pages together; the language selector and search metadata should describe the same set of available versions.

Separate language from booking facts

MDN documents Intl for locale-sensitive date and number formatting. Ask the team to choose those formats deliberately, while treating the appointment time, time zone and currency as separate business decisions. Changing the display language must not change what the customer is buying.

For the cooking school, a visitor booking from another country still needs the class time in Budapest. Spell out the month where a numeric date could confuse customers, label the relevant time zone and repeat the same details in the confirmation. Test accented names and international phone numbers with realistic sample entries.

Budget for review and ongoing changes

Keep a small content register showing each message, its translations, its owner and its review status. When the school changes its arrival instructions, mark every affected language and confirmation template for review. Otherwise, an accurate translation can become an inaccurate promise after the original changes.

Automatic translation can provide a draft, but budget for someone fluent to check meaning, terminology and tone. Test longer labels on narrow screens. Agree what happens when an urgent update cannot be translated immediately: use an explicit fallback or temporarily withdraw the affected offer, according to its importance.

Use this release checklist

Before adding another language, have a reviewer complete a reservation and then change it. Record unclear wording and missing translations alongside functional defects. The same checklist becomes a useful handover for whoever maintains the next release.

  • Check every step, including validation errors and confirmation messages.
  • Switch languages midway and confirm the selected class remains correct.
  • Check dates, currency labels, accented input and narrow-screen layouts.
  • Assign an owner for translations, customer support and future updates.

Sources and further reading

← Back to Insights