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, 251 contributors

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

The survey has closed. Thanks for your participation :)
Here are the Community Wishlist Survey 2019 results!


New special page "Outgoing links"

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

Automatic display authority control template

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)

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)

Voting

Separate templates in "What links here"

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

Create a dissemination platform for Wikinews

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

Voting

  • Support Support Liuxinyu970226 (talk) 08:43, 17 November 2018 (UTC)
  • Symbol oppose vote oversat.svg 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 Support NMaia (talk) 10:38, 18 November 2018 (UTC)
  • Support Support Benjamin (talk) 10:30, 19 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 01:35, 21 November 2018 (UTC)
  • Support Support Vulphere 04:50, 21 November 2018 (UTC)
  • Oppose 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 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 Support Sahaquiel9102 (talk) 17:24, 23 November 2018 (UTC)
  • Oppose Oppose Victorgibby 03:02, 25 November 2018 (UTC) Wiki Tribune tarde o temprano va reemplazar a Wikinoticias y conserva el mismo formato MediaWiki
  • Support Support — AfroThundr (u · t · c) 03:12, 26 November 2018 (UTC)
  • Oppose Oppose PMG (talk) 17:07, 26 November 2018 (UTC)

Recover text of old revisions for the Massachusetts article

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

Wanted (by articles) pages

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)
I do not see that that matters, and it is clear from Who would benefit. PJTraill (talk) 23:55, 26 November 2018 (UTC)

Voting

Display more information about users on the user page

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)

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}}) Yes check.svg 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)

Voting

  • Support 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 Support Liuxinyu970226 (talk) 08:35, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 11:25, 17 November 2018 (UTC)
  • Support Support Like tears in rain (talk) 13:04, 17 November 2018 (UTC)
  • Support Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:07, 17 November 2018 (UTC)
  • Oppose Oppose Per the rationale given in the discussion section. Jo-Jo Eumerus (talk, contributions) 13:18, 17 November 2018 (UTC)
  • Support Support Zoranzoki21 (talk) 14:42, 17 November 2018 (UTC)
  • Support Support Jullan3 (talk) 15:29, 17 November 2018 (UTC)
  • Support Support Vercelas (quæstiones?) 21:56, 17 November 2018 (UTC)
  • Support Support Super Wang on zhwiki (Share your opinions) 03:21, 18 November 2018 (UTC)
  • Oppose Oppose Per rationale of Jo-Jo Eumerus. AHeneen (talk) 06:16, 18 November 2018 (UTC)
  • Support Support NMaia (talk) 10:38, 18 November 2018 (UTC)
  • Support Support Timeshifter (talk) 14:55, 18 November 2018 (UTC)
  • Oppose 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 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 Support Hyperik (talk) 20:40, 18 November 2018 (UTC)
  • Support Support JackPotte (talk) 22:18, 18 November 2018 (UTC)
  • Support Support -- Whats new?(talk) 22:31, 18 November 2018 (UTC)
  • Support Support Stryn (talk) 23:05, 18 November 2018 (UTC)
  • Support Support [[kgh]] (talk) 00:01, 19 November 2018 (UTC)
  • Support Support Waddie96 (talk) 07:59, 19 November 2018 (UTC)
  • Oppose Oppose Mediatus (talk) 08:51, 19 November 2018 (UTC)
  • Support Support ·addshore· talk to me! 10:09, 19 November 2018 (UTC)
  • Oppose 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 Support as opt in. Oppose as opt out Lostinlodos (talk) 19:24, 20 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 01:33, 21 November 2018 (UTC)
  • Support Support Only if optional BugWarp (talk) 01:57, 21 November 2018 (UTC)
  • Support Support Terra  (talk) 03:06, 21 November 2018 (UTC)
  • Oppose Oppose Vulphere 04:48, 21 November 2018 (UTC)
  • Neutral 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 Oppose Per Jo-Jo Eumerus. No such user (talk) 19:34, 22 November 2018 (UTC)
  • Support Support I agree, but this should be an opt-in option. Poslovitch (talk) 20:32, 22 November 2018 (UTC)
  • Support Support I support this idea as long as it is opt-in. Tetizeraz (talk) 23:17, 22 November 2018 (UTC)
  • Support Support Vctrbarbieri (talk) 02:36, 24 November 2018 (UTC)
  • Oppose 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 Oppose IKhitron (talk) 19:37, 25 November 2018 (UTC)
  • Support Support Ranjithsiji (talk) 23:05, 25 November 2018 (UTC)
  • Oppose Oppose ifny (talk) 03:08, 27 November 2018 (UTC)
  • Support Support Dvorapa (talk) 12:45, 27 November 2018 (UTC)
  • Oppose 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

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

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)

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)

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)

