Extension talk:Gadgets

Previous discussion was archived at Extension talk:Gadgets/Archive on 2012-01-06.

Previous page history was archived for backup purposes at Extension talk:Gadgets/LQT Archive 1 on 2015-07-10.

Hi. Shouldn't gadget definitions be removed? Shouldn't categories be added?

It works.

Is 'minify' works for ES6 gadget (requiresES6)?

When do you refer to the page "MediaWiki:Gadgets-definition" misunderstandings may arise.

1) Should I use the namespace MediaWiki even if I have declared another one in my LocalSettings.php (eg: $wgMetaNamespace = "Iubar";) ?

2) Is the page Gadgedts-definition valid for any no US/UK locale installation of mediawiki ?

(eg: in Italian the translation of Gadgets is Accessori)

1. Changing $wgMetaNamespace does not affect MediaWiki: namespace, they're separate things

2. Yes. You just use it exactly as you see it (in English) irrespective of the wiki language.

$wgMetaNamespace controls the name of the namespace that’s called Project on mediawiki.org, not the one that’s called MediaWiki. The name of the namespace MediaWiki can be localized on non-English wikis (through software localization, not in LocalSettings.php), but MediaWiki always works as an alias, so you can just type MediaWiki:Gadget-definition in the search on every wiki in the search field, and it’ll find the right page.

Thank you, resolved

I have several gadgets which contain only CSS and type is styles. However, no matter how I sort them in gadgets-definitions, the order they are loaded seems unchanged. Are they loaded in the alphabetical order, or the order they are defined in gadgets-definitions?

I'm not extremely familiar with gadgets, but likely alphabetical order if they're handled in a similar way as other ResourceLoader modules.

It's unclear where the source files implementing gadgets go. The page only discusses defining which are available to users, but doesn't specify where the extension looks for the provided filenames for gadgets.

It should link to this: Gadget kitchen#Deploying or enabling a gadget

@Mcint

The definition syntax is * mygadget [options] | page names. The easiest and recommended way to create or edit the source code pages is through Special:Gadgets, where we automatically render each gadget's metadata in way that you can interact with, to create or edit the source codee page. You can learn more about the syntax and the special page, near the top of the page at Extension:Gadgets#Usage.

Alternatively, if you prefer navigate to a source page yourself, you could prepend "MediaWiki:Gadget-" in front of the specified page name. For examples of this logic, refer to the docs at Extension:Gadgets#Pages.

https://commons.wikimedia.org/wiki/Special:Gadgets

• doesn't have a way to link to sections (Special:Gadgets#blabla),
• doesn't have a table of contents.
• doesn't have a Talk: page.

Last one first: No special page has a talk page in namespace (while it might be connected with flow discussion thread?).

First and second: Well, actually a good idea. Fragment identifiers might be derived from headline text at least, and perhaps the TOC algorithm may be applied to this particular special page, fed by the headline collection.

The definitions page (linked from the lead) is a regular page and does have a talk page.

The anchors should be generated from the raw section IDs (as seen on MediaWiki:Gadgets-definition, e.g. #Navigation instead of #Improved navigation), so that they remain the same across UI languages.

If users are looking at headline Improved navigation in particular language version, they will copy text of headline and use it for linking.

• No regular reader has access to the internal system message ID.

Therefore both id= need to be hidden in generated HTML:

• Visible headline text in particular language, available within that uselang= only.
• System message ID for programmers; rather sophisticated.

On regular pages there is currently

• <h2> without any id= now
• <span> with headline text in page language and id= generated from that localized text; also when generating TOC
• <span> with toolbox in user language

The first one might address the language independent fragment, the second one such visible text, and third one is not really expected on a special page.

• If both fragments are identical, one is to be omitted to ensure HTML document validity.

Someone should start a feature request at Phabricator.

I found that ja:MediaWiki:Gadget-dark-mode.css, which is @import en:MediaWiki:Gadget-dark-mode.css, does not work well. The reason seems that must come before all other types of rules but it's loaded on the bottom of load.php.

.mw-parser-output a[href$=".pdf"].external,
.mw-parser-output a[href*=".pdf?"].external,
.mw-parser-output a[href*=".pdf#"].external,
.mw-parser-output a[href$=".PDF"].external,
.mw-parser-output a[href*=".PDF?"].external,
.mw-parser-output a[href*=".PDF#"].external {
 background:url(//upload.wikimedia.org/wikipedia/commons/2/23/Icons-mini-file_acrobat.gif) no-repeat right;
 padding-right:18px
}
span.PDFlink a {
 background:url(//upload.wikimedia.org/wikipedia/commons/2/23/Icons-mini-file_acrobat.gif) center right no-repeat !important;
 padding-right:17px !important
}
.allpagesredirect a:link,
.allpagesredirect a:visited,
.redirect-in-category a:link,
.redirect-in-category a:visited,
.watchlistredir a:link,
.watchlistredir a:visited {
 color:#595959
}
.client-js > body.skin-vector #p-personal li {
 font-size:0.75em
}
.client-js > body.skin-monobook #p-personal li {
 font-size:1em
}
.client-js > body.skin-vector #p-personal ul {
 margin-right:5.0625em
}
.client-js > body.skin-monobook #p-personal ul {
 margin-right:7.6em
}
@import url(https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-dark-mode.css&action=raw&ctype=text/css);

