[WIP] Adapt nav bar to support RTL locales

[mboukhalfa]

This PR use bootstrap class only that support RTL to style the navbar. Previously navbar used ml-md-auto class which does not support RTL and also absolute position for the logo which does not automatically support switching to RTL. This PR adapt the navbar styling to automatically support RTL direction

Fix: #45077

Inspired from example 3 in https://www.codeply.com/go/qhaBrcWp3v

Simplified example here : https://www.codeply.com/p/bNdMgLE0A5

[adowair]

Hi @mboukhalfa. I noticed this PR contains some changes I believe you intended for #46043. Will you please rebase and post some screenshot previews?

[mboukhalfa]

Hi @mboukhalfa. I noticed this PR contains some changes I believe you intended for #46043. Will you please rebase and post some screenshot previews?

I was expecting to get preview with netlify but not sure why I am not getting this ! I added the other changes so the build succeed I will rebased once merged

[adowair]

Thanks @mboukhalfa! I am not an HTML expert, but I noticed the language switcher could render better:

Quite an important effort, just wanted to point out this too. Otherwise the navbar itself looks good!

[sftim]

/area web-development
/area localization

[sftim]

I'd prefer to pass the dir for the HTML based on the text direction property of each language. Then it should work much better.

This will need a change within layouts, unless Docsy has support(?)

[mboukhalfa]

I'd prefer to pass the dir for the HTML based on the text direction property of each language. Then it should work much better.

This will need a change within layouts, unless Docsy has support(?)

The problem is supposing that we have the correct dir ! So my understanding for this issue now is if we have en element with ml-md-auto even when the dir="rtl" it will not switch to the other direction as expected
check : twbs/bootstrap#22780

[sftim]

Let's build on that. Can we make the customisations only apply using the cascade when dir is rtl? (We can pair you up with someone who knows SCSS to help make that happen).

[sftim]

Let's only override this for RTL locales.

[sftim]

Where possible, I'd prefer to make the customisations here conditional on the locale's text direction.

[mboukhalfa]

Let's build on that. Can we make the customisations only apply using the cascade when dir is rtl? (We can pair you up with someone who knows SCSS to help make that happen).

I appreciate the offer to collaborate. It would be beneficial to team up with someone skilled in Kubernetes custom CSS. My intention is to implement a generic solution that seamlessly accommodates any text direction. Introducing customizations exclusively for right-to-left (RTL) scenarios could complicate our styling process unnecessarily.

It's worth noting that we're concurrently progressing with the migration to newer Docsy google/docsy#1442. Currently, our setup involves custom styling and local old Bootstrap alongside the legacy Docsy, creating complexity. Moreover, our current navbar styling lacks automatic RTL support, adding another layer of intricacy.

Let's ensure our efforts align with the overarching roadmap and streamline our approach for long-term sustainability.

[sftim]

I'm thinking about this as a technical lead for SIG Docs, and I'm keen to either:

• implement the RTL tweaks for the nav bar using SCSS / CSS only (using a selector based on the dir) attribute
• make any layout tweaks conditional on direction

One reason why: when people see that the changes are conditional on direction, any reviewer looking a future change in the same area is likely to take that into account. The reviewer might check for the impact on RTL language layouts, or ask a localization team (for a language written right to left) to confirm all looks well.

[netlify]

✅ Deploy Preview for kubernetes-io-ar-staging ready!

Name	Link
🔨 Latest commit	df3fcd2
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-io-ar-staging/deploys/66312915302a330008d59514
😎 Deploy Preview	https://deploy-preview-46042--kubernetes-io-ar-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 site configuration.

[mboukhalfa]

Let's build on that. Can we make the customisations only apply using the cascade when dir is rtl? (We can pair you up with someone who knows SCSS to help make that happen).

I created here a simplified example blue navbar is the current implementation and the green my suggestion. Both are shown in their default state and when using RTL.:
https://www.codeply.com/p/bNdMgLE0A5

[sftim]

As drafted, this change makes the top nav not look right in narrow viewports for LTR locales. I'd really like to see something that doesn't regress (partially break) our existing localizations, which are all LTR.

[mboukhalfa]

As drafted, this change makes the top nav not look right in narrow viewports for LTR locales. I'd really like to see something that doesn't regress (partially break) our existing localizations, which are all LTR.

I understand your concerns! Please note that this draft serves as a minimal PoC to highlight the primary issue [ Menu and Logo should switch sides when using dir="RTL" ]. The final solution would be refined for example now the position of the logo is not aligned with the menu and that's related to other misuse ( semantically and make it hard to position ) such as setting the logo as a background image to an element.

website/assets/scss/_custom.scss

Line 149 in 99a1995

background-image: url("/images/nav_logo.svg");

Rest assured that the final solution (targeting main) will treat all those side issues however for now I am looking for guidance and experts here willing to review the work

[sftim]

draft

/retitle [WIP] Adapt nav bar to support RTL locales

If this is a work in progress, we should mark it as such (in case someone approves it without realizing).

[mboukhalfa]

If this is a work in progress, we should mark it as such (in case someone approves it without realizing).

Thanks I was not worried about this since it is targeting a dev branch

[sftim]

It's best not to merge work-in-progress PRs to a localization branch; remember that we intend one day to merge all of that work into main.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale