Resource names in sidebar are not matching original names

[kotkoroid]

URL of the page that's broken

https://search.opentofu.org/provider/cloudflare/cloudflare/latest/docs/resources/queue

Screenshot

OS, browser version, installed extensions

macOS 15.3
Mullvad Browser 14.0.5
uBlock Origin 1.62.0

Additional information

As most resources online use original naming, this could cause confusion when porting to OpenTofu.

[diofeher]

Hello and thank you for this issue! The core team regularly reviews new issues and discusses them, but this can take a little time. Please bear with us while we get to your issue. If you're interested, the contribution guide has a section about the decision-making process.

[Untersander]

The first time i was looking for something in the sidebar this was also confusing to me, but I actually prefer the new style of opentofu now.
I would be interested to see what the core team's opinion is on this.
I would not say that the page is broken or that it is a bug, it's just different styling decision.

[cam72cam]

I kind of like the concise format. Especially on smaller screens, it's easier to navigate. The page title still reflects what the item's true name is.

[apparentlymart]

Hi @kotkoroid! Thanks again for opening this issue.

The OpenTofu core team discussed this today. In the discussion we noted that this seems like a tricky tradeoff without a single clear "correct answer":

1. A huge list of items where everything has the same prefix -- particular when it's a long prefix as is the case for some providers -- tends be hard for some readers to "scan" effectively, because it damages the visual hierarchy. Even putting that aside, these resource type names tend to be quite long overall and so the navigation bar already needs to be rather wide to accommodate even these slightly-abbreviated names.

2. On the other hand, presenting a list of items that appears to be a list of verbatim identifiers is potentially confusing, and there is some risk that someone will copy the name from the sidebar and get poor feedback when it doesn't work.

   Whether or not the prefix needs to be included was one of the confusions that appeared multiple times in tofu init should warn if a provider exists with a prefix opentofu#2084 (comment), and although we recently added some additional advice to the relevant error message in Add a new warning when a provider cannot be downloaded and it was requested by an implicit usage opentofu#2479 it still remains to be seen whether that will be enough of a clue for those encountering it to realize their mistake, particularly if the navigation text in the docs appears to confirm that they used the correct name.

Overall our conclusion was that we don't intend to make any changes here immediately, but we will watch for further evidence of whether or not this presentation is proving confusing for readers, and whether that confusion is temporary or persistent.

One compromise idea we considered was to present the names with both the shared prefixes and the underscores removed, so that they appear less like ready-to-use resource type names. However, we're just recording that idea for future reference and not planning to adopt it yet, due to the conclusion in the previous paragraph.

We're going to leave this issue open in case anyone wants to share additional specific examples of the current presentation causing confusion. Being as specific as you can about what the result of the confusion was and how the confusion was resolved could help us to find a better compromise if we find that this is a recurring problem. Thanks again for raising this!