Meta:Babel/Archives/2012-12

Edit counter does not show opt-in data

http://toolserver.org/~tparis/pcount/index.php?name=Frze&lang=de&wiki=wikipedia works only in russian and english version. Why not in German (Monatsübersichten + Am meisten bearbeitete Artikel)? -- Frze (talk) 21:19, 1 December 2012 (UTC)

You have to ask w:en:User:TParis. AFAIK, the tool is or was already translated on translatewiki.net, but the new maintainer doesn't use the translations updated there. Nemo 21:45, 1 December 2012 (UTC)

You have to create User:Frze/EditCounterOptIn.js, I'll do it for you. Nemo 21:46, 1 December 2012 (UTC)

Thanks a lot, but unfortunately http://toolserver.org/~tparis/pcount/index.php?name=Frze&lang=en&wiki=wikipedia and http://toolserver.org/~tparis/pcount/index.php?name=Frze&lang=ru&wiki=wikipedia are working correct - but not the german version http://toolserver.org/~tparis/pcount/index.php?name=Frze&lang=de&wiki=wikipedia - (Monatsübersichten + Am meisten bearbeitete Artikel) are missing. What's wrong?? Thanks -- Frze (talk) 00:24, 2 December 2012 (UTC)

Bot suggestion

Greetings Meta Wikimedians

Is anybody here familiar with Wikipedia's SineBot that signs any posts that people forget to sign? I was wondering if anybody else believes that this would be a good addition to meta? Matticusmadness (talk) 23:15, 1 December 2012 (UTC)

New namespace on Meta

Hi all. This is just a quick announcement about the creation of a new namespace here on Meta, the Schema namespace. The purpose of this namespace is provide a publicly-viewable schema of data collected by the EventLogging extension. EventLogging is a new extension built and used by the editor engagement experiments team (primarily Ori Livneh), in order to replace the older, rather fragile ClickTracking extension. An example is Schema:OpenTask, which defines the data model for Research:Community portal redesign/Opentask.

Like the MediaWiki namespace, it is editable only by sysops. Somewhat similar to the MediaWiki namespace files for CSS and JavaScript, the Schema namespace only contains JSON, a data format. The namespace presents the data models in a table-like format, and if you try to enter anything except valid JSON, it won't accept it. We chose not to simply use the MediaWiki namespace after exploring that option (example, now removed), because rather than one long data model, we will actually need individual pages for each schema. We decided to host it on Meta because there is precedent for hosting resources used on other projects here (such as CentralNotice banners).

For now, I imagine this will mostly be edited by the experiments team members, and any other developers that are using EventLogging (for instance, the mobile team is using it). For Meta admins and Stewards: note that these schema are defining how we collect anonymized data from user activity on Wikimedia projects. Like AbuseFilter, messing with it can have consequences for other pieces of infrastructure, so please tread with caution.

Thanks, and speak up if you have any questions. Steven Walling (WMF) • talk 23:16, 29 November 2012 (UTC)

I don't understand, what's the problem with creating "individual pages for each schema" in MediaWiki namespace? Whether they're ten, a thousand or a hundred thousands pages, the MediaWiki namespace doesn't care (we already have so many MediaWiki pages for the centralnotice anyway). Why clutter search, preferences etc. etc.?

If it's needed, ok, Meta will bear it; I'm just curious because there's no actual reason above. Nemo 23:27, 29 November 2012 (UTC) P.s.: technically speaking, this is a thread for Meta:Babel.

Ori will probably have a more technical answer, but from my perspective as a person potentially writing and maintaining schema, if we wanted to use the MediaWiki namespace, the issue then becomes how we choose and maintain a strict naming system. Unlike say, a gadget which is only going to have a few files, the potential upper limit for schema is quite large. Having a new namespace helps us avoid naming conflicts, and makes the restrictions regarding presenting and validating JSON less confusing IMO. (Regarding the place for this thread: I am okay with moving it if you want Nemo. Thanks for the heads up.) Steven Walling (WMF) • talk 23:50, 29 November 2012 (UTC)

