Meta:Babel

From Meta, a Wikimedia project coordination wiki
(Redirected from Babel)
Jump to navigation Jump to search
 ← 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
This box: view · talk · edit
Filing cabinet icon.svg
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[edit]

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[edit]

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)

Symbol strong support vote.svg 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 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)
Yes check.svg Donexaosflux Talk 00:29, 22 November 2019 (UTC)

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

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[edit]

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/[edit]

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)

Padlock overhaul[edit]

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- Padlock-silver.svg Semi-protection-shackle.svg Semi-protection-shackle-dual-color.svg
Extended Padlock-blue.svg Extended-protection-shackle-check-mark.svg
Create Padlock-skyblue.svg Create-protection-shackle.svg
Move Padlock-olive.svg Move-protection-shackle.svg
Upload Padlock-purple.svg Upload-protection-shackle.svg
Pending Padlock-silver-light.svg Pending-protection-shackle-double-ticks.svg Pending-protection-shackle.svg
Template- Padlock-pink.svg Template-protection-shackle-brackets.svg Template-protection-shackle-brace.svgTemplate-protection-shackle-brackets 2.svgTemplate-protection-shackle-picture-1.svg
Permanently Interface-protection-shackle-keyhole.svg
Full Padlock.svg Full-protection-shackle-block.svg Full-protection-shackle-double.svgFull-protection-shackle-keyhole.svg
Office Padlock-black.svg Office-protection-shackle-WMFlogo.svg
Cascade Padlock-turquoise.svg Cascade-protection-shackle.svg Cascade-protection-shackle-double-chain-link.svg

I can conduct the change if no oppose rises within one or two weeks. Thank you. Ahmadtalk 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. Ahmadtalk 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)