CodeCanyon Multi Language - WordPress Plugin

How to Configure CodeCanyon Multi Language for BookPro

CodeCanyon Multi Language is not a standalone booking system. It is a connector add-on for BookPro that helps you build a multilingual booking flow on WordPress with Polylang or WPML. In this guide, we will cover what to prepare before installation, how to enable the add-on without breaking existing services, which BookPro data should be translated first, and how to verify that visitors see the correct language on the booking page.

The most common mistake in multilingual booking setup is translating only the page with the form. For BookPro, that is usually not enough. The full chain includes services, categories, staff, schedules, custom pages, emails, currency, date formats, cancellation rules, the "Thank You" page, and the customer account area. If even one piece stays in the default language, a user may complete the form correctly but still receive an email or post-booking page in a different language.

This article is written for site owners, WordPress administrators, and technical specialists who already use BookPro or are preparing a multilingual service website. We will not cover purchasing, licensing, or activation workarounds. The goal here is practical: prepare a working copy of the site, install the dependencies, connect language versions of pages, and test the full customer journey from choosing a service to receiving the booking confirmation.

What the Add-On Handles and Where Its Scope Ends

CodeCanyon Multi Language is an add-on for BookPro, not a replacement for Polylang, WPML, or BookPro itself. Ovatheme's published documentation states that it requires an active BookPro installation and one of two multilingual plugins: Polylang or WPML. That boundary matters. The add-on should not be treated as a "translate the whole site" tool. It helps BookPro operate in a multilingual environment, but language creation, the language switcher, page translation, and many general translation rules still belong to the multilingual plugin you choose.

In practice, the setup works like this. BookPro handles booking entities: services, service types, schedules, staff, orders, customer pages, emails, taxes, coupons, wallet, calendar, and booking change rules. Polylang or WPML determines the active site language, links translated versions of pages, and provides tools for translating strings, posts, taxonomies, and custom data types. CodeCanyon Multi Language sits between them and makes the BookPro workflow usable in a multilingual build.

The add-on is especially useful when a business serves multiple audiences on one site: a salon works with local clients and tourists, a medical office accepts patients in different languages, a school runs classes for both Russian-speaking and English-speaking groups, or a service center presents services across multiple regions. In those cases, translating the site's regular pages is not enough. You need the booking form, service list, customer actions, and booking outcome to feel consistent instead of looking like a mix of languages.

That said, do not expect the add-on to validate translation quality automatically. If a service name is translated incorrectly, if a customer page has no language version, or if a confirmation email is left in the default language, the plugin cannot understand the business meaning of that text on its own. That is why proper setup feels more like editorial assembly: first identify which parts of BookPro the customer sees, then translate those contact points, then run a test booking in each language.

Who This Multilingual Booking Approach Is Best For

The best fit for CodeCanyon Multi Language is a site where BookPro is already the main booking system and multilingual support is needed specifically for the customer-facing workflow. If your site already uses services, staff, schedules, customer accounts, coupons, WooCommerce payments, or offline payments inside BookPro, moving to a different booking plugin may be more expensive than carefully localizing the current system. This add-on lets you keep the familiar BookPro structure and add a language layer using standard WordPress tools.

This approach works especially well for service websites where customers need to understand every step before booking: choosing a category, checking the duration, comparing pricing options, selecting a staff member, reading cancellation terms, receiving an email, and returning to their account. In a multilingual version, it is especially important for the translation to be not just polished, but operationally accurate. For example, if a customer sees "60-minute consultation," the email should confirm that same service, and the staff member should see the booking in the schedule without duplicates or confusion.

When the Add-On Makes the Most Sense

Use this approach if your site is already built on BookPro and the content side of the site is translated with Polylang or WPML. Good use cases include:

• A service website with multiple language versions of pages and one shared booking system.
• A salon, clinic, studio, training center, or service company where the customer needs to book a specific specialist.
• A project where translated service names, descriptions, customer pages, and post-booking messages matter.
• A site with languages that differ in writing direction or local formatting, such as English and Arabic.
• A team that needs BookPro connected to an existing multilingual stack rather than a full move to another booking plugin.

When It Is Better to Revisit the Architecture First

The add-on may not be the best starting point if the site does not use BookPro yet and the whole task is simply a basic two-language "book a consultation" form. In that case, it is worth comparing BookPro with alternatives whose multilingual approach is built differently or is simpler for your workflow. It is also not a good idea to start installation on a live site without a backup if you already have a large number of orders, complex coupons, WooCommerce payments, and customer account pages.

You should also set realistic expectations around automatic translation. In a standard setup, Polylang is more focused on manual control over languages and translations, while WPML offers a more developed translation workflow and String Translation. But neither option removes the need for human review. In booking workflows, automatic translation without manual checking is risky: a mistranslated service, cancellation term, or email can lead to a real customer dispute.

