Khảo sát Mong muốn Cộng đồng 2015/Khác

Voting has CLOSED! Thanks for your votes!

Khả năng bật trình chỉnh sửa mã riêng biệt với "thanh công cụ chỉnh sửa nâng cao"

Tracked in Phabricator:
Task T47850

Đối với tôi "thanh công cụ chỉnh sửa nâng cao" chỉ hữu ích vì trình soạn thảo mã, vì vậy tôi muốn nó được kích hoạt cho tôi chỉ trong trường hợp tôi đang chỉnh sửa trang lua / javascript / css --AS (talk) 09:31, 30 May 2015 (UTC)

Earlier discussion and endorsements
A code editor appears whenever you want to edit a Lua / JavaScript / CSS page regardless of your "enhanced editing toolbar" preferences, isn't it? I believe this is true at least in mediawiki.org.--Qgil-WMF (talk) 08:34, 9 June 2015 (UTC) No, the code editor is part of the enhanced toolbar (integrated into the WikiEditor extension). Disabling it will disable the code editor. Bawolff (talk) 04:12, 10 June 2015 (UTC) Understood, thank you. I could not find a task corresponding to this request in Phabricator. If it is created, it should go under phab:tag/wikieditor/.--Qgil-WMF (talk) 07:55, 10 June 2015 (UTC) phab:T47850? Helder 18:24, 10 June 2015 (UTC)  Endorsed --Edgars2007 (talk) 11:39, 12 November 2015 (UTC)

Phiếu

1.  Support --AS (talk) 09:44, 3 December 2015 (UTC)
2.  Support --Edgars2007 (talk) 09:01, 12 December 2015 (UTC)

Trích dẫn: Chia sẻ: Xuất

Tôi đề xuất hợp nhất và thay thế nhiều mục khác nhau trên thanh bên, đáng chú ý là phần "in / xuất", sẽ giúp ích cho khả năng chia sẻ / khám phá các bài viết và cũng giúp giải quyết vấn đề về truyền thông xã hội trong Wikipedia: được gọi là công cụ "Share | Cite | Export". Khi nút được bấm, nó sẽ mở một hộp thoại sạch / đơn giản trên đầu trang để cung cấp 3 nhóm / tab tùy chọn rõ ràng. Cộng đồng địa phương trên mỗi wiki có thể xác định yếu tố nào họ muốn đưa vào mỗi nhóm.

Nhóm 1 sẽ được trích dẫn và điều này sẽ có ít hộp thả xuống cho bất kỳ định dạng mong muốn - Harvard, BibTeX, MLA, Zotero ... Điều này cũng sẽ có một liên kết rõ ràng đến một trang tài liệu như w:Wikipedia:The_Wikipedia_Library/Research_help

Nhóm 2 sẽ là Chia sẻ . Điều này sẽ có:

• liên kết ổn định đến phiên bản hiện tại
• URL ngắn
• Mã QR (mã QRpedia lý tưởng)
• Chia sẻ liên kết cho bất kỳ nền tảng truyền thông xã hội phổ biến nào có liên quan. Trên Wikipedia tiếng Anh, điều này chắc chắn sẽ bao gồm Twitter và Facebook, nhưng trên Wikipedia tiếng Trung này chắc chắn sẽ bao gồm Weibo, v.v.

Nhóm 3 sẽ xuất và sẽ bao gồm các tùy chọn hiện tại trong phần 'in / xuất' của thanh bên:

• Phiên bản có thể in
• Tải xuống dưới dạng PDF
• Tạo sách
• Công cụ 'thu thập' cũng có thể đến đây [Tôi không chắc nó tương tác như thế nào với chức năng 'danh sách theo dõi' hoặc 'tạo sách' thành thật ...]

Thiết kế trực quan của hệ thống này, thứ tự của các nhóm và thứ tự của các nhóm trong tất cả các nhóm sẽ cần phải có một số nghiên cứu nghiêm trọng về UX vì điểm này vừa là một điểm dừng để chia sẻ mà còn trực quan và không áp đảo người dùng bằng tài liệu. Wittylama (talk) 10:44, 21 November 2015 (UTC)

Earlier discussion and endorsements
Endorsed --Jane023 (talk) 14:41, 21 November 2015 (UTC)

Phiếu

