Multilingual - Plugixa Chauffeur

This page describes exactly what version 1.0.0 does with a multilingual plugin. The short version: the plugin detects WPML and Polylang and its interface text is translatable, but it does not keep separate translations of your vehicles, locations or forms.

What the plugin does

It detects WPML and Polylang

At start-up the plugin’s Multilingual class checks which multilingual plugin is active.

WPML is checked first, so a site with both reports WPML.

It can report the languages

The class wraps both plugins behind one set of methods, for use by other code.

With WPML these read the wpml_current_language, wpml_default_language and wpml_active_languages filters. With Polylang they call pll_current_language(), pll_default_language() and pll_languages_list(). With neither, the language is the first two letters of the site locale, and the language list holds that one language.

$ml = \PlugixaChauffeur\Multilingual::instance();

if ( $ml->is_active() ) {
	$code = $ml->get_current_language(); // for example "fr"
}

Its interface text is translatable

• Every PHP string uses the plugixa-chauffeur text domain, and a template file ships in languages/plugixa-chauffeur.pot. This covers the booking wizard’s labels, the booking emails, the invoice, the default payment method names and the error messages a customer can see.
• The wizard’s labels reach the browser through the plugixa_chauffeur_wizard_i18n filter, so they can also be changed in code. See Hooks reference.
• The wizard formats prices with the site locale.

What the plugin does not do

Be clear about these before planning a multilingual site.

• No per-language content. There is one name and one description per vehicle, vehicle type, location, route and booking form. They are shown as entered, in every language.
• No language filtering. The public booking routes return the same vehicles and routes whatever the visitor’s language. Nothing in version 1.0.0 calls the language methods above; they are groundwork.
• No language switcher in the admin. The admin screens have no language selector and no translation columns.
• No WPML configuration file. The plugin ships no wpml-config.xml and registers no strings with WPML String Translation or Polylang’s string translations.
• Emails are not sent in the customer’s language. A booking does not record the language it was made in. Emails use whatever language WordPress is running in when they are sent.
• Most of the admin app is in English. The navigation labels are translatable, but the field labels and messages inside the admin screens are written in English in the app itself.

About the language columns

The vehicles, vehicle types, locations and drivers tables each have a language_code and a translation_group column. The REST API stores those two values when a location or a vehicle type is created with them, but no screen sets them and nothing reads them back to filter or pair records. Treat them as reserved.

Running a booking form in several languages

What works today:

1. Translate the interface. Add a translation for the plugixa-chauffeur text domain in each language, using the .pot file and your usual translation tool. The wizard’s labels and the customer-facing messages then follow the language of the page.
2. Place the shortcode on each translated page. Translate the page with WPML or Polylang as normal and keep the shortcode in each version. The same form ID works in every language.
3. Name things neutrally. Vehicle names such as “Mercedes S-Class” need no translation. For descriptions, route names and location names, choose wording that works across your languages, or use the site’s main language.
4. Write payment instructions for all audiences. The instructions entered under Settings -> Payments are shown as typed.

If different languages truly need different wording for the same vehicles, that is not supported in version 1.0.0.

Troubleshooting