Practical takeaway: Think of CodeCanyon Multi Language as a bridge between BookPro and your chosen language plugin. It helps you assemble a multilingual booking system, but the quality of the final result depends on how carefully you translate every point in the customer journey.

What to Check Before Installation

The preparation step is not just a formality. Multilingual support touches content, custom data types, URLs, emails, cache, customer accounts, and sometimes WooCommerce. If you install the add-on directly on a working site and immediately start translating services, you can easily create a split state: one language version of a page is already published, another is not ready, the calendar still shows an old string, and the email goes out in the default language. That is why you should first lock down the current state.

Core Dependencies

According to the add-on documentation, BookPro and either Polylang or WPML must be active before installation. Ovatheme also lists PHP requirements across current 7.x and 8.x branches, with a recommendation to use a modern 8.1.x branch. We are not tying this article to a specific WordPress version because that information changes on the CodeCanyon product page. Before installation, check the current compatibility line on the product page and in the BookPro listing.

Before you begin, make sure that:

• BookPro is installed, activated, and its sections open without PHP errors.
• You have chosen one multilingual plugin: Polylang or WPML. Do not run multiple translation systems at the same time unless you have a very clear reason.
• You have a backup of both site files and the database.
• You have a test page with the booking form where you can safely complete a booking.
• Page cache and JavaScript optimization are temporarily disabled or ready to be cleared after setup.
• The administrator has access to hosting error logs, or at least to debug mode on a staging copy.

Inventory Your BookPro Setup Before Translating

Before installing the add-on, it is useful to list every BookPro element the customer can see. Do not stop at the booking form page. BookPro includes services, service types, schedules, staff, customer pages, a thank-you page, login, registration, password recovery, customer account, order list, wallet, favorites, profile, booking management, notifications, and calendar actions. Some of these appear before the booking, some after, and some in emails or inside the account area.

Create a simple table in a working document with columns like "element," "location," "customer-visible," "translation needed," and "how to test." That inventory saves time. For example, if your service business does not use wallet or payout features, there is no need to spend the first phase translating those screens. But if the customer lands on a "Thank You Page" after booking, that page should have a language pair and should be selected in the BookPro settings so it behaves correctly.

Choosing Between Polylang and WPML

If Polylang is already in use on the site, it usually makes sense to start there. It is well suited for manually linking pages, posts, terms, media, and strings, and it also provides a language switcher as a block, menu item, or widget. If the project involves translators, complex custom types, a translation queue, and a need to translate plugin strings through a dedicated module, WPML is often more convenient because of String Translation and the Translation Dashboard.

Do not choose a system based only on the product card mentioning its name. Look at the workflow. For a small two-language service site with manual translations, Polylang may be enough. For an agency project with dozens of services, customer account pages, emails, and repeated interface strings, WPML may provide a more manageable process. In either case, the language switcher should take the user to the matching language version of the booking page, not just switch the site header language.

Installation and First Launch Without Putting Bookings at Risk

Installing CodeCanyon Multi Language is similar to installing a regular WordPress ZIP plugin, but the dependency order is critical here. BookPro must be working first, then Polylang or WPML, and only after that the add-on. If you enable the add-on earlier, it may not find the required language system or the base BookPro entities. Even if WordPress does not show a fatal error, the behavior can be difficult to diagnose.

Installation Order

1. Confirm that BookPro is active and opens without errors in the admin panel and on the test booking page.
2. Install and configure Polylang or WPML: add languages, set the default language, and verify the switcher and URL structure.
3. In WordPress, open Plugins - Add New Plugin - Upload Plugin.
4. Select the file ovabookpro-language.zip, which the add-on documentation lists as the installation package.
5. Click Install Now, then Activate Plugin.
6. Clear the site cache if it is enabled, then open the test booking page in each language version.

After activation, do not jump straight into translating everything. First make sure the existing single-language booking form still behaves the same way: the calendar opens, slots are visible, the service can be selected, the coupon or price shows as before, and a test booking is created in BookPro. That is your rollback baseline. If a problem appears at this stage, fix it before you start translating content.

How to Update the Add-On

Ovatheme documentation describes two approaches: automatic updates through the Envato Market WordPress Plugin and manual updates by downloading the package from CodeCanyon again and replacing the plugin files. On a production site, it is safer to update on a copy first. BookPro, the language plugin, and the add-on form a chain, so a change in one link may only show up later on the booking page or in emails.

If you update manually through a file manager or SFTP, do not mix up the archives. The BookPro installation package has a different filename from the language add-on package. For CodeCanyon Multi Language, use ovabookpro-language.zip specifically. Before replacing anything, make sure you have a backup of the current plugin directory and the database, because translations and mappings are usually stored in the database, not just in files.

Do not update BookPro, Polylang/WPML, and the language add-on all at once on a live site. Split the changes: first the base plugin, then the language system, then the add-on. After each step, run a short booking test.

How the Add-On Connects BookPro to Polylang or WPML

