Stewards' noticeboard/Archives/2014-01

Renaming namespaces

Hi, i found a little problem. On ro.wiki namespace ”Module” is not translated correctly.
Currently it's name is "Module", but this is not proper name for romanian language.
In romanian language:

module = modul

module_talk = discuție_modul

Without "e" at the end! In romanian, if you put "e" at the end, it will become the plural. So, currently we have there all namespaces at singular (normally), and only module is at plural.

• You can look here for translation to believe me https://translate.google.ro/#en/ro/module
• And also look here for definition (in ro.) http://dexonline.ro/definitie/modul (site DEXonline.ro == Romanian Explicative dictionary online)
  

I asked our local birocrats at "Village Pump" if they can rename namespaces, but no one reply in 2 ¾ days. Probably they can't, so i decided to write here. Thank you. XXN (talk) 17:59, 1 January 2014 (UTC)

<non-steward answer>(Btw, this is not a Steward-thing). Also on fi-wiki it's named as "module" when it should be "moduuli". I've tried to find the correct place to change those translations, but I'm not sure where to do it. It's not possible in Translatewiki. Translations for Module namespace were asked on Meta many months ago (also Gerrit change), but when it was asked there I didn't know about that. So maybe we should make a request on Bugzilla to rename those namespaces. --Stryn (talk) 18:20, 1 January 2014 (UTC)

The correct place to ask is translatewiki:Support. --MF-W 18:24, 1 January 2014 (UTC)

Yeah, the translation updater bot handles this automagically (you need to submit a patch to gerrit). Just ask on TWN. PiRSquared17 (talk) 18:25, 1 January 2014 (UTC)

Thank you for redirection to right place to solve my problem. --XXN (talk) 19:35, 1 January 2014 (UTC)

I also asked Matma Rex to help us with this issue. Rsocol (talk) 05:34, 3 January 2014 (UTC)

Patch submitted: https://gerrit.wikimedia.org/r/105175 – it should go live within a few weeks (16 January on Wikipedias if everything goes right), see mw:MediaWiki 1.23/Roadmap. Matma Rex (talk) 13:15, 3 January 2014 (UTC)

Proxy server

Please, translate it. Thank you.

Hola, soy un administrador de la Wikipedia en español y detecté que el rango 14.32.0.0/11 pertenece a servidores proxy. Pero debido a que es muy amplio, no me animé a bloquearlo. ¿Pueden ustedes confirmar esto y tomar las medidas necesaria? Gracias anticipadas. --Metrónomo-Goldwyn-Mayer 05:22, 4 January 2014 (UTC)

Checkusers on loginwiki

Stewards nowadays often do checkuser actions on loginwiki for crosswiki checkuser activities like identifying spambots, interrogating IP ranges for effects of potential global blocks, and the identification of accounts undertaking crosswiki long-term abuse. In loginwiki's checkuser data every creation of a global account is recorded once. No other data (e.g about edits) are there because no edits happen on that wiki.
You can see the frequency on Special:Log/rights, which nowadays is cluttered by such actions ("permanent link": [1], e.g. [2], [3]).
The setting and removing of the checkuser rights on one's own account everytime one does a check is quite annoying and one also tends to "forget" (either really or intentionally to save clicks for the next check) to remove the flag at times. For this reason, I'd like to announce in the name of stewards that from now on those who want will keep the checkuser rights on loginwiki permanently (of course it will be removed when they stop to be stewards).
For the information of the community, we will create Stewards/CheckUser statistics for loginwiki (similar to commons:Commons:Checkusers/Statistics and en:Wikipedia:Arbitration Committee/Audit Subcommittee/Statistics) so that everyone can still see who is active doing CU actions there. --MF-W 21:09, 2 January 2014 (UTC)

Sorry, but you are not announcing anything here in the name of stewards as there isn't consensus even between stewards (specially when it is said that stewards are intentionally "forgetting" to remove rights). Stewards are not in position to announce such change; we are not allowed to disobey checkuser policy, that says:

If local CheckUsers exist in a project, checks should generally be handled by those. In emergencies, or for multi-project CheckUser checks as in the case of cross-wiki vandalism, Stewards may perform local checks. Stewards should remove their own CheckUser access on the projects upon completion of the checks and notify the local CheckUsers or the CheckUser e-mail list.