1. Comment Comparing your proposal to the current system (at least at en.wikipedia.org), there are currently five links on the left: (1) "Cite this page", which is virtually identical to your Group 1 (or could be made identical with minor tweaks; essentially no programming required; (2) "Permanent link", which is one of four items in your Group 2; and (3) through (5) - three links in the "Print/export" section, which are essentially your Group 3. So you're basically proposing (your Group 2) to add some sharing options. Plus, rather than the reader seeing five links, you want to start with one, which opens a dialog box showing three choices (tabs) - your three groups, which then further expands, depending on the tab chosen. John Broughton (talk) 04:35, 1 December 2015 (UTC)

   Correct, the primary work here is in interface improvements and design, not in technical difficulty. Bringing together related types of actions that are currently spread across the sidebar and/or exist as external tools, and enabling the community to determine the order/composition of these actions, will simplify the user-interface thereby encouraging more and better quality (in terms of attribution etc.) sharing of our content. Wittylama (talk) 15:26, 1 December 2015 (UTC)

2.  Support this conceptually although certainly the implementation details could end up somewhat different. I've been wanting easy ways to share articles to social media platforms for a long time. Stevie is the man! ^{Talk • Work} 19:17, 1 December 2015 (UTC)
3.  Support Trizek ^{from FR} 22:10, 1 December 2015 (UTC)
4.  Support Theredmonkey (talk) 19:10, 3 December 2015 (UTC)
5.  Support --Jane023 (talk) 16:35, 4 December 2015 (UTC)
6. Comment The idea is good, and I would probably support it in general. But I think the proposed name of the tool would cause problems with localization. For example, I've tried to choose the shortest translation of it into Ukrainian, but still it is too long to fit the sidebar width.--Piramidion 20:01, 4 December 2015 (UTC)
7.  Support - Bcharles (talk) 02:00, 9 December 2015 (UTC)
8.  Support --Tgr (talk) 22:21, 13 December 2015 (UTC)
9. Comment I think it's not a good idea to make easy to share Wikipedia articles on Chinese media, because of the high surveillance of internet. What's the meaning of adding forced HTTPS, but allow anyone to discover that you were reading "anti-government" articles?--MisterSanderson (talk) 03:29, 14 December 2015 (UTC)

Cách hợp tác để tạo các đồ thị SVG / PNG sử dụng các mô đun Lua

Tracked in Phabricator:
Task T66460

Extension:EasyTimeline thiếu một số tính năng cần thiết và không hỗ trợ khả năng hiển thị văn bản phức tạp cần thiết cho các tập lệnh khác với tiếng Latinh. Cộng đồng Wikipedia cũng tạo ra các biểu đồ cây gia đình được chế tác bằng tay, ví dụ: en:Template:Inglis family tree, sử dụng các bảng HTML hack. Bây giờ chúng ta có hỗ trợ ngôn ngữ lập trình thích hợp trên wiki wiki, sẽ rất tuyệt nếu biểu đồ SVG / PNG có thể được tạo bằng cách sử dụng kịch bản Lua hoặc wikicode bởi cộng đồng, giống như mw:Extension:Inline SVG extension nhưng được cập nhật và sẵn sàng sử dụng, hoặc áp dụng một trong những ràng buộc Lúa của thư viện đồ họa Cairo. --ebrahim^talk 23:16, 9 November 2015 (UTC)

Earlier discussion and endorsements
Endorsed --Ilya (talk) 23:26, 9 November 2015 (UTC) There is also the recently introduced Extension:Graph, it's not IMHO very user friendly, but work was done on de.wiki to generate simple graph using Lua and Graph extension (see de:Modul:Graph and imported in other wikis.--Moroboshi (talk) 13:35, 10 November 2015 (UTC) It's not user friendly because it's backed by Vega which is a pretty complicated visualization grammar that can do anything. Have you looked into Lyra (which is a GUI editor for Vega) and Vega Lite (which has a much friendlier but more limited syntax)? Curious if those would help make the Graph extension more useful, and happy to help make them a reality. Milimetric (WMF) (talk) 13:41, 11 November 2015 (UTC) There should be better support for Graph extension in Lua modules - pie charts aren't supported, as far I understand, at least, they aren't included in documentation. And better help/documentation for Graph extension at Wikipedia/Meta Wiki. --Edgars2007 (talk) 11:31, 12 November 2015 (UTC)

Phiếu

1.  Support Making image generation easier might also facilitate the reuse of Lua-generated material - and improve the illustration on the Wikimedia sites.Jo-Jo Eumerus (talk) 20:11, 30 November 2015 (UTC)
2.  Support--Shizhao (talk) 09:38, 1 December 2015 (UTC)
3.  Support Perhaps this is not explained well but just consider if we could get rid of hand crafted statistical/heat maps, or be able to make multi language diagrams without manually touch and reuploading them. This all would be possible if something like what Lua did to templates would happen on images also. --ebrahim^talk 11:47, 1 December 2015 (UTC)
4.  Support Eman235/talk 21:28, 2 December 2015 (UTC)
5.  Support 4nn1l2 (talk) 14:56, 3 December 2015 (UTC)
6.  Support Not sure Lua is the right tool for this and also not sure about the security implications of Lua scripts being able to create files, but the idea is worth researching at the least. --Tgr (talk) 22:31, 13 December 2015 (UTC)

Tạo bot để hiển thị các thay đổi trong bài viết cho mỗi WikiProject

• Vấn đề: Tôi đang nghiên cứu các bài viết về gastropods (= ốc sên), Chúng tôi đã có hơn 30.000 bài viết trong Wikipedia:WikiProject Gastropods. Đã có một bot cho các bài viết mới (en:User:AlexNewArtBot/GastropodsSearchResult), nhưng không phải cho các thay đổi được thực hiện trong các bài viết hiện có . Điều này làm cho nó gần như không thể theo dõi những thay đổi và loại bỏ bất kỳ phá hoại có thể. Và điều này đi cho tất cả các WikiProject khác.
• Điều này sẽ có lợi cho tất cả người dùng.
• Đề xuất giải pháp: tạo bot cho mỗi WikiProject, theo dõi các thay đổi trong mỗi WikiProject. Các bài viết trong mỗi WikiProject dễ dàng xác định vì chúng có một mẫu chuyên dụng trên trang thảo luận của họ. JoJan (talk) 14:54, 8 November 2015 (UTC)

Earlier discussion and endorsements
Oppose the proposed solution because it is WMF specific and WMF resources are better utilized improving the core software.  Endorsed a special page like Special:Recentchangeslinked as referred to in phab:T117122, as long as it is shipped with core MediaWiki. MER-C (talk) 15:05, 8 November 2015 (UTC) We certainly very much need something to show changes to articles within a project, however exactly it is done. Invertzoo (talk) 15:23, 8 November 2015 (UTC)  Endorsed a solution which makes tracking changes within a project straightforward. How this is done technically I have no idea. BernardP (talk) 22:58, 8 November 2015 (UTC)  Endorsed a solution which makes tracking changes within a project. --Snek01 (talk) 06:19, 9 November 2015 (UTC)  Endorsed. If somebody is interested there was a tool long time ago in old Toolserver times. Here is the user, but he's not active anymore. --Edgars2007 (talk) 10:16, 9 November 2015 (UTC)  Endorsed - project space and project tagging is either over-done or not at all - anything to create an even playing field and encouragement of a more balanced approach to project work - where ever or how ever :JarrahTree (talk) 00:27, 10 November 2015 (UTC) @JoJan: Would you be satisfied with a solution like the one described in nhiệm vụ T117122 (a special page rather than a bot)? Ryan Kaldari (WMF) (talk) 02:56, 13 November 2015 (UTC) This would be a big step forward. All I want to do is check the changes in articles in all the categories (and these could be many), included within a particular WikiProject. JoJan (talk) 08:07, 15 November 2015 (UTC)

Phiếu

1.  Support The easiest way to implement this is to have a (hidden) watchlist that contains all the articles that "belong" to a WikiProject. (The list of articles is known, for example, by the assessment tool that now produces a summary table of the articles with different assessments, by importance, for each WikiProject.) Then all that's needed is a standard watchlist report (or reports) that can be invoked by anyone, which uses the (hidden) watchlist. John Broughton (talk) 05:19, 30 November 2015 (UTC)
2.  Support Lugnuts (talk) 12:06, 30 November 2015 (UTC)
3. I support implementing phab:T117122 (adding a "Associated namespace" checkbox to Special:RecentChangesLinked), which is the generic solution. By the way, on the French Wikipedia, the opposite is needed: virtually all articles are linked to a portal, whereas "Wikiprojets" cover only half of talk pages, so people are looking for ways to watch talk pages of articles linked to a given portal. Orlodrim (talk) 20:29, 30 November 2015 (UTC)
4.  Support--Shizhao (talk) 09:38, 1 December 2015 (UTC)
5.  Support --g (talk) 14:43, 1 December 2015 (UTC)
6.  Support - but on many wikis the English Wikipedia system is not used so not an option. Instead based on category tree, group of users on page or something else. This is also useful for users to follow and help other members of a project. Romaine (talk) 14:56, 1 December 2015 (UTC)
7.  Support Sounds like some of the work that en:WP:WikiProject X is working on, Sadads (talk) 15:49, 1 December 2015 (UTC)
8.  Support I like user John Broughton's idea above. I should mention, however, that it is possible to create a watchlist and then manually go check on it. A way to see changes without actually visiting the watchlist would be helpful. (Similar to WP:1.0's WP 1.0 bot, which lists relevant articles by class, without an editor actually visiting each individual category page. -- 2ReinreB2 (talk) 17:34, 1 December 2015 (UTC)
9. Comment I agree with Orlodrim that implementing phab:T117122 is the way to go, although there's already an "Associated namespace" checkbox on Special:RecentChangesLinked, but to my recent astonishment, means only actual category members in the associated namespace. What is necessary is an additional checkbox named "Reveal associated pages". Stevie is the man! ^{Talk • Work} 19:56, 1 December 2015 (UTC)
10. Comment My transcluded changes tool's been working again since September. Dispenser (talk) 06:39, 2 December 2015 (UTC)

    That's pretty cool but unfortunately it appears to not support projects using the WikiProject United States banner. I currently have to build a page with all the WikiProject's included pages and associated talk pages, and I run RecentChangesLinked against that page. Stevie is the man! ^{Talk • Work} 17:54, 2 December 2015 (UTC)

11.  Support Casliber (talk) 13:33, 2 December 2015 (UTC)
12.  Oppose, there is a very easy solution: Special:RecentChangesLinked. You really do not need anything else — NickK (talk) 15:00, 2 December 2015 (UTC)

    Special:RecentChangesLinked doesn't pull in changes in the relevant talk pages. Shouldn't be too difficult to add a checkbox that does this, though. I  Oppose the proposed solution. MER-C (talk) 17:12, 2 December 2015 (UTC)

13.  Support SantiLak (talk) 10:41, 4 December 2015 (UTC)
14.  Support --Edgars2007 (talk) 09:02, 12 December 2015 (UTC)
15.  Support And a smart bot please, one that identifies the removal of the tag and shows this, instead of immediately removing the article from the list because it have no tag anymore. --MisterSanderson (talk) 04:12, 14 December 2015 (UTC)

API / GUI của Trình chỉnh sửa thống kê

Tạo một API và / hoặc GUI có thể hiển thị thông tin như:

• Có bao nhiêu lượt xem trang có các bài viết không chuyển hướng mà Người dùng X đã tạo đã nhận được trong cuộc đời của họ?
• Có bao nhiêu byte văn bản mà User X đã thêm vào tất cả các bài viết trên Wikipedia?
• Người dùng X đã tích cực chỉnh sửa Wikipedia vào bao nhiêu ngày kể từ khi họ tạo tài khoản của họ? Và mức độ hoạt động của họ trong 6 tháng qua ...
• 5 thể loại hàng đầu của các bài viết mà người dùng X đã chỉnh sửa trong cuộc đời của họ là gì? Trong 6 tháng qua?

Tôi nghĩ những điều này và các truy vấn tương tự khác có thể được sử dụng để tạo Trang tổng quan của người đóng góp (cùng với các thống kê khác), điều này thể hiện rất nhiều thông tin tổng hợp về những ai làm gì và bao nhiêu. Mục tiêu sẽ là tạo ra các bức ảnh chụp nhanh về những gì mọi người làm việc trên đó sẽ giúp bạn dễ dàng biết được ai cần liên hệ và người mà bạn đang giao dịch khi bạn tương tác. Nó cũng sẽ phục vụ như là một động lực 'gamifying' tiềm năng bằng cách cho phép các biên tập viên nhìn thấy sự tăng trưởng trong số liệu thống kê của họ theo thời gian. Ocaasi (talk) 17:48, 21 May 2015 (UTC)

Earlier discussion and endorsements
Agree these are excellent ideas. Some of this data is already available on an article by article basis such as here for gout [1]. And the rest of the data could be added to here [2] Clarifying who writes Wikipedia would improve transparency. Doc James (talk · contribs · email) 04:06, 22 May 2015 (UTC) I love this proposal. We worked on making pageview stats publicly available, and that will be announced literally within a day or so. It's not queryable in the exact way requested here, but it wouldn't be hard to add another endpoint. Look out on the Analytics mailing list for an announcement and comment exactly how you'd like it improved. And we're focusing on edit data for the next 6 months at least (making it publicly queryable from a stable API). So the data for this is really close, now we just need some sort of user profile to dump it into, and various teams at the foundation have worked on that. Milimetric (WMF) (talk) 13:34, 11 November 2015 (UTC)  Endorsed This might be related to mw:Extension:SocialProfile, which already has some of these features? Perhaps this task could investigate deploying that extension more widely. cscott (talk) 18:24, 11 November 2015 (UTC) Unlikely, the requests are more similar to mw:Extension:Contribution Scores and mw:Extension:UserDailyContribs. Nemo 09:58, 13 November 2015 (UTC)  Oppose. Contributing to Wikimedia projects is not a game, and should not be presented as such. Points two and three are enough to reject this -- we want quality contributions, and yes, that includes removing content that does not belong. Quality cannot be measured by the number of bytes added or edits made. MER-C (talk) 16:10, 14 November 2015 (UTC)  Endorsed wikidata game is very successful, micro-contributions may be a way forward for mobile. it is unclear that the powerusers want quality, or power. Slowking4 (talk) 04:57, 15 November 2015 (UTC)  Endorsed Gamification is a good way to get new contributors. --Piotrus (talk) 06:47, 16 November 2015 (UTC)  Endorsed Any and all ways to get more information about colleague editors than browsing their recent edits is welcome. --Jane023 (talk) 10:00, 20 November 2015 (UTC) Comment I would endorse filling in any missing API elements so that this is possible to do in an efficient way that doesn't tax the servers, but rather than spending time an energy working on this, leave it up to third party coders to write the user interface. Why? Because I don't see this as being heavily used AND it's not the kind of thing that really needs to be part of the Wikimedia software to be useful - it's just as useful as an external tool. Davidwr/talk 18:49, 20 November 2015 (UTC)

Phiếu

1. Comment I think that it's important to determine how computationally intense each of these features is, and to drop those which require huge amounts of computer cycles. For example, for someone who has (say) a total of 20,000 edits in mainspace, determining the top five WikiProjects edited of the editor's lifetime might be implemented by (a) building a table of unique pages/articles edited, with a count included in each row of the table - so, perhaps 3,000 rows; (b) checking each article talk page (3,000), and, in a separate table, building a edit-Wikiproject row for each WikiProject found on an individual article talk page (if an average of two, then 6,000 rows). Unfortunately, while (a) can be done incrementally/cumulatively, (b) cannot, because at any time the WikiProjects listed on any given article talk page can change. So even if an editor hasn't edited in (say) a week, (b) has to be done again if the top five WikiProject list is to be accurate. And if an editor expects to see his/her dashboard to be up-to-date at all times - well, that's essentially impossible. John Broughton (talk) 05:47, 30 November 2015 (UTC)
2. Neutral I agree with user John Broughton's points above; this would be very difficult. It does seem mildly useful, but more than that, it seems like making Wikipedia into a competition, with a leaderboard and user statistics. I think that getting a feel for an editor's past work does involve more research than one might want to do (currently), but that's not really a bad thing, and it does help protect user privacy and discourage "I have more edits than you do" fighting (not sure that's the right word). -- 2ReinreB2 (talk) 17:39, 1 December 2015 (UTC)
3.  Oppose --Usien6 (talk) 19:41, 1 December 2015 (UTC) // Waste computational resources to fuel a vanity race? No, thanks...
4.  Oppose There's some minor useful purpose to knowing these things, but all the development work and computation to keep this going just doesn't make it rise above the lowest of priorities. Maybe this could be looked at again in the future, but there are far more important proposals for us to proceed with today. Stevie is the man! ^{Talk • Work} 20:38, 1 December 2015 (UTC)
5. Comment "How many bytes of text has User X added to all Wikipedia articles?" is meaningless. Reverting vandalism can easily make you add tens of thousands bytes in one edit, sometimes several such edits in a row if a vandal keeps blanking a large article. That would dominate normal edits. Gap9551 (talk) 23:14, 1 December 2015 (UTC)
6.  Support "How many bytes of text has User X added to all Wikipedia articles?" I think it can be stadistically usefull, and do a Top User List--Manlleus (talk) 15:23, 2 December 2015 (UTC)
7.  Oppose. Neither article count nor bytes added are adequate measures of a contributor's impact on a project. Curating Wikimedia projects is serious business -- it is neither a competition nor a game. This needs to be super low priority, if it is even considered. MER-C (talk) 17:10, 2 December 2015 (UTC)
8.  Support Academics need to be able to measure their impact to justify spending time editing Wikipedia, and this would be a small step towards some better metrics than "edit counts". See Stuart C. Ray's 42 minute WikiConference USA talk: "Are the Obstacles Academic?" (Starts at 4 hours and 36 minutes). Some statistics would also help motivate existing editors who rarely see much impact from their work. —Pengo (talk) 21:34, 2 December 2015 (UTC)
9. Comment On a related note, it would be interesting to count the total number of <ref>-tags a user has added (while not subtracting removal of such tags). Gap9551 (talk) 23:25, 11 December 2015 (UTC)

