also related T207038

assistive technology building on top of font size based zooming, although not related, similar things like T204807 comes to my mind

@MarcoAurelio this task can certainly be closed out now.

The border should not be removed as it breaks displays of tables such as https://en.m.wikipedia.org/wiki/Help:Sorting#Numerical_sorting_problems

I've recently run into the question of how to compile templates for unit-tests (for T206226 ). In a Node environment such as node-qunit, we have to import the templates somehow, which led me to discover the mustache-loader for webpack (which uses Hogan under the hood). Have we considered using a loader like this for templates?

An update (I love to nerd out on this stuff). We're not the only ones to run into this problem. There are long-standing discussions between the relation of schema.org and Wikidata. Reading through this https://www.wikidata.org/wiki/Wikidata:Schema.org led me to this monster GitHub issue, https://github.com/schemaorg/schemaorg/issues/280 where I noticed the use of equivalentClass property. Turns out, for many entities, the equivalentClass property exists and actually points to a schema.org entity, see https://www.wikidata.org/wiki/Q5398426 . I think where that property exists, we could so something like "get instanceof, and then get equivalentClass of that instanceof", and that might give us the valid schema.org @type for that entity.

@Niedzielski @type is tricky. The @context key refers to the vocabulary used to define the structured data. The problem is that http://schema.org and http://wikidata.org are different vocabularies, so a @type defined by Wikidata may be different than one defined by schema.org. Where schema.org defined "TVSeries", Wikidata defines "Q5398426" (television series). I don't think many search-engines recognize the http://wikidata.org vocabulary, so "@context": "http://wikidata.org", is invalid. Omitting the @context key does validate the markup, but I'm not sure there's much value without it.

@Jdlrobson well I would hate to say that something is impossible.

I've run the pdf-renderer again, overflown it with lots of request, left it on for an hour, intermittently killed the main chromium processes, killed the child processes, disconnected and reconnected the network, and I'm unable to reproduce my previous bug. Good job!

Tracking down where the headerHeight actually comes from, it looks like it's just statically defined as 3.35em.

• increase utils code coverage

I agree with @Jdlrobson that the disabled button is not useless, but I think it could be made much more useful, if it did, as @Niedzielski suggests, it acted as some sort of CTA to lead users to add a translation. That flow however, needs a lot of design consideration. For one, it would be confusing if the same button revealed translations in one state, and led you down a path to add translations in another state.

^ just to elaborate on my thoughts there...
My feeling was that the items inside the header should define its height, and that a statically defined height might break when the items inside are resized or changed.
Looking at the code though, I noticed the header is defined with display: table-cell. This property actually ensures that the height is never smaller than the contents inside it (see here for example video) so, that's pretty cool.

The Share API in an interesting feature to consider. It looks like it only has Android Chrome support, but it's a widely understood feature of mobile apps, and the native Android and iOS Wikipedia apps have it as well.

we could also define a width + a max-width, let's say

max-width: 993.3px;
width: 90%;
margin-left: auto;
margin-right: auto;

That way the content will be never be bigger than 993.3px, and on smaller screens it'll be 90% width.

We could do smooth scrolling with one line of CSS:

scroll-behavior: smooth;

If we're OK with it working only in Firefox, Chrome, and Chrome for Android (right now).

I've tested this on my local with Siege, and it appears to kill the chromium instances correctly, and the queue management seems to be working well.

Out of curiosity, I've tried to debug this behaviour myself.
On my local machine, I've tested on Android 7 / Chrome 58, Chrome desktop, and latest Safari desktop, and seems to work there.

@dbarratt good points. As you mention, there is a distinction between interface translations and content translations.

@Tbayer fortunately, the event-logging actually registers the severity correctly, phew!

Yup, I can reproduce this in Safari on a Mac.

reviewed this today with @Tbayer and agreed that this can be closed out since the error was not occurring on staging anymore.

After reviewing with @Tbayer today, we noticed one error regarding the multiple issues template.
On the page Politics_of_Cyprus, which has a multiple issues template, the modalClosed event sends

Closing this out since in late 2017 we created a "deploy" repo for the Portals project, which contains only the build assets. The builds are generated and deployed weekly. This ensures that each commit represents a new deploy, so rolling back just means reverting the last commit in that repo. More details in T180777 .

The issue here was that the page was not rendering the english label for the word "articles". It did appear in other languages, which is probably why I didn't notice this earlier. :/
The patch above should fix the issue.

In addition to @Jdlrobson's patch, @Niedzielski had a similar WIP here
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Popups/+/454566/

great job guys!

If we use a transpiler like Babel to convert ES6 to ES5 syntax, that would guarantee that the compiled code would be ES5 compatible wouldn't it?