Sorry I didn't see this message until after I had frozen the issue for translation. (I missed checking a column in the workboard). Instead of altering the now-frozen-for-translations issue of TechNews itself, I have added a note into this task's description. Hope that works!
Fri, Jul 31
I think the Con of "Can't in future filter things out of watchlist/recent changes for alterations to languages the user doesn't care about" might potentially be a major concern for options A and B. This is an important feature to have for content-maintainers, in order to control the signal-to-noise ratio in our change-patrol systems, if we're expecting fairly high-velocity RC feeds. -- Is there any upcoming work around T246749: Ability to filter by label language in Wikidata RC in other projects that might help resolve this?
Thu, Jul 30
@matej_suchanek Thank you for writing the explanation! Is there a link that we could add to this, to give more details?
If I understand correctly, this is not yet ready for announcement. For once it is ready, please could you provide an explanatory entry for TechNews. Just 1-2 sentences explaining what the change is. Thanks!
Is this intended to be summarized in TechNews this week? If so, could someone please write a short (1-2 sentence) clear summary for inclusion? Thanks.
Hi. Is this now ready to be included in TechNews, or should it wait for next/future week's? (the User-notice tag was added in 2018!)
Whenever it goes in, please suggest wording for the inclusion, e.g. "Logged-in users will now receive a Notification if their account has been blocked."
Yes, I think with the newer approach this need not be communicated at all as the maintainers are willing to support the current usage, so there'd be no user facing change.
Wed, Jul 29
Thu, Jul 23
Yup. The general process is explained at
as linked from
Just noting for the record, I had similar problems on Monday, whilst delivering TechNews.
It delivered duplicates to 6 Wiktionary pages, at "ja, la, nl, ml, simple, vi", from this list:
The duplicates were delivered ~53 minutes after the first delivery, e.g. at :
Hi AlexisJazz. As I commented in the talkpage thread which you've linked, "we try to write the default content within Tech News to be as clear as possible, so that all the languages which do not have custom-translations can benefit from the clearest possible explanations of each entry. We also need to keep in mind that the target-audience for the newsletter are the technical editors on any given wiki, so a certain amount of technical jargon is expected. Therefor, hopefully there isn't a need for a separate Simple English translation of this newsletter." -- I.e. I didn't include the separate translation when I delivered this issue. Therefor there was no bug here. I will resolve this task. Thanks!
Wed, Jul 22
Confirmed! My mistake. Sorry I overlooked that (now obvious!) detail.
Fri, Jul 17
Mon, Jul 13
Just to check, was this communicated to the CN-admins? (I'm not on that mailing list) Sorry I didn't notice this task earlier.
If it wasn't, and if the above patch doesn't solve it, then hopefully @Jseddon can send an email, and perhaps we could also amend the interface strings within the UI itself to provide a clear reminder/warning?
I cannot see the UI (as I'm not a CN-admin), but presumably something within https://meta.wikimedia.org/wiki/Special:CentralNotice?uselang=qqx
Fri, Jul 10
Thu, Jul 9
Jun 26 2020
Jun 19 2020
Jun 18 2020
Jun 16 2020
2 legit threads/posts since 2018 (in April 2020 and July 2019). Cf. archives list at https://lists.wikimedia.org/pipermail/teampractices/
+1 to sunsetting.
Jun 15 2020
Jun 10 2020
Jun 8 2020
Jun 4 2020
Please do! (I don't have time to check for any content that doesn't already exist there, so please just copy whatever is needed across :) )
Jun 1 2020
May 30 2020
this decades-long best-practice
I'd be interested in seeing some decades old examples for that. This is not what comes to my mind from the 2000-2010 era, but I might have been visiting different webpages that time.
May 29 2020
The logical part of this decades-long best-practice is explained in detail in the project page link (with references there, and an Enwiki article link that gives many more references). It is not a recent development. It is definitely not a fashion.
May 28 2020
May 26 2020
May 25 2020
May 23 2020
May 22 2020
May 15 2020
May 7 2020
May 4 2020
@Enfcer Please do provide the specific email addresses. You can email them to me at nwilson at wikimedia.org if preferred.
See also T251816: Mailing-list sending notifications for inexistent spam messages
(Partial duplicate, but it also covers the new aspect today that "mailman is still sending reminders even after the backlog has been dealt with".)
I've gotten 4 duplicate reminder-emails for "moderator request(s) waiting" within the last ~3 hours.
(In PST@: 10:06, 10:32, 11:52, 12:18)
I dealt with the requests at 10:57, but it still sent 2 more reminder emails.
Apr 30 2020
I noticed that there is an awkward workaround, at the individual banner pages.
e.g. , if we click the link in the very top-left corner for "Preview last saved version" then we can see a preview.
Apr 20 2020
Based on the screenshot, I think this solution will solve the majority of the problems, for the majority of users.
Can another editor or two, please confirm, with your thoughts?
I'm not a developer at all, but maybe @kostajh can give some quick insights?
p.s. Thank you for being a Tech Ambassador from ru-wiki!
Other possible locations to mention it
@Neolexx Yes, that is correct. Unfortunately, it is currently only possible to uncheck all "Page link" notifications. There is no relationship between the "watchlist" feature, and this notification feature, at all.
Apr 14 2020
(Just fixing who resolved it, for the record)
I've overhauled the description to hopefully make this a bit clearer.
And I'll add here a strong +1 from me!
I thought this task already existed, but I could not find a duplicate in either the Special-pages or CentralAuth phab-projects.
Apr 13 2020
Done. New pw sent to the address listed at https://lists.wikimedia.org/mailman/listinfo/wikiwomencamp :)
Apr 11 2020
Apr 8 2020
There are a few existing bug reports about the "failure to deliver when target list is too big" issue, but it's a bit of a mess that I don't have time to untangle right now.
TLDR, we think the primary underlying bug might be T232392: EventBus extension must not send batches that are too large.
Apr 1 2020
@Ilario Per https://meta.wikimedia.org/wiki/Mailing_lists#Create_a_new_list please add to the description above:
- (x3) description of the list for the list info page (should include even if private list so ops and mailman admins know why it exists.)
I.e. please write out exactly what text should be included at the top of page, for each list, at their equivalent of (for example) https://lists.wikimedia.org/mailman/listinfo/otrs-zh
Ideally, write it out in both the list-specific language, and in English. You'll be able to edit the text afterwards via the interface of course, but it's best to start out with something there. Thanks!
To be closed via T31079 once resolved. :)
Mar 24 2020
Mar 23 2020
@Tgr @bd808 @Addshore (@AM?) - Are there any followup actions that need to be taken, from this session's notes and Anomie's comment?
If yes: Please comment or file tasks as needed.
If no: Please boldly Resolve this task.