Meta:Babel

← Index of discussion pages

Babel

archives (latest) →

This is the general discussion forum for Meta (this wiki). Before you post a new comment please note the following: You can comment here in any language. This forum is primarily for discussion of Meta policies and guidelines, and other matters that affect more than one page of the wiki. If your comment only relates to a single page, please post it on the corresponding discussion page (if necessary, you can provide a link and short description here). For notices and discussions related to multilingualism and translation, see Meta:Babylon and its discussion page. For information about how to indicate your language abilities on your user page ("Babel templates"), see User language. To discuss Wikimedia in general, please use the Wikimedia Forum. Consider whether your question or comment would be better addressed at one of the major Wikimedia "content projects" instead of here.

Wikimedia Meta-Wiki

• About Meta
• Discussion pages
• Request pages
• Policies and guidelines
• Information and statistics
• Categories
• Help pages

Participate:

• How to edit a page
• Meta-Wiki discussion page
• Meta-l mailing list

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

Bot to automatically protect highly transcluded templates and modules

A few days ago Meta experienced a wave of vandalism to a lot of highly-transcluded templates. We've experienced the same issue time and time again on English Wikipedia, so since January 2019 we've had a bot that automatically protects templates and modules that have a certain number of transclusions. I am proposing we do the same here on Meta. The bot is configurable, where you can define what thresholds should trigger what levels of protection. There is no "template editor" rights on Meta, so I'm recommending something like:

• Semi-protect templates with over 500 transclusions
• Fully-protect templates with over 5,000 transclusions

This is ran once a day. The bot only looks for unprotected templates, and will ignore any templates were recently unprotected or if they are title blacklisted. Additionally, you can exclude templates from being automatically protected (by exact title or regular expression). Examples on English Wikipedia are subpages of w:Template:POTD. The subpage for the current day has about ~500 transclusions which include only low-visibility pages, and come the next day that template has zero transclusions. So there's no point in protecting them. All of this configuration can be done on-wiki, so the community can change it without having to go through the bot maintainer.

Thoughts? If you like the idea, do you have any alternative suggestions for the thresholds? Regards — MusikAnimal ^talk 19:29, 8 November 2019 (UTC)

I think this is a good idea and absent native MediaWiki support to automatically apply protection/restrictions on highly transcluded NS_TEMPLATE/NS_MODULE pages as locally configured (hi Community Tech :-P ) I support the idea of this bot as long as you're the operator. I don't like the idea of adminbots being operated by non-admins. Thanks. —MarcoAurelio (talk) 19:43, 8 November 2019 (UTC)

I was bold and created task T237814 proposing this to be added to MediaWiki core or a separate extension. Until such a thing happens, if ever, I still support your proposal. I'd even go further and make the Module namespace editable only by Autoconfirmed users, but that can be discussed in a separate thread if needed. —MarcoAurelio (talk) 16:31, 9 November 2019 (UTC)

Can you do a dry run and produce a list? — xaosflux ^Talk 01:04, 10 November 2019 (UTC)

I'm not sure if it'd be a good idea to list all vulnerable templates on-wiki for vandals to have fun in the meanwhile? Maybe a private Phabricator paste. Best regards, —MarcoAurelio (talk) 19:59, 11 November 2019 (UTC)

@Xaosflux and MarcoAurelio: I added you both as subscribers to phab:P9603. This the log output of the bot (apologies for the lack of sorting). I don't immediately see any pages that need to be excluded. — MusikAnimal ^talk 04:42, 13 November 2019 (UTC)

I don't know if number of transclusions is a good metric for this. Perhaps a better measurement would be the combined number of pageviews from all transcluding pages. --Yair rand (talk) 23:37, 20 November 2019 (UTC)

Restrict anonymous users from editing pages in the CNBanner namespace

Tracked in Phabricator
Task T238723 Resolved

Hi, I suggest that we restrict editing to CNBanner namespace from anonymous users and allow only autoconfirmed users to edit that namespace. These (Central Notice banners) attracts a lot of bad faith and test edits because of their high visibility on top of the Wikipedia and other projects. Currently there is Wikipedia Asian Month in progress and the central banner is everywhere asking to translate the 2 short messages. In 3 days I've alone deleted 69 pages in CNBanner namespace (created by anonymous users) and reverted over 30 edits (I colledcted here my logs). It's more useful to use admin and patrollers' resources to something more useful than this. If we get consensus we can ask a configuration change in Phabricator. Best regards, Stryn (talk) 18:12, 12 November 2019 (UTC)

Strong support --Krd 18:29, 12 November 2019 (UTC)

Yes please. —MarcoAurelio (talk) 19:52, 12 November 2019 (UTC)

Holy yeah — regards, Revi 08:08, 13 November 2019 (UTC)

Is this more of a "don't allow" anonymous creation of translations in that space? This may be able to be done with an edit filter. — xaosflux ^Talk 12:19, 13 November 2019 (UTC)

