Open main menu
 ← 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.
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.

Import requestEdit

Copy from d#Auto-updating_WiR_table

I'm in the process of writing some templates to be able to make the Wikipedian_in_Residence table easier to maintain using wikidata. In order to implement w:Template:WiR_table_row here, could I request the import of:

  1. w:module:WikidataIB/sandbox to outreach:module:WikidataIB
  2. w:Template:WiR_table_row to outreach:Template:WiR_table_row
  3. w:Template:WiR_table_start to outreach:Template:WiR_table_start

Let me know if you think there are better locations for it to be hosted than on outreachwiki.

Thank you! T.Shafee(Evo﹠Evo)talk 12:19, 27 September 2019 (UTC)

  Not done @Evolution and evolvability: Meta users are unable to assist with outreachwiki imports. Please talk to their admins.  — billinghurst sDrewth 00:28, 28 September 2019 (UTC)
@Billinghurst: Ah, thanks. I thought there was more overlap. I'll talkpage message a few people on that list. T.Shafee(Evo﹠Evo)talk 01:55, 28 September 2019 (UTC)

Updated request to import to meta: Outreachwiki had lower activity than I thought. Per this discussion, it might be better to implement the table on meta at Wikipedian in Residence. Therefore could I update my import requests to be to this wiki:

  1. w:module:WikidataIB/sandbox to module:WikidataIB
  2. w:Template:WiR_table_row to Template:WiR_table_row
  3. w:Template:WiR_table_start to Template:WiR_table_start

Thanks! T.Shafee(Evo﹠Evo)talk 01:39, 2 October 2019 (UTC)

To do this we need (per phab:T171140 IIRC) Wikidata to support linking to outreachwiki, and outreachwiki supports query datas from Wikidata, Otherwise nothing can work here. @Lydia Pintscher (WMDE): Do you know when outreachwiki will get it? --Liuxinyu970226 (talk) 11:05, 6 October 2019 (UTC)

@Evolution and evolvability: what are you trying to do and can I help? --mikeu talk 00:48, 23 October 2019 (UTC)

@Mikeu, Liuxinyu970226, and Lydia Pintscher (WMDE): Originally I'd intended to get this table working in outreachwiki, but it's been suggested that it'd actually be more sustainable to move the table over to meta instead (discussion). It would therefore be good to import into meta the w:module:WikidataIB/sandbox and the templates listed above if that is possible. T.Shafee(Evo﹠Evo)talk 04:20, 23 October 2019 (UTC)
@Evolution and evolvability: I can import at outreach if that would be useful. I don't have permissions to do this on meta. --mikeu talk 05:50, 23 October 2019 (UTC)
@Mu301: That'd be great if possible! If you can import to outreachwiki, I'll also see if I can get someone to import to meta so that the content can be at either. T.Shafee(Evo﹠Evo)talk 07:16, 27 October 2019 (UTC)
@Billinghurst: Would you be be happy to import those pages to meta (above)? Thanks! T.Shafee(Evo﹠Evo)talk 07:16, 27 October 2019 (UTC)
Imported two templates and corresponding documentation pages. Importing the module especially from a sandbox without further comparison of versions hasn't been done; I always seek the opinion of @RexxS: about versions of their module, and which we should be importing.  — billinghurst sDrewth 07:27, 27 October 2019 (UTC)
@Evolution and evolvability: maybe see how the local version of module:WikidataIB works first and then we can work on what RexxS advises.  — billinghurst sDrewth 07:29, 27 October 2019 (UTC)
@Billinghurst: For the test to work, the features at w:module:WikidataIB/sandbox may be required. Should the sandbox subpage be implemented into the module at wikipedia before importing here? (@RexxS: let me know if I've misunderstood anything). T.Shafee(Evo﹠Evo)talk 07:41, 27 October 2019 (UTC)
@Evolution and evolvability: That is a pretty widespread module, and I see a multi-branched version as being problematic. I will await RexxS the author to tell me when there is a stable version to import.  — billinghurst sDrewth 13:31, 27 October 2019 (UTC)

The above comment is an important point. I haven't looked at this example but many templates have such numerous dependencies that importing can be messy. I'd agree with the wait for a stable branch, and I'd also get a second opinion on outreach. --mikeu talk 15:31, 27 October 2019 (UTC)

I tend to maintain both en:Module:WikidataIB and its sandbox and c:Module:WikidataIB and its sandbox as identical up-to-date modules. They are pretty much always backward compatible, so folks on other language wikis just import one of those to update their version. The module does have several dependencies because it makes use of Jarekt's c:Module:Complex date to render dates in all different languages, but the dependencies are listed at the top of the module code (in case the documentation doesn't get imported). If you're ever unsure, just ping me and I'll do the importing manually - there's very little problem with copy and paste, because the edit history of each module is uncomplicated for purposes of attribution. Cheers --RexxS (talk) 18:39, 27 October 2019 (UTC)
@Billinghurst and Lsandre: The w:module:WikidataIB has now been updated so that it should now work with the WiR table templates (per this comment). Would you be able to do the final re-import the module? Thanks! T.Shafee(Evo﹠Evo)talk 01:39, 28 October 2019 (UTC)
@Billinghurst and Lsandre: Apologies for pestering. Would it be possible to import the current version version of w:module:WikidataIB (was updated two days after the last import with the relevant feature that I need). Thanks! T.Shafee(Evo﹠Evo)talk 00:19, 6 November 2019 (UTC)
  Done for future simple import requests please use Meta:RfH  — billinghurst sDrewth 10:54, 6 November 2019 (UTC)

