Appropedia:Site development

From Appropedia
(Redirected from Appropedia:Admin tasks)
Jump to navigation Jump to search
Shortcuts:
A:SD
A:DEV

This page is Appropedia's site development tasks and bug reports.

New task

Fix bug when converting pages to PDF[edit source]

The bug seems to be Firefox-specific. Sophivorus (talk) 22:20, 10 December 2020 (UTC)

@Emilio After some investigation, it looks like this issue is related to the Vector skin, rather than Firefox. If you load the Poncho skin, it doesn't happen. Can you confirm? Sophivorus (talk) 13:10, 16 February 2021 (UTC)

Look into implementing site-wide citations and DOI for pages[edit source]

See Appropedia:Village pump#Following up on references display. --Emilio (talk)

Add timestamp or date (yyyymmdd) to filename when uploading to avoid duplicate names[edit source]

mw:Extension:PageForms promises various options to control the name of the uploaded files but nothing seems to work! The only thing I could get to work is setting today's date and time as default filename. However prefixing the date doesn't seem possible, except perhaps with some custom JavaScript. However, before doing that, please comment on the current situation (see Special:FormEdit/Project/Foobar) and let me know where should the JavaScript run (if when creating pages with forms, in the visual editor, etc).

I think the visual editor is where it's most likely to be useful. I'm looking at the current idea and it works well. Better if there're no colons in the filename, because that may bring trouble down the road. I'd use UNIX time or random characters. It'd also be good to add the file format, though that may be difficult. --Emilio (talk)
@Sophivorus: I uploaded an image through the form the organization form and threw an error due to the colons in the filename. My recommendation after using it would be to simply use the yyyy-mm-dd format. --Emilio
@Emilio I changed the default filename to the yyyy-mm-dd format. Sophivorus (talk) 12:29, 30 December 2020 (UTC)

Metadata and default license for image uploaders (visual/source editor)[edit source]

Is this normal? Check this image for example. Recommended: set up a disclaimer, for examples: "Images uploaded are licensed as CC-BY-SA 4.0. For other licenses, use Special:Upload." --Emilio (talk)

@Emilio: I just modified MediaWiki:Copyright so that the footer of all pages (including images) now reads "All content is available under CC-BY-SA unless otherwise specified". What do you think? Is it worth allowing images under a different license? Sophivorus (talk) 13:00, 17 December 2020 (UTC)
@Scann, Sophivorus: I think that works for now, and probably Scann may have some ideas. Emilio (talk) 15:43, 17 December 2020 (UTC)
I think we need to clarify the license version (so I'd make it a CC BY 4.0, with a link to the unported/international version), but that should also be accompanied with the overhaul of the Copyrights page (which frankly doesn't make sense). Additionally I'd be very clear that other TOS might apply, we need to make that clear for folks. A safe bet would be to copy a similar footer to what Wikipedia currently has, even if we haven't written those pages yet. Scann (talk) 13:02, 18 December 2020 (UTC)
Also I wonder why we're putting CC BY SA as the recommended license. It might be tricky to recommend licenses. We probably want to generate a blurb that says: "don't know what the CC licenses are? Check here" or something in that line. Scann (talk) 13:04, 18 December 2020 (UTC)

Make our images appear in Google image search for Creative Commons images[edit source]

It may be as simple as some udata or data tag attached to our cc template in images. --Emilio (talk)

