Initialize i18n foundation for English (en)

[TineoC]

This PR establishes a foundation for the default language, English (en), on the Kubernetes Contributor Site (k8s.dev).

Fixes #167

/kind feature

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: TineoC

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [TineoC]

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]

There are empty aliases in OWNER_ALIASES, cleanup is advised.

[k8s-ci-robot]

There are empty aliases in OWNER_ALIASES, cleanup is advised.

[k8s-ci-robot]

There are empty aliases in OWNER_ALIASES, cleanup is advised.

[k8s-ci-robot]

There are empty aliases in OWNER_ALIASES, cleanup is advised.

[k8s-ci-robot]

There are empty aliases in OWNER_ALIASES, cleanup is advised.

[k8s-ci-robot]

There are empty aliases in OWNER_ALIASES, cleanup is advised.

[TineoC]

/verify-owners

[TineoC]

@kubernetes/sig-docs-leads

Is it fine if we include the following channels?

#sig-docs
#sig-docs-localizations

cc. @lmktfy

[divya-mohan0209]

Regarding the inclusion of #sig-docs Slack channel, IMO, it'd be best to scope it to docs-related issues, concerns, and queries only. @natalisucks @reylejano would love for you both to chime in with your opinions, as well.

Tagging @seokho-son & @a-mccarthy since they're the leads for the localization subproject, and I'd like them to weigh in on the inclusion of the #sig-docs-localizations Slack channel.

[reylejano]

There are contributors to both SIG Docs and ContribEx as many contribute to many parts of the project. Since the contributor-site is under SIG ContribEx, ContribEx makes the decisions. Since SIG Docs has a localization subproject and has experience with localization, SIG Docs localization contributors can help and provide guidance but there should be a specific localization team for the contributor-site; SIG Docs localization contributors can contribute to both as we do with k/website and k/contributor-site.
Maybe not in this PR but in a future PR, I would establish a framework / guide to localizing the contributor-site like:

• for a new localization, make a new branch of k/contributor-site main and give it a specific naming convention.
• for a localization to be published, it must localize the following pages: (examples) getting started, guidelines & platforms, github-workflow

[natalisucks]

So, I have a different POV. Currently, for the contributor site, we have a specific list of owners, and IMO, they should also probably be the ones who would "own" the English localization of the contributor site as well, and then we involve localization teams if they have the capacity or want to localize these docs. We wouldn't include the contributor site as a minimum set of docs needed to launch a localization, but it would be up for the specific team if they want to localize.

If we go by this model and we use the current contributor site owners as the overall owners, then I don't think there's an issue with also adding in the sig-docs and sig-docs-localization channels: we'd just need to make the distinction clear

[TineoC]

There are contributors to both SIG Docs and ContribEx as many contribute to many parts of the project. Since the contributor-site is under SIG ContribEx, ContribEx makes the decisions. Since SIG Docs has a localization subproject and has experience with localization, SIG Docs localization contributors can help and provide guidance but there should be a specific localization team for the contributor-site; SIG Docs localization contributors can contribute to both as we do with k/website and k/contributor-site. Maybe not in this PR but in a future PR, I would establish a framework / guide to localizing the contributor-site like:

• for a new localization, make a new branch of k/contributor-site main and give it a specific naming convention.
• for a localization to be published, it must localize the following pages: (examples) getting started, guidelines & platforms, github-workflow

Let me know your thoughts of this https://github.com/TineoC/contributor-site/blob/i18n-foundation-en/CONTRIBUTING.md#localization-i18n

[natalisucks]

Thanks, @TineoC! I like the conciseness of the README, my only feedback is to add a Slack channel for general questions (perhaps the contribex channel for general questions, then listing sig-docs and sig-docs-localizations for specific questions about starting a localization)

Tagging @seokho-son also for his thoughts

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: TineoC

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [TineoC]

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

[natalisucks]

Howdy @TineoC – take a look at the comments by @reylejano and myself, and it's worth noting that the canonical list of owners for the contributor site is here: https://github.com/kubernetes/contributor-site/blob/main/OWNERS – IMO this should be the basis for the "owners" of the localization, so that they have approval permissions just the same as localization teams owning their own pages would

[natalisucks]

So, I have a different POV. Currently, for the contributor site, we have a specific list of owners, and IMO, they should also probably be the ones who would "own" the English localization of the contributor site as well, and then we involve localization teams if they have the capacity or want to localize these docs. We wouldn't include the contributor site as a minimum set of docs needed to launch a localization, but it would be up for the specific team if they want to localize.

If we go by this model and we use the current contributor site owners as the overall owners, then I don't think there's an issue with also adding in the sig-docs and sig-docs-localization channels: we'd just need to make the distinction clear

[natalisucks]

From a SIG Docs perspective, after chatting with @TineoC and us agreeing that ContribEx owns their own localizations, but SIG Docs would own processes of how localization happens, I am good with this change. Adding @reylejano @divya-mohan0209 and @seokho-son once again to this thread for any final checks before we add an LGTM tag from Docs (please note this already has pre-approval since that is the workflow of the contributor site)

[TineoC]

/hold

[kubernetes-prow]

PR needs rebase.

Details

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.

[divya-mohan0209]

I've a query regarding owning the "how of the localisation". If SIG Docs owns it, does that also mean it is unilaterally responsible for any procedural changes with SIG ContribEx chiming in?