Meta:Babel/Archives/2018-02
Please do not post any new comments on this page. This is a discussion archive first created in February 2018, although the comments contained were likely posted before and after this date. See current discussion or the archives index. |
Allow admins to add users to translation admins group
Hi. Could we allow admins to add users to the translation admins user group? This functionality is currently restricted to bureaucrats or own accounts only on Meta-Wiki. --MZMcBride (talk) 18:09, 7 February 2018 (UTC)
- Why? TA requires a community vote at WM:RFA and the system is working just fine IMHO. I'd rather not amend the config again. —MarcoAurelio (talk) 18:25, 7 February 2018 (UTC)
- Someone asked me today about getting added to the group. I was hoping I could just add them myself, but for some reason we only allow self-changes or bureaucrats to add someone to this user group. It remains unclear to me why a separate translation admin user group is needed at all, but requiring an RFA for it seems even sillier. --MZMcBride (talk) 23:15, 7 February 2018 (UTC)
- Meh, our local crats haven't had any trouble keeping up with this. If we wanted to devolve an assignment function from crat to admin things like "uploaders" and "confirmed users" would be more sensible. These are also so rarely used that it's not really causing any backlogs. — xaosflux Talk 20:12, 7 February 2018 (UTC)
- There are currently only three local bureaucrats, I believe. Coincidentally, all three have usernames starting with the letter M. --MZMcBride (talk) 23:15, 7 February 2018 (UTC)
- We dismissed Barras and appointed Matiia so we could conform the "M for Meta Bureaucrat Cabal", a.k.a "The Three Musketeers" (M for Musketeers too!) :-P —MarcoAurelio (talk) 00:40, 8 February 2018 (UTC)
- So I'm hearing you have a chance assuming you can get 2/3 of ALL of them to endorse you! (where did that policy come from?) — xaosflux Talk 00:16, 8 February 2018 (UTC)
- Hmm, looks like it just appeared one day. — xaosflux Talk 00:23, 8 February 2018 (UTC)
- And before, it seems like there was no requirement for a discussion. I do remember back in the day when Meta had one crat for every two admins. – Ajraddatz (talk) 00:43, 8 February 2018 (UTC)
- Hmm, looks like it just appeared one day. — xaosflux Talk 00:23, 8 February 2018 (UTC)
- There are currently only three local bureaucrats, I believe. Coincidentally, all three have usernames starting with the letter M. --MZMcBride (talk) 23:15, 7 February 2018 (UTC)
- I don't mind leaving most of the userrights-related stuff to bureaucrats. Since translation adminship requires some sort of discussion, it should be fine to keep there. – Ajraddatz (talk) 23:22, 7 February 2018 (UTC)
- Out of curiosity, why is a seven-day discussion needed? What's the specific concern? Are we worried people are going to go rogue and mark pages for translation? --MZMcBride (talk) 23:42, 7 February 2018 (UTC)
- Not sure, honestly. Probably just something that was done initially and then continued. – Ajraddatz (talk) 00:43, 8 February 2018 (UTC)
- I realize nobody wants to touch the user rights configuration again (myself included), but I do wonder whether it would make sense to have a "trusted user" group or similar and fold a lot of these individualized user groups into a larger, more general group. This user group could be viral instead of self-added or removed. Viral meaning users already in the group can add other users to the same group. This creates a chain or web of trust, in some ways.
- In my ideal world, we'd just let all users do all of this. I think we should be as open as possible, just as we are with editing. Why should page translation be treated special? Or we could make anyone an administrator. But obviously that isn't going to happen anytime soon. --MZMcBride (talk) 01:34, 8 February 2018 (UTC)
- "Touching" the config to move existing permissions between existing groups is pretty trivial, if the community wants a change there should be no great technical argument. — xaosflux Talk 02:07, 8 February 2018 (UTC)
- Sure, but I think there may be some change fatigue. I didn't mean to suggest that this was difficult from a technical perspective, I was referencing comments like MA's about preferring not to re-amend the configuration. --MZMcBride (talk) 02:10, 8 February 2018 (UTC)
- I recently standardized the Translate permissions WMF-wide (previously we had to do this for every wiki using Translate). I think the system works fine and there's no backlog currently. The discussion at RFA proved helpful in my experience, as it has helped to exclude some people asking for this without the knowledge on how to properly tag a page for translation, effectively breaking translatable pages. This is not to say that I do not trust my fellow administrators to handle this permission, but given the above I'm not sure if there's any need or it's worth the effort to do so. Thanks. —MarcoAurelio (talk) 11:22, 8 February 2018 (UTC)
- Sure, but I think there may be some change fatigue. I didn't mean to suggest that this was difficult from a technical perspective, I was referencing comments like MA's about preferring not to re-amend the configuration. --MZMcBride (talk) 02:10, 8 February 2018 (UTC)
- "Touching" the config to move existing permissions between existing groups is pretty trivial, if the community wants a change there should be no great technical argument. — xaosflux Talk 02:07, 8 February 2018 (UTC)
- Translation admins can easily break a lot of translation pages or unnecessarily create them etc. So I think it makes sense to only give it to users who know how to deal with it. --MF-W 17:03, 8 February 2018 (UTC)
- Hmm....as IMHO, "translators are not toys" which is also mentioned at Meta:Translate extension#In general when I read and translated the Chinese page in not long ago. It maybe a good option to have 1 week support consensus discussions from community users trusted to grant the TA tool by any local admins or crats. SA 13 Bro (talk) 22:48, 8 February 2018 (UTC)
- Not sure, honestly. Probably just something that was done initially and then continued. – Ajraddatz (talk) 00:43, 8 February 2018 (UTC)
- Out of curiosity, why is a seven-day discussion needed? What's the specific concern? Are we worried people are going to go rogue and mark pages for translation? --MZMcBride (talk) 23:42, 7 February 2018 (UTC)
Sandbox link
Hello. Does anyone know how to enable the sandbox link (as on English Wikipedia)? Is it disabled here for a reason? Thanks in advance. Rehman 07:19, 14 February 2018 (UTC) I think you can do it under Meta:Sandbox section(i am not sure)Adithyak1997 (talk) 15:13, 19 February 2018 (UTC)
- @Adithyak1997: the SandboxLink extension is disabled by default While anyone can create a /sandbox page, I don't think we should encourage it with a big red link on the top of everyone's page here on metawiki. You can create your own links with javascripting, as was done on enwiki at one time (see w:en:MediaWiki:Gadget-mySandbox.js). — xaosflux Talk 16:21, 19 February 2018 (UTC)
Multi Colon Escape Error
I am facing an error with the template Template:User1. This template contains multi colon escape error which i could not correct. After correcting that error, i think many of the multi colon escape errors can be removed.Adithyak1997 (talk) 15:11, 19 February 2018 (UTC)
- Like this? Stryn (talk) 15:31, 19 February 2018 (UTC)
Actually, i don't know the correct result that needs to be displayed. But now, the multi colon escape related to this template has gone. Thanks for helping.Adithyak1997 (talk) 16:53, 19 February 2018 (UTC)
Restoring global abuse filter editor group
This came up in this discussion. Basically there are a few of us who feel we could benefit from being able to edit filters across all wikis, including global filers here on Meta. Currently the only option is applying for stewardship, and I'm not sure that filter management alone would warrant such a promotion.
For me, my interest exceeds no more than helping out with performance. I have access to the slow filter dashboard, which shows filters that are unusually slow and could use attention. Not every wiki is reported there, but there are plans to make that happen. Anyway, the issue is the dashboard is only available to those with logstash access, which doesn't include many abuse filter experts. Even those who do have access may not know how to best improve their filters, so someone like me has to walk the local abuse filter manager through it, relaying information we see on the dashboard. Beyond that, I do occasionally get requests to assist other wikis, but again it is almost always out of the interest of performance.
Pinging User:DerHexer, who I believe both created and removed the abuse filter editors group. Do you recall why it was removed? Any thoughts on restoring it? — MusikAnimal talk 18:36, 2 February 2018 (UTC)
- @MusikAnimal: the log says it was removed because it was empty. Generally when a global group has no members it gets purged. — xaosflux Talk 18:58, 2 February 2018 (UTC)
- (moved from another page) I don't think there is big value in creating a local access group for editing meta-local abuse filters only - reason why: it's not really that hard to become +sysop here and meta-local abuse filters don't need that much management. A stronger need-base argument could be made for a group that allows editing of the global filters (applied to small/medium wikis) - my first inclination would be that global sysops would be the natural extension of this, as this group of volunteers is already vetted to impact lots of wikis - challenge is that they may not have the technical inclination or desire to deal with abusefilters, and making someone a gsysop soley for abuse filter management may not be appealing to the global community. — xaosflux Talk 14:45, 2 February 2018 (UTC)
- @MusikAnimal: I don't think most of the 'large wikis' would want someone not very involved with their community making filters/etc. — xaosflux Talk 18:56, 2 February 2018 (UTC)
- For meta sysops it is possible to edit CN, Global spam&title blacklist, etc. Likely it should be able to edit global filters as well. CN is imho more dangerous than global filters. I would make sens to give GS access to global abuse filters as well. Or experienced people are getting added to the usergroup mentioned by MusikAnimal. --Steinsplitter (talk) 19:08, 2 February 2018 (UTC)
- @Xaosflux: Totally. I don't think global abuse filter editor should in general be used for arbitrary creation of filters without discussion. It would foolish to pretend that I understand local abuse issues, or community processes, when I don't even patrol there. Again for me it's about helping out with performance, which in most cases doesn't even require an understanding of whatever non-English language is used in the regex (more commonly it's the condition ordering and function usage that's the issue). This of course would be limited to highly trusted users. Hopefully I fall in that category, but that's obviously up to everyone else to decide :) It would be nifty for Meta sysops to edit global filters too, but that wouldn't fit my use case. Global sysop doesn't apply to every wiki, either. — MusikAnimal talk 19:24, 2 February 2018 (UTC)
- I'd prefer if we focus on the local issue. It might be benefitial to create a local group for some people to also edit local filters, it might be benefitial to create a local group to edit global abuse filters restricted to very trusted and experienced users in that area. The global 'abusefilter' group was created for Andrew G. so it could have a look at its newly deployed extension and I don't think we need one again. —MarcoAurelio (talk) 21:11, 2 February 2018 (UTC)
- @MusikAnimal: What about adding the abilities to the sysadmin global group for those of you who need to work on those? —MarcoAurelio (talk) 21:13, 2 February 2018 (UTC)
- @MarcoAurelio: I'm happy to help just here on Meta with global filters (if you want my help), but my use case extends beyond Meta. I think sysadmins already can edit all filters, no? I do not hold this right, but I suppose cleaning up filters is broadly related to work... so I might could get it. I realize this is not just about me :) and that there's probably not that many people who could benefit from a global abusefilter editor (any filter, any wiki), so maybe it's not worth it. — MusikAnimal talk 22:31, 2 February 2018 (UTC)
- It would be simpler to add abuse filter related userrights to Interface editors group—its membership already consists mainly of developers. Ruslik (talk) 08:06, 3 February 2018 (UTC)
- Simpler maybe, but I'm not sure abuse filter management would fall under the purview of an "interface editor", in a literal sense. — MusikAnimal talk 17:00, 5 February 2018 (UTC)
- It would be simpler to add abuse filter related userrights to Interface editors group—its membership already consists mainly of developers. Ruslik (talk) 08:06, 3 February 2018 (UTC)
- @MarcoAurelio: I'm happy to help just here on Meta with global filters (if you want my help), but my use case extends beyond Meta. I think sysadmins already can edit all filters, no? I do not hold this right, but I suppose cleaning up filters is broadly related to work... so I might could get it. I realize this is not just about me :) and that there's probably not that many people who could benefit from a global abusefilter editor (any filter, any wiki), so maybe it's not worth it. — MusikAnimal talk 22:31, 2 February 2018 (UTC)
- @MusikAnimal: What about adding the abilities to the sysadmin global group for those of you who need to work on those? —MarcoAurelio (talk) 21:13, 2 February 2018 (UTC)
- I'd prefer if we focus on the local issue. It might be benefitial to create a local group for some people to also edit local filters, it might be benefitial to create a local group to edit global abuse filters restricted to very trusted and experienced users in that area. The global 'abusefilter' group was created for Andrew G. so it could have a look at its newly deployed extension and I don't think we need one again. —MarcoAurelio (talk) 21:11, 2 February 2018 (UTC)
- I think the ability to edit the global filters should just be added into the local sysop group. The thing isn't even truly global (though it should be). – Ajraddatz (talk) 21:15, 2 February 2018 (UTC)
- Not really opposed in "general" - just need to make sure people know what they are doing. And it is "almost" global (small- and medium- sized wikis) - I don't think we have the capacity to try to examine large-size wiki's edits centrally without a lot more horsepower! — xaosflux Talk 21:20, 2 February 2018 (UTC)
- Meta admins can already edit the global spam/title/email blacklists. I trust our admins to not mess around with things they don't know. And so far as making the global abusefilter global is a performance issue, that's fine of course. I'm less convinced by the "but muh local community sovereignty" perspective. – Ajraddatz (talk) 23:08, 2 February 2018 (UTC)
- Agreed, the permission suits the Meta-Wiki administrators' job. It doesn't need to be set in stone though: in case the filters become a bigger deal in the future, it can be again restricted to stewards so that people from every wiki have a chance every year to complain about its usage. --Nemo 20:36, 7 February 2018 (UTC)
- Meta admins can already edit the global spam/title/email blacklists. I trust our admins to not mess around with things they don't know. And so far as making the global abusefilter global is a performance issue, that's fine of course. I'm less convinced by the "but muh local community sovereignty" perspective. – Ajraddatz (talk) 23:08, 2 February 2018 (UTC)
- Not really opposed in "general" - just need to make sure people know what they are doing. And it is "almost" global (small- and medium- sized wikis) - I don't think we have the capacity to try to examine large-size wiki's edits centrally without a lot more horsepower! — xaosflux Talk 21:20, 2 February 2018 (UTC)
- I suppose we should put something to a vote, I'm seeing a few prevailing options here
- Local options
- Allow meta
Administrators
access toabusefilter-modify-global
. This will allow them to edit the global abuse filters currently maintained only by stewards here on meta. These filters affect all "small" and "medium" sized public wiki's. No process changes needed, small policy and directions updates. This could be done in addition to options below if desired. - Create a local group (e.g.
Edit filter managers
) that can manage all of the filters managed on meta, including the global list. Permissions to include: ((managechangetags) , (oathauth-enable) , (abusefilter-modify) , (abusefilter-modify-restricted) , (abusefilter-modify-global)
). New process for requesting access can be added to Meta:Requests for adminship. Allow meta Bureaucrats to manage group membership. Possibly allow administrators to add/remove self if not also implementing (1) above.
- Global options
A global group would be as (2) above, but apply globally. There are several options on this one, such as using an existing group (e.g. GIE, GS) and if it should apply to ALL projects, or just a subset (such as the GS list). Some specifications would need to be laid out.
Thoughts? — xaosflux Talk 16:15, 10 February 2018 (UTC).
- A much simpler solution is to create a personal global group for User:MusikAnimal who wants to help us making abuse filters better as we do from time to time. Ruslik (talk) 18:17, 10 February 2018 (UTC)
- I know I'd volunteer to at least help with the global filters here, not sure about visiting all the 100's of local ones though. — xaosflux Talk 21:02, 10 February 2018 (UTC)
- I think the best solution is to allow meta admins to edit the global filters (local option 1). Such a change is in-line with their existing scope and abilities. I don't think that another global group is needed; there are already abusefilter helpers that can view all filters, and global sysops/stewards that can help with filters on small projects. – Ajraddatz (talk) 21:08, 10 February 2018 (UTC)
Can I suggest to create a local group here at Meta-Wiki that has the appropriate permissions to edit global abusefilters? I feel it'd be easiest option. A global group could be an option but editting filters outside Meta-Wiki is controversial and I feel that'd require some discussion. —MarcoAurelio (talk) 21:09, 10 February 2018 (UTC) [well, that's option #2 of Local options above].
- And on review, global sysops can already manage local filters at the sm/med wikis - if they wanted to manage "global filters" they could use the new local group as well. — xaosflux Talk 21:44, 10 February 2018 (UTC)
- RFC Created
A RFC has been created at Requests for comment/2018 Allow meta admins access to global abuse filter to get support to enact this, please see the RFC. Pings to prior participants: User:DerHexer, User:MusikAnimal, User:Steinsplitter, User:MarcoAurelio, User:Ruslik0, User:Ajraddatz. — xaosflux Talk 14:50, 23 February 2018 (UTC)
Lock vs Ban
I may need to take this to another venue. I am reading the questions in re: Steward Elections. Can someone explain in small words the dif between a ban and a lock, particularly globally. I am really only familiar with "blocking". Maybe i need the difs between the 3.— The preceding unsigned comment was added by Ragityman (talk)
- @Ragityman: There is a danger of simplifying it too much but basically:
- a lock is a block for activities such as vandalism/spam or legal threats by a user on more than one wiki, and is usually based on a report by another user without needing extensive discussion;
- a ban is a decision by either the community or the WMF to stop a user from editing altogether on Wikimedia wikis; the community ban follows a lengthy discussion and involves a user causing much more than just vandalism or spamming e.g. persistent harassment, copyright violations or abuse of checkuser/oversight privileges; usually the user account is locked by the steward as a way of enforcing the ban.
- If it helps, you can think of it all as a stairway with warnings and reversions as the first step, talkpage discussion as a second step, blocks as a third step, block appeals as a fourth step, a repeat of the first four steps on another wiki as steps five to eight, locks as a ninth step, lock appeals on Meta as a tenth step, ban discussion as an eleventh step and a ban (with lock) as a twelfth step. Obviously some wikis have extra steps such as arbitration committees, but I assume you are not asking about those. Anything above that is beyond the remit of volunteers. I hope that helps but feel free to ask more questions. Green Giant (talk) 13:14, 26 February 2018 (UTC)
- @Ragityman: There is a danger of simplifying it too much but basically:
Changing the alphabet (Kazakh Wikipedia)
Hi, I'm an admin in Kazakh Wikipedia. What is the procedure for the changing alphabet in the converter? Officially the Kazakh language has changed the alphabet from Cyrillic to Latin. Where should we upload our alphabet?AlibekKS (talk) 10:23, 20 February 2018 (UTC)
@AlibekKS:, I believe it would require contacting the developers of WMF through Phabricator. Create an account there and [1] create a task. --Artix Kreiger (Message Wall) 23:47, 22 February 2018 (UTC)
- Maybe community consensus is needed, Requesting wiki configuration changes. --Liuxinyu970226 (talk) 14:09, 25 February 2018 (UTC)
- @AlibekKS:: You'll need to a) go to Phabricator to request the interface be transliterated and b) code a bot to transliterate the wiki content (articles, userpages, etc.) (but don't actually use the bot before getting approval here on Metawiki). KATMAKROFAN (talk) 20:04, 21 March 2018 (UTC)