Community Wishlist Survey 2021/Miscellaneous

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Miscellaneous
30 proposals, 71 contributors
The proposal phase has ended.
Come back on December 8 at 18:00 UTC to vote on proposals!



Customizable sidebar

Edit proposal/discussion

  • Problem: Right now we have a "one size fits all" situation, where all users get the same sidebar menu. It doesn't matter if you are an occasional reader, a first-time contributor or a veteran with 15+ years of experience. For me (and probably many other long-time users) the sidebar is almost useless. To be quite honest there are only three positions in the sidebar of my homewiki that I sometimes use; I have to get to my "favorite" pages via the watchlist, search bar or URL bar in my browser. In my opinion users should be able to customize their own sidebars. Some might want to put there the articles they often check, some external links to often used references or tools, while some might prefer the default setting.
  • Who would benefit: Experienced users as they can have their workflow improved
  • Proposed solution: I'd have some ideas but don't know if any of them is good. I would see it as a Special Page (Special:Customize sidebar? Additional tab in Preferences?) because I don't think we can trust users to not break their sidebars if that was done in any other way (like creating own pages like MediaWiki:Sidebar). The special page can check if everything (or at least technical aspect) is okay with user's input. The special page could be a form that looks somewhat like this:
Customize your sidebar
Section: (Main) [buttons: create new, edit, remove] [checkbox: collapsible Y/N]
Link: [Text Input] Name to display: [Text Input] [Buttons: Edit Remove]
Link: [Text Input] Name: [Text Input] [Buttons: Edit Remove]
Of course everything done in OOUI, where you can drag and drop elements, with options to create new elements, edit them or whatever, decide whether or not to display the logo, etc. The "Tools" or other "page-specific" sections ("Print/export", "Languages") of the sidebar should not be customizable (so that users cannot break them).
  • More comments:
  • Phabricator tickets:
  • Proposer: tufor (talk) 22:04, 16 November 2020 (UTC)

Discussion

  • It's really easy to add and remove from sidebars using CSS and Javascript. This doesn't seem like a good investment. --Izno (talk) 22:46, 16 November 2020 (UTC)
    • It jumps and it is annoying. Also, not everyone can code in js. tufor (talk) 01:17, 17 November 2020 (UTC)
      • I understand "jump" but "not everyone can code in JS" is not a barrier. It's a single line of well-known Javascript to add a single item in the sidebar, and then just repeat for each item you want to add. --Izno (talk) 19:49, 17 November 2020 (UTC)
        • @Izno: If you don't mind, I am apparently out of the loop on this and am wondering if you can post or link to an example of the single line of well-known Javascript here. I want to have it so I can make such changes for myself and I think it would be good to have just for the purposes of record keeping and for helping others. —The Editor's Apprentice (talk) 19:33, 20 November 2020 (UTC)
  • I like this idea. I currently use my user page, in part, for useful links (and I know others do too), which would work much better as a proper menu, and would be really handy if it were accessible on any page (sidebar would be great). -EdGl (talk) 03:25, 17 November 2020 (UTC)
  • I like this idea. I can't write the code necessary to do this on my own and I, too, keep a list of things on my userpage that would, more usefully to me, be on the sidebar. Jessamyn (talk) 04:38, 17 November 2020 (UTC)
  • I have created a gadget for this on the Romanian Wikipedia: ro:Wikipedia:Unelte/Scripturi/Sidebar (sorry, no translation). You could probably use it in any wiki, although it requires non-trivial configuration. A nice Twinkle like control page could make it more useful.--Strainu (talk) 12:04, 17 November 2020 (UTC)
  • I like it. I never use the sidebar and I've been on Wikipedia for nearly 15 years. Livingston7 (talk) 16:06, 17 November 2020 (UTC)

Expand signature length

Edit proposal/discussion

  • Problem: The signature in Wikipedia is limited to some words. However, some users want a large signature consisting of more words. But they are bound to the short signature. I also faced the problem. And couldn't select my favourite signature due to its short length.
  • Who would benefit: Everyone
  • Proposed solution: Expand the length of signature to double or triple.
  • More comments: All above
  • Phabricator tickets:
  • Proposer: Empire AS (talk) 09:04, 30 November 2020 (UTC)

Discussion

  • Signatures are used to indicate authorship of comments, and they seem to work well for this purpose as they are. How would this proposal improve this? Silver hr (talk) 01:13, 1 December 2020 (UTC)
Although they work fine, I know. However, they should be a bit longer. Therefore, they must be expanded to a few more words or bytes. Thank you. Empire AS (talk) 09:59, 1 December 2020 (UTC)

Templates translation

Edit proposal/discussion

  • Problem: Some templates in different wikis have similar functionality, but it's unnecessarily difficult and time-consuming to copy them from one wiki to another.
  • Who would benefit: Volunteers who edit in more than one wiki and who copy, adapt, and translate information from one wiki to another.
  • Proposed solution: mw:Multilingual Templates and Modules work can be aid by task T243150, which will give users a tool (js-script maybe) which will do what Extension:ContentTranslation already can - translate templates.
  • More comments: There need to be some json on Commons or other way for users to translate parameters of templates and templates names. For citation templates there would be great if there would be possibility to implement some logic, like ru_author = en_last1 .. ", " .. en_first1 etc.
  • Phabricator tickets: task T243150
  • Proposer: Carn (talk) 11:19, 18 November 2020 (UTC)

Discussion

  • Amire80! Carn (talk) 11:24, 18 November 2020 (UTC)
  • A very, very, long-desired wish - if it can be done in a fashion that somehow avoids disrupting the larger local communities by bulking out the templates themselves or the lists of templates that would be a positive. While Abstract will eventually get round to some form of this, because it's a smaller component of their overarching plan, a more tailored project might be more beneficial Nosebagbear (talk) 15:13, 18 November 2020 (UTC)
    • Nosebagbear, I suggested a more tailored project at the section at the bottom: "Practical suggestion: refactor CX template adaptation". What do you think? --Amir E. Aharoni (talk) 13:43, 26 November 2020 (UTC)
  • This is very much in the high cost/high benefit category—it seems like a daunting task, but the savings in duplicated editor effort will make it worth it. I'm not sure if the community wishlist team would be able to take it on, though. {{u|Sdkb}}talk 02:57, 19 November 2020 (UTC)
    I updated a task, I think we can eat elephant part by part. Articles are not always translated entirely. Sometimes it is necessary to translate a single section, and it is convenient to do this by copying the wikitext. At the same time, templates are often found in wikitext on local languages. And it's good if these are english templates, there are often local analogues for them. In some wikis cite web analogues has "URL" and not "url" parameter name. Replacing template names and parameters can be automated.
    If users will have opportunity to insert analogs of parameter names themselves (I don’t know how best to do this, via wikidata or by filling in json tables), then data will be collected that can be used in the future directly for global templates. Carn (talk) 13:24, 19 November 2020 (UTC)
  • Complete infrastructure standardization/unification would be GREAT. And IMHO the EN wikipedia has the most complete and good standard. Making a scalable version of template (basic, rich, full) maybe a good solution for translations or for smaller audiences or countries. But using the SAME template could help a LOT the work of a global wikipedia. This is a standard in every kind of structured and collaborative work :) --Wikit2006 (talk) 22:06, 22 November 2020 (UTC)
  • See the big section I added after the "Discussion" section. If User:Carn agrees to these ideas, I recommend rephrasing the top as follows:
    • "Problem: Small or new wikis don't have template infrastructure. Old versions of templates that they copy from big wikis are not updated properly." -> This should be changed. This problem is very real and important, but the truly complete solution for this is doing the whole Global templates proposal, which is probably too big for the Community Tech team. It should be done, but at this stage, I recommend addressing a different, smaller problem: "Some templates in different wikis have similar functionality, but it's unnecessarily difficult and time-consuming to copy them from one wiki to another."
    • "Who would benefit: Volunteers editing templates and modules and users of small wikis." -> I recommend changing it to "Who would benefit: Volunteers who edit in more than one wiki and who copy, adapt, and translate information from one wiki to another."
    • The current proposal at the top says: "There need to be some json on Commons or other way for users to translate parameters of templates and templates names". In the big section I added, I explain my current proposal for how this will work. Very briefly, I recommend not changing anything at this point, but simply reuse the current algorithm in Content Translation, which is based on TemplateData, and making it available to more users. --Amir E. Aharoni (talk) 13:39, 26 November 2020 (UTC)
