This is postponed until demo is over and we reprioritize tasks based on the roadmap.

Thanks @Nirzar !

@Volker_E on Mobile ~1% of traffic is from Windows OS (Windows Phone), so it seems like Segoe could be useful there.

@Niedzielski would you mind closing this task and moving the pending patches under T173317 or subtasks there?

@Nirzar do you think you could provide the (special)page spec for us to implement?

Yeah it is a complicated topic. Besides the style in the codebases, there are also styles in "content", the common.css, or the skin css (Vector.css or Minerva.css), and soon there will be styles in templates...

In T173821#3590409, @Fjalapeno wrote:

[...]

So I'm thinking of how much we can offload to the PCS here… going off what you are saying, here is my first idea for the "common" styles:

1. We manually decide what the "common" styles are (we can start with what is bundled in the apps and modify that based on your current work)

Sent a patch to it ^

In any case, a change of route should be super easy :D

Sure! What other dev pages would be useful?

@Nirzar Should we update it in the base library?

1. Tech notes

1. Tech details

I'm declining this until we need to implement search. We have more important things on our plates for now.

Thanks for the answer @Peter !

Staging seems to be stuck because of npm modifying the lock file.

Going to review the staging hook and the docs next.

Ping Performance-Team, maybe you have looked into this already?

I'll be adding some more detailed subtasks like creating the Layout or Header component after we have a sync with Design's @Nirzar

In T173821#3580757, @Fjalapeno wrote:

Can you clarify why this doesn't work with an API driven web app? (I assumed this would work with the native apps just fine, so maybe this will be a problem with them, too)

In mobile web, neither navboxes nor vertical-navboxes are shown, because of the size they have and their usage of tables, making them unsuitable for mobile viewport sizes.

Needs technical sign off.

In T175064#3585216, @Jdlrobson wrote:

...it theoretically could show up elsewhere.

We are these days meeting and discussing the objectives so that we can come up with a proper scope and deployment strategy.

Declined until we need this.

This is going to be an ongoing Epic

Re-open if tackling the previous items.

For an initial setup, this is done. There are a few things we could do, but we can tackle them once they hurt:

I'm considering this done for now. There are a few things that could be improved, but we'll tackle them when they hurt. (cron.log rotation/cleanup, server auto restart, clustering, auto start on reboot).

Thanks for the summary @Jdlrobson.

Indeed. The reason is that in debug the file is loaded individually:

Excellent, just verified on https://ca.wikipedia.org/wiki/Portada, all working well!

This seems to have been introduced here https://gerrit.wikimedia.org/r/#/c/373327/ where I upgraded a promise usage to the jQuery 3 version, as @TheDJ mentions. I incorrectly understood that it was available already and migrated the code. As specified in T124742: Upgrade to jQuery 3 we are just starting to roll it out, so the code should be using the old promise behavior that works on v2 and v3 until rollout is complete.

That is a good question indeed.

You can see it working here: http://marvin.wmflabs.org/

Needs tech signoff. Steps are on the description.

I don't think so sadly, and you are totally right.

We can migrate to common.js back but after we made the explicit move to ES modules that would suck.

Initial work of setting up repo and git hook to install/build/re-run on git pull done, see patch above, and https://marvin.wmflabs.org running the repo code now.

Apparently that patch was a NOOP. sourceType module will not honor the parser ecmaVersion and const and let will parse just fine... :( Which is normal, since let and const are valid JS tokens.

Indeed! Thanks!

I personally don't see a problem with conditionally loading tablet modules. Optimizing for the constrained mobile experience seems like the best idea, and there are certain devices that when rotating from portrait to landscape become tablet, so loading tablet modules on resize is a great idea. What we don't do right now that we should is disable the tablet enhancements when the screen is resized back to mobile again.

Thanks @hashar ! We're aware of those warnings, the fsevents one is optional depending on OS, the eslint one is being fixed on eslint-config-node-services but it works fine with eslint v4 which we use, and the last one is a config warning that is a NOOP that we need to fix.

In my opinion that isn't a big win and I wouldn't do it, but I'm not against it if others want to do it. If we do it, let's be sure that all the code base is consistent so that we can reliably grep for message or template usages.

Here's what I'm thinking: