Thank you for the good suggestion! It makes a lot of sense for sites with several languages.
Right now I’m finishing 1.0.7, which brings a good set of improvements: more reliable custom field sync (ACF, Meta Box), more reliable shared stock across WooCommerce language copies, performance improvements, better imports from WPML, Polylang and TranslatePress, and many smaller fixes. I’m taking extra time to test it well before release.
Your Content ReSync idea is planned for 1.0.8. The plan:
a “Resync from source” action that brings over the new page, template or pattern structure;
existing translations kept for every part whose text hasn’t changed, even when you move it or put it in a different block;
only new or changed parts marked for translation, or machine translated with the surrounding text as context, if you choose;
when you add a new language, the same run can create the missing translations and save them as drafts;
the result is saved for your review before it replaces a published translation, or applied automatically if you prefer; either way you can undo it;
if you want, all of this can run by itself when you update a page or add a language.
For 1.0.8: pages, posts, templates, template parts, synced patterns, navigation menus and custom fields; page builders later.
Yes, you’ve understood it correctly: each language gets its own version of a template or template part, similar to translated posts. A translated footer can then be reused across pages in that language.
Please try these steps:
If you haven’t enabled FSE support, go to PerfLocale → Settings → Translation, enable Full Site Editing → Translate block theme templates and template parts, and save the settings.
Open the original/default-language footer itself in the Site Editor. Make a small change and save it.
Refresh the editor page. The translations should now appear in the side panel. Saving the original should create the missing language copies, which should then appear in the Translations sidebar.
Open the relevant language copy, translate its content, and publish it. Until it is published, visitors continue seeing the original footer.
For templates supplied directly by the theme, that first save is important: it creates a customized version in WordPress that PerfLocale can translate.
Alternatively, for items already saved in WordPress, use Generate Missing Translations near the bottom of Settings → Translation. If those items haven’t been assigned a language yet, run Assign Default Language first. Review the generation count before confirming, as this can include other enabled content types too.
The Show If Language block is also a valid approach: it lets you keep language-specific sections within one template. Separate template translations let you manage each language’s version independently.
If the footer still shows “None” after saving the original and reopening it, please let me know your PerfLocale version and theme so I can investigate further.
First, check what already exists: go to PerfLocale → Translations and set the content-type filter to Contact Forms. Each form has a column for every language.
If a language shows a status such as Draft or Published, click it to open that translation in Contact Form 7’s editor and translate it.
If it shows Empty, open the form in Contact Form 7 as usual. The editor now has a Translations box in its right-hand column. Click + Create next to the language, and the new translation opens in Contact Form 7’s editor with all the original fields in place, ready to translate.
Each translation has its own field labels, buttons, email templates and validation messages. You keep the same shortcode on every page, and each language automatically shows its own version of the form.
Each translation also keeps its own mail settings, including the recipient. That lets each language send to a different address, but if you later change the recipient on the original form, change it on the translations too.
It does work, and you were right that there was no way to reach it.
Addon-registered content types weren’t reaching the admin screens, so Contact Forms never appeared in the Translations page.
This is fixed, but not in 1.0.4 – it’s coming in 1.0.5, which I’m working on now.
After updating: PerfLocale → Translations, set the post type filter to Contact Forms, and translate a form as you would a page. It opens in Contact Form 7’s own editor, and each translation covers the field labels, the buttons, both email templates and the validation messages.
Version 1.0.4 is out, and it covers both of the things you asked about. (One note on timing: wordpress.org now holds new plugin versions for six hours before releasing them to sites, so moderators and security scanners can review the changes)
Site title and tagline – go to PerfLocale → Strings. They appear there automatically after the update, tagged Site Title and Tagline beside their current value. Nothing to switch on and no scan to run. (An empty tagline has nothing to translate, so no row shows until you set one.)
Patterns are now fully covered:
A pattern you insert from the inserter is copied into the page, so its text is ordinary page content. Translate the page under Translations, and the text comes with it. That already worked.
A synced pattern is stored once and shared – the page holds only a reference, so translating the page can’t reach the text. Go to PerfLocale → Settings → Translation, find the Translatable Post Types row, expand Advanced content types (it’s collapsed by default), and tick Patterns (wp_block). Each pattern is then translatable like any other post.
If you use a block theme, Navigation Menus (wp_navigation) sits in that same group. Menu link addresses were already translated without it – the checkbox adds the visible menu labels.
One thing worth knowing: if a translation is missing, still a draft, or trashed, the original renders. You’ll never get a blank space where a pattern or menu used to be.
Full site editing (FSE) – translating text you type directly into a template in the Site Editor – isn’t supported yet. It’s what I’m working on next.
Thank you for the questions, the feedback, and the review; that’s very kind of you!
Hi FREEZhao, I’m glad you enjoy the UI and UX. Good questions, and the honest answer is “not yet, but very soon”.
Site title and tagline aren’t on the Strings screen right now. Support for both is built and ships in the next release, by the end of this week. After you update, they’ll appear on the Strings screen automatically – no code and no scan needed.
Until then, a small snippet in your child theme’s functions.php or a code snippet does it:
add_filter( 'option_blogname', function ( $title ) { if ( ! function_exists( 'perflocale' ) ) { return $title; }
$titles = [ 'de' => 'Mein Seitentitel', 'fr' => 'Le titre de mon site', ];
A pattern inserted from the inserter is copied into the page, so its text becomes ordinary page content — translate the page under Translations, and the text comes with it. This works today.
A synced pattern stays a reference, so right now it renders the original text in every language. That’s fixed in the same end-of-week release.
Templates and template parts (full site editing) are next – I’m working on that now.
I’ll post here again once the release is out. Alex
