UX: would you accept renaming the Settings Classes category to something more discoverable (e.g. Object Schema)?

[MichaelUray]

Context

While working on the Workspace Access Center proposal (PR #10883 follow-up), an independent IA / naming review of the Settings sidebar surfaced one item I'd like to raise here before doing anything in our fork:

The Settings → Classes entry exposes the Doc-class schema definitions (e.g. tracker.class.Issue, card.class.Card, mixins, inheritance). For workspace operators / admins coming from outside the Huly codebase, the term "Classes" reads as generic OOP jargon and gives no hint about its operational purpose ("am I editing user-visible labels? schema migrations? something dangerous?").

Two operators we asked independently both guessed wrong ("permission classes?", "CSS classes?").

Proposal (open for discussion)

Rename the Settings category label only — not the underlying model symbols / TS class names — to one of:

• Object Schema — most descriptive, matches what's actually shown
• Data Schema — same idea, slightly broader
• Document Schema — accurate but might be confused with the Document plugin
• Schema — shortest

We'd keep the route key (classes) for deep-link compatibility. Only the i18n string + sidebar icon caption change.

Why I'm asking first

Renaming a top-level Settings entry in our fork is easy, but it creates terminology drift vs. upstream docs, training materials, support channels, and any future upstream-PRs we'd send. I'd rather:

1. Get your read on whether Classes is a deliberate choice you want to keep — if yes, we accept it in our fork too.
2. If you're open to renaming, agree on a target term before either of us does it independently.
3. Avoid filing a PR that then gets bounced for naming-bikeshed reasons.

What I'm NOT proposing

• Renaming the TypeScript class.Class model symbols (those are internal API).
• Touching the Object plugin or related domain models.
• Hiding the entry — power-users still need access; this is purely a label question.

If there's a maintainer position on this already (issue, prior discussion, internal style guide), please point me at it.

Happy to send a PR with the chosen wording + the 13 locale files updated if there's interest.