Thay đổi giao diện chương trình giáo dục

Là một nhà giáo dục sử dụng trang Chương trình Giáo dục, tôi muốn các thay đổi sau xảy ra:

• Special:Students khá vô dụng ([3]). Nó nên được thực hiện sắp xếp, nhưng thậm chí quan trọng hơn, có thể lọc được: Tôi muốn sử dụng nó để chỉ xem các học sinh của TÔI. Và tất cả trong số họ, không phải là một lô 50 hoặc bất cứ điều gì là khóa trong bảng dài trên trang đó.
• Special:MyCourses cần một bản lưu trữ, một tùy chọn để tự động thu gọn các mục nhập của học sinh và chọn độ dài của những ngày mà một người muốn hiển thị trên trang đầu. Bây giờ thật đáng buồn là một trang tôi và học sinh của tôi luôn luôn bỏ qua, với một tiếng thở dài vì nó là khá vô ích. Nó đặc biệt có vấn đề nếu người ta có nhiều khóa học; Tôi hiện đang có bốn, và đây là một mớ hỗn độn, như một số sinh viên hiển thị trong danh sách khóa học 2+, một trong những tôi muốn không thường ở đầu trang, vv Ngoài ra, các hoạt động sinh viên sẽ hiển thị chỉnh sửa của họ bên ngoài Wikipedia tiếng Anh (tôi có của tôi ví dụ: sinh viên chỉnh sửa Wikipedia tiếng Hàn).
• Danh sách các bài báo của học sinh (ví dụ tại [4]) nên hỗ trợ các bài viết bên ngoài Wikipedia tiếng Anh; Tôi có sinh viên chỉnh sửa bài viết trên Wikipedia tiếng Hàn và Wikivoyage, nhưng chúng tôi không thể tạo siêu liên kết ở đó.# Tôi muốn có thể sắp xếp sinh viên trên trang đó thành các nhóm, có thể với màu sắc và tên.

1. Tôi muốn trang đó có thể sắp xếp (theo bài viết, tên, nhóm của học sinh)
2. Tôi muốn trang đó có một nơi để bạn có thể thêm số học sinh / tên thật của học sinh. Đó là một nỗi đau khi học sinh đăng ký với biệt hiệu, và tôi phải giữ một danh sách riêng biệt của họ là ai.# Tôi muốn có một số loại tiến độ theo dõi cho mỗi bài viết/sinh viên/nhóm. Ví dụ sinh viên được yêu cầu gửi một phác thảo trên trang thảo luận của bài viết hoặc chỉnh sửa hoặc yêu cầu xem xét hoặc bất kỳ nội dung nào. Tôi muốn để có thể xác định những người, với thời hạn, cho mỗi khóa học, và có hộp kiểm hiển thị bên cạnh mỗi học sinh/nhóm/bài viết mục.
3. Danh sách đó sẽ bị thu gọn bởi hộp có thể mở rộng cho các chỉnh sửa gần đây của chúng (như trên Special:MyCourses), và tôi muốn nó hiển thị số lượng từng chỉnh sửa của học viên trong tuần qua. --Piotrus (talk) 04:49, 12 November 2015 (UTC)

Earlier discussion and endorsements
Endorsed LeoRomero (talk)  Oppose. Insufficient benefit for the core community, WMF specific. MER-C (talk) 16:06, 14 November 2015 (UTC)  Endorsed and Comment this is the kind of thing that should be coded by college students themselves. The outreach and education teams can work with educators to seek out interested students who have the computer skills to "jump on board" and get this coded. Doing so would at least partially address the issue of "insufficient benefit" as it would tie up fewer resources than if the foundation were to code it (I would still expect the foundation to provide parameters and some oversight of the project, so it would tie up some resources). Davidwr/talk 18:53, 20 November 2015 (UTC)

Phiếu

• Comment The Dashboard at wikiedu.org does allow sorting by students - see, for example here. I'm getting the sense that there are older (no longer being updated?) tools at en.wikipedia.org; is that true? John Broughton (talk) 04:21, 1 December 2015 (UTC)
  • EducationProgram extension is sort of dead in terms of development (and there are also some major security issues with it and new requests to install it on wikis are being declined/stalled). My understanding is that at some point of time WikiEdu will be replacing it. --Glaisher (talk) 15:20, 1 December 2015 (UTC)

Bật chuyển đổi EPUB trên Wikipedia

Tracked in Phabricator:
Task T97672

Đã từng là một công cụ cho phép chuyển đổi các bài viết Wikipedia thành các tệp EPUB. Chức năng này đã bị gián đoạn vì sự hợp tác giữa Wikimedia và PediaPress đã kết thúc. Tôi muốn TechTeam có thể làm việc trên một công cụ chuyển đổi EPUB mới.--Kimdime (talk) 10:53, 10 November 2015 (UTC)

Earlier discussion and endorsements
Reported on phab:T97672. Helder 11:32, 10 November 2015 (UTC) There is a current Outreachy project to add OpenZIM export. Both ZIM and EPUB are standalone HTML variants, so in theory EPUB support will be easier once the ZIM support lands. Cscott (talk) 19:01, 11 November 2015 (UTC)  Endorsed Rather easy one and there are already community tools for this, namely WSexport. Fixing regressions in existing tools is one of the main purposes of the Community tech team, AFAIK. Nemo 10:33, 22 November 2015 (UTC)

Phiếu

1.  Support --Purodha Blissenbach (talk) 11:00, 1 December 2015 (UTC)
2.  Support--Kimdime (talk) 12:03, 1 December 2015 (UTC)
3.  Support --g (talk) 14:44, 1 December 2015 (UTC)
4.  Support --Boehm (talk) 16:38, 1 December 2015 (UTC)
5.  Support --Coentor (talk) 18:22, 1 December 2015 (UTC)
6.  SupportLionel Scheepmans ^{✉ Contact} _{French native speaker, désolé pour ma dysorthographie} 21:35, 1 December 2015 (UTC)
7.  Support --Oriciu (talk) 23:00, 1 December 2015 (UTC)
8.  Support MOBI/KF8 support would also be very useful. Rdrozd (talk) 00:29, 2 December 2015 (UTC)
9.  Support Litlok (talk) 08:24, 2 December 2015 (UTC)
10.  Support --Alexmar983 (talk) 12:32, 2 December 2015 (UTC)
11.  Support--Manlleus (talk) 15:29, 2 December 2015 (UTC)
12.  Support --AlessioMela (talk) 19:49, 2 December 2015 (UTC)
13.  Support Mule hollandaise (talk) 21:01, 2 December 2015 (UTC)
14.  Support Eman235/talk 21:29, 2 December 2015 (UTC)
15. Ok. Nemo 14:43, 3 December 2015 (UTC)
16.  Support SantiLak (talk) 10:41, 4 December 2015 (UTC)
17.  Support Halibutt (talk) 22:58, 4 December 2015 (UTC)
18.  Support -- Sir Gawain (talk) 14:07, 6 December 2015 (UTC)
19.  Support Alkamid (talk) 14:44, 6 December 2015 (UTC)
20.  Support - The GPL Calibre program code may be a good place to start. Bcharles (talk) 02:36, 9 December 2015 (UTC)
21.  Support --Ziko (talk) 13:53, 9 December 2015 (UTC)
22.  Support QuartierLatin1968 (talk) 04:53, 12 December 2015 (UTC)
23.  Support The results should contain less problems than the PDF creator. -- Juetho (talk) 12:42, 13 December 2015 (UTC)
24.  Support --ESM (talk) 16:19, 13 December 2015 (UTC)

Lỗi phân loại theo lỗi #ifexist

Tracked in Phabricator:
Task T14019

Pseudolinks #ifexist bằng cách sử dụng trình phân tích cú pháp. Ở Special:WhatLinksHere cũng trang được làm phiền đủ, danh sách có chứa các mẫu sử dụng #ifexist. Được biết đến từ năm 2007. --Atamari (talk) 19:24, 10 November 2015 (UTC)

Earlier discussion and endorsements
I absolutely support this wish → «« Man77 »» [de] 19:10, 13 November 2015 (UTC)  Endorsed --Aschroet (talk) 18:40, 16 November 2015 (UTC) Much needed. --Matthiasb (talk) 16:36, 21 November 2015 (UTC) @MGChecker, John Vandenberg, Stevietheman, StevenJ81, Nastoshka, Atamari, AlessioMela, and Halibutt: If you're still interested in this issue, please see Community Wishlist Survey 2022/Miscellaneous/Check if a page exists without populating WhatLinksHere. (Only pinging those that didn't vote for this in later years to cut down on pings.) Thanks. Mike Peel (talk) 19:39, 28 January 2022 (UTC)

Phiếu

1.  Support --MGChecker (talk) 19:43, 30 November 2015 (UTC)
2.  Support important bug to make WLH reliable again, and allow more use of #ifexist without this nasty side-effect. John Vandenberg (talk) 04:56, 1 December 2015 (UTC)
3.  Support --Andyrom75 (talk) 16:02, 1 December 2015 (UTC)
4.  Support Stevie is the man! ^{Talk • Work} 20:45, 1 December 2015 (UTC)
5.  Support StevenJ81 (talk) 22:07, 1 December 2015 (UTC)
6.  Support a bug since 2007, it's also time to solve this issue. --Nastoshka (talk) 22:24, 1 December 2015 (UTC)
7.  Support --Atamari (talk) 01:01, 2 December 2015 (UTC)
8.  Support --AlessioMela (talk) 19:50, 2 December 2015 (UTC)
9.  Support Halibutt (talk) 22:59, 4 December 2015 (UTC)
10.  Support --please fix this! Wbm1058 (talk) 18:23, 7 December 2015 (UTC)
11.  Strong support → «« Man77 »» ^[de] 17:57, 11 December 2015 (UTC)

