Jdlrobson

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

English Wikisource grappling with CSS issues, planning for Wikimania

Hi Jon. The English Wikisource community is grappling with our perennial issues of replicating works with sidenotes. Our expertise in CSS is not widespread, and it is opportune for us to flag the issue for Wikimania 2016 in the hope of the desktop/mobile and export experts. Some assistance / overview from the experts and the decision makers on skins would be helpful to guide us getting the right information/phabricaot/... in place would be much appreciated. While this is specifically an enWS discussion, it will be a broader discussion as an issue for the WS sites. Thanks if you can help. — billinghurst sDrewth 01:09, 20 February 2016 (UTC)

Hi @Billinghurst apologies for getting back to you so late - I'm not sure how I missed this message. Is there a specific question/issue I can help you with? I'm not too familiar with what sidenotes are in the Wikisource context but am happy to help in anyway I can. Are there existing pages that are broken on mobile? Jdlrobson (talk) 22:54, 28 April 2016 (UTC)

mobile gadget race condition

Hi! At Swedish Wikipedia (sv.wikipedia) we have a gadget whose JavaScript looks like this:

$( function() {
	'use strict';
	$( '.mw-ui-icon-random' ).after( '<a href="https://tools.wmflabs.org/slumpartikel?mobile=1" title="Exkludera robotskapade sidor" id="ExkluderaRobotskapadeSidor">(−bot)</a>' );
} );

and whose gadget definition looks like this: *ExkluderaRobotskapadeSidorMobil[default|ResourceLoader|targets=mobile]|ExkluderaRobotskapadeSidorMobil.js|ExkluderaRobotskapadeSidorMobil.css

There seems to be some kind of race condition going on here, because it sometimes works and sometimes it doesn't. Can you tell just by looking at this what's wrong? If not, could you point me to a page where the modules that can be loaded as dependencies are described, so that I can try on my own? Nirmos (talk) 13:25, 22 April 2016 (UTC)

Hi!

I'm not surprised this isn't working. The menu is rendered via JavaScript so you'd be better of altering MW.config.get( ' wgMFMenuData' ) to control the rendering of the menu.

There's a longstanding bug around configuring the main menu which would make this a lot easier for you. Sadly it's not a top priority right now but here it is:

https://phabricator.wikimedia.org/T65459 Jdlrobson (talk) 10:24, 23 April 2016 (UTC)

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

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? Slgrandson (talk) 16:58, 8 August 2016 (UTC)

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? Jdlrobson (talk) 17:51, 10 August 2016 (UTC)

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. Slgrandson (talk) 14:58, 11 August 2016 (UTC)

Awesome!:) Jdlrobson (talk) 04:00, 12 August 2016 (UTC)

Using ResourceLoader's target option outside of MobileFrontend

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?

Thanks,

Dror.

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? FFS ^Talk 12:47, 5 January 2017 (UTC)

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 (talk) 02:05, 8 January 2017 (UTC)

Once you are doing the above only 'mobile' target modules will be loaded by that skin... which I think is the behaviour you want? Jdlrobson (talk) 02:06, 8 January 2017 (UTC)

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!) FFS ^Talk 07:01, 8 January 2017 (UTC)

@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 (talk) 13:19, 9 January 2017 (UTC)

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 - https://www.mediawiki.org/wiki/Skin:MinervaNeue - I'm interested to hear how you get on with MFDefaultSkinClass! Jdlrobson (talk) 13:21, 9 January 2017 (UTC)

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? FFS ^Talk 14:43, 9 January 2017 (UTC)

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. Jdlrobson (talk) 02:47, 10 January 2017 (UTC)

Hmmm, so basically a souped-up version of MobileDetect as I envision it. Cool :-) FFS ^Talk 09:16, 10 January 2017 (UTC)

Hi

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! Avicenno (talk) 23:08, 18 February 2018 (UTC)

Herald is indeed a bot! :) Jdlrobson (talk) 17:01, 22 February 2018 (UTC)

Thanks. On what rationale it based when subscribing certain subscribers? Avicenno (talk) 21:14, 22 February 2018 (UTC)

Phabricator/Help/Herald_Rules Jdlrobson (talk) 21:54, 22 February 2018 (UTC)

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

