Multi-language and localisation

Learn how languages work in Booknetic SaaS across owner admin, tenant admin, booking widget, notifications, RTL, and translations.

Version:
Categories

What localisation means in Booknetic SaaS

Localisation is the way your Booknetic SaaS platform shows the right language, translated labels, regional formats, and customer-facing text to the right audience.

In a SaaS setup, there is not just one language setting. You manage a platform used by different groups of people: you as the SaaS owner, your tenants, and your tenants' booking customers. Each group can see a different surface, so language planning needs to happen in layers.

Use this page when you want to run your platform for more than one market, support tenants in different countries, or make the booking experience feel native to customers who do not use your default language.

The three language layers

Think of Booknetic SaaS localisation in three layers:

SaaS owner layer      → what you see in the owner/admin side of the platform
Tenant admin layer    → what each tenant sees in their own Booknetic panel
End-customer layer    → what booking customers see on the public booking widget

Those layers are connected, but they are not the same setting.

LayerWho sees itWhat it controlsTypical setup area
Owner admin layerYou and your platform teamOwner-side SaaS screens such as Tenants, Plans, Settings, Workflows, billing setup, and platform-wide options.WordPress Settings → General → Site Language and Booknetic SaaS → Settings → General.
Tenant admin layerEach tenant and their staffThe tenant's own Booknetic admin, including services, staff, locations, workflows, settings, and booking setup.Tenant admin settings and the languages you allow from SaaS Settings.
End-customer layerPeople booking appointments with a tenantBooking widget labels, service/location/customer-facing content, notification wording, dates, times, and prices shown during booking.Tenant booking-panel labels, translated tenant data, workflow messages, and the tenant's settings.

This three-layer model prevents a common mistake: changing the owner admin language does not automatically translate every tenant's services, every tenant's workflow messages, or every public booking page.

Which languages are available?

Booknetic SaaS relies on three translation sources working together:

  1. WordPress language files — WordPress controls the general site/admin language foundation.
  2. Booknetic core translations — Booknetic provides translated interface strings for the core booking and admin surfaces where translations are available.
  3. Booknetic SaaS translations — SaaS-specific screens, such as tenant signup/signin and owner-side SaaS features, need SaaS-specific translations too.

The current source-backed SaaS UI locale list includes:

  • English
  • Spanish
  • French
  • German
  • Portuguese (Brazil)
  • Turkish

Your own installation may show language labels instead of locale codes, and available languages can depend on the installed translation files and add-ons. Always check your live SaaS settings before promising a language to tenants.

Important: selecting a language makes Booknetic use the available translation files and translated content. It does not automatically translate your custom services, locations, workflow messages, signup copy, or tenant-written content.

Owner admin language

The owner admin layer is what you and your platform team see while managing the SaaS business.

For the WordPress admin foundation, open WordPress → Settings → General → Site Language and choose the language you want for the site/admin experience.

For SaaS-specific language options, open Booknetic SaaS → Settings → General. In the SaaS settings reference, this area includes language-related controls such as enabling the language switcher for tenants and selecting the languages tenants can choose from.

For the complete settings map, see SaaS Settings reference.

Tenant admin language

The tenant admin layer is what each tenant sees after they sign in to their own Booknetic panel.

If your SaaS setup allows tenant language selection, tenants can choose from the languages you make available. This lets one tenant work in one language while another tenant works in a different language.

For example:

  • Tenant A can manage their booking setup in Spanish.
  • Tenant B can manage their booking setup in German.
  • Your owner admin can still remain in English.

The tenant's admin language does not rewrite another tenant's data. Tenant-owned translations are kept tenant by tenant, so one tenant's Spanish service name does not change another tenant's German service name.

For the tenant panel overview and settings areas, see Tenant admin panel reference.

End-customer booking language

The end-customer layer is the language a customer sees while booking with a tenant.

This layer can include:

  • booking-step labels;
  • service names and descriptions;
  • location names and addresses;
  • category names;
  • custom form labels and help text;
  • workflow notification text;
  • sender names and other message details where multilingual fields are available.

