replace role="alert" with role="note"

[orangecms]

The "alert" role is meant for shortlived content, usually for interactive apps. The "note" role, on the other hand, is meant for content that has no suitable semantic element otherwise and is supposed to hint the user on ancillary information.

See:

• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/alert_role
• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/note_role

Description

Issue

Closes: #

[k8s-ci-robot]

Welcome @orangecms!

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. 😃

[netlify]

✅ Pull request preview available for checking

Built without sensitive environment variables

Name	Link
🔨 Latest commit	e3ef834
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-io-main-staging/deploys/698ada33631df50008a27f24
😎 Deploy Preview	https://deploy-preview-54363--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.

[jgrancell]

/LGTM

[k8s-ci-robot]

@jgrancell: changing LGTM is restricted to collaborators

Details

In response to this:

/LGTM

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[Caesarsage]

Hello @orangecms
Thanks for your contribution. We try to make a PR per language.
Can you update your changes to a single language (say English) and when that is reviewed and approved you can raise for the other languages affected

[orangecms]

Hello @orangecms
Thanks for your contribution. We try to make a PR per language.
Can you update your changes to a single language (say English) and when that is reviewed and approved you can raise for the other languages affected

Sure, though it doesn't affect the "language" in that sense here, just the HTML semantics.

[lmktfy]

SIG Docs recommends updating one language per PR.

We can accept this if each localization team, for each of the languages updated in this PR, agrees to an exception from our usual process, or if a website maintainer overrules their decisions. I like the idea of making this change but (as someone able to overrule localization teams decisions) I can't justify using my position there.

The problem with having multiple localizations covered is that it can take a (very) long time to wait for all of those teams to agree to make an exception. The simple choice: revise this PR to update English; other localizations will follow their processes to pick up the change.

[orangecms]

SIG Docs recommends updating one language per PR.

Yea that's the thing - no language change here.
It only appears like it due to some rule saying "if in directory ru, it must be a change of the Russian translation" - which is not always the case. See the discussion where a Russian language maintainer mentions this PR as another example of issues with the simplified rule.

We can accept this if each localization team, for each of the languages updated in this PR, agrees to an exception from our usual process, or if a website maintainer overrules their decisions. I like the idea of making this change but (as someone able to overrule localization teams decisions) I can't justify using my position there.

Well, now we have a deadlock - the RU maintainer has merged the split partial PR I filed, and the PT-BR maintainer has blocked the other PR waiting for this PR here. And so we are both locked and in an inconsistent state.

The problem with having multiple localizations covered is that it can take a (very) long time to wait for all of those teams to agree to make an exception. The simple choice: revise this PR to update English; other localizations will follow their processes to pick up the change.

There is no change in "English". One PR has the changes in layouts. Should I close that one and push it here? I'm confused.

[orangecms]

ok so that part is resolved now:
#54409 (comment)

[orangecms]

I'm not seeing the discussion reference here, whoops:
#51006 (comment)

[chalin]

Hi. Good point in calling this out @orangecms, but as I mentioned in google/docsy#2554, I think that we need a more nuance approach.

For example in this PR, caution and warning should probably stay as an alert and/or depend on the argument. Or at least a status role.

[orangecms]

Hi. Good point in calling this out @orangecms, but as I mentioned in google/docsy#2554, I think that we need a more nuance approach.

For example in this PR, caution and warning should probably stay as an alert and/or depend on the argument. Or at least a status role.

The "alert" role is for live content though, things that need immediate attention. The "note" role is a general thing, not restricted to "levels" of admonition/severity; see the respective explanations on MDN I referenced.

[lmktfy]

I agree with this, but it ought to change only one localization (English).

You could get an exception made, but that means either asking each localization affected to agree to the exception, or asking SIG Docs to overrule the usual process of checking with affected teams before bypassing their processes.
If this were just 1 commit that only touched English pages and files that aren't locally at all, I would be happy to mark it LGTM.

/area web-development

[SayakMukhopadhyay]

I agree with this, but it ought to change only one localization (English).

You could get an exception made, but that means either asking each localization affected to agree to the exception, or asking SIG Docs to overrule the usual process of checking with affected teams before bypassing their processes. If this were just 1 commit that only touched English pages and files that aren't locally at all, I would be happy to mark it LGTM.

/area web-development

I think this is a good use case for this discussion #51006. The changes to the localised pages only affect the html and not the content itself and that too is minimal.

[stormqueen1990]

Leaving my (proactive) approval here for the Brazilian Portuguese portion in case the final decision is to merge as-is
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: stormqueen1990
Once this PR has been reviewed and has the lgtm label, please assign nate-double-u for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[lmktfy]

I'll highlight this to SIG Docs localization folks to sound out the appetite for an exception.

[shurup]

LGTM from the Russian localisation team.

[seokho-son]

PTAL @kubernetes/sig-docs-hi-reviews :)

[dipesh-rawat]

LGTM from the Hindi localisation team.

[orangecms]

So the current state is inconsistent, but also not really blocked:

As per request, I had split up the PR.
Two of the new PRs were merged.
PT-BR put theirs on hold and LGTMed this one.
HI LGTMed theirs and this one.

What can I do from my side to get this finished?

[lmktfy]

So the current state is inconsistent, but also not really blocked:

As per request, I had split up the PR. Two of the new PRs were merged. PT-BR put theirs on hold and LGTMed this one. HI LGTMed theirs and this one.

Ah, if those other PRs have merged, we can use this as evidence to not ask for further actual checking.

I have done that. So, I think we can soon close this as a success, albeit via a route that was more complicated than we'd have liked.

[lmktfy]

/close

Implemented via the split-out PRs. Thanks for working on this, @orangecms.

[k8s-ci-robot]

@lmktfy: Closed this PR.

Details

In response to this:

/close

Implemented via the split-out PRs. Thanks for working on this, @orangecms.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[orangecms]

Thanks, I'm glad this worked out eventually. 🙂🧡