@Ladsgroup - Is there any way that folks can manually purge thumbnails that didn't get regenerated (besides reuploading the images)? Apparently action=purge doesn't do the trick. I imagine giving users blanket thumbnail purging capabilities would be a security concern, but maybe if it were limited to their own uploads it would be reasonable.

Folks on Commons are reporting that this is still a problem.

See T192500 for river and island labels.

Just because this work wasn't completed doesn't mean it isn't still a valid bug that needs to be fixed.

people who value free knowledge, free software and privacy are currently left out by WMF microblogging

This is an important point. The very people who already share the WMF's values (and thus would never use Facebook or Twitter), will never see a social media post by the WMF. It might seem like that demographic is too small to matter, but I imagine it overlaps significantly with the demographic of people who would think writing encyclopedia articles in their free time is fun.

@Legoktm - Given that the WMF has no interest in using Mastodon (judging from @LDickinsonWMF's comments and lack of engagement here), I agree that it would make sense for the community to move ahead on this without official WMF support. Do you know anyone in the community (yourself included) that might be interested in such a job? Maybe someone at one of the chapters?

@LDickinsonWMF - Thanks for sharing that information! I'm glad to hear that the WMF is exploring the use of Mastodon and I look forward to seeing what comes out of it.

@Legoktm - That's a good point. For example, Mastodon expects posts to use content warnings and image descriptions for better safety and accessibility. I know Wikidata moved over to your wikis.world server recently. I wonder what their approach is.

@CKoerner_WMF - I heard you might be the person with the WMF Twitter keys, so would love to know your thoughts.

There is some discussion of crossposting tools at T236397. @bd808 may be able to provide more details.

@MarkTraceur @Tgr Could someone with shell access at least look in some of the relevant archive directories and see if anything is in there. Maybe the filenames have been changed or corrupted or it's an encoding issue.

@matmarex - I'm wondering if your change to mediawiki.page.gallery.js from April could have affected this.

@Jdlrobson - Thanks for the response!

Hey @kaldari the issue here is the gallery code has no maintainers so likely nobody is responsible for triaging https://www.mediawiki.org/wiki/Developers/Maintainers

Ah, I should have guessed that :)

I don't know this code, and am not too familiar with how it works in articles, but the content still seems useable. I see the inconsistency but I am not 100% sure why it's a problem to the reading experience. It looks almost like an intended feature to me - adapting to the available space?

Normally the packed mode is supposed to adapt to the available space (up to 1.5X the default height), but if you set an explicit height, it's supposed to restrict it. I concede it's not a major issue for the reading experience, but in principle we're supposed to render the article content as specified by the editors. But I suppose that might be more idealistic than practical.

@Kudpung - If NPP can't clear all new articles within 90 days, I would definitely consider that bankrupt. Despite the number of new articles per day steadily declining over the years, the length of the unpatrolled backlog has only crept longer and longer. It looks like the current backlog stretches at least to January (disregarding converted redirects, moves, undeletions, etc.). What's to prevent the backlog from growing further than 365 days? The idea that it could take a year for a new article on Wikipedia to become truly "live" is disheartening. Sure, it might discourage a few spammers, but it will also surely discourage a large number of good faith contributors. As a long-time leader in the Wikipedia community, I'm sure you understand that and appreciate the implications. And as admirable as your efforts to instill rigor and quality control into NPP have been, it seems apparent that bigger changes are needed than technical band-aids like this. Looking through the older unpatrolled pages, I'm struck by the fact that nearly all of them have actually been reviewed by other editors and cleaned-up or tagged for problems. It's unfortunate that the patrolling process has become largely divorced from this organic decentralized reviewing process. Have you considered ways that these processes could be brought back together? As the failure of Citizendium and similar projects shows us, too much rigor and control kills the power of crowd-sourcing.

@TheresNoTime, @Kudpung - One of the main reasons that a 90 day limit was imposed was to limit the potential for the noindex template feature to be abused. (See lengthy discussion here.) That issue needs to be addressed prior to any changes to the limit. My personal opinion is that the security risk outweighs the risk of non-patrolled articles being indexed by Google (especially since truly problematic new articles such as vandalism or attack pages are typically deleted within a few days of their creation).

