Community Wishlist Survey 2019/Miscellaneous

17 proposals, 251 contributors, 455 support votes
The survey has closed. Thanks for your participation :)

New special page "Outgoing links"

  • Problem: The special page "What links here" shows the recent edits for all pages linked from a page. However, there's no way to see additional information about those linked pages, especially in the case of categories, WikiProject watchlists and media galleries. I think there should be a sister special page "Outgoing links" that shows a table with all the outgoing links and related information.
  • Who would benefit: Editors and experienced readers.
  • Proposed solution: The table of outgoing links should have sortable columns with the pages' name, first edit date, last edit date, file size, number of editions, and additional buttons to view "History", "Page information" and "Outgoing links".
  • More comments:
  • Phabricator tickets:


@NaBUru38: The 'Problem' section currently does not explain which underlying problem would get solved by such a special page, and why you need to see a list of outgoing links. Could you please clarify? Thanks! --AKlapper (WMF) (talk) 14:59, 31 October 2018 (UTC)

There is an existing API module and database table that does exactly this. MER-C (talk) 15:24, 31 October 2018 (UTC)
Ok, so we need a proper user interface for the existing API. To be usable, the information must appear in a sortable table, with web links as described in the proposal. --NaBUru38 (talk) 19:04, 6 November 2018 (UTC)
@AKlapper (WMF), a problem that might be solved by the proposed feature is to find a picture in Commons to match a Wikipedia article. This image is not in use, but it has in the description links to several Wikipedia articles – 'Outgoing links' on Wikipedia could link to the information given on Commons, information that would otherwise be easyily missed. Jürgen Eissink (talk) 19:13, 7 November 2018 (UTC).
  • There's also a script (1) which do this. ‐‐1997kB (talk) 16:39, 17 November 2018 (UTC)


Automatic display authority control template

  • Problem: There are a lot of articles at the bottom that have a authority control template, and a large number of articles have not yet added this template. If we can automatically display authority control template instead of manually adding it one by one, this aspect of maintenance will be greatly reduced.
  • Who would benefit: Wikipedia editors and readers
  • Proposed solution: Add a new message at the bottom of the page (Displayed above the category), authority control template or other content can be added here.
  • More comments:
  • Phabricator tickets:
  • Proposer: Shizhao (talk) 08:28, 5 November 2018 (UTC)


  • How many people do use Authority Control? My sense is that this is a very niche thing. Jo-Jo Eumerus (talk, contributions) 10:19, 17 November 2018 (UTC)

There should be universal footer on every page, so not only Authority control but also Commonscat or some tracking categories should be here. JAn Dudík (talk) 09:06, 22 November 2018 (UTC)


Separate templates in "What links here"

  • Problem: "What links here" does not distinguish incoming links made from templates (particularly navboxes) from direct links made in article text. That makes it hard to fix incoming links after a page move, particularly when creating a disambiguation page on the previous title, or deleting a page. The problem is aggravated by the database lag after updating template links (even if you retarget the offending template link, "what links here" will still display the transcluding page as being linked).
  • Who would benefit: All editors, particularly page movers, dab page resolvers, and admins deleting pages.
  • Proposed solution: 1) (Better) Indent links made from templates below the template listing, in the same manner as links to redirects 2) (Alternatively) Make sure that "What links here" is updated immediately after the offending template is edited, rather than with a lag (that takes between several minutes and a couple of hours, in my experience).
  • More comments:
  • Phabricator tickets: phab:T5241 (most apt), phab:T14396 (similar 2016 wishlist idea), phab:T3392 (one of many duplicates)
  • Proposer: No such user (talk) 09:45, 5 November 2018 (UTC)


  • See also: Stop ifexist checks from appearing in Special:WhatLinksHereTheDJ (talkcontribs) 10:29, 5 November 2018 (UTC)
  • It's not always that simple. If a link is part of the text passed into the template as a parameter, is that link from the template or not? What if the template generates the link by combining passed-in parameters?

    I note the proposed solution option #2 is likely impossible. When thousands of pages use a template, it's always going to take time to go through and reparse them all. Anomie (talk) 16:47, 5 November 2018 (UTC)


Create a dissemination platform for Wikinews

  • Problem: People don’t usually go to Wikinews to search for its content. While reading Wikipedia is an active interaction, as we look for the content, reading news is usually a passive interaction on internet. We log on our platforms waiting for them to show us the news. Good or bad, that is a reality.
  • Who would benefit: Wikinews community
  • Proposed solution: Create a dissemination platform to reach readers on their usual place of interests, social networks. That platform would contain new articles of Wikinews and readers will be shown that. Whether it’s a blog, an App, a social network account, or all of them I am not sure, but Wikinews can’t beat all other medias that already are where the readers are.
  • More comments:
  • Phabricator tickets:
  • Proposer: —Teles «Talk to me ˱C L @ S˲» 22:08, 6 November 2018 (UTC)


  • Thanks for your proposal, Teles. It sounds like you are asking for giving Wikinews articles more publicity using Wikimedia's social media accounts and official blog. Does that sound correct? -- NKohli (WMF) (talk) 21:49, 7 November 2018 (UTC)
@NKohli (WMF): It would have to be something specific, like an app or a social media account for that purpose. That would have to be well integrated with on-wiki interface though and that’s the hard one. I know it may not perfectly fit with the purpose of Community Survey but I just wanted to provide food for thoughts for probably the only thing that could save Wikinews.—Teles «Talk to me ˱C L @ S˲» 18:40, 10 November 2018 (UTC)
  • For your reference 1) Wikipedia home page features 'news section' with events which are over 3 days old whose 5Ws are painfully difficult to identify. Overcoming this problem requires a high degree of cooperation and learning which hinders the development of some of language editions of the Wikinews project. However Russian, Spanish, German Wikinews are productive and prolific and the comments below about sunsettings things are uncalled for in my opinion. 2) I don't think this proposal is about official blog of Wikimedia NKohli (WMF), I think it is about outreach to attract more people so if you know of any outreach experts or people who can do organizing workshops via online means etc it would be great. I am in the process of transforming how newcomers receive feedback on their first edits, however this is a slow process and as of now I am supported in my endeavours by only a small group. Having an expert from Wikimedia movement who could consult me on this would be great. (WM-AU are unsupportive, WM-RU is another language I speak and I have not yet queried them about this; this is on my todo.) --Gryllida 07:46, 23 November 2018 (UTC)


  •   Support Liuxinyu970226 (talk) 08:43, 17 November 2018 (UTC)
  •   Strong oppose I can support a proposal that chooses to terminate a comatose project.Winged Blades of Godric (talk) 08:11, 18 November 2018 (UTC)
  •   Support NMaia (talk) 10:38, 18 November 2018 (UTC)
  •   Support Benjamin (talk) 10:30, 19 November 2018 (UTC)
  •   Support Novak Watchmen (talk) 01:35, 21 November 2018 (UTC)
  •   Support Vulphere 04:50, 21 November 2018 (UTC)
  •   Oppose Sadly, I believe that Wikinews has not succeeded as a project, and therefore promoting it is not a good idea. The project should probably be shut down, but the Wikimedia movement is notably bad at making the hard decisions when it comes to sunsetting things. --Deskana (talk) 11:56, 22 November 2018 (UTC)
  •   Support interesting idea, poorly discussed at this point to be fair, I would be glad to discuss it in greater detail on-wiki Gryllida 07:36, 23 November 2018 (UTC)
  •   Support Sahaquiel9102 (talk) 17:24, 23 November 2018 (UTC)
  •   Oppose Victorgibby 03:02, 25 November 2018 (UTC) Wiki Tribune tarde o temprano va reemplazar a Wikinoticias y conserva el mismo formato MediaWiki
  •   Support — AfroThundr (u · t · c) 03:12, 26 November 2018 (UTC)
  •   Oppose PMG (talk) 17:07, 26 November 2018 (UTC)

