Leaflet 1.1.0 is out now btw.

Revived and fixed testcase.

It's also listed at Geohack, so I don't consider this a problem really:
https://en.wikipedia.org/wiki/Template:GeoTemplate

The label has overflow-x set. This apparently causes overflow y to change from visible to 'auto'.
https://stackoverflow.com/questions/6421966/css-overflow-x-visible-and-overflow-y-hidden-causing-scrollbar-issue/6433475#6433475

I didn't get that one, but i did get
[Error] Failed to load resource: the server responded with a status of 400 (HTTP/2.0 400) (https://maps.wikimedia.org/img/osm-intl,14,38.922679,-77.206057,300x300.png?domain=www.mediawiki.org&title=User%3ATgr+%28WMF%29%2Ftest2&groups=_1a41aece84fcd54be5cd94fff86557a95d40fc92, line 0)

Likely this was layer being null:

layer = map.addGeoJSONLayer( group.id, group.getGeoJSON(), layerOptions );
layer.dataGroup = group;

inside fetchExternalGroups()

Last revert gave as reasons: "map routes still does not work and nearby places works badly. Give the user a choice."

I'm not so sure about this. I've played around with this as well for a bit, and I have to say, I think having to open another tab/window for this is perfectly fine. Having an 80% modal is a very complicated interaction to solve this problem, we have to think of all the users.

FYI on MacOS Apple has something called network link conditioner available, which also allows you to simulate dropped packets and dns latency.

@Pigsonthewing Because english doesn't have language variants. See https://zh.wikipedia.org/wiki/蒂姆·伯纳斯-李

Cause found: This is due to positionLabel() changing the padding.

@Jdlrobson why does it need a table ? Also why is this not using infobox class ?

See also: https://gerrit.wikimedia.org/r/#/c/304044/

Ace hasn't been updated in our repo's for a while, and thus the syntax libraries haven't either.

Expecting new users to go to a different special page (or even a different wiki) to set global preferences seems a step too complicated. I

Just figured this out: Safari/Chrome do not have beforeprint/afterprint, because they say the same can be achieved with:

I'd use onbeforeprint JS hook to modify the print styles on the fly (As I do here). This should work for most major browsers, though admittedly I never tested IE)

@MarkTraceur you'd need a very specific maintenance script. Dispenser was detecting this, by string matching on the the actual metadata field. If you purge all webm files, you'll requeue a lot of very high resolution media files for transcoding and that is not very desirable.

We should check the effects on older browsers and the worst laptop with throttled connection that we can find. I'm pretty sure the Obama article will become terrible at some point in that situation. This ticket should focus on how to make that 'terrible' experience as best as it can be. For instance by popping up a waiting spinner after half a second, or by automatically disabling syntax highlighting and popping up a bubble etc...

I too use preview a LOT, especially icw source editing. So much so, that I even made a gadget https://en.wikipedia.org/wiki/User:TheDJ/Actual_Live_Preview that has the edit surface and the preview side by side.

I made a ping to enwikibooks already: https://en.wikibooks.org/wiki/Wikibooks:Reading_room/Proposals#Cookbook_and_WikiJunior_namespaces_in_search_results

FYI, this format is rather widespread. We also had to deal with this problem when we added the XML validation to the upload process way back then.
If I remember correctly, the xml declaration (as this is called), is optional in xml 1.0. If that is correct, then the thumbor check is making assumptions that are not necessarily valid.

So, when mw.loader.getState( 'ext.wikiEditor') is loaded, you immediately initialise right ?
I think you are dropping into the timing hole between loading of ext.WikiEditor and the actual toolbar module executing... This whole wikiEditor loading is a disaster for sure :(

FYI, I've just changed {{Reflist}} to also use the responsive columns, whenever the user had not specified an explicit width.

FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.
Next step for en.wp will be to enables responsive by default for a plain <references> element

Another person requesting about audio captcha's
https://en.wikipedia.org/w/index.php?title=Wikipedia:Teahouse&oldid=790035476#Audio_alternative_for_CAPTCHA

@Cameron11598 There is no one currently assigned to this, so no one is taking it upon him to fix this at this moment. It's also not something that any team at the foundation is responsible for, so it's not likely to be prioritized from that end.

which browser version etc ?

i'm pretty sure there is another ticket on this exact topic, but i cannot find it.

I suspect the same problem might occur with blocked users btw. since we have T13443: Auto-noindex user/user talk pages for blocked users..

BTW. If we ever want this feature to return, we could maybe do it client side with a service worker. I know @Jdlrobson looked at that for lazy loaded images at some point, that's basically the same usecase of course. Or we can just make it a client side option that influences the current JS lazy loader.

It's weird, I really had expected to see a big drop somewhere due to more JS prints.... I'm amazed that it's not there. I can't explain it.

Testable with:

This mime-type thing keeps bothering me. I was thinking the following:

1. make mime_type the actual 'frontend' desired mimetype of a specific file.
2. add a new column filehandler_id
3. add filehandler_id's to our FileHandlers
4. add a scan method to file handlers to detect magic bytes, return true or false depending on if this handler can handle this file.
5. when ingesting files, scan with each file handler to find the right file handler
6. add a 'getMimeType' to file handlers to return the correct mime type for a file.
7. register the file handler_id into the database for fast instantiation of the file handler, store the mime-type alias in the database for fast serving of the correct mime_type.

Note that my patch always divides infobox columns equally. I'm not entirely sure if that is a problem anywhere, so I'd definitely suggest to test it more widely, before rolling it out to production.

It is due to https://commons.wikimedia.org/w/index.php?title=TimedText:Editing_basics_-_Uploading_and_adding_images.webm.en.&action=history

i ran into this problem today as well. A 3 column table had the last column at 50%, but due to both other columns claiming 100%, they got ALL the space, whereas the rest got nothing.

The mobile website doesn't have an edit screen, it has an edit overlay onto a normal page. Since .cnotice-button has a z-index: 999; this is logical.

@Liuxinyu970226 This ticket isn't about MobileFrontend. Let's not start bringing that into this.

@DannyH considering what happened in T146675: Convert more wikis to numerical sorting, can this ticket be closed, or is there still more to do/planned ?

@PerfektesChaos and @Bmueller Where is this at btw ? We're half a year on since the last check in.

@Strainu, @Giku while changing this... would they also like numerical sorting ? T146675: Convert more wikis to numerical sorting

Be careful to exempt audio/video files etc by default. They have some serious potential performance effects when purged, and are treated a bit more carefully in generally.

We can overload with https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/String/localeCompare on platforms where available.

There is activeLink however...
https://github.com/search?q=org%3Awikimedia+%24activeLink&type=Code

I was looking into that piece of JS that's being quoted a couple of times here. It seems that this problem still exists.

In T24256#3368695, @JKatzWMF wrote:

I also thought it would be trivial to fix. Judging from this ticket it took almost 3 years!

Ha, I wish: "TheDJ created this task. Jan 25 2010, 2:09 AM"

BTW. it conflicts in two contexts. The history page was also using the 'v' accesskey for the "compare selected revisions". Fewer people know about that one and probably I was the only one who ever complained about that conflict, but it is still a conflict.

@Deskana you might want to read up on https://en.wikipedia.org/wiki/Wikipedia:Keyboard_shortcuts#Using_access_keys

Hmm, my change has some downsides that I did not considered.
https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=786608865#Some_sort_of_glitch_in_mobile_view

Yeah seems pretty clear to me:
Every skin has #toc and #footer.. Except minerva. Using those IDs is a common method to navigate to the top and/or end of a page. We should either provide a different way for Minerva to satisfy that need, or just add the IDs.

For anyone who has made use of scratch codes and succeeded logging in: Please remember that because of T131788: Users should be notified when only two scratch tokens are left and T150601: Add option to generate new set of scratch codes it's not yet possible to get a new set of scratch codes and it won't tell you when you are running out :/

I didn't take a copy of the scratch codes.

@Tbayer partly on 23 and 24th for the smaller stuff, and the big wikipedias on june 1st it seems: https://www.mediawiki.org/wiki/MediaWiki_1.30/Roadmap (1.30.0-wmf.2)