Created attachment 1855621 [details]
We should be consistent in the case we use for the "All Projects" and "all applications" dropdown items, particularly because they appear side by side. One uses headline case, the other is all lowercase. (See screenshot.)
- "All Projects" should be "All projects"
- "all applications" should be "All applications"
Created attachment 1858390 [details]
Created attachment 1858391 [details]
Created attachment 1858392 [details]
Created attachment 1858393 [details]
Created attachment 1858394 [details]
Asked Abigael Donahue about our convention. Thanks for this answer:
It seems like "application" and "projects" are treated as common nouns (not capitalized) in documentation and in examples I found in the terms list, so I'd follow that convention, even though there is a project resource and not an application resource. So this is what I'd recommend for the examples you shared:
- Create application
- No applications
- Create project
- No projects
We should fix and correct this it on the shown pages/screenshots, and search for more inconsistencies.
We have different conventions in console itself for k8s kinds. Currently, we always use PascalCase for Kubernetes types. Since Project is a type, I'd expect it to be capitalized. If we change Project, we have to consider changing all kinds, which is an enormous change :/
To give some more background:
The reason we do this is that we have to handle custom types that can have any name. We only get the PascalCase kind from the API. We used to try to humanize these names in descriptions, but there is no good rule for doing it correctly. For instance, `OAuthClient` should be humanized to `OAuth client` and not `o auth client`. You can't know that programmatically unless you special case every exception, which is impossible because users can add their own custom resources. To avoid these problems, we decided to always use the k8s kind when referring to resources in the console even though this is not what the docs use.
We could revisit this, but it would be a large effort and potentially require a big chunk of the UI to be translated again due to string changes if we're not careful.
Verified it on 4.11.0-0.nightly-2022-02-16-131355. Now we have the `All applications` option in Application dropdown.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Important: OpenShift Container Platform 4.11.0 bug fix and security update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.