Recover text of old revisions for the Massachusetts article

  • Problem: The deletion and undeletion events from 2005 were terrible events that have caused lots of old revisions from January 2005 and earlier for the Massachusetts article to have lost their text. This is a catastrophe that had never been fixed for over 13 years.
  • Who would benefit: Everyone
  • Proposed solution: Download some database dump from February 2005 and extract the Massachusetts article edits. Then create a temporary page (perhaps a talk subpage) containing the fact that the text had been lost, and use Special:MergeHistory to merge all of the article edits from 7 January 2005 and earlier to the temporary page's history. Next, delete the temporary page and restore the latest creation as well as the few earlier non-problematic revisions. After that, merge the earlier non-problematic revisions back to the Massachusetts article's history. Then, import all the old Massachusetts article edits from the database dump. And optionally, create a maintenance script that attempts to copy the text of the imported revisions to the corresponding deleted revisions for the temporary page, and rev_len and rev_sha1 to ar_len and ar_sha1 respectively. Unfortunately, this is more complicated due to the fact that MCR means that we are not going to have rev_text_id and ar_text_id fields anymore. Finally, re-delete the temporary page (optionally also).
  • More comments:



  •   Support Liuxinyu970226 (talk) 08:43, 17 November 2018 (UTC)
  •   Support Ankry (talk) 04:15, 18 November 2018 (UTC)
  •   Support Sebastian Wallroth (talk) 13:11, 18 November 2018 (UTC)
  •   Support Why hasn't this been done before? Benjamin (talk) 10:32, 19 November 2018 (UTC)
  •   Support Novak Watchmen (talk) 01:34, 21 November 2018 (UTC)
  •   Support Terra  (talk) 02:12, 21 November 2018 (UTC)
  •   Support Vulphere 04:44, 21 November 2018 (UTC)
  •   Support Lotje (talk) 06:47, 25 November 2018 (UTC)
  •   Support PMG (talk) 17:07, 26 November 2018 (UTC)

Wanted (by articles) pages

  • Problem: Difficult to easily see what pages are really missing on a site. Current Special:WantedPages such as voy:Special:WantedPages shows a list that are mainly red links on talk and project pages not main space article pages. Takes a lot of clicking to see really needed pages.
  • Who would benefit: Article authors looking for ideas for pages to create. Clean-up contributors looking for problem links.
  • Proposed solution: Create a page similar to Special:WantedPages but the number of redlinks shown to only be from mainspace pages and not talk and admin pages. One alternative idea is to make the existing page a table with a column showing number of redlinks from each namespace type (mainspace, talk of article, user page, template, ....) and make it possible to reorder the table based on descending number of each source page type.
  • More comments:
  • Phabricator tickets: T208935
  • Proposer: Traveler100 (talk) 18:35, 4 November 2018 (UTC)


@Traveler100: Could it make more sense to allow filtering that list by namespace, instead of creating yet another special page? --AKlapper (WMF) (talk) 12:29, 5 November 2018 (UTC)

A namespace filter on the existing page would be a good idea but remember it is not filtering the pages in the list but filtering the pages that link to the pages in the list and the number of links result needs to reflect the source red-links count not the target count. Not sure if that can be handled real-time with a filter. --Traveler100 (talk) 12:39, 5 November 2018 (UTC)
Both filters would be nice. --NaBUru38 (talk) 20:48, 7 November 2018 (UTC)
A real problem, this is ridiculously packed with lots of non mainspace items, echo the opinion that both filters will be nice to have. --Cohaf (talk) 21:10, 7 November 2018 (UTC)
I'm afraid this suggestion only makes sense for editors but not for readers. ---Super Wang on zhwiki (Share your opinions) 23:53, 16 November 2018 (UTC)
I do not see that that matters, and it is clear from Who would benefit. PJTraill (talk) 23:55, 26 November 2018 (UTC)


Display more information about users on the user page

Example implementation of this idea by the userinfo.js user script
  • Problem: Right now, it takes a lot of clicking around to find out basic information about a user—how long they've been editing, how many edits they've made, what user rights they have, whether or not they're an admin, etc. There are a some external tools to help with this such as XTools, but it would be better if this information was readily available just from going to their user page. A popular user script, userinfo.js, does a nice job of this, but requires knowing about the script and installing it.
  • Who would benefit: Anyone who interacts with editors (admins, other editors)
  • Proposed solution: Convert most of the functionality from userinfo.js into an extension so that you can see basic user info directly on the user page.
  • More comments:


Isn't this provided by Wikipedia:Tools/Navigation popups ? Cabayi (talk) 08:06, 30 October 2018 (UTC)
Oh, I didn't know that. Regardless it would be good to have this functionality baked into MediaWiki rather than having to use wiki-specific gadgets or user scripts. Kaldari (talk) 16:54, 30 October 2018 (UTC)

I think it needs to be opt-in for my account, I don't want my privileges to be seen by others - I don't think it matters in most discussions.

I would think the number of edits does not matter in any circumstances as it may result in harsher attitude towards people who have not made any edits and

may result in people aiming to increase their edit count just to seem more important. Gryllida 22:39, 30 October 2018 (UTC)

Account privileges are already visible to people using this script; the proposal is only asking for it to be made into a MediaWiki feature. Enterprisey (talk) 04:58, 31 October 2018 (UTC)
I am not sure that it's a good idea to broadcast far and wide how many hats and edits - or how few - someone has. People routinely attach a lot more significance to these numbers than they deserve. Jo-Jo Eumerus (talk, contributions) 09:32, 2 November 2018 (UTC)

Just saying, because this does not seem to have been mentioned or considered yet: The mobile design of Wikipedia already includes exactly this information for every diff view. See Special:MobileDiff/18448513 for example; you may need to scroll down to see it ToBeFree (talk) 19:19, 3 November 2018 (UTC)

I guess when a user visits their user page they could be presented with a wizard that allows them to show/hide

  • their edit count
  • their contributions ({{Special:Contributions/Gryllida}})   Done
    • pages they created
  • their privileges
  • their participation at sister projects

the first step would be availability of this information as templates which they can put at their user page by hand. I think that's something Wikimedia Community Team could implement...?

I oppose implementing this hardcoded like the mobile diff mentioned above. --Gryllida 07:32, 23 November 2018 (UTC)

