Project:Village Pump

This page is only for discussing issues related to MediaWiki.org site.

To get help with MediaWiki software, ask on Project:Support desk.

Hello! Can you please add a tag for ConvenientDiscussions so that edits are marked not in the description, but in a normal way?

Example: commons:MediaWiki:Tag-convenient-discussions, commons:MediaWiki:Tag-convenient-discussions-description.

Shouldn't we just convert this wiki to DiscussionTools instead?

This is (finally) not an either/or situation. Both CD and DT build on wikitext talk pages (with some basic requirements about the wikitext, like having proper signatures), so the preference is per-user rather than per-page (unlike LQT and Flow, which, once turned on on a page, were forced on everyone). Supporting CD doesn’t happen “instead of” converting the wiki to DT; in fact, the conversion is needed to make CD really usable here.

Yes, but there are already some "regular" pages here, for example Manual_talk:FAQ/ru or Talk:Reading/Web/Desktop Improvements :) But in any case, yes, this wiki will eventually need to be disconnected from the Flow.

Supporting CD doesn’t happen “instead of” converting the wiki to DT; in fact, the conversion is needed to make CD really usable here.

And yet this is asking for special support for a hack that isn't the way forward?

This is not a hack, it's just to make the tool insert normal tags, and not do it in the edit descriptions :) https://www.mediawiki.org/w/index.php?title=User_talk:Iniquity/test&diff=prev&oldid=6216920

I dont see any harm in creating a tag description for any tag people are actually using.

Yes, but there are already some "regular" pages here

I know, this is why I wrote make CD really usable here and not make CD usable here. As long as this wiki is full of Flow boards, CD (and DT) is of limited – but non-zero – use.

a hack that isn't the way forward

In addition to not being a hack, why wouldn’t it be the way forward? The way forward is relying on wikitext talk pages, not forcing everyone to use DiscussionTools. The very idea behind the Talk pages project is acknowledging that people have come to rely on wikitext on talk pages and all the tools built around that, and they shouldn’t be forced into using a new tool (but rather they should have a free choice between DT and other tools).

I likewise see no reason not to go ahead with this - it's just a few clicks for an admin and then will work forevermore. I don't see the point myself either, but if people do then more power to them.

As I understand it, this does no harm, and resolves the thread, so I've boldly created the requested pages, copying (+ `c:`) the strings from Commons over to MediaWiki:Tag-convenient-discussions-description and MediaWiki:Tag-convenient-discussions.

Thanks everyone! :)

@Quiddity, can you please create 'convenient-discussions' tag here: Special:Tags? I didn't check and we forgot about it :(

 Done

Reverted; thank you.

Special:Contributions/177.55.246.233

Report vandalism.

Tracked in Phabricator
Task T353046

FuzzyBot generated numerous empty category pages.

• These pages were previously deleted and have not existed recently.
• The associated translatable page has not been recently marked for translation.

Examples:

• Category:APIAfterExecute extensions/bn
• Category:APIAfterExecute extensions/hu
• Category:APIAfterExecute extensions/pt
• Category:APIAfterExecute extensions/vi

Refer to Special:UnusedCategories for other examples.

Thanks for reporting this issue.

This appears to be a result of running the refresh-translatable-page.php. We've been running this script on wikis to populate the translate-is-translation page props for https://phabricator.wikimedia.org/T299308.

Like P858snake said, I've created a task: https://phabricator.wikimedia.org/T353046 and will look at a way to clean up the empty category pages created.

Regards,

@APatro (WMF) has created a task relating to this https://phabricator.wikimedia.org/T353046

Doh! I thought I had already left a response. Thanks for bringing it to my attention.

Regards,

Hi everyone,

tl;dr The tools we use to document Wikimedia JavaScript code are changing. In the short term, you can read the complete MediaWiki core JavaScript docs using the 1.41 version while we migrate to the new system. If you use JavaScript documentation on doc.wikimedia.org, please share your feedback on Talk:JSDoc WMF theme.

Wikimedia JavaScript codebases are switching from using JSDuck to JSDoc for documentation. Started in 2016, this migration is necessary because JSDuck is currently unmaintained and does not support the ES6 standard. Several Wikimedia JavaScript codebases, including Vector and GlobalWatchlist, already use JSDoc, while several others, such as VisualEditor and MediaWiki core, still use JSDuck.

The migration project consists of two parts: changing the codebases to support JSDoc and improving the usability of the JSDoc WMF theme. For more information, see phab:T138401.

Migrating MediaWiki core to JSDoc

