Change navbar-lang-selector behavior

[paulofponciano]

Description

The current navbar-lang-selector behavior lists all languages in the dropdown even when no translations are available for the current page. When a user selects a language, they are redirected to that language's home page instead of a translated version of the current page.
This misleads users into thinking translations exist for the page, and they only discover it's a fallback behavior after being redirected to the home page.

Proposed changes in this PR:

• Available languages (with translations for the current page) are listed first with default formatting
• Remaining languages (available on other pages but not the current one) are listed afterward, greyed out, with a home icon that links to the site's landing page in the corresponding language

Repo files:

• /layouts/partials/navbar-lang-selector.html
• /assets/scss/_k8s_sidebar-tree.scss
• /i18n/en/en.toml

Example pages with current behavior:

• https://kubernetes.io/docs/tasks/debug/debug-cluster/topology/ (EN only at this time)
• https://kubernetes.io/docs/reference/kubectl/ (currently lists only languages that have a localized version of the page)

Issue

Closes: #53803

[netlify]

✅ Pull request preview available for checking

Built without sensitive environment variables

Name	Link
🔨 Latest commit	1ee4c00
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-io-main-staging/deploys/69c04117c9ed25000821f4c8
😎 Deploy Preview	https://deploy-preview-53804--kubernetes-io-main-staging.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[lmktfy]

/area web-development
/retitle Change navbar-lang-selector behavior

[lmktfy]

Here's a challenge: how do we let people know that the other localization is available, albeit not for the page they have open?

---

Maybe we show some of the localizations in gray text, as a way to indicate that the specific page isn't localized, but with a hint that another page might be.

[paulofponciano]

Here's a challenge: how do we let people know that the other localization is available, albeit not for the page they have open?

Maybe we show some of the localizations in gray text, as a way to indicate that the specific page isn't localized, but with a hint that another page might be.

Thanks for bringing up this perspective.

I've pushed a proposal to staging addressing these points, where we now use class="dropdown-item-text text-muted" listing all the languages identified on the Home page.

---

Also, as another option: just show a message (This page is only available in {{ $.Language.LanguageName }}) indicating the page is only available in that language — implying the limitation is specific to that page.

---

Once there's at least one other language, it follows the default behavior.

[lmktfy]

Our site is, as you know, localized. This needs to use Hugo i18n; see other partials and also https://github.com/kubernetes/website/tree/main/i18n

[lmktfy]

See https://gohugo.io/functions/lang/translate/ and https://gohugo.io/content-management/multilingual/

[paulofponciano]

Thank you @lmktfy for bringing up this concern.
To address this, I've initially added the keys to en.toml and pt-br.toml like this:

[page_not_available_in_language]
other = "This page is not available in {{ .Language }}"

In /layouts/partials/navbar-lang-selector.html we use the i18n key / translation identifier page_not_available_in_language.
The fallback for this case (when the key doesn't exist in somelanguage.toml) is to use language_alternatives = ["en"] for each language (from hugo.toml).

[lmktfy]

Apart from a (big) localization concern, I like both the ambition and the approach.

[lmktfy]

Thanks for the work so far on this. We haven't many people willing to review pull requests. You can help - that might not be obvious, but you can, GitHub just allows you to write feedback on pull requests.

One thing I'd like you to do: squash the commits down on this PR.

Do that, and drop the Portuguese strings, and it could well be good to merge.

[paulofponciano]

/remove-language pt

[paulofponciano]

Thanks for the work so far on this. We haven't many people willing to review pull requests. You can help - that might not be obvious, but you can, GitHub just allows you to write feedback on pull requests.

One thing I'd like you to do: squash the commits down on this PR.

Do that, and drop the Portuguese strings, and it could well be good to merge.

Thanks @lmktfy.
I've dropped the pt-br changes and squashed the commits. Here's a netlify to validate the behavior.

[lmktfy]

The current navbar-lang-selector behavior lists all languages in the dropdown even when no translations are available for the current page.

I don't think it does. For example, go to https://kubernetes.io/docs/reference/kubectl/ ns look at which languages you can choose.

---

We could improve it further, which is what I thought this PR might do.

Looking at https://deploy-preview-53804--kubernetes-io-main-staging.netlify.app/docs/reference/kubectl/ I think what we should show in the nav bar is:

• English
• 中文 (Chinese)
• Français (French)
• Deutsch (German)
• Bahasa Indonesia (Indonesian)
• 日本語 (Japanese)
• 한국어 (Korean)
• Português (Portuguese)
• Русский (Russian)
• Español (Spanish)

and then after those languages, list the remaining languages: remaining in that some other page on the site supports them, but not this page. The remaining languages should be greyed out or otherwise marked unavailable. I might show an icon after each "remaining" language that is not greyed out, and if you click it you go to the landing page for the site in that language.

[paulofponciano]

The current navbar-lang-selector behavior lists all languages in the dropdown even when no translations are available for the current page.

I don't think it does. For example, go to https://kubernetes.io/docs/reference/kubectl/ and look at which languages you can choose.

We could improve it further, which is what I thought this PR might do.

Looking at https://deploy-preview-53804--kubernetes-io-main-staging.netlify.app/docs/reference/kubectl/ I think what we should show in the nav bar is:

• English
• 中文 (Chinese)
• Français (French)
• Deutsch (German)
• Bahasa Indonesia (Indonesian)
• 日本語 (Japanese)
• 한국어 (Korean)
• Português (Portuguese)
• Русский (Russian)
• Español (Spanish)

and then after those languages, list the remaining languages: remaining in that some other page on the site supports them, but not this page. The remaining languages should be greyed out or otherwise marked unavailable. I might show an icon after each "remaining" language that is not greyed out, and if you click it you go to the landing page for the site in that language.

I believe it's now closer to meeting the suggestions made in this same PR.
The navigation bar now lists the available languages first with the default formatting, while the remaining languages (unavailable for the current page but available on other pages) are listed afterward, greyed out, with a home icon that links to the site's landing page in the corresponding language. Could you please take a look, @lmktfy?

https://deploy-preview-53804--kubernetes-io-main-staging.netlify.app/docs/reference/kubectl/

[lmktfy]

Well, personally, I think this is a nice improvement.
/lgtm

[k8s-ci-robot]

LGTM label has been added.

Details

Git tree hash: 129993555387a956cdf94e201e2f0b866082be15

[Caesarsage]

Thanks for this improvement.

But the mobile view is still broken, the text are not showing

[paulofponciano]

/hold
until fix the behavior when accessed via mobile browser

[paulofponciano]

/unhold

[SayakMukhopadhyay]

This PR is pertinent google/docsy#2303

This issue gets fixed upstream in 0.13.0 wherein untranslated locales are disabled. @paulofponciano as a request, can you please add a TODO at the top of navbar-lang-selector.html that notes that this issue gets fixed in 0.13.0. It will help me in figuring out what to keep and discard during that upgrade.

[paulofponciano]

This PR is pertinent google/docsy#2303

This issue gets fixed upstream in 0.13.0 wherein untranslated locales are disabled. @paulofponciano as a request, can you please add a TODO at the top of navbar-lang-selector.html that notes that this issue gets fixed in 0.13.0. It will help me in figuring out what to keep and discard during that upgrade.

Thanks for connecting the dots @SayakMukhopadhyay. Added the TODO for tracking.
Let me know if there's anything else I can help with.

[SayakMukhopadhyay]

Thanks for addressing the reviews

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Details

Git tree hash: 20b15af3c398894d3b5a7c5a974f5c948508df1e

[lmktfy]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lmktfy

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [lmktfy]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment