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.

2FA tester local group on meta

Per Ruslik0 idea on Meta:Requests for comment/Enable 2FA on meta for all users, I propose a 2FA tester local group on meta which meta sysops + stewards are able to grant and remove the oauth-enable, and depreciate the global group.

• Support as proposer.--Camouflaged Mirage (talk) 14:03, 19 February 2020 (UTC)
• Support. Ruslik (talk) 20:59, 19 February 2020 (UTC)
• Support, per comments on RFC. —Sgd. Hasley 21:04, 19 February 2020 (UTC)
• Not against this idea by any means, but I think it is worth noting that Babel is intended for Meta general discussion. Proposals like this would go to either Meta:Requests for comment (local) or to Requests for comment (global); this has global implications so I think the latter is more appropriate. ~riley (talk) 21:37, 19 February 2020 (UTC)

  @~riley: I started here on the advice of Ruslik0. This is sort of phab changes and for the raising of autoconfirm to 5 edits was also held here which resulted in a phab change. I think this is a local meta group, so a meta local RFC will be suitable (but then there is already one for the enabling of all the 2FA on meta already), so then it can be a subsection of that RFC but will make that more complex. For the depreciating the global group, it's unfortunate I put it in such way, it should be redundant as stewards will no longer grant the global 2FA tester group, so the group is still there, but not granted. What will be granted will be the local 2FA group instead. Hope this clarifies, and will be happy to move all these to a RFC if it's needed. Feel free to discuss with me here or on IRC. --Camouflaged Mirage (talk) 07:10, 20 February 2020 (UTC)

• Support Good idea.--Aldnonymous^Bicara? 09:14, 20 February 2020 (UTC)
  • @Ruslik0, Hasley, Aldnonymous, and ~riley: Per above feedback that RFC is more appropriate and IRC conversation, I started Meta:Requests for comment/Create a 2FA tester local meta usergroup. Thanks.--Camouflaged Mirage (talk) 11:50, 20 February 2020 (UTC)
•  Oppose. I fail to understand what is the problem we are attempting to resolve. We currently have 398 accounts in the global group. To deprecate the global group we'll need to remove all of them from the group and later delete it. There's no way to do this with a single click, nor transparently (sure a sysadmin can fiddle with the DB and do it). Is this worth the effort? (assuming we don't want to re-add them later to the local group). Secondly, what kind of benefit do we achieve from switching from global to local? Are we stewards overwhelmed by the number of requests that can't cope with them? I don't think so. Do a local group (which we'll need a Phab task each time we need to change a comma of its config, as opposed to CentralAuth groups) provide any benefits in comparison to the current global group? Maybe set it to auto-expire, but work is being done right now by Melos to implement expiring user groups; and I'm not sure we want to set this group as expiring either. And lastly, are rubber-stamping going to end (one of the reasons offered) being this a local group? Unlikely. So overall and with all due respect no convincing reason has been offered in this discussion nor in the RfC as against the current status quo. My advice is to let this stay until such time 2FA gets rolled to everyone by default (when it is safe to do so) and then yeah, nuke the global group as deprecated. —MarcoAurelio (talk) 18:56, 20 February 2020 (UTC)
•  Oppose - why though? I don't understand what's wrong with the global group. – Ajraddatz (talk) 19:23, 20 February 2020 (UTC)
  • Just a quick response here, I think this thread can be closed as the RFC is on, sorry for starting here and not a RFC. Some response to the opposes above. I am basically open to whether leaving it per status quo or changing. The primary consideration of a local group will be Ruslik0 idea in the 1st RFC which states the issue of rubber stamping as well as more hands can help. This can be in response to Ajraddatz concerns. As per the points raised up by MarcoAurelio. Thanks for all the inputs. My RFC have an option we let both groups remain, though newer users who requested 2FA will be added to the local group only. As of phab concerns, yes, there are, I think since this is just 1 right with 2 groups (meta sysops, stewards) removing and adding it, the code will be simple enough. Rubber stamping won't end I guess, but the idea is basically more people rubber stamping it and to relieve some load off stewards shoulders. Just some thoughts, sorry that these are very brief as it's quite late here, will try to expand when I have the time. Regards,--Camouflaged Mirage (talk) 19:32, 20 February 2020 (UTC)
    • I'm not sure that moving it to a local group will prevent rubber stamping. A clear set of criteria for granting the permissions would be more useful in that regard. I don't think the stewards are particularly burdened by these requests (indeed, back in the old days when I was a steward, people answered these requests usually within minutes). In principle I don't object to steward rights being devolved, something I have always supported (see global abusefilter editing permissions), but I think a clearer need should be established here first. – Ajraddatz (talk) 20:01, 20 February 2020 (UTC)
      • @Ajraddatz:. I am actually quite neutral in this, as some stewards had said they are tired to rubber stamp, if I can help, why not? On the other hand, having the local group doesn't mean rubber stamping will stop, is just more people having the stamp I guess. I think a way is for all stewards to comment here or a list to see if it is a net positive for this right to be devolved. If so let's do it, if not then I think we can close this and the other RFC for all meta users to have 2FA automatically as moot? Regards,--Camouflaged Mirage (talk) 10:04, 21 February 2020 (UTC)
        • The rubber stamping argument is a non sequitur to me. If the consensus is to grant each and every request that comes to us then I may change my opinion at Meta:Requests for comment/Enable 2FA on meta for all users and let all users activate 2FA themselves, customizing the local intro message adding a big ol' fat warning in the lines of: be warned that if you mess up or don't know what are you doing don't come crying to us later. Creating a local group to continue with the rubber stamping is pointless and not worth the effort. Thanks, —MarcoAurelio (talk) 11:27, 22 February 2020 (UTC)