Admin from SqWiki here. Truth is small Wikis (like we are) rely mostly on EnWiki for everything. Most of our new articles come from CTT from EnWiki. Same is also true for technical things like templates, etc. In most cases, the workflow used to "create" a new template by a user is this: Starts to write something translating from EnWiki. -> Realizes a certain template is missing in SqWiki. -> Copy-pastes the template from EnWiki, importing it, usually without translating its components. -> Saves it as a template with the same name as in EnWiki, without a doc subpage and continues working on the page it was working with when the "template inconvenience" presented itself. 90% of our templates are with English names and without explanatory subpages (documentation) because of this process. They are not even connected on Wikidata, because people don't bother to do so. Actually that's where the untranslated title comes into help because you can search for it on EnWiki to read its documentation if you want to change something (and hopefully connect them on Wikidata). So anything that helps facilitate template importation and, hopefully, change the aforementioned workflow, is a very good thing to have. - Klein Muçi (talk) 12:01, 27 November 2020 (UTC)

Practical suggestion: refactor CX template adaptation

Taking a deep breath...

OK, so I'm in a strange conflict of interest here: I'm writing this as User:Amire80, a volunteer editor in several wikis, but I should mention that I'm also User:Aaharoni-WMF, a staff member of the Wikimedia Foundation, in the team that develops Content Translation, which is related to this project. I'm also the author of mw:Global templates and most of its subpages. With these disclaimers out of the way:

Global templates were already proposed in the Community wishlist in 2015, and came in at #3. On the results page it's listed as "in development", but it wasn't actually developed: it was, understandably, too big for the Community tech team, and it somehow slipped from the Parsing team plans, too. However, the wish is very much alive, and lots of people still think it's necessary (one example). So what can be done by the Community Tech team as a reasonable step towards making this come true?

The appropriate thing to do about templates translation in the context of Community Tech is to implement my suggestion in https://phabricator.wikimedia.org/T243150: build a Template adaptation service and the frontend for this service. Here's how it will work:

  1. Refactor the part of cxserver that adapts templates in Content Translation, so that it would be usable not just in Content Translation, but also in the wiki syntax editor and in Visual editor. (cxserver is a simple backend Node.js service that works together with Content Translation. One of its functions is template adaptation.)
  2. The technology for mapping template titles and parameter names doesn't change at this stage, and remains the same as in Content Translation / cxserver. The algorithm is as follows:
    1. If the template page in the source wiki is not linked to anything in the target wiki through a Wikidata sitelink, fail: "This template is not associated with any template in the target wiki".
    2. If the template page in the source wiki is linked to a template in the target wiki through a Wikidata sitelink, use the title of the target template for adaptation.
    3. Check whether the target template has TemplateData defined. If not, fail: "The target wiki does not have TemplateData".
    4. Check each parameter name in the transclusion and search for it in the target template's TemplateData:
      1. If there is a parameter with the same name, use it.
      2. If there is no parameter with the same name, but there is a parameter with the same alias, use the main name of that parameter.
      3. If nothing could be found in the previous two points, fail: "Parameter $1 couldn't be found in the target wiki" (replace $1 with the parameter name).
    5. The parameter values are copied as-is. Auto-adapting parameter values can be added in the future, but it's not a part of this proposal.
  3. There will be no functional change for end-users of Content Translatio n. The code from cxserver will be moved to a separate service, and Content Translation will just switch to using that service for template adaptation.
  4. Global template wiki syntax adaptation tool frontend, with empty fields
    Global template wiki syntax adaptation tool frontend, with input and output
    When editing in the 2010 wikitext editor, people will have a new button: "Adapt a template". This button will allow the following (see the mockups):
    1. The editor copies the wikitext of a template transclusion in another wiki. For example, a transclusion of {{Cite encyclopedia}}.
    2. The editor clicks the "Adapt a template" button in the toolbar. Clicking the button shows a dialog box. This dialog box has a selector for the source wiki, and two text fields: Source template and Target template. The "Source template" is editable, the Target template field is read-only.
    3. The editor selects the source wiki in the wiki selector, for example "English Wikipedia". The target wiki is the current wiki, in which the page is being edited.
    4. The editor pastes the template source to the top box.
    5. The box queries the template adaptation service.
    6. If the adaptation worked, the adapted template output is shown in the Target template field.
    7. If the adaptation failed, the reason for the failure is shown (see the "fail" points in the adaptation algorithm above).
  5. When editing on mobile devices, a similar dialog can be shown.
  6. When editing in Visual Editor, the template can be simply copied from one wiki and pasted in another. This will work similarly to copying and pasting wikitext and converting it to rendered HTML on the fly. When copying, the source wiki name will be stored in the clipboard. When pasting, VE will query the template adaptation service and try to adapt the template. If it fails, VE will show the reason.
  7. When editing in the 2017 wikitext editor, it will work similarly to VE, and the "Adapt a template" button can be available, too.

Why do I believe that it's a good task for Community Tech?

  • It's relatively small.
  • It doesn't change any deep algorithms, and only gives editors more convenient access to already-existing technologies.
  • It fits together well with existing editing tools, and once it's deployed it simply becomes a part of the editing workflow.
  • It adds a tool that is not specifically about languages and translation, but also about any cross-wiki activity. For example, copying a template transclusion from English Wikisource to the English Wikipedia is sometimes needed.
  • It's somewhat comparable to the TemplateWizard extension, on which the Community Tech team already worked in the past.
Template adaptation service flowchart. This proposal deals only with the API entry point, the gray process boxes, and the green result box. The blue boxes will be in a future project, but this project here is supposed to be forward-compatible with it.

Why develop it now? Why not wait for the start of the work on the Global templates repository? It's not certain when will the work on the Global templates repository begin, or whether it will begin at all. Whenever this happens, it will be a very large project. On the other hand, the template adaptation service proposed here is a much smaller project, and it will be immediately useful to editors in all editing interfaces: wikitext 2010, wikitext 2017, mobile, Visual editor, and Content translation.

Where does it fit in the bigger Global templates roadmap? If and when the full-fledged Global templates repository will become available, such a service will be needed. If this project is done, then it will already be mostly available! The service's API will remain the same, and using the global repository instead of local TemplateData will become a new branch in the algorithm. (See the attached flowchart.) All the client editors probably won't need any modification.

I hope it's useful. Other comments are welcome. --Amir E. Aharoni (talk) 13:29, 26 November 2020 (UTC)

