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.

For a significant period, Category:MediaWiki configuration settings 1.40.0 and Category:MediaWiki configuration settings introduced in version 1.40.0 have had overlapping content (with similar overlaps found in other versions).

This revision removes pages from the category mentioned earlier.

Special:Diff/845365's edit summary: "Add a category for deprecated configuration settings; add a category for when a configuration setting was introduced that is redundant with an existing category, but that matches the naming style of the deprecated and removed categories."

What are your thoughts?

I see no need to have two sets of categories containing exactly the same pages.

Agreed

The phrasing of "MediaWiki configuration settings 1.x.x" has always bothered me. "MediaWiki configuration settings introduced in version 1.x.x" is way better. I agree with the proposal.

Deleted as requested

Can an interface administrator (someone with interface editing + any user group that is able to delete pages) please delete these pages when appropriate? They were nominated for deletion by the page creator.

I would personally prefer that these pages be history merged into the corresponding MiniEdit pages rather than deleted, but I have no good reason for that and am fine with another Iadmin deleting without history merging.

Not strictly related to the deletion, but I have some questions:

• Why the user was able to edit the MediaWiki namespace without being interface-admin? Maybe he can delete those pages as well.
• Why it hasn't been created as a gadget here, despite the installation instructions recommending it?

The user that requested deletion has global interface editor permissions to create/edit those pages, but it appears they cannot delete pages.

It looks like GIE needs to be given move rights… Although I'm not sure what the envisaged scope of the group was. but "creating" pages instead of moving has potentially broken history (and any licensing requirements that it needs)

Perhaps moving/history merge could be done instead, if that is somehow possible.

History merge will probably don't work here, since the source page was edited after creating the target page. And to make things even more complicated, the content model was changed too. Doing the "old school" merge history of deleting target page, move old to new, delete and then restore specific revisions should work, but that's always a bit involved.

Bringing @Sophivorus attention just for awareness sake.

Hi guys, sorry for all the trouble. Given all these complications, and since I'm the only author of the page, and I really don't mind losing the history, if @Pppery agrees, I'd say just delete it with no history merge. Else, doing the old-school merge would be fine too, as far as I'm concerned. I'll try to avoid causing these complications in the future, cheers!

When my currently pending request for interface adminship is granted, I'll do a history merge. Any existing Iadmin is free to push the delete button in the meantime. The problem is that none appear to be watching this thread.

Hello @all

My hosting services entry is only visible in english, how I get it visible also for other languages, for e. g. german?

The issue seems to be fixed by a bot (FuzzyBot), but I couldn't figure out how to translate the contents of the table, is there a way? Translate doesn't show table content, as far I could see.

What kind of feedback are you referring to?

Are you saying it is not visible at https://www.mediawiki.org/wiki/Hosting_services/de or that the blurb isn't in german?

It looks like it is visible now (there may just have been a delay). If you want the blurb to be translated, you have to surround the english version of the blurb in <translate>Text to translate</translate>.

That it isn't in german. I have added the translate tags and will wait till the bot adds my changes.

It also has to wait for someone to make the translation

https://www.mediawiki.org/w/index.php?title=Special:Translate&group=page-Hosting+services&action=page&filter=%21translated&language=de

Thanks, it's done.

Hello @all

I wanted to add my hosting service including external link to my hosting business to Hosting services. But I'm not allow to add a external link, can someone tell me how to proceed?

You should be able to do so now.

Thanks, it worked.

Could an interface admin please handle the request at MediaWiki talk:Mobile.css? Thanks.

Done

A minor request. The external link in this section of page Extension:FontAwesome still links to the older version (v5). Please update it as normal users are apparently unable to edit an external link.

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.

More languages • Please help translate to your language

Hello all,

I am pleased to share the next step in the Universal Code of Conduct work. The Universal Code of Conduct Coordinating Committee (U4C) draft charter is now ready for your review.

The Enforcement Guidelines require a Building Committee form to draft a charter that outlines procedures and details for a global committee to be called the Universal Code of Conduct Coordinating Committee (U4C). Over the past few months, the U4C Building Committee worked together as a group to discuss and draft the U4C charter. The U4C Building Committee welcomes feedback about the draft charter now through 22 September 2023. After that date, the U4C Building Committee will revise the charter as needed and a community vote will open shortly afterward.

Join the conversation during the conversation hours or on Meta-wiki.

Best,

RamzyM (WMF), on behalf of the U4C Building Committee, 15:34, 28 August 2023 (UTC)

User page request that was outside of scope

can you make my page unprotected

https://www.mediawiki.org/wiki/API:Allredirects

The doc on that page could use a lot of additional leading "target-"(redirect) edits in my view. To potentially eradicate the ambiguity that this call might potentially be used to only list source redirects. Which it can't/don't.

:-/

Sorry, but I don't understand what's your request and what do you mean with "target-"(redirect).

Would you like to elaborate?

While writing my initial reply I realized that apart from there being:

A) pages that contain a redirect statement.

B) pages that are targeted by a page containing a redirect statement.

One also has:

C) pages that link to pages that containing a redirect statement.

(ergo: Case A can be seen as source or target depending on your mindset.)

This last one(C) trows a wrench in my thinking (and initial reply).

As I'm now completely lost about which cases (A,B, or potentially C) the API:Allredirects doc might be talking about when its using the words "redirect"/"redirecting" or source" vs "target".

Sorry if this is of no help.

(local minor-headache not helping either :-/ )

This api returns the redirect target (case B)

Ok ...

But is the first line on the API:Allredirects page "List all redirects to a namespace" not highly ambiguous in this respects ?

In my view it seems easily misread in that Allredirects is targeting/returning A-cases(source?) instead of B-cases(target?).

The additional arunique parameter text "When used as a generator, yields target pages instead of source pages." seems to suggest the same (if one ignores the potential C-case).

I know its a fine line for doc's between being concise and being to-concise. The Allredirects page seems to me to be way to-concise on its "redirect" parts. (especially in one takes the C-case in account)

Thinking about the Allredirects page is giving me a headache again. ... So I'll leaf it at that.

Okay, I've edited the page to hopefully make it more clearer. Feel free to improve it. However, most of the page is autogenerated by the api help itself, which would require code changes to improve the documentation.

Actually, A, B and C are "correct". Redirects are a tuple of redirect source and redirect target, and this api is supposed to return that list, but not always. It depends on the parameters. The title refers to the redirect target, but if you make it return the ids, those ids refer to the redirect source.

The best way to see how it works is by testing the api itself.

If you check Special:WhatLinksHere for Project:About, listing only redirects, you get currently 13 results.

The same results you can get using the api with from and to = About, and namespace Project (not very useful output), and the same as generator (the output is the same but titles reflect redirect source instead of target).

Note how "About" in the filters doesn't include the Project: namespace, because it's included in the namespace filter. Adding the namespace manually on the title filters will result in an error (!)

But this usage is not very useful, because that's what API:Redirects returns. The only usefulness of this api IMHO is using it as generator, with "from" and "to" pointing to the same page (a bit awkward), or setting the "unique" parameter.

Thanks at least for the API:Allredirects page edit, and additional information here.

Not sure when I will delve back into Allredirects again though. For the moment my redirection-related thoughts are still too jumbled up for that.