Normally I favour transparency, but in this case, transparency could facilitate abuse. Having editor info prominently served up front-and-centre is the wrong emphasis, and potentially increases ease of wikihounding/harassment by new editors who may not yet have acclimated to WP conventions (e.g. edit reverts). I think new users should have to discover this functionality (e.g. via Wikipedia:Tools/Navigation popups, script etc) since in the process they will be exposed to more WP culture (in other words, I support the status quo, and I oppose hardcoding). The lack of opt-out is also a serious red-flag for me; if there was an opt-in I would be more inclined to support. ifny (talk) 03:08, 27 November 2018 (UTC)


  •   Support As this would make this information available for newcomers. This information is already easily available for all more experienced users. Braveheidi (talk) 01:43, 17 November 2018 (UTC)
  •   Support Liuxinyu970226 (talk) 08:35, 17 November 2018 (UTC)
  •   Support ديفيد عادل وهبة خليل 2 (talk) 11:25, 17 November 2018 (UTC)
  •   Support Like tears in rain (talk) 13:04, 17 November 2018 (UTC)
  •   Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:07, 17 November 2018 (UTC)
  •   Oppose Per the rationale given in the discussion section. Jo-Jo Eumerus (talk, contributions) 13:18, 17 November 2018 (UTC)
  •   Support Zoranzoki21 (talk) 14:42, 17 November 2018 (UTC)
  •   Support Jullan3 (talk) 15:29, 17 November 2018 (UTC)
  •   Support Vercelas (quæstiones?) 21:56, 17 November 2018 (UTC)
  •   Support Super Wang on zhwiki (Share your opinions) 03:21, 18 November 2018 (UTC)
  •   Oppose Per rationale of Jo-Jo Eumerus. AHeneen (talk) 06:16, 18 November 2018 (UTC)
  •   Support NMaia (talk) 10:38, 18 November 2018 (UTC)
  •   Support Timeshifter (talk) 14:55, 18 November 2018 (UTC)
  •   Oppose I would prefer this to either be an opt-in feature or completely abandoned. If someone truly needs to know this information it isn't difficult to find, and I'm not sure how "anyone who interacts with editors" would actually benefit through this feature; to me it seems that it would encourage using edit-count as a measure of worthiness when it truly doesn't matter at all. The only time I have ever seen edit-count used as evidence of an active editor is in RfAs. Pagliaccious (talk) 16:48, 18 November 2018 (UTC)
  •   Oppose I appreciate the good intent but unless this is opt-in I think it gives too much information Jessamyn (talk) 17:20, 18 November 2018 (UTC)
  •   Support Hyperik (talk) 20:40, 18 November 2018 (UTC)
  •   Support JackPotte (talk) 22:18, 18 November 2018 (UTC)
  •   Support -- Whats new?(talk) 22:31, 18 November 2018 (UTC)
  •   Support Stryn (talk) 23:05, 18 November 2018 (UTC)
  •   Support [[kgh]] (talk) 00:01, 19 November 2018 (UTC)
  •   Support Waddie96 (talk) 07:59, 19 November 2018 (UTC)
  •   Oppose Mediatus (talk) 08:51, 19 November 2018 (UTC)
  •   Support ·addshore· talk to me! 10:09, 19 November 2018 (UTC)
  •   Oppose If it's opt-in, then maybe, but a huge NO if mandatory.  Paine Ellsworth  put'r there  17:08, 20 November 2018 (UTC)
  •   Support as opt in. Oppose as opt out Lostinlodos (talk) 19:24, 20 November 2018 (UTC)
  •   Support Novak Watchmen (talk) 01:33, 21 November 2018 (UTC)
  •   Support Only if optional BugWarp (talk) 01:57, 21 November 2018 (UTC)
  •   Support Terra  (talk) 03:06, 21 November 2018 (UTC)
  •   Oppose Vulphere 04:48, 21 November 2018 (UTC)
  •   Neutral. What is the benefit to the user of expending the effort to convert it to an extension compared to, say, keeping it as a gadget and making it enabled by default? Is there one? Enabling the gadget by default could be done in five minutes. (I don't know. I'm genuinely asking.) I don't oppose the proposal because this functionality would be perfectly valid as an extension, but I also don't see why effort should be spent converting it to an extension when there'd be no real difference for the user. --Deskana (talk) 12:20, 22 November 2018 (UTC)
  •   Oppose Per Jo-Jo Eumerus. No such user (talk) 19:34, 22 November 2018 (UTC)
  •   Support I agree, but this should be an opt-in option. Poslovitch (talk) 20:32, 22 November 2018 (UTC)
  •   Support I support this idea as long as it is opt-in. Tetizeraz (talk) 23:17, 22 November 2018 (UTC)
  •   Support Vctrbarbieri (talk) 02:36, 24 November 2018 (UTC)
  •   Oppose Victorgibby 03:06, 25 November 2018 (UTC). Eso ya es decision de cada usuario, además si ya existen herramientas como XTools para que hacer esto?
  •   Oppose IKhitron (talk) 19:37, 25 November 2018 (UTC)
  •   Support Ranjithsiji (talk) 23:05, 25 November 2018 (UTC)
  •   Oppose ifny (talk) 03:08, 27 November 2018 (UTC)
  •   Support Dvorapa (talk) 12:45, 27 November 2018 (UTC)
  •   Oppose I think implementing this via a template, rather than changes to the code, would make everyone happier. Daniel Case (talk) 16:21, 28 November 2018 (UTC)

Save the revision that a translated article is based on

  • Problem: We, the another wikipedian (non English) try to translate mostly from English Wikipedia. When we create any article in another language, we frequently notice in spite of passing out several days, no edition has been done there. But in the meantime, we find so many editions in the same English wikipedia article. It is very difficult to us to find out the exact edition in English wikipedia.
  • Who would benefit: The translator who try to enrich a wiki article which is in another Wikipedia of different language.
  • Proposed solution: So, I suggest if any tool can be created and by using it we can understand the differences of editions which have been done in a specific wikipedian article page, it will be so beneficial to us for translating the information.
  • More comments:
  • Phabricator tickets:
  • Proposer: প্রলয়স্রোত (talk) 13:42, 11 November 2018 (UTC)


@প্রলয়স্রোত: It's unclear to me what exactly is requested here... Why do you need to find the exact edition in English Wikipedia that corresponds to a version in another Wikipedia? I'm not sure I understand the underlying problem. When you translate an article from English Wikipedia, do you use mw:Extension:ContentTranslation? --AKlapper (WMF) (talk) 13:32, 12 November 2018 (UTC)

@AKlapper (WMF): Assuming "editing" and "addition" were meant by "edition", this is a request for some sort of version control system, like the one used on multilingual projects (but using an English Wikipedia article as the source). I might be wrong, but it seems to make a lot of sense. Jc86035 (talk) 18:09, 12 November 2018 (UTC)
@Jc86035: Does "some sort of version control system, like the one used on multilingual projects" mean something like that exists already? Could you provide some example link (or steps how to see that system)? Thanks! :) --AKlapper (WMF) (talk) 22:58, 12 November 2018 (UTC)
@AKlapper (WMF): I was referring to mw:Extension:Translate (I forgot what it was called). Jc86035 (talk) 08:49, 13 November 2018 (UTC)

How about putting an HTML comment in the source, like this: <!-- based on (2018-11-12) -->? PJTraill (talk) 23:50, 26 November 2018 (UTC)

Hi প্রলয়স্রোত,

The extension for translating articles is Content Translation and not Translate. I'll assume that this wishlist item is about Content Translation.

Content Translation has saved the revision that a translated article is based on from the very start, since it was launched in January 2015. The link to this revision can be easily found in the edit summary of the first translated revision. For example, if you go to the article Haenyeo (হেনিয়ো), then to its revision history (ইতিহাস দেখুন), you'll see the edit summary on the oldest revision: ("Haenyeo" পাতাটি অনুবাদ করে তৈরি করা হয়েছে). "Haenyeo" is a link to the English Wikipedia article revision from which this article was translated. Does it address the request in the title of this wishlist item? --Amir E. Aharoni (talk) 11:30, 27 November 2018 (UTC)

It is my bad not clearly express what I wanna say. I am going to give an example now: hope it will make sense of my statement:@AKlapper (WMF):,@Jc86035:,@PJTraill:,@Amire80:;
Optical physicist w:Donna Strickland received nobel in 2018. After getting nobel I translated wiki article on her to bangla wiki instantly. Hope, she will live longer but as law of nature she has to die. Suppose she would die on 2021. As of lack of our manpower in Bangla Wikipedia it might be happened that no bengali wikipedian would update her Bengali wiki biography between the three years. So after hearing her death news any of Bangla wikipedian would come to her bangla biograph and will try to compare bangla article with English article for knowing which info is not in Bangla wiki.
And it is very time consuming to read sentence by sentence to compare the two articles which is in different languages or to browse every history pages and it's editing. Because in those three years there may be more than thousand history pages in English wiki.
But, if there are a tool to check only those editings which exists only and can be shown in one page by setting date range, e:g: October 2018-November 2021, it would be helpful for the translator, especially for the large page like w:List of atheists in science and technology, w:Evidence of common descent etc. Sorghum 17:51, 28 November 2018 (UTC)