• Support --Novak Watchmen (talk) 21:11, 26 February 2020 (UTC)
•  Oppose There is no reason to change the state of affairs, or at least I haven't seen one in this proposal. --Martin Urbanec (talk) 19:49, 22 March 2020 (UTC)
• Sigh, this is such a circular argument - don't let people have 2FA becuase it isn't supported, but let anyone who wants it have it if they wave a magic chicken. At this point we should probably fall forward or fall back -- expand it, or stop adding "testers". We really don't need any more "testing", and the people signing up to be "testers" aren't participating in tests at all - they just want to opt-in. — xaosflux ^Talk 14:47, 6 April 2020 (UTC)

Spam domain name

How to remove the domain from spamming blacklist.—The preceding unsigned comment was added by Umangchugh (talk)

Place a request on the page Talk:Spam blacklist. -- Tegel mobile (talk) 13:01, 3 April 2020 (UTC)

Pointless lint filter fixes on discussion pages

These fixes of lint filters in discussion spaces is becoming both tiresome and annoying where it is pointless and basically noise. I can understand fixes in content namespaces, but discussion spaces! Further changes in discussion archives is just plain wrong, they are archives and archives just should be left alone. Why should someone be going in there when someone has archived their pages, and has it noted to leave them alone? Who will go down to their local archive office and take out the books and change those records?

People, please do not be driven to do fixes that are next to valueless. Do not be automatons driven to do pointless issues because someone has given you a toy that finds faults. Be mindful in your actions, do something because it needs doing, not because it can be done. @TheSandDoctor and ~riley: I am talking to you both here as the most recent actors in this place.  — billinghurst sDrewth 08:52, 6 April 2020 (UTC)

Problem is that the old code can break pages and even make half of the page disappear. It's better to fix those for people who later are reading these pages. I know it's not nice when own watchlist is full of this kind of edits, maybe we should leave those for bot accounts. Stryn (talk) 14:35, 6 April 2020 (UTC)

@Billinghurst: can you provide a couple example diffs for our reference? In some cases, lint errors can make a page unreadable so fixing a lint error in general isn't necessarily useless. If these are being done in any volume or bothering recent changes/watchlists then using a bot flag should alleviate that sort of issue. — xaosflux ^Talk 14:43, 6 April 2020 (UTC)

Stryn, how often have you seen disastrously broken discussion pages? Hardly ever. How often are we seeing these linter corrections coming through? Very regularly. Replacing <tt> with <code>. Replacing <font> b/c as has been deprecated, that doesn't mean that it will ever stop working, it means don't use it further. I am not saying don't fix the content pages, where the fixes truly matter. That is not the case for discussion pages. Not user talk pages. Not archives of discussion pages.

I will plead guilty to having fixing some major issues in archive pages, but manually when sighted, not running a bot process through for little value. When we have people running bot-like process on Special:LintErrors#Low priority issues on these discussion pages not focusing on the high priority, then we have an issue. If people want to fix things, go and do something that really matters.  — billinghurst sDrewth 15:11, 6 April 2020 (UTC)

