Fix: Use Core's item_link label for navigation link titles instead of…

[adithya-naik]

What?

Remove the custom sprintf( __( '%s link' ) ) string from build_variation_for_navigation_link()
and always use Core's existing item_link label for navigation link titles.

Why?

The previous code was:

1. Reading the correct, properly-translated item_link label from Core (e.g. "Page Link")
2. Checking if it was a "default" label ($is_default_title)
3. If so, discarding it and replacing it with a custom "%s link" string

This broke translations in most languages because "%s link" assumes
English word order. For example:

• French: should be "Lien de page" but produced "Page lien" ❌
• Arabic: should be "رابط الصفحة" but produced broken RTL/LTR mix ❌
• German: should be "Seiten-Link" but produced "Seite link" ❌

Core's item_link label is already correctly translated into 50+ languages
by the WordPress translation team. There is no reason to override it.

Changes

• Removed $is_default_title condition from the title fallback check
• Removed the untranslatable sprintf( __( '%s link' ), $singular ) string
• Removed the now-unused $singular variable
• Fallback now only triggers when item_link is genuinely absent

Before / After

Before:

$singular = $entity->labels->singular_name ?? ucfirst( $entity->name );

if ( $is_default_title || '' === $title ) {
    $title = sprintf( __( '%s link' ), $singular );
}

After:

// Always prefer the item_link label from Core as it is already properly
// translated for each post type and taxonomy. Only fall back if the label
// is genuinely absent.
if ( '' === $title ) {
    $title = $entity->labels->singular_name ?? ucfirst( $entity->name );
}

Testing Instructions

1. Add a Navigation block in the editor
2. Click + to add a Navigation Link
3. Verify link titles match Core labels (e.g. "Page Link", "Category Link")
4. Switch WordPress to a non-English language and verify titles are correctly
   translated using Core's translations — not a raw "%s link" pattern

Fixes #76891

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: [Package] Block library.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: adithya-naik <adithyanaik@git.wordpress.org>
Co-authored-by: swissspidy <swissspidy@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @adithya-naik! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[adithya-naik]

@ajitbohra / @fabiankaegy Could you please re-run the failed Playwright 3 job? It might be a flaky failure.

[adithya-naik]

@ajitbohra / @fabiankaegy Could you please re-run the failed Playwright 3 job? It might be a flaky failure.

Thanks! No need to re-run now.

I triggered CI again with an empty commit and all checks have passed successfully, including the previously failing Playwright job.

Performance tests also show no significant regression — all changes are within normal variance.

[adithya-naik]

Hi @ajitbohra and @fabiankaegy 👋

Following up on this PR. All CI checks are passing now, and the fix improves i18n by relying on Core’s item_link label instead of constructing "%s link" strings.

This avoids incorrect translations across languages and aligns with existing Core behavior.

Would love your feedback when you get a chance. Thanks!

[adithya-naik]

Just a Follow-up as its been too long
@ajitbohra & @fabiankaegy

[adithya-naik]

Just a Follow-up as its been too long @ajitbohra & @fabiankaegy

Please do consider the PR