Hello! The Wikimedia Foundation is asking for your feedback in a survey. We want to know how well we are supporting your work on and off wiki, and how we can change or improve things in the future. The opinions you share will directly affect the current and future work of the Wikimedia Foundation. You have been randomly selected to take this survey as we would like to hear from your Wikimedia community. The survey is available in various languages and will take between 20 and 40 minutes.

Take the survey now!

You can find more information about this survey on the project page and see how your feedback helps the Wikimedia Foundation support editors like you. This survey is hosted by a third-party service and governed by this privacy statement (in English). Please visit our frequently asked questions page to find more information about this survey. If you need additional help, or if you wish to opt-out of future communications about this survey, send an email through the EmailUser feature to WMF Surveys to remove you from the list.

Thank you!

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

MediaWiki message delivery (talk) 18:36, 29 March 2018 (UTC)

Reminder: Share your feedback in this Wikimedia survey

Every response for this survey can help the Wikimedia Foundation improve your experience on the Wikimedia projects. So far, we have heard from just 29% of Wikimedia contributors. The survey is available in various languages and will take between 20 and 40 minutes to be completed. Take the survey now.

If you have already taken the survey, we are sorry you've received this reminder. We have design the survey to make it impossible to identify which users have taken the survey, so we have to send reminders to everyone. If you wish to opt-out of the next reminder or any other survey, send an email through EmailUser feature to WMF Surveys. You can also send any questions you have to this user email. Learn more about this survey on the project page. This survey is hosted by a third-party service and governed by this Wikimedia Foundation privacy statement. Thanks!

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

MediaWiki message delivery (talk) 01:34, 13 April 2018 (UTC)

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

Hello! This is a final reminder that the Wikimedia Foundation survey will close on 23 April, 2018 (07:00 UTC). The survey is available in various languages and will take between 20 and 40 minutes. Take the survey now.

If you already took the survey - thank you! We will not bother you again. We have designed the survey to make it impossible to identify which users have taken the survey, so we have to send reminders to everyone. To opt-out of future surveys, send an email through EmailUser feature to WMF Surveys. You can also send any questions you have to this user email. Learn more about this survey on the project page. This survey is hosted by a third-party service and governed by this Wikimedia Foundation privacy statement.

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

MediaWiki message delivery (talk) 00:43, 20 April 2018 (UTC)

Wikisource centered images rendering left in mobile

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

On a page like https://en.m.wikisource.org/w/index.php?title=The_Works_of_Lord_Byron_(ed._Coleridge,_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. — billinghurst sDrewth 11:59, 30 April 2018 (UTC)

Raised a bug here: https://phabricator.wikimedia.org/T193595

For quicker replies for me, best to add a task to Phabricator. Will see if I can get this fixed. Jdlrobson (talk) 00:22, 2 May 2018 (UTC)

Ah, I thought that it was a feature that I could control, not a bug. Thanks. — billinghurst sDrewth 11:30, 2 May 2018 (UTC)

Netlify

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. —MarcoAurelio (talk) 21:08, 30 October 2019 (UTC)

Hi Jon, Pagebanner and Women in Red.

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. ~~~~

<figure-inline class="mw-default-size"></figure-inline> Victuallers (talk) 12:34, 3 February 2020 (UTC)

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: https://en.wikivoyage.beta.wmflabs.org/wiki/Women_in_red_test - 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! Jdlrobson (talk) 11:34, 5 February 2020 (UTC)

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

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 ?

Thanks.

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

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 Jdlrobson (talk) 14:29, 21 March 2020 (UTC)

Logo

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I apologize for being so rude. Your comment is a fair point which has place to be. Sorry again. Serhio Magpie (talk) 20:36, 24 June 2020 (UTC)

Oh not at all. My fault for not being more careful with my editing.

I just want to make sure I play my part in keeping the creative energy flowing. I think the existing logo is outdated and I'm keen to any sort of change here.

On reflection I think it's a shame that we jumped into voted so early. There are lots of good ideas in all the logos. Jdlrobson (talk) 00:20, 25 June 2020 (UTC)

I completely agree with you. We are only at the brainstorm stage now and searching for ideas. Thanks. Serhio Magpie (talk) 04:27, 25 June 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

A barnstar for you!