So, local rights are temporary and we have to remove it upon completion of checks. There is no exception. If time has come to change it, fine. Let us discuss that with community and change policy. I think that may be a good idea. However, we are not the ones empowered to decide in the name of community.

At least, two stewards were not agreed on a not really long discussion on list. Please, revert that as you can't add checkuser rights without a valid reason. In fact, you just can't add permanent CU rights for yourself with any reason.

I understand you have good intentions on doing that and want to improve stewards' capacities to better deal with spambots, but, even though in good faith, we have to follow regular procedures, we have rules to follow, we have a community to listen to and make this kind of decision in our name; not the opposite. Regards.—Teles «Talk to me ˱_{C L @ S}˲» 17:38, 3 January 2014 (UTC)

Well, a discussion started on stewards' mailing list a week ago; the announcement draft was sent by me 5 days ago. At the time I posted this, there were no stewards who had expressed disagreement, so I could very well have announced this in the name of stewards. By the way stewards did express on the list that they intentionally don't remove their CU rights there.

About the quote from CU policy, I already said on the ML that that whole section only talks about what to do on projects with local CUs.

I couldn't find anything in Stewards policy or CU policy that says explicitly that rights we self-grant in order "to act as a member of any permissions group on any project with no active member of that permissions group" (S) must always be removed. It is reasonable of course in most cases, but not here. For the same reason, the global group already contains permissions that local sysops, crats etc. have. In fact, I think nothing policy-ish prevents us from creating a global group which would have checkuser rights, and be restricted to wikis without local CUs. --MF-W 18:03, 3 January 2014 (UTC)

• I also would like to note my disagreement with the feelings and reasoning expressed by the statement posted here. I strongly believe that granting ourselves permanent CU access on a local wiki is a violation of both the letter and the spirit of the Checkuser policy as well as being in general a bad idea without the updating of policies to proper regulate this new development.. I offered full reasoning for this in two post to the mailing list that I made after this was posted. While I disagree with the feelings expressed, I think it was entirely fair for MF-Warburg to post the statement as at the time no objections to its content, as I understand it, had been made on the mailing list or elsewhere. And no, MF-Warburg, the Checkuser policy does prevent us from having any sort of global CU, specifically stating that such a thing is restricted to the OC. Snowolf ^{How can I help?} 19:17, 3 January 2014 (UTC)
  • Hm yes, you are probably right on global CU; I retract this stuff about the possibility to create a global group with checkuser rights. I'll catch up with the ML posts soon. --MF-W 00:07, 4 January 2014 (UTC)

If we want to add rights like 'suppressredirect', 'block' (...) on Steward group, fine; they are uncontroversial, not ruled by important policies like CU/OS. However, changing rights that involve private data requires more participation. We can't even decide only by reading checkuser policy; that is a new situation, unpredicted by policy which is now outdated and justifies consulting the community. So, those few stewards that were agreed with this change just gave their personal opinions on the matter.
There was no reason for a decision like that has been taken in a one-week discussion on a private list between stewards. We were not chosen to decide in the name of community, but to decide according to rules or when it is uncontroversial.
It is not consensual between stewards; it's not consensual between community. If loginwiki has no local community and will never have, we all should know that Meta is the place to ask that. Regards.—Teles «Talk to me ˱_{C L @ S}˲» 09:23, 11 January 2014 (UTC)

VisualEditor rollout

Just a heads-up that mw:VisualEditor will made available as opt-out to all users at about 20 mid-sized Wikipedias on Monday, 13 January 2013. This isn't expected to affect the Stewards, but just in case someone contacts you with an emergency, please contact User:Jdforrester (WMF) or find someone on IRC at #mediawiki-visualeditor. Thanks, Whatamidoing (WMF) (talk) 19:15, 10 January 2014 (UTC)

Changes to local wiki

Is here any global sysop who can help me with some edits on ro.wiki?

• It's necessary to add to ro:MediaWiki:Common.css, this sequence of code

.navbox-inner,
.navbox-subgroup {
width: 100%;
}