@Jdlrobson - I'm wondering if this bug warrants some attention. It affects the display of article content (possibly in all skins) and has been live for 2 months now. I know I'm not helping anything by complaining about it, but I'm surprised it hasn't been triaged yet.

This seems to sometimes affect other skins as well. See, for example:
https://en.wikipedia.org/wiki/Tutelina_harti?safemode=1&useskin=minerva
https://en.wikipedia.org/wiki/Tutelina_harti?safemode=1&useskin=vector
The images all initially load at the correct size (height 150), but then some of them are dynamically resized to a larger size, sometimes reflowing the page. If you resize the window, the images randomly change sizes as you are resizing, leading me to believe that this bug is likely related to responsive skin code.

I have confirmed this bug on English Wikipedia in both Chrome and Safari. As it affects the presentation of article content, it should be considered high priority.

What I would like to see is a very small speaker icon, not a play icon (which is ambiguous in this context), which when clicked, opens a modal or floating player (which includes a link to the file page). So something very similar to what you see in the first sentence of https://en.wikipedia.org/wiki/France, but opening a player instead of linking directly to the audio.

In T248418#7804998, @Ladsgroup wrote:

With the recent changes, this seems to be addressed mostly. To see the difference, simply turn on videojs in ruwiki and go to https://ru.wikipedia.org/wiki/%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:IPA_chart/table_pulmonic_consonants_with_audio.

Isn't it what you're imagining?

In T248418#7719073, @Ladsgroup wrote:

