fix: correct invalid Gateway example in v1.1 docs

[UgOrange]

Description

Corrects YAML formatting in the spec.listeners section of the Gateway API example.

Issue

Closes: #50222

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: UgOrange / name: UgOrange (7ec23a886631c8c59c001bff9d1a880551d42130)

[k8s-ci-robot]

Welcome @UgOrange!

It looks like this is your first PR to kubernetes/website 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/website has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. :smiley:

[netlify[bot]]

✅ Pull request preview available for checking

Built without sensitive environment variables

Name	Link
🔨 Latest commit	7ec23a886631c8c59c001bff9d1a880551d42130
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-io-main-staging/deploys/67e6b4b84d623a0008ffe8ed
😎 Deploy Preview	https://deploy-preview-50223--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.

[stmcginnis]

Typically we only do one language at a time, but since this is just updating non-translated code samples, I believe it is good to do in one PR.

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 84dcf9babb4d5607b49fc8b388b6d12e25af80f4

[sftim]

Typically we only do one language at a time, but since this is just updating non-translated code samples, I believe it is good to do in one PR.

/lgtm

The trouble is, it may still need 4 signoffs (one per language)

[tengqm]

Typically we only do one language at a time, but since this is just updating non-translated code samples, I believe it is good to do in one PR.

/lgtm

Em... maybe a little bit explanation would help understand why we don't do more than one language change in the same PR. Among the many possible reasons, I have a compelling one to share.

Members of the Chinese localization team, including me, track the upstream English version by checking its timestamp. When we see that an English page en/foo/bar.md (merged on Mar 26th) is newer than the Chinese version (merged on Mar 20th), we do a git diff to identify ALL CHANGES to the English version since Mar 20th. We need to synchronize ALL those changes to zh/foo/bar.md. We as a team only merge fully synch'ed pages to ensure that when zh/foo/bar.md is merged, ALL new changes to the English page are properly handled. If the en/foo/bar.md is newer than zh/foo/bar.md, the Chinese page is treated as "out-of-sync". We have scripts to quickly find out those pages and the new changes to them. Suppose, zh/foo/bar.md is now out-of-sync, the team will reject any PR to zh/foo/bar.md if it cannot prove that it contains all the necessary changes. In other words, partial sync will be strictly rejected. By maintaining this rule across the team, we never miss any changes to the English version.

I don't how other localization team maintains the up-to-date status for localized pages. At least from the Chinese localization team's perspective, changing the zh page along with the en page is always dangerous. We have to check it carefully in case that when such a partial sync is merged, we won't be able to easily tell what other changes could have been missing.

[UgOrange]

Em... maybe a little bit explanation would help understand why we don't do more than one language change in the same PR. Among the many possible reasons, I have a compelling one to share.

Members of the Chinese localization team, including me, track the upstream English version by checking its timestamp. When we see that an English page en/foo/bar.md (merged on Mar 26th) is newer than the Chinese version (merged on Mar 20th), we do a git diff to identify ALL CHANGES to the English version since Mar 20th. We need to synchronize ALL those changes to zh/foo/bar.md. We as a team only merge fully synch'ed pages to ensure that when zh/foo/bar.md is merged, ALL new changes to the English page are properly handled. If the en/foo/bar.md is newer than zh/foo/bar.md, the Chinese page is treated as "out-of-sync". We have scripts to quickly find out those pages and the new changes to them. Suppose, zh/foo/bar.md is now out-of-sync, the team will reject any PR to zh/foo/bar.md if it cannot prove that it contains all the necessary changes. In other words, partial sync will be strictly rejected. By maintaining this rule across the team, we never miss any changes to the English version.

I don't how other localization team maintains the up-to-date status for localized pages. At least from the Chinese localization team's perspective, changing the zh page along with the en page is always dangerous. We have to check it carefully in case that when such a partial sync is merged, we won't be able to easily tell what other changes could have been missing.

I understand your concerns. I've modified the commit to only include changes to the English version of the document, and hope this won't cause any complications.

[tengqm]

/remove-language bn ja zh

[tengqm]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: tengqm

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:

• ~~content/en/blog/OWNERS~~ [tengqm]

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

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: bb9fc179a72ed8b34c179667ab081f258075a9a9