Today I worked on a project where the customer had asked us to add a missing translation for the label of an exposed filter of a view. The view configuration was originally imported upon installation of a contributed module, that uses that view. I thought that this would be an easy task quickly done: We have configuration translation enabled on that system so all views have a "Translate" operation that you can use to translate the view. Not in this case, of course ;).
I was logged in as the magic super user 1 with the magic administrator role assigned to it, but I still got a 403 access denied exception each time I tried to translate this particular view. Other views that we had created manually or that were provided by other contribued modules worked fine. But not this one. What the ****?
After searching the core issue queue for a while to no avail, I ended up to comment out the "throw AccessDeniedException" in the AccessAwareRouter, just out of curiosity. After all this was a dev system, so what could possibly go wrong? And then I instantly realized what the problem was. The list of translations was displayed and I saw that the "original translation" was "language undefined" or "und". Looking at the configuration object more closely confirmed, that the language was "und". In hindsight, it was kind of logical that I couldn't translate that one, right?
Of course I didn't make the foolish attempt to create an English translation for the view via UI. Since Views doesn't have a UI to change the language of a view like for example Content entities have, I decided to just export the configuration using Drush, find the YAML file for the configuration object in question, edit it so that the language was no longer "und", but "en", and import the configuration again using Drush. Now I was able to translate the view using the UI without my quick modification of the AccessAwareRouter.
Yet another lesson learned.
Systems
Drupal 8/9