Jump to content

Community Wishlist Survey 2019/Miscellaneous

Add links
From Meta, a Wikimedia project coordination wiki
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:

Discussion

@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)[reply]

There is an existing API module and database table that does exactly this. MER-C (talk) 15:24, 31 October 2018 (UTC)[reply]
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)[reply]
@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).[reply]

Voting

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)[reply]

Discussion

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)[reply]

Voting

  • 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)[reply]

Discussion

Voting

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)[reply]

Discussion

@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)[reply]
  • 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)[reply]

Voting

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:

Discussion

Voting

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)[reply]

Discussion

@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)[reply]

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)[reply]
Both filters would be nice. --NaBUru38 (talk) 20:48, 7 November 2018 (UTC)[reply]
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)[reply]
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)[reply]
I do not see that that matters, and it is clear from Who would benefit. PJTraill (talk) 23:55, 26 November 2018 (UTC)[reply]

Voting

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:

Discussion

Isn't this provided by Wikipedia:Tools/Navigation popups ? Cabayi (talk) 08:06, 30 October 2018 (UTC)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

Voting

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)[reply]

Discussion

@প্রলয়স্রোত: 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)[reply]

@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)[reply]
@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)[reply]
@AKlapper (WMF): I was referring to mw:Extension:Translate (I forgot what it was called). Jc86035 (talk) 08:49, 13 November 2018 (UTC)[reply]

How about putting an HTML comment in the source, like this: <!-- based on https://en.wikipedia.org/w/index.php?title=Abc_conjecture&oldid=870703884 (2018-11-12) -->? PJTraill (talk) 23:50, 26 November 2018 (UTC)[reply]

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)[reply]

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)

Voting

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.

Discussion

See also: #Separate_templates_in_"What_links_here" —TheDJ (talk • contribs) 10:28, 5 November 2018 (UTC)[reply]

Voting

Clear roadblock for wiki site URL changes

  • Problem: The domains of several Wikimedia wikis should be renamed. This was done once, when be-x-old.wikipedia.org was renamed to be-tarask.wikipedia.org, 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.

Discussion

Note that this is currently blocking creation and translation of Wikipedia into certain language projects. C933103 (talk) 08:21, 9 November 2018 (UTC)[reply]
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)[reply]

Voting

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.

Discussion

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

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)[reply]

Voting

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 meta.wiki)
  • 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)[reply]

Discussion

@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)[reply]
Sänger My user and talk pages on en.wiki are the only ones that I maintain actively, therefore my signature directs to those. — Insertcleverphrasehere (or here) 08:54, 26 November 2018 (UTC)[reply]

Voting

Have CAPTCHA in languages other than English

Discussion

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

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)[reply]

Voting

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 title.tab. 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 title.tab}} 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.

Discussion

  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

Voting

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 https://tools.wmflabs.org/templatetiger/ 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 https://tools.wmflabs.org/bambots/TemplateParam.php 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)[reply]

Discussion

Voting

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 mediawiki.org (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 MW.org 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.

Discussion

  • 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)[reply]
    @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)[reply]
  • 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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]

Voting

FOLLOW UP

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) 02:38, 12 April 2019 (UTC) [reply]

  • Problem: "→" links to page section on history, watchlist, recentfeed or diff view are too small to click even for advanced users. Please come up with some better solution for edited sections.
  • Who would benefit: Users checking specific revision of some section.
  • Proposed solution: Larger link, more text in link title, whatever...
  • More comments:

Discussion

Voting

Note: my opposition was clearly expressed in the comment here from 09:58, 29 November 2018 (UTC) subsequently moved by MusikAnimal (WMF). Incnis Mrsi (talk) 10:13, 1 December 2018 (UTC)[reply]

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2019/Miscellaneous&oldid=18684605"