Voting

Stop ifexist checks from appearing in Special:WhatLinksHere

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

Clear roadblock for wiki site URL changes

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

Every special page that accepts wikitext should have normal editor toolbar

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

Global signature

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

  • 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 Comment This could cause issues if global is the only option. I for example have a different sig here than on en.wiki (the one here specifically targets to en.wiki 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 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)

Voting

  • Support Support Galobtter (talk) 19:17, 16 November 2018 (UTC)
  • Support Support Cohaf (talk) 19:28, 16 November 2018 (UTC)
  • Support Support James Martindale (talk) 19:43, 16 November 2018 (UTC)
  • Support 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 Support — JJMC89(T·C) 00:14, 17 November 2018 (UTC)
  • Support Support Hell yeah — regards, Revi 02:08, 17 November 2018 (UTC)
  • Support Support Enterprisey (talk) 04:10, 17 November 2018 (UTC)
  • Support Support Hiàn (talk) 04:37, 17 November 2018 (UTC)
  • Support Support Rschen7754 06:18, 17 November 2018 (UTC)
  • Support Support Xiplus (talk) 07:55, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 08:35, 17 November 2018 (UTC)
  • Support Support Hell yeah indeed. stjn[ru] 09:36, 17 November 2018 (UTC)
  • Support Support Life would be little easy. :P ‐‐1997kB (talk) 10:29, 17 November 2018 (UTC)
  • Support Support Frettie (talk) 10:46, 17 November 2018 (UTC)
  • Support Support --Alaa :)..! 10:46, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 11:25, 17 November 2018 (UTC)
  • Support Support Kpgjhpjm (talk) 13:36, 17 November 2018 (UTC)
  • Support Support Martin Urbanec (talk) 13:52, 17 November 2018 (UTC)
  • Support Support 94rain (talk) 14:05, 17 November 2018 (UTC)
  • Support Support Naseweis520 (talk) 15:26, 17 November 2018 (UTC)
  • Support Support Blue Rasberry (talk) 15:44, 17 November 2018 (UTC)
  • Support Support Dcheney (talk) 16:49, 17 November 2018 (UTC)
  • Support Support Wish this happens soon. ··· 🌸 Rachmat04 · 18:38, 17 November 2018 (UTC)
  • Support Support Barcelona (talk) 18:59, 17 November 2018 (UTC)
  • Support Support Amir (talk) 19:10, 17 November 2018 (UTC)
  • Support Support Nightdevil (talk) 19:59, 17 November 2018 (UTC)
  • Support SupportThanks for the fish! talkcontribs 20:23, 17 November 2018 (UTC)
  • Support Support Yamaha5 (talk) 20:35, 17 November 2018 (UTC)
  • Support Support MehdiTalk 20:38, 17 November 2018 (UTC)
  • Support 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)
  • Support SupportAmmarpad (talk) 21:29, 17 November 2018 (UTC)
  • Support Support --Hadibe (talk) 22:54, 17 November 2018 (UTC)
  • Support Support Strongly support. Tom (LT) (talk) 23:17, 17 November 2018 (UTC)
  • Support Support Tim Landscheidt (talk) 01:35, 18 November 2018 (UTC)
  • Support Support HLHJ (talk) 03:03, 18 November 2018 (UTC)
  • Oppose 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 Support Poya-P (talk) 06:24, 18 November 2018 (UTC)
  • Support Support Abductive (talk) 10:05, 18 November 2018 (UTC)
  • Support Support NMaia (talk) 10:36, 18 November 2018 (UTC)
  • Support Support فرهنگ2016 (talk) 10:42, 18 November 2018 (UTC)
  • Support Support Sharaky Talk 10:54, 18 November 2018 (UTC)
  • Support Support Leiem (talk) 15:37, 18 November 2018 (UTC)
  • Support Support ~ Amory (utc) 16:58, 18 November 2018 (UTC)
  • Support Support Jessamyn (talk) 17:14, 18 November 2018 (UTC)
  • Support Support stwalkerster (talk) 17:22, 18 November 2018 (UTC)
  • Support Support Fatemi 18:54, 18 November 2018 (UTC)
  • Support Support -- Whats new?(talk) 22:33, 18 November 2018 (UTC)
  • Symbol strong support vote.svg Strong support Waddie96 (talk) 07:59, 19 November 2018 (UTC)
  • Support Support ·addshore· talk to me! 10:09, 19 November 2018 (UTC)
  • Support Support Sadads (talk) 17:43, 19 November 2018 (UTC)
  • Support Support - tucoxn\talk 18:46, 19 November 2018 (UTC)
  • Support Support Iridescent (talk) 10:16, 20 November 2018 (UTC)
  • Support Support Lofhi (talk) 18:05, 20 November 2018 (UTC)
  • Support Support Mmitchell10 (talk) 21:07, 20 November 2018 (UTC)
  • Support Support CAPTAIN RAJU(T) 22:40, 20 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 01:34, 21 November 2018 (UTC)
  • Support Support Tris T7 (talk) 02:38, 21 November 2018 (UTC)
  • Support Support Terra  (talk) 03:05, 21 November 2018 (UTC)
  • Support Support Definitely! Vulphere 04:45, 21 November 2018 (UTC)
  • Support Support Elfi (talk) 07:20, 21 November 2018 (UTC)
  • Support Support 燃灯 (talk) 16:30, 21 November 2018 (UTC)
  • Support Support Vercelas (quæstiones?) 17:41, 21 November 2018 (UTC)
  • Support Support Arian Talk 18:40, 21 November 2018 (UTC)
  • Support Support Nihlus 22:25, 21 November 2018 (UTC)
  • Support Support tOMG 05:34, 22 November 2018 (UTC)
  • Oppose 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 Support Hecc yeah! ーTesser4D 【🅱alk】 17:29, 22 November 2018 (UTC)
  • Oppose Oppose per Deskana (who, I hope, does not use that fancy upside-down sig on en.wiki 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 Support Sebari – aka Srittau (talk) 20:02, 22 November 2018 (UTC)
  • Support Support FiliP ██ 20:40, 22 November 2018 (UTC)
  • Support Support SalmanZ (talk) 21:19, 22 November 2018 (UTC)
  • Oppose 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 Support James F. (talk) 22:43, 23 November 2018 (UTC)
  • Support Support Sannita - not just another it.wiki sysop 00:51, 24 November 2018 (UTC)
  • Support Support WeegaweeK ❀  t  c  08:30, 24 November 2018 (UTC)
  • Oppose Oppose Per Deskana. CT should deal with more useful stuff. Matěj Suchánek (talk) 09:15, 24 November 2018 (UTC)
  • Support Support Hmxhmx 11:17, 24 November 2018 (UTC)
  • Support Support Helder 11:32, 25 November 2018 (UTC)
  • Support Support  Klaas `Z4␟` V:  12:00, 25 November 2018 (UTC)
  • Oppose 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 Support SemiHypercube (talk) 19:53, 25 November 2018 (UTC)
  • Support Support WhatamIdoing (talk) 02:29, 26 November 2018 (UTC)
  • Support Support — AfroThundr (u · t · c) 03:15, 26 November 2018 (UTC)
  • Oppose Oppose - all custom signatures should be removed. PMG (talk) 16:48, 26 November 2018 (UTC)
  • Oppose 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 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 Oppose, all custom signatures should be removed. Stryn (talk) 10:24, 27 November 2018 (UTC)
  • Oppose Oppose per Matěj Suchánek. Gareth (talk) 09:18, 29 November 2018 (UTC)

Have CAPTCHA in languages other than English

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)

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)