In Ovatheme's published documentation for the add-on, the basic model is described using a site example with English and Arabic, and Polylang or WPML is recommended for creating multiple languages. That points to a practical principle: the active language should be determined by the language plugin, while BookPro should receive enough data to display the matching translations for its elements on the public-facing site.

From the administrator's point of view, this is not a single toggle that says "make everything multilingual." The setup has several layers. The first layer is WordPress pages: the booking page, login page, registration page, password recovery page, customer account page, and thank-you page. The second layer is BookPro data: services, types, descriptions, staff, schedules, coupons, emails, and custom labels. The third layer is behavior: where the customer is redirected, which URLs are shown, how endpoints are built, and how date format and calendar language are chosen.

How Polylang Works Here

In Polylang, you need to create languages, link translated pages, and make sure every existing item has a language assigned. Polylang documentation specifically notes that posts, pages, categories, and custom data types must have a language, or they may not appear on the front end. That is especially important for BookPro if its services or types are represented as WordPress custom post types or taxonomies.

Strings that are not separate pages or posts are handled through the string translation area. Polylang lets you translate custom strings such as the site title, widgets, and strings registered by a theme or plugin. If BookPro or the add-on registers the relevant strings in the standard way, they should appear in the translation table. If a specific string is missing, do not jump to workaround code. First check the documentation, cache, active language, and the state of the field in BookPro itself.

How WPML Works Here

WPML aims for the same result, but the workflow is different. Pages and custom data types are translated through the Translation Dashboard, while plugin, theme, widget, and admin-setting strings are handled through String Translation. WPML documentation also explains how to configure the translation behavior of custom post types and taxonomies. That is useful for BookPro because a service, service category, or related entity may need its own "Translatable" setting.

If the BookPro data type you need does not appear in the Translation Dashboard, check WPML - Settings - the post type and taxonomy translation options. Do not blindly turn on translation for everything you find. Some BookPro system entities may be technical in nature and not meant for editorial translation. Start with what the customer actually sees: services, types, pages, and strings in the public booking form.

What You Should Not Translate Mechanically

Do not translate system order statuses if they are used only inside the admin panel and are not shown to customers in emails or account pages. Do not translate technical slugs if that could break links before you understand how your chosen language plugin handles URLs. Do not translate the same string in several places without checking its source. Sometimes a public-facing label comes from a BookPro setting rather than the language plugin's string catalog.

A good workflow is to translate one group, test the outcome, and then move to the next. For example: pages first, then services and types, then the booking form, then emails, then the customer account area. That order helps you quickly identify where a problem appears.

Which BookPro Data to Translate First

BookPro includes many features, but not all of them matter equally for the first multilingual launch. Start with the customer journey. A user lands on a service page, chooses a date and time, adds one or more services, selects a staff member, applies a coupon, sees the final price, submits the form, reaches the thank-you page, receives an email, and later opens their account. That path should become your test framework.

Services, Types, and Descriptions

BookPro documentation shows that when you add a service, you define the name, type, duration, price option, description, color, staff, and discounts. On a multilingual site, there are several layers here. The service name should be clear in every language. The description should explain conditions and limitations without awkward machine-generated phrasing. The service type matters if the customer chooses by category. The price option and duration should stay logically consistent across languages unless the business runs separate regional price lists.

Start with one representative service. Create or choose a service that already has a clear description, an assigned staff member, and working time slots. Translate the name, description, and type. Then open the language version of the booking page and make sure that exact service is visible in the target language. If the service disappears, the cause is often not the add-on but the fact that no language is assigned, no language pair has been created, or the selected data type is not enabled as translatable.

BookPro Pages and Endpoints

BookPro uses a set of pages and shortcodes for the account, login, registration, password recovery, password reset, thank-you page, and user roles. In BookPro settings, these are selected as specific WordPress pages. In a multilingual build, each of those pages should have a translated version, and the language switcher should not send the customer back to the homepage without context.

In BookPro, an endpoint is an additional URL segment that shows different content inside the same page. For example, the account page might show the profile or account editing screen through different URL endings. On a multilingual site, check two things: the base account page must be translated, and the endpoint must open the right content after a language switch. If changing the language sends the customer to an empty account page or a 404 page, first resave the WordPress permalinks, then review the endpoint settings in BookPro and the page mappings in the language plugin.

Calendar, Time, and Interface Language

BookPro includes calendar settings such as date format, time zone, time format, time step, calendar language, days off, and first day of the week. These are not just text labels. They affect how the customer understands availability. On a multilingual site, pay close attention to the calendar language, because month names, weekday names, and date order are often seen as a trust signal.

Do not change the time format just for translation purposes. If the business operates in one country and serves customers in multiple languages, a single time zone and a single scheduling model are usually safer. If the site truly serves multiple regions, spell out the rules on the page and in the emails. BookPro shows slots based on schedules, business hours, staff days off, service duration, and existing bookings. Multilingual support should not create separate independent schedules for the same staff member if the business expects one shared calendar.