Update: I believe we need to enable the {{Information}} template for the File namespace. —Emilio (talk) 03:12, 22 December 2020 (UTC)
@Emilio Following https://developers.google.com/search/docs/data-types/image-license-metadata and after quite a while of trying, today I was able to hardcode the licensing data for one specific file (File:Lubetkin Highpoint II December 2005.jpg), test it out at Google's Rich Results Test. Next I'll generalize and integrate the markup to the Template:Information so that all new files benefit from it. Also, while researching this issue, I found a compilation of advanced google search features that we could progressively take advantage of. Check it out! Sophivorus (talk) 15:50, 4 January 2021 (UTC)
@Emilio Hi! Today I managed to generalize the image metadata via a new Template:Image license metadata and integrated it to most of the file licensing templates (such as Template:CC BY-SA 4.0) rather than the Template:Information. Now all files using these templates should be understandable by Google (though it will take a few days for Google to catch on). I also normalized and improved the text of said licensing templates and organized the licensing categories. Tomorrow I'll try to finish with this task, since there're still a few loose ends. Sophivorus (talk) 16:45, 7 January 2021 (UTC)
Oh wow, thanks so much! This is beautiful. Emilio (talk) 17:57, 7 January 2021 (UTC)
@Emilio Hi again! Today I finished updating the licensing templates. I also renamed all the "images" categories to the more general and appropriate term "files" (so Category:US images is now Category:US files, etc) and simplified and organized a great deal the file categories, as can be seen from Category:Files. This brings us another step closer to a simple, useful, scalable and maintainable file management system! Sophivorus (talk) 15:55, 8 January 2021 (UTC)
@Emilio It looks like Google is starting to notice the new licencing metadata! Sophivorus (talk) 20:12, 30 January 2021 (UTC)
@Emilio @Kathy Nativi Hi! I just noticed that the new images indexed don't link to the basic image page, but to weird non-canonical URLs. This is because Google is crawling all links on Appropedia, rather than the basic canonical URLs. In other words, Google is crawling links like:
https://www.appropedia.org/w/index.php?title=File:IGSvent_in.jpg&veaction=edit
when it should only crawl:
https://www.appropedia.org/File:IGSvent_in.jpg
To fix this, I just created https://www.appropedia.org/robots.txt following the recommendations at mw:Manual:Robots.txt#With short URLs
I tested the rules at https://technicalseo.com/tools/robots-txt/ and https://es.ryte.com/free-tools/robots-txt/ and it's all looking fine, but we should still keep an eye open on Analytics and Search Console for any issues. Sophivorus (talk) 11:59, 10 February 2021 (UTC)
@Sophivorus: Hi! I checked the Google Search Console, and I think https://www.appropedia.org/robots.txt is causing problems because it couldn't read the sitemap. Also, the health score has dropped drastically to zero, and we now have several orphan pages. Kathy Nativi (talk) 19:23, 15 February 2021 (UTC)
@Kathy Nativi Hi, thanks for noticing! I just added an exception to the robots.txt file for the sitemap. Search Console hasn't caught on yet and I think I cannot force it, but I trust in a few minutes or hours it will. Let me know if you notice anything on your side! Sophivorus (talk) 19:47, 15 February 2021 (UTC)
@Sophivorus Thanks! Let's give it a couple of minutes or hours. I'll keep an eye on it ;) Kathy Nativi (talk) 19:49, 15 February 2021 (UTC)
@Kathy Nativi It looks like Search Console has already found the sitemap. Did the "heath score" recover? Not sure where to look for that. Sophivorus (talk) 13:26, 17 February 2021 (UTC)
@Sophivorus Yep! We're back at 55 :) Kathy Nativi (talk) 15:27, 17 February 2021 (UTC)

Error related to https, images and Firefox[edit source]

See for example CCAT solar bug out box. --Lonny (talk)