Sửa chữa lớn cho các báo cáo đặc biệt

Vì nhiều lý do, nhiều báo cáo đặc biệt đã trở thành vô dụng và một số dự án đã buộc phải tạo báo cáo tùy chỉnh của riêng họ như báo cáo cơ sở dữ liệu hoặc thông qua WMFLabs/Toolserver. Tôi khuyên bạn nên thực hiện sửa chữa toàn bộ cách tạo báo cáo cho phép một số vai trò trong cộng đồng người dùng (như Bảo quản viên hoặc người sửa bản mẫu) có thể sửa đổi mã hướng các trang đặc biệt này. Một số chức năng mà tôi cho rằng sẽ hữu ích khi làm nên bao gồm:

1. Khả năng ẩn các báo cáo từ danh sách những người được hiển thị nếu chúng không liên quan đến dự án
2. Thêm báo cáo mới theo một số loại phần tùy chỉnh
3. Có thể sửa đổi các tiêu chí được sử dụng để tạo báo cáo.
4. Có linh hoạt hơn để mở rộng độ dài của một báo cáo ngay cả khi đó là chia nhỏ nó thành 1000-2500 đoạn bài viết trên nhiều trang. Reguyla (talk) 14:48, 26 August 2015 (UTC)

Earlier discussion and endorsements
Most of the QueryPage special pages run very expensive queries on the database so it is not a good idea to let users on wiki modify them. But we should investigate ways to let the pages more flexible (i.e. options in the form). --Glaisher (talk) 17:16, 26 August 2015 (UTC) Thanks that's good to know. I think I heard that about the queries and maybe as part of the investigation we could see if its possible to make some of them run with less resources. Its also possible some aren't needed at all and could just be eliminated completely or turned off. For example, Pages without language links is pretty irrelevant for Wikipedia now (although some Wiki's may use it) so maybe that could be an example of one we disable and don't run. Does anyone really use Dormant pages or Orphaned pages? My guess is probably not. Reguyla (talk) 17:33, 26 August 2015 (UTC)  Endorsed at least for consideration. I think it is worth including this in stage 2. This, that and the other (talk) 08:24, 17 November 2015 (UTC) Limited  Endorsed for consideration per This, that and the other. Given that these are "expensive" queries perhaps a special "Query editor" user-right that only those with demonstrated programming skills will hold. Proposed changes can be made by any editor on a test wiki, reviewed by the community similar to the way the English Wikipedia's bot approvals group approves bots, then given final technical approval by someone with the "query editor" user right and implemented by that same editor. I call this a limited endorsement because we should also seriously consider doing nothing because, as Reguyla pointed out, there is already a way to "get the job done" using external tools. Davidwr/talk 19:10, 20 November 2015 (UTC)

Phiếu

1. Neutral I certainly see the value in this proposal, but at the same time, I wonder about how much is gained compared to the development work required to implement this. If I could better sense how implementing this would positively impact projects across the board, I might nudge into a 'support'. Stevie is the man! ^{Talk • Work} 20:55, 1 December 2015 (UTC)

Làm cho SecurePoll giàu tính năng

Tracked in Phabricator:
Task T117127

Tracked in Phabricator:
Task T118073

Phần mở rộng SecurePoll hiện được sử dụng cho các cuộc bầu cử ArbCom tại các cuộc bầu cử Wikipedias và WMF của Hội đồng Anh và Ba Tư tại Meta, tất cả đều là cuộc bầu cử đa người chiến thắng (nghĩa là nhiều chỗ để lấp đầy) nhưng tất cả các tùy chọn mà SecurePoll hiện đang cung cấp là hệ thống bầu cử một người chiến thắng . Bỏ phiếu phê duyệt, phương pháp Schulze, bỏ phiếu phạm vi, và đa số đều được sử dụng để chọn một người chiến thắng duy nhất và sử dụng chúng để chọn nhiều người chiến thắng là một sự lựa chọn vô cùng. Hệ thống đồng ý/trung lập/phản đối thông thường được sử dụng rộng rãi trên Wikipedia là chưa từng thấy trong thế giới thực - bạn không thể tìm thấy bất kỳ cuốn sách hay bài báo tạp chí nào về nó để những nhược điểm có thể không được chúng tôi biết đến.

Có một vấn đề khác: Cuộc bầu cử ArbCom của Wikipedia tiếng Anh và Cuộc bầu cử Hội đồng WMF thường kết thúc với cử tri đi bầu cao trong khi các cuộc bầu cử trên các cộng đồng nhỏ hơn, chẳng hạn như Wikipedia tiếng Ba Tư, bị từ chối cử tri (khoảng 50 cử tri). Tỷ lệ bỏ phiếu thấp đòi hỏi một hệ thống bỏ phiếu mạnh mẽ để tạo ra kết quả hợp lý. Cộng đồng Wikipedia tiếng Ba Tư đang xem xét sử dụng các hệ thống bỏ phiếu thay thế như Meek STV hiện không có sẵn trong SecurePoll. Tôi cũng đề xuất bao gồm nhiều phương pháp khác có sẵn trong phần mềm bỏ phiếu. Tôi cũng đã tìm thấy một phần mềm nguồn mở có thể được sử dụng để thực hiện một phương pháp tỉ lệ Condorcet. Bạn có thể muốn xem thuật toán của nó. Có một phần mềm khác bao gồm các hệ thống bỏ phiếu khác nhau nhưng không phải là miễn phí, cụ thể là OpenSTV. 4nn1l2 (talk) 23:40, 9 November 2015 (UTC)

Earlier discussion and endorsements
Endorsed Huji (talk) 17:22, 13 November 2015 (UTC)  Endorsed Dalba 10:19, 19 November 2015 (UTC)  Endorsed examination of alternative systems; without comment on the systems mentioned explicitly above. - Ryk72 (talk) 20:13, 27 November 2015 (UTC)

Phiếu

1.  Support 4nn1l2 (talk) 02:52, 30 November 2015 (UTC)
2.  Support Huji (talk) 20:26, 30 November 2015 (UTC)
3.  Support Dalba 20:38, 30 November 2015 (UTC)
4.  Support John Vandenberg (talk) 05:09, 1 December 2015 (UTC)
5.  Support AnuJuno (talk) 16:44, 1 December 2015 (UTC)
6.  Support -- Tisfoon (talk) 18:37, 1 December 2015 (UTC)
7. Comment This is certainly worth exploring, but I'm just unsure of its priority compared to other proposals. I would support conducting a deeper review of what can be done with this and figuring out what the development effort would be. Stevie is the man! ^{Talk • Work} 21:09, 1 December 2015 (UTC)
8. Comment In the past there have been proposals to use Single Transferable Vote (proportional system for multi-winner elections) in English Wikipedia ArbCom elections. One of the reasons it has never been seriously considered is the supposition that SecurePoll does not support it. Of course that does not necessarily mean that if it was available, it would be adopted, since it would mean abandoning the 50% threshold for election. Although it is possible, given the upsurge in the number of votes this year, that when people see the results there may be renewed interest in a proportional rather than a majoritarian system. (Or not.) Neutron (talk) 00:27, 2 December 2015 (UTC)
9.  Support. The planned revamp of the Election Committee will probably come up with some new ideas; this should be kept near the top of the list, but wait until they have some results or recommendations. Risker (talk) 04:20, 2 December 2015 (UTC)
10.  Support. All wikis and all languages can benefit from this. --KhabarNegar 06:22, 2 December 2015 (UTC)
11.  Support--Manlleus (talk) 15:29, 2 December 2015 (UTC)
12.  Oppose. Insufficient impact -- elections occur very infrequently compared to many other problems surfaced in this survey and each project may want to conduct elections via a different method. This is a super low priority. MER-C (talk) 17:14, 2 December 2015 (UTC)
13. Comment - Prior versions of OpenSTV are open source (on SourceForge and Google Code), so one could start from that. The question of what type of vote systems you want to use precedes the issue of how to implement them. Bcharles (talk) 02:52, 9 December 2015 (UTC)

Công cụ Thống kê số lần xem trang

Wikipedia sử dụng stats.grok.se cũ cần được vá để sử dụng chính xác từ các wiki khác. Một số lỗi đã được đánh dấu từ lâu rồi, nhưng không ai chịu trách nhiệm.

Mặt khác gần đây đã được phát triển wikiviewstats đó là một công cụ đồ họa hoàn chỉnh và linh hoạt hơn. Thật không may, nó đã được dừng lại, và không ai có thể đưa nó trở lại đúng hướng.

Tôi cho rằng nên nhanh hơn để sửa các vấn đề trên thay vì viết từ đầu một công cụ thống kê mới có thể giám sát các truy cập của bất kỳ bài viết nào (cơ bản để hiểu về các insterests của khách truy cập), tuy nhiên bất kỳ lựa chọn nào trong số hai lựa chọn sẽ là một cải tiến tốt. --Andyrom75 (talk) 22:01, 11 November 2015 (UTC)

Earlier discussion and endorsements
Endorsed. Seems to be something that's regularly complained about and also something that should be achievable. Jenks24 (talk) 10:43, 12 November 2015 (UTC)  Endorsed Absolutely! IJBall (talk) 03:50, 17 November 2015 (UTC)  Endorsed -- Stephan Kulla (talk) 14:44, 22 November 2015 (UTC)  Endorsed — in general I support the idea that WMF should develop built-in functionality for stalled but super-useful third-party tools. —Ynhockey (talk) 08:47, 26 November 2015 (UTC) Noting that a new page view API (phab:T112956 and phab:T44259) has been recently released which will help with this. [5] (demo) and [6] are some of the tools that has been written for now. Several developers have expressed interest in the API so we will likely be seeing more stable tools in this area in the future. --Glaisher (talk) 16:34, 22 November 2015 (UTC)

Phiếu

1.  Support I've always thought we should have something more useful and reliable. Samwalton9 (talk) 10:28, 30 November 2015 (UTC)
2.  Support Jenks24 (talk) 10:31, 30 November 2015 (UTC)
3.  Support Lugnuts (talk) 12:05, 30 November 2015 (UTC)
4.  Support We need an officially WMF-supported web UI to the new Pageviews API. I can't stress officially-supported strongly enough here. This, that and the other (talk) 13:21, 30 November 2015 (UTC)
5.  Support (esp. as per This, that and the other). IJBall (talk) 13:52, 30 November 2015 (UTC)
6.  Support Orlodrim (talk) 20:29, 30 November 2015 (UTC)
7.  Support My name is not dave (talk) 21:54, 30 November 2015 (UTC)
8.  Support --Boehm (talk) 00:36, 1 December 2015 (UTC)
9.  Support --EugeneZelenko (talk) 00:46, 1 December 2015 (UTC)
10.  Support T.Shafee(Evo﹠Evo)^talk 01:55, 1 December 2015 (UTC)
11.  Support --Yodin^T 02:35, 1 December 2015 (UTC)
12.  Support Mike V • Talk 02:48, 1 December 2015 (UTC)
13.  Support per TTO. John Vandenberg (talk) 05:35, 1 December 2015 (UTC)
14.  Support--Kippelboy (talk) 05:36, 1 December 2015 (UTC)
15.  Support --Holder (talk) 06:38, 1 December 2015 (UTC)
16.  Support--Shizhao (talk) 09:39, 1 December 2015 (UTC)
17.  Support--Kimdime (talk) 12:25, 1 December 2015 (UTC)
18.  Support · · · Peter (Southwood) ^(talk): 14:16, 1 December 2015 (UTC)
19.  Support. Anthonyhcole (talk) 14:26, 1 December 2015 (UTC)
20.  Support --g (talk) 14:47, 1 December 2015 (UTC)
21.  Support--Xabier Cañas (talk) 15:07, 1 December 2015 (UTC)
22.  Support--KRLS (talk) 15:08, 1 December 2015 (UTC)
23.  Support Goombiis (talk) 16:46, 1 December 2015 (UTC)
24.  Support Ckoerner (talk) 17:07, 1 December 2015 (UTC)
25.  Support --AlasdairW (talk) 18:05, 1 December 2015 (UTC)
26.  Support --Andyrom75 (talk) 18:08, 1 December 2015 (UTC)
27.  Support Jan.Kamenicek (talk) 19:27, 1 December 2015 (UTC)
28.  Support Jules78120 (talk) 19:50, 1 December 2015 (UTC)
29.  Support -Lkcl it (talk) 21:52, 1 December 2015 (UTC)
30.  Support --Hkoala (talk) 20:29, 1 December 2015 (UTC)
31.  Support Stevie is the man! ^{Talk • Work} 21:06, 1 December 2015 (UTC)
32.  Support Why not? Regards, Kertraon (talk) 22:09, 1 December 2015 (UTC)
33.  Support --Nastoshka (talk) 22:28, 1 December 2015 (UTC)
34.  Support --Oriciu (talk) 23:03, 1 December 2015 (UTC)
35.  Support Gap9551 (talk) 23:15, 1 December 2015 (UTC)
36.  Support Johnbod (talk) 04:07, 2 December 2015 (UTC)
37.  Support In veritas (talk) 04:37, 2 December 2015 (UTC)
38.  Support Litlok (talk) 08:25, 2 December 2015 (UTC)
39.  Support--Barcelona (talk) 12:00, 2 December 2015 (UTC)
40.  Support Casliber (talk) 13:34, 2 December 2015 (UTC)
41.  Support --Renessaince (talk) 14:27, 2 December 2015 (UTC)
42.  Support, an official tool is needed for this — NickK (talk) 15:02, 2 December 2015 (UTC)
43.  Support--Manlleus (talk) 15:30, 2 December 2015 (UTC)
44.  Support Matěj Suchánek (talk) 15:47, 2 December 2015 (UTC)
45.  Support --AlessioMela (talk) 19:51, 2 December 2015 (UTC)
46.  Support Thémistocle (talk) 21:52, 2 December 2015 (UTC)
47.  Support -- Dave Braunschweig (talk) 22:00, 2 December 2015 (UTC)
48.  Support Mike Peel (talk) 23:16, 2 December 2015 (UTC)
49.  Support Hobbes Goodyear (talk) 09:11, 3 December 2015 (UTC)
50.  Support --Hektor Absurdus (talk) 15:11, 3 December 2015 (UTC)
51.  Support Theredmonkey (talk) 19:12, 3 December 2015 (UTC)
52.  Support Yes we need to have a reliable version of this. Also perhaps with some extra features. Graeme Bartlett (talk) 04:26, 4 December 2015 (UTC)
53.  Support SantiLak (talk) 10:41, 4 December 2015 (UTC)
54.  Support Mark MacD (talk) 13:17, 4 December 2015 (UTC)
55.  Support --Jane023 (talk) 16:37, 4 December 2015 (UTC)
56.  Support --Wiklol (talk) 18:31, 4 December 2015 (UTC)
57.  Support Halibutt (talk) 23:00, 4 December 2015 (UTC)
58.  Support --Anthonyhcole (talk) 05:05, 5 December 2015 (UTC)
59.  Support --Yeza (talk) 16:44, 5 December 2015 (UTC)
60.  Support -- Sir Gawain (talk) 14:10, 6 December 2015 (UTC)
61.  Support Alkamid (talk) 14:46, 6 December 2015 (UTC)
62.  Support Vätte (talk) 16:30, 6 December 2015 (UTC)
63.  Strong support - There are many programmatic initiatives to improve Wikipedia and increase its impact. For those programs, which draw on volunteer editors but also GLAM professionals, academics, non-profits, etc., measuring impact is a very big deal and can make the difference when deciding whether to participate or donate resources. A good way to measure that impact is therefore extremely important not just to the community but to the movement. (disclosure: I work for the Wiki Education Foundation, which of course cares about measuring impact, but I'm opining here as a volunteer who has been involved on Wikipedia, offline Wikipedia projects, and the education program long before I became an employee). — Rhododendrites ^talk \\ 18:03, 6 December 2015 (UTC)
64.  Support - Would be useful for other projects such as wikivoyage as well - Matroc (talk) 03:21, 7 December 2015 (UTC)
65.  Support --Waldir (talk) 15:02, 8 December 2015 (UTC)
66.  Support Time for WMF to apply its resources to important statistical tools: too many still depending on a single individual. Noyster (talk) 21:24, 8 December 2015 (UTC)
67.  Support Ritchie333 (talk) 15:17, 11 December 2015 (UTC)
68.  Support Nocowardsoulismine (talk) 16:48, 12 December 2015 (UTC)
69.  Support --ESM (talk) 16:21, 13 December 2015 (UTC)
70.  Support --Tgr (talk) 22:35, 13 December 2015 (UTC)

Liên kết Interwiki sơ bộ và tùy chọn ngôn ngữ thứ hai

Ý tưởng của tôi là cho phép người dùng tạo Interwiki sơ bộ liên kết trên Wiki-data bằng cách liên kết bài viết đã tồn tại với bài viết không tồn tại từ một ngôn ngữ khác. Những lợi ích từ sự thay đổi này là gì? Nó sẽ giúp các biên tập viên và khách truy cập của chúng tôi bằng cách cho họ cơ hội để đọc / dịch các bài báo từ một ngôn ngữ khác đặc biệt là nếu họ là song ngữ / đa ngôn ngữ. Bất cứ ai cũng có thể thay đổi sở thích của mình và thêm "Ngôn ngữ thứ hai" sau đó hệ thống sẽ tự động kết nối bất kỳ liên kết màu đỏ nào với liên kết màu xanh từ ngôn ngữ thứ hai của họ.

• Ví dụ:
  • Nếu tiếng Pháp là ngôn ngữ đầu tiên của tôi và tiếng Anh là ngôn ngữ thứ hai của tôi:

conjonctivite allergique ^{[En anglais]}

• Người Tây Ban Nha:

La conjuntivitis alérgica ^{[en Inglés]}

• Tiếng Anh và đặt tiếng Ả Rập làm ngôn ngữ thứ hai:

Almashad mosque bombing ^{[In Arabic]}

Tôi ước rằng bạn có được ý tưởng của tôi và nếu bất cứ ai muốn làm rõ bất kỳ anh / cô ấy hơn chào đón :) --Ziad (talk) 13:19, 10 November 2015 (UTC)

Earlier discussion and endorsements
Endorsed This would also be nice to integrate with mw:Extension:ContentTranslation, so that bilingual users could easily start new articles from redlinks in their 'first language'. Cscott (talk) 19:05, 11 November 2015 (UTC) Comment: Take a look at en:Template:Interlanguage link multi, which has much of the functionality. Finnusertop (talk) 18:09, 12 November 2015 (UTC) wdsearch.js already offers this feature when visiting red links, try and open w:it:Terri Attwood. Content translation already offers to create an article by translation when clicking a red link, too. Nemo 18:14, 12 November 2015 (UTC) We can't link articles preliminarily on Wikidata. Among other things we have not way to tell later if the article that was created at that place is actually about the topic it was linked with in Wikidata. --Lydia Pintscher (WMDE) (talk) 14:16, 13 November 2015 (UTC) comment: That's why I suggested this idea to change wikidata and allow such thing. linking articles through wikidata will be manual task after that the system will automatically link articles on any Wikipedia page. --Ziad (talk) 16:19, 13 November 2015 (UTC) It is not a matter of changing Wikidata. It is a fundamental issue with how article creation can be done independent of Wikidata. --Lydia Pintscher (WMDE) (talk) 12:52, 15 November 2015 (UTC)

Phiếu

1.  Support To-be-created articles (redlinks) could be in a separate table within the Wikidata schema. The system could periodically (weekly?) scan to see if an entity in the separate table now existed as an article; if so, then there could be a separate process (human or automated) to confirm (or not) that the new article was in fact on the same topic as was expected; once that's determined, the entity would be removed from the to-be-created table. John Broughton (talk) 05:27, 30 November 2015 (UTC)
   • To-be-created wikilinked articles would need to be stored in the target wikis.
   • They could be listed (deselectably) on Special:Wantedpages with an appropriate comment.
   • Authors creating wanted pages should generally be informed that WhatLinkshere has a non-empty list, if so, and be asked to take care of the appropriate actions when links do or do not match. --Purodha Blissenbach (talk) 14:15, 1 December 2015 (UTC)
2.  Support --Purodha Blissenbach (talk) 11:05, 1 December 2015 (UTC)
3. Neutral I would support this, if the choice of the Second language was limited to the on-wiki preferences only, and was not connected to the wiki's fallback language or to the browser's language preferences. This wasn't true for VisualEditor's translation suggestions, so we had to disable this feature (I mean translation suggestions) completely in ukwiki.--Piramidion 20:30, 6 December 2015 (UTC)

Hợp nhất tài khoản SUL

Theo SUL § Tôi có hai hoặc nhiều tài khoản với các tên khác nhau. Chúng có thể được hợp nhất thành một tài khoản không?, Việc sáp nhập tài khoản SUL vẫn chưa được triển khai. Nhưng tôi không tìm thấy bất kỳ thông tin thực sự hữu ích nào về tiến trình thực hiện của tính năng như vậy. Tôi có năm di sản (những người có dấu ngã được liệt kê trong trang người dùng của tôi trên ptwiki) và tự hỏi khi nào việc hợp nhất cuối cùng sẽ có sẵn. Trước khi đặt dấu ngã, tôi cảm thấy bị quấy rối trong dự án nhà của tôi. Khi tranh luận với một sysop không thực sự thân thiện, anh ta nhận thấy những điểm tương đồng về màn hình và hỏi tôi liệu tôi có rối loạn và đề nghị đi đến "Newbie Café" (một trang trong cổng cộng đồng dành riêng cho người mới). Điều đó cho rằng tôi là một trong những (nếu không phải là) biên tập viên lâu đời nhất (từ năm 2004) vẫn còn hoạt động trong dự án của tôi. May mắn thay, tôi không bao giờ bị quấy rối trong các cuộc bỏ phiếu về số lượng ấn bản thấp của tôi, nhưng tôi phải đặt tuyên bố từ chối trách nhiệm trong trang người dùng của mình về vấn đề này. Tuyên bố từ chối vẫn còn đó, và tôi không thể chờ đợi để xóa nó ... --Usien6 (talk) 15:43, 13 November 2015 (UTC)

Earlier discussion and endorsements
AFAIK there is already a tool for account merging which has several “bugs”, which means that more often than desired it makes the accounts to be merged totally unusable. They therefore hesitate to continue, and probably even consider to not use it at all. IIRC the reason for this problem is that the database of 15 years is too complex to safely merge accounts. You might want to get in contact with @DerHexer:, who has insight into SUL related issues and is probably willing to give a short update. —MisterSynergy (talk) 16:52, 13 November 2015 (UTC) The tool cannot be used, a re-write is required. But Usien6 can confirm with each of these accounts on their userpages that all accounts are his own. Then I could manually rename them to Usien6 where he can merge them on his own. Cheers, —DerHexer (Talk) 17:18, 15 November 2015 (UTC) Dear @MisterSynergy: Thank you for the update! Dear @DerHexer: Thank you for your stance, I'll be contacting you in your talk page soon... --Usien6 (talk) 16:21, 17 November 2015 (UTC)  Endorsed, although I suppose this may be outside the expertise of Community Tech. This, that and the other (talk) 08:21, 17 November 2015 (UTC) Comment before rewriting/re-coding this into a usable tool, we should survey the need and determine if the affected users' needs can be met without writing the code. If, hypothetically, all affected users will be fine with a partial solution that exists today (such as whatever solution Usien6 winds up using, then there is no need to do anything (that's not to say we shouldn't do it at all, only that it should be a very low priority). On the other hand, if thousands of editors are affected by this and there is no solution acceptable to them, then it should be higher on the priority list. Davidwr/talk 18:59, 20 November 2015 (UTC) I still haven't contacted DerHexer as I am morally hesitant to ask a procedure only to benefit myself. I'm rather wait for a solution for everybody – be they few or many – being that the original purpose of my entry. Finally, I endorse the approach proposed by Davidwr and enlist myself as a volunteer to help such --Usien6 (talk) 11:49, 24 November 2015 (UTC)  Endorsed Helder 12:36, 22 November 2015 (UTC)  Endorsed it is not just a problem for old pre-SUL accounts, newbies sometimes create two accounts by mistake and use both. I would like to provide them a solution before a "feisty" patroller accuses them of sockpuppeting. Also, it is a minor occurrence but some users have created new accounts for a fresh start (nothing bad, just a psychological thing) but at certain point they want "come to terms" to their past. TThere are even users who forgot their password and created a new account, but we all know that they are telling the truth. Sometimes they have to make thousands of edits to become again AP, with a huge waste of time for patroller. So... it is not urgent, I agree, but if we can do something, why not?--Alexmar983 (talk) 00:32, 27 November 2015 (UTC)

Phiếu

1.  Support. --Stryn (talk) 19:02, 30 November 2015 (UTC)
2.  Support tufor (talk) 15:40, 1 December 2015 (UTC)
3.  Support -- 2ReinreB2 (talk) 17:48, 1 December 2015 (UTC)
4.  Support --Usien6 (talk) 19:46, 1 December 2015 (UTC)
5.  Support as this is an obviously necessary tool, although it would be helpful to know how many users this tool would help. Stevie is the man! ^{Talk • Work} 21:22, 1 December 2015 (UTC)
6.  Support JackPotte (talk) 21:40, 1 December 2015 (UTC)
7.  Support --Oriciu (talk) 23:05, 1 December 2015 (UTC)
8.  Support--Alexmar983 (talk) 00:30, 2 December 2015 (UTC)
9.  Support Ankry (talk) 01:36, 2 December 2015 (UTC)
10.  Support From a global renamer, a massive support Litlok (talk) 08:26, 2 December 2015 (UTC)
11.  Support Casliber (talk) 13:36, 2 December 2015 (UTC)
12.  Support, a major drawback of SUL unification as it happened and a deadlock at the moment: one had an account renamed without requesting it but cannot request renaming it back — NickK (talk) 15:05, 2 December 2015 (UTC)
13.  Support GY Fan★ 11:26, 4 December 2015 (UTC)
14.  Support --Waldir (talk) 15:04, 8 December 2015 (UTC)
15.  Support Matěj Suchánek (talk) 21:02, 9 December 2015 (UTC)
16.  Support Nocowardsoulismine (talk) 16:53, 12 December 2015 (UTC)

Hỗ trợ phân nhánh phiên bản cho các trang

Tracked in Phabricator:
Task T113004

Thêm khả năng tạo trang chi nhánh riêng và khả năng kết hợp phiên bản đó vào lịch sử chính (nhánh chính). Điều này sẽ giúp tránh hầu hết các cuộc chiến chỉnh sửa và so sánh các phiên bản khác nhau dễ dàng hơn. --AS (talk) 10:13, 27 May 2015 (UTC)

Earlier discussion and endorsements
I am not sure if I am understanding User:AS what you mean? Doc James (talk · contribs · email) 11:11, 27 May 2015 (UTC) See w:Revision control. Branches need to be policed for garbage, and I'm not too sure giving everyone an easy means of making w:WP:STALEDRAFTs is a good idea. MER-C (talk) 13:21, 27 May 2015 (UTC) I mean ability for a user to create a version (something like non-stabilized version in FlaggedRevs, but with few parallel versions, because there could be conflicts in non-stabilized version). For example a non-admin user can suggest a change for Main page, and if the change is ok, an admin just merges the version, without forking a page, copy-pasting etc. It would be nice to have at least next abilities (which don't need core changes): ability to fork page. Create a copy of page in personal namespace with one click and some magick to not include the page into categories. Why: for experiments and for users forbidden to edit particular pages. ability to see diff of different pages. As I understand, there is currently no fast way to see diff of a fork and original page. ability to partial reverting. During editing, when I see last diff, would be nice if I could just click some "revert" buttons next to particular chunks in diff so it would revert corresponding text in textarea. So I don't need to jump between diff and text to revert some changes on a page. --AS (talk) 14:02, 27 May 2015 (UTC) This would greatly complicate the process of article editing, steepening the learning curve, at a benefit only in very specific cases. It looks like an attempt to solve with technology a problem that should be solved socially. As for copying a page to personal namespace, just copying and pasting the wikicode will do: it's not a hard task that urgently needs simplifying. I share User:MER-C's concern that making it easier to create user drafts will lead to many mor stale drafts. MartinPoulter (talk) 14:30, 27 May 2015 (UTC) „This would greatly complicate the process of article editing, steepening the learning curve“ — this way of editing would be optional. „It looks like an attempt to solve with technology a problem that should be solved socially“ — imho, for now we are solving with social conventions a problem that could be solved with both technology and conventions (and we should delegate as much problems to technology as possible). „making it easier to create user drafts will lead to many mor stale drafts“ — why stale drafts could be a problem (how many is too many)? --AS (talk) 16:25, 27 May 2015 (UTC) We already have sandboxes for articles that are locked such as this one. How does this differ to that? Doc James (talk · contribs · email) 00:55, 28 May 2015 (UTC) 1) no fast way to compare (to preview diff of) sandbox with original page and with other sandboxes. 2) no ability for other person to merge my changes with saving of authority, so I'll be mentioned as author of the version (smth. similar to stabilizing version in FlaggedRevs). --AS (talk) 11:20, 28 May 2015 (UTC) One just copies the current article into the sandbox hits save and than uses history to view the dif. One can state who the author is in the edit summary. I do this all the time when I edit in other languages and add content written by other people. Doc James (talk · contribs · email) 11:31, 28 May 2015 (UTC) „uses history to view the diff“ - with original version, not with current version of original page (if I understand correctly). „One can state who the author is in the edit summary“ — that should be avoided if possible. --AS (talk) 08:57, 30 May 2015 (UTC) Other problem: one can't see list of all sandboxes and can't see list of all proposed diffs --AS (talk) 19:29, 5 June 2015 (UTC) phab:T40795? Helder 18:28, 10 June 2015 (UTC)  Endorsed phab:T113004 is the proposal for the 2016 Wikimedia Developer Summit, and lists a large number of related tasks. It's probably the best place to put current discussion. cscott (talk) 18:13, 11 November 2015 (UTC) en:Wikipedia:Content forking explains why this is a bad idea. The Quixotic Potato (talk) 14:46, 12 November 2015 (UTC)  Oppose per my comments above and en:Wikipedia:Content forking. MER-C (talk) 16:35, 14 November 2015 (UTC) I don't think that en:Wikipedia:Content forking actually is relevant at all. We already have "draft" namespaces, for instance. This could simply enable a better implementation of en:Wikipedia:Drafts, which is already consensus on enwiki. Further, English Wikipedia is not all of the wikimedia project; you'll notice that some of the requests about this feature come from wikisource or wikibooks. So citing policy on enwiki should not be considered determinative; once implemented each projects can determine whether to enable this on a namespace-by-namespace basis. Cscott (talk) 22:04, 18 November 2015 (UTC)

Phiếu

1. Comment It's easy to say that the system should be able to merge two versions; in fact, this is essentially impossible to program (automate). If two versions disagree, how could a computer program possibly decide what text to keep and what text to discard? Let's keep expectations reasonable: if different versions do become possible, only human beings are going to be doing the merging. John Broughton (talk) 05:33, 30 November 2015 (UTC)
2. I think this proposal should be removed +1-1 = 0 endorsements, no? Moreover the endorser is a WMF staffer who proposed to work on the matter, so there is COI. Nemo 10:18, 30 November 2015 (UTC)
3.  Oppose per Wikipedia:Content forking and the above concerns. Draft space on en.wp is mainly for the creation of new articles. MER-C (talk) 10:35, 30 November 2015 (UTC)
4.  Oppose --Usien6 (talk) 19:50, 1 December 2015 (UTC) // High complexity for a low gain. I have always made my forks manually and I'm okay with that.
5.  Oppose Needlessly complex and it would probably go vastly unused. Stevie is the man! ^{Talk • Work} 21:32, 1 December 2015 (UTC)
6.  Oppose If it's like the pages to merge, someone always proposes this job for the others, but not for him. JackPotte (talk) 21:42, 1 December 2015 (UTC)
7.  Oppose per others. You can always save a version to play with in userspace or a talk page sub page. The last thing we want is to make it too easy to have different versions of articles around. Johnbod (talk) 04:10, 2 December 2015 (UTC)
8.  Oppose. Comparing two versions of whatever article is already possible (and can be made even better with 2015 Community Wishlist Survey/Editing#Improved diff compare screen). However, branching articles is not needed as this is too difficult to manage — NickK (talk) 15:09, 2 December 2015 (UTC)
9.  Support --AS (talk) 09:48, 3 December 2015 (UTC)
10.  Oppose I find it hard to imagine an implementation that would be significantly more functional than copy-to-userspace&paste-to-article, without creating a complex mess. Alsee (talk) 15:56, 5 December 2015 (UTC)

Người dùng kỹ thuật có quyền chỉnh sửa tóm lược sửa đổi

Tracked in Phabricator:
Task T15937

Người dùng có quyền chỉnh sửa tóm tắt. Ví dụ, tôi đã thực hiện một chỉnh sửa trong một số mô-đun Lua nhưng quên để lại một lời giải thích về sự thay đổi cho các nhà phát triển khác. --AS (talk) 11:42, 18 September 2015 (UTC)

Earlier discussion and endorsements
See phab:T15937 (Correcting edit summaries (if own, last, & recent)) and phab:T12105 (Allow editing of edit summaries after the fact). Helder 12:16, 10 November 2015 (UTC)  Endorsed --Edgars2007 (talk) 11:40, 12 November 2015 (UTC)  Endorsed but only if the change-history of the summary itself is available to at least those who hold this user-right if not to the general public. Davidwr/talk 06:14, 16 November 2015 (UTC) Clarification: This condition that the history be available to everyone who has the ability to change an edit summary (or better yet, the general public) is for "normal" edit-summary changes. I am not demanding that changes to hide or suppress edit summaries for good reason (similar to what is currently done with revision-deletion and revision-suppression tools) be visible to everyone who has the ability to change an edit summary (far from it - the code should allow for non-current edit summaries should be oversightable (suppressable) and "revision-deletable" even if the page-revision is not oversighted or revision-deleted, with "enabling" this option done on a per-project basis according to that project's consensus). Davidwr/talk 23:44, 16 November 2015 (UTC)  Endorsed I would support the addition of the right of every user to ADD to their own edit summaries information they forgot to include, and to EDIT their own edit summaries if there have been no subsequent revisions. This is not contradictory. If I edit a page and forget to put in an edit summary, I could go back and do so. If I misspell something and realize it right after posting the edit, I could fix it. However, once someone else edits the underlying page, I could only ADD info to the end of my previous edit summary. This would still allow me to add a forgotten edit summary, but not remove what was already there when someone else made an edit after I did. There may need to be a time limit on either action to prevent abuse, and it should always be apparent to the reader when they are reading an edit summary that was added after the fact. Etamni (talk) 07:46, 17 November 2015 (UTC)  Endorsed Edit summaries are an important way to communicate. In edit wars they are the number one communication way. Molarus (talk) 21:41, 20 November 2015 (UTC)  Endorsed per Etamni. IJBall (talk) 21:47, 20 November 2015 (UTC)  Endorsed WereSpielChequers (talk) 15:25, 25 November 2015 (UTC)  Endorsed yes please! That's a sound practical judgment. Time limit or set up for specific group of users, such as autoconfirmed or autopratolled are always possible, depending on the platform "sensitivity", but those are just details.--Alexmar983 (talk) 16:34, 25 November 2015 (UTC)

Phiếu

1.  Support With configurable limitations, as discussed in the endorsements. Samwalton9 (talk) 10:29, 30 November 2015 (UTC)
2.  Support Jenks24 (talk) 10:34, 30 November 2015 (UTC)
3.  Support - Registered users should generally be allowed to fix their own, but the right to modify anyone else's should be restricted. עוד מישהו Od Mishehu 16:15, 30 November 2015 (UTC)
4.  Support, but it should be visibly shown on the history that summary was edited. --Stryn (talk) 19:04, 30 November 2015 (UTC)
5.  Support the right to edit your own summaries if no edits have been made to the page since. Neutral on other issues (e.g. adding to a summary after a subsequent edit to the page; right to view past versions of someone's edit summary). — Bilorv (talk) 20:12, 30 November 2015 (UTC)
6.  Support Matiia (talk) 20:23, 30 November 2015 (UTC)
7.  Support --Grind24 (talk) 20:53, 30 November 2015 (UTC)
8.  Support No reason to be able to modify someone else's (that's why admins have revision deletion, when necessary), but you should be able to modify your own summary for a short period of time, and able also to supply an edit summary to an edit you made that doesn't have a summary at all. Nyttend (talk) 21:59, 30 November 2015 (UTC)
9.  Support --EugeneZelenko (talk) 00:47, 1 December 2015 (UTC)
10.  Support commenting on your own revisions, or those of IP addresses, to describe your edits, and a simple way to claim edits you made while logged out at the same time --Yodin^T 02:35, 1 December 2015 (UTC)
11.  Support but just for editing one's own summaries, and there should perhaps be a time limit set on it so that you can't change an edit summary after, say, 24 hours. IJBall (talk) 03:40, 1 December 2015 (UTC)
12.  Support John Vandenberg (talk) 05:34, 1 December 2015 (UTC)
13.  Support · · · Peter (Southwood) ^(talk): 14:15, 1 December 2015 (UTC)
14.  Support but only for one's own summmaries and for a given time; serious legal issues could come from making a comment in editline apparently subscribed by another user --g (talk) 14:53, 1 December 2015 (UTC)
15.  Support only own summaries + not only edit summaries, also summaries of actions logged in [[Special:Log]] (blocks, deletetions, etc.) tufor (talk) 15:44, 1 December 2015 (UTC)
16.  Support Sadads (talk) 15:50, 1 December 2015 (UTC)
17.  Support --Urbanecm (talk) 17:44, 1 December 2015 (UTC)
18.  Support Matěj Suchánek (talk) 18:10, 1 December 2015 (UTC)
19.  Support per Gianfranco and Tufor. Jules78120 (talk) 19:52, 1 December 2015 (UTC)
20.  Oppose --Usien6 (talk) 19:55, 1 December 2015 (UTC) // Keeping a history-of-the-history doesn't sound like a good idea. Not keeping it sounds even worse.
21.  Support with reasonable limits listed by others (only own summaries, within time limit, etc.). I'm not sure why a new user right is necessary, although perhaps limiting to autoconfirmed users is a good idea. Maybe don't keep history of summary changes -- is that really important anyway? Stevie is the man! ^{Talk • Work} 21:41, 1 December 2015 (UTC)
22.  Support with limits as listed above. StevenJ81 (talk) 22:28, 1 December 2015 (UTC)
23.  Oppose Not worth the addition of more links and options in page histories etc. Also it can be misleading if you change your own edit summary after another editor has e.g. reverted it or made another edit. Maybe it could work, but only as long as no newer edits have been made. Then a summary edit history would not be necessary. Gap9551 (talk) 23:22, 1 December 2015 (UTC)
24.  Support Helder 23:25, 1 December 2015 (UTC)
25.  Support Tar Lócesilion (queta) 23:59, 1 December 2015 (UTC)
26.  Support Litlok (talk) 08:27, 2 December 2015 (UTC)
27.  Support Should be useful. Regards, Kertraon (talk) 13:05, 2 December 2015 (UTC)
28.  Support for own edit summaries and probably for removing part of the content in summaries by others. Real-life story: a user adds a death date with a comment like "this idiot died, see obituary in Anyplace Business Journal 12/2015, p. 99". We would be interested in keeping reference but we would need to remove the word "idiot", but so far we cannot do this without hiding the entire comment — NickK (talk) 15:13, 2 December 2015 (UTC)
29.  Support One should at least be able to edit one's own edit summaries. Eman235/talk 21:32, 2 December 2015 (UTC)
30.  Support being able to edit your own summaries for a short period of time and to correct blank summaries. -- Dave Braunschweig (talk) 22:09, 2 December 2015 (UTC)
31.  Support YBG (talk) 06:21, 3 December 2015 (UTC)
32.  Support --AS (talk) 09:50, 3 December 2015 (UTC)
33.  Support Logical Fuzz (talk) 22:00, 3 December 2015 (UTC)
34.  Support SantiLak (talk) 10:41, 4 December 2015 (UTC)
35.  Support GY Fan★ 11:27, 4 December 2015 (UTC)
36.  Oppose per Usien6. Keeping a history-of-the-history doesn't sound like a good idea. Not keeping it sounds even worse. Alsee (talk) 16:02, 5 December 2015 (UTC)
37.  Support Ardfeb (talk) 01:09, 6 December 2015 (UTC)
38.  Support per Nyttend J36miles (talk) 01:12, 6 December 2015 (UTC)
39.  Support Alkamid (talk) 14:47, 6 December 2015 (UTC)
40.  Support to be able to edit your own summaries for a short period of time and to correct blank summaries. KylieTastic (talk) 15:44, 6 December 2015 (UTC)
41. Strong oppose - the edit summary is part of the editing history. going back to edit your edit summary shouldn't escape the transparency that's otherwise a fundamental part of editing Wikipedia. We would have to either introduce histories to each edit or display both the old and new edit summary in the page history. The former is obviously a technical and practical non-starter and the latter sounds like it would add unnecessary complication to already dense history pages such that it wouldn't really offer anything that couldn't be accomplished with a dummy edit or talk page message. — Rhododendrites ^talk \\ 18:09, 6 December 2015 (UTC)
42.  Oppose - we've all probably sometime realised there's an error in an edit summary just after we've hit the "save page" button and hence I can see why this facility may appear attractive, but the extra complications (particularly when dealing with problem editors - and I'm thinking of en wp here - it might not be so bad on Commons) would be too much. If I see an edit in my watchlist and then look at the article history or at the user's contributions I don't expect the edit summary to have changed in the meantime - that'd be too confusing. DexDor (talk) 23:15, 7 December 2015 (UTC)
43.  Support If a clear indication of a changed summary is visible, and the history of edits to the summary is available, I see no need for a time limit (or even a restriction to only edit one's own summaries, although editing other's summaries could be reserved for users with specific privileges, such as autopatroller, rollbacker, or administrator). --Waldir (talk) 15:09, 8 December 2015 (UTC)
44.  Support, depending on how it's done. → «« Man77 »» ^[de] 18:00, 11 December 2015 (UTC)
45.  Support But only for your own summaries, and only within a short (10 min, maybe 1 hr) time. It is _so_ easy to make a typo or a formatting error that is glaringly obvious, but uncorrectable. Martin of Sheffield (talk) 22:48, 11 December 2015 (UTC)
46.  weak oppose I like the conditions that Martin of Sheffield is proposing. However, I can see the potential for abuse that User:Rhododendrites is concerned about outweighing the potential benefits. This would have to have be subject to careful limitations (maybe the feature is disabled once another editor has viewed the edit history?). QuartierLatin1968 (talk) 04:58, 12 December 2015 (UTC)
47.  Support --Edgars2007 (talk) 09:03, 12 December 2015 (UTC)
48.  Support I support this with the conditions that users can only edit their own summaries, do so within a certain time frame, and only if no other editors have edited the page in the meantime. There should also be an option to disable summary edits on articles that have a history of edit warring, frequent vandalism, etc. In regards to a user privilege, I think it would be helpful for certain approved users to edit other editors' summaries, since there are some users who leave misleading summaries. Nocowardsoulismine (talk) 17:15, 12 December 2015 (UTC)
49. Highly Conditional  Support This is very implementation-sensitive feature. I would support almost none of the proposals which come easily to mind, except that I would support something like the following: 1) ability to annotate an existing edit-summary, or an existing edit-summary-annotation, for the user who made the edit, and for admins. 2) ability to strikethru, in full *or* in part, an existing edit-summary-or-annotation, for the user who wrote that edit-summary-or-annotation. 3) ability to revdel an existing summary, which is a feature that already exists, or an existing annotation, which would be a new feature. Under this scheme, nobody would be able to modify the text of an edit-summary. Nobody would be able to hide/revdel an edit-summary, except for people that already can. Examples: if the user made a goof, they could strikethru the offending bit: "fix typo my moronic content opponent made, add three refs" could become "fix typo my moronic content opponent made^{modified 2015-12-12 @ 12:34z}, add three refs". If the user needed to do more than merely erase a goof, but needed to *add* something, then they could annotate an edit-summary like this: "blank" to have an additional annotated-edit-summary-on-a-new-line, one indented line upwards saying "^{Added 2015-12-12 @ 23:45z:}forgot to leave edit-summary, namely that I fixed another typo, once again made by my new friend". Both types of action should cause a watchlist-alert to be sent to all people watching the page in question, just like a null-edit would cause. Both types of action should appear in Special:Contribs, in some fashion. The GUI-complexity of this specific scheme is pretty low: there is no history-of-the-history needed, beyond the autogenerated superscripted info shown in the examples, and the only additional controls are a button called Strikethru and a button called Annotate (maybe even just *one* single combo-button called AdjustSummary), which appear next to one's own edit-summaries and edit-annotations (or for admins next to all edit-summaries-and-annotations). I'm against letting people rewrite the edit history, in a way that actually *changes* that edit-history. en:WP:REVDEL is a necessary trick to hide information, but does not permit rewriting it. Neither should we implement that ability, to arbitrarily modify the past! See also, en:Mutator_method versus en:Immutable_object, specifically the bit saying "...simpler to understand and reason about...." All actions on-wiki are logged; changes to a page are found in the edit-history of that page. Self-referential changes to that edit-history, should be found right in that very edit-history with no additional pages required. Permitting strikethru (full or partial), and/or annotations (which can in turn be struckthru and/or recursively annotated), and absolutely nothing else, is the way to achieve that. Pretty much any other implementation approach, means I agree with Rhododendrites and DexDor and Alsee: too fucking complicated if we allow arbitrary changes, and too many risks of abuse/confusion/screwups/complexity through loopholes in the equally-complicated mitigating-schemes, to be worth the slight gains. So either build it so that arbitrary changes are not allowed, but simple strikethru and simple annotation-on-new-line are, or do not build it, pretty please with a cherry on top. 75.108.94.227 20:59, 13 December 2015 (UTC)

