Fixed! Now available at https://shuffle.toolforge.org/

I'll keep this open and assigned to me as I intend to finish this on the upcoming minihackathon in the Netherlands.

@Jdlrobson If it was fixed in Vector 2022, then it has regressed because I find the language links in the bottom again on the main pages of enwiki, svwiki and frwiki when using it. Screenshot from enwiki.

Oddly enough, the query below uses DISTINCT and VALUES but correctly returns 4 results. So there might also be a connection to wdt:.

Related, right now when opening a map without lat/lon/zoom in VE, it adds it, possibly ruining the map.

In T166094#8310375, @TheDJ wrote:

I have some other points that should be taken into consideration

2. Review... In much the same way as default content from wikidata was a problem for en.wp, I suspect that default content for alt tags from Commons might be a problem for that community. It would be the first text content from Commons that by default becomes part of wp articles, sourced by search engines etc. There is a vandalism angle possible there, and they may argue that Commons' review processes are not setup to detect that, so that might become a conflict point.
3. Per the law of levels of investment required to get something useful... This is likely only to benefit en.wp in any sort of substantial level. Other languages will stil mostly be left out.
4. It could be a distinguishing feature to have multi lingual alt text of very popular media items.

In T166094#8307437, @Pigsonthewing wrote:

In T166094#8202790, @El_Grafo wrote:

1. "Alt text is context dependent" - that shouldn't keep us from offering general purpose default alt texts like "a basket full of mushrooms on a wooden table" that can be overridden with existing syntax: [[File:foo.jpg|thumb|description|alt=specific alt text]]. No counterarguments have been made against this.

If the image is used on the article about the species of fungus, would that be good alt text? No.

In T188291#8278395, @Spinster wrote:

I would also like to include links to Wikipedia articles but am stuck.

In T264751#8276999, @valerio.bozzolan wrote:

I suggest to remove the Commons Tag and set a generic Cloud-Services and rename this Task to:

In T305121#8008184, @TheDJ wrote:

Apparently this is still broken ?

For legibility, I would prefer single quotes rather than escaping, but if there are some queries where single or double quotes matter (I wasn't ware it could be), then escaping is of course a better solution.

Yes, for example this one that relies on a query which uses several ' : https://sv.wikipedia.org/wiki/Mall:Maplink/Lista_%C3%B6ver_kommun-_och_regionstyren_i_Sverige

I was trying again, and it seems to actually only load twice. But on the other hand, there is a lot of scrolling to even get it to load the first reload, so it seemed infinite. In fact, my screenshot app reached maximum image limit before even hitting the first reload (screenshot attached). I suggest that to change the behavior to reload automatically.

An alternative would be to crop the images so that they can't be recognized. I don't think the important part is seeing them in use, but just getting an understanding of how the clothing look like to inspire others.

Yes, I can confirm that this somehow has been resolved. Not only in the small example in the description, but also this larger map finds all municipalities: https://sv.wikipedia.org/wiki/Lista_%C3%B6ver_kommun-_och_regionstyren_i_Sverige_2018%E2%80%932022#/map/0

Perhaps this should go as a new feature, but if it's not too late to get it right from the start, this thumbnail should also be used on search result pages.

In T181319#7792296, @Mike_Peel wrote:

Just to comment that the example came from https://www.wikidata.org/wiki/Special:LongPages - you can see the first page of these is either COVID or journal article items. It maybe a case of changing the approach of an editor or two on-wiki to avoid these situations arising, more than it requires software changes, though.

In T258176#6891290, @Jenny_Brandt_WMSE wrote:

Wikipage will be added with material.

Related, when I go to full screen with the square bracketed button in the top-right corner of the map, and then close the full screen view, the map totally disappears.

In T276753#7727425, @Jenny_Brandt_WMSE wrote:

This was done in 2021.
Added here: https://drive.google.com/drive/u/0/folders/1--x6REO3fmucaKiwNz_cN9-lYS65Lgj8

In T116762#5251929, @Addshore wrote:

I guess technically these messages do appear on wikipedias and other sites as we have global notifications!

It happens a couple of times every day, but not every search. And I haven't figured out what it is triggering it. So yes, seemingly random to me. But I think I have caught in on stream about every other time I've been doing regular manual editing.

Just curious, which patch fixed this?

In T295633#7502533, @Lydia_Pintscher wrote:

You are talking about this, correct?

Oops, that was a sloppy mistake. Thanks for pointing it out!

Fair. When I filed it I thought it was an official service from the Wikimedia Foundation (that is the impression the page looks on IFTTT gives).

No I am not sure. But perhaps @Slaporte (who seems to have been involved in setting it up) knows?

Regarding the first open question. I imagine this would be a manual opt-in. I wouldn't want to be signed up somewhere unless I specifically asked. For me, there might be 5-10 such pages on Swedish Wikipedia (and possibly similar on other wikis), but once set, I don't think it will ever change. With an exception perhaps for Meta, where these kinds of pages pop up regularly.

I can report that it has been a smooth setup and that the dashboard is public at: https://matomo.wikimedia.se/index.php?module=CoreHome&idSite=7

Just a notice that this problem seems to be global. Compare https://maps.wikimedia.org/#9/59.3370/17.6214 with https://maps.wikimedia.org/#10/59.3370/17.6214 (in Sweden).

The time correlates to the last edit on https://en.wikivoyage.org/wiki/Special:AbuseFilter/37

Thanks for adding that perspective Nikki. I guess it is too hard to configure variabilities for different languages. Instead we could start with a simple control on import: "We found several forms spelled exactly the same on some lexemes. Please uncheck the ones that are not pronounced the same as the first one." This would also probably be helped by showing grammatical features so that it is easier to know if they are pronounced differently but I think we could try it even without that.

Which is this one (and variants are linked from it): https://commons.wikimedia.org/wiki/File:Wikimedia_Accessibility_logo.svg

If that is common, then the ExternalTools that feeds the word list need to be remade, because when I tried to load all the forms for L46694 I only got the possibility to record six files out of the eight possible forms. However, at least in Swedish I don't think it occur at all.

In T284293#7134500, @Infovarius wrote:

What if other forms have "same spelling" but different pronunciation? (homographs but not homophones)

I got sidetracked but intend to finish this soon. I got to starting the tool: https://toolsadmin.wikimedia.org/tools/id/shuffle
The only(?) thing left is to move the files.

Here is my draft if anyone wants to improve it. I submit it under CC 0.

Should this perhaps move to the Social events column on the board?

Opt-in or opt-out seems like a small deal, since whatever the default is, it is so easy to change it. I would prefer opt-out because that means that people might get aware of the feature (not everyone go look at the notifications settings regularly).

My take is: yes, yes, very.

My perception is that two hours is the total timeframe for solving the queries. The fun and challenging part was to solve them under time pressure. To make questions that will take days to solve will be unreasonably hard. The kickstart could be 5 minutes long.

The test in the timeless skin doesn't work (but I don't know why).