WMF appointment of local administrators on Meta-WikiEdit

Several weeks ago, WMF Trust & Safety specialist JSutherland (WMF) used his WMF Support and Safety userrights to appoint User:MusikAnimal (WMF) to the administrators usergroup on Meta-Wiki, for purposes of "Community Wishlist Survey page maintainance". These actions include page deletions, moves, and the creation of edit filters for tracking purposes. The appointment did not involve any local community processes.

This is the sixth such time that the WMF has unilaterally given a member of their staff administrator userrights here on Meta-Wiki.

Is this acceptable? I don't recall the community ever approving of giving the WMF unrestrained super-bureaucrat rights for things like page deletions unrelated to either Mediawiki development work or the necessary actions that the communities delegated to T&S. While it would be reasonable for the community processes to take into account a contributor's employment at the WMF, I don't think that allowing staff to bypass approval entirely is a good idea. Thoughts on this? --Yair rand (talk) 09:55, 5 November 2019 (UTC)

WMF has always had the ability to apply rights to staff on this wiki. It has been for pages where they primarily manage. To note that the administrator appointed is already an administrator on this wiki in their own rights, and to separate staff based and volunteer based editing is preferred. Has been this way since WMF created separate staff based accounts to manage the accountability aspects, so one could differentiate between the differing roles.  — billinghurst sDrewth 11:36, 5 November 2019 (UTC)
Of the five current staff Meta admin appointees, four are not currently Meta admins in their own right, and two have never been admins here as volunteers. While all of these individuals presumably should have adminship (temporary or permanent), shouldn't the community have a say in it? In the past, we have had staff request adminship via the regular community channels. (See also 1, 2.) I don't see why there should be T&S involvement in the community's local appointment process. --Yair rand (talk) 17:02, 5 November 2019 (UTC)
We would complain when a problem would happen (i.e. a right abuse). As of now, let’s let the staff do their work: they are not paid for waiting community opinion concerning each of their actions. Adminship let only do office actions, it doesn’t affect editorial policy, especially on Meta. A trust question. —Pols12 (talk) 17:53, 5 November 2019 (UTC)
This. If an actual situation of staffers causing "community" issues arises we would want to deal with it - so if a staffer starts blocking users, deleting pages, adding controversial filters, etc - we should hold them to account and escalate with their management as needed - else I'm not really seeing a problem. — xaosflux Talk 18:38, 5 November 2019 (UTC)

Bot to automatically protect highly transcluded templates and modulesEdit

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)

Wikiquote CheckUsersEdit

Hello Wikimedians - I do not know if this is the right place but I just want to express that none of Wikiquotes have local CheckUsers, but we have some problem with a sockpuppeteer called WikiLumber with more than 16 socks and harassing another user called WikiLubber. Can somebody help on this? Josephine W. (talk) 00:02, 10 November 2019 (UTC)

Checkuser requests can be made at SRCU (for wikis without local checkusers). It is used for checking suspected socks whose edits are disruptive but do not yet deserve a block. If their behaviors are obviously similar or they are vandalism-only accounts, they can simply be blocked and there is no apparent need to check them IMO. --94rain Talk 00:16, 10 November 2019 (UTC)

Restrict anonymous users from editing pages in the CNBanner namespaceEdit

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)
  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 2019Edit

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 overhaulEdit

Since late 2018, English Wikipedia, Wikimedia Commons and some other Wikimedia projects no longer use old 700912058001/04121503114567/79767982461922/07///////////// 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

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)