A filter in the meanwhile to restrict anons on that namespace is indeed simple and effective, but can only work as a temporary workaround. If we want to put permanent restrictions in place I think they're better handled in the Code itself. Note that each enabled filter does spend at least one condition, and we need them, Meta being the home of local and global abuse filters. Moreover, if a filter gets triggered too much, some actions might get automatically disabled, loosing effectivity. That said, I think a filter until this is implemented would be okay. Thanks. —MarcoAurelio (talk) 15:27, 13 November 2019 (UTC)

Will the filter prevent to start editing the page, or only to save the edit? --Krd 17:06, 13 November 2019 (UTC)

@MarcoAurelio: I'm not exactly sure what needs to be stopped here, but the local MediaWiki:Titleblacklist (along with the noedit and autoconfirmed) parameters may be a solution, without consuming filter cycles. — xaosflux ^Talk 18:42, 13 November 2019 (UTC)

Probably the best idea! --Krd 19:58, 13 November 2019 (UTC)

@Stryn: can you provide a sample list of pages, especially if the list can determine a "pattern" (e.g. "starts with"; "starts with, then contains"; etc?) — xaosflux ^Talk 21:13, 13 November 2019 (UTC)

I've just made Special:AbuseFilter/4. —MarcoAurelio (talk) 21:20, 13 November 2019 (UTC)

(ec) There was a link to "logs". The current pertinent string is CNBanner:Asian month 2019-text though maybe we just do the namespace.  — billinghurst sDrewth 21:21, 13 November 2019 (UTC)

• Comment to local title blacklist I have added an immediate solution for the immediate problem and allows time for discussion about what is realistic.  — billinghurst sDrewth 21:30, 13 November 2019 (UTC)

  @Billinghurst: was the only problem "creating" pages, if it is also editing, that entry may need the 'noedit' parameter. — xaosflux ^Talk 21:36, 13 November 2019 (UTC)

  No, I went the minimum to lessen the noise, and easier to ramp it up. This to the worst part of the problem with regard to having to delete. Easier to revert the others, and the diff in MA's filter can be used.  — billinghurst sDrewth 21:41, 13 November 2019 (UTC)

Done: phab:T238723. So maybe it can be removed from a local title blacklist + abuse filters. Stryn (talk) 11:13, 21 November 2019 (UTC)

Done — xaosflux ^Talk 00:29, 22 November 2019 (UTC)

 This section is resolved and can be archived. If you disagree, replace this template with your comment. 94rain ^Talk 02:59, 14 December 2019 (UTC)

How and where to request activation for WMF projects of the Jmol extension?

as the title suggests, I would be interested in understanding how and where to request activation of the Jmol extension, existing on mediawiki, for wikipedia pages. ---Griot Matteo (talk) 21:22, 18 November 2019 (UTC)

Griot Matteo: Tech issues are handled at Phabricator. Usually, a feature (extension, gadget...) is requested after being discussed on a wiki and being accepted by the community. Esteban16 (talk) 23:12, 18 November 2019 (UTC)

thanks -Griot Matteo (talk) 07:08, 19 November 2019 (UTC)

Also please note that extensions which ain't deployed on any Wikimedia site must first pass mw:Review queue, security review, design review and some other approvals. It's a long and complex process. —MarcoAurelio (talk) 17:32, 19 November 2019 (UTC)

Temporary read-only on 26th November 2019

