-
Notifications
You must be signed in to change notification settings - Fork 14k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve patch releases page #46368
base: main
Are you sure you want to change the base?
Improve patch releases page #46368
Conversation
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
data/i18n/en/en.toml
Outdated
@@ -519,12 +519,27 @@ other = "2006-01-02" | |||
[release_date_format_month] | |||
other = "January 2006" | |||
|
|||
# Use 2006-01-02 (ISO 8601) if you are not sure what to use. | |||
[release_date_format_text] | |||
other = "Monday, 02 Jan 2006" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this will work for localization teams.
This encoding is Golang specific, and the convention here won't translate well into any other languages.
ISO 8601 is a standard that can be followed by all localization teams though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# Use 2006-01-02 (ISO 8601) if you are not sure what to use.
I could change that to explicitly mention that Hugo doesn't support localized date formatting. For English, we can still provide the tooltip, and if Hugo gains support, this will Just Work for other locales.
How about that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like we can localize dates, but we have to use the exact language codes.
https://discourse.gohugo.io/t/localizing-date-format/37868 has more on this.
[release_cherry_pick_deadline] | ||
other = "Cherry Pick Deadline" | ||
|
||
[release_end_of_life_date] | ||
other = "End Of Life Date" | ||
|
||
# Also see release_maintenance_and_end_of_life_details_past | ||
[release_maintenance_and_end_of_life_details_current] | ||
other = "Kubernetes {{ .minor_version }} enters maintenance mode on {{ .maintenance_mode_start_date }}; the End of Life date for Kubernetes {{ .minor_version }} is {{ .release_eol_date }}." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this will work.
I'm not aware of any convention related to the order of template variable substitution and the replacement of localized strings. This uncertainty could be the reason why we have partial sentences in the current file like "xxx_before" or "xxx_1" and "xxx_after".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does work; check the page previews to see how it looks.
partial sentences in the current file like "xxx_before" or "xxx_1" and "xxx_after".
The approach I'm switching to here is what Hugo itself recommends; what we are already doing is more of a bodge (I can say that, because some of those bodges are by me from before I realized the right way).
<td> | ||
{{ time.Format ( T "release_date_format") $patchReleaseInfo.targetDate }} | ||
{{- with $patchReleaseInfo.targetDate -}} | ||
<time title="{{ time.Format ( T "release_date_format_text") . }}" datetime={{ time.Format "2006-01-02" . }}>{{ time.Format ( T "release_date_format" ) . }}</time> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm concerned with the direction of this change is leading us to.
There is no doubt that the automated generation of certain pages or elements could help improve productivity. But this is still a documentation project anyway. Over engineering may not be a good thing to website maintainers. Whenever possible, we should try "keep it simple and stupid (aka KISS)". Carving on shit is not something we as a community should encourage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- The patch releases page is one of our most frequently updated pages and largely changes through data-driven changes.
- Rather than improve productivity for SIG Release, my intent here is to improve UX for people reading the rendered page.
For example, if you can see that an EOL date is a date your business does not usually work, that helps you plan.
It's even better for firms not to wait until the last possible moment to make a change, but I know there are corporations that wait exactly that long.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggested an alternative, more complicated approach: #46426
We have two EOL dates for v1.18, which is likely to confuse readers more than it helps them. Fix that.
and link to CVE list
- Use Hugo's built-in support for localizing dates - Allow customizing date formats separately - Make more dates machine readable - Add a tooltip for dates
241ec56
to
b58fe0b
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Improve https://kubernetes.io/releases/patch-releases/ especially around date rendering.
Example (Bengali):