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.
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.

2FA tester local group on metaEdit

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.--AldnonymousBicara? 09:14, 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)

Broken Babel templates for Mandarin Chinese (cmn)Edit

Currently, {{#babel:en}}, which should be for English, displays the same message as {{#babel:cmn}}, which should be for Mandarin Chinese, as well as all of their respective levels. What would be the way to go about fixing this?

User language
en-N This user has a native understanding of English.
Users by language
User language
cmn-N This user has a native understanding of English.
Users by language

Your help is greatly appreciate, please ping me if you reply. The Editor's Apprentice (talk) 18:22, 20 March 2020 (UTC)

English is always the default if the language is unknown. When did this first start happening? --DannyS712 (talk) 18:37, 20 March 2020 (UTC)
I have no idea when it started happening, I just noticed. The Editor's Apprentice (talk) 22:26, 20 March 2020 (UTC)
Its not just babel. Filing a bug report --DannyS712 (talk) 22:31, 20 March 2020 (UTC)
phab:T248210 --DannyS712 (talk) 22:33, 20 March 2020 (UTC)
Intriguing, thank you very much for your prompt responses and action. I am curious to see how this develops. The Editor's Apprentice (talk) 22:39, 20 March 2020 (UTC)
An additional note, on other sites, such English Wikipedia, {{#babel:cmn}} displays the sentence "This user has basic knowledge of Mandarin Chinese." which is a confusing mix since it is written in English, but correctly identified the language as Mandarin Chinese. —The Editor's Apprentice (talk) 00:03, 21 March 2020 (UTC)

Spam domain nameEdit

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 pagesEdit

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)

  • 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)
  • 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)
  • 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)
  • 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)