I'm wondering if it would look at least a little bit better, if the line was moved to below the selection (i.e. just before the Add namespaces input field), logically I guess it makes more sense to first see what you select, and then decide that you want to have that selection as a default.
@Jan_Dittrich what do you think?

The alias handling of this story is just the first level. Planned final behavior is T218690: Show each alias in a separate line in edit mode, which I think should remove the problem

NB: If this story is unexpectedly more complicated, let's discuss before everything is implemented

I'm not sure how I can test the CRS part of it. I did see the beautiful babel box magic in a ticket I was testing earlier this week, but I understand it right that this ticket is specifically about having it rendered in CSR, not SSR? If yet, how can I produce such a situation?

@Matthias_Geisler_WMDE thanks for the pointer! I now see a beautifully aligned icon, the order of icons is now changed though, which creates an inconsistency with e.g. Wikipedia mobile:

The header looks indeed beautiful, but I'm struggling a bit to accept this story, because I don't see any icon except the ones we expect. Do I maybe need to follow a different link to see the download icon, too?

@Lea_WMDE In addition to the icons immediately visible we also use messages to explain what buttons do (e.g. screenreaders). As of T161367 there are two "competing" messages for the action of persisting, "save" & "publish". Which one is chosen is configurable per installation. Does this configurability have to be reflected in termbox or can we favor one over the other (i.e. always use "publish" implying that termbox will only every be used on Wikimedia projects)?

Just publish sounds best to me, even when it is not configurable I would assume other project could live with the "publish" wording as well :)

The fact that adding this only has a real impact on desktop (where there is an ESC key) maybe makes it even more obvious that it should be a dedicated feature story (that could be added later in the game), I just wanted to scribble down the observation.

Making it an extra story sounds great to me :)

If possible also come to a conclusion whether a "floating bar" would be possible as well.

Users with specialized data are not cached. If we need to reduce the number of requests, not ever sending SSR requests in those cases (i.e. showing nothing), but forcing users to wait for the client side action to kick in would be an option.
If we don't have this, and run into problems with the number of requests, the only way to reduce the number of requests would be disabling the new termbox functionality completely, falling back to the current state.

This should be rewritten to log all failed requests in the central logging instance and not just the there mentioned requests. The ticket is about making it more convenient to not dig through existing logging, and it would also be able to log requests that never made it back out to mediawiki.

It would probably make sense to have the same time out for both directions.

At this stage we would be introducing logging that is not being read by anyone. This ticket is only about adding a line of meta data to the requests we send.

Estimation happened under the assumption that no other ticket in that regard was done

The estimation is based on having separate caches per instance (if there even is more than one instance)

@IKhitron The diffing library we have to change (Wikidiff2) has to be deployed manually, and does not follow the train. If you watch T203069 you will see when the changes are live :)