Page MenuHomePhabricator

List of translations by status
Open, LowPublicFeature

Description

As a translation coordinator, I want to see in a single page all the content that needs to published somewhere and is ready for publishing, so that I can publish it.

This means showing all message groups in all languages, filtered by status (ready).
The system would replace categories such as https://meta.wikimedia.org/wiki/Category:Translations_by_status (old standard translation request) and https://meta.wikimedia.org/wiki/Category:Translation/Fundraising_2011/Jimmy_Letter_002 (https://meta.wikimedia.org/wiki/Fundraising_2011/Translation/Project_report#Language-focused_request_template ).

See also https://meta.wikimedia.org/wiki/Help:CentralNotice/Translations for one current usage of workflow states on Meta-Wiki.

Related to bug T36299: Automatic workflows (a fully automated workflow would include the publishing part).

Details

Reference
bz34300

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:17 AM
bzimport set Reference to bz34300.
bzimport added a subscriber: Unknown Object (MLST).

Thehelpfulonewiki wrote:

+1, this would be useful.

(In reply to comment #0)

Related to bug 34299 (a fully automated workflow would include the publishing
part).

Calling it a blocker to link the two bugs.

@Nemo_bis what processes still rely on looking for published status on Special:Language|MessageGroupStats?

@Nemo_bis what processes still rely on looking for published status on Special:Language|MessageGroupStats?

All the processes which involve republishing of the translations (which are the same as in 2012, plus some more). Do you need a list and why?

I don't have good understanding of the processes so I am not able to properly assess priority of the issue and suitability of the solution.

Hence you must trust the reporter, who knows the solution is suitable and checked with the persons who administer these processes. :)

That's not how it works. If I am to volunteer my time, I need understand the issue to know whether I want to work on this or something else. If I am to do it on paid time, I need to understand the issue to make a case for it. If someone else is going to submit a patch, I cannot review it if I don't know what it is for.

The use case in the description is very clear and I have no idea how it can be made clearer.

By giving a few real examples of what is done now.

The description already links such examples.

I only see some old stuff in there. Is there no recent concrete example what some person does?

I only see some old stuff in there. Is there no recent concrete example what some person does?

What makes you think that the process changed since 2011? What sort of example would be recent or concrete enough in your opinion?

Examples can be picked at https://meta.wikimedia.org/wiki/Translation_requests

I read the page you linked but it says nothing of publishing. Who publishes? What they publish? Where and how they publish? How they currently learn that there is something to publish?

Also, as far as I know banners are now handled automatically so that shouldn't be a problem.

Who publishes? What they publish? Where and how they publish? How they currently learn that there is something to publish?

Nobody, nothing, almost never and randomly. That's the point of this bug.

as far as I know banners are now handled automatically

They aren't, see relevant docs: https://meta.wikimedia.org/wiki/Help:CentralNotice/Translations#Abstract

Who publishes? What they publish? Where and how they publish? How they currently learn that there is something to publish?

Nobody, nothing, almost never and randomly. That's the point of this bug.

You are still avoiding to answer my question. Nothing will move here until there is clarity on the target audience and their needs.

as far as I know banners are now handled automatically

They aren't, see relevant docs: https://meta.wikimedia.org/wiki/Help:CentralNotice/Translations#Abstract

Which says "As soon a message has been set to the 'Published' state, CentralNotice will import that translation and it will go live in any banner using it". That is automatic to me, i.e. there is no separate publishing step besides setting the state. Now, with some guessing, it seems that having a way to change status directly from the listing page would make sense.

The target audience are translation coordinators, as explained in the first line of the task.

there is no separate publishing step besides setting the state

But one still has to find the things which need that step. Currently one has to open Special:MessageGroupStats separately hundreds of times in order to see all the relevant workflow states.

having a way to change status directly from the listing page would make sense

Maybe, but that's a separate bug; this bug is about the lack of a listing:

showing all message groups in all languages, filtered by status (ready).