Stop ifexist checks from appearing in Special:WhatLinksHere

  • Problem: #ifexist is the parser function that checks if a page exists. It is also available as a Lua function. It is potentially a very useful function for Wikidata-enabled infoboxes as it can be used to discover redirects to existing articles (since allowing the creation of links to redirects in Wikidata has been under discussion since 2017 and is unlikely to be resolved soon). However, doing the check also makes a link appear in Special:WhatLinksHere - and that causes problems for Wikimedians who are checking links to disambiguation pages. It is not currently possible to stop that link from appearing.
  • Who would benefit: People writing template code who want to use #ifexist to provide extra functionality, but currently can't as it causes. People doing disambiguation checking while people are using #ifexist statements.
  • Proposed solution: Either stop #ifexist from creating a link in Special:WhatLinksHere, or create a new magic word that does the same as #ifexist without creating the link.


See also: #Separate_templates_in_"What_links_here"TheDJ (talkcontribs) 10:28, 5 November 2018 (UTC)


  •   Support James Martindale (talk) 19:42, 16 November 2018 (UTC)
  •   Support Atamari (talk) 21:44, 16 November 2018 (UTC)
  •   Support Links tables will also need to be updated when a page's existence status changes (T33628). A red link becomes a blue one when a page is created, a deleted page is restored, an existing page is moved, or a page is imported from elsewhere. A blue link becomes a red one when an existing page is deleted or moved without redirect creation. GeoffreyT2000 (talk) 01:32, 17 November 2018 (UTC)
  •   Support Liuxinyu970226 (talk) 08:35, 17 November 2018 (UTC)
  •   Support Tractopelle-jaune (talk) 09:49, 17 November 2018 (UTC)
  •   Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:05, 17 November 2018 (UTC)
  •   Support Cabayi (talk) 17:36, 17 November 2018 (UTC)
  •   Support Jon Harald Søby (talk) 12:35, 18 November 2018 (UTC)
  •   Support — Draceane talkcontrib. 18:21, 18 November 2018 (UTC)
  •   Support Viswaprabha (talk) 23:36, 18 November 2018 (UTC)
  •   Support β16 - (talk) 13:52, 19 November 2018 (UTC)
  •   Support This is important to people I depend on to write tools, anything that makes their work easier would be great John Cummings (talk) 16:21, 19 November 2018 (UTC)
  •   Support please at least create a way to filter ifexist-"links" out the result → «« Man77 »» [de] 13:11, 20 November 2018 (UTC)
  •   Support Novak Watchmen (talk) 01:35, 21 November 2018 (UTC)
  •   Support Jack who built the house (talk) 18:25, 21 November 2018 (UTC)
  •   Support Wikisaurus (talk) 18:27, 21 November 2018 (UTC)
  •   Support Iniquity (talk) 11:52, 22 November 2018 (UTC)
  •   Support stjn[ru] 18:24, 22 November 2018 (UTC)
  •   Support No such user (talk) 19:36, 22 November 2018 (UTC)
  •   Support Serhio Magpie (talk) 03:30, 23 November 2018 (UTC)
  •   Support BrownHairedGirl (talk) 01:17, 25 November 2018 (UTC)
  •   Support Alexei Kopylov (talk) 01:33, 25 November 2018 (UTC)
  •   Support IKhitron (talk) 19:40, 25 November 2018 (UTC)
  •   Support — AfroThundr (u · t · c) 03:11, 26 November 2018 (UTC)
  •   Support DMacks (talk) 19:36, 26 November 2018 (UTC)
  •   Support Dvorapa (talk) 12:48, 27 November 2018 (UTC)

Clear roadblock for wiki site URL changes

  • Problem: The domains of several Wikimedia wikis should be renamed. This was done once, when was renamed to, but this renaming exposed several issues. Performing any more renaming is not advised until these issues are resolved.
  • Who would benefit: Users of wiki sites pending for rename.
  • Proposed solution: Clear roadblock for wiki project language code changes so that they can be changed
  • More comments: It have been a decade since these renaming were initially requested.


  • @C933103: It looks like the link Phabricator task has been resolved. Regardless, I don't think this is something Community Tech could help with, as it isn't a matter of software development but rather site operations and/or systems administration. Perhaps I am missing something? MusikAnimal (WMF) (talk) 22:26, 30 October 2018 (UTC)
    • @MusikAnimal: Ah I have manually typed a wrong phab code. It have been updated and corrected. While the actual process for site renaming is related to site operation and administration, it seems like there are things that prevent it to occur that are blocking it at a more general level.C933103 (talk) 01:14, 31 October 2018 (UTC)
      • Got it, thanks. I do see some subtasks that we might be able to help with. MusikAnimal (WMF) (talk) 01:23, 31 October 2018 (UTC)
Note that this is currently blocking creation and translation of Wikipedia into certain language projects. C933103 (talk) 08:21, 9 November 2018 (UTC)
Currently nowiki is effectively perpetrating linguistic discrimination due to a domain and language code anomaly, and an age-old language conflict. This proposal would potentially make it possible for us to find a way out of this embarassing situation. - Soulkeeper (talk) 16:22, 9 November 2018 (UTC)


  •   SupportC933103 (talk) 07:10, 17 November 2018 (UTC)
  •   Support Liuxinyu970226 (talk) 08:36, 17 November 2018 (UTC)
  •   Support stjn[ru] 09:35, 17 November 2018 (UTC)
  •   Support ديفيد عادل وهبة خليل 2 (talk) 11:26, 17 November 2018 (UTC)
  •   Support Jon Harald Søby (talk) 12:36, 18 November 2018 (UTC)
  •   Support Sebastian Wallroth (talk) 13:06, 18 November 2018 (UTC)
  •   Support Hydriz (talk) 13:30, 18 November 2018 (UTC)
  •   Support Timeshifter (talk) 14:44, 18 November 2018 (UTC)
  •   Support Viztor (talk) 03:46, 19 November 2018 (UTC)
  •   Support Strong support - we've been trying to rename -> for a decade! Deryck C. 14:29, 19 November 2018 (UTC)
  •   Support also/even more because we should care even if it doesn't affect the wikis most of us use ourselves. —TheDJ (talkcontribs) 14:30, 19 November 2018 (UTC)
  •   Support per above. - Soulkeeper (talk) 16:52, 19 November 2018 (UTC)
  •   SupportEjs-80 12:16, 20 November 2018 (UTC)
  •   Support Novak Watchmen (talk) 01:37, 21 November 2018 (UTC)
  •   Support Vulphere 04:46, 21 November 2018 (UTC)
  •   Support Matěj Suchánek (talk) 09:15, 24 November 2018 (UTC)
  •   Support PMG (talk) 17:06, 26 November 2018 (UTC)
  •   Support Yes and hopefully one day also resolve all the issues with be-x-old Dvorapa (talk) 12:42, 27 November 2018 (UTC)

