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.

I approve as well in case it matters ;)

Note that this has been made into a proposal at the Community Wishlist Survey: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Wikidata/Link_Wikipedia_redirects_to_Wikidata_items

We’ve actually wanted to do this from the start, but have not pursued this because of the dual licensing.

The licensing is not an issue for any data that would be automatically filled in by UploadWizard. None of that data is copyrightable. Bots have been adding this data from the template content since at least January 2020 with no controversy.

In T95553#3695730, @thiemowmde wrote:

The message for this is https://translatewiki.net/wiki/MediaWiki:Wikibase-time-precision-century/en. We could remove the dot if this makes the situation better.

@Iniquity - If you expect anyone to work on this bug, you need to provide some specifics. When you say "The player's launch buttons are slightly not adapted to the accessibility recommendations" what are you actually talking about specifically?

Note that this is a cosmetic issue as the buttons are still clickable and functional.

@WDoranWMF @AMooney - This was being worked on by a volunteer a year ago, but never made it through code review and is now stalled. At the very least we are going to need CheckUser to use the actor table in order to move forward with IP masking. Is this something that Core Platform could pick up and carry across the finish line?

@kchapman - This was being worked on by a volunteer a year ago, but never made it through code review and is now stalled. At the very least we are going to need CheckUser to use the actor table in order to move forward with IP masking. Is this something that Core Platform could pick up and carry across the finish line?

I would strongly favor full extension of externalLinks.json via a page like Mediawiki:KartographerExternalLinks.js. There's nothing wrong with doing this, especially now that the MediaWiki namespace is locked-down to a very small number of editors. Other MediaWiki extensions and services allow similar on-wiki configuration (e.g. WikiLove, PageCuration, Citoid, etc.).

@sdkim - Would love to learn more about this task.

Note that the LandingCheck extension only does its own geolocation lookup as a fallback (if Geo.country was not passed to it within the link).

@Xover - What would be the effect of just deleting all the caches? Tesseract has been upgraded since most of those caches were generated anyway.

Just to give some context, AntiSpoof has two main use cases (which don't always align perfectly well):

Yes, since this feature has already been implemented and deployed (although not to the bigger Wikipedias yet), I think we can close the RFC. See https://meta.wikimedia.org/wiki/Community_Tech/Watchlist_Expiry and Expiring-Watchlist-Items for further updates.

@Ammarpad - Ah, that makes sense! Thanks for clearing up the mystery!

I wonder why you are phrasing this as a response to what I wrote? Personally I agree that increasing the length of the column is a bad idea.

I think we are misunderstanding each other. I was saying that using a hash would bloat the table as we would be storing 32 bytes per row rather than 6-16 bytes (in practice). Changing the column to varbinary(50) would have no effect on the size of the table or keys (assuming that none of our wikis have any plans to switch to collations with extra long names).

@ssastry - Recently I discovered that the reason that pronunciation links on Wikipedia are backwards (the speaker icon links to the file page, while the text links to the actual audio) is because of this 12 year old parser bug. It looks like the bug got integrated into Parsoid as well in order to match the Parser output. The purpose of the Media pseudo-namespace is to easily allow linking to files directly, but for some reason this was never implemented correctly for the link parameter in File links. @Bawolff came tantalizingly close to fixing this seven years ago, but sadly it was never followed up on. Just wanted to bring it to your attention so it could finally be properly triaged.