Some block categories are not translatable

Spun up an MR and started with the (slightly refactored) test from #27. Can see the test-only results at https://git.drupalcode.org/issue/drupal-2500607/-/jobs/5680572

1) Drupal\Tests\block\Kernel\BlockDefinitionsTest::testBlockCategory
Block plugins missing categories: views_exposed_filter_block, views_block, system_powered_by_block, system_messages_block, system_main_block, system_breadcrumb_block, system_branding_block, system_clear_cache_block, navigation_user, navigation_shortcuts, navigation_link, field_block, extra_field_block, help_block, announce_block, local_tasks_block, local_actions_block, page_title_block
Failed asserting that an array is empty.

I then applied all the same categories from the existing patches, but of course we have attributes instead of annotations now, so had to be done manually. There were some new plugins revealed by the failing test so I added categories for those as well.

Then I added in the changes to CategorizingPluginManagerTrait and CategorizingPluginManagerTraitTest, but didn't quite follow @alexpott's comment in #33. Maybe it wasn't clear that this is a fallback, so we get the "provider" and try to translate that.

Guessing the IS needs an update, maybe some new screenshots.

The Needs Review Queue Bot → tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request → . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

Ok thanks bot. Hiding patches, even though I think they are useful for confirming that the MR is on the right track.

Amending attribution.

Can we update the summary with a proposed solution.

Also this brings up a question about attributes, if we are adding a new key how do we ensure contrib/custom modules update theirs too? WOuld have to be done in the attribute itself?

Can we update the summary with a proposed solution.

Done

Also this brings up a question about attributes, if we are adding a new key how do we ensure contrib/custom modules update theirs too? WOuld have to be done in the attribute itself?

The key already exists in the attribute, but it's optional. We're ensuring all core blocks have a category set. Contrib/custom will fallback to the module name, which we're now translating. Although I was under the impression we're only meant to translate string literals, so not sure if that part is suitable. We could always deprecate not passing a category, but that could be pretty annoying.

Did a search for #[Block and there appear to still be other instances

Mainly test blocks, if those aren't needed can we least update the block.api

If you are another contributor eager to jump in, please allow the previous poster(s) at least 48 hours to respond to feedback first, so they have the opportunity to finish what they started!

I don't think we need to do the test blocks. Category is still optional, we're just ensuring core blocks set the category. I've updated the example in block.api.php

I'm still unsure about the fallback translation in CategorizingPluginManagerTrait. If we have that, why bother enforcing all the core blocks have a category?

idk if a good search but I looked for $definition['provider'] and didn't see any other spots that are doing translations.