Các công cụ để xử lý các trích dẫn của các bài báo khoa học rút gọn

Vui lòng xem chủ đề này và thảo luận được lưu trữ này.

Tôi đã nghĩ đến một công cụ cho phép người dùng nhập vào nhiều cách khác nhau tham chiếu đến các bài viết rút gọn, chẳng hạn như số DOI (Peaceray là một chuyên gia trong các bài viết này). Công cụ sẽ chấp nhận nhiều đầu vào đồng thời, chẳng hạn như tất cả 64 bài viết đã được rút lại trong một loạt. Công cụ sẽ trả về cho người dùng một danh sách tất cả các bài viết trong đó các tham chiếu đó được sử dụng làm trích dẫn và đánh dấu các đoạn của bài viết nơi các trích dẫn được sử dụng. Điều này sẽ, tôi hy vọng, cải thiện đáng kể hiệu quả của quy trình làm việc để xử lý các bài báo tạp chí rút gọn. Hy vọng rằng công cụ này có thể hoạt động trên nhiều wiki và ngôn ngữ. --Pine^✉ 05:23, 16 November 2015 (UTC)

Earlier discussion and endorsements
Endorsed This wouldn't affect many articles but it would greatly improve the quality of the project of retracted articles could be easily identified and flagged so readers know they are no longer reliable. Davidwr/talk 05:44, 16 November 2015 (UTC)

