User talk:Jdlrobson

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

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)

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)

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

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

Hook SkinAfterPortlet is to add additional text to the portlet, but NOT to modify the label of the portlet, I guess?

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.

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

$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. :-(

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 );
		}
	}

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

That's dirty and by doubling the same entries an increase of the overhead, but I had already thought of that... ;-)

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

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;

}

}

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)

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

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')

Thank you! I tried it, but I'm on a Special-namespace page. Will it only work in mainspace?

It displays on all special pages except those in this list: https://github.com/wikimedia/mediawiki-extensions-Popups/blob/master/extension.json#L90

	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)

I apologize for being so rude. Your comment is a fair point which has place to be. Sorry again.

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.

I completely agree with you. We are only at the brainstorm stage now and searching for ideas. Thanks.

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

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

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!

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.

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.

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.

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