Booknetic stores the language used at booking time on the appointment record. That helps support teams investigate questions such as "why did this customer receive the message in this language?"

Do not describe the booking widget as automatic country/IP language switching. The source-backed safe setup is to provide explicit translations and test the customer journey in each language you want to support.

If your customer asks "can visitors from Turkey automatically see Turkish and visitors from Germany automatically see German?", the safe answer is: configure and test the languages you need, but do not rely on automatic visitor-country detection as a confirmed built-in behavior.

Set up languages before launch

Use this setup order before advertising a multilingual SaaS platform.

1. Set the WordPress Site Language

In WordPress:

  1. Open Settings → General.
  2. Find Site Language.
  3. Choose the language for the owner-side WordPress/admin foundation.
  4. Save changes.
  5. Refresh the admin area and confirm the expected language appears.

This is the base WordPress language. Booknetic and SaaS translation files still need to exist for Booknetic-specific text.

2. Select the languages tenants can use

In Booknetic SaaS:

  1. Open Booknetic SaaS → Settings.
  2. Go to General settings.
  3. Enable the tenant language switcher if your setup uses it.
  4. Select the languages you want tenants to choose from.
  5. Save.

Only select languages you are ready to support. If a language has incomplete translation coverage, tenants may see a mix of translated text and English/default text.

3. Confirm Booknetic translations are present

After selecting a language, test the actual surfaces your tenants and customers will use:

  • owner SaaS settings;
  • tenant admin dashboard;
  • tenant signup and signin pages;
  • booking widget;
  • workflow message editor;
  • emails or channel messages sent from a real test booking.

If some text still appears in English, that usually means the translation for that string is missing or incomplete. See the translation override section below.

4. Translate tenant-owned content

Each tenant should review the content their customers see, especially:

  • services;
  • categories;
  • locations;
  • custom form labels;
  • booking-panel labels;
  • workflow notifications.

This is the content customers actually read during booking. It needs manual review, even when the interface itself is translated.

5. Test with a real booking journey

Create a test tenant and complete the whole journey:

  1. Open the tenant admin in the tenant's chosen language.
  2. Create or edit one translated service, staff member, and location.
  3. Open the tenant's booking URL.
  4. Complete a test booking as a customer.
  5. Check the confirmation screen and notification messages.
  6. Repeat for each language you plan to offer.

Do this before tenants start sharing booking links publicly.

Translation overrides and custom wording

You may want to change a word, fix a missing translation, or use a different term for your market.

Booknetic follows the standard WordPress translation approach, so translation tools such as Poedit or Loco Translate can be used to customize language files. This is useful when you want to:

  • replace a term across a language;
  • translate a missing string;
  • adjust wording to match your brand;
  • support a language where the existing translation is incomplete.

Keep two rules in mind:

  1. Custom translations should be stored safely. Use a workflow that preserves your custom files across plugin updates. If you are not sure where to store them, test on staging first or ask support.
  2. A global wording change affects every matching use in that language context. For example, replacing a word everywhere may change more screens than you intended.

If a tenant only wants to translate their own service name, location name, or booking-panel label, use tenant-side multilingual fields where available instead of changing a global translation file.

Per-tenant translation behavior

Tenant-owned booking content is scoped to that tenant.

That means translations for a tenant's services, locations, categories, and customer-facing labels should affect that tenant's booking experience, not every tenant on your platform.

For example:

  • Tenant A can translate "Dental Cleaning" into Spanish for their own services.
  • Tenant B can use German service names for their own services.
  • Your SaaS owner screens and platform settings are still controlled separately.

This separation is helpful for multilingual SaaS platforms, but it also means tenants are responsible for reviewing their own customer-facing content.

RTL languages such as Arabic and Hebrew

Right-to-left languages need extra testing. Text translation is only one part of the experience; the layout also needs to read naturally.

