If you run a real estate or rental listing site on WPResidence or WPRentals, you’ve probably looked into making it multilingual at some point. And if you actually tried, you know how it usually goes: install a third-party translation plugin, buy an add-on license for theme compatibility, spend a weekend configuring it, then discover that half your search filters broke because the plugin treated your price fields like regular text.
We got tired of watching that happen. So we built our own multilanguage plugin, designed from scratch around how WPResidence and WPRentals actually store and display property data. It’s free, it’s in beta right now, and if you want to test it on your site, you can request a copy through our ticket system or Facebook page.
This article walks through what the plugin does, how it’s different from a generic multilingual setup, and the one configuration step that prevents the most common translation failure on real estate sites.
The actual problem with translating listing sites
Most multilingual plugins were built for blogs and corporate sites. They translate posts and pages. They handle menus and widgets. That works fine when your content is paragraphs of text.
Real estate listings aren’t paragraphs of text. A property has a title and a description, sure, but it also has a price, a number of bedrooms, GPS coordinates, a property ID, a status taxonomy, and dozens of custom fields that your theme’s search filters rely on to function. When a generic translation plugin creates a “translated copy” of a listing, it often duplicates or overwrites those structured fields in ways that quietly break filtering, sorting, and display.
The result is a site that looks translated on the surface. The listing pages read fine in Spanish or French. But when someone tries to filter by price range, or sort by bedrooms, the results come back wrong or empty. The site owner doesn’t notice because they’re checking the translated pages visually, not testing every filter combination in every language.
That’s the problem we set out to fix.
What the plugin actually does
The plugin lives inside your WordPress dashboard under a single menu called WPEstate Translate. It has a “Start Here” page that lays out the recommended setup order, because the sequence matters. Translating your listings before you’ve configured your taxonomy behavior and custom field rules will create problems you’ll have to undo later.
Here’s the setup sequence, and why each step exists.
Languages come first. You define which languages your site supports, set a default, and toggle visibility. Everything downstream depends on this being locked in: URL structure, string files, menu sync, and content translation all reference this list.
Theme and plugin strings come second. These are the small UI pieces that visitors see constantly: button labels, search placeholders, filter names, form text. The plugin scans your active theme and plugins, collects these strings, and lets you translate them per language. Then it generates proper translation files so WordPress loads them correctly. If you skip this step, you end up with a site where the listing descriptions are in French but the search bar still says “Search” and the filters still say “Property Status” in English. That looks unfinished, and it erodes trust with visitors.
Taxonomy translation comes third. Your property categories, statuses, types, and locations are taxonomies, and your search filters are built on them. The plugin lets you choose, per taxonomy, whether terms should be translated per language, translated with missing terms hidden, or shared across all languages. The practical rule: if a taxonomy appears in a search filter, translate it and hide missing terms. Otherwise, a visitor switches to German and sees filter options that lead to zero results.
Custom field rules come fourth, and this is the step most people get wrong. The plugin shows you every custom field attached to your listings and lets you assign a behavior to each one. Some fields should always copy identically across translations: price, bedroom count, bathroom count, property ID, GPS coordinates. These aren’t text to be translated. They’re data your theme uses to query and display properties. Other fields should copy once and then allow local edits, like a custom headline you might want to tweak per language. And some fields should be fully independent per language, like a long-form description meant to read naturally.
If you skip this configuration and just run a bulk translation, the translated listings will look correct when you read them. But the data behind them won’t match what the theme expects. Prices might display wrong. Filters might miss properties. Search results might return nothing for certain combinations. It’s the kind of bug that doesn’t look like a bug until a real visitor tries to actually use the site.
Automatic translation comes fifth, once all the rules are in place. You pick a translation engine, add your API key, choose target languages and post types, and run the job. The plugin creates translated drafts that follow the taxonomy, string, and custom field rules you already defined. The output is a solid first pass. You still need to review and edit, but you’re editing inside a structure that won’t break your filters or data.
Menu synchronization comes sixth. You pick a source menu and a target-language menu, and the plugin copies the structure while mapping items to their translated counterparts. If a translation doesn’t exist yet, you set a fallback so the menu doesn’t have dead links.
Global settings come last. You set your URL strategy (subdirectories, for example), default language, and language switcher placement. After changing URL settings, flush your permalinks.
The one rule that prevents silent failures
If your translated listings look fine but search filters misbehave or numeric data displays incorrectly, the cause is almost always the same: structured fields were treated like translatable text.
Before you run any bulk translation job, go to Custom Field Rules and confirm that prices, IDs, coordinates, bedroom counts, and any other numeric or reference fields are set to copy, not translate. Translate the text that humans read. Leave the data that the theme queries alone.
That single distinction is what separates a multilingual content site from a multilingual real estate site that still works.
How to get it
The plugin is free and built specifically for WPResidence and WPRentals. It’s currently in beta. If you want early access and you’re willing to share feedback as you use it, send us a message through the WPEstate ticket system or our Facebook page and we’ll send you a copy.
The fastest way for us to improve it is real usage on real sites with real listings. If you run into problems, tell us. If something works well, tell us that too.
How to test it
1. Download the plugin from here
2. If the theme version is 5.4.1 or older you need to download this wpr folder and uploaded into themes/wpresidence/ folder
3. The child theme has already a lot of translation files made . You can aactivate the child theme and the plugin will read the translations files already made there . or you can copy only your language files into the wpresidence/languages folder.
4. Please give us feedback – and tell us , what is not clear, what is not working well and what you like – we will collect this feedback , solve any bugs reported and listen to your suggesting regarding new features and functionality.
Thank you.
