Community Wishlist Survey 2019/Miscellaneous

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Community Wishlist Survey 2019

Miscellaneous
17 proposals, 95 contributors, 136 support votes

Go-previous.svg Maps  •  Mobile and apps Go-next.svg


Separate templates in "What links here"

Support Edit proposal/discussion

  • 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)

Discussion

  • See also: #Fix_a_bug_from_2007:_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)

Voting

Recover text of old revisions for the Massachusetts article

Support Edit proposal/discussion

  • 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

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

Support Edit proposal/discussion

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.
  • Proposer: Gareth (talk) 02:02, 30 October 2018 (UTC)

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)
  • 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)

Voting

Stop ifexist checks from appearing in Special:WhatLinksHere

Support Edit proposal/discussion

  • 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 (talkcontribs) 10:28, 5 November 2018 (UTC)

  • As noted in the past where this issue has come up, the reason the problem has existed for so long is because the solution isn't as simple as it at first seems. When a page is edited, created, or deleted, MediaWiki needs to know which other pages need to be re-parsed due to that change, so it maintains pagelinks (for changes on creation/deletion) and templatelinks (for changes on edit) tables in the database. These tables are also used for Special:WhatLinksHere. Satisfying the request to not display some kinds of "links" from these tables on Special:WhatLinksHere while still correctly updating other pages when a page is created/deleted/edited would require either adding more tables to mostly duplicate the data or adding a field to the existing (very large) tables, both of which would be a very significant amount of work. Anomie (talk) 15:58, 17 November 2018 (UTC)

Voting

  • Support Support James Martindale (talk) 19:42, 16 November 2018 (UTC)
  • Support Support Atamari (talk) 21:44, 16 November 2018 (UTC)
  • Support 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 Support Liuxinyu970226 (talk) 08:35, 17 November 2018 (UTC)
  • Support Support Tractopelle-jaune (talk) 09:49, 17 November 2018 (UTC)
  • Support Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:05, 17 November 2018 (UTC)
  • Support Support Cabayi (talk) 17:36, 17 November 2018 (UTC)

Global signature

Support Edit proposal/discussion

  • 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)

Discussion

Voting

Display more information about users on the user page

Support Edit proposal/discussion

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)
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)

Voting

Every special page that accepts wikitext should have normal editor toolbar

Support Edit proposal/discussion

  • 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 (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)

Voting

Wanted (by articles) pages

Support Edit proposal/discussion

  • 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)

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)

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)

Voting

Automatic display authority control template

Support Edit proposal/discussion

  • 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)

Discussion

  • 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)

Voting

Create a dissemination platform for Wikinews

Support Edit proposal/discussion

  • 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)

Discussion

  • 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)

Voting

Have CAPTCHA in languages other than English

Support Edit proposal/discussion

  • 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: https://phabricator.wikimedia.org/T7309
  • Proposer: Pavanaja (talk) 14:22, 11 November 2018 (UTC)

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)

Voting

"→" links to sections should be easier to click

Support Edit proposal/discussion

  • 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

  • Yeah, just make the grey text part of the link. I wrote a user script on en.wp to do this here and Lego proposed to make MW do the same thing here. Should be pretty easy to do in PHP, which is the optimal solution. Enterprisey (talk) 15:56, 30 October 2018 (UTC)

I like the idea. Gryllida 22:36, 30 October 2018 (UTC)

Voting

Shared Multilingual Templates and Modules available to all wikis

Support Edit proposal/discussion

  • 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)
    @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)

Voting

New special page "Outgoing links"

Support Edit proposal/discussion

  • 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)

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)

Voting

Save the revision that a translated article is based on

Support Edit proposal/discussion

  • 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:
  • 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)

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)

@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)

Voting

Clear roadblock for wiki site URL changes

Support Edit proposal/discussion

  • 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

  • @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)

Voting

Provide a tool to efficiently analyze the usage of a template

Support Edit proposal/discussion

  • 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)

Discussion

Voting