Every special page that accepts wikitext should have normal editor toolbar

  • Problem: None of the Mediawiki editing extensions currently in use (like search and replace and CharInsert) are available for use with ExpandTemplates. Another missed opportunity, when previewing templates and template code is the inability to review the "Parser profiling data" to monitor and manage the work being done with respect to technical limitations.
  • Who would benefit: Any editor who uses the ExpandTemplates special page will benefit by having these editing extensions available when using that page for its intended purpose.
  • Proposed solution: I propose that the "input pane" be modified to mimic the "editing pane" used across our Wikimedia projects. And when input is rendered for preview, along with a visualization of the template/syntax after expansion, provide the "Parser profiling data", as well, to show the efficiency of said expansion when rendering said preview. I can hardly imagine another time when the information would be more empowering than when expanding/previewing templates and syntax on the ExpandTemplates special page.
  • More comments: If a Special NavBar is created — tailored to the unique purpose and needs of this special page — that would certainly be great! But, that is not what I am proposing at this time. I will be happy with the same "add-on array", currently in use, without modification. In my opinion it will be an immediate improvement to the ExpandTemplates page the moment these features become available. Thank you for considering this proposal.
  • Phabricator tickets: I am not aware of any.


@John Cline: So you want to make the Special:ExpandTemplate debug page, a full fledged Template editor or something, if I understand correctly ? —TheDJ (talkcontribs) 14:29, 2 November 2018 (UTC)

I would like the page to mimic the full editing experience by making the header bar available (particularly for its "advanced" and "help" features) and a footer array of "Insertable wiki markup" (which could be customized to insert the most common "variables" and "conditional expressions" used in template code) without, of course, the footer bar (which allows the edit summary, marking change as minor, and publishing changes). I hope this has answered your question; please follow-on if it has not. Thank you.John Cline (talk) 15:26, 2 November 2018 (UTC)


Global signature

  • Problem: For people who would like to have some uniqueness in their signatures, the default signature has to be re-configured over and over again every time we entered a new Wiki project. Besides, for people with non-latin usernames (like me), they might want to display a more recognizable, possibly Romanized signature on other Wiki Projects, and a more complicated username in their home wiki.
  • Who would benefit: Cross-wiki users; people having non-latin characters in their user names, and people reading their comments
  • Proposed solution: A global signature (maybe the one used in
  • More comments: I also hope that the default signature can be bolded, because the current plain link just make it merge into the discussions, and indistinguishable from other blue links.
  • Phabricator tickets: T188200
  • Proposer: 燃灯 (talk) 18:46, 4 November 2018 (UTC)


  • Why doesn't just putting it in Special:GlobalPreferences work for this? BWolff (WMF) (talk) 02:15, 5 November 2018 (UTC)
    • @BWolff (WMF): It isn't avaiable as a global preference despite my request during development. — JJMC89(T·C) 04:50, 5 November 2018 (UTC)
  • Translating scripts would probably make it easier for people unfamiliar with some scripts to recognize editors. But this might also make names unrecognizable across wikis; many people have natural names in multiple languages which are not obviously related to one another. If this gets implemented, could we please have a Languages section in the sidebar of user pages so that it's obvious what other names a user uses? HLHJ (talk) 03:03, 18 November 2018 (UTC)
  •   Comment This could cause issues if global is the only option. I for example have a different sig here than on (the one here specifically targets to user page, where if the en one was used here it would target my meta user page). — Insertcleverphrasehere (or here) 15:34, 23 November 2018 (UTC)
@Insertcleverphrasehere: How is your signature compatible with conventions, as there is no link to either your user page or your talk page in this project included, just links to outside this project? Grüße vom Sänger ♫(Reden) 05:26, 26 November 2018 (UTC)
Sänger My user and talk pages on are the only ones that I maintain actively, therefore my signature directs to those. — Insertcleverphrasehere (or here) 08:54, 26 November 2018 (UTC)


  •   Support Galobtter (talk) 19:17, 16 November 2018 (UTC)
  •   Support Cohaf (talk) 19:28, 16 November 2018 (UTC)
  •   Support James Martindale (talk) 19:43, 16 November 2018 (UTC)
  •   Support But what if users from other countries can't see your signature properly? Think about those containing CJK characters or Thai, Lao, or Burmese. Super Wang on zhwiki (Share your opinions) 23:49, 16 November 2018 (UTC)
  •   Support — JJMC89(T·C) 00:14, 17 November 2018 (UTC)
  •   Support Hell yeah — regards, Revi 02:08, 17 November 2018 (UTC)
  •   Support Enterprisey (talk) 04:10, 17 November 2018 (UTC)
  •   Support Hiàn (talk) 04:37, 17 November 2018 (UTC)
  •   Support Rschen7754 06:18, 17 November 2018 (UTC)
  •   Support Xiplus (talk) 07:55, 17 November 2018 (UTC)
  •   Support Liuxinyu970226 (talk) 08:35, 17 November 2018 (UTC)
  •   Support Hell yeah indeed. stjn[ru] 09:36, 17 November 2018 (UTC)
  •   Support Life would be little easy. :P ‐‐1997kB (talk) 10:29, 17 November 2018 (UTC)
  •   Support Frettie (talk) 10:46, 17 November 2018 (UTC)
  •   Support --Alaa :)..! 10:46, 17 November 2018 (UTC)
  •   Support ديفيد عادل وهبة خليل 2 (talk) 11:25, 17 November 2018 (UTC)
  •   Support Kpgjhpjm (talk) 13:36, 17 November 2018 (UTC)
  •   Support Martin Urbanec (talk) 13:52, 17 November 2018 (UTC)
  •   Support 94rain (talk) 14:05, 17 November 2018 (UTC)
  •   Support Naseweis520 (talk) 15:26, 17 November 2018 (UTC)
  •   Support Blue Rasberry (talk) 15:44, 17 November 2018 (UTC)
  •   Support Dcheney (talk) 16:49, 17 November 2018 (UTC)
  •   Support Wish this happens soon. ··· 🌸 Rachmat04 · 18:38, 17 November 2018 (UTC)
  •   Support Barcelona (talk) 18:59, 17 November 2018 (UTC)
  •   Support Amir (talk) 19:10, 17 November 2018 (UTC)
  •   Support Nightdevil (talk) 19:59, 17 November 2018 (UTC)
  •   SupportThanks for the fish! talkcontribs 20:23, 17 November 2018 (UTC)
  •   Support Yamaha5 (talk) 20:35, 17 November 2018 (UTC)
  •   Support MehdiTalk 20:38, 17 November 2018 (UTC)
  •   Support This would be nice to have, bit, is not a top-priority by any means for me, though. SshibumXZ (talk) 21:12, 17 November 2018 (UTC)
  •   SupportAmmarpad (talk) 21:29, 17 November 2018 (UTC)
  •   Support --Hadibe (talk) 22:54, 17 November 2018 (UTC)
  •   Support Strongly support. Tom (LT) (talk) 23:17, 17 November 2018 (UTC)
  •   Support Tim Landscheidt (talk) 01:35, 18 November 2018 (UTC)
  •   Support HLHJ (talk) 03:03, 18 November 2018 (UTC)
  •   Oppose It may not be polite to use a fancy signature in other wiki projects due to difference in culture.--Temp3600 (talk) 05:56, 18 November 2018 (UTC)
  •   Support Poya-P (talk) 06:24, 18 November 2018 (UTC)
  •   Support Abductive (talk) 10:05, 18 November 2018 (UTC)
  •   Support NMaia (talk) 10:36, 18 November 2018 (UTC)
  •   Support فرهنگ2016 (talk) 10:42, 18 November 2018 (UTC)
  •   Support Sharaky Talk 10:54, 18 November 2018 (UTC)
  •   Support Leiem (talk) 15:37, 18 November 2018 (UTC)
  •   Support ~ Amory (utc) 16:58, 18 November 2018 (UTC)
  •   Support Jessamyn (talk) 17:14, 18 November 2018 (UTC)
  •   Support stwalkerster (talk) 17:22, 18 November 2018 (UTC)
  •   Support Fatemi 18:54, 18 November 2018 (UTC)
  •   Support -- Whats new?(talk) 22:33, 18 November 2018 (UTC)
  •   Strong support Waddie96 (talk) 07:59, 19 November 2018 (UTC)
  •   Support ·addshore· talk to me! 10:09, 19 November 2018 (UTC)
  •   Support Sadads (talk) 17:43, 19 November 2018 (UTC)
  •   Support - tucoxn\talk 18:46, 19 November 2018 (UTC)
  •   Support Iridescent (talk) 10:16, 20 November 2018 (UTC)
  •   Support Lofhi (talk) 18:05, 20 November 2018 (UTC)
  •   Support Mmitchell10 (talk) 21:07, 20 November 2018 (UTC)
  •   Support CAPTAIN RAJU(T) 22:40, 20 November 2018 (UTC)
  •   Support Novak Watchmen (talk) 01:34, 21 November 2018 (UTC)
  •   Support Tris T7 (talk) 02:38, 21 November 2018 (UTC)
  •   Support Terra  (talk) 03:05, 21 November 2018 (UTC)
  •   Support Definitely! Vulphere 04:45, 21 November 2018 (UTC)
  •   Support Elfi (talk) 07:20, 21 November 2018 (UTC)
  •   Support 燃灯 (talk) 16:30, 21 November 2018 (UTC)
  •   Support Vercelas (quæstiones?) 17:41, 21 November 2018 (UTC)
  •   Support Arian Talk 18:40, 21 November 2018 (UTC)
  •   Support Nihlus 22:25, 21 November 2018 (UTC)
  •   Support tOMG 05:34, 22 November 2018 (UTC)
  •   Oppose. I'd prefer we got rid of customised signatures completely due to the hassle they cause. For example, in the recent migration from Tidy to RemexHtml, illegally formatted signatures containing improperly terminated font tags caused tens of thousands of talk pages to turn into multicoloured rainbows, with font colour tags colouring the text on the rest of the page until the next font colour tag came along and changed it again. The font tag has actually been deprecated for 20 years (really!) but it's used on millions of talk pages due to custom signatures. The headaches caused by custom signatures don't seem worth the benefits to me, so I'm not exactly in favour of exacerbating the problem by encouraging their globalisation. --Deskana (talk) 12:15, 22 November 2018 (UTC)
  •   Support Hecc yeah! ーTesser4D 【🅱alk】 17:29, 22 November 2018 (UTC)
  •   Oppose per Deskana (who, I hope, does not use that fancy upside-down sig on anymore ;) ). No such user (talk) 19:43, 22 November 2018 (UTC)
    • @No such user: Yes, I did, and that's actually a good example of the problem! An upside down signature like I used to use is a nightmare for accessibility since a screenreader wouldn't be able to make any sense of it. Nice callout. ;-) --Deskana (talk) 11:23, 23 November 2018 (UTC)
  •   Support Sebari – aka Srittau (talk) 20:02, 22 November 2018 (UTC)
  •   Support FiliP ██ 20:40, 22 November 2018 (UTC)
  •   Support SalmanZ (talk) 21:19, 22 November 2018 (UTC)
  •   Oppose Customized signatures aren't welcome in every project. Enforcing them against local customs can lead to unnecessary disputes. --Zinnmann (talk) 15:21, 23 November 2018 (UTC)
  •   Support James F. (talk) 22:43, 23 November 2018 (UTC)
  •   Support Sannita - not just another sysop 00:51, 24 November 2018 (UTC)
  •   Support WeegaweeK ❀  t  c  08:30, 24 November 2018 (UTC)
  •   Oppose Per Deskana. CT should deal with more useful stuff. Matěj Suchánek (talk) 09:15, 24 November 2018 (UTC)
  •   Support Hmxhmx 11:17, 24 November 2018 (UTC)
  •   Support Helder 11:32, 25 November 2018 (UTC)
  •   Support  Klaas `Z4␟` V:  12:00, 25 November 2018 (UTC)
  •   Contra wie Deskana. Klickibunti-Egovergrößerungsmüll, den einige hier haben, sollte dann selbstverständlich untersagt werden. per Deskana. Clicky-Dicky-Ego-Enhancing-Junk that some have as signatures should be strictly forbidden in that case. Grüße vom Sänger ♫(Reden) 14:17, 25 November 2018 (UTC)
  •   Support SemiHypercube (talk) 19:53, 25 November 2018 (UTC)
  •   Support WhatamIdoing (talk) 02:29, 26 November 2018 (UTC)
  •   Support — AfroThundr (u · t · c) 03:15, 26 November 2018 (UTC)
  •   Oppose - all custom signatures should be removed. PMG (talk) 16:48, 26 November 2018 (UTC)
  •   Oppose PJTraill (talk) 00:00, 27 November 2018 (UTC) I did not realise (but am not surprised) that custom signatures cause so much pain.
  •   Oppose The issues of bad syntax can be worked out (T178879 and related), so I'm not real sympathetic to Deskana's opposition. The bigger problem with custom signatures is the general inaccessibility as noted by others here. --Izno (talk) 00:49, 27 November 2018 (UTC)
  •   Oppose, all custom signatures should be removed. Stryn (talk) 10:24, 27 November 2018 (UTC)
  •   Oppose per Matěj Suchánek. Gareth (talk) 09:18, 29 November 2018 (UTC)

