Page MenuHomePhabricator

Let order in Special:Translate to be random
Open, LowestPublicFeature

Description

I sometimes check and translate a bunch of messages in Special:Translate of translatewiki (like this). I skip messages that I don't understand, hard to translate, not important (IMO ofc) and when I want to do it again. They all are piled up in top. It makes it even worse when I want to give this list to people to translate, they (usually non-technical people) are struggle to translate it (because I did it too and skipped those). I understand it's sometimes needed (for example in case of translating tech news) but can this be done for mediawiki messages?

Event Timeline

I don't have any idea how to do deterministic random sorts (for paging) efficiently.

I don't have any idea how to do deterministic random sorts (for paging) efficiently.

random by definition is not deterministic. I know it's not efficient but it should not be a big deal if the result is not big. So one idea is to put a cap in returned results and disable order by random if number of returned messages for translation is bigger than X.

I suppose you could do random up to the limit (500?) and if more is required, ask to refresh. Then it doesn't need to be deterministic (I mean, with a given seed, you always get the results in the same order, as long as the underlying data hasn't changed). But it would complicate the code quite a bit, and I don't know if the database can do that efficiently.

Nikerabbit moved this task from Backlog to tux on the MediaWiki-extensions-Translate board.

I sometimes refresh the page for various reasons within a translation session (to get rid of already-translated messages, because I need to restart browser etc.), and I want to continue where I left off, so this feature would be very annoying for me. For page translation, it totally doesn’t make sense IMO, as we’re translating one continuous text; for Translatewiki, I see Ladsgroup’s point, but still don’t want to see it in my workflow. I think the best solution would be to make it a (preferably opt-in) preference, which can be set in the preferences, but can be overridden with a URL parameter as well (so that a URL can be sent to people with an appropriate toggle state).

Nikerabbit changed the subtype of this task from "Task" to "Feature Request".Dec 7 2020, 3:11 PM