I was so confused by this news. Isn't it a template that can be collapsed (which contains sections), rather than actually collapsing sections?

In T166094#6880079, @Multichill wrote:

You don't understand. The description array is empty for *every* file on Commons. It's not used at all. So if we technically need a place to store this in a multilingual way, it's still available (fresh in your words). In the user interface you can call it whatever you like.

In T166094#6878327, @Multichill wrote:

No we don't, captions are just labels, see https://commons.wikimedia.org/wiki/Special:EntityData/M96527.json . Description is currently unused in SDOC.

Well, then we need a new field for the caption. They are not meant to solve the same problem and should almost always be different from each other. So for every image it would be very useful with two separate text fields.

It can certainly be done as a subtask as it would be valuable even without the following addition. But I guess this task is dependent on such a query to be able to know the exact forms to add the files to, so it needs to be connected as a blocker.

The simplest solution that would still be hugely valuable would be to feed LinguaLibre with forms of lexemes (preferably through a query), get to record the forms in the regular interface, and then after they are uploaded the files get added with pronunciation audio (P443) on the respective form.

Should this be reopened since Space has been abandoned?

PeerTube got support for live streams in its latest release a week ago! Since it is open source, this is a possible way forward.

Wouldn't it be better to edit this through the API than a bot? The tool already asks for Oauth. This has a few advantages, I can get credit/blame more directly and I can also immediately inspect the edit (If I have to wait for the bot, I might forget it).

In T21906#6681654, @Pigsonthewing wrote:

I asked you to clarify what you mean.

How about I add a table to the results section? It could have a column per "channel" and try to fill it with as much analytics data the platforms let me retrieve.

Suggestion: remove all points that are better suited in an email. We don't need a meeting just to share information.

It doesn't really matter what the English Wikipedia Manual of Style says, since this is something that affects all the projects and anything added could be overwritten locally. If it's has an argument of great weight, that should be added into this thread so that no one need to guess what on that page is vaguely referred to.

Then please explain why then in this thread, because that's what the English Wikipedia manual of style seem to suggest.

@Pigsonthewing Are you arguing that making sure that there absolutely is no alt-text is better than one which is easy to locally override and that only might be slightly off-topic?