Render API reference using a content adapter

[sftim]

This is a Feature Request

What would you like to be added
[If we like the idea], use a Hugo content adapter to render our API reference pages. This may need supporting code to generate the input data.

Why is this needed
Likely benefits:

• This approach cuts the effort to localize the API reference pages, compared to the existing more manual approach.
• Content adapters let us control the layout (as in URL paths) of the generated pages, and to define the rules in code.
• By moving more of the generation into the Hugo site build, we can automatically hyperlink reference pages to related content pages (such as tutorials and concept guides).

Comments
/area web-development

We'd also need to use Hugo v0.126 or later.

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[Aaina26]

Since this feature request will also change dependency. I would like to add one more tag.
/area dependency

[dshebib]

For clarity, do you mean to use the API reference at https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/ to generate the pages under https://kubernetes.io/docs/reference/kubernetes-api/?

[sftim]

For clarity, do you mean to use the API reference at https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/ to generate the pages under https://kubernetes.io/docs/reference/kubernetes-api/?

I don't think I do @dshebib. I mean that we'd make a new generator that produces special input to Hugo, that Hugo would then render using a new, as-yet-undecided mechanism.

The final thing could look similar to https://kubernetes.io/docs/reference/kubernetes-api/ and we could render a single page reference from the same input data. The ideal is certainly that we can take the best of both worlds.

If folks'd like to explore more about what Hugo can offer, I can make some of my time available to sketch out options.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[mengjiao-liu]

/remove-lifecycle stale