Paging should be added to the page, like Special:GlobalUsage

• Don't show the list mode after successful actions; instead show a success message with a link to the list. When I mark a page for translation, usually, I just want to know whether it succeeded not about other translatable pages.

Done in a0e6713b47fd.

This should probably be done together with finishing of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Translate/+/717507/

A very basic sketch for design could be:

• Implement paging like on other page list special pages
• Implement status filtering with checkboxes/toggle buttons for the headings
• By default do not show pages where no action is needed. Only needs-update, proposed, broken.

Likely will need a search input for exact match or prefix filtering (with autocomplete) to make it easy to modify settings of a certain page.

MediaWiki.org has so many pages now that some of the queries it does are flagged as a performance issue. One related to the translate_metadata table has been fixed, but others remain:

Expectation (readQueryRows <=) 10000 by MediaWiki::main not met (actual: 12162):
query-m: SELECT page_id,page_namespace,page_title,page_latest,MAX(rt_revision) AS rt_revision,rt_type FROM `page`,`revtag` WHERE (page_id=rt_page) AND rt_type IN ('X') GROUP BY page_id, page_namespace, page_title, page_latest, rt_type ORDER BY page_namespace, page [TRX#625701]

Implementing a paging could help with this.

In T141961#7397732, @Nikerabbit wrote:

This should probably be done together with finishing of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Translate/+/717507/

A very basic sketch for design could be:

• Implement paging like on other page list special pages
• Implement status filtering with checkboxes/toggle buttons for the headings
• By default do not show pages where no action is needed. Only needs-update, proposed, broken.

Likely will need a search input for exact match or prefix filtering (with autocomplete) to make it easy to modify settings of a certain page.

@Pginer-WMF - Bringing this to your attention.

You can view the current page at: https://www.mediawiki.org/wiki/Special:PageTranslation

Primary objectives for redesign:

1. Performance: We're currently display all the translatable pages at once which has an impact on performance.
2. Usability: The currently long list is quite unusable. It would be good to have something that is easy to browse through.

I think in this context it may be useful to differentiate those pages that are in a special status (and may require some action) from the rest. Since these seem to work as separate categories with different actions, I think we can support the idea by using separate tabs:

• Proposed. Pages not marked yet. Users can mark for translation those pages ready for the community to translate them.
• Discouraged. Pages where translation is discouraged. Users can reconsider and enable the translations for them.
• With updates. Pages with updates that have not been marked for translation. Users can mark for translation the pages when the updates are completed enough for translation.
• All. Lists all pages. Users can find a specific page (or set of pages) to act on them (e.g., discourage their translation).

In addition, an option to filter with a query and pagination, can be useful to deal with long lists. Especially in the "all" tab.

In this way, the status and possible transitions are more clear, users interested in a particular activity have a clear backlog to review, and those interested in a particular project can focus on it.

Please, let me know if the general idea described above makes sense to you. I'll explore options and create some mockups based on it to check how that may look.

There are two more to-do categories:

• Broken pages. Pages which have been marked for translation, but not in their most recent version, and their most recent version cannot be marked for translation (e.g. all <translate> tags have been removed).
• Backlogs caused by software changes instead of on-wiki edits. This currently includes pages using syntax version 1 (T254484), pages not using translation-aware transclusion (T47096, although having pages not using it is expected, zero pages should not be a goal), and pages using the old translation variable syntax (T274881).

Since for the three backlogs that have separate sections on Special:PageTranslation right now (proposed + with updates + broken) the goal should be zero pages, and usually have relatively few pages indeed (probably the best rate has mediawiki.org, which has as few as 19 out of more than 6000 translatable pages, or 0.3%, and even the worst Meta has only 323 out of over 8000 pages, or 3.9%), I think it makes sense to combine them on one tab. So I think the tabs should be:

• On-wiki backlog (proposed + with updates + broken), in three sections like now
• Discouraged, may also be sectioned (with updates, broken, up-to-date)
• Software change backlog (currently: syntax version 1 + no translation-aware transclusion + old tvars), not sectioned, as the categories are not distinct (actually usually syntax version 1 implies no translation-aware transclusion and no translation-aware transclusion implies old tvars due to the timing of these changes)
• Everything, in four sections like now

Thanks for the input @Tacsipacsi. I iterated a bit with the naming and groupings.

I created a basic prototype that may help to try how the information provided in each tab is organized.

For this iteration, I considered:

• To review. Includes sections for "Proposed" and "With updates". I considered a more action-focused tab to communicate these need action, and tried to include those where the focus is on reviewing the content (as oppose to the code).
• Discouraged. Kept as a separate list since it captures a clear status and intent.
• Code issues. Includes sections for "Blocked" and "Outdated code". I considered to group states that involve the review of the code and translation-specific markup. Also, "Blocked" seems a bit more specific than "Broken" to suggest what is the issue.
• All. It was a it unclear whether the division in sections is useful given the different tabs.

In addition, I explored options to filter based on a search query (e.g., to locate a particular page or focus on a set of sub-pages) and namespace selector (e.g., to focus on content, documentation, etc.) could be useful in this context.

To review	Discouraged

Code issues	All

Since this page supports different workflows with different states, we may still need to get further feedback and iterate. So feel free to comment on any of the proposed ideas.

Broken/blocked is usually more of an editorial issue (similarly to proposed and outdated pages) than a technical one (like deprecated syntax): either someone tried to update the page and accidentally broke the syntax (which would actually count as an outdated page, just a bit more cleanup is needed before marking it than usually), or someone tried to remove the page from the translation system but didn’t have the right to do it properly, in which case probably communication is needed with that person to make sure they understand the implications of removing the page from the system. Updating deprecated syntax, in contrast, usually requires little or no manual changes, one just needs to change the source code if necessary (in case of the new syntax version and the translation-aware transclusion, it’s often not even necessary, and the tvar syntax can be updated with a one-liner script), check if everything’s okay and press the button. These are not caused by other users and don’t require communication with anyone. Thus I still think that broken pages should be in the To review category.

The namespace filter is a great idea. I’m not sure if the search field will be useful (it won’t hurt, though, for sure), but being able to filter for namespaces makes much sense, as quite different attitude is needed to work with templates (translation-aware transclusion is important, extra markup is needed e.g. to mark up English templates in translated pages or to handle parameters), user (sub)pages (communication with the user is often necessary) and other pages.

What I really don’t like is the spacing. I’ve already set the current two-lines-per-page layout to one-line-per-page to make it easier to have an overview of the pages, but these changes add even more whitespace, and the removal of the numbered list makes it less obvious where one item ends and the next one starts. Even if only 500 pages will be visible at once instead of 8000, that’s still a lot. The numbered list also makes it easier to find the section boundaries when scrolling: the numbering restarts in each section. When there are 300 pending and 50 outdated pages, this, combined with the more whitespace and the removal of the borders of the section titles compared to the currently used <h2>s makes it much more difficult to find the beginning of the outdated pages section’s start.

On the All tab, there are chips that indicate if there’s any special concern about the page, but it says Code issues, and there are no chips in the Code issues section. Since they are quite different (old syntax version causes issues for readers, the lack of translation-aware transclusion and the old tvar syntax cause issues for editors; the lack of translation-aware transclusion is often expected, while the old syntax and old tvar syntax should eventually be 100% cleaned up), as a translation administrator I want to know what issues a page has so that I can decide whether I’m willing/able to fix them (if necessary at all). Please change the Code issues chip to the appropriate issue(s) and show all chips in all sections, except that in sections containing only one particular issue (proposed, outdated, discouraged, broken), that issue’s chips should not be shown (but eventual other chips should). So if a discouraged page is outdated, uses syntax version 1 and doesn’t support translation-aware transclusion, it should appear

• In the To review tab’s With updates section as Foo (discouraged) (old syntax) (no transclusion support)
• On the Discouraged tab as Foo (with updates) (old syntax) (no transclusion support)
• In the Code issues tab’s Outdated code section and as Foo (with updates) (discouraged) (old syntax) (no transclusion support)
• On the All tab as Foo (with updates) (discouraged) (old syntax) (no transclusion support)

I second Tacsipacsi thoughts regarding additional white-space, numbering for the lists and displaying badges in all sections.

Thanks for the input @Tacsipacsi and @abi_.
The main focus of the exploration was around the classification and navigation structures. The list was more of a sketch, and we can consider to keep the current format for that part to avoid too many changes in one go. In any case, the importance and numbering and spacing is quite relevant for when we consider to work on that part.

Regarding the Broken/blocked category seems to be the one that is harder to fit perfectly in the proposed organization. I can see that "Blocked" require different interventions than those with outdated code. However, those still represent more of a warning/error situation that requires more expertise to fix compared to the "to review" which is more about deciding if the content is at the right moment to be send to translators.

Regarding, more specific and visible "chips", makes perfect sense. If multiple are possible, we need to consider how those would look like. But that will be relevant if/when we consider the review of the list items themselves.