See: #4600 for context
Long story short, it would be a good idea to extend the admin label and description to be consistent across all of backdrop.
There should be a standard API to the way it works on BD and it should be available to contribs if they want to use it, but not a requirement.
I also feel like we need to figure out how the wording will work for "most" use-cases throughout backdrop, then it can be addressed on how each specific area needs to have wording tokenized for it's respective use.
(loose) Examples: Blocks Add a label or description to better identify this [block] on admin pages.
Fields Add a label or description to better identify this [field] on admin pages.
Views Add a label or description to better identify this [view] on admin pages.
Add a label or description to better identify this [view_relationship] on the view admin page. Taxonomy Add a label or description to better identify this [taxonomy] on admin pages.
etc.
Make the wording congruent, such that any time someone runs across it, they understand its purpose. Otherwise, if each respective task has it's own vocabulary, it can become confusing as-to what the goal is. "I think this is where I set my own name for easy identification? But... I'm not really sure because it says something different??"
Another thought: How can the wording be conveyed so that non-programmers can easily understand it? I am all-to-guilty of bringing out my analytical side when I talk, but I think sometimes we get carried away with certain lingo that 35% of the userbase has a hard time understanding. Something to think about.
Recent comments
Graham Leach: Has anyone got any experience with the assets in this area of Backdrop CMS? filetransfer.inc ftp.inc local.inc ssh.inc If you do, I'd love to chat with you... Graham...
Jan 16th 2025 Weekly Meetings
I've been building Backdrop sites since 2021 with the first being my own: https://www.systemhorizons.co.uk/ Two over time for one client: https://www....
Happy Birthday Backdrop CMS - Share your projects!
Hi Tim. Yes I think at the moment it needs custom code. Depending where you want the class it could be either: /** * Implements hook_preprocess_page(). */ function theme_name_preprocess_page...
How to make clear to editor if they are on a revision?