How can I fix this? Do you have any tips to use @important on the Gadgets?

Hi. Indeed, the CSS format does not permit use of @import anywhere other than at the start of a stylesheet. However, the guruantees we provide for batching and ordering stylesheet modules requires exactly that (in most cases) we place it somewhere later in the response.

In ResourceLoader we have a legacy exception for the "user" (personal user css) and "site" (site-wide Common.css) modules which historically are unable to register their subfiles as native. The exception is that when we encounter a later chunk, we split it out into a new request and/or flush the chunk as its own <style> element.

For all other modules (MW core, extensions, and gadgets) it is expected that code is loaded natively for optimium performance as we do not want the visual rendering of articles to be delayed by late-discovered additional requests, especially requests to other domains.

The type option for gadgets (docs) can switch between pure "styles" and "general". The main benefit of "styles" is that it loads immediately and before the page is visually rendered. However, this immediate-ness is contradicted when importing files from other wiki. The browser does not know about these files until after all the styles have arrived. Delaying rendering at this point is slow.

Your options are:

1. Make it a locally cached and optimised gadget, by copying the page content as well. This creates fast page views and no delays of dark mode.
2. Alternatively, you can set type=general. I tried this in jawiki rev 90881097 and confirmed that this "works" in so far that it makes the page render exactly as fast as if dark mode was not there, but then dark mode arrives at the same time as it would if we were to delay rendering for cross-domain styles import. Despite being faster, this way feels slower because we first see the fast page rendering and only then the dark mode.

There are ways to support @import with workarounds in our software that create complicated ways of loading stylesheets, that are difficult to debug and understand. I have choses in the past not to support this, and instead invest the cost in making everything else faster and simpler. The first option would be my recommendation in today's possibilities.

There is a third option, which is to develop the code as an extension and seek deployment (or in the future, "global gadgets", phab:T22153).

Thank you for your advice. I understand current situation. I followed your suggestion#1 (copying) for dark-mode.css.

I installed this extension but it doesn't work, where could the problem be?

You're going to have to provide more detail: did you follow the usage instructions? What exact steps did you take? Are you seeing any error messages?

wfLoadExtension( 'Gadgets' ); in LocalSettings.php

I put the file in the extensions folder, but the tools are not displayed.

I don't get any error.

I also installed other plugins, I know how to install plugins.

My site https://wikidm.org/

Okay, so this extension does not come with any gadgets actually preinstalled; you have to install them all yourself. Read through the usage instructions that I linked in my previous comment for a basic explanation of how to use the extension.

Thank you very much for the advice, I will read again.

Since I just found out about it myself, Gadget kitchen looks like a very good resource as well.

Thank you very much for your persistence and guidance

Hi, I recently converted a gadget on frwikt to ES6 syntax but despite specifying the 'requiresES6' option in the Gadgets-definition page, I get this error: "JavaScript parse error (scripts need to be valid ECMAScript 5): Parse error: Missing ; before statement in file 'MediaWiki:Gadget-CreerNouveauMot.js' on line 55". The thing is, it works on at least another one. What am I doing wrong? Thanks for your help.

Here are some links:

• Gadgets definition: fr:wikt:MediaWiki:Gadgets-definition#Création
• Gadget that does not work: fr:wikt:MediaWiki:Gadget-CreerNouveauMot.js
• Gadget that does work: fr:wikt:MediaWiki:Gadget-Barre de luxe.js

So, new development, it seems that I get this error only when the "default" option is active as well… Are there any compatibility issues between these two options that I am not aware of? I looked at the documentation but found nothing relating to this topic.

Yes, you can't enable an ES6-only gadget by default as by default implies all users/skins/browsers, whereas by definition it would fail in ES5 browers where we do load other gadgets and stylesheets. This leads to compatibility issues, dependency problems, and code complexity that developers likely wouldn't test well given it doesn't affect their own browsers. Such blind spots create inverse incentives, where the "easy" and default behaviour is to create experiences that aren't accessible through no fault of your own.

The requiresES6 feature is a temporary option to allow experimental opt-in gadgets to start using this until we're ready to drop ES5 support for Grade A. See also Compatibility and T178356.

Makes sense, thanks for your answer :) Unless I’ve missed it, I think it should be specified explicitely in the extension’s documentation so anyone can know before finding out too late.

Is it legal to add extra wikitext like categorization and description text after the title in Mediawiki:Gadget-section-X? Something like this

Title

<p style="font-weight: normal; font-size: initial;">
Section description
</p>

[[Category:Section headings]]

seems to work, but can it cause problems later?

@Hunsvotti I would recommend against it. It is a common pattern within Wikipedia communities to use the talk page to categorize interface pages like these. That way the interface script, or interface text remains clean and pure from these organisational types of metadata.

As it stands today, it appears this indeed has no negative side-effects, but it seems like the kind of thing we might change to accomodate something we need in the future. Best to avoid it, I think!

Thanks! Categorizing the talk page didn't even occur to me.