@Lonny, Sophivorus: We found that it only seems to occur on Firefox (not on Chrome). Might be a browser thing, or a server thing.
@Emilio, Lonny: After some investigation, I think the issue is actually related to the Vector skin. The skin seems to be loading the little PDF icons via http, which triggers a Firefox non-encrypted resource warning. If you load the Poncho skin (from Preferences > Appearance), the issue disappears. Can you confirm? Sophivorus (talk) 13:03, 16 February 2021 (UTC)
@Sophivorus: Confirmed: Firefox with Vector = the non-encrypted warning. Firefox with Poncho = no warning. Not logged in to Appropedia on Firefox = the non-encrypted warning (and it seems that vector must be the not-logged-in skin. --Lonny (talk) 20:33, 16 February 2021 (UTC)

Look into privacy-control extensions[edit source]

This may not be necessary if we decide to implement a private wiki at https://private.appropedia.org Sophivorus (talk) 13:21, 11 December 2020 (UTC)

@Emilio Is this still a request? Sophivorus (talk) 12:52, 18 January 2021 (UTC)
I can ask User:GSTC about this but I think it will still be relevant. — Emilio (talk) 16:02, 18 January 2021 (UTC)
The key thing is that the participants in the GSTC can spend time developing their content and sharing it internally with their team without it being published to the wider world. We will then want to "turn on" visibility for everyone to see the content, but up until then, it should be protected from view. GSTC (talk) 03:07, 10 February 2021 (UTC)
@GSTC @Emilio Hi! After evaluating the available extensions to restrict viewing, I settled for the Extension:Lockdown. I installed the extension, created a new namespace called GSTC, a new user group also called GSTC, and configured it all so that pages in the GSTC namespace can only be created and viewed by users in the GSTC user group (and admins). So for example, I created the page GSTC:Test, which should only be viewable by users in the GSTC user group. Catherine, I've added your user to the group, so you should be able to view the page (please confirm) but if you visit the page while logged out, you won't. Furthermore, I've given your user a special right so that you can add other users to the GSTC group. To do so, just visit Special:UserRights. When you want to publish a page, simply move the page out of the GSTC namespace (by clicking the Move button next to Edit). Hope this helps, let me know of any questions or issuesǃ Sophivorus (talk) 13:08, 11 February 2021 (UTC)

Improve Help:Creating a page#Get started with a page template to use forms and visual editor[edit source]

Sophivorus (talk) 18:06, 24 December 2020 (UTC)

Image upload form is broken[edit source]

Tried uploading an image at [1] and gave an error: [X@grks5HnOUAcSXF7EftfwAAAAc] 2020-12-27 06:37:06: Fatal exception of type "Error"

@Sophivorus: I am testing this again. Uploading from forms such as the organization form is throwing errors despite eliminating colons in the filename. --Emilio (talk) 22:55, 29 December 2020 (UTC)
@Emilio: I was unable to reproduce the error you encountered. I uploaded all sorts of files without any trouble, from the organization form, from the skill form and from the regular upload form. Anything weird about the specific file you tried to upload? Are you able to reproduce the issue at will? Sophivorus (talk) 12:26, 30 December 2020 (UTC)
@Sophivorus: Here it is (video plays in Chrome only due to it being mkv):
Emilio (talk) 15:51, 30 December 2020 (UTC)
I was now able to reproduce it, enabled debug mode and captured these details:
Screenshot 2020-12-30 at 1.15.44 PM.png
I'll try to figure it out tomorrow! Sophivorus (talk) 16:39, 30 December 2020 (UTC)
@Emilio Hi! I just enabled the "simple upload" feature of Extension:PageForms, which basically simplifies the upload mechanism enormously (test it out!) and apparently also fixes this bug. However, it has some downsides. First, it doesn't allow the user to select a new file name. The file is uploaded with the name it already has. Furthermore, if there's another file with that name, it will replace it with no warning. :-( To mitigate all this, I wrote a fairly clear warning next to the upload button (check it out). Given that the previous upload form we had was complicated, not-configurable and buggy, this may be a reasonable solution. I can also code a way to add a timestamp to file names, so we don't have overwrite issues, though that would imply modifying the PageForms source code. Coding a patch that can be merged upstream would be trickier and demand more time, but also doable. What do you think? Sophivorus (talk) 12:40, 31 December 2020 (UTC)
Hm. Tricky. I am curious as to whether this file renaming problem is consistent across all of MediaWiki and how other people sort it out. But definitely, the best option is to code a patch and hope for the best. Could we share with the community and see what do they think? Emilio (talk) 13:36, 31 December 2020 (UTC)
@Emilio Hi! Today I installed mw:Extension:UploadWizard and configured it so that it creates similar file pages to the visual editor. Check it out! The upload wizard has a friendlier user interface and allows to upload several files at once, among other features. This brings us another step closer to a simple and coherent file uploading experience. Next step would be to create file form to edit all pages in the file namespace. Tomorrow I'll also rise the min file size to 100 MB. Cheers! Sophivorus (talk) 15:56, 2 January 2021 (UTC)
Beautiful!! Emilio (talk) 16:20, 2 January 2021 (UTC)
@Emilio I'm glad you're liking it! Today, rather than creating the file form, I was able to greatly simplify and improve the UploadWizard flow, please test it out! We may still simplify it further by removing some licencing options that we don't really want to support (let me know). But other than that, I think it's ready!
See File:Time-lapse of tomato seedlings.mp4 for an example of a file page created using the UploadWizard. By commenting out two lines of JavaScript code from the UploadWizard source code, we can get rid of those abominable =={{Int:filedesc}}== and =={{Int:license-header}}== headers and make the file pages consist of a simple {{Information}} template followed by a simple license template like {{Cc-by-sa-4.0}}. If we do comment out those lines, we should inaugurate some page like Appropedia:Source code changes to document these and any other source code changes. Modifying the source code is generally undesirable, but it may actually become necessary at some point. For example we already have another case where modifying the source code a little would be handy, namely to add a timestamp to the files uploaded via the PageForms "simple upload" to prevent undesirable file overwrites. I think that if you, me, Lonny and every other user with access to the server are made aware of the documented source code changes, and we keep them to a minimum, we could benefit a lot more than the minor inconvenience of having to re-do them every so many years after updating a modified extension. Also, if we do forget to re-do the changes, it wouldn't actually matter much, at least not for the two source code changes I'm suggesting. What do you think?
I also just increased the max upload size to 100 MB, though I didn't test it out. Cheers! Sophivorus (talk) 14:02, 3 January 2021 (UTC)
Sorry for not noticing earlier, but I'm curious about whether we can leave only CC-BY-SA 4.0 and CC-BY 4.0 as options. I see that 3.0 versions are available. Emilio (talk) 03:33, 14 January 2021 (UTC)
@Emilio Hi! I just limited the licencing options when uploading a file as your own work to CC-BY-SA-4.0 or CC-BY-4.0, cheers! Sophivorus (talk) 15:35, 3 February 2021 (UTC)
@Sophivorus, J.M.Pearce: One comment from User:J.M.Pearce was the possibility to also add the GNU FDL option. Here is his comment: I really like the new file uploader -- only thing is we lost the GNU FDL -although not the functionality. Could we have that one too? — Emilio (talk) 17:17, 3 February 2021 (UTC)
@Sophivorus, J.M.Pearce: I would add CC0 to this list. So it would be:
What do you think? Emilio (talk) 18:18, 9 February 2021 (UTC)
I just added CC0 and GFDL, so the current list is:
  • CC BY-SA 4.0
  • CC BY 4.0
  • CC0
  • GFDL
Should I remove CC BY 4.0? Sophivorus (talk) 11:32, 10 February 2021 (UTC)
Hmm...yeah, maybe it's a good idea. I wonder what the rest of the community think, but we can see that as more organizations start generating content with us and adapt to their needs. Emilio (talk) 20:08, 1 March 2021 (UTC)
Did you decide to do any source code changes? I agree that keeping track of them will be super useful. Emilio (talk) 19:35, 3 March 2021 (UTC)

PdfHandler[edit source]

This extension might be useful, especially to display many PDF files such as documents and presentations. PDF might also serve in the future as the second type of media available at skill pages.

@Emilio This extension requires some command line tools (pdfinfo, pdftotext and maybe others) that are not currently available on our server and don't seem trivial to install via WHM. Sophivorus (talk) 14:24, 3 January 2021 (UTC)

Accept ToS when creating account[edit source]

Is it possible that we create a ToS (Terms of Service) were we also include the information about the copyrights? I'm working on the Copyrights page now, but I think it would be useful if when people create an account they directly agree to releasing their content under a CC BY SA 4.0. The same is true for the "save changes" section, that needs to be improved:

Appropedia copyright.png

I'd put a different text there, it should read:

"By saving changes, you agree to the Terms of Use, and you irrevocably agree to release your contribution under the CC BY-SA 4.0 License. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license."

Terms of Use should link to a page we don't have yet but that we should create, where we explain that users a) should not upload copyrighted stuff and b) that Appropedia might decide unilaterally and on its own to update the CC license version to the most updated one, etc., among other things.

Also, happy new year folks!

(also I can't find the signature button anywhere but who else could be talking about copyright & tos)

Exemplary articles[edit source]

@Emilio: Build a list of exemplary articles of each category and link them from the most relevant places in the help documentation. Sophivorus (talk) 15:31, 12 January 2021 (UTC)

Started at Appropedia:Toolbox#Exemplary pages. Sophivorus (talk) 13:24, 16 February 2021 (UTC)

Create template for Bill of Materials[edit source]

Sophivorus (talk) 19:36, 18 January 2021 (UTC)

Can we call it Template:BOM please? Some Bill of Materials might not contain costs. -- Emilio (talk) 18:04, 19 January 2021 (UTC)
@Emilio Sure! Today I started Template:Bill of materials (I made Template:BOM a redirect, as I think abbreviations should be allowed but not encouraged), check it out! It still has a long way to go, but I think it had a good start. To design it, I searched for "bill of materials" and opened several pages to see what elements were most common. In the next iteration I want to make the "buy" link more flexible, since it looks like users sometimes write plain text, other times link to Appropedia pages, and other times to external sites, see for example Open-source metal 3-D printer#Bill of Materials (one of our top pages). Feedback welcome! Sophivorus (talk) 14:59, 22 January 2021 (UTC)

Add semantic capabilities to an Mbox[edit source]

For the text, we can take a course page such as 3D-printed chemical etching handle. The relevant information is the following: organization (link to organization page), course (link to course page), year, open edit (yes/no).

@Emilio: Hi! I just did a first implementation of this request, check it out at the wikitext of the Template:L3999 Fall2017 template and the resulting properties of 3D-printed chemical etching handle and let me know your thoughts! I haven't implemented the open edit yes/no property yet, but before I do so I'd like to share a thought about semantic properties. In order to maximize the chances of them getting used and reused, I think we should carefully balance precision vs practicality. For example, we currently have Property:Date of publication and if we followed the infobox properties verbatim, we should have Property:Date of update and Property:Date of creation. But isn't so much precision an obstacle both for querying projects and for adoption by new users and use cases? Wouldn't it be better to have just Property:Date? Sophivorus (talk) 13:51, 5 February 2021 (UTC)
Hi! I was looking at Understanding solar concentrators as a great example of ported content that does not describe a specific project or device. I will remove the notice template and use an MBox to try and describe what is on this page.
A thought: date of publication exists because there could be old projects that are recently ported or published by someone. I think we can start thinking about these issues, for example, in terms of when a project/device was created and when it was documented. Open Know-How standard considered the creation of the manifest file, which seemed to me a bit unpractical (and this is one of the cases). But the documentation being made at a later date in time is definitely important.
Some property ideas I'm thinking of:
  • Document type (topic page/lit review/technical brief/research note)
  • Source--when a verbatim copy (URL/citation of PDF file/etc)
  • Derivative of (citation, other document, or article on Appropedia)
  • Translation of
  • Language
Check this example of derivative works: Aerial Ropeways in Nepal (original) and Aerial Ropeways in Nepal. -- Emilio (talk) 20:43, 18 February 2021 (UTC)
@Emilio Hi!
  1. I think maybe Understanding solar concentrators could maybe be a use case for the new generic Template:Infobox page, though admittedly, the infobox would need several new parameters to capture the meta data in the intro of the page.
  2. Regarding the Property:Date of publication, ok then, lets keep it.
  3. I do agree that having meta data about the manifest itself is impractical. It adds complexity to the infoboxes and forms while yielding negligible benefits. If you agree then, I'd like to remove them.
  4. Regarding your property ideas:
    • Document type: already implemented, see Property:Type. You can see all currently existing types from the dropdown at Search. I just created Template:Literature review and modified Template:MOST lit so that they use this property. As to "topic page", "technical brief" and "research note", it'd be a matter of creating an mbox/infobox for each and add them to the relevant pages.
    • Source: do you have an example of a page in need of this?
    • Derivative of: already implemented, see the Property:Variant of and the "variant-of" parameter in Template:Infobox device and Template:Infobox medical device. Should I rename it?
    • Translation of: already implemented, see the Property:Translation of and the "translation-of" parameter in many infoboxes.
    • Language: already implemented, see Property:Language code, the "language-code" parameter in many infoboxes and the corresponding field in many forms. Using language codes rather than language names is important because it allows the software to understand it.
  5. As to Aerial Ropeways in Nepal, check out this strategy which allows us to get rid of static pages like Aerial Ropeways in Nepal (original), like I just did here.
Maybe we should do a call to talk about some of these points? Kind regards, Sophivorus (talk) 14:16, 3 March 2021 (UTC)
I agree. Can we make a working page for these properties? I'm writing a full description with some examples to get the discussion going since I'd love to hear your thoughts on them. Emilio (talk) 21:11, 3 March 2021 (UTC)

Twitter Cards[edit source]

Hi @Sophivorus:! Can you help me implement Twitter Cards to the website? It'd be nice to look good in the Twitter feed as those tags instruct Twitter what information (title, description, image, etc.) to display whenever a URL to a page is shared. I think you'll need my help to access the Twitter developer platform.

@Kathy Nativi, Emilio: Done! I installed the Extension:TwitterCards which is designed to add precisely that functionality. I tested the cards at the Twitter Card Validator and they seem to be working fine except that the robots.txt file was blocking access to images. So I added another exception to the rules, but it looks like our cache (either Varnish or CloudFlare, not sure) is still serving the old version, so it may take a few hours to catch up. Cheers! Sophivorus (talk) 12:14, 16 February 2021 (UTC)
@Sophivorus Hi! Apparently there are some pages with one or more of the basic Twitter card tags missing. Basic Twitter cards include twitter:card, twitter:site, twitter:title, twitter:description, and twitter:image. Can you take a look at it? Thanks! Kathy Nativi (talk) 15:32, 17 February 2021 (UTC)
@Kathy Nativi Hi! As far as I can tell, the reason why many pages don't have their basic Twitter card tags, is because many pages don't have an intro or main image. So for example, if you go to the Twitter Card Validator, you'll notice that How to build a bamboo shade structure generates a decent card, while How to start a solar company does not. But that's because the first page has an intro and a main image, while the second doesn't. This cannot be fixed on the software side. The solution is to normalize and improve pages so that they all have an intro and a main image. Other reasons for wanting to do this are to have the "popups" display correctly (hover over the links above to see what I mean) and to help Google and other search engines display a good snippet on their search results. Kind regards, Sophivorus (talk) 14:55, 18 February 2021 (UTC)

Facebook pixel[edit source]

@Sophivorus @Emilio Hello again! I just sent you an email with a pixel base code from FB to install it on the website :) Kathy Nativi (talk) 18:57, 16 February 2021 (UTC)

@Kathy Nativi: we are thinking that it might be best not to include Facebook code on our code. I know it can help us get better-driven traffic, but we want to maintain a clean experience as much as possible for our users. So far we have Google Analytics and Hotjar, but we'll make sure to be careful in how we gather usage data. Do you think we can find any alternatives to this problem? Emilio (talk) 20:35, 18 February 2021 (UTC)
@Emilio Got it! I'll just set goals and funnels in Google Analytics to measure conversions :). Just be aware that if installed, the FB pixel information will not match the GA data because Facebook is a people-based tracking and GA is cookie-based tracking. Kathy Nativi (talk) 21:12, 18 February 2021 (UTC)

Poncho skin[edit source]

@Emilio Hi! I just improved the Poncho skin so that the menu (top-right) now supports submenus, check it out! You'll notice that one of the submenus is just too long for this design, but I actually think the problem in this case is that the submenu is just too long in general, and it may be better to shorten it rather than expecting Poncho to support such long menus. Other than that, what do you think of this submenu strategy? Sophivorus (talk) 14:07, 17 February 2021 (UTC)

@Emilio Hi again! I did some more tweaks to the skin based on what we talked, check it out at for example CCAT greenhouse, GSTC and Category:GSTC courses. Feel free to play with the skin at MediaWiki:Poncho.css and let me know your thoughts and any issues you notice. Also, let me know when you settle on a color palette so I can start experimenting too, cheers! Sophivorus (talk) 13:19, 1 March 2021 (UTC)

Progress or checklist template[edit source]

Develop a template that detects and communicates to users the missing elements of a proper documentation. Sophivorus (talk) 17:05, 18 February 2021 (UTC)

@Emilio First version at Template:Project checklist. Waiting for some feedback from Catherine or you. :-) Sophivorus (talk) 13:21, 1 March 2021 (UTC)

Update Template:Event[edit source]

I was looking at mw:Template:Event and wanted to hear your opinion on the best way to implement it since Template:Event exists for a different purpose. What do you think? I'm looking to implement a template to track events happening on our platform (such as by Fashion Revolution or GSTC. —Emilio (talk) 00:57, 4 March 2021 (UTC)

@Emilio Our Template:Event isn't really used anywhere in the wiki, so we may replace it. But before I do, I'd like to know, where would the template be used? On the main page? Sophivorus (talk) 11:31, 4 March 2021 (UTC)
I was thinking of using them to show future events at portals such as the FR, maybe as a sort of "upcoming events" widget. Emilio (talk) 17:56, 4 March 2021 (UTC)