The reason for delveoping it now is that it's needed now. I don't underant why its ushc as major problem, tho it might me if implemented at once for al; languages. DGG (talk) 10:27, 29 November 2020 (UTC)

  • @Amire80: If defining new variables in templates was possible, wouldn't this be just the matter of mapping $english_variable:={{{localized_parameter_name}}} and calling the en.wiki template within a localized wrapper template? Also, with local template variables some nested template code would be much more comprehensible. Ponor (talk) 08:19, 3 December 2020 (UTC)
    This assumes that English templates are some kind of a "main" version, which is tempting, but wrong. English is, indeed, the main source for translation for many languages, but not for all. Some wikis use other languages as the source for translating content or importing tools: Spanish, French, Russian, German, Polish, Indonesian, Chinese, and so on. In addition, "just [...] calling the en.wiki template" sounds easy, but actually it's quite difficult: Evidently, software developers have attempted to implement cross-wiki transclusion since 2004, and never managed to complete it. It will certainly be done some day, but it will have to be done in baby steps.
    More generally, the $english_variable:={{{localized_parameter_name}}} syntax you are proposing may be good, but it's new. Any new syntax will require much more development resources from the engineers, and much more adaptation effort from the template maintainers on the wikis. What I propose here doesn't add any new syntax, but uses the existing wiki markup and TemplateData. Even the adaptation algorithm that I propose is already implemented in the code of cxserver, and I only propose to refactor it so that it would be directly usable from all versions of the wiki syntax editor and the Visual editor (currently it's only usable from Content Translation).
    The smaller a project is, the likelier it is that it will actually be implemented and deployed. And later it can be extended :) --Amir E. Aharoni (talk) 08:36, 3 December 2020 (UTC)

Support more OSM relation types in Extension:Kartographer

Edit proposal/discussion

  • Problem: The Kartographer extension can only display OSM relations of type multipolygon, route, and boundary on maps. Other relations like waterway, superroute, network etc. can not be displayed.
  • Who would benefit: Readers and editors of wiki pages which can be improved with interactive maps displaying OSM relations which are now unsupported.
  • Proposed solution: Add support for more or ideally all OSM relation types in Kartographer. Especially waterway relations (typically rivers) and superroute relations (typically international routes) would be nice to display.
  • More comments: OpenStreetMap (OSM) have free geodata for most geographic features in many parts of the world. It can be a big help for many Wikipedia articles and Wikivoyage to have access to these data to generate interactive maps showing their topics.
  • Phabricator tickets: T156433
  • Proposer: Dipsacus fullonum (talk) 01:28, 21 November 2020 (UTC)

Discussion

  • Could that be added to the river-template? Automatically generated river maps, that's what I've been looking for for so long. I would vote for that. --Smarties (talk) 20:59, 22 November 2020 (UTC)
    Yes. Maps from OSM are used in many infoboxes on English Wikipedia. An example is wikipedia:Bundesautobahn 1. The infobox gets the map data for Bundesautobahn 1 from OpenStreetMap relation 9716761 which have type=route. If type=waterway was supported you could do the same for almost any river. --Dipsacus fullonum (talk) 22:16, 22 November 2020 (UTC)

Visual Translation Override

Edit proposal/discussion

  • Problem: Translation tool is only WYSIWYG, it should enable users to edit source at early phases as well, or at least enable a way to for an automated move of such article to their drafts
  • Who would benefit: Mostly Wikipedia Editors, those who are translating content to other Wikipedia Projects.
    • In these countries which use a way more customized templates, or have specific formatting requirements, that usually are not met by WYSIWYG translator.
    • Also, it would be beneficial to users who currently use workaround by working on source in drafts.
    • Project overall, as this automation will accelerate progress and improve engagement of such translators.
  • Proposed solution:

While browsing articles in English Wikipedia, we are encouraged to create translations to languages which don't have that article yet. (E.g. in case the article for our language is not present, the language is grayed out at the languages list).

While creating articles in a different language than English, the visual editor/translator (WYSIWYG) is run by default, (the popup: "This page does not exist in polski yet. Do you want to create it?").

Popup with just one big blue button, that takes users to WYSIWYG

Solution consists of a workflow and adding of a small link beneath the big blue button. User by clicking it gets the article created in own drafts DIRECTLY, with source edit flawlessly being opened.


Other possibility, just to add source code preview at visual translator stage. I bet there exists number of users who will prefer to be able to edit code, at the incredibly early stage of article.

Now, many users must use following workaround: start a newly translated article, then they move the article to their drafts, and then edit its source there. I think possibility to automate this behavior, introducing a small link for that under the blue button, taking user to user's drafts so they can already work on source in their drafts space, will benefit in engagement, and allow to grow drafts more. Thank you!

  • More comments:
  • Phabricator tickets:
  • Proposer: Poland B (talk) 18:33, 18 November 2020 (UTC)

Discussion

WikiMaps - a proprietary tool for map editing

Edit proposal/discussion

  • Problem:

For the presentation of maps we use static, ready composed images. Editing and uploading vector graphics, variants, language versions, generates a lot of data rubbish. We do not understand maps like articles that can be edited in detail and where even small edits have to be justified. There is no intelligent discourse about boundaries and there is no database of information from which aspects can be added or hidden depending on the article area. The huge amount of work that is put into the maps could be used in a much more meaningful and sustainable way. But for this we need a completely new tool that helps us to understand maps like Wiki articles. This would lead to maps that also have a recognizable global style.

  • Who would benefit:

Simply put: everyone, except those who would have to implement the whole thing.

  • Proposed solution:

Objective: I would like to select maps for an article from a special map archive. Enter a period of time in this archive, select a section on a world map with the mouse. In the search mask I can search for information available for this temporal and spatial section and add it. For example, I can also select country and district boundaries, places with 100,000 inhabitants or more and the distribution of forests and finaly the information of a certain battle. The archive gives me a code which I simply insert into my article in Wikipedia. Summarised: I would like to be able to compose a map from layers of information.

Implementation: Every piece of information such as area or points of a border would have to be stored in a geo-referenced form. These would be assigned a period of time for which this boundary applies. In addition, further parameters would be added, such as the type of boundary or the subject area to which the information belongs. Each entry (like a boundary) is to be understood as a Wiki article in its own right. The exact course of the border can be debated on discussion pages, and sources can or must also be cited.

  • More comments:

Disadvantage: Such a project is a huge amount of work for some people. And that is a strong trivialisation.

Some Advantages:

  1. The work of the users would have a much much greater value. No entry would be wasted, nothing would be lost.
  2. Users could work together on geo-referencing.
  3. With Wikidata we already have the perfect tool to implement the project.
  4. With OSM we have map material that we can use as a resource.
  5. With georeferenced maps, you also have all the freedom you need. Not only two-dimensional maps can be output, but also three-dimensional ones.
  6. Furthermore, gifs or videos can be used to show the historical changes.
  7. Even tectonic and climatic changes could easily be depicted and displayed as gif.
  8. All linguistic aspects would be solved.

Objections: It is always said that there are other projects like OSM who are responsible for such endeavour. However, OSM has a completely different approach than my proposal, has no historical component and is far less effective in daily use. The reality is that we create our own maps and they are static, uncheckable and uncollaborative. There are projects here and there on the internet to georeference historical maps. But these projects regularly fail or cannot provide a tool to edit and debate borderlines in detail. Furthermore, the source of these maps is, politely put, critical.

  • Phabricator tickets:
  • Proposer: N3MO (talk) 04:42, 21 November 2020 (UTC)

Discussion

I think this is done, N3MO, using OSM's database. See, for instance, the source of en:Ōnawe Peninsula. My understanding is that OSM is developing historical dimensions. I'd certainly support more collaboration there; I think we have a lot to learn from OSM when it comes to collaborative databases. Since OSM's data is copyleft, and Wikidata still can't take any license but CC0, we can't use OSM data on Wikidata, and I do not think that duplicating that datagathering effort would be good. Duplicating the effort of making map-editing interfaces would also not be good. HLHJ (talk) 02:01, 24 November 2020 (UTC)