Emails, Statuses, and Post-Booking Messages

BookPro includes email notifications for new bookings, cancellations, changes, and other events, and orders use statuses such as pending, processing, completed, canceled, refunded, and expired. In customer-facing communication, those strings need to be clear. If emails remain in the default language, users may assume the booking failed or was sent to the wrong branch.

For the initial launch, translate at least three communications: the new booking confirmation sent to the customer, the notification sent to the administrator, and the text on the page shown after a successful booking. Then add cancellation and rescheduling emails if those features are enabled. Check not just the email subject line, but also the variables: customer name, service, date, time, amount, and account link. The translation must not break shortcodes or placeholders if they are used in the email template.

Detailed Configuration After Installation

Once the add-on is active, the easiest way to configure it is to think in terms of five areas: languages, pages, translatable data, form behavior, and message verification. Do not try to solve everything from one screen. Multilingual BookPro works reliably when each area is configured separately and tested through a real action.

Step 1. Languages and URL Structure

In Polylang or WPML, create the languages, assign the default language, and choose the URL structure. For most service sites, separate language prefixes work well because they are easier to test, index, and explain to users. After that, add the language switcher to a menu, header, or widget area, but do not judge the setup by the switcher's appearance alone. What matters is where it takes the customer on the booking page.

Check this carefully: the Russian service page should switch to the matching English or other language version, not to the homepage. If a page translation does not exist yet, it is better to temporarily hide the link or send users to a clear language-specific homepage than to leave them on an empty template. Polylang includes a switcher behavior setting that may send users to the homepage if no translation exists, so keep that in mind during testing.

Step 2. BookPro Pages

Create language versions of the main pages selected in BookPro - Settings - General. According to BookPro documentation, that section selects pages for the account, thank-you page, login, registration, password recovery, password reset, and the default pages for staff and customers after login. Each page should include the correct shortcode or block if BookPro requires one there.

Example checklist:

• The account page contains [obp_member_account] or the matching BookPro block.
• The login page contains [obp_login].
• The registration page contains [obp_register_user].
• The password recovery page contains [obp_forgot_password].
• The password reset page contains [obp_reset_password].
• The page shown after a successful booking exists for every language and opens without redirecting to another language.

If a shortcode exists only on the default page, the translated version may look like an ordinary blank page. Do not mechanically copy content through the visual editor if the translation plugin provides a proper duplication feature. Create the language pair first, then verify the shortcode, then adapt the visible text.

Step 3. Translating Services and Categories

Open the BookPro admin panel and locate the services that are actually published on the site. For each service, review the name, type, description, duration, price option, discounts, and assigned staff. It is not enough to translate only the long description. The type name, price option label, discount text, and short hints may also appear in the form or service card.

If you use the shortcode [obp_services ids="14,15,16"], check which IDs belong to the translated service versions. In some multilingual setups, the translation gets its own ID. That means the shortcode on the translated page may need a different set of IDs or a separate display rule. Do not change IDs on the live site without testing first. Open the page in a private window and make sure the service list matches the language.

Step 4. Booking Form and Slot Behavior

BookPro calculates available time based on several conditions: schedules, business hours, staff days off, service duration, and existing bookings. Multilingual support must not break that calculation. If the English and Russian versions of one service both point to the same real staff member, a booked slot should disappear in both language versions. This is a critical test, because otherwise the site could accept two bookings for the same time.

The check is simple: create a test booking in one language, then open the page for that same service in the second language and look at the same day and time. Expected state: the occupied slot should not be available again. If it still appears as available, check the service translation mapping, the staff assignment, the schedules, and whether you accidentally created separate services instead of language versions of the same entity.

Step 5. Emails and Messages

After the form works in testing, move on to the emails. Open the BookPro notification templates and translate the customer-facing text. Leave system variables, shortcodes, and technical links exactly as they are. If WPML String Translation or Polylang Strings displays BookPro strings, translate only the visible phrases there and do not change keys or identifiers.

For email templates, three things matter: language, meaning, and data. The language should match the page where the customer submitted the booking. The message should be clear even without any knowledge of the admin panel. The data should match the order: service, staff member, date, time, amount, and account link. If an email still arrives in the default language, check where the template comes from: BookPro settings, string translation, the translated page version, or the site's general email module.

Translating Strings, Pages, and Shortcodes Without Creating Chaos

In multilingual BookPro, there are two different kinds of text. The first is regular content that the editor sees as a page, post, service, service type, or description. The second is interface text: a button, error message, field label, email subject, status text, or label inside the form. Problems start when those two types get mixed up. An administrator looks for a button in the translated page, even though the button comes from plugin strings. Or the opposite: someone tries to translate the service description through String Translation even though it is a field on the service itself.

To avoid that confusion, use a simple rule: if the text is edited in the service card or on a WordPress page, translate the entity itself first. If the same text appears in multiple places and is not tied to a specific service, look for it in Polylang or WPML strings. If the text belongs to an email, check the BookPro notification template or WooCommerce if the payment flow runs through WooCommerce. This order saves hours because you are not guessing your way through every panel.