For RTL languages, check:

  • whether text alignment changes correctly;
  • whether booking steps, arrows, calendars, and progress indicators remain understandable;
  • whether mixed text such as English brand names, numbers, dates, prices, and placeholders stays readable;
  • whether custom CSS or whitelabel styling still works after the layout direction changes;
  • whether notification text reads correctly in Email, SMS, WhatsApp, and Telegram.

Gotcha — RTL needs verification: current source material flags SaaS RTL support as an open QA/localisation item. Do not launch an Arabic or Hebrew SaaS experience without testing the owner admin, tenant admin, signup/signin pages, booking widget, and notification messages first.

For branding and Custom CSS risks, see Whitelabel branding guide.

Notification template localisation

Notification messages are not auto-translated for you.

Your tenants need to write and maintain the message content they want customers to receive in each language they support. This applies to common channels such as:

  • Email;
  • SMS;
  • WhatsApp;
  • Telegram;
  • Mailchimp Transactional Email, Amazon SNS, or Webhook actions if those add-ons are used.

For Email, the tenant may be able to customize sender details such as sender name and reply-to, while the SaaS owner controls the platform mail gateway. For channel setup, see Tenant notification channels.

When your workflow or template editor offers language-specific content fields, fill the subject and body for every language you support. If a customer books in a language where the matching message content is missing, do not assume Booknetic will invent a translation. Use a safe fallback message in your default language and test the exact result.

Gotcha — no automatic translation: Booknetic can store and use translated content where the feature supports it, but it does not write Spanish, German, Turkish, or Arabic message copy for you. The owner or tenant must provide the translated template text.

Dates, times, timezone, and currency

Localisation is not only text. Customers also notice date, time, and price formats.

Date and time format

Date and time display can depend on the site language, WordPress settings, Booknetic settings, and the tenant's own booking setup. Test examples such as:

  • 31/05/2026 vs 05/31/2026;
  • 24-hour time vs AM/PM time;
  • translated month and weekday names;
  • calendar layout in the booking widget.

Booking timezone

For booking availability, use the tenant's business timezone as the operational source. A customer may open the booking widget from another country, but the appointment belongs to the tenant's schedule.

If a tenant serves customers across time zones, make sure the tenant's timezone and booking rules are clear before launching.

Currency and number format

SaaS billing currency is configured by the platform owner, while tenant customer-payment settings live inside the tenant's own Booknetic setup.

For customer bookings, the end customer should see the tenant's configured booking currency and price format, not an automatically converted currency based on the customer's country.

For SaaS plan billing, review the currency settings before you start charging tenants. Changing billing currency after plans and subscriptions are live can create confusion and may not update existing external payment-provider records automatically.

For the broader billing setup, see SaaS Settings reference and Setting up Stripe webhook.

Multi-currency note

Multi-language and multi-currency are related, but they are not the same feature.

A tenant can present their booking prices in the currency configured for that tenant's booking setup. The customer sees the tenant's currency; Booknetic should not be described as automatically converting each customer's price into the customer's own local currency.

Example:

  • A Spanish-speaking tenant may charge in EUR.
  • A Turkish-speaking tenant may charge in TRY.
  • A German customer booking with the Turkish tenant should still see the Turkish tenant's configured booking currency unless that tenant changes it.

For SaaS owner billing, your platform currency is controlled separately from tenant customer-payment settings.

Locale and tenant URLs

Tenant URLs decide where customers open the booking page. Language decides what text they see once they are there.

The current routing guide confirms tenant URLs such as:

https://your-platform.com/tenant-name/

or, in advanced setups, subdomain-style tenant URLs when hosting and DNS are configured for it.

A native language-in-URL pattern, such as /es/tenant-name/, is not confirmed in the current SaaS routing source. If you need language-specific landing pages, handle that carefully in WordPress and test the final booking widget URL.

For tenant booking links and routing, see Tenant URLs and routing.

Common questions

Can I add a language Booknetic does not officially support?

You can usually create custom translations using standard WordPress translation tools, but treat a completely new SaaS language as a project, not a one-click setting.