Voting

  • Support Support Liuxinyu970226 (talk) 08:35, 17 November 2018 (UTC)
  • Support Support Martin Urbanec (talk) 13:52, 17 November 2018 (UTC)
  • Support Support Theklan (talk) 18:16, 17 November 2018 (UTC)
  • Support Support JAn Dudík (talk) 20:23, 17 November 2018 (UTC)
  • Support Support HLHJ (talk) 02:26, 18 November 2018 (UTC)
  • Support Support Jeb (talk) 15:55, 18 November 2018 (UTC)
  • Support Support Joalbertine (talk) 17:39, 18 November 2018 (UTC)
  • Support Support and they should be accessible. Trizek from FR 10:47, 19 November 2018 (UTC)
  • Support Support«« Man77 »» [de] 13:18, 20 November 2018 (UTC)
  • Support 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 Support Novak Watchmen (talk) 01:36, 21 November 2018 (UTC)
  • Support Support Vulphere 04:42, 21 November 2018 (UTC)
  • Support Support Elfi (talk) 07:18, 21 November 2018 (UTC)
  • Neutral 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 Support Adithyak1997 (talk) 10:22, 24 November 2018 (UTC)
  • Support Support Arbnos (talk) 23:05, 24 November 2018 (UTC)
  • Support Support Victorgibby 03:04, 25 November 2018 (UTC)
  • Oppose Oppose IKhitron (talk) 19:40, 25 November 2018 (UTC)
  • Support Support — AfroThundr (u · t · c) 03:22, 26 November 2018 (UTC)

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

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

