User talk:Jdlrobson

Jump to navigation Jump to search

About this board

Previous discussion was archived at User talk:Jdlrobson/Archive 1 on 2015-12-18.

difference not clear (?) between tags 'mobile edit' 'mobile web edit'

Wladek92 (talkcontribs)
mobile edit	Mobile edit	Edit made from mobile (web or app)	72,244 changes
mobile web edit	Mobile web edit	Edit made from mobile web site

Hi Jon , referring to Topic:Viy7jkhlv2w5x5s2 and apart of 'This is expected behaviour.' answer from Forestier I still do not understand the difference between the tags. The number of modifications being the same for both tags, they seem redundant. One says "Edit made from mobile web site" (a) that means I have used the 'Mobile version' on my desktop for my translations (and its true). Other says "Edit made from mobile (web or app)" which covers "Edit made from mobile web" (b), and "Edit made from mobile app)"(c). I understand (b) seems the same as (a) and I wonder what are the cases "Mobile edit" which ARE NOT "Mobile web edit" ? ...

Since I make translations using the web (Special:Translate), the translated text (that means the contents) is the same when viewed on a desktop or a tablette. If one decides to cancel all updates "Mobile edit" there is a risk my translations are lost. Isn't there a warning to write for translators against this situation ?


Christian FR (talk) 11:50, 21 March 2020 (UTC)

Jdlrobson (talkcontribs)

Mobile edit is also used on edits from mobile phone applications (not mobile domain) e.g. Android and iPhone.

Consider an edit with the following tags:

Tags: Mobile edit, Mobile app edit, Android app edit

Reply to "difference not clear (?) between tags 'mobile edit' 'mobile web edit'"

Hi Jon, Pagebanner and Women in Red.

Victuallers (talkcontribs)

We have 5-600 banners that we use each day on Twitter and now on our en:wiki talk page. We use some basic code to turn over to a new "Woman of the Day" each day. However our banners look no where near as good as the ones used on Wikivoyage and I'm wondering if it is possible/easy to use PageBanner on en:wiki?

Our woman of the day currently looks like this. Could this appear neater? We have run 150 editathons to date and your code would smarten us up a bit. Can you point us to how we can achieve this. ~~~~

Jdlrobson (talkcontribs)

I'm not sure if the There's no constraints in turning on Extension:WikidataPageBanner on enwiki for a certain namespace. To have it enabled it would need to follow the site request policy.

You could always enable it for the project or talk namespace, experiment with it and turn it off if you find it is not for you.

You can also experiment with it on this test wiki page: - please use a throwaway account if you decide to experiment and certainly don't use your Wikipedia password on any new account you create there!

Have fun!

Reply to "Hi Jon, Pagebanner and Women in Red."
MarcoAurelio (talkcontribs)

Hello Jon. Following our IRC conversation, I have declined the request to install Netlify on Wikimedia's GitHub organisation for MobileFrontend, MinervaNeue and PopUps. If however Netlify or any other GitHub App is needed over there again, please set it up and, in case you cannot approve it, please let me know to have them approved (I might need to check with RelEng though). Best regards.

Reply to "Netlify"

Wikisource centered images rendering left in mobile

Billinghurst (talkcontribs)

Hi. I hope that you can point me to where the configuration exists ...

On a page like,_Prothero)/Poetry/Volume_1 the mobile skin is left aligning images that have been typeset to be centred to align with the remainder of the text on the page, see standard view, s:The Works of Lord Byron (ed. Coleridge, Prothero)/Poetry/Volume 1

So in the end we have people using text centering styles rather than image placement formatting to achieve their ends. Is this image positioning forcing something that we can control at a local level? Thanks.

Jdlrobson (talkcontribs)
Billinghurst (talkcontribs)

Ah, I thought that it was a feature that I could control, not a bug. Thanks.

Reply to "Wikisource centered images rendering left in mobile"

Your feedback matters: Final reminder to take the global Wikimedia survey

MediaWiki message delivery (talkcontribs)

WMF Surveys, 00:43, 20 April 2018 (UTC)

Reply to "Your feedback matters: Final reminder to take the global Wikimedia survey"

Reminder: Share your feedback in this Wikimedia survey

MediaWiki message delivery (talkcontribs)

WMF Surveys, 01:34, 13 April 2018 (UTC)

Reply to "Reminder: Share your feedback in this Wikimedia survey"

Share your experience and feedback as a Wikimedian in this global survey

MediaWiki message delivery (talkcontribs)

WMF Surveys, 18:36, 29 March 2018 (UTC)

Reply to "Share your experience and feedback as a Wikimedian in this global survey"
Avicenno (talkcontribs)

Hi. I am 1339861mzb at phabricator. I want to ask you who is herald? Because it is like bot i.e very fast. I created a new task at phabricator and found like herald add subscribers simultaneously!

Jdlrobson (talkcontribs)

Herald is indeed a bot! :)

Avicenno (talkcontribs)

Thanks. On what rationale it based when subscribing certain subscribers?

Jdlrobson (talkcontribs)
Reply to "Hi"

Using ResourceLoader's target option outside of MobileFrontend

FreedomFighterSparrow (talkcontribs)

Hi Jon,

A not-so quick question for you:

I use custom responsive skin on my wiki, but recently have started a move to separate the mobile site from the desktop one, in order to improve performance. However, I have no wish to use MobileFrontend, as it is inextricably tied to Minerva. What I did instead was take Extension:MobileDetect and improve upon it, mainly by taking parts out of MobileFrontend.

