Page MenuHomePhabricator

Avoid showing "Translation search server unavailable: Result window is too large"
Closed, ResolvedPublic

Description

Go to https://translatewiki.net/w/i.php?title=Special:SearchTranslations&filter=untranslated&language=en&query=entities+used+in+this+page

You will get an error:

Translation search server unavailable:Result window is too large, from + size must be less than or equal to: [10000] but was [11000]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level parameter.

In CrossLanguageTranslationSearchQuery one could add a check if offset > 10000 then stop (or even better: catch the exception so that we do not hardcode the limit), show what has been found, and then show an error message. Some code needs to be changed to indicate the result is incomplete.

It could also be migrated to use https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-scroll.html but that could be a bit more complicated.

If you work on this task you must have MediaWiki running with a working Translate extension with ElasticSearch setup. For testing the index.max_result_window should be set to a low value.

Details

Related Gerrit Patches:
mediawiki/extensions/Translate : masterBetter handle errors in Special:SearchTranslations

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 28 2017, 12:43 PM

In CrossLanguageTranslationSearchQuery one could add a check if offset > 10000 then stop (or even better: catch the exception so that we do not hardcode the limit), show what has been found, and then show an error message. Some code needs to be changed to indicate the result is incomplete.

It could also be migrated to use https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-scroll.html but that could be a bit more complicated.

This needs a working Translate with ElasticSearch setup. For testing the index.max_result_window should be set to a low value.

Aklapper renamed this task from Translation search server unavailable: Result window is too large to Avoid showing "Translation search server unavailable: Result window is too large".Nov 27 2017, 9:03 PM
Aklapper updated the task description. (Show Details)
Nikerabbit raised the priority of this task from Normal to High.Sep 18 2018, 6:07 AM

I am increasing this to high priority, because this is the most frequent item in translatewiki.net logs.

Change 469637 had a related patch set uploaded (by Nikerabbit; owner: Nikerabbit):
[mediawiki/extensions/Translate@master] Better handle errors in Special:SearchTranslations

https://gerrit.wikimedia.org/r/469637

This patch has been cherry-picked to translatewiki.net a few days ago.

Change 469637 merged by jenkins-bot:
[mediawiki/extensions/Translate@master] Better handle errors in Special:SearchTranslations

https://gerrit.wikimedia.org/r/469637

Etonkovidova closed this task as Resolved.Feb 7 2019, 9:46 PM
Etonkovidova added a subscriber: Etonkovidova.

I marking the ticket as 'Resolved', but I'd like some feedback from @Nikerabbit on the following. My questions below may refer to just desired behavior.

(1) The error message "tux-sst-error-language": "This language cannot be used with this type of search." is in place:

However, the message is displayed even though no language was selected, e.g.
https://translatewiki.net/w/i.php?title=Special:SearchTranslations&filter=untranslated&query=wiki+test+. On the screenshot above there is no language selected on the side, so the reference in the message to "This language..." might be confusing.

(2) I could not hit the message :"tux-sst-error-offset": "No more search results can be shown. Please narrow your search." even when the number of search results is really high:


On the other hand, I did not notice any degradation in performance for such deep paging, so most likely it's ok to have that many results.

However, the message is displayed even though no language was selected

If not specified it defaults to the interface language. This could be improved further.