I'd like to hear from Language-Team before deploying this change, as it can have some implications (probably related to the purging systemd job). See below for current job declaration details:

[urbanecm@mwmaint1002 /lib/systemd/system]$ cat mediawiki_job_purge_old_cx_drafts.service
[Unit]
Description=MediaWiki periodic job purge_old_cx_drafts

[Service]
User=www-data
SyslogIdentifier=mediawiki_job_purge_old_cx_drafts
ExecStart=/usr/local/bin/mw-cli-wrapper /usr/local/bin/foreachwikiindblist "/srv/mediawiki/dblists/wikipedia.dblist - /srv/mediawiki/dblists/special.dblist - /srv/mediawiki/dblists/closed.dblist - /srv/mediawiki/dblists/testwikis.dblist - /srv/mediawiki/dblists/private.dblist" extensions/ContentTranslation/scripts/purge-unpublished-drafts.php --age-in-days=455 --notify-age-in-days=425 --really
[urbanecm@mwmaint1002 /lib/systemd/system]$ cat mediawiki_job_purge_old_cx_drafts.timer
[Unit]
Description=Periodic execution of mediawiki_job_purge_old_cx_drafts.service

[Timer]
Unit=mediawiki_job_purge_old_cx_drafts.service
# Accuracy sets the maximum time interval around the execution time we want to allow
AccuracySec=15sec
OnCalendar=*-3,18 10:30
RandomizedDelaySec=0

[Install]
WantedBy=multi-user.target
[urbanecm@mwmaint1002 /lib/systemd/system]$

On first (uneducated) look, it looks the actual expiry is hardcoded in the job. If that's right, it might be tricky to customize the expiry per-wiki, as requested.

On a second look, it looks wgDraftMaxAge is used by purge-unpublished-drafts.php as a fallback if age-in-days option is not passed. Since we pass the option to the script, it has no effect at WMF sites at all. The obvious solution would be to remove the opion, but then notify-age-in-days would do nonsense stuff for fawiki (or at best log errors/warnings).

Blocking this on Language-Team, as they're the experts at the codebase in q.

I think it makes sense to adjust the tool to the particular needs of each community. Having specific configurations also makes the system less predictable, so before going that path I'd like to check which is the motivation behind this proposal. Is the intention to avoid translations that get published with outdated information because they have been in the making for too long, or is it a way to solve for content being blocked for other s to translate? If it is the later, it may be better to really solve this issue directly (T86151) rather than rely on the deletion f inactive drafts.

@Pginer-WMF the motivation is the latter. I agree that T86151 is the optimal solution, but it has been open since 2015 and its implementation will require a major code overhaul. So, the effort is high and evidently not prioritized. That is why our community is in favor of the minimal effort alternative requested here.

The "system less predictable" risk is a valid argument, but I am not sure how big the risk is. Note that the experience will be predictable for users of each single wiki; it is only cross-wiki experience that become less predictable. I doubt there are many who translate content both to Persian and to anther language. Much less, if there are people who translate multi-lingually at such slow pace that shortening the grace period would result in unanticipated loss of work for them. And bear in mind that when wfDraftMaxAge is approaching, the content does not magically disappear; ContentTranslation will first give the user a heads-up. So all in all, I think it may be a small issue and a price we decide to pay given that we have not been able to address T86151 in over six years.

In T285547#7344554, @Huji wrote:

@Pginer-WMF the motivation is the latter. I agree that T86151 is the optimal solution, but it has been open since 2015 and its implementation will require a major code overhaul. So, the effort is high and evidently not prioritized. That is why our community is in favor of the minimal effort alternative requested here.

Thanks for the context. This is useful. I'll check with the team if the upcoming changes needed for Section Translation makes it easy to make progress on this realistically.

Also, it is not ideal, but in case it helps a bit, there is a workaround for these situations: it is possible to copy the source code of a page into a sub-page under your user name and translate that one instead of the blocked original.

The "system less predictable" risk is a valid argument, but I am not sure how big the risk is. [...] And bear in mind that when wfDraftMaxAge is approaching, the content does not magically disappear; ContentTranslation will first give the user a heads-up. So all in all, I think it may be a small issue and a price we decide to pay given that we have not been able to address T86151 in over six years.

What I was referring to is that when developing the tool, we may work on the assumption that the drafts live for a certain period and having exceptions can mean those may experience some issues. For example, this change may propagate also to the notifications. Currently we sent:

• A notification after 3 months to encourage users to edit the 3-month old draft (T89707). With the proposed change to delete drafts in 3 months, we may need to adjust this too to avoid encouraging to continue a translation we just deleted.
• A notification confirming the deletion (T184268) that uses the message "Your translation for <page-name> was discarded because its content was outdated by more than a year. Start a new translation with fresh content anytime." The message does not match with the new time proposed (3 months). So we may need to either have a custom message or make the general message more generic to fit al cases.

These changes are doable, but I wanted to illustrate that this customization comes at a price for every feature in this area (existing or future). So it need to be evaluated with care.

Thanks for this perspective, @Pginer-WMF. Given the above, I agree the work involved might be a bit larger than changing a config var. It seems like the "3 month" config var was taken for granted by other parts of code and there are technical debts that may need to be addressed if one wants to change the config var (e.g. the notification period may need to be calculated based on the config var, etc.)