How to Work With Shortcode Pages

BookPro uses shortcodes to output individual pages and service lists. The documentation includes an example like [obp_services ids="14,15,16"] for displaying specific services by ID, and the page settings also use shortcodes for the account, login, registration, and password recovery pages. In a multilingual environment, the shortcode itself is not the translation. It simply tells BookPro which functional block to render on that page.

That means each language page should have meaningful content around the shortcode. For example, the Russian page might explain booking terms, cancellation rules, and visit preparation in Russian, while the English page should convey the same meaning in English. The shortcode itself may stay identical if BookPro and the language plugin correctly select the translated data. But if the shortcode hardcodes service IDs, check whether the translated page should use the IDs of the translated service versions instead. This is not a minor SEO detail. It is an operational risk: the wrong ID can display the wrong language service or even the wrong staff member.

After changing a shortcode, always test the page as a guest. Administrator mode sometimes shows more data than a regular user sees. Open a private window, choose the language, go to the page, select the service, and continue to the time-selection step. If the service is visible only to the administrator, check the publish status, the entity language, the translation mapping, and the access permissions.

How to Avoid Breaking Variables in Emails

BookPro and WooCommerce emails may contain variables, shortcodes, or placeholders that insert order data. You cannot translate those like regular text. If a template includes a token for the customer name, order number, account link, or booking date, leave the token itself untouched and translate only the surrounding text. This matters even more in languages with a different word order. It is better to rewrite the sentence around the variable than to change the variable and lose the data.

A proper email test should include more than simply receiving the message. Open the email and compare it with the order inside BookPro: service, date, time, staff member, amount, status, and link. Then click the account link. If the link opens a page in the wrong language, the problem is not the email subject. It is the page mapping, endpoints, or redirect behavior. If the data did not populate, roll the template back to a backup version and repeat the translation more carefully.

Strings That Should Stay Technical

Not every English fragment in the admin panel needs to be translated. Exact interface item names, system statuses, hook names, shortcodes, slugs, and internal keys should remain stable unless the documentation explicitly says otherwise. On the public side of the site, the customer should see clear language, but admin-side troubleshooting is often easier when technical terms match the documentation. That is why this guide presents such elements in code and does not turn them into loose free-form translations.

If your site team includes both an editor and a technical specialist, split the responsibilities. The editor handles the meaning of service names, descriptions, terms, and emails. The technical specialist handles pages, shortcodes, endpoints, cache, translation settings for data types, and booking tests. That approach reduces the risk of an editor accidentally changing an ID in a shortcode or a developer leaving a machine-translated customer email in place.

BookPro Features That Matter Most in a Multilingual Setup

BookPro goes well beyond a simple "choose a date" form. It includes schedules, staff, discounts, coupons, taxes, wallet, roles, reCAPTCHA, calendar integrations, booking changes, and cancellations. Not every site needs all of these, but every enabled feature adds another point where language and data can drift apart. After the base CodeCanyon Multi Language setup is in place, test the modules your business actually uses.

Schedules, Business Hours, and Staff Days Off

BookPro slots depend on schedules, business hours, staff days off, service duration, and existing bookings. In translation terms, that raises an important question: should the translated version of a service use the same real schedule or a separate one? For most sites with one physical schedule, the answer is simple: the same one. If a staff member is booked, they are booked in every language. If the salon is closed on Monday, the page language should not make Monday suddenly available.

Check not only slot visibility, but also interval timing. If one language version shows the service as 30 minutes while another was mistakenly copied as 45 minutes, the calendar may start showing different availability. The same applies to days off. If a staff day off is set only in one copy of the entity, the site will accept bookings unevenly. After translating a service, open the staff schedule and confirm that the translated version did not create a separate independent calendar.

Discounts, Coupons, and Tax Labels

BookPro documentation shows that a service can have date-based discounts, and the booking form can account for coupons, subtotal, system fee, discount rate, and tax. In a multilingual version, the numbers should match and the explanatory text should be clear in the customer's language. If a customer sees a discount on one language page but not on another, check not the translation but the discount conditions: booking date, service date, selected service, and coupon.

Tax labels and the final total are especially sensitive. Do not translate them too freely if their legal meaning depends on the country. A short, clear wording with a link to the terms is better than a long machine-translated paragraph. If WooCommerce is part of the payment flow, test the cart and checkout page in every language as well. BookPro may display the amount correctly while the WooCommerce email or checkout still remains in the default language unless configured separately.

reCAPTCHA and Account Forms

BookPro lets you enable reCAPTCHA for several forms: login, registration, password recovery, and the booking form. In a multilingual workflow, this is not only spam protection but part of the customer experience. If reCAPTCHA breaks form submission in one language, the customer will not understand that the issue comes from the security layer rather than the booking itself. That is why every form using reCAPTCHA should be tested after activation.

