Wikimedia Forum/Archives/2014-01

Add links
From Meta, a Wikimedia project coordination wiki

Wikivoyage is down?

I'm getting just "[7b940ffc] 2014-01-02 18:56:15: Fatal exception of type MWException" on all languages of Wikivoyage. Other WMF projects appear to be unaffected. K7L (talk) 18:57, 2 January 2014 (UTC)

All Wikivoyage projects, Wikidata and Wikimedia Commons have been down since around 17:45 (UTC). Wikimedia Foundation operations team is aware of the problem and actively pursuing a fix; please be a little patient :-) odder (talk) 18:59, 2 January 2014 (UTC)
The sites seem to be back again, after a 1h 45 minutes-long outage. There might be some delays and general wonkiness for a while, so please bear with us. odder (talk) 19:39, 2 January 2014 (UTC)

Automatic linking between wikis?

Hi!

The page http://en.wiktionary.org/wiki/scythe has a link to http://en.wikipedia.org/wiki/Scythe , but not vice versa. I guess this links are inserted manually, so I suggest automating it.

Regards, David

Hi, this will be automated in the future when Wikidata enables its client on Wiktionary. John F. Lewis (talk) 20:21, 2 January 2014 (UTC)
(Edit conflict.) Are you sure that Wikidata will do that automatically without asking for local community input first? I mean, interproject links are something completely new for most of the WMF public wikis. Vogone talk 20:25, 2 January 2014 (UTC)
I'm not sure they will, see the RfC and bug I linked. But John Lewis seems to think so, and I assume he knows better than I do. PiRSquared17 (talk) 20:26, 2 January 2014 (UTC)
What happens now for some projects is linking between the different language versions of the projects. What is not happening yet is linking between different projects. It is possible technically but I want at least some rough consensus first before we enable this also for project-to project links. I very much want to see this happen though. --Lydia Pintscher (WMDE) (talk) 20:32, 2 January 2014 (UTC)
(Edit conflict.) It's not automatic yet, it uses wikt:template:wikipedia. See also Interproject_link, Requests for comment/Interproject links interface, bugzilla:708. Possibly also related: d:Wikidata:Wiktionary, Wiktionary future. It will be automatic when Wikidata is enabled on Wiktionary. PiRSquared17 (talk) 20:23, 2 January 2014 (UTC)

Arabic dialects and Wikimedia projects

I wonder if anyone has determined which Arabic dialects have a sufficient standardized writing for establishing Wikimedia projects. We have Egyptian Arabic Wikipedia and the Moroccan, Algerian, Tunisian, Libyan, and both the North and South Levantine dialects in the Wikipedia incubator as well as an Egyptian Arabic Wiktionary in the proposal stage, but AFAIK that is all.

  • AAO: Algerian Saharan Arabic
  • ABH: Tajiki Arabic
  • ABV: Bahrani Arabic
  • ACM: Mesopotamian Arabic
  • ACQ: Tai'zzi-Adeni Arabic
  • ACW: Hijazi Arabic
  • ACX: Omani Arabic
  • ACY: Cypriot Arabic
  • ADF: Dhofari Arabic
  • AEC: Sa'idi Arabic
  • AFB: Gulf Arabic
  • AJP: South Levantine Arabic - Wikipedia Incubator
  • APC: North Levantine Arabic - Wikipedia Incubator
  • APD: Sudanese Arabic
  • ARQ: Algerian Arabic - Wikipedia Incubator
  • ARS: Najdi Arabic
  • ARY: Moroccan Arabic - Wikipedia Incubator
  • ARZ: Egyptian Arabic - Wikipedia, Wiktionary proposal
  • AUZ: Uzbeki Arabic
  • AVL: Bedawi Arabic
  • AYN: Sanaani Arabic
  • AYP: North Mesopotamian Arabic
  • AYH: Hadhrami Arabic
  • AYL: Libyan Arabic -Wikipedia Incubator
  • MEY: Hassaniya Arabic
  • PGA: Juba Arabic
  • SHU: Chadic Arabic
  • SSH: Shihhi Arabic
  • TUN: Tunisian Arabic - Wikipedia Incubator

---Dead dialects:

  • SQR: Siculo-Arabic
  • XAA: Andalusian Arabic

WhisperToMe (talk) 22:04, 7 January 2014 (UTC)