<figure-inline></figure-inline>	The Special Barnstar
	For all the work you do to make Mobile Web an awesome reading space for web readers :) X-Savitar (talk) 00:24, 7 July 2020 (UTC)

Page Previews: wikipage.content hook

Hi! I'm writing a user script that adds new links to a page, and would like to enable Page Previews handlers for those links. Per this change, it looks like the wikipage.content hook won't work, and I've been looking through the code and can't see any other way to do this. Would that be correct? (And sorry if this is the wrong venue - I wasn't sure opening a task on the Page-Previews phab workboard was a good idea.) Enterprisey (talk) 07:23, 8 September 2020 (UTC)

The delegate event handler we use means any link no matter when it is added will trigger a page preview so no hooks are needed here.

The link to be considered valid however must have a link and title attribute and an associated page preview associated with the URL. This code for example will trigger a page preview:

$('<a title="Hello" href="/wiki/Hello">hello</a>').prependTo('#mw-content-text')

Jdlrobson (talk) 15:26, 8 September 2020 (UTC)

Thank you! I tried it, but I'm on a Special-namespace page. Will it only work in mainspace? Enterprisey (talk) 08:26, 10 September 2020 (UTC)

It displays on all special pages except those in this list:

https://github.com/wikimedia/mediawiki-extensions-Popups/blob/master/extension.json#L90 Jdlrobson (talk) 14:16, 10 September 2020 (UTC)

Using hooks

I try to do stuff with hooks, but there are still issues unsolved:

• Extension:AgeClassification (Seems to work)
• Extension:WimaAdvertising (Still has issues)

--WikiForMen (talk) 20:14, 1 January 2021 (UTC)

Are the styling issues only in certain skins? If so, you can add skin specific styles which will be easier to maintain.

it's a bit outdated but Manual:$wgResourceModuleSkinStyles explains how you can do that (feel free to update that page)

and here's an example of it in action in Minerva:

https://github.com/wikimedia/mediawiki-skins-MinervaNeue/blob/master/skin.json#L167 Jdlrobson (talk) 21:45, 1 January 2021 (UTC)

For Ad1 and AD2 could you use Manual:Hooks/SkinAfterPortlet to add HTML to an existing menu? I think all the Wikimedia skins should support that, and if not that's a bug.

You'd need to check $portlet parameter to check if its AD1 or AD2 Jdlrobson (talk) 21:48, 1 January 2021 (UTC)

Hook SkinAfterPortlet is to add additional text to the portlet, but NOT to modify the label of the portlet, I guess? WikiForMen (talk) 20:32, 2 January 2021 (UTC)

If you are modifying the label, you can only do that in MediaWiki:Sidebar, by a translateable message or by constructing a new portlet to the sidebar using Manual:SidebarBeforeOutput

A few general Q and As can be found here: User :Jdlrobson/Skins for extension developers#Q: I want to add a new "portal" menu to the sidebar. Jdlrobson (talk) 20:48, 2 January 2021 (UTC)

I see. Now I can explain you, why this will not work. The labels should be translated, if you select an other language in personal settings. Depending on the purpose, the headings should be advertisement, event notice or hint. According to your suggestion, I would now have to change the entry in the navigation bar each time... I would like to avoid precisely this annoying workload.

Hook "SidebarBeforeOutput": If there are two advertising blocks, both should be called Advertisment. How should I differentiate when assigning the HTML snippet? Can this work?

This is the reason why I enter AD1 and AD2 as markers in the sidebar, I then have distinguishable markers to which I can assign an HTML snippet and in the hack of the skin I then bend the markers AD1 and AD2 to the labels, according to the variables $wgSidebarAd1Type and $wgSidebarAd2Type. And it is precisely this that cannot be implemented with all the available hooks.

Nor is it a question of creating a new "portal" SOMEWHERE. The advertising blocks must also be positioned appropriately in the sidebar in the sidebar. But this is precisely the purpose of the AD1 and AD2 markers.

That's why I decided to drill out the skins, because the task cannot be solved with the Mediawiki hooks.

And all "examples" of the hook shit going with the test/href scheme.

Actually, it still needs its custom class specifications. I have to use tricks to display the advertising blocks appropriately (background colour, spacing, border if necessary).--WikiForMen (talk) 21:56, 2 January 2021 (UTC)

The documentation is so unsatisfactory that I do not understand what the difference between Manual:Hooks/SidebarBeforeOutput and Manual:Hooks/SkinBuildSidebar is supposed to be. --WikiForMen (talk) 22:26, 2 January 2021 (UTC)

> That's why I decided to drill out the skins, because the task cannot be solved with the Mediawiki hooks.

I'm not sure I completely understand the problem here, but I'm still fairly confident you can achieve what you are doing with hooks and if it's not we should update those hooks to make it possible.

> I would like to avoid precisely this annoying workload.

HTML should be cached for each time it's generated or were you talking about something other than performance here? You can use internal caching methods if what you are doing here is very intensive but it doesn't seem that way.

> The advertising blocks must also be positioned appropriately in the sidebar in the sidebar. But this is precisely the purpose of the AD1 and AD2 markers.

And that's fine. Putting AD1 and AD2 in MediaWiki:Sidebar will create 2 elements with id's #p-AD1 and #p-AD2. These will have headings translateable at `MediaWiki:aD1` and `MediaWiki:aD2`, but can also be replaced with the SidebarBeforeOutput. Using Php array methods you can retain the same positioning with a custom heading by doing something like this...

e.g.

$wgHooks['SidebarBeforeOutput'][] = function ( $skin, &$bar ) {
  $newbar = [];
  foreach( $bar as $key => $menu ) {
    if ( $key === 'AD1' ) { 
       $newbar[ 'My custom label or message key' ] = $menu;
    } else {
       $newbar[$key] = $menu;
    }
  }
  $bar = $newbar;
};

If the above doesn't help can you provide a bug report-style account of what you are trying to do here?

e.g.

// Do this...

// Run this code

// Expected result..

// Actual result.. Jdlrobson (talk) 22:26, 2 January 2021 (UTC)

$wgHooks['SidebarBeforeOutput'][] = function ( $skin, &$bar ) {
  $newbar = [];
  foreach( $bar as $key => $menu ) {
    if ( $key === 'AD1' ) { 
       $newbar[ 'My custom label or message key' ] = $menu;
    } else {
       $newbar[$key] = $menu;
    }
  }
  $bar = $newbar;
};

is not working because of a serious problem.

$wgHooks['SidebarBeforeOutput'][] = function ( $skin, &$bar ) {
  $newbar = [];
  foreach( $bar as $key => $menu ) {
    if ( $key === 'AD1' ) { 
       $newbar[ 'advertising' ] = $menu; // <== first set
    } else if ( $key === 'AD2' ) { 
       $newbar[ 'advertising' ] = $menu; // <== overriding first set
    } else {
       $newbar[$key] = $menu;
    }
  }
  $bar = $newbar;
};

You see the issue? With two ad blocks one will override the other. :-( WikiForMen (talk) 22:51, 2 January 2021 (UTC)

I did another try with array_splice:

public static function onSkinTemplateOutputPageBeforeExec(
		SkinTemplate &$skin,
		QuickTemplate &$tpl
	) {
		global $wgSidebarAd1Code, $wgSidebarAd1Style, $wgSidebarAd1Type;
		global $wgSidebarAd2Code, $wgSidebarAd2Style, $wgSidebarAd2Type;
		$_key1 = empty( $wgSidebarAd1Type ) ? 'advertising' : $wgSidebarAd1Type;
		$_key2 = empty( $wgSidebarAd2Type ) ? 'advertising' : $wgSidebarAd2Type;
		// Transfer keys 'AD1' and 'AD2' to labels
		$_modified = false;
		$offset = 0;
		$sidebar_new = $tpl->data['sidebar'];
		foreach ( $tpl->data['sidebar'] as $key => $value ) {
			switch ( $key ) {
				case 'AD1' :
					if ( empty( $wgSidebarAd1Code ) ) {
						// Deactivate marker 'AD1' if $wgSidebarAd1Code is not defined
						$sidebar_new['AD1'] = false;
					} else {
						// Replace array with the key 'AD1' with key $wgSidebarAd1Type
						array_splice( $sidebar_new, $offset, 1, [ $_key1 => $wgSidebarAd1Code ] );
					}
					$_modified = true;
				break;
				case 'AD2' :
					if ( empty( $wgSidebarAd2Code ) ) {
						// Deactivate marker 'AD1' if $wgSidebarAd1Code is not defined
						$sidebar_new['AD2'] = false;
					} else {
						// Replace array with the key 'AD2' with key $wgSidebarAd2Type
						array_splice( $sidebar_new, $offset, 1, [ $_key2 => $wgSidebarAd2Code ] );
					}
					$_modified = true;
				break;
			}
			++$offset;
		}
		if ( $_modified ) {
			$tpl->set( 'sidebar', $sidebar_new );
		}
	}

WikiForMen (talk) 22:41, 2 January 2021 (UTC)

> You see the issue? With two ad blocks one will override the other. :-(

You'll need two unique message keys that translate to the heading. Use advertising-1 and advertising-2 and define those messages in i18n/en.json

Appending ?uselang=qqx to url will show you message keys for the page. Jdlrobson (talk) 23:21, 2 January 2021 (UTC)

That's dirty and by doubling the same entries an increase of the overhead, but I had already thought of that... ;-) WikiForMen (talk) 23:26, 2 January 2021 (UTC)

Why is that dirty? And what overhead are you exactly referring to here? I don't see any problem with having 2 messages using the same text. I've seen this in other extensions. The context is different. See https://github.com/wikimedia/mediawiki/blob/master/languages/i18n/en.json#L148 for example.

The benefit of turning these into translatable messages is that you give the site owner control over those headings - I imagine some people may want to blank them for example and not have a heading.

Also please consider somebody reading with a screen reader. Two portals with the same heading is going to be confusing to those users, so another use case might be translating those to "advertisement 1" and "advertisement 2". Jdlrobson (talk) 23:40, 2 January 2021 (UTC)

If you want to know, why I call it dirty, have a look at the css files:

https://github.com/WikiMANNia/MediaWiki-Extension-WimaAdvertising/blob/master/resources/css/Vector.css

It's ugly! --WikiForMen (talk) 01:58, 5 January 2021 (UTC)

Nice! Seems easier to maintain than forking the entire skin, though? :) Using LESS might make that a bit easier to maintain as you'd be able to nest all the rules.

e.g.

#p-wimaadvertising-advertising,

#p-wimaadvertising-advertising2

....

#p-wimaadvertising-hint2 {

.body {

   background-color: #ffffff;

   margin-left: -.7em;

   margin-top: .3em;

   padding: 0 0 .1em 0;

   width: auto;

}

} Jdlrobson (talk) 18:23, 5 January 2021 (UTC)

I'm not that IN with css and thanks for the help and suggested solutions. :-) --WikiForMen (talk) 01:20, 6 January 2021 (UTC)

It would be less "dirty" if it was considered that #2 is only used if both are advertisements or event notes ... But at least it works now. Thanks for the help. May it be helpful for someone. :-) --WikiForMen (talk) 00:13, 3 January 2021 (UTC)

Prove, if image is present

Hi, I have something like this:

• resources
  • css
  • images
    • de
      • Donate_Button.gif
    • en
      • Donate_Button.gif
    • es
      • Donate_Button.gif
    • fr
      • Donate_Button.gif

How can I prove, that "it/Donate_Button.gif" does not exist? --WikiForMen (talk) 13:49, 14 January 2021 (UTC)

[WMF Board of Trustees - Call for feedback: Community Board seats] Meetings with MediaWiki and Wikitech communities

The Wikimedia Foundation Board of Trustees is organizing a call for feedback about community selection processes between February 1 and March 14. While the Wikimedia Foundation and the movement have grown about five times in the past ten years, the Board’s structure and processes have remained basically the same. As the Board is designed today, we have a problem of capacity, performance, and lack of representation of the movement’s diversity. Our current processes to select individual volunteer and affiliate seats have some limitations. Direct elections tend to favor candidates from the leading language communities, regardless of how relevant their skills and experience might be in serving as a Board member, or contributing to the ability of the Board to perform its specific responsibilities. It is also a fact that the current processes have favored volunteers from North America and Western Europe. In the upcoming months, we need to renew three community seats and appoint three more community members in the new seats. This call for feedback is to see what processes can we all collaboratively design to promote and choose candidates that represent our movement and are prepared with the experience, skills, and insight to perform as trustees?

In this regard, two rounds of feedback meetings are being hosted to collect feedback from the technical communities in Wikimedia. Two rounds are being hosted with the same agenda, to accomodate people from various time zones across the globe. We will be discussing ideas proposed by the Board and the community to address the above mentioned problems. Please sign-up according to whatever is most comfortable to you. You are welcome to participate in both as well!

• Round 1 - Feb 25, 4:00 pm UTC
• Round 2 - Mar 4, 4:00 am UTC
• Sign-up and meeting details: Wikimedia Foundation Board of Trustees/Call for feedback: Community Board seats/Conversations/MediaWiki and Wikitech

Also, please share this with other volunteers who might be interested in this. Let me know if you have any questions. KCVelaga (WMF), 14:37, 21 February 2021 (UTC) MediaWiki message delivery (talk) 14:37, 21 February 2021 (UTC)

Skin:MediaWikiBootstrap need help to update the skin

Hi Jdlrobson,

I just saw that you marked the Skin:MediaWikiBootstrap as Unstable. I know it does not work even in 1.36.

I found this issue a few weeks back and tried to search the related docs to update the skin. We also talked a few months back about upgrading the skin. I am kind of frustrated that Mediawiki is updating the skin system and there is no related doc at all. If any skin developer have to discover the list of methods from the codebase, that is the other way of saying, "Do not use MediaWiki" at all!

Can you please let me know where can I find the docs and help to build a skin which works. ~~~~ Nasir Khan Saikat • talk • 17:18, 22 June 2021 (UTC)

I'm not sure what docs you are looking for, but the skin is not working for some time due to usage of a function deprecated a long time ago.

https://github.com/nasirkhan/mediawiki-bootstrap/pull/15 should be all that's needed to fix it. Provided you are subscribed to deprecation notices (and the deprecation notices that should appear in your server logs and in your browser), all you should need to upgrade your skin is to follow the Release notes.

If you are building a skin from scratch against current master, Manual:How to make a MediaWiki skin documents exactly what you need to do. If you have an existing skin I'm not sure what documentation you are looking for so it would help if you were more specific with your queries so I can help you. Jdlrobson (talk) 18:05, 22 June 2021 (UTC)

thank you for you help.

I do not regularly follow the mediawiki releases and did not updated the skin for a long time. So, even though I know that Release notes are the best place to look into while updating the skin. You updated one method which was deprecated in 1.36 and there might be other method calls while may deprecate on 1.37 or the next release. And structurally MediaWikiBootstrap and Example/SkinLabsSkin is different.

In summary I want to update the skin to Mustache but the skin will look similar.

If I read the Manual:Skinning Part 2 and Manual:Skinning Part 3 I would be able to built a PHP based skin. But if I want to build a Mustache based skin there is not equivalent amount of doc available.

I have a number of queries, those might look silly but as I do not building the skin system I do not have much info about those. Like I installed 1.37 and installed Example skin. After that I found that the logo is not visible, but there is a file on the LocalSettings logo path. What should i do now? How to set the Favicon? how can I show the language links? will I have to do anything for RTL language wiki? how to control the footer links? what are the steps to format the categories area? I also need to add Google Fonts, Icon fonts. how to show/hide the navigation menu items, how to format those? styling the search box, add an extra class/id with that, formatting the search box results. None of these questions have answers to that Manual:How to make a MediaWiki skin doc.

If you can answer to my queries, I also can write docs and update that single page as well. Nasir Khan Saikat • talk • 23:25, 22 June 2021 (UTC)

Okay lots to digest here. I think a good starting point might be a migration guide of how to migrate a SkinTemplate skin to SkinMustache. I'll commit to writing one of those as that seems like it would be useful to others.

In terms of your questions, I would say these are good questions and thanks for asking them. I've raised the ones I've understood on the Manual_talk:How_to_make_a_MediaWiki_skin and will get to them when I can.

It would be helpful to expand on your other questions with time, to understand them better.

> "what are the steps to format the categories area? I also need to add Google Fonts, Icon fonts. how to show/hide the navigation menu items, how to format those? styling the search box, add an extra class/id with that, formatting the search box results."

I'm not 100% sure what's being asked here. Provided you've setup a CSS/LESS file you can put anything you want in there, including paths to resources such as downloaded fonts or Google Font URLs. You are also free to include libraries such as Icon fonts in the declarations. ResourceLoader/Developing_with_ResourceLoader has information on how that works if that's what's needed here. You are also free in your skin to add any HTML markup you need for styling things like the search box.

Some pages that may help you with your immediate questions around languages and icons:

• Logo: Manual:$wgLogos
• Favicon: Manual:FAQ#How do I change the icon in the browser.27s address line .28favicon.29.3F
• Language links: Manual:Interwiki Jdlrobson (talk) 00:03, 23 June 2021 (UTC)

It would be really helpful if you can write a migration guide. When it will be ready it will be easier to prepare a doc to building a skin from scratch.

I can write my questions in details, but got confused about where to ask those! I did not asked those to Manual_talk:How_to_make_a_MediaWiki_skin as the questions are not specific to that page. Rather about those which are not included there. I asked to Project:Support desk, Discord and wikitech mailing list ( Topic:Wb1kvracyubak7se, Topic:Wb1rvgucmqffnsws, Topic:Wazztppvnjh62mo7, https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/HVS7OBF5YQEMY7MFAYRSQZNEMHJGA5VS/). Not no one have the time or knowledge to help, except you.

So first help I need is, a place where I can ask questions and get answers about MediaWiki. Should I ask everything to you, or if there is any group/ forum available? Nasir Khan Saikat • talk • 00:40, 23 June 2021 (UTC)

Historically there has not been much interest in skin development for mediawiki (IMO) and a lot of the skin development does seem to happen in private. In 1.36 we began to challenge that by trying to simplify the creation process and poke existing skins to see it they were still being actively developed.

Manual_talk:How_to_make_a_MediaWiki_skin is probably the best place to ask questions as it's linked to the main page and the small group of us that does exist is at least aware of it. Jdlrobson (talk) 02:23, 23 June 2021 (UTC)

I will ask questions to the Manual_talk:How_to_make_a_MediaWiki_skin page then. I hope I will be able to build a skin soon with intended customization.

I think you are not right that, people do not have interest on the skins. From my experience and issues I am facing so far, I can confidently say that people were demotivated and discouraged in a a number ways to build new skins and even using MediaWiki. This is done by the core community/staff members of MediaWiki. I asked a number of questions about some common customization needs like, logo, navigation, footer and so on. There is no answer available for those, without those answer how can someone new to the platform can build a skin?

You are the only person who is replying with some helpful information. But you are not the only one who is building and using the entire skin system. Where are others and which platform they are active in? You can check Topic:Wb1rvgucmqffnsws as a reference. The person trying to help may have the least info about the skin system. But I asked the question in the Support desk and there are a group of volunteers claim to be active there!

Wordpress is the most popular CMS and a major reason is their are docs and community member helping others and their theme/skin is easy to build/customize. So far the Wordpress websites I visit every day I probably not seen any site with the default theme, where as a big number of mediawiki sites are using default skin. It can not be the lack of interest to developing new skins. Nasir Khan Saikat • talk • 07:34, 23 June 2021 (UTC)

There is no team at the Wikimedia Foundation supporting skins and no skin community site (wordpress on the other hand does that).

I am not questioning that people want to build skins and are put off from doing so, I am saying we do not have a community in the same way. The skins that are built are seldom shared as there is nowhere obvious to share them. Https://skins.wmflabs.org is an experiment in seeing what happens when skins are showcased, but this is being done by me in a volunteer capacity.

I have begun your migration guide. Questions at this early stage are welcomed Manual:How to make a MediaWiki skin/Migrating SkinTemplate based skins to SkinMustache Jdlrobson (talk) 19:09, 23 June 2021 (UTC)

thanks for starting the migration guide. I will add my questions to Manual_talk:How_to_make_a_MediaWiki_skin and you can pick which you want to add in the migration guide.

I know there is no separate team to support skin, but my point was a skin in a part of MediaWiki not some outside thing. I support MediaWiki means, I support MediaWiki and all the core components including extension & skin systems. Nasir Khan Saikat • talk • 14:48, 25 June 2021 (UTC)

Skin:Lakeus’ newer version is not deployed on https://skins-demo.wmflabs.org

I might have deleted and recreated the 1.0.17 tag, and now the newer release of the skin is no longer deployed on it. Could you help me fix it? Thanks! Lakejason0 (talk) 04:47, 26 October 2021 (UTC)

Question about srcset removal on mobile, and parser cache fragmentation

Hi Jon!

I was reading your post about the impact of removing srcset from mobile pageviews, and I was impressed by the amount that it reduced the image bandwidth. Do you think the reduction in 2G load time is due to devices that are running on 2G that were previously requesting the 2x version of the image, but now are forced to request the 1x version? Or is there some other explanation? I know that at least back in 2015-16 there were some bugs in browser engines that would request both the "src" image and also one of the "srcset" entries as well, although I think those have generally been fixed.

I'm also curious whether those graphs might have overestimated the effect, due to the issue Brion brought up on T134115#2257578 (sorry, AbuseFilter is blocking me from making that into a link!) which would have caused the non-srcset versions of pages to sometimes display to desktop users as well. It's a bit weird though because I think then (and even now) the majority of "retina" displays were mobile.

Also wondering whether most of those gains would have been eaten up by Reading/Web/Lazy loading of images on all wikis anyway, but that's probably harder to answer after-the-fact.

I'm mainly asking because naively, it seems like this change (plus Brion's addition to the parser cache key) roughly doubles the number of parser cache misses, because now mobile and desktop pages need to use entirely separate cache entries. Am I missing something that makes it not that way, or makes that less of a problem than I (not being associated with WMF at all) would think?

