A new booking stores one normalized language_locale. Free captures it at the frontend booking boundary and carries it through booking creation. Pro CSV and OTA writers use a validated supplied locale or provider fallback. Legacy rows without a snapshot use the current provider locale without being rewritten.
Verify a localized booking
- Start in a language-specific route, such as
/vi/search-availability/. - Complete a controlled booking with synthetic guest details and the selected payment method.
- Confirm the signed confirmation, dates, room, totals and payment labels use the booking language.
- Open Hotel Booking → Bookings, inspect the recorded locale and compare the safe summary with the confirmation.
- Check the customer email. It must use the stored locale and the same immutable room, service, tax and payment snapshot.
- With Pro, generate the invoice and confirm its labels, dates, numbers and localized line descriptions use the invoice snapshot locale.
Email rendering uses a scoped locale and restores the previous WordPress locale even when rendering fails. PDF generation does not switch WPML or Polylang global state. Editing a translation or changing the site default later cannot rewrite queued email bodies, invoice rows or existing confirmations.
If an email or invoice falls back unexpectedly, record booking code, locale, template and redacted output. Do not retranslate a historical record by editing its database row. A booking without a recorded locale should be labelled legacy and investigated separately from a provider configuration error.