This doesn't seem likely to be fixed because of T242855 (see also T211881)

For some reason, it works (not reproducible) in Internet Explorer 11.

Still reproducible in all three browsers (Firefox 79.0, Chrome 84.0.4147.105 and Internet Explorer 11).

With debug=on:

It's caused by the extension Google Translator https://addons.mozilla.org/fr/firefox/addon/google-translator-webextension/ though it was last updated on July 17, 2019 (not 2020).
Firefox (78.0.2) was last updated on July 9, 2020

It's caused by the extension Google Translator https://addons.mozilla.org/fr/firefox/addon/google-translator-webextension/

Indeed, I can't reproduce it with a new Firefox profile but I can in a private window.
It happens on every page.
There is one other user who reported a similar problem with Firefox: https://www.wikidata.org/wiki/Wikidata:Project_chat#Merge_gadget_with_not_functioning_for_me_in_Firefox_78

Great idea! Here's an example of change that ends up having the same size while actually adding characters: https://fr.wikipedia.org/w/index.php?title=Ha%C3%AFti&type=revision&diff=169953710&oldid=169807136

The new user script link is https://www.wikidata.org/wiki/Wikidata:Tools/Enhance_user_interface#overpass

I really can't say for sure. :/

✔️ https://commons.wikimedia.org/wiki/User:The_RedBurn/KartoEditor.js

This can be reproduced every time when pasting an image name. Once it doesn't reproduce anymore, just edit a different article.

Here's where http:// is used as default instead of both http:// and https://
https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/specials/SpecialLinkSearch.php$73

Thanks!
The fact that it's not documented on Mediawiki itself seems to mean that it's not the expected behavior, meaning that the documentation on :en was added to avoid unexpected results.

In T221438#5125041, @Aklapper wrote:

That's documented and probably expected behavior (if it still makes sense is another question). The page says:

The “http://” protocol specification is optional; any other protocol (“https://”, etc.) must be given explicitly.

In T213214#5020003, @ema wrote:

In T213214#5018951, @The_RedBurn wrote:

I did notice that shift + refresh seemed to fix it after some time, so that makes sense.

Can you still reproduce this, or can the task be closed?

That's great to hear!

In T213214#4870224, @CDanis wrote:

If anyone can manage to reproduce this consistently, even for a few minutes, capturing a Chrome NetLog using chrome://net-export would probably shed light on what is happening.

https://dev.chromium.org/for-testers/providing-network-details

Details on what is captured and how to use it are at https://www.chromium.org/developers/design-documents/network-stack/netlog

Thanks!

I can't even see the map on the Android app right now. Rather annoying since more and more articles now use mapframe.
So the mobile version is better than the Android app version.

Indeed, thanks @Agabi10 for the patch and @Jdforrester-WMF and @matmarex for the review!

In T167788#3390329, @thiemowmde wrote:

I'm afraid there is no way any parser can ever be sure what "9/7/2017" means. Even if we use your IP address or location (something we should never do because of privacy reasons), or the interface language from your preferences, it might still either mean MM/DD/YYYY or DD/MM/YYYY. The only thing we can (and want to) use is the date format from your personal preferences at https://www.wikidata.org/wiki/Special:Preferences#mw-prefsection-rendering. See https://gerrit.wikimedia.org/r/153211.

In T167788#4559199, @Izno wrote:

In T167788#4559189, @The_RedBurn wrote:

In T167788#4551700, @Izno wrote:

There are a few other countries in the same time zones...

Those time zones are defined by country, not by hour differential, so that's not a problem.

So far as I am aware, the system only cares about offset from UTC. So no, it is a problem.

In T167788#4551700, @Izno wrote:

There are a few other countries in the same time zones...

Based on https://en.wikipedia.org/wiki/Date_format_by_country, apart from two English speaking islands, the United States is the only country to interpret 07/09/2017 as MM/DD/YYYY.
So for languages other than English, DD/MM/YYYY seems to be the norm.

In :fr, we'd like to use TemplateData as parameters documentation to keep the documentation synchronized with TemplateData. There's already some styling in place (example), but these empty fields take space without adding anything useful.

Is there any way to get this straightforward patch reviewed and checked in? Maybe change the reviewer?

Can't we use this new implementation of Reference Tooltips to fix this bug and make it available to all wikis?
The old implementation is already used by default for everyone on the English Wikipedia, so it should have been tested enough by now.
If necessary, it could be made available as a beta feature in the beginning to make sure the new implementation works everywhere.

Is there any estimation about when it will be possible?
Shouldn't the status be stalled instead of declined if it will be possible in the future?

The offset is now much smaller with the new sidebar. However, I thought it would have fixed it.

I've sent an email about this problem to support@mywot.com with a link to this bug.

I just found out: it's the extension "WOT: Web of Trust"
https://addons.mozilla.org/firefox/addon/wot-safe-browsing-tool/
https://chrome.google.com/webstore/detail/wot-web-of-trust-website/bhmmomiinigofkjcapegjjndpbikblnp

From Twitter above:

• 10.1080/03014223.1975.9517878 (tandfonline.com)

The delay for this one is about 43 seconds.

Since there's "some other publishers" in the title, here are two examples of non working ones:

• 10.1152/ajpendo.00361.2010 (physiology.org)
• 10.1177/0883073809337162 (journals.sagepub.com)

While they fail on Wikipedia because of the 20 seconds timeout, they work on the REST API (https://www.mediawiki.org/api/rest_v1/#!/Citation/getCitation) after about 33 seconds for both.

Following T154524.

https://phabricator.wikimedia.org/diffusion/ETDA/browse/master/TemplateDataBlob.php;68b8c0b60eb6e439291ac2a1c0bbd212b7e18ca1$842

I don't know what you meant in T174771#3581686, there's no TemplateData for https://simple.wikipedia.beta.wmflabs.org/wiki/Template:Refbegin so of course it can't be reproduced with that template.

Like Yurik said in T147768#3080101, this has been fixed in Vega (2.6.5) since January 6.
What is preventing the update to Vega 2.6.5 (last 2.x version) (T174766)? Wouldn't it be both easier and preferable than a direct migration to Vega 3 (T165118)?

Why is this still open? Isn't the current version already 2.6.3?
https://phabricator.wikimedia.org/diffusion/EGRA/browse/master/lib/vega2/vega.js

Reproduced yesterday:

This is now working, as verified on live wikis and on https://en.wikipedia.org/api/rest_v1/#!/Citation/getCitation

There's experimental support as seen at Wikicite 2017: https://youtu.be/1pMHSghEM7A?t=25037

I can confirm that it works on https://simple.wikipedia.beta.wmflabs.org
Should this be marked as invalid or resolved?

Yes, exactly, and what I called "Visual diff" is the wikitext diff shown by the VisualEditor.