Multi-language and localisation
Learn how languages work in Booknetic SaaS across owner admin, tenant admin, booking widget, notifications, RTL, and translations.
Learn how languages work in Booknetic SaaS across owner admin, tenant admin, booking widget, notifications, RTL, and translations.
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.
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 widgetThose layers are connected, but they are not the same setting.
| Layer | Who sees it | What it controls | Typical setup area |
|---|---|---|---|
| Owner admin layer | You and your platform team | Owner-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 layer | Each tenant and their staff | The 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 layer | People booking appointments with a tenant | Booking 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.
Booknetic SaaS relies on three translation sources working together:
The current source-backed SaaS UI locale list includes:
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.
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.
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:
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.
The end-customer layer is the language a customer sees while booking with a tenant.
This layer can include:
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.
Use this setup order before advertising a multilingual SaaS platform.
In WordPress:
This is the base WordPress language. Booknetic and SaaS translation files still need to exist for Booknetic-specific text.
In Booknetic SaaS:
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.
After selecting a language, test the actual surfaces your tenants and customers will use:
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.
Each tenant should review the content their customers see, especially:
This is the content customers actually read during booking. It needs manual review, even when the interface itself is translated.
Create a test tenant and complete the whole journey:
Do this before tenants start sharing booking links publicly.
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:
Keep two rules in mind:
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.
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:
This separation is helpful for multilingual SaaS platforms, but it also means tenants are responsible for reviewing their own customer-facing content.
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:
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 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:
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.
Localisation is not only text. Customers also notice date, time, and price formats.
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;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.
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-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:
For SaaS owner billing, your platform currency is controlled separately from tenant customer-payment settings.
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.
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.
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.
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.
Usually, one of these is true:
Fix it by identifying the exact screen and text, then adding or correcting the translation with your normal WordPress translation workflow.
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.
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.
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.
Language files cover interface text. Tenants still need to translate service names, category names, location details, custom form labels, and workflow messages.
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.
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.
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.
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.
Before you promote your platform as multilingual, confirm: