Fix sidebar navigation for non-ASCII localized section headers

[AmoghParmar]

Fixes #23885

Testing done

This change was manually verified by running Jenkins locally from source with the Japanese locale enabled.

Steps:

1. Built Jenkins from the fix-23885-sidebar-navigation branch.
2. Opened a job’s Configure page with the UI language set to Japanese.
3. Clicked ビルド後の処理 (Post-build Actions) in the left sidebar.
4. Verified that the page scrolls to the correct section instead of ソースコード管理 (Source Code Management).

This confirms that localized section headers now generate unique DOM IDs and sidebar navigation behaves correctly.

Screenshots (UI changes only)

Before

Clicking ビルド後の処理 scrolls to ソースコード管理 due to both sections resolving to the same DOM ID.

After

Clicking ビルド後の処理 scrolls to the correct section.

Proposed changelog entries

• Fix sidebar navigation for non-ASCII localized section headers.

Proposed changelog category

/label bug, web-ui

Proposed upgrade guidelines

N/A

Submitter checklist

• The issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change and are in the imperative mood.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since Javadocs, as appropriate.
• New deprecations are annotated appropriately, if applicable.
• UI changes do not introduce regressions with Content Security Policy.
• For dependency updates, links to external changelogs are provided, if applicable.
• For new APIs and extension points, there is a link to at least one consumer, if applicable.

Desired reviewers

@jenkinsci/core-pr-reviewers

[daniel-beck]

Why is this still here? This seems unnecessary and prone to problems. In particular, a similar problem would occur if there are sections with partially ASCII words.

Admittedly unlikely for the terminology we're using in the default sections, but plugins may add their own IIRC.

[github-actions]

Please take a moment and address the merge conflicts of your pull request. Thanks!

[AmoghParmar]

Hi @daniel-beck

This PR is hitting a failure in Security3630Test.testHashMap on Linux JDK 21. The failure seems to come from an unexpected update-center lookup (No download site found) rather than CLI logic touched by this change.

Does this look like a known CI / initialization-order issue, or is there a recommended way to avoid triggering this path from UI-related changes? Happy to follow up with fixes once I understand what the test expects.

Thanks!

[MarkEWaite]

This PR is hitting a failure in Security3630Test.testHashMap on Linux JDK 21. The failure seems to come from an unexpected update-center lookup (No download site found) rather than CLI logic touched by this change.

That is an unexpected failure, likely caused by the Jenkins update center being unavailable during the automated test.

Does this look like a known CI / initialization-order issue, or is there a recommended way to avoid triggering this path from UI-related changes? Happy to follow up with fixes once I understand what the test expects.

We expect the Jenkins update center to be up all the time. More than 250,000 distinct Jenkins controllers access it every week.

I've started a new build that should confirm the test failure is transient. Daniel updated the test to only run it on certain configurations as part of pull request:

• https://github.com/jenkins-infra/helpdesk/issues/4904 #25927

We use Launchable to track test flakiness. That test has failed roughly 1 of 50 test runs as shown in this screenshot from Launchable:

[MarkEWaite]

This has passed ATH and PCT testing and has been interactively tested by the submitter. Thanks!

[MarkEWaite]

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback.

/label ready-for-merge

[MarkEWaite]

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback.

/label ready-for-merge

I am withdrawing my ready-for-merge because the new code always encodes characters, even ASCII characters. For instance, if I use " abc def gh " as the string, the old code generated the identifier "abc-def-gh" while the new code generates the identifier "61-62-63-20-64-65-66-20-67-68".

Is that intended @AmoghParmar ? Have you confirmed the safety of that change by testing and by code review?

[daniel-beck]

@MarkEWaite In the current UI, the page does not link to these as anchors (i.e., they do not show up in the URL), so there seems to be no negative side effects of encoding them like this. Could you clarify what your concerns are?

If we ever want to link there from elsewhere, we'd probably need to switch to locale-independent IDs anyway.

[MarkEWaite]

the page does not link to these as anchors (i.e., they do not show up in the URL), so there seems to be no negative side effects of encoding them like this. Could you clarify what your concerns are?

My concern was that there might be links that refer to these ID values as anchors. I had not considered that if there were links that refer to these ID values, those links would be broken by any localization of the text. Thanks for the clarification.

[daniel-beck]

@MarkEWaite
Does that mean we can agree on 9d78384 / https://github.com/jenkinsci/jenkins/pull/26068/files/9d78384173b4149323c85e935619d4c48ed447c0 as the reasonable state for this PR we can accept?
For outside references, the anchors would need to be in a default locale anyway.

IMO: The latest state only works for locales like English; even Spanish will have the majority of IDs as unreadable strings, so it's not much better than ignoring the "problem" entirely while having more complexity. A different encoding (with behavior perhaps similar to Punycode) would be needed to make partially ASCII strings readable, but I don't think it's worth the effort or complexity.

[MarkEWaite]

@MarkEWaite
Does that mean we can agree on 9d78384 / https://github.com/jenkinsci/jenkins/pull/26068/files/9d78384173b4149323c85e935619d4c48ed447c0 as the reasonable state for this PR we can accept?
For outside references, the anchors would need to be in a default locale anyway

Yes. I think that the most recent change should be reverted.

[AmoghParmar]

Hi @MarkEWaite and @daniel-beck,

I’ve reverted to the full encoding approach, as discussed.
Thank you both for the detailed discussion and guidance on the best approach!

[daniel-beck]

Works well in my local testing, both with Spanish and Traditional Chinese locales. Unlike current releases, I can jump to the last section of a freestyle config in Traditional Chinese now (weekly gets stuck at the first translated entry).

[daniel-beck]

@AmoghParmar Thanks for your patience and willingness to adapt, while we figure out how this should be fixed!

[AmoghParmar]

@AmoghParmar Thanks for your patience and willingness to adapt, while we figure out how this should be fixed!

Thanks @daniel-beck for testing and for the kind words.

[MarkEWaite]

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback.

/label ready-for-merge

[welcome]

Congratulations on getting your very first Jenkins core pull request merged 🎉🥳

This is a fantastic achievement, and we're thrilled to have you as part of our community! Thank you for your valuable input, and we look forward to seeing more of your contributions in the future!

We would like to invite you to join the community chats and forums to meet other Jenkins contributors 😊
Don't forget to check out the participation page to learn more about how to contribute to Jenkins.