Phiếu

1.  Support. Anthonyhcole (talk) 14:32, 1 December 2015 (UTC)
2.  Support Looks similar to one of the roles of the WikiProject X Librarybase concept: https://phabricator.wikimedia.org/T111066 Sadads (talk) 15:52, 1 December 2015 (UTC)
3.  Support Seems reasonable. Stevie is the man! ^{Talk • Work} 21:51, 1 December 2015 (UTC)
4.  Support Probably a good idea. StevenJ81 (talk) 22:27, 1 December 2015 (UTC)
5.  Support Spencer (talk) 01:11, 2 December 2015 (UTC)
6.  Support Mule hollandaise (talk) 21:04, 2 December 2015 (UTC)
7.  Support Halibutt (talk) 23:04, 4 December 2015 (UTC)
8.  Support - Bcharles (talk) 04:05, 9 December 2015 (UTC)
9.  Support --Ozzie10aaaa (talk) 10:48, 12 December 2015 (UTC)
10.  Support Nocowardsoulismine (talk) 17:28, 12 December 2015 (UTC)

Thuật sĩ WikiProject

Tracked in Phabricator:
Task T97210

Tạo cổng thông tin WikiProject tốt là vô cùng tẻ nhạt và tốn thời gian. Nó đòi hỏi kiến ​​thức sâu sắc về cú pháp mẫu WikiText và cách giao tiếp với nhiều công cụ và chương trình tồn tại để sử dụng cổng thông tin WikiProject. Sử dụng FormWizard (hoặc một kịch bản tùy chỉnh mới), một giao diện thuật sĩ có thể được tạo ra để xây dựng các cổng WikiProject mà sẽ đơn giản hóa đáng kể quá trình này.