Provide a tool to efficiently analyze the usage of a template

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

Shared Multilingual Templates and Modules available to all wikis

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

Voting

  • Support Support Liuxinyu970226 (talk) 04:25, 17 November 2018 (UTC)
  • Support Support Rob Kam (talk) 10:02, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 11:25, 17 November 2018 (UTC)
  • Support Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:07, 17 November 2018 (UTC)
  • Support Support Naseweis520 (talk) 15:27, 17 November 2018 (UTC)
  • Support Support Theklan (talk) 18:15, 17 November 2018 (UTC)
  • Support Support Barcelona (talk) 19:00, 17 November 2018 (UTC)
  • Support Support Helder 20:42, 17 November 2018 (UTC)
  • Support Support Capankajsmilyo (talk) 00:01, 18 November 2018 (UTC)
  • Support Support Megalibrarygirl (talk) 02:27, 18 November 2018 (UTC)
  • Support Support Jon Harald Søby (talk) 12:38, 18 November 2018 (UTC)
  • Support Support JackPotte (talk) 22:16, 18 November 2018 (UTC)
  • Neutral 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 Support Shizhao (talk) 02:50, 19 November 2018 (UTC)
  • Support Support β16 - (talk) 13:55, 19 November 2018 (UTC)
  • Support Support Ghybu (talk) 02:14, 20 November 2018 (UTC)
  • Support 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 Support Gareth (talk) 16:20, 20 November 2018 (UTC)
  • Support Support Doc James (talk · contribs · email) 18:13, 20 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 01:35, 21 November 2018 (UTC)
  • Support Support JopkeB (talk) 09:14, 21 November 2018 (UTC)
  • Support Support JAn Dudík (talk) 09:11, 22 November 2018 (UTC)
  • Support 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 Support No such user (talk) 19:30, 22 November 2018 (UTC)
  • Support Support MisterSynergy (talk) 09:56, 23 November 2018 (UTC)
  • Support Support Sannita - not just another it.wiki sysop 00:49, 24 November 2018 (UTC)
  • Support Support Matěj Suchánek (talk) 09:12, 24 November 2018 (UTC)
  • Support Support Hmxhmx 11:15, 24 November 2018 (UTC)
  • Support Support Victorgibby 03:07, 25 November 2018 (UTC) La mejor propuesta de todas
  • Support Support IKhitron (talk) 19:38, 25 November 2018 (UTC)
  • Support Support Uanfala (talk) 23:34, 25 November 2018 (UTC)
  • Support Support — AfroThundr (u · t · c) 03:13, 26 November 2018 (UTC)
  • Support Support Ghilt (talk) 15:50, 26 November 2018 (UTC)
  • Support Support PMG (talk) 17:07, 26 November 2018 (UTC)
  • Support Support PJTraill (talk) 00:10, 27 November 2018 (UTC)
  • Support Support yeah, enough of broken templates and modules, especially lua ones Cohaf (talk) 00:12, 27 November 2018 (UTC)
  • Support Support Zache (talk) 14:10, 27 November 2018 (UTC)
  • Support Support --Nemo 22:36, 27 November 2018 (UTC)
  • Support Support Kpjas (talk) 10:24, 29 November 2018 (UTC)
  • Support Support Dumbassman (talk) 18:07, 29 November 2018 (UTC)

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)

"→" links to sections should be easier to click

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)
  • Am I (¿or my mouse?) so unusually advanced? I can click (or hover) on the arrow quite easily! But linking the grey text too seems eminently reasonable, if a few people want it. PJTraill (talk) 00:08, 27 November 2018 (UTC)
  • FYI, this is now implemented, as can be seen in the history page of the meta Forum for instance. Thanks to the Google Code-in student and his mentor Legoktm. —TheDJ (talkcontribs) 07:47, 29 November 2018 (UTC)
  • Note: User:Incnis Mrsi/short-section-links.js is a script (mostly) undoing this “improvement” which is currently online in several Wikimedia wikis, including Meta and Commons. Incnis Mrsi (talk) 12:11, 29 November 2018 (UTC)
  • Yet another confusing “improvement” targeted for people with glitchy touch-pads or poor eyesight, but pushing hundreds of clueless blue things into brains of everyone. Shouldn’t make its way into the core MediaWiki anyway. I’m immediately working on a script undoing this sea of hyperlinked waste introduced with 1.33/wmf.6. Incnis Mrsi (talk) 09:58, 29 November 2018 (UTC)
    Probably it could be solved in a better way, I'm a little bit disappointed as a proposer. --Dvorapa (talk) 11:53, 29 November 2018 (UTC)

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)