Add a Quick Settings Panel/Page

Edit proposal/discussion

  • Problem: In order to change simple settings, you have to navigate through a fairly lengthy Preferences section with many pages.
  • Who would benefit: Readers (as in, people who come just to read, not to edit), less experienced editors, anyone who frequently changes a setting.
  • Proposed solution: I propose that their should be a sort of quick setting panel or page, one that is very straight forward and simple for just a regular, non-techsavvy person to do simple things, such as change font size, time, appearance, language, I don't really know, just whatever the most changed settings are. It would be very clean and simple, and maybe even customizable for logged in users to include a few of their favorite settings, but that last part isn't the main point. The main point is making it very easy for the average reader to change a simple setting.
  • More comments:
  • Phabricator tickets:
  • Proposer: Thanks, EDG 543 (message me) 15:52, 17 November 2020 (UTC)

Discussion

Why would one frequently change a setting? Which settings would one frequently change? · · · Peter (Southwood) (talk): 07:23, 22 November 2020 (UTC)

Pbsouthwood, well, it's not so much that the individual would need to change the setting over and over, I just was referring to a setting that any random user (non-editor) would likely want to change but couldn't because of there is no easy way for them to change it. I don't really know which specific setting the average reader would want to change, but it wouldn't be hard to conduct a survey or something. Thanks, EDG 543 (message me) 14:43, 30 November 2020 (UTC)
EDG 543, Thank you for clarifying. It would appear that the first step would be to establish a need and the settings that would be involved. Cheers, · · · Peter (Southwood) (talk): 06:00, 1 December 2020 (UTC)

Consertar o bug do tradutor de conteúdo

Edit proposal/discussion

  • Problema: Há um bug do tradutor de conteúdo que rola a tela toda a vez que alguma coisa é digitado. Esse bug faz a tradução ficar irritante e quase que impossibilita a tradução rápida que é prometida.
    • There is a bug in the content translator that scrolls the screen every time something is typed. This bug makes the translation annoying and almost makes the quick translation that is promised impossible.
  • Quem beneficiaria: Todos os usuários que usam o tradutor de conteúdo.
    • All users using the content translator.
  • Solução proposta: Consertar o bug, o que teria como efeito o não rolamento da tela.
    • Fix the bug, which would have the effect of not rolling the screen.
  • Mais comentários:
  • Pedidos no Phabricator:
  • Proponente: Paz e concórdia (talk) 11:13, 17 November 2020 (UTC)

Discussão

  • I wonder what browser you are using. Firefox, especially on mobile, has had some issues like this. --Izno (talk) 17:20, 20 November 2020 (UTC)
  • @Paz e concórdia: Qual navegador, versão do navegador e dispositivo você está usando? MusikAnimal (WMF) (talk) 05:56, 1 December 2020 (UTC)
  • @MusikAnimal: I translate using Microsoft Edge and Chrome. You work with WMF. Will you fix the bug? Thank you. Paz e concórdia (talk) 11:25, 1 December 2020 (UTC)

Make deleted edits visible to their author

Edit proposal/discussion

  • Problem: Make the deleted edits visible to its author. Deleted edits are restricted to admins and checkusers. I think that a user should be able to see his/her deleted edits not of others.
  • Who would benefit: All users who would like to see their deleted edits
  • Proposed solution: Just make the edits visible to their authors.
  • More comments: All above.
  • Phabricator tickets:
  • Proposer: Empire AS (talk) 07:01, 22 November 2020 (UTC)

Discussion

There should be some security problems, but at least I would like to see titles of deleted pages I had edited - useful eg in commons - according to name I can search it in log and maybe made new upload with correct licence. JAn Dudík (talk) 09:43, 23 November 2020 (UTC)

I think that there would be no problems regarding security. A user should be able to see only his/her edits, not of others. So, in future, he/she might stop the increase in his deleted edits. Empire AS (talk) 11:42, 23 November 2020 (UTC)
No. This will let people just posting their deleted spam / defamatory posts / vandalisms/ hoaxs etc more easier w/o the need to keep it somewhere else. Camouflaged Mirage (talk) 11:53, 23 November 2020 (UTC)

Put the pages in my language automatically

Edit proposal/discussion

  • Problem: In Mediawiki, Meta, and the help pages of Commons and Wikidata have a menu to change the language. The pages are by default in English.
  • Who would benefit: Each user who reads these pages and does not know English.
  • Proposed solution: Redirect automatically all pages in the language selected in the preferences.
  • More comments:
  • Phabricator tickets:
  • Proposer: USI2020 (talk) 11:16, 29 November 2020 (UTC)

Discussion

MediaWiki message delivery must consider order of messages

Edit proposal/discussion

  • Problem: In different projects and even on different pages of the same project, a different order of adding new messages is often adopted: somewhere they need to be added at the top, and somewhere at the bottom. User:MediaWiki message delivery completely ignores this order. In large projects, this leads to the fact that the message needs to be moved to the beginning of the page each time. In small projects, no one pays attention to this, and on forums where messages should be added at the top, no one reads mass messages at the bottom of the page, and they just go to the archive.
  • Who would benefit: All projects. Mostly small projects that do not have the resources to fight bots.
  • Proposed solution: It should be possible to indicate in the list of message recipients that new messages should be added at the top. Alternative solution: add the magic word like __TOPNEWSECTIONLINK__, which will affect not only the bot, but other scripts too.
  • More comments:
  • Phabricator tickets:
  • Proposer: — putnik 05:57, 17 November 2020 (UTC)

Discussion

  • I mean, this is an improvement, but it's not an improvement I would vote for. --Izno (talk) 04:37, 18 November 2020 (UTC)
  • The fundamental problem here is that messaging/discussion on WM projects uses the utterly inadequate tool of wiki pages. If we had actual proper tools for messaging and discussion, this problem would not exist. (And it's not like the tools don't exist in the wider world--forum software has existed for decades now.) Silver hr (talk) 01:04, 1 December 2020 (UTC)

Social interaction

Edit proposal/discussion

  • Problem: Nowadays it is common for digital natives to like, comment, rate and share content. These forms of interaction are essential for motivating people to contribute content on the Internet. But apart from the "thank you" function, there are no features in the Wikimedia projects that enable contemporary social interaction and feedback about content.
  • Who would benefit: People who feel motivated by likes, comments and sharing functions to contribute content.
  • Proposed solution: Which functions might be possible and useful would have to be discussed. The following functions could e.g. be considered:
    • A share button with which articles and multimedia files can be shared via email, messenger or in social media etc.
    • A like button for articles and multimedia files
    • A comment function for multimedia files that can be used to give personal comments on the content (in addition to the discussion page, which is used to improve the content).
  • More comments:
  • Phabricator tickets:
  • Proposer: Nicor (talk) 20:18, 24 November 2020 (UTC)

Discussion

Isn't this the purpose of user talk pages? :) In addition, Wikimedia projects are not social media sites, so I am not a big fan of adding functions that turn Wikimedia sites more social media site-like. Share buttons (provided by social networking sites) are also a privacy concern (read nightmare) to me. H78c67c (talk) 02:29, 25 November 2020 (UTC)

  • Your claim that "These forms of interaction are essential for motivating people to contribute content on the Internet" might be true for some web sites, such as Instagram. However, Wikipedia has had huge amounts of contribution from a huge number of people without the features you listed, so clearly they are not needed for motivating people to keep contributing to Wikipedia. For me personally, these features would just add noise. Silver hr (talk) 00:45, 1 December 2020 (UTC)

Input Forms