• Also in ro:MediaWiki:Sp-contributions-footer it's necessary to change obsolete toolserver links

[http://toolserver.org/~tparis/pages/index.php?name={{urlencode:{{{1|$1}}}}}&lang=ro&wiki=wikipedia&namespace=0 Articole create]

must become

[http://tools.wmflabs.org/xtools/pages/index.php?name={{urlencode:{{{1|$1}}}}}&lang=ro&wiki=wikipedia&namespace=0&redirects=noredirects&getall=1 Articole create]

and

[http://toolserver.org/~vvv/sulutil.php?user={{urlencode:{{{1|$1}}}}} Conturi în alte proiecte]

must be changed to

[https://tools.wmflabs.org/quentinv57-tools/tools/sulinfo.php?username={{urlencode:{{{1|$1}}}}} Conturi în alte proiecte]

• Also Template NAVBOX must be repaired by ading this code

  {{#invoke: Navbox | navbox }}<noinclude> {{documentation}} </noinclude>

  (Actually it is broken and redirected, and due to this, on rowiki we have all navboxes broken (example1, example2, example3 I created specially for it ro:Modul:Navbox + other 2)//Note: try collapse template; and look at three buttons. )
  

I have knowledges, but i haven't sufficient rights. I proposed those modifications on rowiki local "Village pumps", but beacause i am in a open conflict with some staff members, they intentionally ignore me. Thanks you. --XXN (talk) 17:52, 22 January 2014 (UTC)

Global users can not act in this case because there are plenty of local administrators. Ruslik (talk) 18:46, 22 January 2014 (UTC)

 Closed

Global Flow permissions

Hello,

Flow uses a different set of permissions (flow-delete, flow-hide, etc.), which are all now available to global groups (bugzilla:59794). flow-delete and flow-edit-post are considered to be administrator level privileges and are probably worth giving to GS'es/stewards. flow-suppress is for suppressing content (obviously!). flow-hide is for hiding posts, but it's automatically given to any logged in user, so probably isn't necessary to be added to a global group. Thanks! Legoktm (talk) 20:03, 16 January 2014 (UTC)

Done for both Global sysops and stewards. Thank you for poking. Snowolf ^{How can I help?} 20:19, 16 January 2014 (UTC)

How did you do that? I mean, without editing the localsettings.php... — The preceding unsigned comment was added by 2001:470:c:156::8 (talk)

Stewards can change the rights of global groups via Special:GlobalGroupPermissions. --MF-W 21:11, 16 January 2014 (UTC)

But there is no page like that for local rights? That's only for CentralAuth, and I'm guessing it was designed specifically so that WMF stewards can edit those rights, am I correct? 2001:470:C:156:0:0:0:8 21:20, 16 January 2014 (UTC)

no, it isn't only for centralauth. Yes, it was designed so stewards can change rights from there. Matanya (talk) 21:22, 16 January 2014 (UTC)

This is wrong. Special:GlobalGroupPermissions is a page made by CA and only deals with global groups. --Krenair ^{(talk • contribs)} 21:41, 16 January 2014 (UTC)

so where does one go to change the local rights? and don't say special:UserRights. 2001:470:C:156:0:0:0:8 21:31, 16 January 2014 (UTC)

special:userrights it is. see steward handbook. Matanya (talk) 21:35, 16 January 2014 (UTC)

I think they mean changing the rights each group has like Special:GlobalGroupPermissions but locally, not who is in which group. To answer the question: You can't. It has to be done through LocalSettings.php (on most wikis - WMF stores this elsewhere) until this change is done. --Krenair ^{(talk • contribs)} 21:38, 16 January 2014 (UTC)

Added flow-suppress to the stewards group (was forgotten apparantly). The other stuff was already done.[4] Trijnstel_talk 21:32, 16 January 2014 (UTC)

It was not forgotten but I have no real issues with the addition. Snowolf ^{How can I help?} 21:53, 16 January 2014 (UTC)

AAR changes

Hi. There have been some changes to the wording of the admin activity review page. If you disagree with them, feel free to change them back or discuss them. PiRSquared17 (talk) 03:50, 22 January 2014 (UTC)