This uses some code called "Fuzzy Like This" which was removed from elasticsearch in 2015 due to performance issues (https://github.com/elastic/elasticsearch/pull/10391). To avoid the translate team needing to re-work this we took the old code and put it in our plugin, so the query still "works" but is painfully slow.

Plausibly to make this faster the query would have to be reworked to not use fuzzy-like-this.

We'll look into this for a day and try to come up with possible solutions.

Sorry if this interrupts any work, but I've realised that the Elasticsearch/TTMServer part of this task might be a potential duplicate of T101236: TTMServer performance and coverage issues.
The idea in this task's description to potentially split the message-doc-fetching into its own API request seems like it could be achieved separately, but I assume that wouldn't fall within the Search Platform team's scope… (and I'm guessing also might not be necessary if any solutions can be found to this on the Elasticsearch/Search Platform side of things).
Sorry about this!

In T399569#11058363, @A_smart_kitten wrote:

Sorry if this interrupts any work, but I've realised that the Elasticsearch/TTMServer part of this task might be a potential duplicate of T101236: TTMServer performance and coverage issues.
The idea in this task's description to potentially split the message-doc-fetching into its own API request seems like it could be achieved separately, but I assume that wouldn't fall within the Search Platform team's scope… (and I'm guessing also might not be necessary if any solutions can be found to this on the Elasticsearch/Search Platform side of things).
Sorry about this!

No worries! Yes, performance issues in TTM is a known issue, if you believe that things got really worse recently we could possibly investigate if there are easy remediations otherwise we can mark this as a duplicate of T101236 indeed.

To be completely honest, this was probably the first time I've ever properly taken note of how long the translation docs/ttmserver responses take to load, so I'm afraid I can't really say whether things have got better/worse recently or not - apologies!

Re whether or not to mark this task as a duplicate -- I filed this task mainly from the POV of the translation documentation specifically taking so long to load, and - after looking into it - it seems like the final bullet-point of the task description might actually already be possible to do:

from the task description

• As an idea, if improving the ttmserver performance is tricky to do, maybe the message-documentation-fetching (and/or everything apart from querying ttmserver) could be split into its own API request, so that it's not affected (or hopefully affected less) by the slow speeds of querying ttmserver?

By appending &prop=documentation to the API call (e.g., https://www.mediawiki.org/w/api.php?action=translationaids&format=json&title=Translations:Extension:EmailAuth/16/nl&uselang=en&prop=documentation), it seems like this might already be possible(!)
So I guess, if splitting the one action=translationaids API call into two could be a way of resolving this specific task on the 'message-documentation-being-slow-to-load' side of things, maybe this task is distinct from T101236 after all (and maybe we should untag Elasticsearch)? /genq

@A_smart_kitten thanks for the suggestion, this optimization would indeed be unrelated to Elasticsearch and thus going to untag it, I believe MediaWiki-extensions-Translate is the right tag for this request.

Regardless of translation memory performance, I wonder if certain parts of the translator documentation can be displayed as soon as they are available instead of waiting for all translation helper content. I assume the challenges of this are repaints?

Front-end complexity and shifting content. Also, if you separate just ttmserver, you lose some of the benefit of the parallel-curl requests for MT/TM (though if I remember correctly, on WMF TM request is not even happening in parallel).