Edit proposal/discussion

  • Problem: Currently, many Wikipedia processes require users to fill out information. This range from edit requests to edit filter reports to all sorts of nominations. The current solution is usually using preload templates, asking users to fill in details as template parameters. This can be very confusing to users unfamiliar with the template syntax, especially newcomers. “What does <!-- —>mean? Where do I fill in the page title?” some users may try to figure out how the seemingly baffling template syntax works, but most would probably give up, frustrated.
  • Who would benefit: Newcomers who have little understanding of template syntax and experienced users who could address the newcomers' issue more easily
  • Proposed solution: I could think of 2 ways to solve this. First way is an overhaul of the InputBox extension, allowing the creation of forms with multiple text fields and, if possible, even other controls (switches, checkboxes, etc.) The second way may be a gadget that displays an intuitive input form to users, in which the form is constructed by reading, for example, a JSON containing the form structure.
  • More comments:
  • Phabricator tickets:
  • Proposer: H78c67c (talk) 07:11, 17 November 2020 (UTC)

Discussion

  • Seconded. Keepcalmandchill (talk) 11:05, 17 November 2020 (UTC)
  • I think the Page Forms extension was written for this. Maybe it only needs some work to be available on Wikimedia wikis as well? --Matěj Suchánek (talk) 16:58, 17 November 2020 (UTC)
    @Matěj Suchánek: from what I can tell, not exactly. The Page Forms extension is for creating or editing pages with structural data, including those inside templates, which is already partially achieved with VisualEditor and TemplateData. What I am proposing is almost like InputBox, but with support for multiple form inputs, not just one. Please correct me regarding the Page Forms part if I am wrong. H78c67c (talk) 06:50, 18 November 2020 (UTC)
    You are maybe right. Sorry, but I am not that much familiar with Page Forms. In fact, I recalled a comment from this my task (which would benefit from this proposal, right?) but that comment mentions a tool called "FormWizard". --Matěj Suchánek (talk) 11:10, 18 November 2020 (UTC)
    mw:Extension:FormWizard is almost exactly what I’m looking for! I wonder what needs to be done to install it on WMF wikis. H78c67c (talk) 15:39, 18 November 2020 (UTC)

Use sitelinks to link to Commons in the Wikipedia sidebar