I understand. I feel this is a specific usecase of audio players. I looked how enwiki handles it and they link to the audio file instead (which is not great either). I feel for such cases we need to have a specific tool/code built to handle (whether in TMH or a gadget on wiki based on videojs). Trying to force the general audio player to do this (while it's a valid usecase) seems a bit off to me. Once that's done, we can also try to make enwiki and other Wikipedia languages to adapt this as well. Does that make sense?

An average Wikipedia reader is not going to have any idea what a tiny Commons logo means, but they will have some idea what the information icon is for, even if they don't expect it to take them to Commons. Either way, something like T258585 seems like a better solution in the long term.

Is this still a valid feature request? The main problem identified in the description (that some articles are linked to in Wikidata via redirects) doesn't seem to actually be a problem, as this is explicitly allowed on Wikidata, and desirable in many situations. If the feature request is just to remove unintentional links via redirects, that should be clarified in the title and description.

In T27619#3970962, @Tgr wrote:

Also 1 and I are in the same equivalence set but l is not. Those two sets should probably be merged.

Reopening as the list is again out of date. See also T280829.

In T132308#7016285, @DavidEppstein wrote:

It is the clear and explicit consensus of en.wiki editors not to allow YYYY-MM dates. Not in what is shown to readers, but also not in the source code, and not in the allowed parameters of citation templates. So whether you think YYYY-MM is better or not is irrelevant: if Citoid did this on en.wiki it would be in error and in violation of the local consensus, and should not be used.

@Izno - I'm not arguing against Citoid doing sanitation of the date. I just think the Citoid service should sanitize it to YYYY-MM, not YYYY-MM-XX for three reasons:

• EDTF is too new and I don't know a single browser that supports it yet (via JS).
• All 20 versions of RefToolbar handle YYYY-MM fine. YYYY-MM-XX breaks them.
• As stjn mentioned, the #time parser function also doesn't support YYYY-MM-XX (although I'm not sure what that impacts).

While I understand that the idea of fixing the problem from the VisualEditor side (either with '-XX' or full internationalization) may feel like throwing a request into a black hole, I'm pretty confident that @Mvolz could handle it, and I'm curious to get her opinion on that idea.

@Mvolz - For the short term, what do you think about moving the '-XX' addition from the Citoid service to the Citoid extension (i.e. VisualEditor)? Otherwise, we need to fix RefToolbar on all the wikis ASAP per https://en.wikipedia.org/w/index.php?search=%22undefined+NaN%22&title=Special%3ASearch&go=Go&ns0=1 (which I can't do since I don't have permissions).

In T132308#7015707, @Izno wrote:

In T132308#7015539, @kaldari wrote:

• Have Citoid return all dates in regular ISO 8601 format, e.g. 2020-12 for December 2020.

The reasons we have issue with it on en.WP are well-founded.

@Izno - As I mentioned above, the Citoid service never interacts directly with English Wikipedia, so that's not a reason for Citoid to not use 2020-12. Accommodation of CS1 (and any potential localization) should happen at the VisualEditor/RefToolbar level, not at the service level.

In T132308#7015721, @Whatamidoing-WMF wrote:

On Kaldari's suggestion to substitute a localized date, I think that harms translation efforts. It might be nice to see 2021. április 19. in the wikitext for your article, but it is not nice to have to turn that into 19 April 2021 or 19 avril 2021 or 2021年4月19日 later.

I wonder whether this is as big of a problem as it seems to me personally. I checked a dozen pages in https://en.wikipedia.org/wiki/Special:RandomInCategory/CS1_errors:_dates and found none of these. There were several of the MM/DD/YYYY format, but nothing that looked like YYYY-MM.

I... guess? That's like saying Wikipedia doesn't have a white background: it doesn't (pretty sure it's not #fff but I've haven't checked lately), but no-one cares because the end effect is that some systems mostly-powered by Citoid do. Either Citoid does the work or the other systems do.

@stjn - Sorry, that makes sense!

In T132308#6985062, @stjn wrote:

JFYI: MediaWiki parser function #time does not support 2020-03-XX format (and would return Invalid time error from it). If any template uses it for formatting time in citations, they would have to remove the -XX manually (in template or by hand) to get it to work.

@Mvolz - Also here is my opinion on what the correct solution to the original problem is:

• Have Citoid return all dates in regular ISO 8601 format, e.g. 2020-12 for December 2020.
• Have VisualEditor convert the date into a standard JavaScript date object, e.g. new Date('2020-12'), which unlike CS1 does adhere to ISO 8601 AFAICT.
• Have VisualEditor convert the JavaScript date object into a localized date for that wiki (which should be relatively easy since it has access to all the local MediaWiki JavaScript functions).

I'm not sure why everyone in this Phabricator discussion is thinking that Citoid interacts directly with CS1 as that isn't true.

I'll try to fix the RefToolbar code (for the Wikitext 2010 editor) later today...

Note that Source Han Sans is licensed under the SIL Open Font License.

This task seems to be getting more complex by the day. I wonder if it might be better to just keep it simple and disable the download button for disambiguation pages, as that case is unambiguously needed. This could be done with the existing __DISAMBIG__ magic word via a hook handler in the Disambiguator extension. I would hate to see a solution that creates a lot more curation work for Wikisource, as en.wikisource (at least) already has lots of curation backlogs. Just some thoughts to consider.

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/602422/ still seems like a product decision by @Lydia_Pintscher and or @Samantha_Alipio_WMDE that needs to happen here.

In that case, would you mind asking one of them to respond here or at T54564? They do not seem to be responsive to Phabricator pings.

Looking at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/602422 this changes all input of site title to NOT be normalized.
This will probably lead to a large number of sitelinks being created as redirects, rather than just for the cases discussed here and in T54564 etc.

That is correct.

Briefly looking at T235420#5932084 it sounds like this could have a solution that doesn't change all sitelink title input.
This comment suggests that the issue is that badges can not be created on sitelinks that are redirects.
Is that functionality alone enough to meet the requirements here?
This ticket is after all about "Create wikidata badges to indicate when sitelinks point to Wikipedia redirect pages", not "do not use canonical pages names (including following redirects) when sitelinks are created"

Either solution is fine with me, but just ignoring everyone isn't a good solution. The Wikidata community clearly favors allowing redirects as sitelinks and has been doing it via a workaround for a long time now. There's no good reason (that I've heard) to make it difficult.

If there are no objections within the next two weeks, I'm planning on +2ing https://gerrit.wikimedia.org/r/602412 and https://gerrit.wikimedia.org/r/602422.

Oops, my CSS is missing a space!

Observations by the end of November 2020
After turning off IP editing on ptwiki, we saw:

• an increase in active registered editors
• an increase in new accounts
• an decrease in total edits
• an decrease in reverts
• an decrease in non-reverted edits
• an decrease in blocks

However, the ORES model is known for being biased against IP editors.

@jwang - This seems like an extremely important detail. Can you elaborate on it? I skimmed through the paper you cited, but didn't see anything about it.

In T111735#6709412, @Aklapper wrote:

In T111735#6708782, @kaldari wrote:

Maybe the real problem here is just that the string in German is way too long.

I'd say the underlying problem are design decisions or implementations which either ignore or make strange assumptions about human languages and/or character widths. See also https://www.w3.org/International/articles/article-text-size.en

I changed it to "Dankeschön senden (für andere sichtbar)?" which is 19 characters shorter.

Maybe the real problem here is just that the string in German is way too long.

@Addshore - Both Amir and myself have tried to ping @Lydia_Pintscher by Phabricator and email several times over the last six months to see if she had any remaining objections to merging https://gerrit.wikimedia.org/r/602412 and https://gerrit.wikimedia.org/r/602422. Neither of us have heard back, so I'm going to assume that silence means consent in this context. Unless you know something that we don't, it seems like we should move ahead with these patches, as there is community consensus in favor of this approach. (See RFC and Wishlist proposal.) As I mentioned above, it seems like Lydia's previous objections have been resolved by the redirect badge and templates like {{Wikidata redirect}}. What do you think?

@matthiasmullie - Thanks for the thorough investigation! Yeah, it sounds like we should revisit this once it is decided how MediaSearch will be utilized on Commons. Depending on how that goes, it may make sense to just drop the depicts auto-suggestions.

@matthiasmullie - Which code repo actually controls this feature? Is it a hook in WikibaseMediaInfo or something implemented directly in CirrusSearch or something else?

Fixed. You can see the new version of the button in action at https://test.wikipedia.org/wiki/User:Kaldari.

A new test using Test OCR document 2.jpg

''Character Errors" means errors other than not detecting diacritics or curly quotes.

@Samwilson @aezell - Now that we have Tesseract 4.1.1 on Toolforge, I went back and tested with it. Interestingly, the accuracy was greatly improved by specifying the languages to apply (even for the English part), suggesting to me that Tesseract doesn't have good language detection (a problem that merlijn.wajer at the Internet Archive is apparently working on).

''Character Errors" means errors other than not detecting diacritics or curly quotes.
Test file: Test OCR document.jpg

For future reference, here are some ways to check if pages are disambiguation pages on save...

@Xover - Have you tried it with a newly uploaded file? That should let us know if it's a caching issue or just not working at all.

I think we should push out a MediaWiki-wide fix for this ASAP. TagItemWidget is prominently used in the Preferences interface, the Search interface, in ContentTranslation, UploadWizard, etc. Once this hits Wikipedia, a lot of people are going to notice.

Rather, I think the focus on the IP information is a bit too short-term and is a distraction from the issue that really we just have very bad counter-vandalism tooling as soon as someone signs up. This is a problem today as well. I think it's worth focussing on that and exploring more the space of how we can empower patrollers and admins to do more with less.

@Krinkle - That's exactly what the Anti-Harassment Tools team is working on. You can read more about it at https://meta.wikimedia.org/wiki/IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation#Tools and https://meta.wikimedia.org/wiki/IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation/Improving_tools.

Instead of a cloak flag what if it was just a new user right (e.g. hide-ips) that could be assigned to any user group, like extended confirmed users? That way each wiki could tailor it to their specific anti-vandalism needs and capacities.

I've updated the Developers/Maintainers list.