This was requested in this comment. When participating in campaigns, the chances of users trying to translate the same article increase, which makes blocking topics for translation to be a bigger problem.

Change 523809 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ContentTranslation@master] Send notification to users that they should continue their translations

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

@Pginer-WMF old drafts are purged after one year. The cron job executes the script twice a month. If we remind users for drafts old three months (and up to one year), this would mean that there will be multiple notifications about same translation (with current setup, user would get those in 15 days periods). Should we prevent this noise by giving users the ability to opt out or is it fine?

In T89707#5348698, @Petar.petkovic wrote:

@Pginer-WMF old drafts are purged after one year. The cron job executes the script twice a month. If we remind users for drafts old three months (and up to one year), this would mean that there will be multiple notifications about same translation (with current setup, user would get those in 15 days periods). Should we prevent this noise by giving users the ability to opt out or is it fine?

The idea is to notify users only once. In a period of time that is approximately 3 months after the translation started. We can be flexible about the time period, but the notification should happen only once. If the script is ran every 15 days, I'd expect it to select the translations started in the range [3 months ago, 3months ago + 15days].

For example, the script running at the beginning of April would target translations from the beginning of January to mid-january. The next run, at mid-April targets translations from mid-January to the end of January (making sure it does not overlap with the previous period). Note that I'm using months in the example as if they had 30 days for illustration purposes.

In T89707#5348704, @Pginer-WMF wrote:

I'd expect it to select the translations started in the range [3 months ago, 3months ago + 15days].

@Pginer-WMF what about first run? Should we notify users about all drafts older than three months and than target 15 day windows or should we start with 15 days window for the first run as well?

In T89707#5480010, @Petar.petkovic wrote:

In T89707#5348704, @Pginer-WMF wrote:

I'd expect it to select the translations started in the range [3 months ago, 3months ago + 15days].

@Pginer-WMF what about first run? Should we notify users about all drafts older than three months and than target 15 day windows or should we start with 15 days window for the first run as well?

Good question, @Petar.petkovic.
I'd propose not doing anything special for the first round. Older drafts than the first window won't be notified, and I think it is ok (other earlier drafts have been deleted without notice anyways). In addition, we avoid bringing too much attention to some CX1 drafts and content heavily outdated.

We need to notify users about old drafts in 15 day windows. In order to avoid notifying same user twice or missing some draft, we decided to save timestamp of last notified draft in that run. That avoids saving and updating info per draft as well.
For purpose of saving this timestamp of last notified draft, new database table is introduced. Since this involves schema changes, by following guidelines, I've added Schema-change tag. Separate task will be created after patch is merged.
Patch which introduces this table can be merged before table is created, as new table usage is behind configuration.

Hi,

For what I see in the patch, the implementation is at the moment planned as an extra table. If that is right, and such a small table is the only sql change, we just need a heads up before production deployment for it to be added to the list of private tables on the operations/puppet repository (but it not technically considered a schema change). After that, we encourage developers to add the table themselves so they are not blocked on us, as it is not a dangerous process.

If it involves changes to existing tables, we need to get the ALTER command so we can apply it to production, as it would be a more dangerous process and need special care.

Will this table be public? Can it be replicated without any restrictions to our wiki replicas? (https://wikitech.wikimedia.org/wiki/Portal:Data_Services#Wiki_Replicas)
If this table is expected or is supposed to be accessed by our Wiki Replicas users, a view will be needed and for that a ticket to cloud-services-team will be required.

In T89707#5524842, @Marostegui wrote:

Will this table be public? Can it be replicated without any restrictions to our wiki replicas? (https://wikitech.wikimedia.org/wiki/Portal:Data_Services#Wiki_Replicas)
If this table is expected or is supposed to be accessed by our Wiki Replicas users, a view will be needed and for that a ticket to cloud-services-team will be required.

This team normally works on x1 section, which we don't replicate for privacy concerns. We do, however, add them to private table list in case we do in the future (by accident of by choice).

Change 523809 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Send notification to users that they should continue their translations

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

@Petar.petkovic can you tell me how to test this on local?

In T89707#5597426, @Jpita wrote:

@Petar.petkovic can you tell me how to test this on local?

You need to run a script located at core/extensions/ContentTranslation/scripts.
When you are in that directory, run php purge-unpublished-drafts.php. You also need to pass some command line option to your script:

• age-in-days - This option was existing before changes made to the script for the purposes of this task. It determines how old are the drafts which are being removed from DB.
• notify-age-in-days - This option was introduced for this task. It determines how old are drafts that you notify users to "continue their translations before they get deleted"
• really - Unless this option is included, you get log of drafts which users are notified about or which get purged and actions are not performed really. Without this option is what we call "dry run".

You can use something like php purge-unpublished-drafts.php --notify-age-in-days=1 --really to notify users to continue their drafts which are one day old. I'm using one day since you probably don't have older drafts available locally. You can also use other parameters and tweak you calendar date on your OS to test this.