We are migrating MediaWiki core to JSDoc incrementally. While the migration is in progress, the master branch docs will be incomplete, containing only those modules that have been migrated. To read the old JSDuck docs, see the MediaWiki 1.41 docs.

To help with migration, choose a module from the list in phab:T352308, and follow the guide on phab:T138401 to translate the tags from JSDuck to JSDoc.

Migrating other codebases

You can find a list of codebases that use JSDuck on phab:T138401. (Please add any that are missing.) To help migrate a codebase that uses JSDuck, follow the instructions to set up JSDoc, and use the guide in phab:T138401 to translate the tags from JSDuck to JSDoc.

Improving the JSDoc WMF theme

One of the biggest differences between JSDuck and JSDoc is the HTML interface for reading the docs. The WMF theme for JSDoc is not as full-featured as the JSDuck theme, but to support this migration, the Wikimedia Foundation Web, Design Systems, and Technical Documentation teams are working to prioritize and complete a set of improvements to the JSDoc theme, with the goal of releasing version 1 of jsdoc-wmf-theme in 2024.

If you use JavaScript documentation on doc.wikimedia.org, please leave a comment on Talk:JSDoc WMF theme and let us know how you use the docs and which features of the theme are the most important to you.

Respectfully, I'm not sure this is the right place for this sort of announcement. They should go to wikitech-l.

Thanks for this feedback! I thought it would be interesting since it impacts the MediaWiki docs, especially for people following links from Template:Js doclink.

Respectfully, I'm not sure this is the right place for this sort of announcement. They should go to wikitech-l.

It did.

Posting this here so it is more visible, with this being a significant change to the way the main page works.

The Main page currently does not switch Chinese language versions correctly. Where all Chinese variants should be switched to /zh, currently only users who select zh will see the Chinese translation and all varients will see the english page. For example see MediaWiki/zh compared with MediaWiki/zh-Hans. I originally noticed this on Wikifunctions, and since the Wikifunctions main page was based on the one here I also checked and it is also an issue here. I recently proposed and edit to fix right-to-left on the main page after discussion with User:Quiddity on the issue at Wikifunctions.

The changes: I have updated MediaWiki/sandbox and Template:Main_page/sandbox and as you can see by sandbox/zh and sandbox/zh-Hans this correctly switches the language, I also removed the language switch from the template and moved it to the main page as this is the way I found that worked. After discussing with User:Tacsipacsi, I also changed Template:Main_page to use Module:Caller title as this appears to be the better approach, instead of my original solution to the problem.

Overall I am looking for this update to be added by an administrator so that Chinese language switching can be fixed as well as using the caller title module but also for it to be checked since I can't preview the change. I have already added it to Wikifunctions if you want to check it there, but there may be issues that I have missed with this change.

It feels utterly stupid to me that we have to add special-case code for Chinese for the generic pattern "show a page in the user language". But whatever. (Not an objection to another admin doing this)

Maybe the translation extension should follow File:MediaWiki fallback chains.svg. Not sure if there is a ticket for this.

Thanks for proposing this change.

For confirmation, should we replace MediaWiki with the following (by removing sandbox/)?

