As a continuation of ideas from #5248
Backdrop lacks the ability to organize from an administrative standpoint. This causes larger sites to suffer from being able to narrow down to the specific item they are trying to look for.
Proposed solution
What is proposed is to take the same tagging system that is used in Views and extend it to all entities, menus and areas where an admin tag would better organize that information. When tagging with Views, a filter can narrow down to show all of the views that have a specific tag. If a site has a large number of views, this can be a huge time-saver when compared to combing through every view name.
As an example, imagine a site has 30 content types and of those, 5 are dedicated to services. Being able to tag each service content type as "service" would allow a site builder to narrow down the list of content types to only show the service ones.
Like views, tagging should be an optional feature.
This should be designed in such as way that it can encompass any contrib that wants to benefit from it but preferably designed so that contribs automatically incorporate it if they fit a certain criteria such as creating an entity. Paragraphs, Commerce, ECK, etc are some examples that create entities and should have this without the authors explicitly enabling it. (The API should have an option to disable in code if the author doesn't want it included)
Admin tagging should not be tied to, or viewed as a taxonomy solution. This idea should be a completely separate tagging system that works in the background and only exposes itself to the admin interface. I would imagine a single new DB table to hold all of the tags is all that would be needed. Views tags would need to be converted to this table at some point down the road.
I recommend adding an admin tagging overview page OOTB for core that lists all objects that are tagged, grouped by the type of tagged object (content type | block | paragraph | etc). This could easily be accomplished with a view once the admin tagging has been exposed to views.
Additional information
The same author who created Views, also added tagging to many of his other projects. His implementation was far more intricate than what is proposed here as those tags would directly and dynamically influence whether fields etc were exposed to other areas that were connected by the tags. I don't think we need to go that far with it, however I would recommend laying the groundwork so that it might be possible through contrib or future realizations of this need.
Draft of feature description for Press Release (1 paragraph at most)
Backdrop now includes the ability to create optional administrative tags on content types, blocks, menus and more to help better organize how the site displays information relevant to site builders. For example, when editing a content type, you have the option to add a tag and narrow down by that tag name in the content type overview page.
Recent comments
Very interesting - seems useful. But it gives me an error: SQLSTATE[42S22]: Column not found: 1054 Unknown column 't.langcode' in 'where clause': SELECT t.translation FROM {...
Ubercart in Danish?
You can always use Translation template extractor to extract the untranslated strings from a specific module (like Ubercart). Very easy to use.
Ubercart in Danish?
Thank you Olaf, I am in the process of getting every string on my experimental site with Ubercart translated by ChatGPT - so far with very acceptable result (better than I could do...
Ubercart in Danish?