Thanks! CookMePlox (talk) 15:26, 18 February 2022 (UTC)

Hey CookMePlox, thanks for reading through and reaching out.

My knowledge is a little hazy here, but as I recall, the fully load time was the time to load all assets in the page, and that included images, so by reducing the payload of most of the images from 2x to 1x, there was less to load, and it could be loaded quicker.

My hope had been that reducing the payload of the HTTP requests there would be less competition and faster loaded resources on the critical path, but we never managed to prove that one way or the other.

Yes there was a bug a while back that loaded both srcset and src - I remember that one, and yes those should be fixed now.

I believe the Brion bug in phab:T134115#2257578 meant that depending on what got cached first, we were either stripping srcset from desktop articles, or including them on mobile. The data in those graphs is mobile only, so I think that would have underestimated impact if anything. Reading back the phab ticket, this problem got identified quickly and fixed May 2nd 2016 with a purge, so I don't think it would have impacted those graphs for the days that followed.

Yes to the cache misses problem. The mobile and desktop cache differently. It would probably be a good project at this point to explore adding native lazy loading to desktop phab:T148047 and revising the mobile site to use it, so that the two can share a cache. Assuming nothing else varies the cache, that would have quite the impact.

Lazy loading of images on all wikis had a more significant impact than the srcset removal. Not sure if you read this blog post, but that has a write up: https://diff.wikimedia.org/2016/09/19/mobile-web-improvements/ Jdlrobson (talk) 18:15, 19 February 2022 (UTC)