Do not turn on reCAPTCHA for every form at once if the site is still going through translation setup. First test the booking flow without it, then enable protection for the booking form, then for registration and password recovery. If the error appears only after activation, check the keys, domain, cache, and JavaScript optimization compatibility. The error message should be understandable to the customer, but the site key and secret key should never be placed in public materials or passed to an article generator.

Booking Changes and Cancellations

BookPro includes dedicated booking change settings. You can allow or block customers from changing an appointment, set a limit on the number of changes, and define the minimum time before the booking. For changes and cancellations, not only the technical permission matters, but also a clear translated explanation of the rules. Customers should understand in advance when they can reschedule, how many attempts they have, and why a button becomes unavailable before the visit.

Test these rules on a sample booking. Create an order, open the customer account in the user's language, try changing the time, then cancel the booking if that feature is enabled. Look not only at the button, but also at the denial message. If the rule works but the explanatory text is not translated, the user will read it as an error. If the text is translated but the rule does not work, check the minimum time, order status, and BookPro settings rather than the language plugin.

Calendar Integrations and Export

BookPro lets you add bookings to Google Calendar and Apple Calendar through iCal, and it also supports CSV export for orders. These are internal business tools, but they can still suffer from incomplete multilingual setup. If a staff member receives a booking in their calendar, the service name and customer data should be understandable. If a manager exports orders for reporting, mixed-language service names can make sorting harder.

For a multilingual site, decide which language should be used in internal reporting. Sometimes it is more practical to keep internal service names in the team's language and translate only the public descriptions. In other cases, the business needs fully localized export data. In either case, do not leave this to chance. Run a test export and see how it will actually be used.

Use Case: Bilingual Booking for a Service Studio

A practical example shows how to use CodeCanyon Multi Language for a real-world task. Imagine a service studio that serves customers in Russian and English. The goal is for a visitor on the Russian page to see the Russian service name, choose a time, receive a confirmation in Russian, and open the account area. An English-speaking visitor should go through the same flow in English, but both versions should book against the same real staff calendar.

Goal

Create two language versions of one BookPro service without splitting the schedule. The site has a page called "Book an appointment" and its translated version, one shared staff member, one set of business hours, and one consistent rule for occupied slots. The user should never see mixed languages: the Russian version should not show English hints outside the UI, and the English version should not contain Russian cancellation terms.

Preparation

Before you begin, BookPro, CodeCanyon Multi Language, and one language plugin must already be active. Polylang or WPML will both work for this example, since the overall approach is similar. You also need one configured BookPro service with a duration, pricing option, and assigned staff member. Make sure that without the multilingual layer, the service can already be booked in the default language.

Setup Steps

1. Create two booking pages: the main page and its translation. Link them in Polylang or WPML.
2. Place the BookPro form or shortcode on each page so it outputs the target service or service list.
3. Translate the service name, description, and type. If the translation creates a separate ID, record it in your working table.
4. Check the staff assignment. If this is one real specialist, the staff member should remain linked to the service in both language versions.
5. Translate the visible form strings through the tools of the selected language plugin or through BookPro settings if the string comes from there.
6. Set up the thank-you page for each language and select the matching pages in BookPro settings.
7. Create a test booking in the first language, then check the availability of the same slot in the second language.
8. Review the customer email, admin email, and the booking entry in the BookPro orders section.

Expected Outcome

On the Russian page, the visitor sees the Russian service name, a clear description, and the correct terms. On the English page, they see the English version of that same service. If a booking is made in one language, the occupied time should also be blocked in the other language version. In the BookPro admin panel, there should be one booking, not two separate duplicates. In the email, the customer should receive the details of the booking they actually made.

The Most Commonly Missed Pitfall

If the translated versions are created as separate services without a shared link to the real schedule, the site may behave as if you have two different booking products. On the surface, it looks like translation, but operationally these are two different entities. For a business with one staff member and one schedule, that is dangerous. That is why after each language version is set up, you should verify not only the text but also slot occupancy, the order list, and the staff calendar.

How to Verify the Setup After Configuration

The final test should mirror a real customer journey, not just an admin checklist. Open the site in a private window, choose the language through the switcher, go to the service page, complete a booking, check the thank-you page, the email, and the account area. Then repeat the same flow for the second language. If WooCommerce payment is enabled, use a test payment method or a safe payment gateway sandbox, but do not run live charges unless absolutely necessary.

Customer Journey

Check these points:

• The page URL contains the expected language or opens the correctly linked language version.
• The language switcher does not reset the selected service to the homepage without explanation.
• The service name, type, description, form hints, and buttons appear in the correct language.
• The date, time, currency, and final amount are displayed in a format the site's audience can understand.
• After the form is submitted, the customer lands on the thank-you page in the same language.
• The customer email arrives in the correct language and includes the correct service, time, and account link.
• In the customer account area, the order appears without mixed-language labels in key actions.

