This page is an archive for proposals posted on the Community Wishlist Survey 2015 that were closed. Proposals were closed for several reasons: The proposal described a project that's already happening, the proposal directly conflicts with an existing product team's work, the proposal was a duplicate of another proposal, the proposal was withdrawn by the proposer, or the proposal failed to receive any endorsements in the proposals phase.
Recommend to create automatic bot for those small wiki which may not have local expertise. They can submit a template and data file and a bot expert will create and run the bot (with permissions of local admin.). Yosri (talk) 02:34, 10 November 2015 (UTC)[reply]
@Ryan Kaldari (WMF):Ditto, but without the need for the said user to have bot expertise. More like the local user only prepare a template and the data file. A standard bot will pick it up and generate the pages. That means, wiki in other languages need only to translate the template to generate complete pages in local languages, instead of manually translating those pages one by one. Yosri (talk) 16:00, 18 November 2015 (UTC)[reply]
@Yosri: OK, I think I understand better, but could still use some clarification. What types of bots did you have in mind? Are you thinking of bots that generate database reports (en:Wikipedia:Database reports)? Bots that edit articles? Bots that build reports for WikiProjects? Which ones would be your highest priority? Any specific examples would help. Ryan Kaldari (WMF) (talk) 23:30, 18 November 2015 (UTC)[reply]
@Ryan Kaldari (WMF): A bot that create article, very much like mail merge. User supply template and data file, the bot run on batch (after local admin given green light.) If other language Wiki want to use the same data file, they just copy both to local Wiki & translate the template and some field in the data file (I imagine) and their local admin give green light / flag bot on for that template and off it go. After all, not all user is technical savvy enough to operate a bot, but can still manage mail merge like concept. Yosri (talk) 14:30, 19 November 2015 (UTC)[reply]
Yes the whole point of the project is not to create the actual wikitext article unless an editor comes and takes the time to expand on the info Wikidata can already provide. The moment you make it a real article it becomes much more difficult to for example keep it updated automatically. --Lydia Pintscher (WMDE) (talk) 11:18, 26 November 2015 (UTC)[reply]
Create a new-generation default upload wizard for Commons that is 100% icon-based, without using any text at all. I know it's a challenge, especially considering the incredible amount of text here. There must be a way to use the creative commons licensing logos and editing logos to indicate fields for input, and nation flags for local templates and so on. Behind the logos can be links to help pages, but it should theoretically be possible to upload a file without encountering any text at all. This improvement will greatly enhance repetitive upload experiences, while making it possible to fit many input fields on one screen (sometimes something basic such as the "Next button" drops off my screen in the lower right for example). Suggestions such as the current links in the default uploader for "Learn/Upload/Release rights/Describe/Use" can all be substituted by a question-mark token taking you to help pages. The term "Releasing rights" is useless and only acts as a deterrent for potential uploaders. This should be substituted with a drop-down selection for the proper creative commons license (or combination thereof) which may include a direct link to that license on creative commons, not to some page on Commons itself. The "Use" button doesn't belong in upload wizard at all, but should be part of the basic information template. This is a feature that should always be available, and not just on file creation. (I will create a separate wish for this). --Jane023 (talk) 11:38, 20 November 2015 (UTC)[reply]
Modify Commons Upload Wizard to move "Use" linkedit
Screenshot of "Thanks" page as it currently is today
Currently, after uploading an image on Commons using the default uploader, the user is presented with a "Thanks" page that includes a use-link under the header "To use the file in a wiki, copy this text into a page:". The thankyou is fine and should appear at the top of the page and the rest of the page should be the default file page. The use-link should be part of the basic template to be used at any time, not just on file-upload. I suggest putting it under the image, so e.g. next to the current link under the image that states "Open in Media Viewer". --Jane023 (talk) 11:46, 20 November 2015 (UTC)[reply]
Improve Transfer of files from Wikipedia to Commonsedit
Current tools like tools.wmflabs.org/commonshelper often "loose" a lot of valuable information during transfer, they also often produce quite bad results that requires massive cleanup efforts on the Commons end. Requirement of the improved system would be:
file and description edit history should be copied and accessible on Commons through "history" tab. First this seems to be the only way to satisfy the requirements of matadata CC-BY-SA-3.0 license, second the metadata after transfer often has confusing licenses, OTRS licenses or other important information and it is essential for regular users to be able to go back to the original file and look it up. Unfortunately at that point the original file is often deleted and can not be viewed without help of wikipedia administrator.
there has to be community maintained mapping between templates and template parameters, so Wikipedia templates used on file pages can be replaced with equivalent Commons templates and all the parameters used by the templates are properly copied. For example sr:Шаблон:OTRS is equivalent to c:Template:PermissionOTRS, but parameter "1" does not match Commons parameter "1" and Serbian "{{OTRS|3396357}}" is equivalent to commons {{PermissionOTRS|ticket=https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom&TicketID=3396357}}.
Wikidata should be used for matching categories and possibly templates.
Transfer tool should work both ways so files which could be used on supporting wikipedias under "fair use" can be easily copied from Commons instead of just deleting them.
Today one of the most frequent omission in new aticles is the need to enter "references" when there exist "ref"s in the text. It ought to be posbile to "propose" to the edistoir these in the right place.Yger (talk) 10:49, 11 November 2015 (UTC)[reply]
RefToolbar is a default gadget on the English Wikipedia. It adds a "cite" button to the WikiText editing toolbar for quick and easy addition of commonly used citation templates. It is probably the most common way that citations are added into Wikipedia. It also has an auto-fill feature that lets you create a full citation by just entering the ISBN, DOI, or PMID number. There is a new Citoidservice that is being developed for the VisualEditor that will allow the same auto-fill capability based on raw URLs. Since Citoid is an API service, there is no reason it can't be added to the WikiText editor as well through RefToolbar.
Looks like the bug is currently unclaimed, but is being considered as a possible GSOC project for August. Specifically, the bug is about adding Citoid + TemplateData support to WikiEditor (unclear if this would include a citation template editing interface), which sounds like a larger project. My idea above is a quick hack just to add a Citoid lookup to the existing URL field in RefToolbar. RefToolbar already does API look-ups and has mappings for all the en.wiki citation templates, so this would be a smaller, short-term project. Kaldari (talk) 18:44, 12 May 2015 (UTC)[reply]
Pre-re-organization, it was definitely the Editing team, whose main project was VisualEditor, but whose scope also included the wikitext editor and Cite.php.
The VisualEditor team is definitely planning on doing this as part of the modern wikitext editor project. However, it's not being actively worked on yet and probably won't be for another quarter or two. I leave it up to the Community Tech team whether to include it in their survey, but I don't think they want to take on things that other teams have fairly concrete plans to do :)—Neil P. Quinn-WMF (talk) 20:16, 11 November 2015 (UTC)[reply]
Just to clarify, the project is to build a new wikitext editor with all these features (to avoid suddenly breaking users' workflows and gadgets). This wouldn't help people who strongly want to stick with the existing editor.—Neil P. Quinn-WMF (talk) 20:40, 11 November 2015 (UTC)[reply]
The functionality for automatic non-breaking spaces should be improved. As far as I know, this already exists for "%" and "« »", but there are other places where it would be needed, such as "§". Also, VisualEditor does not support non-breaking spaces yet. Thanks, --Gnom (talk) 10:04, 12 November 2015 (UTC)[reply]
My understanding is that spaces before most punctuation marks are automatically converted into non-breaking spaces. § isn't really used as punctuation though (at least not in English), but to designate a section or paragraph in a work. I'm assuming that you would want the space after the § to be converted into a non-breaking space, correct? Are there any other specific examples of cases that would benefit from automatic conversion? Ryan Kaldari (WMF) (talk) 18:01, 12 November 2015 (UTC)[reply]
Please take a look at the use of "§" and "& nbsp;" in §_175, a law-related featured article on German Wikipedia. It currently contains 249(!) instances of "& nbsp;". I don't think I can come up with any good English examples, but maybe "Mr._Smith" is one. Thanks, --Gnom (talk) 21:26, 12 November 2015 (UTC)[reply]
@Ryan Kaldari (WMF): Your understanding appears to be wrong. You can test it by creating a short test page with long words and slowly resizing the browser window. To see the difference, then replace with the spaces before the punctuation (punctuation such as hyphens -). But it would be nice if this could be implemented. --V111P (talk) 03:50, 22 November 2015 (UTC)[reply]
@V111P: I created a test page at User:Ryan Kaldari (WMF)/Sandbox. It looks like automatic non-breaking spaces are being added for semicolons, question marks, and exclamation marks. Periods don't need them, since periods don't have spaces before them (even in French). I'm not sure what you mean by hyphens. When would a hyphen need a non-breaking space? Ryan Kaldari (WMF) (talk) 22:54, 23 November 2015 (UTC)[reply]
@Ryan Kaldari (WMF): Sorry, I wasn't familiar with French punctuation rules, that's why I didn't test ;, ? and !. I gave the hyphen as an example because it is often used instead of a dash, I am also interested in having non-breaking space in front of the en dash – the one that is sometimes used with spaces, including in German. And I don't think that it's acceptable for the dash to appear at the start of a line in these cases. It's not the most important problem in Wikipedia, but it would be nice if it can be fixed. --V111P (talk) 04:04, 24 November 2015 (UTC)[reply]
@V111P: Ah I see. That might make sense to put them in front of en dashes. It could be problematic for em dashes, though, since in some languages (like Russian apparently) you're supposed to use a "narrow non-breaking space" character in front of em dashes (or in English, no space at all). Hyphens would also be problematic since they are often used for negative signs (which don't need a non-breaking space in front of them). Kaldari (talk) 21:31, 24 November 2015 (UTC)[reply]
@Kaldari:, it should probably be an option in MediaWiki (if it's not already an option) – Spanish (Wikipedia) also uses special rules for the em dash —space before the first one— but after the second one. --V111P (talk) 03:13, 25 November 2015 (UTC)[reply]
Article sweeper / examine list for later checkingedit
Problem
We have no way to do article quality checking, in series.
Benefit
All users / all projects.
Currently addressed
Using hovercards over articles in categories, in Wikipedia (very limited).
Solution
By a tool that navigates an article list (on the left) and previews articles (on the right) using keyboard (left/right changes article, up/down (and mouse) scroll article). The list can be fed in a number of ways, i.e with a category and by selecting the level of deepening inside it.
An article with a poor lead section or table of contents is often a poor article.
Using hovercards is not enough and article message templates are not visible.
Sweeping an article category (+selectable depth) with preview is extreme help for thematic quality checking.
Scrolling the article preview helps examining the full article.
Putting articles to a personal examine list by using spacebar toogling (and similar button to watch list 's star click) helps later checking.
Make simple to directly put article message templates while previewing.
Provide an editor that provides concurrent wikitext / WYSIWYG views. (Obviously there would be some unspecified view for construct in progress. e.g. If the user opens [[ to start a wikilink we wouldn't want to render that as an error.
Auto-completion similar to what the Eclipse IDE provides for writing Java. For example, user starts a template {{web cite| ... provide dropdown /autocomplete with available parameters.
User warning due to multiple edits without summaryedit
Some years ago a user on itWiki (RicordiSamoa, I am not pinging him but you can ask him) developped a simple bot that could insert warnings in talk pages of users that had forgot to fill the summary line of their edits for more than 5 times in a row. The public discussion where the idea emerged showd no specific concern with it, but since the bot was activated "too early" (the discussion was still ongoing), it was stopped.
Now, as far as I recall, it looked a very simple feature to implement. Both as a warning in talk page or in the editing environment, you get the idea. Similar mechanisms are usd on some platforms. It can be tuned too: for example you can have it only working for registered users, or even only AP users, or using it with a higher edit threshold or focusing only on ns0 edits. I feel it could be useful, especially for retropatrolling, and that some wikiprojects will activate it without problems. It looks quite harmless: we have templates to ask for more attention, I don't see why I should waste my time to insert them when the operation can be "automatized" when needed.--Alexmar983 (talk) 17:58, 22 November 2015 (UTC)[reply]
On wiki stating a generic principle in a discussion in my experience "works" because the amount of people who agree is usually higher than those who would highlight that sometimes it does not show a great correlation with the discussion itself.
On itWiki we have a warning that informs users when they make a duplicate or a mistake introducing the cite book template. Is it forcing those users to avoid the insertion of such duplicate or mistake? Nope, it's just informing. We also have a template that politely asks editors to use more summaries. Is it forcing those users to actually use more their comment bars? Not that I recall. So we are stating a principle if we do these things but "not efficiently" or "not always"? Something does not sound right here, or is it just me? :D I am happy to know that a lot of time is wasted in retropatrolling because we have to state a principle but please next time, let's try to show an "overall perspective" otherwise I think the message is lost...--Alexmar983 (talk) 18:21, 24 November 2015 (UTC)[reply]
@Alexmar983 It might not force them directly, but unless the proposed user warning system only notifies someone once, the user who neglects the summary line will have their talk page flooded, thus making them feel somewhat forced to do it. I wholly agree that people (including me) need to use the summary line more, but I think an automatic system isn't a good idea considering that sometimes an empty edit summary is warranted, such as when you're correcting one little typo or syntax error. InsaneHacker (talk) 09:55, 26 November 2015 (UTC)[reply]
I write "typo" sometimes. BTW, if you mark "m" you don't need a summary. I use both, the second less than the first one but from the practical point of viw it is the same. It is a detail you can fix very easily--Alexmar983 (talk) 20:14, 26 November 2015 (UTC)[reply]
On EN Wiki edit summaries are optional, before you start warning people for not leaving a summary first you need consensus that Edit Summaries are compulsory. I find it useful to know that someone is likely to be a vandal or newbie so I would oppose making edit summaries compulsory. If someone could show a benefit from compulsory edit summaries that would be greater than the loss then I might reconsider. WereSpielChequers (talk) 15:46, 26 November 2015 (UTC)[reply]
why somone should show a benefit from compulsory edit summaries since they are not compulsory and they will never be? Why you should "need consensus that Edit Summaries are compulsory"? You are commenting something that is not my proposal, how can I reply on that? You just transformed it in something different.
The only users that insert less than 20% of edit (in ns0) are basically newbies. Actually, to get 50% probability to mak 5 edits in a row without any type information you need a filling efficiency of 13%... Or some distracted user once in a while. there won't be any flood of warning in talk pages and by the way you can skip the warnings in the talk and focus on the warning on the interface editing. A line informing you that the one you're saving is the n-th edit in a row without summary is not a shock (or similar/related concept) to your contribution history. In any case you can always start the warning after some hundrets of edits (I said in my proposal to focus on AP users for xample, or similar groups, depending on the platforms)
Even if this excessive picture you are describing were true (and it's not, if you crunch the numbers), still it would be a nice, useful tool that some platforms might need to adopt, whatever the backgruond behind that choice is. --Alexmar983 (talk) 19:26, 26 November 2015 (UTC)[reply]
Just to be clear: I just showed with maths that this has statistically an effect basically on people who make less than 13% of edit with summary and therefore all the previous comments focusing on the "almost 100% philosphy" were in fact quite off-scale. Just wanted to point out.
The answer to your question is a simple no. You warn people to pay more attention, this has to do with "something wrong" but also with "something that can be improved". If your comment were correct, templates asking for more attention in user talks should me removed. They have been used for years on some platforms, aren't they?
There's even more. In it:Aiuto:Oggetto you can read Una linea guida importante da seguire è compilare sempre il campo Oggetto... it's even compulsory! Noone wants that but do you ralize how excessive your comments sound compared to what is actually written in guidelines? In en:Help:Edit summary you can read It is considered good practice to provide a summary for every edit. So I think that a warning to encourage a good practice is perfect good sense especially when it is actually so mild. 5 in a row without summary is at the limit of what is considered good practice, isn't it?--Alexmar983 (talk) 23:43, 26 November 2015 (UTC)[reply]
Search and replace functionality in the editoredit
As a posibility to speed up mass replacements (e.g.: abbreviation by full word, one typographical symbol by another, etc.) it would be really nice to have some search and replace (all) functionality within the editor. -- Lord van Tasm (talk) 14:57, 23 November 2015 (UTC)[reply]
VisualEditor allows mass replacing (use Ctrl + F). Probably there are gadgets as well which lets you do this with the wikitext editor. --Glaisher (talk) 15:21, 23 November 2015 (UTC)[reply]
I've also been editing for several years now but have never noticed this until now (Thanks Nemo!). Is there any reason why the feature is "hidden" at the other side? Why can't it be just next to the other icons in the toolbar? --Glaisher (talk) 15:32, 24 November 2015 (UTC)[reply]
I think it would be useful if Single Purpose Accounts and new user edits were flagged somehow in page histories and reports such as Recent Changes. These are often sources of problematic edits, so it would help in identifying such edits. Additionally this information is useful in deciding how to respond to problems and it would thus save having to check user contributions. Would have to decide how to define such accounts. Maybe a SPA is one with more than 80% or mainspace edits on one page, and new users are those with less than 20 mainspace edits, but maybe there are stats available that might give a better understanding of how to set this criteria. Derek Andrews (talk) 00:08, 9 November 2015 (UTC)[reply]
As regards new users, I believe this can be done by setting edit filters to tag edits by users with few edits. No comment with regard to SPAs. BethNaught (talk) 18:21, 9 November 2015 (UTC)[reply]
Oppose they're already filter tagging new edits this way, but where is the new editor curation and coaching? fixing problems is a particularly bad idea, try system improvement. Slowking4 (talk) 04:03, 14 November 2015 (UTC)[reply]
Comment I am sensitive to the "scarlet letter" issue. Perhaps a better idea would be to have proven-sock account's edits made after a certain date [e.g. the date the original puppetmaster was blocked] retroactively tagged. Retractive tag changes would likely require a change to the MediaWiki software. Davidwr/talk06:02, 16 November 2015 (UTC)[reply]
Oppose Not all SPA accounts are bad, nor are all -- or even a majority -- of new user accounts problematic. In my opinion, it is better to miss one sock puppet than to falsely accuse a new user of sock puppetry. Likewise, it is better to miss a problematic edit than bite a potentially productive future editor by failing to assume good faith. Etamni (talk) 06:42, 17 November 2015 (UTC)[reply]
In a very short time, it's become clear to me that many admins need help dealing with IPv6 rangeblocks. See this and [this for example. Can the WMF come up with better tools, scripts, or at least more understandable documentation to help out? I looked at the MW docs and there are no practical examples admins can follow. --NeilN (talk) 18:19, 11 June 2015 (UTC)[reply]
The damage that COI offenders cause to our reliability and integrity as a community: On his WP Talk page, Jimbo Wales said: This story looks worthy of a discussion. I have long advocated that we should deal much more quickly and much more severely with COI editors. The usual objections (from some quarters - I think most people agree with me) have to do with it being hard to detect them, but in this case, the COI was called out, warnings were issued, and nothing was done. Now the editor has been called out by the media embarrassing him (he deserves it), his employer (who may not), and Wikipedia.--Jimbo Wales (talk) 17:08, 20 November 2015 (UTC)[reply]
Which users would benefit?
All but the COI.
How is this problem being handled now?
from WP:COI: "How to handle conflicts of interest": avoid outing, be civil; offenders "should be made aware of this guideline and warned not to continue their problematic editing. If the same pattern of editing continues after the warning, the account may be blocked." Then hand them a lollipop?
What are the proposed solutions?
Research: Adapt existing tools, and control measures proposed in this Moderation section, to make it easier for Wikimedians to research and flag suspicious users
Limit the damage: Suspend user ability to edit pages other than COIN/ANI, pending investigation
Resolve: Unblock/ban user, depending on results of investigations
The Community Tech team is focused on curation and moderation tools for editors. This (interesting) proposal is clearly out of scope for this team. Maybe it is a good candidate for #possible-tech-projects? I have commented in the task.--Qgil-WMF (talk) 11:49, 21 September 2015 (UTC)[reply]
MER-C closed this proposal for being out of scope for the Community Tech team. It is, but I think it's still worthwhile to gauge community interest for this idea. It doesn't duplicate or conflict with a product team's current roadmap, so this can stay open. -- DannyH (WMF) (talk) 23:33, 18 November 2015 (UTC)[reply]
Echo notifications for anyone "listening" besides the page's creatoredit
I think we should use create the possibility to anyone start "listening" a page through Echo notifications as if this user was the page's creator (I think it is the same as T106991 in Phabricator). And, of course, to "stop it" whenever it wants. José Luiztalk00:04, 10 November 2015 (UTC)[reply]
Currently Ping needs a signature to work. If someone forgets to sign while pinging, ping won't work. I've seen lots of users who forget to sign at the first step, but will sign a few moments later and still expect to send their ping, while it is not sent! I think the MediaWiki software should be able to identify the ping operator, independent of signature. 4nn1l2 (talk) 23:03, 18 November 2015 (UTC)[reply]
The main reason this has never been implemented is that it would potentially cause unwanted pings when people copied and pasted discussions from one place to another (for example, when archiving discussions). Ryan Kaldari (WMF) (talk) 04:04, 25 November 2015 (UTC)[reply]
Comment this could be implemented by a special "save" button that auto-appended the editor's signature then immediately made a new edit which removed the signature. It would be a kludge and it would have to account for race conditions/edit conflicts but if done correctly it wouldn't break anything and copy-and-paste would still work as one would expect it to. Davidwr/talk22:32, 25 November 2015 (UTC)[reply]
One problem facing users of Wikipedia is determining whether an article they are reading has been vandalized. While I think we do a good job of catching and reverting vandalism, there is inevitably a time interval between the act of vandalism and its removal. Given the large number of people who use Wikipedia, some readers may access the article during that time interval. There is currently no easy mechanism to help readers check whether an article they are reading is in a vandalized state.
Which users would benefit? (editors, admins, Commons users, Wikipedia users, etc.)
This proposal primarily benefits users of Wikipedia. Editors would also benefit by simplifying checking article changes for errors.
How is this problem being handled now?
A knowledgeable user can employ our diff mechanism to see what changes have recently been made to an article, however there is no obvious base point to check from and the procedure may be too complex for most readers.
What are the proposed solutions?
I would like to propose a ‘’Wikipedia check-point edition’’ as a way to address this problem. Here's how it would work:
As of a certain day and time, not publicized in advance (say 2359 GMT on November 15, 2015), the current version of all articles would be recorded as a list, indexed by article name, consisting of permalinks to the latest version the article as of that date and time. An automated scripts would then “apply” certain subsequent edits made by auto confirmed users over, say, the subsequent two weeks. Applying an edit would mean replacing the permalink in the checkpoint list with that of a later or former version. Edits that would be applied automatically might include:
rollbacks or reversions that are marked as vandalism removal
edits marked as removing copyright violations
Any article deleted in the time window (deletion scripts might be updated to delete from the checkpoint list as well)
Articles created less than, say, two weeks earlier might also be excluded from the list as too immature.
Articles that are the subject of active dispute resolution or in the midst of an edit war as of the date and time might also be excluded so as not to favor one side in a dispute. For articles that have recently undergone a review, such as featured articles or good articles, the last reviewed version of the article would be the check point version.
Manual changes to the list would only be made on an exception basis by an admin, with notice on the article talk page and, perhaps, a notice board. The only acceptable reasons would be for clearcut vandalism not caught by the automated scripts, copyright violations and BLP violations. Errors of fact, POV bias, poor sourcing and other disputed material would NOT be a basis for changing the checkpoint edition. Changes to the checkpoint would be limited to substituting a later or earlier revision of the article to replace the one listed. Admins could also simply remove the article from the checkpoint list, if there was no other clean option available.
The goal would be to create a list or articles that reflect a vandalism free version of Wikipedia as of the check point time, using minimum human intervention. New checkpoint editions might be created every year or two, perhaps at a randomized time so as not to create an opportunity for editors to get POV material into articles just before they are check-pointed. Note that nothing in this proposed process would change the current content of Wikipedia articles or our normal editing process.
A tool or button on the article display would then be provided to view the check point version and to compare the current version by diff with the check point version. A reader concerned about the status of the article could compare it with the check pointed version, and then check the sourcing of any changes that seemed material. There would also be a mechanism to report uncaught vandalism in the checkpoint edition.
This proposal is not foolproof. There will always be some vandalism that is missed, but I believe such a mechanism would be a useful tool for readers concerned about the trustworthiness of Wikipedia. -- — The preceding unsigned comment was added by ArnoldReinhold (talk) 20 Nov 2015
@ArnoldReinhold: You could try installing ScoredRevisions, which indicates which edits in the history of a page have a high probability of being reverted, or being damaging. It uses data from ORES server for that.
Show Reasonator-style manual+automatic descriptions in Wikidata searchesedit
User-provided description fields on Wikidata are often empty, or minimal. Make Wikidata search-page results easier to interpret, as Reasonator does, by including auto-generated descriptions as well as the stored ones -- compare Reasonator search vs usual search for "John Arbuthnot". Jheald (talk) 13:07, 13 November 2015 (UTC)[reply]
Standard way to be able to enable archiving of sections marked closededit
It would be good to be able to mark sections 'closed' and for them then to be transferred to an archive.
Yes, I know that on some wikis there are bots set up that may be able to do this automatically; but I am not sure whether that is true on all wikis, or smaller wikis where nobody may be running such a bot. (eg on Wikidata, it would be nice to be able to implement this for d:Wikidata:Classification noticeboard, ideally together with searchable archiving, but I have no idea how to set this up).
Yes, I also know that Flow can sort-of do this; but it would be nice to be able to do this in a conventional wiki talk page environment, with archiving to conventional editable wiki pages, without having to adopt everything else about Flow. Jheald (talk) 13:37, 13 November 2015 (UTC)[reply]
It would be nice to be able to share a common watchlist between legitimate alternative accounts. Currently, watchlisted items must be manually copied between accounts. Any editor with an alternative account who uses watchlists would benefit. There is already a "key" that allows a watchlist to be exported via a feed, so adding the ability to input that key into a different account should be fairly simple. Example of how this might be used: I have my main account (Etamni) as well as a declared alternative account used for mobile edits and edits from shared computers or public WiFi (Etamni-m). This ability would allow me (or others in similar positions) to use a master watchlist for both accounts. If I add or remove a watchlist item from either account, the change would apply to both accounts automatically. This would be an opt-in feature and would not apply to editors who don't want to use it. Etamni (talk) 08:17, 17 November 2015 (UTC)[reply]
I'm not sure how that would work for editors who watch hundreds or thousands of pages. I welcome new users and warn vandals with Twinkle, and add their user pages to my watchlist automatically. I also add any page where I correct vandalism or fix other unhelpful edits. Throw in other users' talk pages, a few drama boards, and the pages I'm actually interested in, and maintaining a separate list to watch would quickly become unwieldy. Etamni (talk) 09:00, 20 November 2015 (UTC)[reply]
Slovene and other Slavic languages (and perhaps some others too) use gender-specific words to describe occupation of a person, with male form being default. It would be useful to add a descriptor M/F to an object's description in a given language, and enable targeted transclusion of this data to Wikipedias. Then, infoboxes for women could be auto-filled with appropriate words. This would of course necessitate creating a second label for the variant for the other gender, so I don't know it it's really feasible, but it's something to think about.
Oppose. Recruitment companies in most of these countries are working at creating gender neutral labels for occupations and these are what we should be using for labels in all languages in Wikidata because the wikidata items are gender neutral so any label that isn't is a label that is wrong. This is just as the English words 'actor' and 'waiter' have, over the last twenty years, come to mean either a man or a woman. The solution to this problem is first to resolve a way to give these occupations gender neutral labels ('programador/a' or even 'programador or programadora'). That is not a technical problem the Community Tech can help with.
Once we have the gender neutral labels sorted then we can look at whether we also need properties for the male and female versions and a couple of lines of Lua code to find them or if we can just switch to using the gender neutral labels in wikipedia infoboxes in all languages. Filceolaire (talk) 06:47, 13 November 2015 (UTC)[reply]
@Filceolaire: gender-neutral labels are of course possible, but cumbersome if the purpose is to fill infoboxes. We aren't recruiting unknown people to fulfill some roles, we are describing existing men and women (in other words, Ada Lovelace is not a programador/a, she is a programadora). I don't understand why should we condition looking for solution with setting up an inelegant system. Instead, an inelegant system should be put in place if a better solution is not possible. — YerpoEh?07:49, 13 November 2015 (UTC)[reply]
It is a failing of Wikidata that it does not support this. It is a deliberate choice and we suffer from its consequences. It is an obvious issue of cultural determinism. Thanks, GerardM (talk) 07:40, 20 November 2015 (UTC)[reply]
On a small wiki, visiting any missing page or searching for a page not on the wiki should load up Reasonator in the local wiki language. For example, the Johann Sebastian Bach info page can and should be shown on all 272 wikis that don't have a J.S. Bach page. Global south!
Comment We would need a campaign to translate Wikidata content or the small wikis would be filled with generated English articles. --Molarus (talk) 10:37, 15 November 2015 (UTC)[reply]
Browser widget to fill Wikinewses' source templatesedit
Several Wikinews languages make use of templates to cite sources which metadata have to be copied and pasted from another browser tab, e.g. title, publisher, date, URL what requires several copy and pastes. The idea is to get a browser widget for Firefox which allows to copy all meta data and fill in within one edit.
This is a Community Tech team task. Perhaps contributors could comment here or at the Phabricator page with suggestions for the most burdened classes of Wikimedians. What technical tools would be helpful? Rogol Domedonfors (talk) 06:35, 26 July 2015 (UTC)[reply]
I realize this may be a bit out of scope but I wanted to throw it out there...
It would be very useful to have some mechanism that would generate a sound file from phonetically spelled words, at least in English. Right now if one clicks on a phonetically spelled word (e.g. one tagged as a IPAc-en inline template), one is directed to a pronunciation key. It would be nice if wikimedia created some sort of function that would also sound out the word say in an .ogg file. Wikiliki (talk) 17:30, 9 November 2015 (UTC)[reply]
It would be good to introduce a virtual computer keyboard in search field (like in Google search field). There are moments when you can not use the keyboard. For example. I had two occasions when I broke my keyboard. Without a keyboard I could not type anything in the search field of Wikipedia. And this was very unpleasantly surprised me, because I was effectively denied access to Wikipedia. — Green Zeroобг10:19, 10 November 2015 (UTC)[reply]
Oppose I broke my CPU, I was unpleasantly surprised to discover I was effectively denied access to Wikipedia (chuckle). I'm not opposed to this functionality per se, but I'm opposed to this taking the slot of more valuable Community Wishlist projects. Alsee (talk) 00:10, 15 November 2015 (UTC)[reply]
Turn HotArticlesBot into a publicly available serviceedit
HotArticlesBot is a ToolLabs bot that creates lists of articles that have been frequently edited within the past few days (typically as a subscription service for WikiProjects). The lists are based on the articles belonging to a particular category or including a particular template. It would be nice if there was a public interface that anyone could use to configure the lists that HotArticlesBot generates (via OAuth). It would also be nice if it supported projects besides English Wikipedia.
wikiproject.json is a publicly editable configuration file that will be used by my scripts for per-project configurations. HotArticlesBot and other bots are welcome to use it to store configuration data. harej (talk) 19:17, 11 May 2015 (UTC)[reply]
There are probably at least a dozen PHP API frameworks for MediaWiki. Most of them are old and with limited features. It would be nice to have one feature-rich well-maintained PHP framework that people could use for a wide variety of projects, similar to pywikibot for Python.
There is a small Node.js framework for MediaWiki as well as a fair bit of JavaScript API code within the MobileFrontend extension. These could be used as the basis for building a robust JavaScript API framework for MediaWiki.
Cool, but needs more details. Is this for use by external clients (the first link), external web pages, or on wiki pages (the Mobilefrontend link)? If the last one, how does it relate to the mediawiki.api module? -- SPage (WMF) (talk) 21:29, 15 May 2015 (UTC)[reply]
Timeline graphs of changes in article number and quality for WikiProjectsedit
It would be nice to give WikiProjects a historical overview of the number and quality of their articles. This would require keeping a record of this data in a dedicated database on Tool Labs. Should investigate coordinating with WP 1.0 bot.
It would be based on log and revision data from the MediaWiki database (or a mirror of the database). It would show recent blocks that had occurred. Kaldari (talk) 18:33, 16 July 2015 (UTC)[reply]
Bot to generate list of worst lead sentences on Wikipediaedit
Not sure how this idea would work? Based on what criteria? And why would we need a bot to do it? Users can simple go through articles. Lead sentences are really hard to write. Doc James (talk · contribs · email) 07:14, 28 May 2015 (UTC)[reply]
The impending WikiProject directory on the English Wikipedia will generate lists of active contributors to both the project space (the WikiProject page, talk page, subpages) and the project scope (articles and talk pages tagged by the WikiProject). This presents an opportunity for a bot to use this information for invitations. harej (talk) 19:19, 11 May 2015 (UTC)[reply]
It would be opt-in on a project-by-project basis; so WikiProject Medicine could decide to use or not use such a service. The exact criteria for receiving an invitation would have to be nailed down. In the meantime, my reports list editors on the basis of having at least five edits in a project area in a one-month period, regardless of how old that account is. harej (talk) 13:37, 27 May 2015 (UTC)[reply]
It sounds like something that would be good to study. It could be set up to send invites to half the people who made at least 5 edits and not to half (those who have been previously send invites would not get another)
This idea was piloted a couple years ago on Portugese Wikipedia (botrequest). I'm not sure what the outcome was, but it might be useful to get in touch with Alchimista or one of the other editors who was involved. Jmorgan (WMF) (talk) 23:16, 3 June 2015 (UTC)[reply]
On Portuguese Wikipedia is was used in a pilot project, it invited newbies to the local medicine project. I can't find retention stats, but if anyone find them usefull, i can get them. Alchimista (talk) 21:02, 23 June 2015 (UTC)[reply]
Tools to support conference program developmentedit
There are now registration tools, but there are not necessarily tools to support conference development.
The Wikimania programme committee utilizes a matrix to assess the committee's opinion on entries, however that matrix might be more challenging for some to manage. Might be helpful to either adapt these things to better use VE, or develop gadgets to help.
Session evaluation tool - a method of collecting evaluations on sessions.
I suspect there are other tools that could be helpful for consistent conference tasks.
Recent reports by things like OTRS have gone outside the traditional wikicode based report mold. Is that something that other entities should be encouraged to do? If so, should there be tools to help them do that to lower the technical skills needed and timeload on more tech savvy volunteers involved in those groups? Especially if the methods they are using are similar each time.
A very common request is to hide some element of the UI, but everyone has their own little pet peeves. The problem summarizes basically as: "We have 10000 UI elements and you can probably for each of those elements find one or more users who would like to hide it. 10000 UI options don't scale".
My idea would be to make a gadget that alla 'Adblock' would allow you to highlight an area. The area would show the CSS selector for that part of the page. It then asks you to confirm if you want to hide this part only for this page or for all pages. We would save the result to global.css. Then everyone can adapt their user experience to their hearts content on their own responsibility. Some libs that could help with this: https://vimeo.com/52055686 and https://selectorgadget-plus.appspot.com —TheDJ (talk • contribs) 18:14, 19 May 2015 (UTC)[reply]
"Inventory pages" or nice "to-do" displays for each Wikiprojectedit
Background: Page Weight Matters, by Chris Zacharias
"Three years ago, while I was a web developer at YouTube, one of the senior engineers began a rant about the page weight of the video watch page being far too large. The page had ballooned to as high as 1.2MB and dozens of requests. This engineer openly vented that “if they can write an entire Quake clone in under 100KB, we have no excuse for this!” Given that I agreed with him and I was excited to find a new project, I decided to champion the cause of getting the YouTube watch page to weigh in under 100KB. On the shuttle home from San Bruno that night, I coded up a prototype. I decided to limit the functionality to just a basic masthead, the video player, five related videos, a sharing button, a flagging tool, and ten comments loaded in via AJAX. I code-named the project “Feather”.
"Even with such a limited set of features, the page was weighing in at 250KB. I dug into the code and realized that our optimization tools (i.e. Closure compilation) were unable to exclude code that was never actually used in the page itself (which would be an unfair expectation of any tool under the circumstances). The only way to reduce the code further was to optimize by hand the CSS, Javascript, and image sprites myself. After three painstaking days, I had arrived at a much leaner solution. It still was not under 100KB though. Having just finished writing the HTML5 video player, I decided to plug it in instead of the far heavier Flash player. Bam! 98KB and only 14 requests. I threaded the code with some basic monitoring and launched an opt-in to a fraction of our traffic.
"After a week of data collection, the numbers came back… and they were baffling. The average aggregate page latency under Feather had actually INCREASED. I had decreased the total page weight and number of requests to a tenth of what they were previously and somehow the numbers were showing that it was taking LONGER for videos to load on Feather. This could not be possible. Digging through the numbers more and after browser testing repeatedly, nothing made sense. I was just about to give up on the project, with my world view completely shattered, when my colleague discovered the answer: geography.
"When we plotted the data geographically and compared it to our total numbers broken out by region, there was a disproportionate increase in traffic from places like Southeast Asia, South America, Africa, and even remote regions of Siberia. Further investigation revealed that, in these places, the average page load time under Feather was over TWO MINUTES! This meant that a regular video page, at over a megabyte, was taking more than TWENTY MINUTES to load! This was the penalty incurred before the video stream even had a chance to show the first frame. Correspondingly, entire populations of people simply could not use YouTube because it took too long to see anything. Under Feather, despite it taking over two minutes to get to the first frame of video, watching a video actually became a real possibility. Over the week, word of Feather had spread in these areas and our numbers were completely skewed as a result. Large numbers of people who were previously unable to use YouTube before were suddenly able to.
"Through Feather, I learned a valuable lesson about the state of the Internet throughout the rest of the world. Many of us are fortunate to live in high bandwidth regions, but there are still large portions of the world that do not. By keeping your client side code small and lightweight, you can literally open your product up to new markets."
(Reproduced under fair use: "The first factor is regarding whether the use in question helps fulfill the intention of copyright law to stimulate creativity for the enrichment of the general public, or whether it aims to only 'supersede the objects' of the original for reasons of personal profit.")
Given the above, I think that we should start a project -- a real project with measurable goals and a schedule -- to reduce page weight. --Guy Macon (talk) 22:21, 21 May 2015 (UTC)[reply]
This goes absolutely to the core of our mission, so a project is a good idea but there is work done on it already. I'd be interested to hear from the WMF how much priority/work is given to decreasing page weight. Maybe it's already been set as a goal? As for talk pages, perhaps there isn't a technological solution: maybe users should be nudged/helped to archive more frequently? MartinPoulter (talk) 14:36, 27 May 2015 (UTC)[reply]
Yes with respect to talk pages the push likely needs to come from the community. Editors need to be informed that they do not own their talk page and that it is like all other pages to improve the encyclopedia. If people cannot post on yours as it is to long someone may archive it. Doc James (talk · contribs · email) 07:21, 28 May 2015 (UTC)[reply]
Are there any measures about page weight on Wikipedia. There is a load of one-time data about page structure and layout which is cached afterwards. Anything beyond is page content
A comparable project can be found under mw:ResourceLoader. Maybe it needs to be reevaluated.
@Guy Macon:: some of the subtlest and most crucial performance engineering is already being done by volunteers who optimize and refine Lua modules, so there is good precedent for editors making a positive contribution to site performance, and I'm happy to see this affirmed in your proposal. Could you elaborate a little on how you imagine this working out? What sort of things would you eliminate to reduce page weight? I suspect that the biggest impact could be made by conducting an audit of on-by-default gadgets and site JS / CSS across major wikis and doing some initial triage by ranking gadgets in order of size and popularity. This would be very valuable work, and you would definitely have partners for this work in WMF Engineering. I can elaborate further, but I want to stop and check with you if this is consistent with what you had in mind, or if I'm missing the mark. --Ori Livneh (talk) 21:45, 30 May 2015 (UTC)[reply]
┌─────────────────────────────────┘
I would love to help the WMF in any way that I can in this area.
Before I get into the details of what I have in mind, I want to make sure that everyone reading along understands that this only concerns number of HTTP requests a page makes and the total number of bytes sent to the browser (the page weight). It has nothing to do with how hard Wikipedia's servers have to work to generate those HTTP requests and bytes of data. The gold standard is low page weight on the first access to a page, but making it so that subsequent accesses get as much data from local cache instead of from Wikipedia's servers is also an important factor in reducing page weight. Also optimizing for mobile (optimizing for a small screen, no mouse/keyboard, low-power CPU, and moderately limited bandwidth) is not the same problem as optimizing page weight (optimizing for severely limited bandwidth and nothing else). I cannot emphasize this strongly enough.
The above is a good description of the general idea I have in mind, but I would go about it in a somewhat different way. First I would split the problem into two problems:
Reduce page weight without changing anything that is visible to the user.
Reduce page weight by changing what the user sees.
Work on the second problem should be delayed until we have done all we can to solve the first problem.
Next, I would look at a few of our most-accessed pages (especially the main pages at www.wikipedia.org and en.wikipedia.org) and analyze exactly how many HTTP requests and bytes of data it takes to display them. Do those gadgets and JS / CSS add a lot of bytes? Or are the images a larger problem? Is there any place where we can replace two HTTP requests with one? Measure first, then optimize where it does the most good.
I am going to break my own rule now and talk about optimizing the talk page you are reading. I am doing this because every time I bring this up someone inevitably says that Wikipedia is already doing pretty much all that it can to reduce page weight. I am not implying that the following should or should not be a high priority before we do the measuring I discuss above.
Even simple text-based pages such as this talk page can be optimized.
Consider the following snippet from the thread above:
[...] Maybe it needs to be reevaluated.
-- Menner (talk) 16:14, 30 May 2015 (UTC)
@Guy Macon:: some of the subtlest and most crucial performance engineering is already being done [...]
That's 180 displayed characters, plus whatever it takes to make the links, bold, etc. work.
The wikimarkup for the above is really quite compact:
[...]Maybe it needs to be reevaluated.
: -- [[User:Menner|Menner]] ([[User talk:Menner|talk]]) 16:14, 30 May 2015 (UTC)
:{{Ping|Guy Macon}}: some of the subtlest and most crucial performance engineering is already being done[...]
That's 225 characters, and you get the the links, bold, etc.
<dd>@<a href="/wiki/User:Guy_Macon" title="User:Guy Macon">Guy Macon</a>:: some of the subtlest and most crucial performance engineering is already being done [...]
Now we are at 406 bytes sent to the browser (ignoring compression for the sake of argument, because I would have to post what looks like random garbage above. When we do the measuring, compression should be taken into account).
So, can we reduce that page weight?
First. every line sent to the browser has a DOS-style carriage return and line feed (OD OA) as a line ending. If we used a Unix-style line feed (0A) that would save one byte on every single line of HTML on Wikipedia.
Actually HTML works just fine with both the carriage return and the line feed removed, but it isn't as readable for geeks like me who look at the raw HTML output. This is easily addressed by making the HTML line ending configurable in the preferences.
OK, how about that "title=" in the link? Can we get rid of that?
So right there we have a bunch of useless bytes sent to the browser for every signature. They have zero benefit to anyone. All they do is increase the page weight.
I could go on and on with other obvious ways to optimize this page without changing what the user sees, but again, the first step is to measure the page weight of various pages and identify where we will get the most benefit for the least effort.
I am open to help WMF in any way that I can in order to make this happen. I will tell you, though, that measurable goals and a schedule are non-negotiable. I have worked on too many engineering projects to let my name be associated with a project that lacks measurable goals and a schedule. See [ http://www.guymacon.com/structuredengineering.html ] for some reasons why. --Guy Macon (talk) 08:40, 31 May 2015 (UTC)[reply]
You are presenting data that (correctly) claims that for those of us in the first world with adequate internet bandwidth there are more important things than HTML requests and byte counts, but you have completely failed to address my argument that in rural third-world areas with severely limited bandwidth high page weight makes websites completely unusable. Try using a 1200 baud dial-up modem with its typical 300ms latency to connect to the Internet and see how you like trying to access websites with a high page weight. --Guy Macon (talk) 19:38, 31 May 2015 (UTC)[reply]
It isn't true. In urban third-world areas the Internet is basically accessed with mobile devices. Once you get out of the range of cell phone towers and (relatively) high incomes, the Internet is largely accessed by a village-full of obsolete laptops all sharing a single Wifi connection with an extremely limited-bandwidth connection to the rest of the world. Read the Page Weight Matters essay at the top of this thread. Those Youtube users almost certainly were not using phones to access the net. Low bandwidth Wikipedia access and mobile Wikipedia access are two separate problems. Mobile has somewhat limited bandwidth, small screens, no keyboard, and slow processors designed to extend battery life. Low bandwidth has extremely limited bandwidth, with typical older laptop screen size, processor and keyboard/mouse. --Guy Macon (talk) 00:32, 8 July 2015 (UTC)[reply]
This doesn't sound like it's in the scope of the Community Tech team. I believe Ori has been working on this recently, though. Kaldari (talk) 18:01, 7 July 2015 (UTC)[reply]
Is that a personal opinion or are you speaking on behalf of the WMF? And can you point to the description of exactly what would be "in the scope of the Community Tech team"? Oh wait, there isn't one. Didcot power station (talk) 19:19, 7 July 2015 (UTC)[reply]
This is just the standard WMF stonewalling technique. When anyone posts any sort of proposal -- even in places specifically designated as being for proposals -- a WMF employee tells him or her that it was posted in the wrong place with no indication as to where the right place might be. Sometimes, just for variety, they suggest another place and then you get stonewalled when you go there. Its all very predictable after you have experienced it a half a dozen times. --Guy Macon (talk) 00:32, 8 July 2015 (UTC)[reply]
Indeed, it is just two years since this was illustrated at MediaWiki [1]. And every time it happens it demonstrates that this "Community Tech" process is a sham. We were told recently [2] by a WMF employee that "no WMF employee will say much on behalf of the Community Tech team before the Community Tech team lead is hired and announced". Yet Kaldari, a WMF staff member, tells us what the scope of the project is. So I challenge them, give us some reason to believe that this project is not a huge sham by publishing the scope here and now. No real project would be set up and staffed without someone, somewhere, having a clear idea about scope. If there is a scope, publish it. If not, why not, and why is he trying to put off volunteers by making guesses about what it might be? Didcot power station (talk) 06:47, 8 July 2015 (UTC)[reply]
If we want this page to be useful, we need to add ideas... but also remove them when they can be addressed better elsewhere. Reducing page weight fits squarely within the scope of the Performance team lead by Ori Livneh, who added a comment above. This interesting proposal is getting into deep details, and it deserves a more productive context for discussion and work than a segment in a huge wiki page with many unrelated updates. I have created phab:T105136. There you can subscribe, capture what matters in its description and you can find or create subtasks, blockers, related tasks.--Qgil-WMF (talk) 11:11, 8 July 2015 (UTC)[reply]
Frequently Unanswered Questions about this proposaledit
In the HTML that Wikipedia sends to the browser, every line sent to the browser has a DOS-style carriage return and line feed (OD OA) as a line ending. If we used a Unix-style line feed (0A) that would save one byte on every single line of HTML on Wikipedia. Actually HTML works just fine with both the carriage return and the line feed removed, but let's just discuss (OD OA) vs (OA) for now. We could do this by making the line ending configurable in nthe preferences with the default (OD OA) and (OA) an option, then after we are sure there are no bad effects, change the default. Why am I unable to get anyone at the WMF to discuss the merits of doing this? --Guy Macon (talk) 00:26, 8 July 2015 (UTC)[reply]
So right there we have a bunch of useless bytes sent to the browser for every signature. They have zero benefit to anyone. All they do is increase the page weight. Why am I unable to get anyone at the WMF to discuss the merits of doing this? --Guy Macon (talk) 00:26, 8 July 2015 (UTC)[reply]
There are gadgets/user scripts that rely on that. Mostly because a link can be a redirect. Navigation popups uses this for instance. Perhaps we can output them only when there are redirects, but still those scripts relying on it's presence will break. —TheDJ (talk • contribs) 21:55, 12 July 2015 (UTC)[reply]
It would be great to have some storage for pages metadata. For example, there are different projects in wikipedia, and currently status and priority of an article within a topic are stored on talk page in templates like en:Template:Vital article. It would be easier to manipulate and analyze such data if it is stored in something like Wikidata. But this data is helpful only for specific wiki, so thats my idea: local Wikibase for each wikimedia project! --AS (talk) 16:42, 27 May 2015 (UTC)[reply]
MediaWiki no longer includes hit counters in core, following a request for comment, which means that Special:PopularPages and the "Most Viewed Pages" section of Special:Statistics are now removed. The hit numbers, which occurred until the 1.25 upgrade was installed, will still be kept in the database, but they will no longer be updated. It is planned to re-implement this functionality in an extension.
How is this relavent to community tech. The hitcounter feature was not used on wikipedia, and is inherently unsuitable to the architecture that wikipedia (and other wikimedia wikis) use. Thus its not in scope of the community tech team, at least as I understand their scope. (However, to answer your question, User:MarkAHershberger was working on this I believe). Bawolff (talk) 04:18, 10 June 2015 (UTC)[reply]
I have been contributing to nl.wiktionary for a long time and I am now trying to overhaul the en.wikibook Dutch that I wrote a long time ago and I am very frustrated at how primitive and inadequate wikisoftware is when it comes to interactivity, even such passive interactivity where readers can push a simple button to hear the pronunciation of a word.(Let alone the kind of interactivity of websites like Memrise or Quizlet, I'm not even talking about that. In fact instead I send my readers to Quizlet to go practice there, because I don't have much hope that wiki will ever be able to do what they are doing.)
First of all it took years before it became even reasonably feasible to upload pronunciation files to commons. Luckily that has been streamlined enough that there is a treasure trove of sound files there. But now the question is whether you can actually use them. The only way that I have sound that comes even close to what I need to let people learn some language from my page is
[[file:nl-geweldig.ogg|noicon|40px]] geweldig
resulting in
geweldig
All other templates like audio etc. either result in something HUMONGOUS or in something that abducts my readers away from the text I want them to read while listening, to some primitive black screen.
Even the simple arrow as above has its problems. It is still too big and it does not match the size of a line of text. It cannot be used inside a piece of text and the only way I have found that suppresses the automatic line feed is to put in "left"
Unfortunately, you can only do that once, otherwise you get a mess
noicon geweldig noicon geweldig
So, the logical thing would to put it in a table, but look what happens inside a collapsible wikitable, which apparently doesn't work here, so please follow me to the french wikibook and open the two boxes saying "Solution" to see what I mean. Also look at the convoluted way I put all my arrows in. It was necessary, I assure you otherwise the mess is even greater. I spent an hour trying to defeat this wonderful software..
So my tech idea? To actually start worrying about how primitive this wonderful software is. Am I insulting you with that? Then please look around on the internet and you will find videos that start whether you want them to or not or websites that suddenly start talking to you and ask for your input. You don't even have to push a button...
To be honest, it was difficult to understand what your actual complaint was (Other then that our support for audio/video multimedia sucks, which I think everyone agrees with). After reading a couple times, you basically want an inline play button for audio files, in order to make something more like:
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
I've got good news on this one :) TCB, Wikimedia Deutschland's Community Tech team, has been working on a Category watchlist, and we should see the first deployments within the next few weeks. You can check out the Phabricator ticket for more details. -- DannyH (WMF) (talk) 22:54, 18 November 2015 (UTC)[reply]
Add a category watchlist feature, that lists all changes, additions to, and removals from a category. En-Wiki has HUGE maintenance backlogs dating back to 2006 or earlier in categories like Articles lacking sources. I don't think those backlogs would be as bad if we could watchlist categories and know when an article was added to them. Likewise, some articles have a significant overlap, and if interested editors could watchlist categories and see when new articles were added to categories it would help avoid unnecessary duplication of content. ONUnicorn (talk) 14:11, 8 November 2015 (UTC)[reply]
This is currently being worked on right now by the German TCB Team and will be made available in the coming months. See the linked ticket for details. I Endorsed this, by the way, if Community Tech can help get this out the door faster. MER-C (talk) 14:19, 8 November 2015 (UTC)[reply]
Oppose calling this a new "Community Tech project". This is obvious very valuable, but it appears to be completed, deployed, and awaiting routine-review(?) to flip the on-switch. Alsee (talk) 13:11, 15 November 2015 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Alerts are for matters that require urgent attention, like mention in a discussion or proposed deletion of a picture I uploaded. It is sad that I almost always see these alerts when I happen to come back to that particular wiki, where it is usually too late. Syced (talk) 07:30, 11 November 2015 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Develop tools to convert Flow and LQT pages to normal talkpagesedit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
If that hypothetical scenario ever did become true, the proposed tool would be fully-developed. The WMF has a duty and intends to maintain or improve the extension, and that extends through all the standard software life-cycle phases. Quiddity (WMF) (talk) 00:38, 14 November 2015 (UTC)[reply]
In the not too distant future the Flow project will be abandoned and people will be forced to admit that it failed (just like LQT). When the inevitable happens, we need to have a way to convert the messy and unreadable Flow and LQT pages back to talkpages. The Quixotic Potato (talk) 05:46, 21 July 2015 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Statistics on gadgets usage (number of users like for beta-functions). It is currently unclear, which old gadgets should not be maintained anymore. --AS (talk) 09:26, 30 May 2015 (UTC)[reply]
Endorsed I think, that beta features and gadgets are quite different story, but yes, it would be nice for developers to see, which gadgets are used more (are more popular), so they can be developed more. --Edgars2007 (talk) 07:27, 31 May 2015 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
It would be nice to have special area where JS scripts can be placed. That could be a namespace like script: and only users with assigned rights can edit them. This scripts will be executed by every visitor of that page.
In a more relaxed scenario these script pages might be embedded into common wikipages like templates similar to LUA.
The advantage over imported commons:COM:User Scripts is that it requires no obscure technical methods before the scripted features can be used.
An example might be to realize advanced search bars, special upload tools, diffrent kind of calculators, template filling forms with wikitext generator or in my case a replacement of commons:com:SVG Check and maybe other tools that currently require specific wmf tool server.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
It would be nice to be able to search one's contributions by edit summary or such. For example, I label my proposed deletions as such, and then I check on them once or twice a year. Currently I have to look at 1000+ entries, and do a search for them using a browser function. Would be nice if this was doable through the contributions page itself. --Piotrus (talk) 05:04, 10 November 2015 (UTC)[reply]
User:Edgars2007: wow, I never noticed that. Ha. Thanks. Through in this case I'd revise my request to: make the tool work faster. It's been chewing on my query for several minutes now... (Finished: Elapsed time: 332.21 seconds. ) --Piotrus (talk) 03:28, 12 November 2015 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Work on this proposal is currently underway by the Wikidata team, and we should see the first user-facing results of that work in early 2016. I'm sure the Wikidata team is cheered by the level of support shown for this proposal. :) -- DannyH (WMF) (talk) 20:34, 24 November 2015 (UTC)[reply]
We should resume the Structured metadata for Commons project. A lot of the problems Commons currently faces come from the fact that MediaWiki is not a very suitable content management system for media files. With structured metadata it does become a much more flexible and scalable content management system. All user groups would benefit from a better functioning Wikimedia Commons: It's easier to find suitable images, easier to classify images, more accessible, etc. Multichill (talk) 18:48, 10 November 2015 (UTC)[reply]
Comment Maybe we could integrate into the Media Viewer some data from wikidata? In this way we could get some experience about what is useful before investing millions of dollars. Molarus (talk) 20:40, 20 November 2015 (UTC)[reply]
Endorsed commons just lacks the structure many other projects have, together with a huge volume of data. Every idea to improve the situation is a good one.--Alexmar983 (talk) 22:59, 21 November 2015 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Besides improving SVG rendering it would be useful to have a "SVG Help Button". Like the Media Viewer button it could be placed below SVG files on Commons media meta pages visible only for loged-in users. Because SVG itself as a non-WYSIWYG format has many pitfalls, it is important to give guidance to contributors.
Until end of 2015 I'll make a prototype with an idea of its look and feel based on user scripts.
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Wikitext paste conversion tool interferes with table pasting from MS Word for one user(?)edit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
And this is the big problem. Any one can understand that before I was doing only copy and past. Now I will have to make a wikitable every time. So I have put this wish into https://phabricator.wikimedia.org/T117859 here. But this bug has "Low" Priority. I have seen history of phabricator and bugzilla. There are numbers of bugs which have "Low" priority and they filed before 4 year and 5 year ago. I thing this problem will harm sa.wikipedia and slow sa.wikipedia's speed. Moreover "for one user(?)" this portion signs that it bug will never solved. I personally have 700+ tables to paste in sa.wikipedia. So my wish to solve this bug as soon as possible. We are small community and this is the biggest problem fort of us. This is not for only one user but all sa.wikipedia. We wish to solve it.NehalDaveND (talk) 07:08, 11 November 2015 (UTC)[reply]
More information is necessary to reproduce this. As far as I know there haven't been any copy/paste changes in the past few weeks. Cscott (talk) 19:40, 11 November 2015 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
This extends the autoblocker such that a cookie is placed when a user is blocked, and triggers the autoblocker when such a cookie is detected. This impedes shifting IPs (sometimes unintentionally) to evade blocks. MER-C (talk) 01:50, 8 June 2015 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Now that SUL finalization is complete, there is no longer an obvious obstacle to developing a proper cross-wiki watchlist. This is a very old request (phab:T5525 from September 2005) and has been cited as one of the reasons why users on, say, Wikipedia are reluctant to branch out and participate on Meta, Commons, etc. There has been an effort to develop this as an external OAuth tool (phab:T92955), but it really should be developed within MediaWiki itself, dovetailing in with the existing Special:Watchlist page in some manner. This, that and the other (talk) 10:05, 17 July 2015 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Generate automatic summary /* blah */ when I manually add a new section heading when editingedit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Global, shared gadget list users can pick fromedit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Yes, I know if you put your gadgets on meta it gets to all wikis, but this is not user friendly and has a lot of RTL issues all over the place. Matanya (talk) 22:46, 19 May 2015 (UTC)[reply]
Endorsed And they need to be live searchable, so there is no reason to restrict on publishing gadgets, because "the preferences section already has 60 of them". —TheDJ (talk • contribs) 06:55, 20 May 2015 (UTC)[reply]
We need a whole package of add ons (such as template and gadgets) that Wiki's can opt into and which are supported by the WMF. I love WikEd for example but it is not an option on many Wikis and thus if I want to use it I need to copy the content to En Wiki first. Doc James (talk · contribs · email) 04:08, 22 May 2015 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
A lot of effort goes to duplication of templates all along different wikis. It would be ideal if certain / many of them would be available under a Global Template wiki, with multilingual support by Wikidata. --FocalPoint (talk) 21:51, 13 November 2015 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
This is me working on librsvg. I've fixed five long term bugs in five days. SVG is everytime a problem when I draw a scientific graphic. Detailed analysis isn't done yet. Currently I'm trying to get some important fixes into latest gnome release before next freeze. Anything else would mean years of waiting. -- Menner aka 2A02:810D:1740:1554:D50D:D2D:256C:10D417:49, 27 May 2015 (UTC)[reply]
Endorsed +1 It is absolutely annoying, time and resource wasting for everyone is willing to share SVG. Take simply a look on Commons, many SVG have an flooded crappy file-history (and then sometimes unused and dead or replaced by pixel-graphics). ↔ User: Perhelion13:24, 3 July 2015 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
As stated in the Survey description, "A proposal that duplicates or conflicts with items on another WMF team's roadmap may be flagged by the Community Tech team, and not included in the voting phase." The Collaboration team is responsible for Flow, and Community Tech isn't going to override their plans. Proposals for disabling Flow will not be included in the voting phase. Concerns about Flow and the Collaboration team's roadmap should go to the Collaboration team; this page is not an appropriate place for discussing them. DannyH (WMF) (talk) 19:30, 15 November 2015 (UTC)[reply]
I'm not sure how to migrate existing talk page to something like mw:Extension:Flow, but it would be helpful. Current page-like-editing is not user-friendly for newbies :( --AS (talk) 16:51, 27 May 2015 (UTC)[reply]
Some years ago, the community identified four desirable improvements to talk page editing, all of which can be done in MediaWiki using Wikitext (and hypothetically could be extended also to VE editing). They are:
automatic signatures on talk page entries (easily done, we have bots that do it now - Flow automatically appends the username, not the user signature)
a button on the editing toolbar to automatically and correctly indent a post in a discussion and automatic outdenting after a certain number of indents (both also fairly easily done - on last looking at Flow, the indentation scheme made most threads almost unreadable)
more graceful edit conflict management (significant work on this has already been done - this is the only thing Flow is better at, but that is because it literally creates a new page for each entry)
ability to watchlist an individual thread or discussion (this is a challenge for wikitext, but Flow's current solution seems to be that you have to watchlist individual threads on a 'page' in order to see changes to that thread, which essentially deprecates watching entire 'pages')
It escapes me why we have gone on to create a *third* user interface that new users would need to learn in order to be full participants in their editing communities. (In fairness, VE is optional on most projects.) Even if Flow was fully implemented on all talk pages, users would still need to use wikitext for a large number of workflows such as deletion discussions (where Flow would actually impede the work with its method of data storage), many discussion boards, requests for comment, requests for adminship, and dozens of other places. Adding another user interface adds complexity, it does not make things easier for new users. What it does is marginalize them, because it makes it that much harder to learn how to participate in almost all of the areas where input from community members is important. If it weren't for the fact that VE prevents people from adding signatures (and blocks a few other key wikitext functions), I'd say just go with permitting VE on talk pages. In fact, I think it would be fiscally more efficient to figure out how to add these features to VE dependent on namespace, rather than invest further in Flow. Risker (talk) 22:26, 23 July 2015 (UTC)[reply]
I think this is one of the points where exposure of the WMF software development roadmap to the community would be useful. Currently the Flow Portal shows the roadmap ending at 2014-15 Q4, ie at the end of last month. (I may say that the paragraph there beginning The roadmap items that appear below are guesses does not exactly fill me with confidence.) Questions have been asked of the ED as to her plans for Flow, but that discussion remains unresolved. It is hard for the community to make sensible proposals for improvements or new features if it is not told what the software base is expected to be, nor what the design criteria are, nor when, if ever, it is to be delivered. Rogol Domedonfors (talk) 10:16, 24 July 2015 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Show additions or removals of items from categories on watchlistsedit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
It would be good if there was an option to have additions to watchlisted categories, or removals from it, appear as watchlist notifications for a watched category. Jheald (talk) 12:38, 13 November 2015 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Unfortunately, it is not clear whether all communities will get Flow in near future. And even if so, it will certainly not replace all talk pages. WMF has realized that Flow is a good piece of software, but also far away from being a solution for all talk pages. We will therefore have to continue to deal with regular wikitext talk pages for quite some while. This proposal needs endorsement. —MisterSynergy (talk) 11:44, 12 November 2015 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Edit summaries are currently limited to 255 bytes. This is a pain for non-English editors, where one UTF-8 character consumes at least two bytes. MER-C (talk) 06:29, 3 July 2015 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Tell prospective users what Wikipedia is not foredit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
The problem: prospective users get no explanation before they sign up of what Wikipedia is for, and more importantly what it is not for. They know "anyone can edit", and suppose that means "anyone can post whatever they like". Therefore very many new articles are posted which have no hope of becoming encyclopedic: non-notable Facebook-style autobiographies, CVs, company advertisements, copies of promotional websites, puff pieces about garage bands...
Who would benefit:
Prospective Wikipedia users who are really looking for a social-networking site or an advertising platform would be spared wasted effort and disappointment.
New page patrollers and administrators would be saved unproductive, tedious and repetitive work deleting unsuitable pages and explaining, over and over again, why Wikipedia is not for what the disappointed newbies wanted to do.
If the flood of no-hope new articles were reduced, more time and attention could be given to those newbies who really want to contribute but need guidance.
With fewer disappointed newbies out there, Wikipedia might lose some of its reputation for being unfriendly.
Proposed solution: the sign-up page you get on clicking "Create account" should say something like:
"Wikipedia is a project to build an encyclopedia. It is not a social-networking site, or a free platform for promotion. If you want to help build the encyclopedia, you will be very welcome; but if what you want to do is tell the world about yourself, your friends, your company, your client, your band, your good cause or your new original theory, this is not the site for you to do that."
For those who want more explanation, a link could be provided to a page giving brief summaries of the policies on autobiography, notability, advertising and conflict of interest. My experience of this problem is on en:wp, but I expect others have it, too: each project should be able to decide what message, if any, to display on the sign-on screen.JohnCD (talk) 09:27, 21 November 2015 (UTC)[reply]
Endorsed Agree totally with the importance of at least attempting to tell people what they are signing up for. Rather than say "build an encyclopedia" twice, I would try to explain briefly what we mean by this - even at the expense of making the message longer. After getting the "not" part out of the way, we could say: "You are very welcome to sign up if you are interested in improving existing Wikipedia articles, or adding new articles about widely significant topics. We try to make sure that all information is reliable and well-written. You can find out more here [link to WP:Contributing to Wikipedia]" Noyster (talk) 18:08, 21 November 2015 (UTC)[reply]
@The wub:Unfortunately the link you give is to an announcement that the page was deleted by User:Amire80 on 30 Sept 2015 for reason "identical to source". Could either of you help in identifying the "source" that this page was identical to? Thank youNoyster (talk) 17:16, 28 November 2015 (UTC)[reply]
Support Seems like a good idea, so long as the message is diplomatic and unambiguous. I think it might be better to provide links to Wikipedia content guidelines rather than a direct message to new users. Sort of, trying to show prospective users what's expected of them, rather than discourage people from joining altogether. -- 2ReinreB2 (talk) 17:29, 1 December 2015 (UTC)[reply]
Support the need to do something, but Oppose the proposed solution as it comes off snotty and condescending. In its place, I would propose stating what's expected of editors in a professional tone, with appropriate links to details. E.g., "Wikipedia editors from the very new (like you!) to the most experienced are engaged in the serious editing of a comprehensive, high-quality encyclopedia (link 'encyclopedia', as many may not even know what an encyclopedia is and what it should be.). Newly created articles are expected to be about notable subjects. Edits to existing ones are expected to be..." Stevie is the man!Talk • Work18:29, 1 December 2015 (UTC)[reply]
Oppose, this is just useless. Editors who came here to promote something will do it anyway, but good faith editors may think we consider them vandals and leave the project before their first edit — NickK (talk) 14:54, 2 December 2015 (UTC)[reply]
Support As a one-time popup, it can be written in a nice, encouraging way that doesn't put people off. This won't end the problem, not even close, but if it cuts it by 20% or even 10%, that's not a bad return. Even 5%. It has to be friendly and very readable, not like those stupid EULA's that nobody reads and we all just click OK. Like, have the window say what WP is and is not, and then have new users click on "I want to help make a great encyclopedia" or "I want to meet people who share my interests", or something broader. Just so it doesn't look like an automatic step. Dcs002 (talk) 12:25, 3 December 2015 (UTC)[reply]
Neutral. I like the idea, but it's not necessary to bring this to the Foundation's Technical Team, it can be solved locally by tech voluntaries. So I don't want to waste 1 of the 10 projects the Technical Team will implement.--MisterSanderson (talk) 15:53, 3 December 2015 (UTC)[reply]
Oppose We don't need to talk about our own history as yet another hurdle to take for someone interested in contributing. Let them come contribute with as few barriers as possible. --Jane023 (talk) 16:32, 4 December 2015 (UTC)[reply]
Oppose totally pointless, every test in the past and has shown that it only confuses good faith people, makes them scared and doesn't actually teach them anything, while bad faith people just ignore it and do there thing anyways. —TheDJ (talk • contribs) 22:53, 5 December 2015 (UTC)[reply]
Support hundreds of new pages each day from people who are not "bad faith", they simply have no idea what distinguishes WP from any other website. Like others, though, I would prefer a more positive wording (see my suggestion under "Earlier discussion"). Noyster (talk) 13:40, 7 December 2015 (UTC)[reply]
Comment Note that there are different rules which kind of space 
Oppose adding a scarlet letter so that people assume bad faith is a terrible idea. Beeblebrox (talk) 00:36, 10 November 2015 (UTC)
Endorsed this, by the way, if Community Tech can help get this out the door faster. MER-C (talk) 14:19, 8 November 2015 (UTC)
Resolved. now there is Special:GadgetUsage at each project. --Edgars2007 (talk) 11:25, 12 November 2015 (UTC)
Support. Szalakóta (talk) 16:57, 1 December 2015 (UTC)
Neutral. It could be useful in some cases but not sure it does not have negative consequences in some other cases. Beagel (talk) 14:56, 12 December 2015 (UTC)