Edit proposal/discussion

  • Problem: At the moment the link to Commons in the sidebars on Wikipedias and other projects is generated using the P373 ('commons category') property on Wikidata where there isn't a sitelink directly in the linked Wikidata item. P373 is frequently outdated and easy to vandalise, however, and using the sitelinks is a better way to provide the link (in particular, it is bi-directional and provides the links from Commons to the Wikipedias, and it is difficult to vandalise). Where there is a category for a topic, though, the Commons category sitelink is stored there rather than in the topic item, and does not get displayed without a P373 value. (For more background, see d:User:Mike Peel/Commons linking).
  • Who would benefit: Readers and editors going to Commons from Wikipedia articles
  • Proposed solution: The code should be updated to
  1. If there is a sitelink to Commons in the attached Wikidata item, use that (optional: unless it is to a gallery page)
  2. If there is a P910 ('topic's main category') value, follow that to the category item and use the sitelink to Commons from there
  3. If there is a P1754 ('category related to list') value, follow that to the category item and use the sitelink to Commons from there
  4. Otherwise, display nothing.
  • More comments: This is probably a straightforward change to implement, and it is an important step towards deleting P373, however it has been stuck on phabricator for over a year.
  • Phabricator tickets: phab:T232927
  • Proposer: Mike Peel (talk) 11:11, 27 November 2020 (UTC)

Discussion

Show all active sessions

Edit proposal/discussion

  • Problem: Sometimes we can forget to log out when using an other device than usually thus making it possible that someone can use your account.
  • Who would benefit: all users
  • Proposed solution: Create "active sessions" special page and let users to remove sessions they don't want to keep active. Similar like in Google/Facebook etc.
  • More comments:
  • Phabricator tickets: T58212
  • Proposer: Stryn (talk) 11:22, 17 November 2020 (UTC)

Discussion

  • This seems like it could be a big security improvement. I wonder what the common use cases would be. My first thought was that I know a significant number of editors work from library computers - I'd be interested in people's experiences of whether Wikimedia login sessions persist on library computers or get logged out by default. — Bilorv (talk) 19:38, 17 November 2020 (UTC)
  • I know we aren't voting now, but I think that's a great idea. I have a shared computer that I sometimes use when my personal computer is unavailable and my phone doesn't make the cut. I wouldn't want my young, mischievous siblings using my account. The security of everyone's account would be improved as well. You could easily see if someone were in your account, and could change your password accordingly if necessary. Thanks, EDG 543 (message me) 01:38, 18 November 2020 (UTC)
  • If nothing else, the ability to view a simple count of active sessions (or sometimes "sessions other than the current one"), along with the ability to log out all additional active sessions other than the currently-active one, is kind of the bare-minimum for account-management features in federated authentication systems of similar scale/scope to Wikimedia's. Gravy on top would be the ability to see when each session was last active, where each session was logged in from (either geolocation, network topology, OS / browser fingerprinting, etc.) and the ability to disconnect individual sessions instead of having no option other than the nuclear one. -- FeRDNYC (talk) 00:54, 24 November 2020 (UTC)

Allow sanitized-CSS to use pointer-events

Edit proposal/discussion

  • Problem: Currently sanitized-CSS does not support pointer-events.
  • Who would benefit: Sanitized-CSS users
  • Proposed solution: As indicated by the title
  • More comments:
  • Phabricator tickets:
  • Proposer: Pseudo Classes (talk) 05:26, 19 November 2020 (UTC)

Discussion

@Pseudo Classes: I haven't looked into this, but this might be intentional, as it might not be desirable to fake certain pointer events and it might be used in situations of phising or something. Please make a better Problem description of where and how you would use this pointer-events (examples), so that the usefulness and risk can be eveluated. —TheDJ (talkcontribs) 11:01, 20 November 2020 (UTC)
@TheDJ: Sorry, I’m not sure I understand. Why pointer-events property might be abused? Pseudo Classes (talk) 02:49, 21 November 2020 (UTC)
K. checked. the reason why pointer-events is not supported, is because it is CSS that is part of the SVG2 module which is not included in the sanitizer right now. It will also be added to the upcoming CSS level 4, but the sanitizer only supports Level 3. —TheDJ (talkcontribs) 12:21, 21 November 2020 (UTC)

Improve pdf outprints

Edit proposal/discussion

  • Problem: PDF does not work anymore
  • Who would benefit: Anyone who wants to use wiki in printed form
  • Proposed solution: Make PDF possible again. In older times there were two versions: text in one column including tables and text in two columns excluding tables. It would be desirable if the text could come in two columns and including tables as well as images in a suitable format (eg image (s) with text next to it in full page width). This would make the printout more "professional" in its design.

On the same occasion, the text should be corrected so that text arranged in list form (with numbers or hyphens) gets the same form as other running text (which was not the case before).

It is desirable if it becomes possible to edit a pdf layout and update the appearance until it gets the desired look prior to printing.

  • More comments: Not all people are computer geniuses, so the possibility to the ability to edit the text should be fairly simple to understand.
  • Phabricator tickets:
  • Proposer: Sven Halfdan Nielsen (talk) 07:19, 17 November 2020 (UTC)

Discussion

Comment Comment It's possible to download PDF with Chrome, but not for Firefox. We need also to do a review of this. I'm not sure if it's the same problem or one different, but apparently are related. --Ganímedes (talk) 09:48, 17 November 2020 (UTC)

@Ganímedes: can you elaborate ? It works just fine for me. —TheDJ (talkcontribs) 11:45, 17 November 2020 (UTC)

Comment Comment I'm a teacher, I sometimes use wikibooks with my students and this could be an important improvement, because they often need a good print version in order to follow properly the activities during the lesson in class. The majority of students don't have digital devices so a good print would help a lot.--AGeremia (talk) 11:04, 17 November 2020 (UTC)

@AGeremia: I would file a separate request for book rendering to PDF, as this also requires combining multiple wikitext pages into a single document, which is a complex procedure with much additional logic. Please do file that as a separate request. —TheDJ (talkcontribs) 11:45, 17 November 2020 (UTC)

Comment Comment @Sven Halfdan Nielsen: "Make PDF possible again". PDF already is possible, most wikis have a "Download as PDF" link right in the left column. Can you be more specific perhaps about where and when it does not work for you ? I also see you'd with additional layout options, which seems like a separate request from 'make pdf possible again".. —TheDJ (talkcontribs) 11:45, 17 November 2020 (UTC)

Comment CommentPDF versions could be a good choice if they did not release author private information. For more information, read this page at Wikimedia. --Doostdar (talk) 14:03, 20 November 2020 (UTC)

Make signature global

Edit proposal/discussion

  • Problem: After a username change all self created signatures become invalid
  • Who would benefit: All users who got name changed
  • Proposed solution: make signature global so only once the signature needs to be updated and not on all projects
  • More comments: another option might be to change the app/procedure used for user rename, but that might be a tad more complicated
  • Phabricator tickets: T188200
  • Proposer:  Klaas `Z4␟` V:  22:05, 20 November 2020 (UTC)

Discussion

  • A lot of signatures contain language specific portions like (talk) and thus can't be global. ChristianKl❫ 13:55, 24 November 2020 (UTC)
    The (talk) part can be solved by using {{int:Talkpagelinktext}} instead, just like how Wikidata does. H78c67c (talk) 02:21, 25 November 2020 (UTC)

Add filters to history pages

Edit proposal/discussion

  • Problem: On some of the high traffic pages, due to volume of activity, it is difficult to identify true authors or find other editing patterns.
  • Who would benefit: Admins and editors investigating page histories.
  • Proposed solution: Add ability to filter/sort page histories, by for example:
    • Show/hide IP edits
    • Show/hide reverted edits and their reverts
    • Show/hide banned user edits
    • Show/hide bot edits
    • Show/hide minor edits
    • Show/hide/sort edits by number of bytes added/subtracted
    • Show/hide my edits
    • Sort edits by IP/username
    • Show/hide selected user's edits (if this is deemed uncontroversial)
    • Show/hide deleted edits (for administrators only?)
  • More comments: Reposting from 2017 survey
  • Phabricator tickets: T18619, T97020
  • Proposer: Renata3 (talk) 02:38, 17 November 2020 (UTC)

Discussion

  • Seconded. It could be helpful. --Piotrus (talk) 04:49, 17 November 2020 (UTC)
  • Yes, this would be useful. I can't imagine controversy in showing/hiding edits by a specific user as this tool to list edits on a page by a user is linked in the page history on the English Wikipedia, and I believe runs on any Wikimedia project. — Bilorv (talk) 19:32, 17 November 2020 (UTC)
  • Very helpful :D HeartGlow30797 (talk) 14:35, 22 November 2020 (UTC)

Unify Preferences and Global Preferences

Edit proposal/discussion

  • Problem: Right now we have Special:GlobalPreferences and Special:Preferences for each wiki. While Global Preferences does not include the Gadgets section, rest settings are duplicated in both of them. Global Preferences are very confusing and the system of having Preferences for each wiki with having Global Preferences is confusing.
  • Who would benefit: All users.
  • Proposed solution: Best solution could be to unify them and label it Global Preferences or Preferences and Gadgets section could be single searchable place per Community Wishlist Survey 2021/Bots and gadgets/Add more gadgets to Preferences/Gadgets or gadget page could change according to where user open new preferences. It will also make Global Preferences less confusing and simplify the overall user preferences system.
  • More comments:
  • Phabricator tickets: phab:T188424, phab:T174521, [1]
  • Proposer: ‐‐1997kB (talk) 10:20, 17 November 2020 (UTC)

Discussion

  • Some users want to have some different preferences across all Wikimedia projects. The signature setting is the most important here, I guess, because user signatures typically contain a link to the talk page of the signer and it is good if the link can be translated. For example, I use “PiotrekDDYSKUSJA” on pl.wikt, but would like to use “PiotrekDTALK” here or on en.wikt. (Actually, I have just set it here.) PiotrekDTALK 21:33, 17 November 2020 (UTC)
There's already a task to add signatures in global preferences, but as you said some people want different signature for different wikis, there can be an option to apply A sign on X, Y, Z wikis and B sign on others. All I'm trying to say is that having one place for all user preferences is much preferred than 700+ different preferences. ‐‐1997kB (talk) 06:40, 20 November 2020 (UTC)
  • I don't think they should be unified, instead, we should simply flick the default for new users who never know about, nor would care very much about the fact that you can have local preferences. —TheDJ (talkcontribs) 10:53, 20 November 2020 (UTC)
  • While this product was being built, I told the team the design was horribly backwards. The current design theoretically provides the needed functionality, but in reality it is almost unusable. It is particularly unhelpful for new users. If this project is taken up you can ping me and I'm happy to discuss details. In short here is my suggested userstory:
    1. A new user finds their way to the Preferences for the first time. They look for, find, and change a setting. They expect this change to apply globally (which is what it should do). This is the primary and basic use-case. The user likely returns to this use case many times before encountering the next use case.
    2. The user becomes more experienced, more sophisticated, their needs become more sophisticated. They realize they want/need a different preference-value for something on this particular wiki. They either click a special option displayed next to the preference, or they enter some more advanced mode, and they create a LOCAL override for this preference. The user can then change the local setting, which only applies on the current wiki.
    3. When the user returns to the preference panel they see all active preferences. Most preferences display the GLOBAL setting for simple direct editing, but where a LOCAL override exists then the LOCAL value is displayed for simple direct editing. (The local-value-display directly replaces the global-value-display, and the UI uses a colored-background or other styling to highlight that a LOCAL preference is displayed in this slot.)
I considered writing comparison Story for a user attempting to use the current interface, but it would be long and ugly as the user repeatedly runs into problems.
P.S. I am not thrilled with consuming another Community tech slot to complete a project was abandoned in an almost unusable state. Alsee (talk) 10:05, 21 November 2020 (UTC)

Interactive article editing view tool

Edit proposal/discussion

  • Problem: Sometimes I look up at an article with improvement intention, and see parts of it which are very specific, so I wouldn't need to look all the page's history to find who made that line or fragment.
  • Who would benefit: Everyone who wants to check article edits quickly, and then to edit on them, instead of seeing all the history comparisons.
  • Proposed solution: I propose a new tool, that as the Visual Editing does, has an interface which leads to the editor a direct interaction with the normal article view screen. The thing goes like this:
    • The editor presses the button to open the tool interface.
    • In that interface, the editor is able to click or simply pass by the cursor around the text shown in the article, and then suddenly bringing information about the date a line or related has been last changed, edited, or written. This is basically the history data.
  • More comments: There is no need to go deep into the design part. But a easy way to represent this is by selecting the part of the article you want, and maintaining it in a box, of which the data appears.
  • Phabricator tickets:
  • Proposer: De un millón (talk) 22:50, 20 November 2020 (UTC)

Discussion

  • @De un millón: This exists! Allow me to present to you... Who Wrote That?. This was built by Community Tech in response to the #4 wish on the 2017 survey. It is available as a browser extension. Only a handful of wikis are supported, but I see Spanish Wikipedia is your home wiki, which is supported. Does this work for you? If the browser extension is not satisfactory, you could revise your proposal to turn it into a gadget. I think that would be fine. Or, if there are other Wikipedias you would like to be added, that might make for a good proposal too. Unfortunately we can't add every wiki/language, at least not in the short-term. Let me know what you think! Regards, MusikAnimal (WMF) (talk) 23:06, 20 November 2020 (UTC)
@MusikAnimal (WMF):I have read the tool overview, but I don't understand why it isn't allowed in mobile devices, wondering it in a general sense; maybe it's due to a format trouble or a storage saturation (perhaps, because the computer/desktop view is faster and more confident).
If there aren't any problems at all, then why not? (At least it should be made to the APP) Regards, --De un millón (talk) 01:04, 21 November 2020 (UTC)
@De un millón Extensions for mobile browsers aren't a thing (yet). I can't seem to find a Phabricator task, but I do recall the one of the mobile teams talking about adding Who Wrote That? functionality into the app, so that might be in our future. At any rate, as written this proposal is for something we already built. Would you like to reword it to be about making Who Wrote That? work on mobile, and/or a gadget (if it's a gadget, you can load it in your own Minerva.js)? MusikAnimal (WMF) (talk) 21:18, 23 November 2020 (UTC)
On open-source mobile phones, extensions to mobile browsers are in beta last I heard. I would like a non-browser-dependent version of this, tho. HLHJ (talk) 02:33, 24 November 2020 (UTC)
Actually extensions are a thing for mobile browsers. Firefox v78+ supports only a handful of manually picked extensions, but v68 and before had quite well WebExtensions support; Samsung Internet allows installing browser extensions from Galaxy Store (developers need to join a closed beta); Kiwi Browser allows installing directly from Chrome Web Store; and so on. When Who Wrote That? was developed, Firefox still supported WebExtensions, so it would have been a question of ticking a checkbox to release it on mobile; it was not because of no extension support that it wasn’t released for mobile. It was rather because the current design of the tool simply doesn’t work on touchscreen devices—it shows data on hover, which is not really a thing with touchscreen, and the developers were not willing (so far) to redesign the whole thing. Maybe convert this wish to ask WWT specifically for mobile, and see how it goes? —Tacsipacsi (talk) 23:34, 25 November 2020 (UTC)

Make CentralAuth extension to log actions everywhere

Edit proposal/discussion

  • Problem: The CentralAuth extension doesn't log some actions on every wiki but just the wiki from where the action was performed (for Wikimedia, It's Meta-Wiki). This also makes us to have a local Steward and a local Global Renamer user group on Meta to keep the logs on Meta. If someone wants to see the logs then they will have to visit Meta-Wiki, this is really annoying. List of logs:
· Special:Log/gblblock (globalblock), You can't see logs of global IP blocks from wikis other than Meta.
· Special:Log/globalauth/Special:CentralAuth (centralauth-lock), You can't see logs of global account locks/unlocks and hide/unhide (private, only shown to users with centralauth-lock) from wikis other than Meta.
· Special:Log/gblrename (centralauth-rename), You can't see logs of global account renames from wikis other than Meta, You can see log entry at Special:Log/renameuser only if the account is locally created.
· Special:Log/gblrights (globalgroupmembership/globalgrouppermissions), You can't see logs of global user rights and global group management changes from wikis other than Meta.
  • Who would benefit: Everyone
  • Proposed solution: Make CentralAuth extension to log actions everywhere. Some third-party sites who use CentralAuth may don't want this, so add option to disable it.
  • More comments:
  • Phabricator tickets:
  • Proposer: CptViraj (talk) 05:32, 17 November 2020 (UTC)

Discussion

Display default/recommended values at Special:Preferences

Edit proposal/discussion

  • Problem: At Special:Preferences, it's impossible to know which settings you have changed away from the default (or have acquired a new default value since you signed up) without doing a full reset.
  • Who would benefit: All editors who like to customize their settings, and particularly longer-term editors who may not be aware that some settings have acquired new default values.
  • Proposed solution: Show some kind of default indicator, as mocked up by Quiddity.
  • More comments: This was discussed at en-WP at Wikipedia:Village pump (proposals)#Clearly display each Default setting at Special:Preferences and received clear support.
  • Phabricator tickets: task T70689
  • Proposer: {{u|Sdkb}}talk 03:03, 17 November 2020 (UTC) (but really mostly Nick Moyes, who put forward the Village pump discussion, and Quiddity)

Discussion

Bring back PDF book rendering

Edit proposal/discussion

  • Problem: PDF book rendering has been "ŧurned off for a short term in September 2017" but never brought back. It was an useful feature.
  • Who would benefit: Anynone wanting to collect pages into a book and then download PDF for printing.
  • Proposed solution: Get PDF book rendering back to life. We know it's doable. Maybe it's a lot work, but it would be so nice to have this feature back!
  • More comments:
  • Phabricator tickets:
  • Proposer: Tchoř (talk) 16:33, 25 November 2020 (UTC)

Discussion

Kartographer icon improvements

Edit proposal/discussion

Icons urgently needed for Wikimedia maps
Some icons currently available, but of little use to Wikimedia maps
Currently, a skyscraper is an office, a capitol building is a town hall, a hotel is a bed, a church is a cross, and banks are credit cards?
  • Problem: There is no one clear set of icons dedicated to Wikimedia maps. Three things need to happen – (1) an established set of icons particular to Wikimedia mapping needs, (2) the rewriting needed in order to add this set of icons, and (3) better support to more easily add and modify icons in the future.
  • Background: Kartographer-based Mapframe maps work wonders to easily show maps in Wikipedia infoboxes and beyond. However the mapping tool really suffers from a lack of identifying icons. Especially for maps that show numerous features, editors are having to be creative to come up with icons that just barely associate with their topics. This is because MediaWiki uses an obsolete version of Maki icons, but even that still wouldn't fix all the problems relevant to Wikimedia spaces. The Maki icon set was designed for maps, though not for Wikimedia. Therefore it has numerous icons useless to Wikimedia spaces, and lacks icons essential to mapping here. There are at least 11 unclear icons, and at least 47 missing icons key to mapping here.
Other problems include, for accessibility, making more options for legibility. Right now, icons only display white. Icons should be able to be at least colored black, if not more colors, for increased contrast when the marker color is set to a lighter color. Markers should also have options for shapes other than the default teardrop shape, to allow for differentiation when using grayscale maps and for people with low color recognition (see task T131618).
  • Who would benefit: Innumerous Wikimedia spaces, primarily Wikipedia and Wikivoyage, but including numerous unique projects like Wiki Loves Monuments and Wiki Loves Earth, which need good mapping.
  • Proposed solution: Developing an additional entirely new set of icons, including many of the below missing or unclear examples:
Part one: coding
  • Code to allow for easy icon additions and improvements. This needs to happen now, and likely as Kartographer becomes more widespread on WMF projects, future changes will be necessary.
Part two: icon/marker formatting
  • Icons, currently only available in white, should be available at least in black as well, for increased contrast when marker-color is set to a light color
  • Markers should have more shape options behind the tear-drop shape.
Part three: fixing unclear icons
Part four: adding missing icons
  • More comments: The above set of icons proposed are only ones I have found immediately relevant; others in the current Maki set or elsewhere may prove to be as well. Careful care needs to be taken to ensure a non-Western view, as some instances of map icon bias have already been pointed out.
How this should best be solved needs investigation, whether it be adopting later Maki items, WMF or community creating new icons, utilizing existing free Commons files, or a combination of those options. Nevertheless, the technical function of adding and modifying icons needs to take place.

Discussion

  • I support this, because one of most painful limitation is task T141335 the impossibility to use 3 digits on markers. --Andyrom75 (talk) 21:41, 20 November 2020 (UTC)
  • I support this, since this issue already lead to quite a lot of discussions on Wikivoyage. --Nw520 (talk) 22:15, 22 November 2020 (UTC)

Default languages for Captions and Descriptions on Wiki Commons

Edit proposal/discussion

  • Problem: When uploading new pictures on Wikimedia Commons, you have to click "Add a caption in another language" and then again "Add a description in another language" for each picture, and for each language. When you can speak several languages, and you want to contribute as much as you can, this leads to a number of unnecessary, annoying clicks and it takes too much time, if you upload more pictures at once, as you have to do this with every language for every picture twice.
  • Who would benefit: every contributor using more languages
  • Proposed solution: I propose to add option of default languages (with possibility to choose more languages) for user, so you could choose several languages you speak and use, and after uploading a picture, caption and description boxes in these languages would be added automatically to each picture.
  • More comments:
  • Phabricator tickets:
  • Proposer: Lukáč Peter (talk) 21:51, 25 November 2020 (UTC)

Discussion

Private Notes

Edit proposal/discussion

  • Problem: To make notes that no one else should read, third-party software is required.
  • Who would benefit: All Users
  • Proposed solution: A MediaWiki extension that allows to make private notes.
  • More comments: The extension is not for a Sandbox. It should have minimal formatting options such as bold and italic and Onwikilinks.
  • Phabricator tickets:
  • Proposer: 𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 20:00, 16 November 2020 (UTC)

Discussion

  • @WikiBayer: I'd suggest making a more comprehensive description of the problem. What problem does it solve (in terms of the article writing process), how many people/how regularly have people asked for this functionality ? I mean.. my first idea would be.. use the notepad functionality of your computer.. It's easy, its there, you are already familiar with it. As we shouldn't cram the functionality of an entire operating system inside MediaWiki if we can avoid it, why would it be so much better to have it in the MediaWiki software that it would eleviate the burden of making and keeping such basic functionality provided by so many other pre-existing and focused systems ? —TheDJ (talkcontribs) 21:19, 16 November 2020 (UTC)
    en:Signal (software) has self-send functionality which it treats as notes. I know that private messaging in MediaWiki is a perennial, so there's a potential crossover there. --Izno (talk) 22:00, 16 November 2020 (UTC)
Alternative software is always more cumbersome than a function in the Mediawiki. Appropriate programs are required on all PCs/Smartphones. A "interview" by WMF with CheckUsers has also shown that they keep making alternative notes.---𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 08:13, 17 November 2020 (UTC)
  • @WikiBayer: We'd like some more details about what sort of connections or features these Private Notes would have? Is the desire here to be able to use Wikitext? Link to wiki articles? Do sandbox development in private? We'd like to see the specific use cases be at the heart of the proposal so that it's clearer, more specific, and easier for voters to understand (and support). --AEzell (WMF) (talk) 23:21, 2 December 2020 (UTC)
@User:AEzell (WMF) The proposal is intended as a pure administrative aid and organizational aid. It is only intended to enable you to take notes and to format them minimally so that longer notes remain clear and can be navigated quickly. It should be possible to create Links to Wiki Articles and write in bold and italic.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 08:49, 3 December 2020 (UTC)

Add a tracker for CSS selectors

Edit proposal/discussion

  • Problem: We don't have a query service for searching CSS selectors (e.g. id and classes). It makes really hard to clean up the legacy codes. Because of that, it took several years to supersede deprecated "prettytable" class in Commons. Until the legacy selectors are completely eliminated, we must keep the legacy codes for really long time. Also, we are not able to evaluate the impact of the style modifications.
  • Who would benefit: interface administrators and developers, template editors
  • Proposed solution: Add a special page to search pages using the specific id or class selectors
  • More comments:
  • Phabricator tickets:
  • Proposer: – Kwj2772 (msg) 14:56, 18 November 2020 (UTC)

Discussion

  • Hello Kwj2772! You should be able to identify use of CSS selectors by simply doing a insource search. For example, here is an example of where I'm searching for the wpFilterRules selector (I intentionally did not include the # (ID) symbol in case there was some JavaScript that used for instance document.getElementById()). You can also search via regular expression. If you need to search across multiple wikis, try the Global Search tool. That tool has a convenient link to search only JS/CSS/JSON as well. It also supports regular expressions, among other features. Do any of these solutions work for you? MusikAnimal (WMF) (talk) 21:33, 18 November 2020 (UTC)
    • Difficult point still exists when the classname is defined in common words. For example, you would have much trouble when you have to find the classname "notice". – Kwj2772 (msg) 09:44, 19 November 2020 (UTC)
      https://w.wiki/nkE for example seems to work well. The regular expression could be tweaked to be more strict, if needed. I'm not sure how would we even be able to track use of IDs/selectors. MusikAnimal (WMF) (talk) 22:30, 23 November 2020 (UTC)

Include size change in diffs

Edit proposal/discussion

  • Problem: While the change in size is shown for each change in Recent Changes and article history pages, it is not shown on the diff itself, nor in the API as far as I can tell
  • Who would benefit: People reviewing changes
  • Proposed solution: Add the change in size to the diff page and API
  • More comments:
  • Phabricator tickets: phab:T172698
  • Proposer: the wub "?!" 17:59, 30 November 2020 (UTC)

Discussion

Check if a page exists without populating WhatLinksHere

Edit proposal/discussion

  • Problem: Does a wiki page exist? You would expect that this would be a simple thing to check, and it partly is - you can use the #ifexist parser function. However, this has unexpected consequences: the wiki page that does this check will now appear in Special:WhatLinksHere. These false flags causes problems for editors that are working on resolving misplaced wikilinks, such as links to redirects or disambiguation pages. That in turn leads to them objecting to templates that check for the existence of a page to see if they should link to it.
  • Who would benefit: Template developers and editors resolving disambiguation links on all wikis
  • Proposed solution: Stop checks for the existence of a page from appearing at WhatLinksHere
  • More comments: This was included in the 2015, 2017, and 2019 community wishlists: while it only had 1 oppose vote, it did not get enough support votes to be addressed. It is tricky to resolve, but it should be fixed.
  • Phabricator tickets: phab:T14019 (started on 18 November 2007 - happy 13th birthday!), this is part of the larger task described at phab:T268526 ("Use a dedicated mechanism to track page dependencies")
  • Proposer: Mike Peel (talk) 22:14, 18 November 2020 (UTC)

Discussion

I do not know how important this is, but I'll support since it keeps getting asked over and over again apparently. Hopefully, that gets implemented. MarioSuperstar77 (talk) 22:37, 18 November 2020 (UTC)

  • I created Template:Linkless exists to address this issue. It has disadvantages: please read its documentation before using! However, I'd still like to see a built-in and supported equivalent. Certes (talk) 01:09, 23 November 2020 (UTC)
    Thanks for that, Certes. I thought a simple work-around was possible; I actually opened a tab in my browser pointing to en:Template:If exist as a reminder while I waited the light bulb telling me how to do it turned on (there are probably multiple ways). But I hadn't considered using the PROTECTIONEXPIRY parser function as the trick to implement it. See User talk:Wbm1058##ifexist for links to another work-around implemented in 2016 which used alternative logic that avoided the need to explicitly check if a page exists. Wbm1058 (talk) 15:34, 23 November 2020 (UTC)
I've supported this fix every year. I hope the 13th is the lucky one ;-) --Andyrom75 (talk) 17:35, 23 November 2020 (UTC)