At least parts of your statement are not correct. Yes, they work now, but that does not mean they will work forever, otherwise the deprecation is useless. They'll stop working one day, and where they're not replaced will break badly. And deprecation does not mean "don't use it further" only, it means don't use it further and replace existing usages. – Ammarpad (talk) 06:03, 11 April 2020 (UTC)

• If you are talking to two specific users, why are you creating a community discussion rather than approaching them directly? This is the equivalent of dragging two editors to AN without approaching them first. A polite request to not touch discussion pages rather than a rant on Babel goes a long way. ~riley (talk) 19:36, 6 April 2020 (UTC)

  We have a system design problem with a social component. You two are not the first, and you won't be the last. The system encourages people to come and address low value tasks. When valued and experienced users get sucked into doing those tasks then we are losing. That users are drawn to edit archive pages that are usually tagged with {{archive-header}}, {{talk archive}} or an equivalent, then we are losing. That we cannot exclude these pages ourselves, then we are losing. I am talking to you both to get an understanding of what draws you, understanding why it happens is important.  — billinghurst sDrewth 00:18, 7 April 2020 (UTC)

Hi. It seems like there are three potential objections to these linter edits:

1. Modifying discussion pages, particularly archives.
2. Clogging up recent changes, watchlists, page histories, and user contributions feeds.
3. How volunteers choose to spend their time.

sDrewth's posts focus on the third point, which is the worst and weakest argument, in my opinion. There are a lot of time sinks around here: user renaming, sockpuppet investigations, account creation, broken and double redirect management, people deleting and re-creating category description pages all the time, etc. But we don't typically fault users for wanting to get involved in these byzantine and often asinine systems. --MZMcBride (talk) 03:28, 7 April 2020 (UTC)

I cannot agree with your PoV, the three points are raised by me. I am not here raising these points because I am irritated by what people are doing with their time, the issue is raised of what they are doing at the higher level, and of other people's edits in discussions that shouldn't be changed without real purpose.

At meta I can only deal with meta, and try to understand why people are now doing something that for years we would not have done, and seemingly just because a tool has listed it on a page report. The community hasn't asked for it to be done, and it isn't resolving any existing issues. I will deal with the problematic system issues at phabricator, which I have separately done.  — billinghurst sDrewth 05:37, 7 April 2020 (UTC)