Naming conflicts, really? Perhaps I missed something. Are you going to create millions or billions of pages? --Nemo 07:07, 30 November 2012 (UTC)

The MediaWiki namespace does care. Message cache pollution is a real issue and the CentralNotice extension is one of many offenders that abuse the MediaWiki namespace. The MediaWiki namespace is for customizing (or localizing) the interface of the MediaWiki software. If it's being (mis-)used in other ways, those are separate bugs that should be addressed.

Regarding adding another namespace to Meta-Wiki, I think this namespace is a marked improvement over some of the past namespaces here (that were finally removed). There are some general bugs with how MediaWiki handles (or doesn't handle) having multiple namespaces on the same site (such as search usability, navigation [sidebars], etc.) that should also be addressed, but I don't see any reason to not do high-level content separation with a namespace in this specific instance. This seems like exactly what namespaces were designed for. (I'll also note that the upcoming Gadgets extension will take a similar approach using a "Gadget" namespace.) --MZMcBride (talk) 03:18, 30 November 2012 (UTC)

You don't have any reason not but you didn't say any reason for either. These schemas fall within the very typical usage of MediaWiki namespace for customization, as you said. Are you saying we need a namespace so that people can search the schemas, or what?

Forgive me, I don't have anything against the creation of yet another namespace (I'm among those who care less) but I'd like to understand the [missing] rationale. --Nemo 07:07, 30 November 2012 (UTC)

"These schemas fall within the very typical usage of MediaWiki namespace for customization'" actually no... MediaWiki namespace is almost entirely interface modification as MZ specified. These schemas do no interface modification whatsoever. Steven Walling (WMF) • talk 08:10, 30 November 2012 (UTC)

The most important pages in MediaWiki namespace are things like title blacklist, spam blacklist, other things like MediaWiki:babel-template or MediaWiki:Newusermessage-substitute‎ which change how an extension works... "Interface" can mean anything. But again, you're discussing on terminology rather than focusing on actual needs and functionality. --Nemo 08:33, 30 November 2012 (UTC)

Categories go in a category namespace. Templates go in a template namespace. User pages go in a user namespace. MediaWiki interface pages go in a MediaWiki namespace. Gadgets go in a Gadget namespace. Schemas go in a Schema namespace.

The rationale was that MediaWiki supports high-level content separation and it doesn't make sense to further pollute the MediaWiki namespace with pages that are irrelevant to or outside of its purpose. I'm not sure what more explanation you're after. :-) --MZMcBride (talk) 14:42, 30 November 2012 (UTC)

Categories, templates and user pages are not protected to start with; a gadget namespace doesn't exist. This is just your opinion/fantasy/religion, not a fact; might be desirable or not, but it's just not an explanation or rationale. --Nemo 14:45, 30 November 2012 (UTC)

My opinion/fantasy/religion? Don't be an asshole, please. I didn't rewrite the Gadgets extension to use a separate namespace. The fact that it does (or soon will) is relevant in the context of a discussion about high-level content separation, especially as it relates to MediaWiki extensions. (I also didn't create the concept of namespaces such as Category and Template and User for high-level content separation, but the fact they're widely used and supported is also relevant here.)

Is your grievance about the sysop-only default protection of the Schema namespace or are you simply making noise for the sake of making noise? You came close to admitting above that you don't even really care about this issue, so it's becoming increasingly difficult to reply to your posts. High-level content separation makes sense. It has some usability warts, but what exactly are you trying to get at? Do you have a legitimate issue to bring up? --MZMcBride (talk) 14:54, 30 November 2012 (UTC)

Sigh.

Also, "close to"? I said it clearly. Nemo 15:13, 30 November 2012 (UTC)

There's surely a difference between saying you don't care about the issue and caring about the issue. --MZMcBride (talk) 03:11, 1 December 2012 (UTC)

I give up. I'll answer my question myself: none of the above KiB provides any rationale, and logic disallows me to believe we can create namespaces without rationales. However, I looked around a bit and gerrit:36136 suggests that the rationale is to distinguish user permissions so that Staff can edit those pages even if blabla. Looks like instructions creep (currently useless with out permission system), but at least it's a valid reason for namespace creation. Thanks, Nemo 15:13, 30 November 2012 (UTC)

Please don't give up. I agree that providing a clear reason up front is essential with things like this. There were of course reasons leading to the decision, and neglecting to articulate those reasons when seeking a change is indeed a significant oversight. Thank you for speaking up about this. -Pete F (talk) 15:54, 30 November 2012 (UTC)

What oversight? I'm still pretty lost as to why any of this is confusing. Schemas go in a Schema namespace, just as users go in a User namespace and categories go in a Category namespace. It seems perfectly natural to me to use a separate namespace for this. Mis-using the MediaWiki namespace would have been a bad idea and I'm glad it isn't being further polluted. Namespaces were designed for high-level content separation and these types of pages are clearly not like other pages (e.g., Schema:Sandbox). --MZMcBride (talk) 03:11, 1 December 2012 (UTC)

I'll bite on Steven Walling's call for questions, but limit myself to just a few:

• Regarding the stated purpose, to "provide a publicly-viewable schema of data collected by the EventLogging extension." – What is the intended benefit of hosting this on-wiki in a "publicly-viewable" format rather than as part of the extension's codebase? Is each new extension now going to have its own dedicated namespace(s) for similar purposes?
• Regarding the scope of use, "used by the editor engagement experiments team" – Is "Schema" an appropriate global name for a component of a particular team's extension using a particular schema language? What would we call the schemata of other team's extensions, or future extensions from this team?

I encourage folks to think about dedicated namespaces from a big-picture perspective. ~ Ningauble (talk) 16:07, 1 December 2012 (UTC)

You think an extension's codebase is comparably accessible (in terms of reading or writing) to a wiki page? I think you're discussing apples and oranges.

I don't imagine most extensions will need their own namespace. As mentioned above, certain extensions such as the Gadgets extension will one day have their own namespace. Probably CentralNotice as well. Will Poem or ExpandTemplates or WikiHiero? Probably not. Whether an additional namespace (as a means of high-level content separation) is needed depends on the purpose and implementation of the particular extension.

Regarding the "Schema" namespace name, I brought this up as well. It doesn't make any mention of the EventLogging extension or JSON. That said, I'm not sure a more specialized namespace name would help anything here. --MZMcBride (talk) 16:15, 1 December 2012 (UTC)

No, I do not think they are comparable at all. They are so completely different that I am finding it hard to imagine why someone who is not conversant with the application's code base would have any business editing its data definition schema on-wiki. I don't think my question is answered: I do not understand the benefit that the stated purpose provides. ~ Ningauble (talk) 17:39, 1 December 2012 (UTC)

MZ has given a fine answer I think, but since you asked me directly I'll have a go...

• Regarding the stated purpose, to "provide a publicly-viewable schema of data collected by the EventLogging extension." – What is the intended benefit of hosting this on-wiki in a "publicly-viewable" format rather than as part of the extension's codebase? Is each new extension now going to have its own dedicated namespace(s) for similar purposes?
  • Some background in how data models are created is necessary here, if you'll forgive me being a little longwinded: The definition of what data is collected doesn't usually come from developers. It comes from data analysts and product managers (I'm the latter), whose job it is to figure out what data we need to make good decisions about features. These data models can change depending on how the features change, whenever we add new features, etc. Putting schema in to a wiki takes care of the revision history for us, and closes the loop between anyone who might want to collect some data and developers who make it happen. As a side benefit, it also means that exactly what kind of user data we collect is completely public. In short, creating and maintaing data models is collaborative process no matter who is doing it at Wikimedia, and the best platform for collaboration is the wiki itself. JSON itself is designed to be human-readable, and is far from difficult for anyone in Wikimedia engineering to write, even if they're not a programmer. There are other benefits to choosing Meta in particular, since it is optimized to host global resources like banners.
• Regarding the scope of use, "used by the editor engagement experiments team" – Is "Schema" an appropriate global name for a component of a particular team's extension using a particular schema language? What would we call the schemata of other team's extensions, or future extensions from this team?
  • The key word you omitted from my statement is "mostly". We built this for our own purposes, but as I said above, EventLogging is already being used by mobile as well, and it's likely that it will expand beyond our two teams. There is also potential for any volunteer MediaWiki developer to use EventLogging and the Schema namespace, if they'd like to do the legwork. If anyone else wants to use this system, they wouldn't create their own new namespace, because it's simply not necessary. They'd just create any new pages in the Schema namespace that they needed.

Hope that answers your questions further. Steven Walling (WMF) • talk 01:50, 3 December 2012 (UTC)

Thanks Steven, for a cogent explanation. I now understand (1) that the stated purpose relates to public disclosure when data analysts and product managers to interface collaboratively with developers, and (2) that the "Schema" namespace is for the exclusive use of the EventLogging extension, but not for the exclusive use of the E3 team. I am not sure this implementation is ideal, but it seems reasonable enough. ~ Ningauble (talk) 19:45, 3 December 2012 (UTC)

This looks very cool. Thanks for the heads-up. –SJ talk  02:34, 3 December 2012 (UTC)

+1 SJ -- thanks much for the explanation, Steven! Sounds great. -Pete F (talk) 03:47, 3 December 2012 (UTC)

Renaming the Local Embassy

Moved to Wikimedia Forum because this will affect embassies on all wikis, not just Meta-Wiki. πr² (t • c) 04:38, 15 December 2012 (UTC)

Iberocoop namespace

Hello all! Why was an Iberocoop namespace created? We don't have namespaces for other cross-language/project/chapter projects, like Skanwiki, Cooperation of Wikimedia's Italian regional projects, African languages, Promoting the Southeast Asian languages projects, and Slavopedia (Славопедиа). Also, there are not many pages in the Iberocoop namespace and there are subpages of Ibercoop which are not in the Iberocoop namespace. Why not just use subpages of Iberocoop? πr² (t • c) 04:02, 15 December 2012 (UTC)

I dunno about the others but the italian cooperating thing is dead and was born dead. Snowolf ^{How can I help?} 00:33, 16 December 2012 (UTC)

Yeah I agree, I can't remember when this namespace was created but I believe at the time it was done without the community consensus of people here on Meta, and given that only 7 pages exist is this namespace, I'd be inclined to agree with you PiRSquared and move it back to mainspace as subpages. Let's see what others have to say. Thehelpfulone 00:37, 16 December 2012 (UTC)

Huh, it turns out that this discussion did indeed happen, (see Meta:Babel/Archives/2012-07#Namespace for Iberocoop in Meta) and that there was consensus for the creation of it. My apologies for the confusion, and after reading the discussion on that page now I agree that it makes sense for this namespace to exist (I didn't know that there was an existing wiki for example). I do remember that there was one namespace that appeared without prior consultation but clearly I've got mixed up with which namespace it was! Thehelpfulone 01:10, 16 December 2012 (UTC)

Agreed with all above. -Mh7kJ (talk) 00:38, 16 December 2012 (UTC)

None of the user groups mentioned above is in any way comparable to Iberocoop. As for the reasons for the creation of the namespace, please see the original discussion; yes, not all the content the namespace was created for has been moved in it yet, but it's just been created, several months after it was asked, so it's not unlikely that any momentum they initially had for the cleanup and move may have weakened, or that like all volunteers they've recently had less time for it than they had before, etc.
We constantly talk of how our several wikis should be combined in Meta and so on, but then we are hostile in all ways to people trying to work here? It's possible that our initial reaction made Iberocoop people think that Meta is just too hostile and frozen an environment for them to work here, but if there's still any possibility that what they were trying to do will work it makes no sense to kill it. I'd say wait a year or two to see if the namespace is really a failed experiment and only then evaluate it; now it's just too soon. Nemo 01:01, 16 December 2012 (UTC)

Removal of Meta from wikimedia.org portal

See talk page. --Nemo 08:39, 27 December 2012 (UTC)