WPML FSE Navigation Block Wrong Language: How to Fix Menus in Block Themes

Your visitor switches to French, German, or Spanish—and the page changes perfectly. Then the header serves the default-language menu anyway. It is a small failure with a big effect: the site suddenly feels unfinished, and visitors can be one click away from landing back in a language they did not choose.

The wpml fse navigation block wrong language issue is especially frustrating because block themes do not handle menus the way classic WordPress themes do. The Navigation block, its Navigation posts, and the templates that render them can each hold a piece of the puzzle. A menu may be translated yet still not appear where it should—or a template may quietly keep calling the original navigation.

The good news is that this usually is not a mysterious WPML failure. It is a mismatch hiding in the new Full Site Editing workflow, and once you know where WordPress stores and assigns block-based navigation, the wrong-language menu becomes much easier to track down.

Why does a WPML Navigation block show the default language menu?

How Navigation blocks work in Full Site Editing themes

A translated page does not automatically mean a translated header. That is the trap behind a wpml fse navigation block wrong language issue. In a block theme, the Navigation block can point to a saved Navigation entity, while the header itself usually lives in a reusable template part. That template part may appear on every page, regardless of the page’s language.

This differs sharply from classic WordPress menus, where a theme location such as “Primary Menu” was assigned a language-specific menu. With Full Site Editing, WordPress assembles the layout from blocks, template parts, templates, and saved navigation data. Each can have its own translation state.

What WPML must translate for multilingual navigation

WPML needs more than translated destination pages to render the right navigation. The linked pages, posts, categories, or products must have translations, but the Navigation item also needs a translated version or correctly translated links. Then check the header template part containing that block.

Finally, inspect the template used by the translated page. A page may use a translated header template part, an untranslated template, or a template that overrides the expected header entirely. In other words, WPML can translate the content perfectly while the layout still calls the original navigation.

Symptoms that point to the actual problem

• Labels remain in the source language, but links are correct: the Navigation entity or its individual labels have not been translated.
• Labels are translated, but URLs lead to default-language pages: the menu links were copied rather than connected to translated content.
• The entire familiar default-language menu appears: the translated page is rendering the original Navigation entity, header template part, or an overriding template.

The last symptom is the most important. Do not start by editing page content; trace which template and header the translated URL actually renders.

Check whether the translated navigation has been created and completed

A translated page can be flawless while its header still sends visitors back to the default language. That is the trap behind many wpml fse navigation block wrong language reports: in a block theme, the Navigation block uses a saved navigation entity, and that entity needs its own completed WPML translation.

Find the navigation used by your site header

Open Appearance > Editor and edit the template part used for your header. Select the Navigation block, then inspect its settings to identify the saved navigation it displays. Do not assume every screen uses that same header. Many block themes assign separate template parts to posts, pages, product archives, or WooCommerce checkout views.

Check each relevant header variant and write down the navigation name attached to it. If the English header uses “Primary Navigation” but the translated template part points to another menu—or an untranslated one—you have found the likely mismatch.

Translate the Navigation item in WPML

In WPML’s translation workflow, locate the saved navigation item identified in the Site Editor. The exact screen can vary with your WPML configuration, but the goal is constant: find that navigation entity, open its translation, and create the target-language version if it is missing.

Completion status matters. A translation marked complete before its items have been reviewed may still render the default-language structure or outdated entries. Review every label and destination, save the translation, and mark it complete only when the menu is genuinely ready. If you already run WPML, LATW AI Translator for WPML can speed up page and post translation within WPML, but WPML still owns the navigation and multilingual structure.

Verify links, custom URLs, and nested submenu items

Translated labels are not enough. Click every internal menu link while viewing the translated navigation and confirm that it opens the corresponding translated page, product, category, or post—not the original-language URL.

• Review custom URLs individually; translate localized landing-page paths where appropriate.
• Keep external URLs unchanged unless the destination has a language-specific version.
• Check anchors such as #pricing, which must exist on the translated page too.
• Expand nested submenu items. A single untranslated child link can make an otherwise correct menu look broken.

Make sure the translated template uses the translated Navigation block

Review the translated header template part

A translated menu can exist perfectly in WPML and still never appear on the site. In block themes, the visible menu is determined by the Navigation block saved inside the active header template part—not simply by the navigation translation you created.

Open Appearance → Editor, switch to the affected language using WPML’s language controls, then edit the Header template part. Select the Navigation block and check which menu it is assigned to. It should point to the translated navigation entity, not the original-language menu copied from the source header. This is the most common cause of a wpml fse navigation block wrong language issue: the translated header markup still contains a reference to the main-language navigation.

Check page, post, and archive templates for header overrides

Do not assume that a correct homepage proves the whole setup is correct. A block theme may use one header on the front page, another on single posts, and a custom template or inline Navigation block for product, archive, or search pages.

In the Site Editor, inspect the templates used by the page types where the problem occurs. Look for a different template part, such as “Header Minimal,” or a Navigation block placed directly in the template. If the block was copied before translation, it may still be tied to the default-language menu. Update that specific block or replace it with the properly translated header part.

Save changes and clear every relevant cache

Save the translated navigation first, then save the edited template part and any affected templates. Next, clear your WordPress caching plugin, purge host or CDN cache, and test in a private browser window. Switch languages on the homepage, a regular post, a page, and an archive. Checking several page types matters because each can load different FSE template markup.

What to do if WPML still serves the wrong FSE menu

Rule out theme conflicts and stale Site Editor data

A wpml fse navigation block wrong language issue is often not a translation failure at all. In block themes, a header template part can retain an older Navigation block reference even after the visible menu appears correctly translated elsewhere.

Test changes on a staging copy first. Temporarily disable nonessential cache, optimization, and block-related plugins, then check the affected language in a private browser window. Update WordPress, the active block theme, WPML, and its related components before drawing conclusions. Clear every relevant cache layer: plugin cache, host cache, CDN cache, and browser cache.

Avoid editing WPML records, navigation references, or template data directly in the database. That can turn a recoverable mismatch into broken translation relationships. Re-enable plugins one at a time after testing; the moment the translated header changes back, you have a useful lead.

Prepare a support request WPML can reproduce

Persistent cases need evidence, not a vague report that “the menu is wrong.” Give WPML support enough detail to inspect the relationship between the template part, Navigation block, and translated navigation item.

• WordPress version and versions of WPML and all active WPML components
• Active block theme name and version
• The affected URL, source language, and target language
• Screenshots of the header Navigation block in each language within the Site Editor
• The translation status of the relevant navigation and template-part content
• Every cache layer already cleared and the conflict tests performed

Translate WPML content without costly credit workflows

If your site already runs WPML, LATW AI Translator for WPML is an optional add-on for translating posts, pages, metadata, SEO fields, and WPML strings through your chosen AI or translation-provider API. It is not a standalone multilingual plugin, and it does not manage FSE navigation infrastructure: WPML remains the prerequisite and continues to handle languages, URLs, and menu relationships. Its role is simply to make content translation more efficient without relying on WPML’s credit-based automatic translation workflow.

Make the Navigation Entity the First Place You Look

When the wpml fse navigation block wrong language issue appears, work from the block theme’s saved entities outward: identify the Navigation post used by the header, complete its WPML translation, then confirm that every translated template or template part is assigned to the matching translated navigation. Clear all relevant caches only after those relationships are correct, and retest from a clean browser session.

If the menu still falls back to the primary language, the language switcher is rarely the real problem. The cause is usually a missing translation or an incorrect assignment inside the FSE structure. Fix the entity connection, not the symptom, and your translated header can behave as consistently as the rest of the site.