Administrator and Staff Workflow

The admin-side check matters just as much. In BookPro, open the orders section and confirm that the status matches the customer action. BookPro documentation describes statuses such as pending, processing, completed, canceled, refunded, and expired. Translating public-facing labels should not prevent the administrator from seeing the real order status. If staff members use the front-end schedule, check their calendar too. The booking should appear in the shared schedule and in the individual staff schedule.

If calendar integrations, CSV export, Google Calendar, or iCal are enabled, test them separately. BookPro can add bookings to Google Calendar and Apple Calendar through iCal, but that action depends on calendar settings and the order status. Do not consider the setup complete until you have seen a real booking reach the place where the staff member will actually look for it.

Mini Acceptance Checklist

For each language version, create one test booking and fill out a short acceptance log:

SEO, Indexing, and User Experience for Multilingual Booking

A multilingual booking page affects not only customer convenience but also search visibility. That said, in a booking workflow SEO should stay subordinate to service accuracy. Do not create language pages filled with machine-generated text just to increase page count. Two carefully translated pages where the service name, terms, address, duration, and booking process are clear are better than five language copies with the same mistakes.

Language URLs and Service Pages

Polylang and WPML usually let you create separate URLs for each language version. That is useful for services because both search engines and users can reach a dedicated page in the right language. Make sure canonical tags, hreflang, and language mappings are generated correctly by the plugin you chose. Do not manually add conflicting SEO tags if you do not fully understand how your SEO plugin interacts with Polylang or WPML.

If BookPro outputs the service list through a shortcode on a regular page, optimize that page itself: title, short description, FAQ, address, neighborhood, booking terms, and contact details. The shortcode alone does not replace useful content. On a multilingual site, each language version should have its own natural text rather than the same list of keywords reused everywhere.

Date Formats, Currency, and Trust

BookPro includes settings for currency, symbol position, separators, date format, time zone, time format, and the first day of the week. These settings help users understand what they are booking. If the site serves an international audience, make sure the date format does not look ambiguous. For example, a numeric date can be read differently in different countries. When in doubt, use a format with the month name or add a clarifying note on the page.

Currency is especially important if BookPro works with WooCommerce. Do not imply that customers will pay in a local currency if the actual checkout uses a different one. It is better to explain the terms clearly on the service page and in the email. On a multilingual site, trust depends on consistency: the page language, the currency, the email, and the final amount should not contradict each other.

Cache and Dynamic Forms

A booking page is not the same as a static article. It shows availability and reacts to the selected service, staff member, date, and existing bookings. Aggressive caching can store a fragment of the form in one language or with an outdated slot set. After configuring CodeCanyon Multi Language, test the page with caching disabled, then turn caching back on and add exclusions if the form behaves strangely.

For most sites, the safe approach is to cache the content portion of the page while treating AJAX requests, the customer account area, the WooCommerce cart, and post-booking pages more carefully. Do not add custom JavaScript to force the form language if the real issue can be solved through language plugin settings or a cache exclusion. A quick script may hide the symptom, but it will not fix the underlying data.

Common Problems and How to Diagnose Them

Most multilingual BookPro issues look like "the add-on is not working," but the actual cause is often in a different layer: the page is not linked, the service has no language assigned, a string was not translated, cache is showing an old form, an endpoint was not resaved, or the email pulls text from a separate template. Below is a symptom-based troubleshooting path worth following before contacting support.

Services Disappear After Switching Languages

Symptom: the service list is visible in the default language, but the form is empty or incomplete in another language version. A likely cause is that the service, service type, or page has no assigned language, the translation is not linked to the original, the shortcode contains only the source service IDs, or the BookPro data type is not marked as translatable in WPML.

Check the page language mapping first, then the service itself and the service type. If the shortcode uses specific IDs, find the IDs of the translated versions. If you are using WPML, review the translation settings for custom post types and taxonomies. Fix one element at a time, and after each change open the page in a private window.

The Form Shows Mixed Languages

Symptom: the service name is translated, but buttons, error messages, or some helper text remain in the default language. The reason may be that some strings come from the translated service, others from BookPro settings, and others from strings registered by the plugin for Polylang or WPML String Translation.

First identify the source of the string. If it is the service name or description, look for the translation in the service entity. If it is a system button, check string translation. If it is text from the email or thank-you page, look for the template in BookPro settings. Do not edit the plugin files. Updates will overwrite those changes, and a mistake in PHP or JS can break the booking flow.

An Occupied Slot Is Still Available in Another Language

Symptom: a customer books in one language, but the same staff member and time are still available in another language version. This is one of the most serious failures. A likely cause is that the translated service became an independent entity with its own schedule, the staff mapping is inconsistent, or the tested pages are outputting different services.

Check the chain "service - staff - schedule - duration." Create a test booking, then open the shared calendar and the staff schedule. If the booking appears in the schedule but the second language still shows the slot as free, check the shortcode IDs and translation mapping. If the booking does not appear even in the staff schedule, the issue is no longer translation-related. It is a base BookPro configuration problem.

