Restore canonical link template to fix regression issues

I can reproduce the error. Additionally. I've also noticed that the translation option for the Site Settings entity is missing. This appears to be caused by the removal of the "canonical" route in this commit, related to this issue. Re-adding the line
"canonical" = "/admin/structure/site_setting_entity/{site_setting_entity}",
restores the translation functionality.

Thanks for getting to the bottom of it. So reverting this one? #3522947: Remove the canonical route of the site setting entity type. It was the solution to a different issue though with the old flattened site settings loader, so would need to understand how to get a fix that covers both

Just marking #3527709: Undefined array key "metatag" possibly on Site Setting Entity as duplicate, as likely my issue was the same as here.

I think, usually when removing the canonical route, it's not "actually removed" but instead redirects or links to the edit link template?
I feel like that should solve the initial issue along with this issue.
The canonical "route" remains, but it's not an actual route and just sends you to the edit page.

We are encountering similar issues.
Site settings entities are no longer translatable after #3522947: Remove the canonical route of the site setting entity type has been committed.

The translatability of an entity is checked by \Drupal\content_translation\ContentTranslationManager::isSupported().
This checks if there is a link template "drupal:content-translation-overview".

Looking into where this template is defined - \Drupal\content_translation\Hook\ContentTranslationHooks::entityTypeAlter, we see it is only defined after the following logical check:
if ($entity_type->hasLinkTemplate('canonical')) {}

Which is now no longer the case.

I think the safest solution would be to restore the canonical route, and perhaps just load the entity "edit" form for that route?

Yeah that sounds like a good plan re #6 thanks!

I have added a new MR now, to attempt to fix this issue.
In the first commit, I just restore the canonical link for SiteSettingEntity.

In the second commit, I add a configuration setting to not render the site entity on its canonical link, but its edit form instead.
I have added an option in the config form to disable this.

I'm not really sure why site settings shouldn't have a canonical view actually... When you use the revision system of that entity (by deselecting the config option "Hide the administrative advanced options"), it would make sense that you can view the latest revision of the entity + earlier revisions, for comparison. They are only viewable for people with the "view published site setting entities" or "view unpublished site setting entities" permissions...

I'm not sure what the exact issue with the flattened site settings loader is exactly, that causes an infinite loop, but there might be another way to fix that, rather than messing too much with the default Drupal entity link templates...

Can someone check if my solution that renders the edit form instead, fixes the flattened site settings loader issue?
And could use some extra thoughts on whether the edit form rendering is a good idea to begin with...

Adding a simple patch file to just restore the canonical link, to fix this issue via Composer patching workflow (only recommended for websites not using the flattened site settings loader obviously), while awaiting a more robust solution in the next release.

Renamed issue for clarity.

Thanks very much for the work on this! Looks good to me! I didn't make any change other than labels/variable names, but worth a quick check if you have any major concerns @svendecabooter before I merge.

Beyond that added a very basic test coverage to this. Will add a follow-up issue to add test coverage for translation itself.

Leaving as needs review to get your thoughts, but RTBC+1 from me

Looks good to me.

Thanks!