Reported at https://ca.wikipedia.org/wiki/Tema:Un2fecuwlgy3551q

Sorry, I guess in my excitement I misinterpreted the meaning of MW-1.32-notes (WMF-deploy-2018-09-18 (1.32.0-wmf.22))

Yes, people can add themselves. I have no idea about what is going on here...

Beats me...

I see

This looks like the counterpart of T175497: Fields of newsletter not being updated in the newsletter info page (your own update triggered something that finally unblocked the update that got stuck somewhere for months).

Is this resolved, then?

One question, does the number of subscribers get out of sync after adding/removing someone manually only temporarily and then re-syncs, or are manual removals/additions cause the number of subscribers to become false, permanently out of sync?

(I didn't test every day as I promised but) Yesterday night it happened again. This time I was clicking a link from a Google Hangout chat in my mobile device to https://en.wikipedia.org/wiki/Wikipedia:Arbitration_Committee/Noticeboard. The link activated the Wikipedia app, and a few seconds after I got the email about the Failed Attempt.

The patch has been merged. Is this task Resolved?

Very good idea. This task is a good candidate for Google-Code-in-2017

Thanks. Declining this task for now. We can reopen it in the future if we have real use cases being limited by the current functionality.

Absolutely, thank you very much for these ideas and the mockup. This looks like a good candidate for Google-Code-in-2017

Totally, thank you very much.

You are right, but I believe the current list of issue announcements is literally a log. Does someone know how difficult would be to parse this information as @Ckoerner suggests?

This is of course a very good idea. I wonder how complex the implementation is.

Yes, this would be a good improvement. Would you like to volunteer the texts, so a Google-Code-in-2017 student can make a straightforward implementation?

Yes, this would be a good improvement. Would you like to volunteer the texts, so a Google-Code-in-2017 student can make a straightforward implementation?

Thank you, good catch! Yes, "page" is better.

Thank you for these ideas! Let's see.

All MediaWiki.org syspos (administrators) have permissions to manage newsletters here and, in fact, anyone can post anything in any newsletter if they so wish. They only have to add themselves as publishers before (two clicks).

I'm not sure about this. Until now we have followed the principle of giving permissions to those who need them.

At least from a UX point of view, I see the behavior differently: the Newsletter page is by default the Special page about to be created, unless the user defines an existing wiki page.

(Since then I have added more publishers to newsletters, and I have heard no further complaints.)

Looking good!

Thank you very much for working on this, @SimmeD !

A newsletter announcement consists of two fields only: a URL and a summary. I don't think it is too much to ask both?

When creating a new newsletter, Main Page is the page defined as the "home" of the newsletter. It makes sense that is is unique because one can assume ust one wiki page designated as wiki page related to just one newsletter. Then again, it would not be the end of the world if checking this uniqueness causes problems and we remove the check.

The last patch has been waiting for a review 11 days. It's a pity, because a lot of work has been put in that changeset and its iterations. @Addshore could you help reviewing, please?

Today it happened again, when QuimGil performed a search for Catalan Wikipedia from the app. I am going to try once per day from now on.

@01tonythomas @Bawolff @Addshore I have tried to define the interwiki support feature in way that allows developers to discuss the technical implementation. Do you think that it is clear enough?

New text proposed above, in the task description.

It's not that users needing urgently a newsletter don't have options. You have created a newsletter in MediaWiki.org that is serving Hebrew Wikipedians, and you can also create a newsletter in he.wiki distributed with MassMessage, like newsletters in Wikimedia have been doing and continue to do.

As suggested in the description, why not emulate how VisualEditor handles links? The "Search" tab for MediaWiki and interwiki pages only, not the external links.

Plain users and plain publishers not finding each other. A single list with all the newsletters reduces that risk.

In T177825#3682603, @QuimGil wrote:

Confirmed. Notifications about new Newsletter issues are not arriving.

In T177825#3680113, @Vriullop wrote:

On ca.wiki it is reported that it works saving user preferences with some change. I tried changing notification to email, then changing back to "web" and now it is working for me, both notification for mention and structured discussion.

In T110645#3682995, @IKhitron wrote:

How exactly the partial deployment can make the problem bigger?

@Bawolff I am not sure the interwiki notifications are the problem. Currently users are already getting Newsletter notifications in their wikis when they are not MediaWiki support, thanks to plain interwiki Notifications. T175279: Add the newsletter description to interwiki bundle notification is a problem, but maybe the solution lies in the Notifications framework, not in the interwiki support for Newsletter extension.

In T177151#3649481, @IKhitron wrote:

A pity, but you are the boss, of course.

In T177151#3649481, @IKhitron wrote:

In T177825#3680735, @IKhitron wrote:

I just published a new MediaWiki-extensions-Newsletter issue. Some of notifications in email arived, some didn't.

I have created a newsletter that has the newsletter page as its main page. I have cheated:

Or... maybe the question is simply how hard would it be to whitelist *:?

How hard would it be to whitelist phab:?

Note that T176199 is a different kind of request, because office.wikimedia.org is a stand-alone (not SUL) and private wiki. Therefore, the interwiki problem doesn't apply there.

Hi, sorry, the Newsletter extension cannot be deployed to other Wikimedia wikis until we have figured out how to solve T110645: Interwiki support for Newsletter extension. A key value envisioned for this extension is to have a single catalog with all the newsletters, so users can check the one and only list and find everything there. If we start enabling this extension before the interwiki question is solved, we will have dozens of catalogs of newsletters spread all over.

For what is worth, fixing descriptions (trying to see the difference when a suspicious edit comes and restore a previous version if it was vandalism indeed) is an unpleasant task. It needs to be done manually, takes time, and makes you miss a revert link. This needs to be done with reasonable frequency in MediaWiki.org or Catalan Wikipedia, and I suspect other wikis with SD enabled. The more SD expands, the biggest this problem will become.

I support this suggestion, In fact, I came here to report it and then I found this task.

@Eugene233 you asked me via chat, but then I have thought a bit more, and... Considering that this is your first task for the Newsletter project, I think it is better that you upload a patch with the fix sooner than later. Since it is a quite visible change, I think writing tests here is not so important as to delay that first upload and the beginning of the code review.

Thank you for this report.

Not a proper notification, but user Qgil-WMF removed user QuimGil as a test, and this is what QuimGil received via email:

Thank you @He7d3r for reporting, thank you @D3r1ck01 for promoting, and thank you @Eugene233 for taking this task. Good luck! If you have questions, please ask.

First we would need to check whether the Notifications framework allows to do this.

How do edit summaries parse wikitext, and could we use the same approach? Edit summaries accept wikitext links [[Some page]] that will be parsed as such in the page history and Recent Changes. However, http links, images, templates etc will not be parsed.

Maybe the solution is to simply use the same type of field that MediaWiki offers for edit summaries. It's a textfield and not a textarea, which in itself gives an idea of conciseness. It has a character counter that lets users know how many characters are left.

This is weird. Today I saw that the old description had reappeared in Special:Newsletters and the Manage page. What / who brought it back and from where, I don't know.

This request has some open questions common to T175430: Allow translatable text in the summary of Newsletters. A newsletter only needs a multilingual title when it has multilingual issues. For practical reasons, let's mark this task blocked by T175430 and let's start the discussion there.

From a subscriber point of view, what would decide in which language I receive the notification? An algorithm will have to decide, based on what? Unless subscribers are able to define a preferred language when subscribing, which would complicate things. The same question applies to T175431: Allow name of Newsletter to be translatable.