Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://phabricator.wikimedia.org/p/01tonythomas/ below:

♟ 01tonythomas

This is great @Gryllida. I do not know what exactly would be the process here, but then, in this case, we agree to take care of the extension together, and you can add your name into the Individual contributors list, I would guess? If you want to simply play around the extension, we might have something in the backlog of MediaWiki-extensions-Newsletter (to setup Git/Gerrit and the feel of getting a patch out). Or, can someone else tell us what would be the expectation/steps here?

Just went ahead and created a patch anyway ;) Will wait for a go-ahead from @Gryllida!

So, what is the next step in these kind of cases? Do we simply add a configuration change to Mediawiki-config like https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/379316 or wait again to get the interwiki problem resolved and install to meta? From an architectural point of view, I see that - we should be able to still support a meta installation (assuming the interwiki is resolved in the future), even if we allow individual wikis to install and use the extension today.

Closing it as done. Thanks again for everyone who participated in getting our summarizer out.

Thank you! And, I went ahead and added myself as a steward for the extension in Developers/Mainteners. Now the extension has been running bug-free (mostly) in Mediawiki for a couple of years now, so we can trust that and give it a try in En-Wikinews?

Yes, we did. But for now we can't use even the Meta version, because the Flow is down, and there is no other proper way to send new issues until the problem of "one can sand only new page, it can't be section on some page" will be solved.

We solved it last week btw. It should be out on the May 20th release: https://phabricator.wikimedia.org/T393844

I played around with a bit, and saw that it was Echo that was killing the fragments by relying simply on the pageId. I thought about providing the fragment as an extra param while creating the issue, and using it when rendering it. Works, but, to be honest, this has to be implemented at Echo level, IMHO. But since that is a big ask, probably we might be able to live with this as well?

Ah, I got a bit disconnected for some time, and lost track of things :-(. Hopefully, I can respond and fix those comments you did one of these days, @Pppery! Thanks again for them.

·

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

Here is a new demo video of the progress, after:

• Added an option to [x] Make this newsletter globally available on all wikis:

Thank you @Ladsgroup; I also had to do some work arounds to setup 2 wikis locally to test this whole inter-wiki setup, and it kind of is looking good in shape.

Hmm. Good point. I think we will have to change how we only store the issuePageId right now to a bit more elegant structure where we can store #fragments from pages, and maybe interwiki properties as well. There are these couple of properties on the Title object, but I am not so sure how to save it in a nice way into the database. Asked in #wikimedia-dev. Lets see if someone answers.

Anyone feel like code reviewing https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Newsletter/+/977269 if this is going to be done? It's not nice to have a patch pending code review since November.

Should be resolved now. Great one, @Pppery

Marking as resolved, might get into mediawiki.org in the next release train, I hope.

9 years later, we see that this is one of the part of the puzzle that would get the extension out of its current state. I hope to take a look at reviving that old PR: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Newsletter/+/446590 to see if we can get somewhere.

Was just playing around, and thought about fixing this one to get back into the codebase. This is how it would look btw:

renamed

from

to

.

Closing the task as done, then. Thanks @Quiddity

Apparently this is due to a permission check. Will fix it in an upcoming PR.

Thank you for pinging @Aklapper; we might have some sort of a proof of concept (with only access to text under sections in Article and Talk pages) at: https://tonythomas01.github.io/wikipedia-section-summaries. You can see a demo here as well. Would be great to take this forward!

Great, if that one goes through - I can safely ditch my PR.

I could just reproduce this locally on my Mediawiki Docker + Echo + Newsletter setup.

Closing this in favour of T247679

Thank you for setting up the documentation @mukadas_maltiti. I think it would be great to link it from the tool as well.

Sorry to ping on this very old one, but we have something going on in: T336692

Closing this as Resolved, since we have a setup ready with https://phabricator.wikimedia.org/P10014

All of it. Google? Announcement? It is sitting there looking like it was ready to go, and then silence for a long time. Just wondered there was any information.

Works again :) There were some tiny Django updates, and I had to get rid of the old authentication methods. Closing this as resolved.

Hmm. Maybe my second change to upgrade to python 3.9 kind of broke it :-(

Lets move to 3.9.2 instead since 3.7.x is deprecated.

Fixed with a recent change. @mukadas_maltiti, let me know if you run into something else. Closing this task as resolved for now.

Thank you @Aklapper for pointing.

Hope to plan on the blogpost by the weekend. As of now, we have somethings https://github.com/tonythomas01/wikipedia-section-summaries

They could be stored as cookies - that's slightly annoying for people who are active on several projects, but avoids the need of storing PII on Wikimedia Cloud which is technically against policy. (Not sure how granular the API keys are but access to past chats is very personal information.)

I was planning on working on something very similar - summarizing talk page sections, preferably as a gadget and not a hosted tool (although not sure if that's feasible).

I am going to try rebasing this, and bring the patch back up.

Hmm. Its a bit sad to see that the extension remains unmaintained. I used to develop on it back in the days, and I think I finally have more free time these days. I will take a look at open tasks and the code reviews soon and see if I still can manage it.

So I just booted up a vagrant machine pointing to fresh "master" branch. Added the newsletter role, with this on top:

429be9a (HEAD -> master, origin/master, origin/HEAD) Localisation updates from https://translatewiki.net.

and mw-core versions saying:

Hmm. Out of curiosity @Reedy: Was this on the wmf cluster, or on a standalone instance ?

Adding @Lea_Lacroix_WMDE, who has some use-cases in taking this forward. If the problem was simply the build fails, we should get this going.

So long since we talked about this, but @Addshore: I know you did some works on this, but it would be great if you can mention here why the we could not get it all the way to the end. I know there were some build fails, but I see some fresh conscience on this (from private emails), so I am wondering if we can resume the work you already started.

Woah, knew this would be solved better like that. Thanks @Tgr. Probably something we should do next time then.

Un-assigning myself as I lost track of the progress. However, https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Newsletter/+/447087 is here in case someone wants to continue building.

Closing as we introduced Selenium tests for the extension and no new requirements came.

I pinged Google support and for the time being removed it to "Not ready to announce". Lets see what they have to say about it.

Wow. I am surprised about that security warning. We were supposed to get rid of that after all our Google security review. Let me see what is happening. Thank you @Ammarpad !

@Trizek-WMF so to come back here again on notifying the community, we think we have a solid tool out now (after it took almost a year for Google to accept our OAuth screens and access to Google drive). The tool is hosted at https://gdrive-to-commons.toolforge.org/ and now supports, among other things:

1. Select and upload multiple pictures from your Google drive at once.
2. Select categories, geolocation, license, creation-date and author attribution. A sample screenshot here:

Closing it for now. Thank you!

I am going to close this down as we are kind of done with our immediate enhancements. Great work team.

Great news guys. Finally, our request has been granted. Took just over a year of iterations but Google finally approved it today! Great work @Abbasidaniyal , @srishakatux. We should come up with a village pump post or something very soon about https://gdrive-to-commons.toolforge.org

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4