Request to remove me aas a subscriber

Hi. Can you please remove me as a subscriber from this task here: https://phabricator.wikimedia.org/T328719 It seems like I can not do this by myself and I can not help with this task. Best Regards --KleinerKorrektor (talk) 19:15, 24 February 2023 (UTC)

Thank you! --KleinerKorrektor (talk) 22:06, 25 February 2023 (UTC)

Missing programming experience.

Hello, nobody has programming experience on s:nl|the Netherlands wikisource . There are about 4 persons who try to keep that site alive. Whatever help you may give us, is thankfully accepted. The introduction of the proofread-projet, as late as 2016, has never completely done. Maybe you can help to add a working ''header=1'' functionality to the tag ''pages index=''. Also several gadgets never have been installed. Thanks a lot for any adjustment you make. Havang(nl) (talk) 16:52, 21 August 2023 (UTC)

Recommendations for night mode compatibility on Wikimedia wikis

The good and bad examples you've added to Recommendations for night mode compatibility on Wikimedia wikis#Target night mode using standard CSS class on HTML element AND media query are completely the same. Please try again. Nardog (talk) 08:28, 31 January 2024 (UTC)

Manual:SkinMustache.php

In the version 16 janvier 2024 à 18:28 you add the description "ID unique to this specific menu" for the key name of "PortletListItemData" and the description "ID of the menu item" for the key id. To use "Id" for both is not very clear. Mahabarata73 (talk) 13:46, 2 December 2024 (UTC)