Backport cve-feed shortcode to dev-1.26-ko.1 branch

[jihoon-seo]

Hope this PR resolves the cve-feed shortcode-related Netlify build error.

• [ko] Update outdated files in dev-1.26-ko.1 (M45-M57) #39761:
  https://app.netlify.com/sites/k8s-dev-ko/deploys/6400e3c038c2f70008c2cd23
• [ko] Update outdated files in dev-1.26-ko.1 (M62) #39786:
  https://app.netlify.com/sites/k8s-dev-ko/deploys/6403e18609f95b0008c26d52
• ...

[netlify]

✅ Deploy Preview for k8s-dev-ko ready!

Name	Link
🔨 Latest commit	44334fa
🔍 Latest deploy log	https://app.netlify.com/sites/k8s-dev-ko/deploys/6405bf37b142e30008703ff4
😎 Deploy Preview	https://deploy-preview-39787--k8s-dev-ko.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 settings.

[jihoon-seo]

The Netlify preview build for this PR succeded without error.
After merging this into dev-1.26-ko.1 and getting each related PR rebased against the updated dev-1.26-ko.1, then the Netlify build error of those PRs will be resolved.
(FYI: dev-1.26-ko.1 is the working branch of the Korean localization job for 1.26 (main).)

Since this PR is touching the files under layouts/, it needs lgtm & approval from English approvers.
@mehabhalodiya @nate-double-u as the reviewers of this PR, please take a look!
(CC: @seokho-son)

[seokho-son]

Hi @jihoon-seo
Making this change would not follow the Korean branch strategy. (we don't rebase the upstream development branch for Korean onto the main to keep the commit history. It is to check outdated contents by comparing two Korean dev branches.)

When we try to merge dev-1.26-ko.1 into the main branch, the commit in this PR possibly incur a conflict that may require rebasing dev-1.26-ko.1 onto the main.

How about cheery-picking the related commits? https://kubernetes.slack.com/archives/CA1MMM1HU/p1677746887238269?thread_ts=1677732886.663289&cid=CA1MMM1HU

[jihoon-seo]

@seokho-son please note that this is the cherry-picking PR with the fix commit from #39719.
If needed, I will replace the cherry-picked commit with those from #38579 or e277fe5 (ref: https://kubernetes.slack.com/archives/CA1MMM1HU/p1677746887238269?thread_ts=1677732886.663289&cid=CA1MMM1HU).

[seokho-son]

@jihoon-seo
The cherry-picked commit in this PR is from release-1.25, and it does not exist in main branch.
So, for dev-1.26-ko.1, the commit in this PR is just new changes.

I guess we can minimize conflict with a bare minimum cherry-pick commit from the main when we merge commits in dev-1.26-ko.1 into the main branch. What do you think so ?

[sftim]

Thanks
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sftim

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [sftim]

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

[sftim]

It'd be more useful to merge main into dev-1.26-ko.1 - if that suits the Korean team's workflow. However, this cherry-pick would also work.

[seokho-son]

It'd be more useful to merge main into dev-1.26-ko.1 - if that suits the Korean team's workflow. However, this cherry-pick would also work.

Thanks @sftim
I agree that merging main into dev-1.26-ko.1 is more common way. Unfortunately, it may not fit with current Korean team's workflow. The Korean team's workflow have avoided merging main into an ongoing Korean localization dev branch. (to check outdated Korean contents by comparing differences between two dev branches)

I think it would be nice to use cherry-pick this time, and look forward to improving the Korean team's workflow.

[jihoon-seo]

@sftim Thank you for your approval.

@seokho-son as per your comment, I updated this PR to cherry-pick the commit e277fe5 which is in main branch.
Please note that during the cherry-pick process, the commit hash has been updated as 44334fa, and thus when we merge dev-1.26-ko.1 into main, I guess that Git will recognize those 2 PRs as different & separate ones, not the same one, and eventually we will have both e277fe5 and 44334fa as separate commits in main branch anyway.
And IMO if merge conflicts related with this occur when merging dev-1.26-ko.1 into main, then we might resolve the conflicts with appropriate merge commit.

[sftim]

Don't worry about the duplicate commits. Git is clever, at least about this sort of thing.

[seokho-son]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 8f7e36f7f67147942796c31fbe2453eaad085b0f