Have CAPTCHA in languages other than English

  • Problem: Have CAPTCHA in languages other than English
  • Who would benefit: All Wikimedians who use languages other than English
  • Proposed solution: Localize CAPTCHA images.
  • More comments: This is quite involved job. Once achieved, this will help a lot in improving OCR softwares as well.
  • Phabricator tickets:
  • Proposer: Pavanaja (talk) 14:22, 11 November 2018 (UTC)


What do you mean by "this will help a lot in improving OCR softwares as well"? --Wargo (talk) 23:30, 16 November 2018 (UTC)

Hi, Wargo. You can use captcha data for machine learning. The original reCAPTCHA also directly digitized public-domain books, by asking the user to read and type one known word and one unknown word. Google bought it in 2009 and is now using it to generate proprietary data for training its driverless car software (to recognize other cars, street signs, roads, and so on). HLHJ (talk) 02:26, 18 November 2018 (UTC)
  • I don't think other languages is very useful, and there is also a HUGE problem with phab:T6845 accessibility. I'm in favor of working on this, but probably best to find a complete alternative. —TheDJ (talkcontribs) 13:53, 19 November 2018 (UTC)
    TheDJ, have thought about non-latin users who only have non-latin keyboards? Trizek from FR 13:55, 19 November 2018 (UTC)
    @Trizek: Yes I did. What I meant here is "not a sustainable solution". No matter which keyboard layout you support, there are going to be MORE people without that layout. We need something better altogether. —TheDJ (talkcontribs) 14:01, 19 November 2018 (UTC)
    Got is, thanks! Trizek from FR 15:10, 19 November 2018 (UTC)


  •   Support Liuxinyu970226 (talk) 08:35, 17 November 2018 (UTC)
  •   Support Martin Urbanec (talk) 13:52, 17 November 2018 (UTC)
  •   Support Theklan (talk) 18:16, 17 November 2018 (UTC)
  •   Support JAn Dudík (talk) 20:23, 17 November 2018 (UTC)
  •   Support HLHJ (talk) 02:26, 18 November 2018 (UTC)
  •   Support Jeb (talk) 15:55, 18 November 2018 (UTC)
  •   Support Joalbertine (talk) 17:39, 18 November 2018 (UTC)
  •   Support and they should be accessible. Trizek from FR 10:47, 19 November 2018 (UTC)
  •   Support«« Man77 »» [de] 13:18, 20 November 2018 (UTC)
  •   Support With reservations. I support this but only on non en sites. there should also be a fallback option to english keyboards where non-english is principally offered. Lostinlodos (talk) 19:21, 20 November 2018 (UTC)
  •   Support Novak Watchmen (talk) 01:36, 21 November 2018 (UTC)
  •   Support Vulphere 04:42, 21 November 2018 (UTC)
  •   Support Elfi (talk) 07:18, 21 November 2018 (UTC)
  •   Neutral A prominent Wikimedia Foundation engineer recently demonstrated that the CAPTCHA system we use is easily crackable by machines anyway (I don't want to reveal the details for fear of stuffing beans up my nose) so overhauling it so that that isn't true any more would probably be better than expanding it to other wikis. --Deskana (talk) 12:23, 22 November 2018 (UTC)
  •   Support Adithyak1997 (talk) 10:22, 24 November 2018 (UTC)
  •   Support Arbnos (talk) 23:05, 24 November 2018 (UTC)
  •   Support Victorgibby 03:04, 25 November 2018 (UTC)
  •   Oppose IKhitron (talk) 19:40, 25 November 2018 (UTC)
  •   Support — AfroThundr (u · t · c) 03:22, 26 November 2018 (UTC)

Provide an easier way to create a wikitable from a Commons dataset

See or edit source data. Here's a graph created from a Commons dataset,
but where's the corresponding wikitable?

  • Problem: Tabular data can be stored on Commons by creating a page named something like Data:Page This allows the data to be used across multiple pages, projects and languages. There are several templates that can be used to easily turn the data into a graph, but bringing the data to other sites via a wikitable is difficult. This proposal is to provide an easier way to create these wikitables and to fix a handful of bugs that severely limit the usefulness of Commons' Data namespace - these bugs also affect map data pages stored at Commons, so maps users would benefit from these fixes as well.
  • Who would benefit: A central repository for tabular data has major benefits for editors; it allows tables and graphs to be created from a single data source and enables the data powering both the table and the graph to be updated simultaneously. Additionally, it allows content to be reused across multiple projects and languages (particularly beneficial for smaller communities, which can piggyback on the creation and maintenance work of the larger communities). A central repository that easily allows the creation of tables and graphs would probably lead to more graphs being created - readers would benefit from an alternative (and sometimes more easily understandable) way to view the data. An additional benefit for readers would be the availability of more up to date data across the various languages and projects. An easy way to get the data out of the data page and into a wikitable is the key to wider adoption of the technology. (BTW, the graph software can do much more than simply displaying "traditional" graphs. The example at Template:Graph:World Historical Highlights shows a graph based on a world map; the map data comes from a .map page and the statistical data comes from a .tab page. Adding easy creation of wikitables to the mix would open up very interesting possibilities.)
  • Proposed solution: We need three things:
    • An easy way to access and display the data.
      • This would be akin to the current methods for accessing content stored on Commons - <mapframe> for map data and [[File:Image.jpg]] for images and other files. It could possibly be achieved by expanding on the transclusion method that works at Commons but nowhere else. (Typing {{Data:Page}} will display the data page as a wikitable.)
      • There should be a way to customise the display of data e.g. setting column widths; adding formatting such as highlighting rows, columns and cells; selecting which parts of the dataset to display and some way to add wikilinks.
    • A link to the dataset so that people can easily edit it.
    • Fixes for bugs that make Commons’ Data namespace limiting or difficult to use (the following issues also affect map data stored at Commons):
      • Support appropriate documentation of CC BY SA data on Commons (T200968)
      • Add a data-page-only wiki markup header to datasets (T155290)
      • Track Commons Dataset usage across wikis (what links here) (T153966)
      • Support Data namespace redirects (T153598)
    The lack of support for redirects and what links here means that moving (or splitting) pages in the data namespace is liable to break stuff, with no way to know whether this has occurred – a really unacceptable situation for a repository that is supposed to be available across projects and languages.
  • Phabricator tickets: See above.
  • Proposer: Gareth (talk) 02:02, 30 October 2018 (UTC)


  • I had no idea one could do this. It's great. It even seems to use colourblind-functional colours by default. Adding tables seems like a good idea, but I can also think of lots of other things I'd love to have, so I've added a wishlist for new templates to the talk page, including your wish for tables. Thank you for alerting me to the existence of this. HLHJ (talk) 03:06, 31 October 2018 (UTC)
  • Very much support this work. A good data/graphing infrastructure would be a priority for me. That should include a simple integrated service to convert CSV/TabSV files to JSON (even if post-editing the JSON would be required). --Gregor Hagedorn (talk) 12:24, 31 October 2018 (UTC)
  • I'm not sure why this was moved to the "Multimedia and Commons" section - tables aren't really multimedia and Commons simply acts as the data repository; adding/customising the tables would take place at other projects. I think placing the proposal in this section is quite misleading. Gareth (talk) 01:57, 2 November 2018 (UTC)
    • Given the above, the vague rationale for the initial move and the lack of further explanation, I've moved this back to the "Miscellaneous" section Gareth (talk) 05:35, 7 November 2018 (UTC)


Provide a tool to efficiently analyze the usage of a template

  • Problem: As in previous years (2017), again I want to raise your attention to the fact that working with often used templates and making changes to them is a mess. Why? There is no tool or handy way to get to grips how the template has actually been used and which peculiarities one has to consider (or which pages where the template is used need to be edited) when rewriting a template.
The tool written by User:Kolossos has been helpful for many years, but instead of providing live information it is based on dumps (most a year and a half old, some even more), and there is no interface (you need to know how to manipulate the URL to filter the information).
The tool developped by User:Bamyers99 only supports Commons and enwiki. There is some interface, and according to the discussion of last year's proposal it provides live information upon request, but I can't really talk about its pros and cons as I didn't test the tool very much, as it doesn't support the wikis I regularly visit.
  • Who would benefit: Primarily users who curate and amend templates, secondarily authors who use templates in their articles.
  • Proposed solution: I don't know if it's better to amend one of the two tools I mentioned above or to build something new, but the following characteristics should be considered:
    • for the timeliness of data: For an efficient curation of templates we need to be able to analyze live data, not an old dump. Permanently scanning the entire wikiverse sounds like an overkill, providing an analysis on request seems fine for me.
    • scope: I think it is fair to ask for a tool that is able to analyse all Wikimedia wikis, not just a couple of popular wikis.
    • features: The tool should be able to answer different inquiries such as:
      • table of all pages which use a template with all parameters (like this)
      • sortable list of articles in which parameter X is defined.
      • list of articles in which parameter X is defined as or contains Y (with Y being a regular expression).
    • usability: The tool should have an interface which is easy to get to grips with, lets say similar to petscan.
  • More comments:
  • Phabricator tickets: phab:T120767
  • Proposer: → «« Man77 »» [de] 21:49, 6 November 2018 (UTC)



Shared Multilingual Templates and Modules available to all wikis

  • Problem: Every wiki has to maintain its own its own templates and modules. They are often copied from other wikis and translated, but any fixes and improvements to the original templates often do not get copied, making them very hard to maintain. This is especially bad for the smaller wikis because they often do not have enough technical volunteers to maintain it.
  • Who would benefit: Content contributors
  • Proposed solution: Ideally this should be fixed in MediaWiki, but that may take too long. A much simpler and quicker solution is to use already existing technologies, and create a bot that will do most of what we need. A typical workflow for the multilingual templates and modules:
  • A template or a module is created on (MW is better because its community is more dev-focused, whereas Commons tends to be content-focused)
  • all localization strings are placed in the tabular data on Commons to simplify translation
  • template parameters are also placed in a tabular data on Commons
  • All strings are used via the Module:TNT
  • Some well known infobox is placed at the top of the template/module documentation to indicate that this module is shared between multiple wikis, and should not be changed anywhere else.
  • A bot looks for all modules/templates on that have that infobox, and copies them automatically to all other wikis using the sitelink list in Wikidata
  • If someone wants to use that template/module in a wiki X, they just need to copy/paste it to the wiki X, and add the sitelink - the bot will automatically keep it up to date from there on.
  • If a wiki decides to "fork" their version, they can simply remove the infobox from the docs.


  • See also Community Wishlist Survey 2019/Archive/Centralized templates and modules and Community Wishlist Survey 2019/Miscellaneous/Centralised language independent wikiproject for modules and templates. This proposal in a nutshell seems to be "doing it in MediaWiki is too hard, so hack it up with a bot". Anomie (talk) 16:07, 11 November 2018 (UTC)
    @Anomie: thx for the links. Yes, this proposal is a stopgap until MediaWiki implements it, AND it can be easily migrated to a more permanent solution once it becomes available. --Yurik (talk) 20:15, 11 November 2018 (UTC)
  • I've said this elsewhere, but "Module:TNT" is a garbage name. What is the point of the module? Name it that. --Izno (talk) 01:12, 12 November 2018 (UTC)
    @Izno:, there was a reason for such name -- it has to be short, and it should NOT be language-specific. Unlike all other templates and modules, TNT must be named the same way in all languages, so that templates and modules that use it would not have to be changed when copied from wiki to wiki. --Yurik (talk)
    So you chose en:TNT? :) As for "TNT must be named the same way in all languages, so that templates and modules that use it would not have to be changed when copied from wiki to wiki", this seems like an artificial restriction. If it is a template, and it's used for meta templates, it probably doesn't need a localized name (since most programmers are willing to program in English). And for where it's not used in meta templates, TNT does not tell them anything at all! --Izno (talk) 01:26, 12 November 2018 (UTC)
    It has to be short AND not already taken in any of the wikis. So yes, I had to do some considerable checking in all of the wikis to make sure. Some wikis are very serious about English names, e.g. I had a big discussion in dewiki trying to convince them to add a redirect to some well know help template to simplify the copying. They said they do not want any English-named content, even including a redirect. Also, considering that you will have to use TNT all over your modules and templates (one for each localized message string), the shorter the better. --Yurik (talk) 01:51, 12 November 2018 (UTC)
    P.S. Turns out it wasn't fully random either -- TNT Template (not Module) is already used as a redirect for Translatable template. --Yurik (talk) 22:04, 14 November 2018 (UTC)
  • I have a vaguely similar project (in development) at T187749, except instead of a bot it uses a MediaWiki extension to sync wiki pages to a git repo. It's meant more for CSS/JS than modules/templates (which benefit from integration with the wiki editor, and have a more complex localization ecosystem) but might be a starting point for handling this in another way. --Tgr (talk) 21:00, 26 November 2018 (UTC)


  •   Support Liuxinyu970226 (talk) 04:25, 17 November 2018 (UTC)
  •   Support Rob Kam (talk) 10:02, 17 November 2018 (UTC)
  •   Support ديفيد عادل وهبة خليل 2 (talk) 11:25, 17 November 2018 (UTC)
  •   Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:07, 17 November 2018 (UTC)
  •   Support Naseweis520 (talk) 15:27, 17 November 2018 (UTC)
  •   Support Theklan (talk) 18:15, 17 November 2018 (UTC)
  •   Support Barcelona (talk) 19:00, 17 November 2018 (UTC)
  •   Support Helder 20:42, 17 November 2018 (UTC)
  •   Support Capankajsmilyo (talk) 00:01, 18 November 2018 (UTC)
  •   Support Megalibrarygirl (talk) 02:27, 18 November 2018 (UTC)
  •   Support Jon Harald Søby (talk) 12:38, 18 November 2018 (UTC)
  •   Support JackPotte (talk) 22:16, 18 November 2018 (UTC)
  •   Neutral Like "central repository" but bot is workaround. --Wargo (talk) 23:39, 18 November 2018 (UTC)
    Wargo, I'm all for creating a "proper" central repository, but we have been waiting for it for 18 years :). So might as well get something working with minimal effort and use it now. Once the MediaWiki can support central repositories, it can simply use these templates/modules we will create. --Yurik (talk) 01:03, 19 November 2018 (UTC)
  •   Support Shizhao (talk) 02:50, 19 November 2018 (UTC)
  •   Support β16 - (talk) 13:55, 19 November 2018 (UTC)
  •   Support Ghybu (talk) 02:14, 20 November 2018 (UTC)
  •   Support Core support would be better. But hackfix solution is fine too. Vort (talk) 06:02, 20 November 2018 (UTC)
    There's no sign of WMF ever giving templates for non-WMF users any priority. --Rob Kam (talk) 10:01, 20 November 2018 (UTC)
  •   Support Gareth (talk) 16:20, 20 November 2018 (UTC)
  •   Support Doc James (talk · contribs · email) 18:13, 20 November 2018 (UTC)
  •   Support Novak Watchmen (talk) 01:35, 21 November 2018 (UTC)
  •   Support JopkeB (talk) 09:14, 21 November 2018 (UTC)
  •   Support JAn Dudík (talk) 09:11, 22 November 2018 (UTC)
  •   Support. This is likely to be a colossal undertaking due to the social challenges, resulting from recent general hesitation to globalise things recently (cf. the English Wikipedia's negative reactions to centralising things using Wikidata). That said, that hesitation alone is not a good enough reason to not do this, it's just something that needs awareness and support from, for example, the Community Relations Specialists. --Deskana (talk) 11:59, 22 November 2018 (UTC)
  •   Support No such user (talk) 19:30, 22 November 2018 (UTC)
  •   Support MisterSynergy (talk) 09:56, 23 November 2018 (UTC)
  •   Support Sannita - not just another sysop 00:49, 24 November 2018 (UTC)
  •   Support Matěj Suchánek (talk) 09:12, 24 November 2018 (UTC)
  •   Support Hmxhmx 11:15, 24 November 2018 (UTC)
  •   Support Victorgibby 03:07, 25 November 2018 (UTC) La mejor propuesta de todas
  •   Support IKhitron (talk) 19:38, 25 November 2018 (UTC)
  •   Support Uanfala (talk) 23:34, 25 November 2018 (UTC)
  •   Support — AfroThundr (u · t · c) 03:13, 26 November 2018 (UTC)
  •   Support Ghilt (talk) 15:50, 26 November 2018 (UTC)
  •   Support PMG (talk) 17:07, 26 November 2018 (UTC)
  •   Support PJTraill (talk) 00:10, 27 November 2018 (UTC)
  •   Support yeah, enough of broken templates and modules, especially lua ones Cohaf (talk) 00:12, 27 November 2018 (UTC)
  •   Support Zache (talk) 14:10, 27 November 2018 (UTC)
  •   Support --Nemo 22:36, 27 November 2018 (UTC)
  •   Support Kpjas (talk) 10:24, 29 November 2018 (UTC)
  •   Support Dumbassman (talk) 18:07, 29 November 2018 (UTC)


This functionality has been implemented, but needs a global bot flag (or a bot flag on every wiki that wants to use it). --Yurik (talk)