Yes, you can translate custom fields and taxonomy terms in WPRentals and still use them in filters. Translations change what guests see, not how search stores or reads data. With WPRentals and WPML (WordPress Multilingual Plugin) using the right settings, all languages share one inventory. So labels, amenities, property types, and locations can differ by language, but the search logic stays stable.
How does multilingual search work with translated amenities and locations?
Multilingual search can show translated terms and still use one shared set of listings.
A guest might click “Piscine” in French or “Swimming Pool” in English. But both choices still reach the same properties. WPRentals is tested and marked as compatible with WPML, so they work together for this. You keep one catalog, and each listing gets translations, not separate items that drift away from each other.
WPRentals saves locations and amenities as taxonomies that WPML can link across languages. Inside WPML, each term connects to its versions in other languages, so “Paris” and “París” stay tied. When the AJAX advanced search runs, the theme uses those links and the shared term IDs. That way the query always reaches the same listings, no matter what text guests see.
AJAX matters here, and it is where many site owners struggle. The advanced search and half map results use AJAX calls that must know the current language. WPML has a switch called the language cookie for AJAX that gives this context. WPRentals expects that option to be on so maps, taxonomies, and filters respond in the same language as the page.
| Element | What gets translated | What stays shared |
|---|---|---|
| Amenity terms | Names like Pool or Piscine | Term IDs and property links |
| Location taxonomies | City and area labels | Coordinates and search queries |
| Property pages | Titles and descriptions | Booking logic and availability |
| Search labels | Field names and placeholders | Search structure and fields used |
| AJAX requests | Language context from cookie | Database of listings |
The rule in the table is simple. Text for users can change, but IDs and database links stay fixed. At first this looks minor. It is not. This is the reason multilingual filters in WPRentals keep working, even if you add more languages later.
Can I translate custom fields and still use them as filters?
Yes, if you translate field labels and copy field values, custom filters stay reliable in every language.
Custom fields are a big reason many people pick this theme. They behave well with languages when you respect how values are saved. WPRentals lets you create many custom fields and plug them into advanced search. So you can make filters like “Sauna type” or “Boat length” and expect them to work in French and Italian too.
The usual WPML pattern is clear. Set custom fields used in search to “copy” so raw values match across languages. WPRentals fits this pattern because its queries use those saved values, not the label text. If a dropdown stores “eco_certified” as the value, all translations keep that value. Guests only see translated labels on the site front end.
Dropdown and checkbox options also translate safely in this approach. You define the field once in WPRentals, pick text, number, dropdown, or checkbox, then send its labels to WPML String Translation. So “Eco certified” can appear in several languages while the internal key stays fixed. I should rephrase that. As long as you keep the key and stored value the same everywhere, filters with that field stay accurate, even when you add more languages in the future.
How are translated taxonomy terms kept consistent for cross-language filtering?
Linked translations of taxonomy terms keep filters working the same way in every language.
Amenities, property types, and locations are taxonomies with fixed IDs that never depend on language. WPRentals uses this design directly. Filters work on these IDs in the background, so one property type term serves English, German, and Italian. You are not creating three “Apartment” groups, which would be a mess over time.
WPML lets you create and connect translations for each taxonomy term. So “Villa,” “Villa,” and “Vila” all link as variants of the same base term. WPRentals search then uses the shared term ID, which means any “Villa” filter returns the same properties. Admins can allow multi select on these translated taxonomies, like choosing two areas at once. The logic still hits the same terms and listings under the surface.
What setup steps ensure multilingual filters, maps, and calendars stay in sync?
Correct multilingual settings keep filters, maps, and calendars in step across languages.
There are a few settings that really matter, and they are easy to overlook. WPRentals suggests turning on WPML’s language cookie for AJAX so every map load and AJAX search uses the right language context. With that set, the same advanced search fields behave the same way in each language and limit results to that language’s site version.
- Enable WPML language cookie for AJAX so searches and maps use the right language.
- Keep calendar data shared for each listing so all translations show the same booked dates.
- Use shared coordinates for each property so every language shows the same markers.
- Translate booking forms and emails so guests and owners get messages in their own language.
Because calendars connect to the listing, not the translation, you never sync dates between languages. WPRentals reads one calendar everywhere, so a blocked night in English is blocked in Spanish too. The same pattern works for map coordinates, which means language switches keep markers on the same physical homes. I know this sounds like repeating the same thing. It is repeated on purpose, because mixing calendars per language breaks sites fast.
Let me step out of the tidy tone for a second. Many admins try to “separate” calendars per language, thinking it gives more control. It does not. It just creates double bookings and angry hosts, and then they come back to the shared calendar model anyway. So yes, share the calendar and coordinates, and spare yourself a month of fixing mistakes.
FAQ
Can I run one inventory and still have full multilingual search and filters?
Yes, you can run one shared inventory and still keep search and filters multilingual.
The listings live once in the database, and translations act as different views of that data. WPRentals and WPML handle term links, field copying, and language cookies so queries stay unified. Guests in several languages can search by locations, amenities, and custom filters without you duplicating properties.
Do I have to translate both taxonomy terms and custom field labels?
No, you can choose to translate taxonomy terms, custom labels, or both based on your visitors.
Many admins start with locations and amenities so filters read naturally in each language. WPRentals then lets you also translate custom field labels and search form labels through WPML String Translation. You can leave very technical fields in one language for staff while keeping front end labels multilingual.
Do pricing and monetization work the same way on multilingual sites?
Yes, all pricing and monetization in WPRentals works the same on multilingual setups.
Service fees, paid listings, and membership packages tie to user accounts and listings, not languages. So commission levels, featured listing payments, and package limits behave the same in any admin language. You only translate the texts that describe these options, not the pricing behavior itself.
How do I translate theme buttons like “Book Now” and system messages?
You translate theme buttons and messages with language files or a supported translation plugin.
WPRentals ships with language files and supports major translation plugins, so you can localize theme strings. Load them into a tool like WPML String Translation, pick texts such as “Book Now” or “Advanced Search,” and add translations. The theme then shows each text in the guest’s language while booking logic and filters keep working the same way.