My main problem at this point is with the ResourceLoader target; I want to use that functionality to prevent some modules from loading in mobile. Unfortunately, the target definition for each module is in core, even though MobileFrontend is a separate extension - therefore certain modules that I need, such as mediawiki.legacy.shared, are not defined for mobile, simply because Minerva doesn't need them. While I can redefine every module manually for mobile, this will be very error prone; therfore, I tried doing so automatically using a whitelist and parsing both $wgResourceModules and Resources.php (because core modules aren't in $wgResourceModules).

What I do is allow 2 ways to define whitelisted mobile modules:

  1. Using the global $wgMobileDetectModuleWhitelist
  2. By a new hook, MobileDetectWhitelistModules, where you can add the name of a module(s).

This is my fork of MobileDetect, and this is a comparison showing only the whitelist changes.

Unfortunately, this just doesn't work... Maybe because I'm doing all the work in onBeforePageDisplay, and it's just too late to register and load my modules? Any ideas how to fix that? Or maybe just tell me if I'm just going down the wrong path?



P.S. I did take a look at [[ResourceLoader/Writing a MobileFrontend friendly ResourceLoader module]]. It looks like maybe your are adding modules in SkinTemplateOutputPageBeforeExec?

Jdlrobson (talkcontribs)

Minerva is not inextricably tied to MobileFrontend :) The config variable MFDefaultSkinClass is designed to allow you to choose another skin as the Mobile skin.

e.g. wgMFDefaultSkinClass = "Vector"

Jdlrobson (talkcontribs)

Once you are doing the above only 'mobile' target modules will be loaded by that skin... which I think is the behaviour you want?

FreedomFighterSparrow (talkcontribs)

Hi Jon,

I'll actually give wgMFDefaultSkinClass a go, though I fear MobileFrontend is doing way too much for what I need.

About the mobile target: the problem is that some modules, both in core (mediawiki.legacy.shared) and in extensions (CategoryTree) are not marked for mobile, because MobileFrontend/Minerva doesn't need them; however, my skin does need them. I'm trying to allow for a simple way to mark those as 'allowed on mobile', but for some reason I'm completely failing...

(Thank you for replying!)

Jdlrobson (talkcontribs)

@FreedomFighterSparrow I think the only way to circumvent this is to update the definitions in core unfortunately. I'm not sure if it's possible to do that in a hook. If possible I'd suggest migrating away from those while it's impacting you.

I don't know much about the CategoryTree extension but I suspect there is little harm in updating the module definitions there.

mediawiki.legacy.shared will be a little trickier, but it's quite a simple module and I think it would probably be easier to pick out the bits you need from it.

Jdlrobson (talkcontribs)

And on subject of MobileFrontend - we recognise this and are trying to cut it down. Pulling out the Minerva skin would reduce most of it - - I'm interested to hear how you get on with MFDefaultSkinClass!

FreedomFighterSparrow (talkcontribs)

Hi Jon, thanks for looking at this. I hate patching core - it just takes a one-time mistake when upgrading to have "unexplainable" regressions... but I'd just might do it, as I've exhausted most of my other options.

Regarding the split of MobileFrontend, I know you're working towards this and I appreciate this - we actually discussed this way back in Lyon ;-)

What's left in MF after removing Minerva?

Jdlrobson (talkcontribs)

MobileFrontend without Minerva would essentially be an extension that allows you to serve a different skin to mobile users on a different mobile domain if wanted.

There are other things it would provide under the hood:

  • mobile formatted content to support section collapsing, lazy loaded images, the ability to remove content from the mobile view, main page special casing + API to provide it.
  • various mobile optimised pages where changes to desktop have proved tricky/impossible e.g. the history, diff, watchlist pages. [note: I'd love to see these in core, but it's just not possible without HTML markup changes which will result in visible styling changes]
  • Ability to serve manifests to skins.
  • Possibly some JS friendly modules that can be used by skins that are not yet covered by core /oojs ui.
FreedomFighterSparrow (talkcontribs)

Hmmm, so basically a souped-up version of MobileDetect as I envision it. Cool :-)

Reply to "Using ResourceLoader's target option outside of MobileFrontend"

Collapsing code works on desktop MW, but (glaringly) NOT with MobileFrontend

Slgrandson (talkcontribs)

Good day, Mr. Jdlrobson. Yesterday, after hours of experimentation, I implemented an alternative to MW's standard Navboxes in the form of this Collapse Widget on my Referata wiki, The Dixwell Dossier. (Inspired by this StackExchange thread from July 2013, and this answer by "DavidLin".)

I'm already aware that MobileFrontend can't support Navbox because, as I've heard, it's too clunky and unwieldy for mobile. As such, I came up with an alternative that's supposed to be backwards-compatible by design. On the regular MW, the prototype code's "Expand/Collapse" function works with no problems (as is currently demonstrated in the Sandbox on that site), but when seen on the mobile view... Nothing happens. "Expand" is unchanged and unclickable, and the items that are supposed to be hidden below are exposed to view.

I wonder if you can come up with a mobile-compliant/MW-compliant JavaScript fix, or have I run into a bug on MobileFrontend's part?

Jdlrobson (talkcontribs)

Hi @Slgrandson it looks like the script tag is being rendered above the navbox. The code is running but it runs before the navbox is rendered.

You'll need to wrap this to make sure it only executes when ready. $( function() { // code } )

I'm not sure why it is working in desktop mode - is it possible there is a gadget or another extension making it work?

Slgrandson (talkcontribs)

Thanks to your patch, looks like it's now working on both sides; see for yourself. Thanks a dozen!

Don't think gadgets or extensions were involved before I gave it another go.

Jdlrobson (talkcontribs)


Reply to "Collapsing code works on desktop MW, but (glaringly) NOT with MobileFrontend"