The target audience are translation coordinators, as explained in the first line of the task.

I feel like I am repeating myself over and over, but I want to understand the big picture, and you probably have a real use case in mind but you are withholding information about it.

there is no separate publishing step besides setting the state

But one still has to find the things which need that step. Currently one has to open Special:MessageGroupStats separately hundreds of times in order to see all the relevant workflow states.

having a way to change status directly from the listing page would make sense

Maybe, but that's a separate bug; this bug is about the lack of a listing:

showing all message groups in all languages, filtered by status (ready).

So if we narrow the use case is to something concrete: publish CN banners which are ready, but not yet published, the use case has multiple requirements

  • finding such message groups
  • facilitating the review (or doing something entirely different, if review is not necessary and can be automated)
  • facilitating changing the status of one ore more (usually more?) to published status

While it can be built piecemeal, the whole thing should be understood first, that we will spend time on the right things.

you probably have a real use case in mind but you are withholding information about it

I prefer to keep the use case general to avoid getting into Wikimedia-specific workflows and fights. It's extremely common for translation tools out there to produce translations which then have to be copied/moved elsewhere. Wikis are the exception, not the rule; it would be nice to make Translate useful also for those who don't see the wiki pages themselves as their final target («all the content that needs to published somewhere»).

Specific use cases are already linked in the task description. Have you clicked them? For instance https://meta.wikimedia.org/wiki/Category:Translations_in_need_of_publishing has examples such as https://meta.wikimedia.org/wiki/Licensing_tutorial/gl , is anything unclear?

Some other information has been recently removed from [[m:Translation requests]], so I've now added an informational section. Does this help you remember?

the use case has multiple requirements

Requirements 2 and 3 which you listed already exist and are satisfied. Only 1 is missing.

Of course it is possible already via lots of clicks, but likely with small effort it could be much more efficient overall.

Of course it is possible already via lots of clicks, but likely with small effort it could be much more efficient overall.

I'd focus on features for which there is demand. There isn't currently a demand for a speedup of 2 and 3 (especially since some feel the review should be more accurate rather than less).

I would bet there would be demand for features 2 and 3 if lack of 1 wasn't a blocker.

I would suggest starting a backend API/WebAPI class. Frontend can be done as a new special page or gadget or whatever makes sense.

The query is very simple, though not efficient:

[dev_translatewiki_net]> explain select * from bw_translate_groupreviews where tgr_state = 'proofread';

idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra
1SIMPLEbw_translate_groupreviewsALLNULLNULLNULLNULL950Using where

[metawiki]> explain select * from translate_groupreviews where tgr_state = 'ready';

idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra
1SIMPLEtranslate_groupreviewsALLNULLNULLNULLNULL83002Using where

With this few rows, even with lack of index for tgr_state the queries are quite fast. But we should consider adding on it.

You would need to figure out how to present this results, and likely provide some kind of paging (there are over 5000 rows for state=ready for example).

Nemo_bis is quite right. cy-wiki has lost editors as English only banners are published. I translate the banner, but nothing happens; I'm not allowed to publish! A non-Welsh speaker Meta Admin comes along and clicks publish without understanding a word of it! Take a look at my request: https://cy.wikipedia.org/wiki/Wicipedia:Y_Caffi#Baneri_Wikipedia and on Meta here: https://meta.wikimedia.org/wiki/Wikimedia_Forum#Banner_translations_still_do_not_appear Thanks!

As long as final CentralNotice translations rely on the MediaWiki namespace, while I certanly understand the concerns that a non-native user has to publish them, I don't think there'll be any solution but to trust editors and use common sense as we've been doing until now. Maybe we should create a CentralNotice best practices guide and add that the responsible for a campaign should be checking via LanguageStats if there's any new translation for the campaign he's managing and act on them proptly. I cannot think on any better idea for now. Thanks.

Nikerabbit changed the subtype of this task from "Task" to "Feature Request".Sep 26 2022, 11:53 AM