Meta:Babel/Archives/2017-01

계정이름

계정이름 어떻게 바꿔요?--트와이스광팬입니다잘부탁트려요ㅋㅋㅋ위키백과초보자입니다 (talk) 04:26, 2 January 2017 (UTC) Changing username

(If the automatic translation I checked can be trusted) @트와이스광팬입니다잘부탁트려요ㅋㅋㅋ위키백과초보자입니다: How to change your username is explained at Changing username.--QuimGil (talk) 10:37, 2 January 2017 (UTC)

That was correct, and it seems to be done. — regards, Revi 08:27, 10 January 2017 (UTC)

Enabling RSS extension on Meta wiki

Tracked in Phabricator:
Task T155830 resolved

Wikimedia Germany Policy Team are setting up their page on Meta (its current draft is at https://meta.wikimedia.org/wiki/DE_policy) and we would like to have a RSS feed of policy-related news (hosted at https://tagteam.harvard.edu/hubs/wmde-policy-update/tag/rss/wmde.policy.update) included there.

In order to achieve this we'd like to have RSS extension enabled here. Thanks, Leszek Manicki (WMDE) (talk) 12:06, 23 January 2017 (UTC)

I'm not very familiar with RSS. What is that suposed to do? Thanks, —MarcoAurelio 12:47, 23 January 2017 (UTC)

It generates wmf:Home#Recent Wikimedia blog posts, for instance. Enabling the extension is ok from a user perspective, but beware that each feed needs to be whitelisted individually. Nemo 14:38, 23 January 2017 (UTC)

Yes, each feed needs to be whitelisted per wiki so it can be actually used, which is good: just enabling the extension does not mean all possible RSS feeds could be randomly included. And to clarify, it might not have been obvious from my first message: We'd like to have RSS extension enabled AND the RSS I linked to above whitelisted. Leszek Manicki (WMDE) (talk) 07:50, 24 January 2017 (UTC)

This sounds fine to me. As Nemo notes, we already use this extension on other Wikimedia wikis, including wikimediafoundation.org and mediawiki.org (cf. "wmgUseRSSExtension" in <https://noc.wikimedia.org/conf/InitialiseSettings.php.txt>). It's simple enough to add 'metawiki' => true, and configure the extension as needed. --MZMcBride (talk) 03:51, 24 January 2017 (UTC)

Looks do-able to me. I have no reason to object. --Vogone (talk) 08:31, 24 January 2017 (UTC)

I'd say there's consensus to move forward with this after the explaining of Leszek. —MarcoAurelio 15:24, 28 January 2017 (UTC)

On translating by unregistered contributors

Over the time the translation extension has been enabled I find that (& maybe I'm wrong) that many translations which are being done by unregistered contributors are tests and vandalism, or made no sense at all. It is also true that there might be good translations but those I've encountered 'mopping' the site were not. As such I'd like to ask for comments as to if we could restrict the translation tools just to registered contributors or do you have a better idea on how to handle bad translations from unregistered contributors. Regards, —MarcoAurelio 12:44, 23 January 2017 (UTC)

Having translation open for unregistered editors is very useful: I often direct people to Special:Translate on Meta-Wiki when they ask for an easy way to contribute to Wikimedia, even when they're not registered yet. This way I've managed to involve some professional translators and copywriters who had offered their services but had no experience with Wikimedia yet.

Moreover, Special:Translate is the only way to edit translation pages: if we disabled it, non-English editors would be discriminated in their ability to experience a "really wiki" Meta-Wiki. This would easily end up discouraging people from making more pages translatable, since that would come to equate semi-protecting all subpages.

Last but not least, I don't think we should proceed to any decision without at least some data. I don't yet see a reason to believe unregistered contributors are especially harmful when it comes to translation. In fact, I've just spot-checked Special:SupportedLanguages/it and, from a small sample, 60 % of unregistered contributors are productive. This proportion is often higher in certain important pages, where we direct a wider audience of non-wikimedians and where unregistered users end up translating where registered users gave up: for instance Free knowledge based on Creative Commons licenses/it. It would be sad to give up translating such important pages which are of interest beyond Wikimedia editors. --Nemo 14:36, 23 January 2017 (UTC)

I'm not sure if setting translate rights only to registered contributors really hinders our work and don't understand where that discrimination would appear. Pages translated are visible to all users, being registered or not. Creating an account is easy and anyone really interested would for sure create it. Thanks, —MarcoAurelio 15:23, 28 January 2017 (UTC)

Well, but based on that argument one could disable anonymous editing altogether. --MF-W 20:06, 28 January 2017 (UTC)

Old discussions about the same thing: Meta:Babel/Archives/2016-08#Translations_by_IPs, Meta:Babel/Archives/2014-03#Translations_for_autoconfirmed. --Stryn (talk) 14:50, 23 January 2017 (UTC)

I agree with Nemo above. To answer the question how to deal with bad translations: The same way we deal with other bad edits, i.e. reverting and making the user in question aware that metawiki is not a sandbox. Individual page protections can be set as needed. --Vogone (talk) 20:40, 28 January 2017 (UTC)

IIRC, page protection does not work well with translate subpages, since they mirror what the translator does on the Translations: namespace. I'm not even sure if AbuseFilter supports that either. That's why I think a mild restriction such as requiring an account, which is nothing hard to get, could work. Obviously if people is happy with the status quo no changes will be made. —MarcoAurelio 11:44, 29 January 2017 (UTC)

Protections in the Translations: namespace work just as well as in any other namespace, as far as I am aware. --Vogone (talk) 17:16, 29 January 2017 (UTC)

Enabling Dashiki Extension on Meta wiki

Tracked in Phabricator:
Task T156971

The Analytics team at Wikimedia Foundation would like to enable Dashiki, a simple extension that would clean up storage of dashboard configurations on meta.wikimedia.org. Currently, we store configuration for dashboards in articles such as Dashiki:DefaultDashboard/wikimetrics. After deployment of the extension, we would move all such articles to the Config: namespace, under the Dashiki: sub-namespace. For example, this is how the article would be rendered by the extension: deployment.wikimedia.beta.wmflabs.org/wiki/Config:Dashiki:TestConfig. This way, both users of Dashiki and other editors can understand the page better, and we can clean up the main namespace. The task we've been using to develop the extension and get it deployed to beta is here.

I can give any context, about Dashiki, the extension, plans going forward, or anything people might be interested in, just wanted to stick to the basics to start. I would appreciate the community's permission to deploy this extension or a discussion about any potential problems. Milimetric (WMF) (talk) 21:21, 30 January 2017 (UTC)

Thank you for this post! It looks like Meta-Wiki would be the first Wikimedia wiki to install mw:Extension:Dashiki?

Yes, first and only. We would like to centralize all dashiki configs on meta. Milimetric (WMF) (talk) 03:46, 31 January 2017 (UTC)

We already have pages such as Config:VisualEditorAndWikitext on this wiki. I thought these pages were living in a real namespace (the documentation at mw:Extension:JsonConfig suggests that namespace ID 482 is used by default), but when looking at these Meta-Wiki pages, they're currently living in namespace 0. We'd need to move these existing "Config:"-prefixed pages to the new namespace or move them elsewhere. --MZMcBride (talk) 00:10, 31 January 2017 (UTC)

Yes, I will personally move all of these pages to the new Config:Dashiki sub-namespace as soon as it's available. The Config namespace is not quite right, the Dashiki sub-namespace puts just a tiny custom render on top of that. Milimetric (WMF) (talk) 03:46, 31 January 2017 (UTC)

There's a maintenance script to do it. A shell user should just run that on Meta-Wiki and it'll move all the pages, assuming we want to set up a Config namespace here. --MZMcBride (talk) 00:29, 1 February 2017 (UTC)

I'm finding Meta being converted slowly in mediawiki 2.0 with lots of technical stuff that few people is able to understand. Can I please be explained why is this needed and what it'd do? Not opposing, but I'd really like to know what that would do. There's also a Schema: namespace I don't know what it does. Thanks indeed for the notice. Best regards, —MarcoAurelio 10:37, 31 January 2017 (UTC)

I understand what you mean, I'll try to explain as well as I can. The most important part is that many of us think putting configuration on a wiki is a really good idea. It provides some transparency into what we're doing, though I can see how sometimes we need to explain the transparency a little bit better. If we agree on this point, the remaining questions are how do we put the configuration on the wiki and which wiki. In both cases, Config:Dashiki: and Schema:, we need to store JSON which is a little ugly in a raw format. So the custom namespaces simply make raw JSON look a little prettier and they add some convenient copy and paste code for developers. As for which wiki is best, meta seems like the best choice among existing wikis. If we had a technical-meta wiki, that would fit better, perhaps. So, the remaining question is do we agree that putting configuration on the wiki is a good idea in the first place? I will try to explain why I think that's the case for Dashiki and EventLogging, please let me know if you'd like more detail, and we can talk on IRC in #wikimedia-analytics or #wikimedia-office if you'd like. So, EventLogging is a tool that helps both community and WMF staff collect information. One option would be to hide what information it's collecting in code so that only technically proficient people can understand. But the creator of EventLogging thought that was contrary to our values and wanted to make sure everyone could access what kind of information is being collected. So, for example, Schema:MediaViewer explains that the MultimediaViewer extension collects sampled logs of how people interact with it. If this page did not exist, someone would have to read this code instead. Even better, Schema_talk:MediaViewer has information about the author of this collection and how soon the data is being purged from our servers as well as links to how much data is being collected. This all allows the community to engage with this kind of collection without having to know how to read code. Another tool we use is Dashiki: it renders dashboards that are useful for our movement, such as vital signs or browser statistics. That first dashboard, vital signs, is configured by Config:VitalSigns. This way if the community wishes to maintain a dashboard, they can do so by editing this article directly. Right now, Dashiki is not 100% ready for this use case, but this deployment is one more step. I hope this explanation helps, please let me know if anything was confusing. Milimetric (WMF) (talk) 15:32, 31 January 2017 (UTC)

Since Meta-Wiki runs on MediaWiki, wouldn't a slow move to MediaWiki 2.0 mean that we're upgrading regularly? I would think this would be a good thing. :-) Meta-Wiki is a central place for various sub-communities, in some ways no different than the English Wikipedia or the Spanish Wikinews being a central place for various sub-communities. There are certain parts of the user interface that may need additional love if we continue to add namespaces, but in general, if people want to house technical configuration related to all Wikimedia wikis on this wiki, I think that's fine. --MZMcBride (talk) 00:32, 1 February 2017 (UTC)

Thank you. And also, I agree that adding too many namespaces is not a great idea. That's why this just used a sub-namespace of the already existing Config namespace. So no new namespaces have to be assigned and semantically this is definitely configuration so it fits fine inside Config: If there are no objections, I'll start the task to get this deployed and report back here on the status. Thanks again for the thoughts. Milimetric (WMF) (talk) 04:02, 1 February 2017 (UTC)

@Milimetric (WMF) and MZMcBride: Thank you for the explanations. I see that most of you think this would be a good idea and I do not perceive it'd be harmful. Maybe we should restrict editting of that namespace to autoconfirmed users to avoid messing with config issues, or even higher? Oh, and when I was refering to MediaWiki 2.0 I meant that I feel sometimes we install things which are very technical/not all users are able to understand, as it happens in MediaWiki, where advanced technical configuration is stored. But I appreciate Milimetric's detailed reply and of course appreciate that Meta receives more love from developers and is kept up-to-date :) Regards, —MarcoAurelio 22:04, 1 February 2017 (UTC)

@Milimetric (WMF): What will this extension do differently than if we didn't have it? How would I notice that it had been installed? —Justin (koavf)❤T☮C☺M☯ 04:11, 1 February 2017 (UTC)

@Koavf: This page Dashiki:DefaultDashboard/wikimetrics will be moved to Config:Dashiki:DefaultDashboard/wikimetrics and it will look like this instead. So you'll notice less pollution in the main namespace and nice looking config pages. Milimetric (WMF) (talk) 16:02, 1 February 2017 (UTC)

@Milimetric (WMF): Great. And what are some examples of times where a normal user such as myself might edit pages in that namespace? —Justin (koavf)❤T☮C☺M☯ 17:36, 1 February 2017 (UTC)

@Koavf: If you make a dashboard such as this one, you can configure it from a page in this new sub-namespace. Most people probably won't do this, but it's there if you need it. As for patrolling the namespace, so far we haven't seen any problems but it can be harder to look for them without a dedicated prefix. Milimetric (WMF) (talk) 21:52, 1 February 2017 (UTC)

I see that the namespace to be added would be a Config: one and pages will be named Config:Dashiki:<module_name>. Could, maybe, work be done in the future so its naming be either Config: or Dashiki: and not Config:Dashiki: ? —MarcoAurelio 22:11, 1 February 2017 (UTC)

The Config: namespace is a parent namespace that's meant to hold all configuration-type namespaces inside it. This is a good idea because it prevents the creation of potentially hundreds of other new namespaces for all the different types of configuration people want to add to meta. So it's good that it's in Config:Dashiki:, it keeps things organized and makes extensions like the one I have to deploy extremely simple to build and maintain. Does that help explain it or do you have other problems with the Config:Dashiki: namespace that I'm missing? Milimetric (WMF) (talk) 23:29, 1 February 2017 (UTC)

Fixing of messed references

Someone with a bot access on this wiki could fix those messed references left by MediaWiki message delivery, like this. How to fix? Example from fiwiki. It's easy with AWB. --Stryn (talk) 12:55, 15 January 2017 (UTC)

Got it!--Shriheeran (talk) 13:56, 15 January 2017 (UTC)

Adding {{reflist}} at the end of the message can fix these references. On eswiki exist these problem also. Imo a bot authorization could be opened to do this task. --Ks-M9 ^[disc.] 14:11, 17 January 2017 (UTC).

I've asked for help fixing this, currently underway. (all the details) I'm very sorry about the bother. Quiddity (WMF) (talk) 04:22, 10 February 2017 (UTC)