Earlier discussion and endorsements
As part of WikiProject X I wrote a requirements document for a Project Builder. I hope to work on it sometime in the next couple of months. harej (talk) 19:16, 11 May 2015 (UTC)  Endorsed--Shizhao (talk) 07:53, 12 November 2015 (UTC)  Endorsed -- :JarrahTree (talk) 00:10, 18 November 2015 (UTC)  Endorsed On itWiki I have been asking for at least a non-compulsory standard for the style/layout of Wikiproject and Wikiportals pages... but not enough people were interested so far and projects/portals with strong identities have this fear they would be forced to be less indipendent on the long term... I hardly doubt that... 1 or 2% of projects/portals can be creative and do wonderful things, good for them, but we need some "structure" to provide decent maintenance and support to the "vast majority", espcially now that users contributions are flat or decreasing. Many sections of projects are very often the same such as "articles to do", "related project", "most requested article (red links)", "quality evaluation", "articles under deletion", "articles recently created in the area", "portals under this project's supervision" etc... they are more or less the usual building blocks. The same happens for the portals: "quality image(s)", "good article(s)", "new articles", "related portals", "rotation of selected articles"... at the end the code is usually copy-pasted from project/portals to project/portals with no perpspective and a huge confusion. It's a mess: some sections are updated manually, others are automatic, same sections show different names. An impressive amount of time can be lost making order in this mess when necessary. Usually, newbies try to (re)create or reinvigorate projcts/portals more than old users... It's normal, if old users were interested, they would have already done something... newbies are the fuse or the critical mass of this process and they're often left alone. No decent draft, limited success. That's why specific "plug-and-play" tools would be useful. --Alexmar983 (talk) 19:23, 29 November 2015 (UTC)