There is a temporary read-only time scheduled for meta-wiki on 26 November at 06:00 (UTC). You will be able to read but not to edit this wikis for up to 30 minutes. It will probably last much shorter than 30 minutes. This will also affect the centralauth database. This could for example affect changing passwords, logging in to new wikis, changing emails or global renames. For more information, see linked phabricator task. -- Kaartic ^{correct me, if i'm wrong} 18:02, 19 November 2019 (UTC)

Thanks for the warning. Best regards, —MarcoAurelio (talk) 19:35, 19 November 2019 (UTC)

Extension used by Special:Contact/

Does anyone know what extension is being used, and where that data ends up stored, by the page Special:Contact/affcomusergroup? T.Shafee(Evo﹠Evo)^talk 03:41, 25 November 2019 (UTC)

@Evolution and evolvability: its the ContactPage extension - see code on gerrit and documentation on mediawiki --DannyS712 (talk) 04:02, 25 November 2019 (UTC)

@DannyS712: Thank you! —The preceding unsigned comment was added by Evolution and evolvability (talk) 04:35, 25 November 2019‎ (UTC)

 This section is resolved and can be archived. If you disagree, replace this template with your comment. 94rain ^Talk 02:59, 14 December 2019 (UTC)

Padlock overhaul

Since late 2018, English Wikipedia, Wikimedia Commons and some other Wikimedia projects no longer use old ​File:Padlock-COLOR.svg​ padlocks. The new design is intended to be informative, simple and up-to-date. c:Category:Page Protection Padlock Redesign (2018) shows all new icons by their color.

Meta still uses old padlocks. Since they have been created in 2007, they represent a somehow old design. Also, they aren't informative for new users. Another problem is that all padlocks on Meta currently link to English Wikipedia's protection policy, which uses the new padlock design. I suggest we change all the padlocks. Since Meta is a multilingual project, I suggest we use symbol-based padlocks instead of letter-based ones. I have provided a list of suggestions in the table below:

Type	Old	New	Alternatives
Semi-
Extended
Create
Move
Upload
Pending
Template-
Permanently
Full
Office
Cascade

I can conduct the change if no oppose rises within one or two weeks. Thank you. Ahmad^talk 15:45, 5 December 2019 (UTC)

@Ahmad252: can you point to some examples of these in use? I just checked 10 semi-random pages from Special:ProtectedPages and don't see these being used at all. Also meta-wiki does not have all those levels, and does have other levels. — xaosflux ^Talk 16:45, 5 December 2019 (UTC)

One lock is enough. This is not English Wikipedia nor Commons. Stryn (talk) 16:50, 5 December 2019 (UTC)

@Xaosflux and Stryn: Yes, I see. Although Meta doesn't have all of them, Module:Protection banner/config does. Removing them from the module shouldn't be difficult, but I think they may become useful in the future. This change won't effect a lot of pages, as Module:Protection banner is only used in less than 250 pages, and all those pages are templates/modules. This means that only >250 pages currently have a padlock, so the change is, in my opinion, fairly uncontroversial. The purpose of this proposal is mainly changing the fully-protected padlock, but I think changing them all is a better idea. Of course, we can remove the additional padlocks from the module and change only one or two padlocks. Ahmad^talk 16:59, 5 December 2019 (UTC)

Even as an experienced user, I find the new padlocks much more helpful. I support this change. ~riley (talk) 17:51, 5 December 2019 (UTC)

The symbols make no sense at all, and the colours are deeper so the blues and greens look nearly identical on some screens. They are substantially less informative and are probably the worst design choice en.wiki has made in a while. Given it's not a huge deal, but the new ones really are hideous as icons go. TonyBallioni (talk) 01:58, 12 December 2019 (UTC)

I don't get it. Why are they "less informative"? I mean, what can we understand a green padlock, and what is the difference between a green and a purple padlock? Can you guess what they mean if you have never been active in Wikimedia projects before? Ahmad^talk 16:59, 12 December 2019 (UTC)

I edit at night because I work in the day. Like many editors, I have my computer set to night mode so I can go to bed at some point. This is a common setting on most devices used to access the internet these days. I can't tell a difference between create, move, and cascade protections, and extended looks very close. Pending and semi-protection also look identical. To the significant portion of the editing population that has a day job and edits when they get off of work, substantially less information is conveyed if they use the settings that are recommended for being on a computer at night. This is only a problem with the new ones, not with the old ones. The weird symbols convey no meaning and the only one I'd be able to guess is upload protection. The rest are just random symbols that don't appear to have any relationship to what the protection is. So yes: the new ones aren't really compatible with the night modes that are common on new computers these days, making them less informative. TonyBallioni (talk) 01:23, 13 December 2019 (UTC)

• Meh. The en.wiki overhaul didn't really do anything and the old version looks nicer. The new versions are ugly and despite the claim during the en.wiki implementation, don't convey any additional information unless you already know what they mean. Oppose as not needed on meta and in addition to being ugly. TonyBallioni (talk) 01:50, 12 December 2019 (UTC)
• Comment I think that we only use semi- and full, so 1) I don't think it matters either way, they are indicators only; 2) that the change makes little difference to what happens here. That two wikis have moved is neither here nor there and many wikis use the old schema. That said, I am okay about updating the two templates that we use; though I do not wish to see a further implementation of a more convoluted scheme. KISS principle works here.  — billinghurst sDrewth 02:42, 12 December 2019 (UTC)

  Further comment: Both modules are fully protected so only admins will making any changes. Ping to importer and protecter ... @MarcoAurelio:  — billinghurst sDrewth 02:47, 12 December 2019 (UTC)

  @Billinghurst: Please see my comment above. I listed all the padlocks, beacuse they are included in the module. Changing them will not affect anything now, but if we add a, say, extended-protection level in the future, the padlock will be of the type I've suggested above. In fact, the only visible changes are full and semi-protection padlocks. Ahmad^talk 16:55, 12 December 2019 (UTC)

• In my course as an admin on Meta, I have never seen or used an template (for the padlocks and others) -- do we really use it - or put it other way, do we really need it? — regards, Revi 01:44, 13 December 2019 (UTC)

  @-revi: I don't think we really need them at all, and it looks like the only place they are really in use at all is via templates with documentation pages called by another template, that calls a module, that calls another module (Module:Protection banner), that calls the lock template, that then uses these icons. That being said, I don't really have any problems with changing the icon file. — xaosflux ^Talk 03:17, 13 December 2019 (UTC)