You need to translate the relevant WordPress, Booknetic core, SaaS-specific, and tenant/customer-facing content. Then test owner admin, tenant admin, signup/signin, booking, and notification messages in that language.

If the language is right-to-left or uses special date/number expectations, include an RTL/localisation QA review before launch.

If my tenant is in Spanish but their customer is German, what does the customer see?

Do not assume Booknetic will automatically switch to German because of the customer's country.

The customer-facing booking widget uses the configured translations and language context available for that tenant/customer journey. If the tenant has Spanish content and no German content, the customer may see Spanish plus any available default interface translations.

The safe setup is to add and test the German translations you want customers to see, then complete a test booking in that language.

Can each location within a tenant have a different language?

Locations can have translated fields such as names and addresses where multilingual fields are available. That helps the same tenant show location information in different languages.

A separate "force this location to use a different interface language" setting is not confirmed in the current source material. If you need location-specific language behavior, treat it as a product confirmation or custom-work question.

Why do some Booknetic strings still show in English after I set another language?

Usually, one of these is true:

  1. The WordPress language is changed, but the Booknetic or SaaS translation file for that string is missing.
  2. The interface string is translated, but your tenant-owned content, such as service names or workflow messages, has not been translated yet.
  3. The active language does not have full translation coverage.
  4. A custom translation override is missing or was not stored in the correct update-safe place.

Fix it by identifying the exact screen and text, then adding or correcting the translation with your normal WordPress translation workflow.

Do notification templates auto-translate?

No. Notification templates need human-written content for each language you want to support.

Booknetic can use translated content where the workflow/template field supports it, but it does not automatically create a Spanish, German, Turkish, or Arabic version of your message.

Can tenants choose their own language?

Yes, when your SaaS setup enables tenant language selection and includes the language in the available list. As the SaaS owner, you decide which languages are available from SaaS Settings.

Does changing the language affect existing appointments?

Existing appointments keep their own booking data. Source material also confirms that Booknetic stores the language used at booking time on the appointment, which can help explain follow-up notification behavior.

If you change language settings after tenants are live, run a test before assuming existing workflows, templates, and customer-facing content all switch exactly as expected.

Gotchas to avoid

Selecting a language is not the same as translating your business content

Language files cover interface text. Tenants still need to translate service names, category names, location details, custom form labels, and workflow messages.

Custom CSS may not behave well in RTL layouts

If you use Custom CSS for branding, test it again in RTL languages. CSS that looks fine in English may break spacing, alignment, or button order in Arabic or Hebrew.

Locale changes may need a fresh session

Some admin screens may not fully refresh language context until the user reloads the page, clears cached browser state, or signs out and signs back in. If a language change looks incomplete, test in a private browser window before treating it as a product issue.

Tenant translations do not automatically become platform translations

A tenant translating their own services or booking labels does not translate the SaaS owner admin. The owner/admin language and tenant-owned customer content are separate layers.

Avoid overpromising automatic visitor detection

Do not promise "Booknetic detects the visitor's country and changes the language automatically." The source-backed safe path is explicit language setup and testing.

Pre-launch checklist for a multilingual SaaS

Before you promote your platform as multilingual, confirm:

  •  WordPress Site Language is set correctly.
  •  Booknetic SaaS language settings are configured.
  •  The languages tenants can choose from are selected.
  •  Translation files are present for every language you advertise.
  •  Tenant signup and signin pages are tested in each language.
  •  Tenant admin screens are tested in each language.
  •  Booking widget labels are translated and tested.
  •  Services, locations, categories, and custom form labels are translated for the test tenant.
  •  Workflow notification subjects and bodies are written manually for each supported language.
  •  Date, time, timezone, currency, and number formatting are reviewed.
  •  RTL languages are reviewed by QA/localisation before launch.
  •  Whitelabel and Custom CSS still look correct after language changes.
  •  Tenant URLs open correctly and do not depend on an unconfirmed language-in-URL pattern.

Related pages