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.

Working great, thanks!

I think users wouldn't try to partially-select for linking if [[apple]]s worked with VE.
And one half of fixing that would be to search for "Apple" for links suggestions if "Apples" isn't found.
If the user then selects "Apple" in the suggestions, the correct

A <br /> could be inserted when the user uses Shift + Enter (line break instead of change of paragraph).
This would be consistent with word processor software.

Support of parenthetical referencing (also known as Harvard referencing) would be good to have.
A nice way to do it would be to show the full citation below the partial citation.

See also T125222

Thanks, it works great!

Why is the og:site_name property reserved to pages recognized as "webpage"?
Couldn't it be tried on pages recognized as "blogPost", "videoRecording", "film" and maybe others?
Since this is stalled, it would fix websites such as bbc.com, youtube.com and imdb.com

Thank you, it already looks much better.
But it seems like a hack.

In T136286#2330836, @Danny_B wrote:

In T136286#2330763, @Krenair wrote:

Anyway I wonder if this might be https://bugzilla.mozilla.org/show_bug.cgi?id=361923
I downloaded both, and...
-rw-rw-r-- 1 alex alex 15086 Mar 14 18:08 wikinews.ico
-rw-rw-r-- 1 alex alex 2734 Mar 14 18:08 wikipedia.ico

The one I tested had 2,07 kB, so perhaps not...

You should be able to add it back by following the procedure in the link I've posted.
If not, at which point doesn't it work?

I see the default icon for wikinews but I can't seem to add the wikipedia search.

Here is how to do it: https://support.mozilla.org/en-US/kb/add-or-remove-search-engine-firefox#w_add-a-search-engine

You filed this under "Wikipedia-App". Which exact version of the mobile application on which Mobile platform are you using?