✅ Pull request preview available for checking

Built without sensitive environment variables

Name	Link
🔨 Latest commit	4fa23bc
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-io-main-staging/deploys/64a3f819fa48dd0008eaa888
😎 Deploy Preview	https://deploy-preview-41768--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 site configuration.

/area web-development

LGTM
(this PR implements what its description says it does)

However:
Please omit the Japanese localization for the added strings. That should arrive in a follow up PR.

Once you make that change @morix1500, I recommend you squash this down to 1 commit.

As this stands:
/lgtm

The tweak I suggested in #41768 (review) is welcome too; either as a change in this PR, or as a follow up.

Thank you @morix1500

LGTM label has been added.

/lgtm

This PR does what the description says it should.

LGTM label has been added.

/area localization

Thank you @morix1500 for this! This will be extremely helpful.

This is a nice addition for the website! Thanks for working on this @morix1500 😃

I think the files for the Japanese localization were removed but the label wasn't removed.

/remove-language ja

I believe this is a positive addition and a step in the right direction. However, I have identified a potential limitation. Currently, any update made to the localized file modifies the Lastmod value and disables the "Needs update" notification, even if further content updates are required. It is important to make the localization teams aware of this limitation and encourage them to take additional measures. If feasible, they should consider adopting the "automated-diff" scripts utilized by the Korean localization team. These scripts have proven to be effective in ensuring accurate updates.

I believe this is a positive addition and a step in the right direction. However, I have identified a potential limitation that needs to be addressed. Currently, any update made to the localized file modifies the Lastmod value and disables the "Needs update" notification, even if further content updates are required. It is important to make the localization teams aware of this limitation and encourage them to take additional measures. If feasible, they should consider adopting the "automated-diff" scripts utilized by the Korean localization team. These scripts have proven to be effective in ensuring accurate updates.

A suggestion to address this risk would be to adopt a new front-matter field as a next step that indicates the version of a given page. I imagine it might be undesirable from a broader docs perspective, but a change such as that could allow more reliable checks across localized content.

I believe this is a positive addition and a step in the right direction. However, I have identified a potential limitation. Currently, any update made to the localized file modifies the Lastmod value and disables the "Needs update" notification, even if further content updates are required. It is important to make the localization teams aware of this limitation and encourage them to take additional measures. If feasible, they should consider adopting the "automated-diff" scripts utilized by the Korean localization team. These scripts have proven to be effective in ensuring accurate updates.

Is the lack of a notice a problem? If so, how much?

If in future we want to track where a page is up to, I'd record the short ref that the page was last brought fully up to data against. But really we'd love to make localization work simpler, not add effort.

I love the simplicity of this solution and definitely would not want to make things more complicated. However...

Is the lack of a notice a problem?

Indeed. Users and localization contributors might misinterpret the missing notice as an indicator that the content is up-to-date, leading to the following unintended consequences:

• Users who need the current recent information (from the unlocalized English content) might use the outdated localized content.
• Localizers might overlook the need to refresh the localized content.

If so, how much?

This is unclear and varies depending on the circumstances.

• As it stands, without a notification, users are left to decipher this on their own.
• By introducing this notification, we take on the liability of providing information that occasionally misleads.

Here is how we update a zh-cn localization page. The localization team reached a consensus about two years ago:

• We check if a page is "fresh" or not based on its last commit time (against the English upstream).
  Nothing is simpler than time comparison.
• To make timestamp-based checking feasible, the localization reviewers need to
  ensure each time a page is being "refreshed" by a PR,
  all upstream changes to that page are incorporated in the same PR.
  In other words, no partial updates are supposed to be merged.

These rules appeared too strict during the first few weeks/months. When the convention
is formed and shared across the team, everything works great till now.

There is a secret tool which really helped, scripts/lsync.sh.
To check if a ja page is out-dated, run:

./scripts/lsync.sh content/ja/docs/path/to/page.md

To get an overview of out-dated pages, run:

./scripts/lsync.sh content/ja/docs/path/to/directory/

As a side note, I'm not a big fan of adding more banners to the pages.
I've just filed an issue related to this. #41859

@morix1500
As commented in previous review, you can squash the commits.
Please see this ja page or en page.

Love this change and really happy to see how fast the idea was implemented after our recent discussion in Slack. While it is a simple implementation, I fully support it. I think we can think about improving it further after introducing this change to the end users and getting their first feedback.

It will be also important to inform all localisation teams about this change and its limitations (the possible Lastmod-based-only inconsistency concern that was fairly mentioned above).

Preview of the change proposed in this PR

I support this change
/approve

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: reylejano

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

The pull request process is described here