After Booking, the Wrong Language Page Opens

Symptom: the form is completed in Russian, but after submission the customer lands on the English thank-you page, or vice versa. The cause is often in the BookPro page setup: only one Thank You Page is selected, the language pair is not linked, or the redirect does not respect the active language.

Check the pages in BookPro - Settings - General. Create translated versions of the thank-you page and make sure the language switcher recognizes them as translations. If the problem persists, temporarily disable cache and redirect plugins, then repeat the test.

The Customer Account Area or Endpoints Return 404

Symptom: the customer logs in, but the profile, orders, or account editing section opens with an error. BookPro uses endpoints, which are extra URL segments that display different screens inside one page. In a multilingual build, the issue may appear after a page slug change, a translated base URL, or an update to permalink rules.

Resave WordPress permalinks without changing the structure, then review the endpoint settings in BookPro. Make sure the account page exists in every language and contains the required shortcode. If an endpoint conflicts with the slug of another page, rename the slug intentionally and retest every email link.

The Email Arrives in the Wrong Language

Symptom: the form and thank-you page are correct, but the customer email arrives in the default language. Check where the email template is stored. If it is a BookPro setting, translate it through the available string mechanism or through a separate language template if your setup supports one. If the email is sent through WooCommerce, also review WooCommerce email settings and your language plugin's WooCommerce compatibility.

Check the variables and shortcodes in the email separately as well. They cannot be translated like ordinary words. If the email loses order data after translation, restore the template from backup and change only the visible text around the variables.

When It Is Better to Roll Back the Setup

Roll back changes if the setup starts creating duplicate bookings, the form stops creating orders, the customer receives an email with incorrect data, or the account area becomes inaccessible. Text translation can be improved gradually, but failures in order creation and slot occupancy cannot be left for "the next release." First restore a stable single-language setup, then re-enable the multilingual layer on a staging copy.

Safe Improvements Without Editing Plugin Files

With CodeCanyon Multi Language, you should avoid adding random PHP snippets. The public documentation does not provide confirmed hooks specifically for this add-on, and invented code inside a booking system is risky. It is safer to rely on BookPro settings, Polylang or WPML tools, your SEO plugin, cache exclusions, and light theme-level CSS if you only need to adjust the appearance of the language switcher or language hints.

What You Can Safely Improve

• Add a language switcher near the booking form if the site header is too far away or hidden on mobile.
• Place a simple translated explanation of cancellation and rescheduling terms above the form on each language page.
• Create a separate test service for translation checks so you do not interfere with real customer bookings.
• Set cache exclusions for the account page, thank-you page, WooCommerce cart, and the form's dynamic requests.
• Create an editorial translation table for service names, types, emails, and pages so the team does not rewrite them inconsistently.

When CSS Makes Sense

CSS is appropriate when the issue is purely presentational: the language switcher wraps onto a new line, a button sits too close to the form, or a long language name breaks a service card layout. But CSS should not be used to hide system problems. If a service disappears, an email is not translated, or a slot is duplicated, CSS has nothing to do with the fix.

Place appearance tweaks in a child theme or another safe location for custom CSS, not inside BookPro files and not inside the add-on files. After an update, verify the mobile version, because booking forms are often used on phones. If a styling change makes the page harder to read or interferes with the booking button, roll it back immediately.

Working With WooCommerce

BookPro declares WooCommerce compatibility and can use WooCommerce payment gateways for paid bookings. On a multilingual site, that adds another layer: product behavior, cart, checkout, WooCommerce emails, and order statuses all need to stay aligned with the selected language. If you accept payments, test not only the BookPro page but also the cart, checkout, return page, and WooCommerce email.

The practical sequence is simple: first get free or offline booking working correctly, then enable payment. If the issue appears only at the WooCommerce stage, look for the cause in the WooCommerce, payment gateway, and language plugin integration rather than in the service name translation. That saves time and reduces the risk of fixing the wrong layer.

When CodeCanyon Multi Language Is a Good Choice

CodeCanyon Multi Language is worth using if BookPro already handles your booking workflow and multilingual support is needed as a clean layer on top of the existing system. A strong use case is a service site with multiple language pages, shared staff and schedules, translatable services, emails, and a customer account area. In that setup, the add-on lets you keep the existing booking foundation while adapting it to a multilingual WordPress structure.

Before going live, run one last short check: dependencies are active, pages are linked, services are translated, the same slot is not duplicated across languages, the email arrives in the correct language, the account area opens, endpoints do not return 404, and cache is not serving an outdated form. If all of those checks pass, you can move on to real-world testing with live services and gradually expand translation coverage across additional BookPro sections.

If you are ready to test the add-on on your own site copy, go to the download section and get the WordPress version. Start with a staging environment or a separate internal page, and only after a successful booking test and email review should you move the multilingual workflow into the site's main navigation.