Phiếu

1.  Oppose. Insufficient impact -- creation of a WikiProject is a very low frequency task. The desired look and contents of a WikiProject portal may differ between WMF projects, making this somewhat project specific as well. MER-C (talk) 15:43, 1 December 2015 (UTC)
2.  Support Interactivity is part of socialization in communal processes, it would be useful to have a more dynamic (and simpler) strategy for organizing people on Wiki for topical collaboration, Sadads (talk) 15:53, 1 December 2015 (UTC)
3.  Support but ONLY IF this is NEVER forced on any WikiProject to use. Also, I'm concerned about the development resources this would sink compared to other proposals, but at the same time, I see this being developed incrementally as it is piloted in various spots. Stevie is the man! ^{Talk • Work} 21:59, 1 December 2015 (UTC)

   I'd like to further note that I would much prefer to see the development of useful modules/templates that can be inserted into existing WikiProjects that don't choose to have their WikiProject pages terraformed by a tool like this. Stevie is the man! ^{Talk • Work} 22:02, 1 December 2015 (UTC)

4.  Oppose Other things far more important. StevenJ81 (talk) 22:29, 1 December 2015 (UTC)
5.  Oppose, extremely wiki-specific. Each wiki is free to create a generic template for WikiProjects to make this task easy, but there is nothing for Community Tech here — NickK (talk) 15:17, 2 December 2015 (UTC)
6.  Oppose Opposed to automatic creation. Thémistocle (talk) 21:51, 2 December 2015 (UTC)
7.  Oppose I'm not even sure what a "WikiProject Portal" is - on en wp WikiProjects and Portals are different things, and both suffer from too many being (half) created, being edited by users who don't understand the intricate template/subpage/category structures involved and then abandoned leaving a mess for other editors to clean up. A wizard to assist erasing abandoned wikiprojects/portals might be more useful. For info: en wp currently has 126368 pages in Portal namespace. DexDor (talk) 23:28, 7 December 2015 (UTC)