Infrastructure

exact timestamps would help to diagnose easier, need some time to debug...

I so far miseed the important bit of this thing, namely that it is a suggestion that needs to be accepted and edited by the function in the hover-menu..

Indeed I can reproduce the slowness using that method - there seems to be a DB deadlock situation in this case.

"Fixed tracking suggestions in history." in one of the 4.13 changelog

So need to recheck after update to 4.14

next weblate update will require a little larger downtime since metric data needs to be converted to a different format.

The problem with editing suggestions is not something that can be solved by a workaround and is caused by our large repositories - from weblate's POV both taking the suggestion in the edit box and then modifying it are two changes that are synced to the git repository only after the edit is submitted, so when user hits save button it first needs to create a commit for the original suggestions (i.e. wait for git lock and all that and wait for git commit completion), and then do another one for the edit. Since we're using weblate's git squash addon to combine multiple commits into a single one those individual commits don't show up in the repo, so one optimization weblate devs will implement is to trigger the save for the suggestion immediately when using the "use and edit" on the suggestion, so when the user then is done with modifying the first save should be completed and should be "hidden from the user"/speed should be the same as regular translation as weblate doesn't need to wait.

Plan to do the update after 7.6.0 beta1 is tagged

proper target version