• Such "pointless" fixes are often necessary as it breaks HTML syntax and (consequently) makes it invisible or hard to see. (Example: This is not the "extreme" one, actually one of the most mild one, but d:User_talk:GerardM/Archive_1#Human_groups and scroll to the bottom) Fixing such thing is a good thing and should not be discouraged. — regards, Revi 16:47, 7 April 2020 (UTC)
  • That's a different category of errors, none of these actually affect the display of the page. Legoktm (talk) 03:31, 9 April 2020 (UTC)
• I agree with Revi here. These fixes may seem pointless, but are somewhat useful, and if someone wants to volunteer to do them then I don't see any harm. If the notifications are disruptive, then this can be done manually from a bot account. – Ajraddatz (talk) 17:00, 7 April 2020 (UTC)
• I agree with MZMcBride on this. Lint errors are errors that need to be fixed. Deprecation is typically done with the intent to remove in the future. As such, fixing lint errors is fairly important. The less reliant, for example, a page is on deprecated HTML tags the better. Just because they are time sinks doesn't mean that users should not be repairing them when they see them. I do, however, agree that flood rights would be a better option for doing any quantity of them and will be sure to use flood rights for this sort of work in the future as to avoid flooding anyone's watchlist. In regards to a bot doing this work: a lot of the awb results require manual adjustment prior to saving. Letting a bot loose on these would not be the best option. --TheSandDoctor ^Talk 17:40, 7 April 2020 (UTC)

• There also appears to be further consensus on the related phab ticket that backs up what has been said here by myself and others. --TheSandDoctor ^Talk 23:22, 7 April 2020 (UTC)
• Not really, I doubt any of the browsers are ever going to remove support for <font> for example. What kind of AWB regex are you using that requires manual fixes? Legoktm (talk) 03:31, 9 April 2020 (UTC)

• en:HTML_element has plenty of examples of tags that are invalid or outright removed starting in HTML5. I will specifically note that, starting in HTML 4.0 strict, the font tag is considered invalid markup and is outright not a part of HTML5. It is not a leap to consider that it will outright have support in browsers etc removed in the future. --TheSandDoctor ^Talk 01:07, 10 April 2020 (UTC)

• It is definitely a leap, given that no browser has given these indications. Anyways, if it ever happens, Tim figured out a plan at gerrit:334990 which is kind of documented at mw:Parsing/Notes/HTML5 Compliance. In short, there is literally no urgency to make these changes. Legoktm (talk) 04:32, 11 April 2020 (UTC)

• Mozilla, the developers of Firefox, have given such indication, stating in a prominent warning "...Although it may still work in some browsers, its use is discouraged since it could be removed at any time...." (emphasis mine). So unless we're to use the logic "not all smokers die from cancer, so it's fine to pick up smoking", I think we should definitely follow the advice of Mozilla and begin removing these errors. Further, how volunteer editors spend their time and whether they choose to do wikignome work is their call. I've decided this is an area I want to allot my time towards, and as the flood flag prevents the edits from disrupting the RC feed I will be moving forward. --TheSandDoctor ^Talk 20:15, 22 April 2020 (UTC)

• I'm sure you have the best of intentions, but if you're not going to understand or read the links I posted, there's not much point in me engaging further. You're trying to fix something that isn't actually a problem, and that we have better ways to fix if it ever did become a real problem. If you want to keep going and tell yourself that it's not disruptive, instead of doing something productive, have fun. Legoktm (talk) 23:09, 26 April 2020 (UTC)

• There is nothing wrong with what they are doing. Fixing archives to make it more readable is always a good thing... Leaderboard (talk) 18:01, 7 April 2020 (UTC)
  • Just to be clear, you understand that there are no visible changes to these archive pages right? That they look exactly the same? Legoktm (talk) 03:31, 9 April 2020 (UTC)
• Per above, nothing harmful. However, I would strongly suggest using a bot to fix lint errors on talk pages and archives. Minorax (talk) 06:28, 8 April 2020 (UTC)
• Seems moot as TSD had asked for Limited Admin here per Meta:Requests for limited adminship/TheSandDoctor where they can add flood flag to themselves and I think ~riley noted. There is a consensus that the edits are useful as well as the possible adding of flood / bot might be useful in some situations. I don't see any need for this thread to be continued. Camouflaged Mirage (talk) 15:43, 8 April 2020 (UTC)

As far as I can tell, the edits in question were all replacing deprecated HTML tags, which isn't a real problem today, hence the low priority designation. Just use a bot account please and have a script (I'm sure someone has already written one) fix all of the issues in one go rather than requiring multiple edits for each type of tag. Legoktm (talk) 03:28, 9 April 2020 (UTC)

Good reminder to use a bot; we'll both proceed with using the pseudobot flag when performing these edits. I am not going to comment on the value or priority of these lint errors. Although we may be working on the low priority ones now, primarily because one page can have up to 10 lint errors and it's easy to tackle, the medium to high priority lint errors are on the list to be done. @Legoktm: Do you have any ideas for who may have written such a script? I have tried searching. ~riley (talk) 22:39, 9 April 2020 (UTC)

mw:Help:Extension:Linter#Tools, probably WPCleaner. Legoktm (talk) 04:32, 11 April 2020 (UTC)

• My meta limited/temp RfA just recently closed as successful. Given that there is both consensus here on meta and phabricator that lint fixes should go ahead regardless of location, I will continue as before. However, I do agree that using flood rights is vastly preferred for this and have received confirmation from Matiia that assigning myself flood rights for this activity would not constitute going outside of my approval. Based on this, I will temporarily assign myself the flood flag for the duration of runs. I also second what riley has said above. If lego has a script for this or knows someone who does, I would likewise be interested. --TheSandDoctor ^Talk 01:32, 10 April 2020 (UTC)

  I don't think there's an informed consensus here, mostly because most people here aren't really aware of what is being discussed. Legoktm (talk) 04:32, 11 April 2020 (UTC)

I don't think that's the case, Babel is the most public place for meta-Meta discussion, serving as the Village Pump for the project. In my opinion, those that wanted to have a say on this already did it, and from the ones that did, a consensus emerged that the lint errors should be fixed. Best, —Thanks for the fish! ^{talk•contribs} 01:57, 22 April 2020 (UTC)

