Fri, Jul 21
I'm not sure I understand the problem here and can only suspect this is a confusion about how the targets system works. I commented on T170668 that the wikibase.mobile module only defines a target of mobile - the default is desktop or null (which will default to desktop)
Not sure I understand what's happening here.
sets a target of 'mobile'
MinervaNeue is now using this module. Here's some notes from an exchange on the previous review with @Krinkle
cc @MaxSem apparently this fix didn't make it into wmf10....
Provided we use commonjs (just like we support that sortof in RL) I'm agnostic to the tool we'd use - I just suggested webpack as I use it, know it and love it, but any type of bundler would be great and I think it would be easy to migrate as we leant on it more.
@Krinkle I guess a static object could be a 4th argument if necessary, but right now that seems like over-engineering. Are we going to need this? The third argument makes it convenient to build simple classes.
I've moved this to tracking for the time being as I don't think it's required if we are using the lead paragraph of text summaries which is my current plan in the new endpoint.
I suggest we do this when the new endpoint is in place - that way we can decide if we want to add a URL for the new endpoint to the warning messages
Looks like etsy phan is running on RelatedArticles when I do check experimental.
Do we want to add a phan file there or do we want to remove this from the experimental build? It confused me while working on https://gerrit.wikimedia.org/r/#/c/347116/
That's what we have... Before MobileFrontend runs its MobileFormatter the HTML would be
<h2>Heading<h2> Section text goes here
We wrap any content between headings with a div. It's that simple.
It should be part of https://gerrit.wikimedia.org/r/#/c/366173/6/print.less which is incomplete (I've updated description).... I'm waiting for a review of it before continuing. Don't worry we'll make sure we've done all the parts during our sign off phase.
(this is unplanned - see email "Sampling rate for page previews too low" and blocked since no deployments till Monday).
Good job! :)
(To be clear I'm fine with using it here now the code has been written, but I think there is a larger conversation to be had on a mailing list about adopting it for all our projects....)
(Don't want to confuse our workflow by adding this to Kanban board.)
I'd appreciate a review/merge on https://gerrit.wikimedia.org/r/366173. That's blocking me from doing the other parts.
Patches are in task description.
Don't use UBN unless something serious is broken. Lots of people are specifically watching Phabricator for UBN. This is not appropriate usage.
MobileFrontend markup currently looks like this (sorry if I wasn't clear):
<h2>Heading<h2> <div>Section text goes here</div>
This is intentional and how it works.
https://www.mediawiki.org/wiki/Extension:PageImages#Image_choice explains how an image is chosen. The image in the lead section of https://ca.wikipedia.org/wiki/Nova_Creu_Alta is not suitable for the type of display the usage of this is intended for.
Good catch @Vachovec1!
Thu, Jul 20
The main problem to be aware:
- is that the <references /> tag can be put in any section by an editor. A section could also have other HTML/content - so omitting an entire section and relying on references overlays is not the best idea
- When printing it should be possible to see references (although this is possibly only a problem for web)
- A page can have multiple reference groups displayed in different locations. I can't find any examples right now but usually anything with a "Notes" section probably also has a "References" section
- references can be nested. e.g. a reference might appear inside a reference (that is only shown in the references list)
In web, the most important use case we have is section collapsing. The current implementations suggest that the heading would be inside the section tag however in mobile web we put it outside.
This is happening more and more often...
Currently, only NotificationButton and MainMenu are documented.
That's because they are the only classes provided by MinervaNeue. All other code are private functions.
As @Nirzar says we shouldn't set false as the default as this helps more wikis than it breaks, however if someone has the time to set false for all the wikis we don't have logos for (and enable the ones we do) in that table that would be helpful. It's time consuming and we have lots of other ongoing activities so this is not of the highest priority for us just yet so we've been relying on where we can get the help (several wikis have already been proactive and asked or made their own logos).
Most of the service is now built with the exception of...
(branding is being done in T169826)
You're right. Turns out the MCS was sending ppprop instead of pageprops. T151241 is to be deployed but will make this possible.
Looks like is best fixed on wiki for the time being... ? Or should we merge into T131896 ?
MinervaNeue has a config flag $wgMinervaEnableSiteNotice - it defaults to false.
Thanks Sam! Olga will sign off.
looks like a page is not created properly, ReadMore-is-present-in-Minerva.png
I've explained this before on another bug. You can see from the screenshot that the "Related Articles 1" page has not been created. This should be created by the test run (L40 of https://gerrit.wikimedia.org/r/#/c/347116/32/tests/selenium/support/index.js ) - the fact it isn't suggests there is something wrong with the article creation API.
Thanks I've setup T171181 to get this fixed.
@HairyDude it should be yes. Works for me too. Wmf9 went live on Monday.