The translations are coming from translatewiki. The offending keys seem to be entityschema-label-edit-placeholder, entityschema-description-edit-placeholder, entityschema-aliases-edit-placeholder.

After consulting with @Jakob_WMDE the motivation to use an <a> tag in termbox was that there is apparently one situation where there SSR needs to render an actual link, which should then act as a js-button in the frontend.
We don't have these circumstances here, so we can use a button straight away.

Chiming in here: At Wikidata Bridge we started using the "new" wdio5, instead of the current wdio4. Is it possible that upgrading might improve the situation?

That EventEmittingButton component uses a link (<a>) with href="#" and styled as a button. This is an anti-pattern and poses accessibility issues. If we need a button, then let's use a semantically correct element and use links if we actually want to link to something.
This will also make our component simpler.

In T228986#5408986, @Jakob_WMDE wrote:

My interpretation is that "this" refers to the component library, not bridge. I'm having trouble seeing the need for product ownership for it.

Yes, we had a good experience with this as EntitySchema. Do note, that in these pre-commit hooks, we did not use grunt, but the linters directly. The reason is that you cannot give files as CLI arguments to grunt and lint-staged is designed to only run the linting on the staged files.
This is basically option 1 of what you mentioned with an added git add where possible.

The experience of termbox about parser cache and their ADR could be related? See https://gerrit.wikimedia.org/r/530092

This happens only on commons, so adding tags for the WikibaseMediaInfo/Structured Data on Comons team.

Results of my investigation so far:

From the merged commits I cannot see anything that suggests that this ticket has been implemented. Therefore, I consider this to still be relevant and title is still accurate. I will add explicit AC, if that is needed.

Currently,

Recent changes appear to work fine for Lexemes for now: https://www.wikidata.org/wiki/Special:RecentChanges?hidebots=1&hidecategorization=1&namespace=146&limit=500&days=7&urlversion=2

The lines that were changed have been created about a year ago. Do we have an idea what changed to cause them to break now?

This comment seems to be related: https://phabricator.wikimedia.org/T192166#4475526

This still requires some cleanup regarding eslint warnings.

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/525037 is merged now, so lowering priority as this should no longer block anyone anymore. Feel free to raise this again if it is still an issue.

Still flaky in gate and submit: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/525037

Other than resolving the root cause, logging the frequency of this error to Grafana to monitor it and preventing it from going to Logstash could be a sensible way forward, too.

Created a patch which should revert the commit that added the browser tests to CI: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/525037