Lego isn't saying the venue is inappropriate, he's saying that consensus isn't based on hard facts (i.e. that these changes have no substantive value). I'm personally fine with them so long as they are happening behind the scenes and out of my watchlist/the recent changes. – Ajraddatz (talk) 02:41, 22 April 2020 (UTC)

That makes more sense than my original thinking of the here in "most people here" being this page. Thanks for clarifying :) —Thanks for the fish! ^{talk•contribs} 20:19, 22 April 2020 (UTC)

Right. Most of the people commenting here don't appear to understand the technical issue being discussed, so it's not really possible to call it a consensus. Legoktm (talk) 23:09, 26 April 2020 (UTC)

Editing news 2020 #1 – Discussion tools

Read this in another language • Subscription list for this multilingual newsletter

This early version of the Reply tool automatically signs and indents comments.

The Editing team has been working on the talk pages project. The goal of the talk pages project is to help contributors communicate on wiki more easily. This project is the result of the Talk pages consultation 2019.

In a future update, the team plans to test a tool for easily linking to another user's name, a rich-text editing option, and other tools.

The team is building a new tool for replying to comments now. This early version can sign and indent comments automatically. Please test the new Reply tool.

• On 31 March 2020, the new Reply tool was offered as a Beta Feature editors at four Wikipedias: Arabic, Dutch, French, and Hungarian. If your community also wants early access to the new tool, contact User:Whatamidoing (WMF).
• The team is planning some upcoming changes. Please review the proposed design and share your thoughts on the talk page. The team will test features such as:
  • an easy way to mention another editor ("pinging"),
  • a rich-text visual editing option, and
  • other features identified through user testing or recommended by editors.

To hear more about Editing Team updates, please add your name to the "Get involved" section of the project page. You can also watch these pages: the main project page, Updates, Replying, and User testing.

– PPelberg (WMF) (talk) & Whatamidoing (WMF) (talk)

19:24, 8 April 2020 (UTC)

Notification of global ban proposal who were active on this wiki

English: This is a notification of global ban discussion against PlavorSeol, persuant to the global ban policy.

You are getting notified because they have edited on this wiki/blocked on this wiki.

한국어: 이 안내는 전역 추방 정책의 규정에 따라 PlavorSeol 사용자에 대한 전역 추방 논의를 알리기 위한 안내입니다.

이 사용자가 이 위키에서 활동한 전력이 있거나, 차단된 바가 있기 때문에 이 안내를 받게 됩니다.

— regards, Revi delivered by MediaWiki message delivery (talk) 16:25, 17 April 2020 (UTC)

Template:Main Page/Sisterprojects/Code

I was about to edit the page in title to make the text in it aligned but an admin suggest me to obtain consensus then I put a topic at its talk page. However, it did not got reply as of now, so I put it here. I advise to change the template above according to this diff to fix the alignment. Sincerely, Hamish 07:23, 18 April 2020 (UTC)

Please change all padlock (protection) images to a more simplistic, material design

Hello. Would you please completely change all the padlock/protection images to the one like this , It's really getting out of date and it needs to be completely redesigned to get a newer, fresher look. 126.26.147.201 11:42, 30 April 2020 (UTC)

How is that thing "fresh"? It looks like it's from Windows 95. For the record, the current one can be seen at MediaWiki talk:Protectedpagetext. --MF-W 12:59, 30 April 2020 (UTC)

Also, take a look at Special:ProtectedPages - you will notice we don't normally use "lock icons" at all here on meta-wiki. — xaosflux ^Talk 13:12, 30 April 2020 (UTC)

We already discussed it. Meta:Babel/Archives/2019-12#Padlock overhaul. — regards, Revi 14:06, 30 April 2020 (UTC)

Steward requests/Global becoming too long to navigate

This month, I saw that there are a total of almost 1,000 global locking requests, and that's a whole lot. I mean, that's really too many. But how can this be fixed at all though? 153.204.13.193 22:20, 30 April 2020 (UTC)

The global blocking for 2607:fb90::/32 is completely unnecessary.

I think that this kind of global block should be immediately lifted, because it will likely cause too much of a collateral damage. But how about you, stewards? 180.69.109.128 23:56, 30 April 2020 (UTC)