took care of watchstar.less, thanks @Niedzielski
Thu, Dec 6
Unfortunelty, the patch above doesn't only separate out functions into smaller pieces. It also (inadvertently) fixes the icon issues raised T202349. This fix includes modifying the way page-issue banners manipulate the DOM, which means the patch should go through thorough browser QA.
Wed, Dec 5
I’ve finally gotten around to looking over @Jdlrobson’s updated patch, but alas, I’ve found another bug, it breaks the overlay for multiple-issues templates. :(
Thu, Nov 29
Judging from this stackOverflow issue, this JS selenium implementation, and the GitHub issue below, it does seem that Selenium takes into account the height of an element to determine whether it is "shown".
Looking through the previous tasks, as well as the test itself, it seems like lots of stuff has been tried to fix this before. Not sure what would help, but one thing that I've identified is that the notification_area_element is the element is the selector .mw-notification-area. On the page, that element has a fixed position and a height of zero, so I'm not sure if selenium counts that as "visible".
Wed, Nov 28
Tue, Nov 27
Mon, Nov 26
I reverted this patch as soon as I became aware of this bug. Still have to investigate what error here was.
Wed, Nov 21
Just poking around the Views & Overlays, I discovered the View uses either props.className or this.className in _postInitialize() (View.js#220):
Oct 22 2018
Oct 16 2018
also related T207038
assistive technology building on top of font size based zooming, although not related, similar things like T204807 comes to my mind
Oct 15 2018
@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
Oct 11 2018
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, in Wikidata, 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.
Oct 10 2018
@Jdlrobson well I would hate to say that something is impossible.
Oct 9 2018
Oct 8 2018
Oct 4 2018
Oct 3 2018
Oct 2 2018
Oct 1 2018
Sep 28 2018
Sep 27 2018
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!
Sep 26 2018
Sep 24 2018
Tracking down where the headerHeight actually comes from, it looks like it's just statically defined as 3.35em.
- increase utils code coverage
Sep 20 2018
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.
Sep 19 2018
^ 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.
Sep 18 2018
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.
Sep 17 2018
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:
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.
Sep 13 2018
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.
Sep 12 2018
@dbarratt good points. As you mention, there is a distinction between interface translations and content translations.