Dead dialects will not be included. Living ones might be created should a significant number of people request it, as long as they have an ISO code and an active Incubator project, but it is also up to LangCom to decide whether it is appropriate. PiRSquared17 (talk) 22:16, 7 January 2014 (UTC)

HTTPS for logged in users on Wednesday August 21st

As a comment (not sure if anyone already mentioned it in historic discussions) this seemed to break many imported javascript links if they relied specifically on http. Had no idea what caused all of my js to disappear, until it became more flexible... -- Mentifisto 06:01, 15 January 2014 (UTC)

wikt.org domain

Hello again. I don't know if this is the right place to put this, but I've just been notified that the wikt.org domain will be available soon if anyone wants to take it, and probably the Wikimedia Foundation will be interested. It seems to have been previously used for some experiments and was intended as a placeholder for a redirect to Wiktionary. TeleComNasSprVen (talk) 23:27, 13 January 2014 (UTC)

Hi TeleComNasSprVen! Thank you for letting us know. We'll look into it. Mpaulson (WMF) (talk) 01:34, 14 January 2014 (UTC)
Idea 1: It could be a candidate for the mobile version of Wiktionnary: instead of "language-code.m.wiktionary.org", we could have "language-code.wikt.org" as a useful alias, it would avoid using unsafe external URL shorteners to link to a word definition.
So that we could directly post the URL: "http(s)://en.wikt.org/word", instead of "http(s)://en.m.wiktionary.org/wiki/word" or "http(s)://tinyurl.com/random-code"
This short domain would be a safe HTTP redirector to the Mobile version or the standard web version (after parsing the device capabilities from HTTP headers). verdy_p (talk) 21:11, 14 January 2014 (UTC)
Idea 2: We could even post only the URL "http(s)://wikt.org/word" and this web site would look for the given word in all editions of Wiktionnary and would propose a page listing links to the various language editions that have an article for "word". It could as well propose links to Wikipedia articles, or categories on Commons (it would also use Wikidata), with some samples for relevant images.
  • If the user is logged on, he could also tune the list of language projects to list in priority.
  • If only one link is found on a single Wikimedia project, it would link directly to it (if the user opts in for this preference).
  • The page rendered by "wikt.org" would be in fact a cross-wiki Wikimedia search engine, proposing related contents, based on user preferences and statistics for the most relevant links (these statistics being maintained when following one of the proposed links, an statistics being maintained language by language, and then ordering languages using user languages preferences (it could also use the language preferences sent by the browser), much like when using Google search on any word (except that here, we could get only pages from Wikimedia projects, and NO ads). When the search engine finds geolocalizd articles, it could also display a free browsable map of the area, with pointers mapped on it for the listed articles.
  • It could also link to other non-wiki sites of Wikimedia (for example blogs, IRC channels).
  • It could eventually list contents from partner wikis approved by the Wikimedia Foundation and the community (including the sites of Wikimedia chapters), and relevant Google groups, Facebook pages, Twitter pages, OpenStreetmap wiki and projects, RSS feeds, newsletter feeds, as long as they are built and promoted by active Wikimedia affiliates (really part of the "Wikimedia movement").
Under this concept, "WikT.org" would not mean just "Wiktionnary" but "Wikimedia Tiny" (or "Wikimedia Tee").
  • If we want to assign an interwiki code to this site, it should be"t:" and not "wikt:" (alrady mapped to Wiktionary).
  • If one wants to restrict searches to Wikitionary only or to a specific project, and/or to a specific language, we could still use "http(s)://wikt.org/interwiki-code:language-code:word" (using the existing methods for creating wikilinks), or probably "http(s)://language-code.wikt.org/interwiki-code:word" (to set the prefered language of the UI used on Wikt.org and define language priority in searches). However in this case, the Wikt.org site would link to the search page of that interwiki project (if there's an interwiki-code: in the page path) if possible, and use its local preferences. In that mode, wikt.org would not display anything but would be an HTTP redirect to that project, if possible (not always possible for all supported interwiki elements, hosted on sites without a local search engine).
  • To search accross wikis using Wikt.org, use the syntax: [[t:word]].
The Wikt.org site would have no contents by itself, all contents coming from supported projects. If it needs to render links to discussions about it, or to statitics/usage report or policies, or to pages needed to manage its own translations and localisations, it could link to a project page here on Meta. However it will have its own local user preferences (but no user pages, hosted on projects).
  • The Wikt.org site would be fully multilingual (according to user preferences) and would be integrated with SUL (Single User Login). It would also display the central notice banners.
  • Users registered on Wikt.org (with SUL) could setup the interwiki link to his prefered user page on a supported project, so we could link to the prefered page of a SUL user with "http(s)://wikt.org/user:username" and to his prefered talk page with "http(s)://wikt.org/talk/username" (without having to search).
  • These user pages and talk pages would not necessarily be the "home wiki" of that user used by SUL: it could be a page to any other supported project, including outside those operated under SUL (for example a SUL user could link his user page and his page to a page on the Foundation wiki, or to a supported blog site), as long as it has a valid interwiki code, or even to his email (kept private, where Wikt.org would host the form to send mail to him, directly via "http(s)://wikt.org/talk/username").
  • All user preferences stored in Wikt.org (which should be minimal: navigation preferences, language preferences, relevance statistics, usage statistics, user name, and the two interwiki links for his user page and talk page) would be private, links to other projects going to pages managed by their own applicable policies. For this reason, we could not create a user account on it (Wikt.org should never be the "home wiki" for the SUL user name, and only users with a SUL account would benefit from the "user/" and "talk/" namespaces). However Wikt.org could suggest a list of projects where a user can register a new account, and link to it.
  • Because this wikt.org site has no content (it won't be a wiki but an automated search engine and redirector), it will not be modiable by bots. However it may be indexable by external search engines, so a user preference on wikt should include an opt-out option for indexing crawlers.
  • So by default "http(s)://wikt.org/talk/*" and "http(s)://wikt.org/talk/*" would have the "robots: noindex,nofollow" setting.
  • If the user opts in for being indexed by the internal crawler and by external crawlers, he will also be reachable by "http(s)://wikt.org/talk:username" and "http(s)://wikt.org/talk:username", which will look for that user name in SUL (otherwise these links will not resolve directly and won't display the user in the search results of the wikt.org search engine (to reach that user directly, use the slash, not the colon).
    • To create a direct interwiki link on Wikimedia Wikis to a given user, use the syntax [[t:user/username]] or [[t:talk/username]] (with the slash); no search will be performed (if the user name is not found it wll just say that this SUL user name does not exist and it will not propose any other user). These links will go to the user's preferred pages defined in Wikit.org preferences.
    • To create an interwiki link on Wikimedia Wikis to search for users that have the opt-in option, use the syntax [[t:user:username]] or [[t:talk:username]] (with the colon) : the site will perform a search and will attempt to locate that user and propose relevant links (possibly finding other opt-in usernames with a different but similar orthography). These links will go to the user's preferred pages defined in Wikit.org preferences.
  • The wikilink to current user's preferences on Wikt.org will be [[t:Special/Preferences]] or the url "http(s)://wikt.org/Special/Preferences". It won't be possible to link to the preferences of any other user except the currently connected user. (note the use of the slash, not the colon which falls in the public search engine, in the indexed and crawlable space; colons in paths of Wikt.org are not namespaces).
    • Other special pages (not for performing searches) needed for the site itself (including admin pages or status pages) many be found in "http(s)://wikt.org/Special/*";
    • Only the following paths will go outside the default search engine: "//wikt.org/special/*" or "//wikt.org/Special/*", "//wikt.org/user/*" or "//wikt.org/User/*", "//wikt.org/talk/*" or "//wikt.org/Talk/*".
    • If one needs to search for items in queries starting by these prefixes, the slashes may be URL-encoded (for all other prefixes, the URL-encoding remains optional, even if t's recommanded and will be used by the online search form displayed on the site home page "//wikt.org/" which could be used as a default search engine).
    • If you don't like this scheme of prefixes needed to exclude searches in URLs, use only the prefix "?" to recognize query strings only in the home page, including for direct links to user pages ([[t:?user=username]] going to "//wikt.org/?user=username"), user talk pages ([[t:?talk=username]] going to "//wikt.org/?talk=username") and special pages ([[t:?special=preferences]] going to "//wikt.org/?special=preferences").
    • Query strings won't resolve as query parameters in the default search space (this means that you could use question marks in the main search space, so that it will support questions in natural language, or will allow to look for titles containing a question mark, without having to URL-encode this question mark; however hash mark (used by anchors, and always after the query string) will still need to be URL encoded in URLs.
    • For example [[t:C#]] does not work in wikilinks, but [[t:C%23]] will work and will resolve to the URL "//wikt.org/C%23" to look for Wikimedia pages about "C#".
verdy_p (talk) 21:23, 14 January 2014 (UTC)

New project proposal: Wikiabstracts

There are lots of books and articles at your desk, that you need for writing an essay. Finally you read all the articles and worte your paper, when in the last moment you find another paper you did not find earlier. You know this problem? Wikiabstracts wants to challenge it: A database of abstracts and a bibliography with all relevant texts for your subject. If your interested and think the idea could work - join the project!

I've just created a related proposal: Wikisummary! See this heading just below:

Sections without an identifiable timestamp aren't auto-archived. --MZMcBride (talk) 04:50, 16 January 2014 (UTC)

New Project Proposal: Wikisummary

How often have you read dozens of pages of an academic article or book, only to feel that they could have summarised it in two or three? Wikisummary aims to solve this by summarising academic books and articles, and linking to reviews of them. See the [project proposal here]

Sections without an identifiable timestamp aren't auto-archived. --MZMcBride (talk) 04:50, 16 January 2014 (UTC)

New project proposal: Concisia

Just added a new project proposal: Concisia - kind of a mixture of Wikipedia, Wikidata, Twitter and user ratings. It's quite different from other wiki projects but I hope you like it.

Sections without an identifiable timestamp aren't auto-archived. --MZMcBride (talk) 04:50, 16 January 2014 (UTC)

New project proposal might be a project having a close number of pages that Wikipedia may have!

Wikiecnomics which just proposed might need a lot of support, but it might be a very good project if it were to go up and running. By its nature it would require millions of pages. Also, it might popularize Wikimedia. But, this can only be done with a lot of support. Click here to go to proposal of wikiecnomics.Doorknob 747.

Sections without an identifiable timestamp aren't auto-archived. --MZMcBride (talk) 04:50, 16 January 2014 (UTC)

Call for comments on draft trademark policy

Hi all,

The Wikimedia legal team invites you to participate in the development of the new Wikimedia trademark policy.

The current trademark policy was introduced in 2009 to protect the Wikimedia marks. We are now updating this policy to better balance permissive use of the marks with the legal requirements for preserving them for the community. The new draft trademark policy is ready for your review here, and we encourage you to discuss it here.

We would appreciate if someone would translate this message into your language so more members of your community can contribute to the conversation.

Thanks,
Yana & Geoff

Sections without an identifiable timestamp aren't auto-archived. --MZMcBride (talk) 04:50, 16 January 2014 (UTC)

WikiMiniAtlas idea

I just learned that the WikiMiniAtlas maps are apparently OK to use on Wikipedia (i.e. public domain). Would there be any support for an extension to display WikiMiniAtlas maps inline for articles on locations? It would certainly make it easier to illustrate locations. I'm imagining something like <map long=1.234 lat=5.678/>, which would display a map of the given location. This idea was also suggested at the Teahouse on enwiki. --Jakob (talk) 20:36, 14 January 2014 (UTC)

This would especially be nice on Wikivoyage, where they currently use a script to get maps from OpenStreetMap: voy:Template:OpenStreetMap. See also WikiMiniAtlas. PiRSquared17 (talk) 00:45, 17 January 2014 (UTC)
wikiMiniAtlas is also based off OpenStreetMap (plus w:VMAP0 from NGIA gummint spysats), but I heard that WMF has a local server/cluster which caches the OSM-data, for speed/load reasons. I *believe* generating a flat 'live' inline image ... as opposed to the usual WikiMiniAtlas popup-ajax-based-floating-iframe ... *is* actually possible today (I was the teahouse person, by coincidence). See the infobox of w:Statue of Liberty which I believe is generating the map therein, straight from the lat-lon cords, not from a pre-uploaded SVG. p.s. WikiMiniAtlas is awesome. More people should know about it. Dschen ought be proud. 74.192.84.101 23:45, 23 January 2014 (UTC)

On-wiki chat

We have all got used to the model of communication of posting on user talk pages and in other venues. That is somewhat similar to sending e-mails on the internet. I was wondering, what the admins and experienced editors think about adding the ability to chat? That would allow interactive communication that could be used in dispute solving, or in collaborative editing for example. The editors could decide at any time if they would like to avail themselves to chat.

The logs of the chats would be either saved in one place, and links to the logs would be posted on the editors' talk pages; or the logs could be posted on the talk pages, perhaps in collapsed form.

It should be implemented as a feature of a real-time chat on all wikis.Tdfdc (talk) 16:51, 8 January 2014 (UTC)

The people on #wikimedia-tech think it's inevitable, that at some point it will be implemented. There is currently: https://www.mediawiki.org/wiki/Future/Real-time_collaboration that outlines it. I would suggest to start the implementation.Tdfdc (talk) 17:39, 8 January 2014 (UTC)
I personally don't think it'll be that big an improvement over the current system, and we do have IRC for fast communication. Other wiki softwares outside of Wikimedia might have real-time chat features that we could emulate if we wished though. (Plus IRC has a tendency to 'degrade' into off-topic or silly conversation, because its fast and freeform nature allows for much greater leeway in normal conversation that otherwise is restricted when talking on-wiki about on-topic wiki issues. I'd hate to replace IRC with that restrictive form of communication.) TeleComNasSprVen (talk) 18:53, 8 January 2014 (UTC)
IRC is an outdated real-time communication approach, and it is optimized for group chats. Which wiki software outside of Wikimedia are you referring to please? Well, the idea is not to replace IRC, but to add an additional, more social-oriented and more modernized way of real-time communication. Tdfdc (talk) 19:36, 8 January 2014 (UTC)
IRC is actually the ideal software for group chats. That is where it shines. It also isn't really outdated as you implied in this and another discussion. -Djsasso (talk) 13:54, 9 January 2014 (UTC)
That is what I have said, IRC is optimized towards group chats. IRC is a bit outdated in my opinion. I wouldn't say either, that it is really outdated. I base the opinion on the number of users who are currently using IRC comparing to the number of users who are using Facebook, Skype and other platforms that got real-time chat implementations. (Ie, in the past more users used IRC on a percentage basis (comparing to other modes of real-time communication via text.))Tdfdc (talk) 16:47, 9 January 2014 (UTC)
Please take a look at https://www.mediawiki.org/wiki/Flow. What is your opinion about it?Tdfdc (talk) 16:55, 9 January 2014 (UTC)
I guess flow will come sooner or later anyway, regardless whether we like it or not. Though, this extension is still under development and maybe the devs will do good work and it becomes indeed useful someday. Vogone talk 17:53, 9 January 2014 (UTC)
The more insightful feedback/suggestions/requests that are left - ideally at mw:Talk:Flow or en:WT:Flow (to avoid tangenting this thread, and to avoid fragmenting the discussions) - the greater the possibility that Flow will turn into something that we all like and want, many many months from now. It needs our help/guidance/input/testing to do so, during that time. </end of request> Quiddity (WMF) (talk) 22:16, 11 January 2014 (UTC)
Yes, that's clear. :) Vogone talk 15:52, 12 January 2014 (UTC)
I will admit that IRC's learning curve is a bit steep, but no other chat system effectively scales to the level of hundreds of users at once and uses so little bandwidth, and it's far from outdated (less people use it, true, but it's far from dead). For one-on-one discussion, IRC has private messaging as well.--Jasper Deng (talk) 01:45, 10 January 2014 (UTC)
Flow is shit. --MF-W 08:07, 10 January 2014 (UTC)
To reiterate again, there is no proposition of removing IRC. The proposition is to develop on-wiki chat. It should be used for friendly chats (mostly one on one), real-time collaborative editing and real-time dispute resolution. Proper guidelines of the chat usage towards real-time dispute resolution would have to be developed.Tdfdc (talk) 13:56, 10 January 2014 (UTC)
As I mentioned several times on en.wp (to the point that people stopped listening to me), we should organize resistance against FLOW until it is too late.--Ymblanter (talk) 13:33, 11 January 2014 (UTC)
I assume that could be done elsewhere, as this thread is about the proposal of on-wiki chat. I'm personally is neutral in this stage regarding FLOW.Tdfdc (talk) 15:03, 11 January 2014 (UTC)

In my opinion such a chat is redundant to IRC (hence my comments about it above), and could give the impression that a project is a social networking site.--Jasper Deng (talk) 05:20, 12 January 2014 (UTC)

I welcome your opinion Jasper. However I would like to mention, that I don't see any problem for Wikipedia becoming more of a 'social site'. That is because we are a community of people united around one idea. Thank you. Please give this proposal another thought.Tdfdc (talk) 08:26, 12 January 2014 (UTC)
One of the things Wikipedia tries hard to prevent is people viewing and using this site as a social site. So yes, anything that makes us look more like one is a problem. -Djsasso (talk) 12:47, 16 January 2014 (UTC)
We're an educational project not runscape or AIM. There's IRC if you want, which is off-wiki and rightfully so. Any implementation of on-wiki chat is outside the purpose of our projects and would detrimental to them, in the manpower required to police it, in the on-wiki sanctions required for violation of policy on said chat, in having to monitor the logs and suppress issues there, and all that stuff. All of this for a tool that offers no benefits relevant to our purpose here. If one wants to socialize, they can go to Wikimania, a club or whatever. Snowolf How can I help? 20:56, 26 January 2014 (UTC)
There are a number of bugs (open and closed) about on-wiki chat in Bugzilla, if you poke around. --MZMcBride (talk) 03:44, 13 January 2014 (UTC)

Oppose Oppose, for 2 reasons. Tdfdc Djsasso MF-W Quiddity (WMF)

  1. Talk pages are for collaboration, not socializing.
  2. When there's a need to be interactive, there is IRC, and it appears to be more healthy to not log such chat publicly and keep it separate from the wiki.
  3. FYI Flow thread depth is limited (which is a regression; bug priority "low"), it is also using twitter-like user mentions which are not hidden. Not addressing these two bugs is an excellent way to turn it into on-wiki chat.
--Gryllida (talk) 12:56, 16 January 2014 (UTC)
  • Support Support Tdfdc's idea of on-wiki chat, permanently iframe'd in the lefthand-sidebar, as a supplement (not replacement!) for old-school talkpages/IRC/etc, plus as a WP:FLOW-killer. In particular, I see the chat-window as a place to receive brief 99-byte-or-less notifications about things that appear on one's watchlist, user-talkpage, and similar. If you make an edit, and somebody reverts you the following day, you get a chat-alert-message giving their edit-summary, plus a link that allows you to click-for-diff. If you make a talkpage edit, and somebody replies to you the next day, you see the first few words of their reply as a chat-alert. Third example: if you want to 'follow' a person you are collaborating with (or a possible w:visigoth you may need to revert), the chat-window makes that easy, and makes communication faster than the orange bar of doom. You can also 'follow' an article, or an article-talkpage, or a user-talkpage... aka Watchlists For Dummies™.
  The key point is that on-wiki chat will be attractive to new folks, the target-demographic of WP:FLOW (and VizEd), as well as potentially being convenient to us old-timers. Anons cannot have watchlists, echo-notifications, the thanks-feature, and similar perks. On-wiki chat gives anons most of what those things offer, *without* the anon needing to learn about colons on talkpages, signing their posts, watchlist-configuration, echo-toolbars, or all that jazz. Therefore, implementing on-wiki chat CAN be justified, purely in terms of declining editor-count. http://reportcard.wmflabs.org is all the evidence we need, though http://stats.wikimedia.org/EN/SummaryEN.htm is even more terrifying helpful.
  However, the ULTERIOR motive here, is that on-wiki chat in the sidebar would be pretty easy to implement, and would eliminate 90% of the reason for WP:FLOW... and as MF-Warburg might put it, w:WP:FLOW wp:blows. If we want to nip that monstrosity in the bud, as Ymblanter suggests, then we best plan ahead, by having an alternative solution to offer. We need something that keeps beginners from having to remember to sign their posts, keeps beginners from having to learn not to split talkpage comments, and keeps beginners from needing to edit in plaintext where they supply their own colons or asterisks for indentation-markup. On-wiki chat in a permanent left-sidebar iframe *is* the alternative which trumps WP:FLOW. It is a technology that most folks are familiar with already, from skype/msn/yahooMsgr/jabber... and yes, even old crufty IRC, my top choice by far.  :-)
  TLDR. We can keep old-school IRC. We can keep old-school talkpages/watchlists/etc. But if we want to make sure WP:FLOW is safely superfluous, I submit that we need on-wiki chat, up and running yesterday. We can control w:WP:NOTFACEBOOK behavior in the on-wiki-chat-window, just like we do on talkpages: w:banhammer. Hope this helps, and thanks for improving wikipedia, folks. 74.192.84.101 23:15, 23 January 2014 (UTC)
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum/Archives/2014-01&oldid=19957956"