{{#if:{{#invoke:String|match|s={{int:lang}}|pattern=zh-|plain=true|nomatch= }}<!--IF: Chinese variants
-->|{{Main page/zh}}<!--/zh
-->|{{Main page/{{#ifexist:Template:Main page/{{int:lang}}|{{int:lang}}|en}}}}<!--/language or /en
-->}}{{NOEXTERNALLANGLINKS}}<!--
-- To edit what appears on this page,
-- please see [[Template:Main_page]] 
-- https://www.mediawiki.org/wiki/Template:Main_page
-->

And for Template:Main page, do we just apply the exact same content in Template:Main_page/sandbox?

**Steps to replicate the issue** (include links if applicable):
* I activate in my Preferences the numbering of sections to check right indentation -> https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-gadgets:
[X] Heading Anchor: Adds section anchors to each wiki page heading. They become visible on hover. (Vector skin only)
[X] Auto-number headings
*  i open page -> https://www.mediawiki.org/wiki/Help:Controlling_search_engine_indexing

**What happens?**:
*  TOC is disabled there using **__NOTOC__** in the source, section numbering shows :


>     1 Software settings and robots.txt
>         1.1 Software settings
>         1.2 Robots.txt noindexing
>     2 NOINDEX magic word
>         2.3 Individual pages
>         2.4 Standard template noindexing
>     3 INDEX magic word
>         3.5 Individual pages
>         3.6 Current issues
>     4 Footnotes

**What should have happened instead?**:
* notice that headers == follow logical numbering, -> ok
* notice that headers === are cumulated, they do not restart from 1 each time we change the parent
* notice that once TOC is reenabled (deleting the tag line), the section numbering is correct : 
>     1 Software settings and robots.txt
>         1.1 Software settings
>         1.2 Robots.txt noindexing
>     2 NOINDEX magic word
>         2.1 Individual pages
>         2.2 Standard template noindexing
>     3 INDEX magic word
>         3.1 Individual pages
>         3.2 Current issues
>     4 Footnotes
* so i ask section numbering to be realigned such as to display this last format and be independant from the presence of tag __NOTOC__

This needs to be posted on Phabricator.

Really funny ! it has just been rejected from there -> https://phabricator.wikimedia.org/T348221 --Christian 🇫🇷 FR (talk) 16:46, 5 October 2023 (UTC)

Oh! Sorry about that, I forgot that heading auto-numbering had been removed from MW core.

I'll try and take a look at the problem

The logic (MediaWiki:Gadget-autonum.css) seems fine---higher levels reset lower level counters, and each heading increments its corresponding counter. From playing around in inspect-mode a bit it seems that the counter-reset operations are not working on the higher number counters: counter-reset: autonum-h3 autonum-h4... in an h2 isn't doing anything. I suspect a scoping/shadowing issue due to the use of reset (changing to set instead of reset, like counter-set: autonum-h3 0 autonum-h4 0.. seems to fix it on that page at least).

Hello everyone, I am new to the world of MediaWiki and have a question about SCSS. So far I have only been able to find limited information on this topic. My specific question is: Is it possible to convert my Styles.css template into an SCSS file? If so, what is the best way to do this?

Many thanks in advance for your help!

Since all CSS is SCSS, you can just save your CSS file as a .scss file and it will be SCSS. Is there a certain application you have in mind? I'm struggling to understand why this would be helpful, but I'm not a very smart person.

If you weren't smart, you wouldn't be here :) The point is. We have a very large collection of CSS code and templates on our wiki page under Templates:Style.css, Templates:Styles-min769.css etc.. My colleague thinks that the page would be faster if the whole thing was implemented with Scss or Sass. As I am a newcomer to Mediawiki and the world of CSS preprocessors, I have to familiarise myself first.

This is another not-so-great answer, but you can look thru tickets at Phabricator such as those found here: https://phabricator.wikimedia.org/search/query/ktexKDhOVZs1/#R or here: https://phabricator.wikimedia.org/search/query/srWzSOQOZOnX/#R or here: https://phabricator.wikimedia.org/search/query/pAisUpvFM8MG/#R to get an idea of what kind of discussion has occurred with using precompilers and which requests are open. That may help give you some understanding, in addition to what I hope is a more instructive answer from someone else.

@Koavf Thank you for your help

MediaWiki has many different css files and places where you can put/use them. Each location has their own benefits, downsides and capabilities.

Templates:Style.css Templates:Styles-min769.css. makes it sound like you might be using Extension:TemplateStyles. In that case, NO, you cannot currently use sass/scss/less for templatestyles. But when using TemplateStyles, you are also not using pure css, you are using a sanitised version of css, which adds prefixes and css property allowlists. TemplateStyles are useful for a limited amount of styling. Think of them as styles that go with a html web component or a vue component or a subset of pages.

You can't go faster than pure css as scss itself gets processed and turned INTO css. At most you might argue that it is faster for development.

Extensions CAN use less (similar to, but different from sass). When working with extensions, I advise you to read ResourceLoader/Developing with ResourceLoader. MediaWiki has its own asset manager called Resource Loader which predefines the asset bundles and allows for code segmenting and on demand loading and postprocessing of resources, that you will have to integrate with when writing extension logic.

Some general principles:

1. Styling and layout for the non-content parts of pages, goes into the skin
2. Small adaptations to an existing skin go into MediaWiki:skinname.css
3. Styling for the widgets (buttons etc) can be done as a seater OOUI theme (OOUI is the widget and design set used by MediaWiki)
4. Styling for content goes either into MediaWiki:Common.css (loaded on every single page)
5. Or if it is only used by specific templates, into TemplateStyles.
6. Styling for your own customer functionality goes into Extensions.
7. Styling for custom functionality used only by some users goes into Extension:Gadgets

Hi all, I'd like to share a new way to set up a local development environment for MediaWiki: Local development quickstart.

The purpose of the quickstart guide is to provide the shortest, simplest path to running MediaWiki locally for people who don't want to use Docker. The goal is to eventually replace the Local installation section on How to become a MediaWiki hacker with a link to the quickstart guide. For more background information, see T347347 on Phabricator.

If you're interested in helping test the quickstart guide, please share your feedback on the talk page or on the Phabricator task. For feedback about MediaWiki development environments in general, I've started a comparison of available options and key pages on Project:Development environments.

Thanks to @Timo Tijhof (WMF) for all his help with this project! I've documented his excellent copy-to-clipboard gadget on Project:Code samples.

This is looking REALLY good. Very readable. Hope to test it soon.

Hello everyone, I took over a project from a colleague this week and have the following problem when updating from Fontawesome 5 to Fontawesome 6. I would like to add that I am a complete newcomer to the Mediawiki world. Since this is a local environment, I don't have an official website for you. Key data:

MediaWiki 1.39.5 (e53adb1)

06:49, 7 Apr 2022

PHP 8.1.25 (fpm-fcgi)

MariaDB 10.5.19-MariaDB-0+deb11u2

ICU 67.1

Debian Distribution

Nginx

We use our own icons, which are integrated via gitlab. If I now install Fontawesome 6 Pro and integrate it into my main.scss:

$fontAwesomeFont:'Font Awesome 6 Pro';

@import 'variables';

@import 'sp-sass/scss/style';

@import 'fontawesome-pro/scss/brands';

@import 'fontawesome-pro/scss/duotone';

@import 'fontawesome-pro/scss/light';

@import 'fontawesome-pro/scss/regular';

@import 'fontawesome-pro/scss/solid';

@import 'fontawesome-pro/scss/v4-shims';

@import 'fontawesome-pro/scss/fontawesome';

@import 'glyphicons/glyphicons/glyphicons';

@import 'glyphicons/halflings/glyphicons-halflings';

@import 'spicons';

@import 'modules/sidebar';

@import 'wiki';

@import 'modules/content';

@import 'modules/searchForm';

and recompile the assets, the custom icons are no longer displayed. I found a place in the source code that causes problems: .fa-slash-back::before If I delete this, everything works. I have no idea why this is happening and hope you can help me. I hope I could give you enough information.

There's a thread on the English Wikipedia's Village Pump that would be of interest to MediaWiki devs. As you can see, once the idea is brought up, a large fraction of editors believe being able to mark edits as minor is a bad idea and should be removed. (Disclaimer: I am not a neutral party and am one of the biggest proponents of this idea.) Jason Quinn (talk) 08:52, 28 August 2023 (UTC)

Proper link for convenience: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(policy)#Proposal_to_remove_%22rearrangement_of_text%22_from_definition_of_minor_edit.

That's mostly just en.wp's business. They tell us what they want and we go do it. We already have support in mediawiki for restricting who can make minor edits on a per usergroup basis.

Perhaps devs should question the raison d'etre of the "minor edit" toggle. The claim being discussed is that it is an anti-feature because it does not reliably convey the information it is intended to convey and that this is largely because the concept a "minor edit" itself is ambiguous to the point of being partly useless. The same will be true for all languages. Therefore it should be totally turned off for all languages going forward, not just the English Wikipedia because that community wanted it but because is a bad software design idea (ie this perhaps is more of a development topic than a community issue).

I don't know Mediawiki's codebase but if it's possible maybe all traces of "minor edit" code could be removed completely. That code could be split off into some sort of plugin or patch that enables it if installed. The patch should also have a toggle to have the feature actually turned on or not on the wiki. This approach covers all bases: it excises the minor edit feature from brand new wikis while allowing wikis that want "minor edits" for some reason to still have it whilst also satisfying legacy wikis that don't want "minor edits" but that regrettably need to have it (eg so that past conversations regarding edits that mentioned their minor edit status still makes sense).

Get an rfc on meta if you want it killed across all projects. En.wp certainly doesn't speak for the rest of wikimedia.

As far as if it is a good idea. Meh, wouldn't be the first time mediawiki had a feature that turned out to be a bad idea. Maybe it would get removed if it became clear everyone hates it across the board, but we are nowhere near that stage yet.

In terms of pure practicality - extensifying it might be difficult in its current form. It currently involves extra fields in the revision and recentchanges tables, which is something extensions aren't supposed to do. Probably the way to extensify it would be to reimplement it as a special purpose edit tag. Honestly that sounds like quite a bit of work that's not worth it. If enough people like it we would probably just keep it with an off switch, if nobody wants it it would probably just be removed. (To be clear, i dont speak for other devs or the WMF, they may disagree with me)

More specifically, this would be "complete restriction of…", we won't drop the functionality, just who can use it.