When you add a second language to WPResidence with the WPResidence Translate plugin, your translated content does not disappear into a mystery box. Every language version, translated string, translated URL slug, and auto-translation helper lives in six dedicated tables the plugin adds to your WordPress database. You do not need to touch those tables manually — but knowing what sits where helps you understand what a backup must include, what a “reset” actually wipes, and why a multi-language real estate website stays organized even with thousands of properties.
Why Custom Tables and Not Just Post Meta?
WordPress core stores posts, pages, and properties in the wp_posts table. Translations could technically be shoved into post meta, but that becomes very slow once you have a few languages and thousands of listings. WPResidence Translate keeps translations in their own tables so that:
- Language lookups stay fast, even with 10,000+ properties.
- Your original English post stays a normal WordPress post — no plugin lock-in on the content itself.
- Deactivating the plugin does not corrupt your original content. Language variants remain in the database, intact, ready for the plugin to re-enable them.
The Six Tables at a Glance
All tables use your database prefix (usually wp_). Below is what each one is responsible for, in everyday terms.
| Table name | What it stores, in plain English |
|---|---|
wp_wpestate_translation_translations |
The “family tree” of your content. It records that property #42 (English), #87 (French), and #132 (Spanish) are three versions of the same listing, linked by a shared translation ID. |
wp_wpestate_translation_strings |
Every translated label on your site — button text, form fields, email templates, menu items, everything the theme prints out in fixed wording. |
wp_wpestate_translation_slugs |
The translated piece of each URL. If your English property lives at /property/beach-villa/ and the French version lives at /fr/propriete/villa-plage/, the per-language slug lives here, along with old slugs for redirects. |
wp_wpestate_translation_glossary |
Fixed word pairs the auto-translator must always respect — for example, “Townhouse” should always become a specific term, never get machine-guessed. |
wp_wpestate_translation_memory |
A memory bank of every sentence ever auto-translated. If the same sentence appears in another listing, the plugin reuses the stored translation instead of calling (and paying) the API again. |
wp_wpestate_translation_languages |
Your active language list: code, display name, flag, default flag, display order. |
How the Tables Talk to Your Posts
Your English property remains a normal post in wp_posts. When you create the French version, WPResidence Translate:
- Creates a second post in
wp_posts(yes, a real WordPress post). - Adds one row to
wp_wpestate_translation_translationsfor the English post and one for the French post, both sharing the sametrid(“translation ID”). - Stores the French URL slug in
wp_wpestate_translation_slugs. - Optionally copies selected custom fields across, based on your Custom Field Rules.
That is why WordPress search, the media library, and any other plugin keep working normally — the translated posts are just posts. WPResidence Translate only links them and filters queries by language.
What Gets Translated Where
| Content type | Lives in |
|---|---|
| Posts, pages, properties, agents, agencies, developers | wp_posts (standard WordPress), linked via wp_wpestate_translation_translations. |
| Post and page URL slugs per language | wp_wpestate_translation_slugs |
| Theme button labels, filters, emails, menus | wp_wpestate_translation_strings |
| Category names, location names, feature names | wp_terms (standard WordPress), linked via wp_wpestate_translation_translations with element_type set to the taxonomy. |
| Custom field values | wp_postmeta (standard WordPress) — synced or kept unique based on your Custom Field Rules. |
| Your language list and defaults | wp_wpestate_translation_languages plus the wpr_translate_languages option. |
Non-Latin Characters Are Safe
All six tables are created with your WordPress charset and collation (typically utf8mb4). Cyrillic, Arabic, Hebrew, Chinese, Japanese, Korean, Thai, and Greek language names, slugs, and translated content are preserved exactly as entered, with no transliteration.
What You Should Know for Backups
- A full database backup includes everything. If you export your whole database, all six tables are included automatically.
- Partial exports must include them. If you use a tool that exports “only the posts table,” you will keep your translated posts but lose the links between them. Always export all
wp_wpestate_translation_*tables together. - Uninstalling the plugin does not drop the tables. If you deactivate and remove the plugin, the translations stay safely in the database until you explicitly reset or drop them. Re-installing the plugin picks them right up again.
What “Reset” and “Delete Translations” Actually Touch
The admin tools under the plugin menu are deliberately conservative:
- Reset Settings — clears the plugin’s options, but does not delete any translation data from the six tables.
- Delete Translations — targeted cleanup tool to remove specific translated rows if you want a clean slate for one language.
- Cache Purge — clears temporary caches only; translated content and slugs are never affected.
If you ever need a total wipe, you can drop the six wp_wpestate_translation_* tables manually — but only do this when you are sure, because there is no automatic rebuild.
Further Reading
- Installation, Activation & Uninstall — the lifecycle around creating and removing these tables.
- Translation Linking (trid system) — how the “family tree” actually groups language variants.
- Performance & Caching — how WPResidence Translate keeps these tables fast on a large site.
For the bigger picture on running a multi-language real estate website, start from the WPResidence multi-language guide.