Khảo sát Mong muốn Cộng đồng 2015/Biên tập-Sửa đổi

Voting has CLOSED! Thanks for your votes!

Chỉnh sửa WikiText được mã hóa màu

Tracked in Phabricator:
Task T101246

Tracked in Phabricator:
Task T104479

Đã có một số thí nghiệm về chỉnh sửa WikiText được mã hóa màu (bao gồm một tiện ích trong Wikipedia tiếng Anh và triển khai hoạt động trong ứng dụng Android). Điều này có thể được thực hiện thành một tính năng thực sự của phần mở rộng WikiEditor.

Earlier discussion and endorsements
Is it like mw:Extension:CodeMirror? --Pastakhov (talk) 17:40, 20 May 2015 (UTC) Yes I low the color coding of text that WikEd gives and miss it when I edit other languages. Sometimes I even work on text from other languages on En Wikipedia because we have better tools. We need a set of tools that the WMF will install on all Wikis that wish to opt in. Doc James (talk · contribs · email) 10:31, 21 May 2015 (UTC) @Doc James: actually you can install for yourself set of tools to be loaded globally. See mw:Help:Extension:GlobalCssJs. If you need some help, you can use my talk page here or @enwiki. --Edgars2007 (talk) 11:47, 12 November 2015 (UTC)  Endorsed +1 --AS (talk) 16:29, 27 May 2015 (UTC) This could be considered part of the "modern wikitext editor" project. Cscott (talk) 18:21, 11 November 2015 (UTC) Yes, 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) Actually, let me clarify a couple of things. 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. In addition, syntax highlighting (within the context of a VE-like wikitext editor) is apparently more complex than it seems, and may have a negative impact on performance. So the new wikitext editor will probably include syntax highlighting, but it's not 100% certain, and it may be an opt-in preference rather than the default.—Neil P. Quinn-WMF (talk) 20:43, 11 November 2015 (UTC) I think it's actually *very* useful to include things in the community wishlist which are already on WMF roadmaps. As Neil notes, it's not a near-term project for the Visual Editor team. The community wishlist is an opportunity to rank all these different *community wishes* against each other. If this proposal ends up ranked high on the wishlist, the VE team perhaps should reprioritize their work. Conversely if it is low, they should perhaps continue to defer this. We need these feedback mechanisms to allow the community to weigh in on the priorities of WMF teams. Cscott (talk) 21:57, 18 November 2015 (UTC)  Endorsed--Shizhao (talk) 07:59, 12 November 2015 (UTC)  Endorsed --Edgars2007 (talk) 11:47, 12 November 2015 (UTC)  Endorsed WikiText editor one of features most used by editors is not improved at all. Syntax highlighting is feature from the 1980's, but still missing in MediaWiki in the 2010's, 30 years after --Ilya (talk) 20:06, 15 November 2015 (UTC)  Endorsed--Lsanabria (talk) 12:19, 20 November 2015 (UTC)

Phiếu

1.  Support When helping new editors the first thing I tell them to turn on is the syntax highlighting extension. Samwalton9 (talk) 10:09, 30 November 2015 (UTC)
2.  Support --Patrick87 (talk) 18:05, 30 November 2015 (UTC)
3.  Support --Isacdaavid (talk) 02:14, 1 December 2015 (UTC)
4.  Support The very useful en.WP syntax highlighter has some very old cosmetic bugs and chokes on pages that are too large. Jonesey95 (talk) 05:04, 1 December 2015 (UTC)
5.  Support--Shizhao (talk) 09:17, 1 December 2015 (UTC)
6.  Support —Ynhockey (talk) 09:48, 1 December 2015 (UTC)
7.  Support —Tito☸Dutta 14:44, 1 December 2015 (UTC)
8.  Support --Arnd (talk) 14:44, 1 December 2015 (UTC)
9.  Support tufor (talk) 15:28, 1 December 2015 (UTC)
10.  Support Flinga (talk) 16:19, 1 December 2015 (UTC)
11.  Support It's hard for me to edit without this. Stevie is the man! ^{Talk • Work} 16:31, 1 December 2015 (UTC)
12.  Support just like dreamweaver.--Temp3600 (talk) 16:39, 1 December 2015 (UTC)
13.  Support --Urbanecm (talk) 17:42, 1 December 2015 (UTC)
14.  Support --Etamni (talk) 18:03, 1 December 2015 (UTC)
15.  Support --Woodcutterty (talk) 18:54, 1 December 2015 (UTC)
16.  Support --Wesalius (talk) 18:59, 1 December 2015 (UTC)
17.  Support --Fritzmann2002 (talk) 19:19, 1 December 2015 (UTC)
18. Neutral --Usien6 (talk) 19:22, 1 December 2015 (UTC) // As long as editors could opt-out.
19.  Support Helder 23:48, 1 December 2015 (UTC)
20.  Support Rdrozd (talk) 00:24, 2 December 2015 (UTC)
21.  Support --Ilya (talk) 12:45, 2 December 2015 (UTC)
22.  Support, would make wikicode easier to understand. And especially think of highlighting all curly brackets as counting them manually is annoying — NickK (talk) 13:53, 2 December 2015 (UTC)
23.  Support--Manlleus (talk) 15:14, 2 December 2015 (UTC)
24.  Support --AlessioMela (talk) 19:45, 2 December 2015 (UTC)
25.  Support Mule hollandaise (talk) 21:07, 2 December 2015 (UTC)
26.  Support --JQTriple7 (talk) 23:26, 2 December 2015 (UTC)
27.  Support --MisterSanderson (talk) 04:52, 3 December 2015 (UTC)
28.  Support --AS (talk) 09:36, 3 December 2015 (UTC)
29.  Support --Aryan hindustan (talk) 10:30, 3 December 2015 (UTC)
30.  Support: This will make editing a lot easier.--Bowleerin (talk) 11:23, 4 December 2015 (UTC)
31.  Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)
32.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
33. Neutral: I would support the idea, except w:Wikipedia:WikiEd is already there, I'm using it and it works great. The only thing it doesn't do is highlighting the corresponding brackets (per what User:NickK wrote above Halibutt (talk) 00:00, 5 December 2015 (UTC)
34.  Support --Ricordisamoa 01:15, 5 December 2015 (UTC)
35.  Support Ardfeb (talk) 00:53, 6 December 2015 (UTC)
36.  Oppose - Not opposed to the idea, but to using the wishlist for this. As noted in the "earlier discussion" WMF is going to do this anyway, and it's not something that I think should take precedence from some of the other ideas on the wishlist that would not otherwise be completed [to get it done sooner?]. — Rhododendrites ^talk \\ 17:29, 6 December 2015 (UTC)
37.  Oppose. Yes I want this, but this is not a Community Tech project per Rhododendrites and Neil P. Quinn-WMF. MER-C (talk) 18:10, 6 December 2015 (UTC)
38.  Support Mpn (talk) 18:22, 7 December 2015 (UTC)
39.  Support --Waldir (talk) 14:50, 8 December 2015 (UTC)
40.  Support - Bcharles (talk) 04:13, 9 December 2015 (UTC)
41.  Support Therud (talk) 09:22, 10 December 2015 (UTC)
42.  Support Lsanabria (talk) 15:22, 10 December 2015 (UTC)
43.  Support --Edgars2007 (talk) 08:59, 12 December 2015 (UTC)
44.  Support --NaBUru38 (talk) 03:37, 13 December 2015 (UTC)
45.  Support in the form of some upgrades and bugfixes for w:Wikipedia:WikiEd, in full collaboration with en:User:Cacycle, so that they are happy with the help.  :-)     Specifically, besides lack of bracket-flashers, WikiEd is limited to supporting only desktop browsers (Chrome/Firefox/Safari plus maybe Opera), but does not support Internet Explorer, which still is used by a good-sized chunk of internet denizens. Furthermore, I don't believe there is any special support for mobile browsers, used when doing mobile editing. Because wikiEd generates a custom iframe, it would be a boon were it to be customized for this use-case: entering template-related punctuation for refs and infoboxen, for instance, would be something that could be helpfully improved so that mobile editors don't need to mess with their vkeyb endlessly (or just give up and stop clicking edit). And sure, it is true that Someday there are some plans that the WMF will be working on a Visual-Editor-like-wikitext-editor. But that is an entirely different thing. We already have a default wikitext-editor, the simple <textarea> of the mid-1990s. We already have a syntax-highlighting purely-browser-based improvement on that classic, w:Wikipedia:WikiEd, which is javascript-only <iframe>-based and thus even supports anons, if it were only available as a toggle-on toggle-off default feature of the 'pedia. You can switch back and forth from <textarea> to wikiEd-<iframe>. And yeah, someday there will be the VE-compatible-wikitext thing, which will allow you to switch from visual-editing of WYSIWYG to visual-editing of wikitext. But why wait, when we can upgrade wikiEd, with a laser-focus effort today, to make it site-wide rather than a manually-enabled-gadget or a manually-installed-greasemonkey-script? Think of it as a prototype, which will help field-test what actual wikipedians doing actual wikitext editing, will actually *want* to see in the future VE-style thing. 75.108.94.227 21:52, 13 December 2015 (UTC)

Chế độ giao diện người dùng mặc định

Những người đã chỉnh sửa trong một thời gian dài thường có giao diện được cá nhân hóa cao và cũng có quyền truy cập vào nhiều công cụ/quyền khác nhau không có sẵn cho người dùng mới. Đây là cả hai điều quan trọng, nhưng nó gây khó khăn cho người dùng hiện tại để hiểu các vấn đề mà người dùng mới phải đối mặt. Một ví dụ thực tế của việc này là, khi thuyết trình cho người dùng mới tại các sự kiện tiếp cận, nhiều Wikimedian tạo một tài khoản người dùng 'giả' đặc biệt để có thể hiển thị giao diện người dùng 'mặc định' trên màn hình cho người mới. Quan trọng hơn, người trình bày không bao giờ thực sự nhấn 'lưu' khi hiển thị cách chỉnh sửa, bởi vì tài khoản người dùng này sẽ nhận được quyền tự động xác nhận.

Tôi đề xuất việc tạo ra một người dùng thích 'chế độ' làm cho cả giao diện người dùng và quyền người dùng là "mặc định" cho người dùng mới được đăng ký. Gọi nó là "chế độ người dùng mới" hoặc "chế độ mặc định". Quan trọng, chỉnh sửa ở chế độ này có nghĩa là người dùng KHÔNG ĐƯỢC 'tự động xác nhận' khi họ lưu các chỉnh sửa của họ nhưng WOULD vẫn tính sự thay đổi trong số lần chỉnh sửa của họ. Nó có thể được đánh dấu trong lịch sử với một thẻ #defaultMode hoặc một cái gì đó. Wittylama (talk) 10:27, 21 November 2015 (UTC)

Earlier discussion and endorsements
Wouldn't it be easier to have a preference setting "incognito", which when on, just strips all preferences to the defaults? I think it is best to be able to act as yourself whenever possible. I understand the need, but it should be doable without an extra account. Alternatively, there could be a "Newbie" account that is not a real account (i.e. cannot save edits). This would be a variation of the sandbox theme. --Jane023 (talk) 14:35, 21 November 2015 (UTC) I think that a preference setting called "incognito" implies that you're editing with the user-rights of an anon/IP editor (which is different form a newly registered/non-autoconfirmed editor). Also, "incognito" is a term used in some browsers that implies certain differences regarding privacy and tracking. I think that the word therefore sets an incorrect impression for the user about what it would mean, people might think that "being incognito" means they could leave messages without being identified by either their username or their IP, which isn't true. When you say "it should be doable without an extra account" - yes, precisely. That's what I'm hoping for. Currently, for people to see the default interface they either have to create a new user account, or log-out and edit as an anon, both are sub-optimal approaches. What I'm suggesting is a mode that works while logged-in to your existing user-account. The "newbie" account that cannot actually save an edit is also sub-optimal for that very reason. Wittylama (talk) 09:06, 22 November 2015 (UTC)  Endorsed OK, got it now. --Jane023 (talk) 10:15, 22 November 2015 (UTC)  Endorsed In addition, it could be useful for testing an abuse filter. In many cases, there's a condition like user_age <= 900 which may be fulfilled by a "new user mode". -- Juetho (talk) 10:22, 22 November 2015 (UTC)

Phiếu

1. Oppose this won't really take the place of using a fresh account if that is what is trying to be demonstrated. (e.g. Having to solve captcha's, redlinking your own pages, etc). xaosflux ^Talk 00:22, 1 December 2015 (UTC)
2.  Oppose I sympathize with the rationale for this proposal, but I think coding it up will be rather complicated, with some unknown ramifications. The current workaround of creating a new, 'fake' account doesn't seem unreasonable. At best, this should be a very low priority. Stevie is the man! ^{Talk • Work} 16:52, 1 December 2015 (UTC)

   I understand your perspective Stevietheman. I just wanted to emphasise that the 'fake' user account method has the specific drawbacks that by saving edits it will become auto-confirmed and therefore move away from being a 'new' user account, and it also means that the presenter is forking their contributions (and therefore attributions). Wittylama (talk) 20:51, 3 December 2015 (UTC)

   I agree those are drawbacks. Nevertheless, it doesn't take much work to create a fake account on the rare occasions one needs one. Also note that on someone else's new account one may be mentoring, they will also become auto-confirmed in short order. Overall, while I can see the benefits of this proposal, I think the development effort required to fully deal with all the ramifications keeps me at an 'Oppose', especially with all the other proposals that we need much more. Stevie is the man! ^{Talk • Work} 17:59, 4 December 2015 (UTC)

3.  Support Szalakóta (talk) 16:50, 1 December 2015 (UTC)
4. Why not, instead, an option under "gadgets" that, when checked, overrides all other preferences/javascript/whatnot? Eman235/talk 21:16, 1 December 2015 (UTC)
5.  Support As a presenter, I understand the idea. That would be very useful but as Stevietheman has already pointed out, I think it would be rather difficult to implement. Litlok (talk) 08:19, 2 December 2015 (UTC)
6.  Support – Established editors training new users do need to be reminded what their trainees are going to be looking at when they're setting up new accounts; a "new user mode" sounds perfect, assuming it's possible to implement such a thing. The muddle resulting from the trainer's having a different interface must be off-putting to new users. Ham II (sgwrs / talk) 19:09, 2 December 2015 (UTC)
7.  Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)
8.  Support an option that would disable all custom js and css. -- Fauzan^{✆ talk} _{✉ email} 16:45, 4 December 2015 (UTC)
9.  Support Juetho (talk) 11:57, 12 December 2015 (UTC)
10.  Support This sounds like a useful idea but if it is as difficult as some people think it should not be a high priority. I would hope they would be a relatively easy way of creating such an option if so it would be worthwhile.--Sphilbrick (talk) 23:14, 12 December 2015 (UTC)

Bật Apertium trên cy, để dịch nội dung

Tracked in Phabricator:
Task T102101

Dịch nội dung KHÔNG hoạt động trên cy ; nó ngồi đó dư thừa, twiddling ngón tay cái của nó. Bật Apertium có nghĩa là nó có thể sử dụng được. Đây là cuộc thảo luận dẫn đến một cul-de-sac. Hãy giải quyết vấn đề này và kích hoạt dịch en -> cy. Llywelyn2000 (talk) 12:09, 20 November 2015 (UTC)

Earlier discussion and endorsements
@Runab WMF: in the above link mentions either enabling Apertium or "get a Moses setup in place". Either Apertium or Moses, but at the moment, it's neither! To quote Runab: "We do want to get it started again and would be really grateful if you know someone who can help us speed up the process. At present we are a little short on time and people to take up the challenge to get a Moses setup in place." Llywelyn2000 (talk) 07:18, 21 November 2015 (UTC) Further info here. Llywelyn2000 (talk) As that article mentions, it is a "“gisting” machine translation system for Welsh to English" – someone who knows Welsh would have to actually get involved with Apertium in order to create e.g. transfer rules for the other direction (currently, there are 144 transfer rules cy→en, but only 13 en→cy). If anyone is interested in getting involved with developing an en→cy translator, please get in touch! --Unhammer (talk) 12:46, 23 November 2015 (UTC) … and this would be a good time if anyone is/knows a high school student willing to get involved, since Apertium is now in the Google Code-In competition. --Unhammer (talk) 07:22, 24 November 2015 (UTC)  Endorsed -- Oergell (talk) 12:41, 20 November 2015 (UTC)  Endorsed -- Cymrodor (talk) 17:16, 20 November 2015 (UTC)  Endorsed -- Dafyddt (talk) 15:32, 20 November 2015 (UTC)  Endorsed -- AlwynapHuw (talk) 23:39, 20 November 2015 (UTC)  Endorsed -- Pwyll (talk) 11:20, 21 November 2015 (UTC)  Endorsed – Ham II (sgwrs / talk) 21:57, 21 November 2015 (UTC)

Phiếu

1.  Support --Isacdaavid (talk) 02:13, 1 December 2015 (UTC)
2.  Support --[Google works en - > cy, but is full of errors; NOT an option!] Llywelyn2000 (talk) 15:08, 1 December 2015 (UTC)
3.  Support Litlok (talk) 08:20, 2 December 2015 (UTC)
4.  Support Jason.nlw (talk) 09:59, 2 December 2015 (UTC)
5.  Support EdwardLane (talk) 11:37, 2 December 2015 (UTC)
6.  Support --Drgkl (talk) 11:53, 2 December 2015 (UTC)
7.  Support --Barcelona (talk) 11:54, 2 December 2015 (UTC)
8.  Support Cymrodor (talk) 12:56, 2 December 2015 (UTC)
9.  Support – Ham II (sgwrs / talk) 19:11, 2 December 2015 (UTC)
10.  Support, obviously. Eman235/talk 21:15, 2 December 2015 (UTC)
11.  Support AlwynapHuw (talk) 05:43, 3 December 2015 (UTC)
12.  Support - tucoxn\^talk 14:04, 3 December 2015 (UTC)
13.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
14.  Support --Rhyswynne (talk) 21:12, 4 December 2015 (UTC)
15.  Oppose Insufficient impact -- only affects a small number of wikis at best. MER-C (talk) 18:28, 6 December 2015 (UTC)
16.  Support - It's important to support smaller languages, and this one is well-covered by volunteers and has a local chapter to help support events there. Richard Symonds (WMUK) (talk) 14:46, 7 December 2015 (UTC)
17.  Oppose Content Translation is not for machine translation. It's only an auxiliary feature. On ukwiki we don't have machine translation either, but our translators use Content Translation quite often - as a UI that helps to do simple jobs like adapting links and references etc - so you generally don't really need machine translation, the CX is quite usable (unless it's as buggy as it used to be, which I doubt). Besides, the implementation of this would have local impact only. --Piramidion 12:34, 12 December 2015 (UTC)

Tạo tóm tắt tự động / * blah * / khi tôi thêm tiêu đề phần theo cách thủ công khi chỉnh sửa

Tracked in Phabricator:
Task T22307

Xem yêu cầu của Phabricator (được liên kết ở lề phải). Điều này đặc biệt hữu ích trên các trang thảo luận. Có vẻ như một nhiệm vụ tương đối dễ dàng. Có lẽ sau khi ngồi trong danh sách yêu thích trong sáu năm, một người nào đó có thể được chỉ định cho nó. Cảm ơn, Wbm1058 (talk) 14:53, 16 November 2015 (UTC)

Earlier discussion and endorsements
Endorsed Having the wrong section indicated is worse than having no section indicated at all. Swpb (talk) 19:50, 17 November 2015 (UTC)  Endorsed --Jane023 (talk) 10:47, 20 November 2015 (UTC)  Endorsed I really hate when it indicates the wrong section! --Alexmar983 (talk) 19:47, 23 November 2015 (UTC)

Phiếu

1.  Support I don't think it's a huge time sink to change your edit summary manually, but this would be a nice feature. Samwalton9 (talk) 10:13, 30 November 2015 (UTC)
2.  Support Jenks24 (talk) 10:23, 30 November 2015 (UTC)
3.  Support. --Stryn (talk) 18:55, 30 November 2015 (UTC)
4.  Support Dalba 20:21, 30 November 2015 (UTC)
5.  Support Szalakóta (talk) 16:52, 1 December 2015 (UTC)
6.  Support in clear cases where the new section is the beginning of what's inserted. Stevie is the man! ^{Talk • Work} 16:59, 1 December 2015 (UTC)
7.  Support -- 2ReinreB2 (talk) 17:19, 1 December 2015 (UTC)
8.  Support -- Grüße vom Sänger ♫^(Reden) 22:12, 1 December 2015 (UTC)
9.  Support Risker (talk) 03:46, 2 December 2015 (UTC)
10.  Support —Beleg Tâl (talk) 17:09, 2 December 2015 (UTC)
11.  Support – Ham II (sgwrs / talk) 19:12, 2 December 2015 (UTC)
12.  Support I tend to do this manually, but hardly anyone else does. Eman235/talk 21:16, 2 December 2015 (UTC)
13.  Support --Carrotkit (talk) 05:49, 3 December 2015 (UTC)
14.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
15.  Support --Jane023 (talk) 16:29, 4 December 2015 (UTC)
16.  Support - Doesn't save most of the people voting here much time, but that's not the point. The point is that there are lots of newbies and people who don't do this that affect our ability to determine the subject of comments on busy talk pages. — Rhododendrites ^talk \\ 17:33, 6 December 2015 (UTC)
17.  Support as proposer. Wbm1058 (talk) 19:06, 7 December 2015 (UTC)
18. Comment - It could be difficult to differentiate between edits where the new section is the full edit, and those where it is among other edits to other sections of the article. Bcharles (talk) 04:23, 9 December 2015 (UTC)
19.  Support Therud (talk) 09:23, 10 December 2015 (UTC)
20.  Support QuartierLatin1968 (talk) 04:38, 12 December 2015 (UTC)
21. 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)

Giảm một nửa bút chiến

Tracked in Phabricator:
Task T72163

Tất cả chúng ta đều có xung đột trong việc chỉnh sửa, những người trong số chúng tôi đã ở lại wikipedia hầu hết là những người đã học cách giải quyết chúng, hoặc thực hiện rất nhiều chỉnh sửa để giảm thiểu thời gian bị mất khi chúng ta có một cuộc xung đột. Đã có nhiều đề xuất về bugzilla và các nơi khác để giảm xung đột chỉnh sửa, nhưng họ không có tài nguyên như việc giữ các biên tập viên mới không sử dụng để được ưu tiên. Nhưng đây là một trong những điều mà các biên tập viên mới thấy khó chịu nhất về wikipedia, và thường thì đó là người mới, những người thua cuộc xung đột chỉnh sửa bởi vì họ đang dành vài phút cho bản chỉnh sửa của họ và người phân loại hoặc templater chỉ vài giây. (V / e tất nhiên làm cho điều này tồi tệ hơn bằng cách loại bỏ phần chỉnh sửa và làm chậm trình chỉnh sửa.)

Hiện tại, chúng tôi thậm chí không có số liệu thống kê công khai về số lượng người chỉnh sửa bị mất thông qua các xung đột chỉnh sửa. Đơn giản chỉ cần đo lường chúng và số lần chúng dự đoán một trình soạn thảo sẽ xác nhận đây là một trong những nguyên nhân lớn nhất của các trình chỉnh sửa mới tốt, nhưng thực sự khắc phục một số điều gây xung đột chỉnh sửa có thể mất ít tài nguyên.

Loại bỏ tất cả các xung đột chỉnh sửa sẽ yêu cầu một sự thay đổi mang tính cách mạng trong giao diện người dùng, nhưng việc giảm một nửa xung đột chỉnh sửa sẽ tốn một khoản đầu tư khá nhỏ.

Các cách cụ thể để giảm số bút chiến bao gồm:

1. Hãy coi việc thêm mẫu ở đầu bài viết hoặc danh mục ở cuối bài viết không xung đột với sự thay đổi nội dung ở giữa.
2. Đặt trước tất cả các bài viết mới tạo với các phần như == Tham khảo == và == Xem thêm == hoặc tương đương bằng các ngôn ngữ khác
3. Xử lý # giống như một tiêu đề phần vì vậy hai câu trả lời trong hai chủ đề khác nhau của cùng một phần sẽ không được coi là xung đột. WereSpielChequers (talk) 20:54, 10 November 2015 (UTC)

Earlier discussion and endorsements
Obvious  Endorsed. MER-C (talk) 21:36, 10 November 2015 (UTC)  Endorsed Great idea! ONUnicorn (talk) 23:09, 10 November 2015 (UTC) Related: phab:T108664 ("Interactive edit conflict resolution tool") Cscott (talk) 19:33, 11 November 2015 (UTC) Proposal (1) sounds simple enough. (2) is probably not a good idea. (3) should be obviated by Flow. Swpb (talk) 19:42, 17 November 2015 (UTC)  Endorsed Huge wall for newcomers, and for others too. Three-way diff on conflict could help experienced editors there. — Arkanosis ✉ 16:30, 18 November 2015 (UTC)  Endorsed 4nn1l2 (talk) 23:28, 18 November 2015 (UTC)

Phiếu

1.  Support 4nn1l2 (talk) 03:07, 30 November 2015 (UTC)
2.  Support I imagine there are even more methods which could be used to avoid edit conflicts, but the examples given here are a great start. Samwalton9 (talk) 10:08, 30 November 2015 (UTC)
3.  Support - anything we can do to reduce the potential causes of edit conflicts can only be a plus, provided that it doesn't take any noticeable amount of time or hog too much system resources. עוד מישהו Od Mishehu 16:10, 30 November 2015 (UTC)
4.  Support I don't want to prioritize edit conflicts too highly; maybe I've been lucky or maybe I'm editing the wrong places but they don't happen all that often. Annoying when they do and I understand how offputting they could be to a new editor. That said I see the potential for some low hanging fruit. Item 1 sounds relatively simple and straightforward. Item 2 has benefits beyond resolving edit conflicts. I support those two items and other items if relatively simple.--Sphilbrick (talk) 16:58, 30 November 2015 (UTC)
5.  Support Not too sure about #2 (although have no strong prejudice against it), but the others both seem like good ideas. — Bilorv (talk) 19:44, 30 November 2015 (UTC)
6.  Support --MGChecker (talk) 20:01, 30 November 2015 (UTC)
7.  Support MER-C (talk) 20:05, 30 November 2015 (UTC)
8.  Support Dalba 20:29, 30 November 2015 (UTC)
9.  Support Armbrust (talk) 22:41, 30 November 2015 (UTC)
10.  Support - Nothing annoys me more than edit conflicts (Especially if you're replying to someone at ANI and end up getting 6 edit conflicts!), It drives me mad and although I don't think anything can really be done I guess it would be nice if something could be done. –Davey2010^Talk 02:56, 1 December 2015 (UTC)
11.  Support Oh goodness, yes. Edit conflicts are a pain, and I know I cause them with my quick gnome edits, causing pain to someone who is actually trying to add valuable content to an article. Jonesey95 (talk) 05:07, 1 December 2015 (UTC)
12.  Support--Shizhao (talk) 09:20, 1 December 2015 (UTC)
13.  Support · · · Peter (Southwood) ^(talk): 14:00, 1 December 2015 (UTC)
14.  Support —Tito☸Dutta 14:45, 1 December 2015 (UTC)
15. Neutral Question: pre populate with references and see also, when there are no such content in the article? I'm sceptical about that, that's nothing that's done on svwp at least. Suggestion: there was another suggestion, I believe, about adding the headline "references" (and equivalents in other languages) when someone had added a <references />-tag, or similar. Or was it to add such a tag (and header) when someone had added ref-tags? Those are not bad suggestions at least, why not the latter? Afaik ref-s are auto-displayed if a finishing references-tag is missing, but why not perhaps auto-adding? 78.82.170.236 15:41, 1 December 2015 (UTC) (who btw just got an edit conflict.. :) But I was slow.) edit: that comment was me, somehow I was logged out.. Flinga (talk) 15:45, 1 December 2015 (UTC)
16.  Support --Andyrom75 (talk) 15:57, 1 December 2015 (UTC)
17.  Support Papuass (talk) 16:23, 1 December 2015 (UTC)
18.  Support Goombiis (talk) 16:26, 1 December 2015 (UTC)
19.  Support 1 as stated and 3 modified to include * (if not treated as a separate section already -- I'm not sure).  Oppose 2 bitterly as it would create multitudinous empty sections that would make the Wikipedia look like crap. I'm open-minded to other low-hanging fruit. Stevie is the man! ^{Talk • Work} 17:11, 1 December 2015 (UTC)
20.  Support -- Tisfoon (talk) 17:46, 1 December 2015 (UTC)
21.  Support --Warp3 (talk) 18:00, 1 December 2015 (UTC)
22. Partial  Oppose. I disagree with the point 2: Pre populate all newly created articles with sections such as ==References== and ==See also== or equivalents in other languages. I support the remaining two points. Jan.Kamenicek (talk) 18:46, 1 December 2015 (UTC)
23.  Support Artem.komisarenko (talk) 19:37, 1 December 2015 (UTC)
24.  Support point 1 and 3, not point 2. Gap9551 (talk) 20:04, 1 December 2015 (UTC)
25.  Support StevenJ81 (talk) 21:59, 1 December 2015 (UTC)
26.  Support Alkamid (talk) 07:37, 2 December 2015 (UTC)
27.  Support Especially #1. ...Aurora... (talk) 10:39, 2 December 2015 (UTC)
28.  Support : support points 1 and 3 but not point 2, many communities do not agree to add empty sections for the sake of having them for future — NickK (talk) 14:29, 2 December 2015 (UTC)
29. I  Support working on reducing edit conflicts but I strongly  Oppose the point 2. Matěj Suchánek (talk) 15:46, 2 December 2015 (UTC)
30.  Support Needs careful implementation, but would make life a lot easier for many editors. PamD (talk) 21:35, 2 December 2015 (UTC)
31.  Support #1 and 3 and anything else people come up with to reduce edit conflicts. Neutral about #2 (auto-inserting section headers). --Anypodetos (talk) 08:20, 3 December 2015 (UTC)
32.  Support Not convinced by #2, though. Three-way diff would be another valid approach. — Arkanosis ^✉ 13:55, 3 December 2015 (UTC)
33.  Support - tucoxn\^talk 14:05, 3 December 2015 (UTC)
34.  Support edit conflicts are one annoying feature. Graeme Bartlett (talk) 04:16, 4 December 2015 (UTC)
35.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
36.  Support Grüße vom Sänger ♫^(Reden) 17:20, 4 December 2015 (UTC)
37.  Support Lester לסטר (talk) 18:04, 5 December 2015 (UTC)
38.  Support the general idea, which addresses a major problem for new users, without wanting to get into the specific "how" myself (certainly not #2, but I imagine there are plenty of ways to go about this) — Rhododendrites ^talk \\ 17:36, 6 December 2015 (UTC)

    Comment. I'd support any proposal to reduce edit conflicts, though this one is fairly minor. I have had many edit conflicts over the years, but I don't recall any of them being because of the addition of a template at the top of the article or a category at the bottom. The one that bugs me the most is bots coming in to do something very minor (such as adding a date on an existing template - usually inline). I would support the notion that certain low maintenance bot edits do not trigger edit conflicts. But surely, better than that, would be an automatic note that popped up if you went to edit an article, and someone was already editing it. A note saying: "User:XXX is currently editing this article so any edits you make will result in an edit conflict, please try again in a few moments. If you continue to have problems, you may wish to contact User:XXX". As with some others, I am not certain about point 2. While I feel adding a reference section to article pages is useful, I am not convinced that every article needs a See also section. SilkTork (talk) 09:19, 9 December 2015 (UTC)

    From reading the instructions, non support comments are not counted, so I have indented my comment so it isn't counted. SilkTork (talk) 09:23, 9 December 2015 (UTC)

39.  Support --Ziko (talk) 13:51, 9 December 2015 (UTC)
40.  Support --Ochilov (talk) 15:18, 9 December 2015 (UTC)
41.  Support except #2 -- Juetho (talk) 11:57, 12 December 2015 (UTC) Comment Each project (Wikipedia, Wikibooks, Wikisource, etc.) has its own conventions to start a page. One project or portal may pre populate, but not via software.
42.  Support the proposal in general. But the description of the issue is a bit inaccurate. This may not be true for the newbies, but as for me, when I get an edit conflict, that's not a problem nearly at all. Of course, it consumes a few seconds and might be annoying, but I never lose my text. If I get a conflict, nothing prevents me from going back in my browser to copy what I've typed, and then pasting it where I intended to. Yes, newbies might not know these «workarounds», so that's really a problem for them. But I really don't understand why should an experienced editor need «to do lots of little edits in order to minimise the time lost» - I could rewrite a whole article in one edit without being afraid that an edit conflict takes place. It's just confusing that there might be experienced contributors that don't know such simple things.--Piramidion 11:55, 13 December 2015 (UTC)
43.  Support, because I often make large edits, which touch a half-dozen places (or more). If somebody has messed with *any one* of those places, e/c. And sure, I can manually find the five places where there *was* not actually a conflict... but that the "overly-cautious" mediawiki software prevented me from saving... and redo them, along with the one bit that actually caused the edit-conflict. I can imagine that VE-users will experience equally bad results, especially as they are starting to get ambitious. Imagine you are a beginning editor. Making a few typo-corrections, gives you a sense of accomplishment. So you start working on bigger changes. You are a good potential wikipedian, so you think hard about them, and you are a beginner at wikitext, so it takes you several preview-cycles to get it exactly right. Finally, your first major edit (or 2nd or 3rd or 4th... but not 1000th... you will get a LOT of edit-conflicts before you hit 1000 edit-count, especially if you make LARGE or complex edits). You click save. Edit conflict! Gumption trap. As for experienced editors, smarter software that doesn't have edit-conflicts will save them some time and annoyance; not much, just a few seconds and a slight amount of annoyance... but multiply the savings across ALL the long-haul highly-active editors, and you have improved efficiency... plus more importantly, morale. 75.108.94.227 22:04, 13 December 2015 (UTC)
44. Neutral I think a better edit conflict UI is the lower-hanging fruit (T108664) --Tgr (talk) 22:45, 13 December 2015 (UTC)

Màn hình so sánh hai sửa đổi được cải thiện

Tracked in Phabricator:
Task T15466

Tracked in Phabricator:
Task T15462

Bạn không chỉ yêu thích khác biệt như thế này. Có thể cải thiện chế độ xem diffcompare này. Để có cảm hứng, bạn có thể xem tiện ích wikEdDiff. http://i.imgur.com/R9ZfCA1.jpg The Quixotic Potato (talk) 06:41, 29 September 2015 (UTC)
[Kết hợp từ đề xuất riêng biệt:] Khi ai đó di chuyển một đoạn và sau đó chỉnh sửa nó, chỉnh sửa này không được hiển thị riêng biệt theo chức năng "Khác biệt giữa các thay đổi". Vấn đề này cũng xảy ra khi ai đó chèn một dòng trống phía trên một đoạn văn và sau đó chỉnh sửa nó. Cảm ơn, --Gnom (talk) 10:12, 12 November 2015 (UTC)

Earlier discussion and endorsements
@The Quixotic Potato: or cleanDiff, which is more like Wikimedia edit diff. Screenshot. --Edgars2007 (talk) 03:17, 3 November 2015 (UTC)  Endorsed Related: phab:T108664 ("Provide an interactive edit conflict resolution tool"), phab:T26617 ("Implement diff on sentence level"). cscott (talk) 18:30, 11 November 2015 (UTC)  Endorsed Very important. WikEdDiff already exists and the only thing that needs to be done is to make it work with the button "Show changes" while editing, right now this only works if the whole WikEd is enabled (then there is a separate button for WikEdDiff). --V111P (talk) 23:22, 12 November 2015 (UTC) @V111P: Not true. You can enable WikEdDiff separately: w:en:User:Cacycle/wikEdDiff. --Edgars2007 (talk) 06:48, 14 November 2015 (UTC) @Edgars2007: I know, but it doesn't work when editing, with the WikEdDiff gadget you can't see what changes you made before saving, so it's not a full replacement for WikEd. We use scripts for formatting and need to be able to look at the changes before saving. I already asked Cacycle on WikEdDiff's talk page about that, but don't know if and when I'll get a response. --V111P (talk) 09:30, 14 November 2015 (UTC) OK, thanks. Didn't notice that. --Edgars2007 (talk) 09:58, 14 November 2015 (UTC)  Endorsed improvements to diff. My pet peeve is when diff gets confused and lists unchanged paragraphs as both - and + text. It would also be nice if diff were smart enough to avoid cutting two <tags> in half (start and endpoints of diff-text inside tags) when it would be much cleaner to align on the tag boundary. I'm sure there's a lot that could be improved if diffs were targeted as a project. Alsee (talk) 20:22, 14 November 2015 (UTC)  Endorsed. This sounds like a good idea, since I think it would be a very useful improvement. Would this include improving the diff when removing empty lines, or when moving sections, as in the suggestion below? That would not the least be a useful feature, to the extent that it is possible to achieve. Flinga (talk) 16:43, 17 November 2015 (UTC)  Endorsed 4nn1l2 (talk) 23:24, 18 November 2015 (UTC) @Gnom: answer to your problem is w:en:User:Cacycle/wikEdDiff. --Edgars2007 (talk) 06:50, 14 November 2015 (UTC) Hi, Edgars2007, there are also other user scripts that address this problem. I would like to see one of these solutions integrated into MediaWiki. --Gnom (talk) 09:36, 14 November 2015 (UTC)

Phiếu

1.  Support 4nn1l2 (talk) 03:06, 30 November 2015 (UTC)
2.  Support Smarter/better diffs would be valuable. Digging through a poor diff can be slow and painful. Alsee (talk) 08:42, 30 November 2015 (UTC)
3.  Support This can be a real pain, especially when something as simple as a new paragraph throws it off, highlighting the entire thing. Samwalton9 (talk) 10:05, 30 November 2015 (UTC)
4.  Support Jenks24 (talk) 10:21, 30 November 2015 (UTC)
5.  Support MER-C (talk) 10:47, 30 November 2015 (UTC)
6.  Support --Gnom (talk) 12:00, 30 November 2015 (UTC)
7.  Support Lugnuts (talk) 12:03, 30 November 2015 (UTC)
8.  Support Badly needed. Debresser (talk) 12:59, 30 November 2015 (UTC)
9.  Support MrX (talk) 15:10, 30 November 2015 (UTC)
10.  Support --Sphilbrick (talk) 16:25, 30 November 2015 (UTC)
11.  Support BethNaught (talk) 17:45, 30 November 2015 (UTC)
12.  Support Tryptofish (talk) 18:12, 30 November 2015 (UTC)
13.  Support. --Stryn (talk) 18:59, 30 November 2015 (UTC)
14.  Support --MGChecker (talk) 20:00, 30 November 2015 (UTC)
15.  Support Dalba 20:28, 30 November 2015 (UTC)
16.  Support Matiia (talk) 20:29, 30 November 2015 (UTC)
17.  Support Voll (talk) 22:06, 30 November 2015 (UTC)
18.  Support Armbrust (talk) 22:42, 30 November 2015 (UTC)
19.  Support --Isacdaavid (talk) 02:17, 1 December 2015 (UTC)
20.  Support YES --Yodin^T 02:24, 1 December 2015 (UTC)
21.  Support per Samwalton9 - The amount of times I've come across edits like the above and despite sitting there for 5 whole minutes trying to figure out what the hell's changed you still can't figure it out, An improvement to this would help us all I think. –Davey2010^Talk 03:01, 1 December 2015 (UTC)
22.  Support Please. Doug Weller (talk) 09:42, 1 December 2015 (UTC)
23.  Support The diff screen should be much smarter. The example linked by the proposer is all too common, especially when non-ASCII characters are involved. Jonesey95 (talk) 05:09, 1 December 2015 (UTC)
24.  Support Casliber (talk) 05:11, 1 December 2015 (UTC)
25.  Support--Kippelboy (talk) 05:35, 1 December 2015 (UTC)
26.  Support - I think this is something many users will enjoy! Alleycat80 (talk) 09:02, 1 December 2015 (UTC)
27.  Support--Gbeckmann (talk) 09:18, 1 December 2015 (UTC)
28.  Support —Ynhockey (talk) 09:48, 1 December 2015 (UTC)
29.  Support - I'd also like to see an option to view a simple diff - one that just shows the article text without the wiki markup. --Anthonyhcole (talk) 10:07, 1 December 2015 (UTC)
30.  Support And make the line numbers actually mean something usable. · · · Peter (Southwood) ^(talk): 14:02, 1 December 2015 (UTC)
31.  Support --Arnd (talk) 14:45, 1 December 2015 (UTC)
32.  Support --Continua Evoluzione (talk) 14:52, 1 December 2015 (UTC)
33.  Support--KRLS (talk) 15:13, 1 December 2015 (UTC)
34.  Support – Haltiamieli (talk) 15:17, 1 December 2015 (UTC)
35.  Support — Quoth (talk) 15:19, 1 December 2015 (UTC)
36.  Support tufor (talk) 15:29, 1 December 2015 (UTC)
37.  Support --Nastoshka (talk) 15:40, 1 December 2015 (UTC)
38.  Support --Andyrom75 (talk) 15:57, 1 December 2015 (UTC)
39.  Support Especially if it includes improving the diff when removing empty lines, or when moving sections (as I've meantioned in the earlier discussion, and which was also another suggestion then). The idea with "simple diff" above might also be something. Flinga (talk) 16:17, 1 December 2015 (UTC)
40.  Support Goombiis (talk) 16:27, 1 December 2015 (UTC)
41.  Support a real code typer.--Temp3600 (talk) 16:42, 1 December 2015 (UTC)
42.  Support JohanahoJ (talk) 16:46, 1 December 2015 (UTC)
43.  Support and also suggesting an improvement to identifying where the diff is from on the page. Line numbers aren't always useful. --2macia22 (talk) 17:00, 1 December 2015 (UTC)
44.  Support _anything_ that improves the various issues with diff. Stevie is the man! ^{Talk • Work} 17:20, 1 December 2015 (UTC)
45.  Support Genius plan, though I'm not sure exactly how or what changes need to be made. It seems like the current system's drawbacks are there for a good reason. -- 2ReinreB2 (talk) 17:22, 1 December 2015 (UTC)
46.  Support Wugapodes (talk) 17:24, 1 December 2015 (UTC)
47.  Support -- Tisfoon (talk) 17:43, 1 December 2015 (UTC)
48.  Support Jan.Kamenicek (talk) 18:48, 1 December 2015 (UTC)
49.  Support --Wesalius (talk) 19:01, 1 December 2015 (UTC)
50.  Support --Tdslk (talk) 19:04, 1 December 2015 (UTC)
51.  Support Jules78120 (talk) 19:48, 1 December 2015 (UTC)
52.  Support Any improvement here would be very useful. It seems that a minor relocation of a paragraph already 'hides' the actual change. Gap9551 (talk) 20:07, 1 December 2015 (UTC)
53.  Support --Woodcutterty (talk) 20:10, 1 December 2015 (UTC)
54.  Support --Akela (talk) 20:59, 1 December 2015 (UTC)
55.  Support Yes, improvement needed. Regards, Kertraon (talk) 21:59, 1 December 2015 (UTC)
56.  Support StevenJ81 (talk) 21:59, 1 December 2015 (UTC)
57.  Support --Grüße vom Sänger ♫^(Reden) 22:17, 1 December 2015 (UTC)
58.  Support Helder 23:48, 1 December 2015 (UTC)
59.  Support --Emptywords (talk) 00:08, 2 December 2015 (UTC)
60.  Support Vätte (talk) 01:17, 2 December 2015 (UTC)
61.  Support --Chaoborus (talk) 02:23, 2 December 2015 (UTC)
62.  Support Removing a line space causes the entire section to be marked, very easily to lose vandalism in there.--Loriendrew (talk) 03:44, 2 December 2015 (UTC)
63.  Support Risker (talk) 03:48, 2 December 2015 (UTC)
64.  Support In veritas (talk) 04:26, 2 December 2015 (UTC)
65.  Support Can this actually be fixed? The need for this is so obvious that I assumed some insurmountable technical hurdle must be preventing it from being done. Any improvement here would be most welcome. Antepenultimate (talk) 04:37, 2 December 2015 (UTC)
66.  Support Alkamid (talk) 07:36, 2 December 2015 (UTC)
67.  Support Litlok (talk) 08:22, 2 December 2015 (UTC)
68.  Support Sidevar (talk) 10:33, 2 December 2015 (UTC)
69.  Support ...Aurora... (talk) 10:42, 2 December 2015 (UTC)
70.  Support --β₁₆ - (talk) 11:46, 2 December 2015 (UTC)
71.  Support --Renessaince (talk) 14:22, 2 December 2015 (UTC)
72.  Support — NickK (talk) 14:40, 2 December 2015 (UTC)
73.  Support Matěj Suchánek (talk) 15:46, 2 December 2015 (UTC)
74.  Support --AlessioMela (talk) 19:47, 2 December 2015 (UTC)
75.  Support Smarter diffs in general - yes, please. PamD (talk) 21:37, 2 December 2015 (UTC)
76.  Support SteveStrummer (talk) 02:51, 3 December 2015 (UTC)
77.  Support absolutely. The biggest issue seems to be line insertion (e.g. insertion of a section header) and removal (e.g. deleting an empty line). --Anypodetos (talk) 08:16, 3 December 2015 (UTC)
78.  Support --V111P (talk) 10:27, 3 December 2015 (UTC)
79.  Support Oh yes please! Dcs002 (talk) 11:40, 3 December 2015 (UTC)
80.  Support — Arkanosis ^✉ 13:56, 3 December 2015 (UTC)
81.  Support - tucoxn\^talk 14:06, 3 December 2015 (UTC)
82. I'd support this but I suspect the real issue is too hard for the team. Cosmetic changes made by the WMF usually end up producing inferior software, like Special:MobileDiff/123456. Nemo 14:39, 3 December 2015 (UTC)
83.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
84.  Support This could save a lot of editor time. Mark MacD (talk) 13:13, 4 December 2015 (UTC)
85.  Support Jmatazzoni (talk) 17:47, 4 December 2015 (UTC)
86.  Support Grüße vom Sänger ♫^(Reden) 18:26, 4 December 2015 (UTC)
87.  Support Avgr8 (talk) 20:57, 4 December 2015 (UTC)
88.  Support --Yeza (talk) 16:40, 5 December 2015 (UTC)
89.  Support Zamaster4536 (talk) 12:57, 6 December 2015 (UTC)
90.  Support -- Sir Gawain (talk) 14:25, 6 December 2015 (UTC)
91.  Support - Supporting the idea, but my sense is this would be a huge undertaking so I don't know how likely it is. Worth exploring, though. — Rhododendrites ^talk \\ 17:39, 6 December 2015 (UTC)
92.  Support Wbm1058 (talk) 16:05, 7 December 2015 (UTC)
93.  Support Mpn (talk) 18:25, 7 December 2015 (UTC)
94.  Support --Waldir (talk) 14:54, 8 December 2015 (UTC)
95.  Support Although at this point it's obvious this has practically unanimous support. Hopefully that means this gets some developer resources put to it. -- Llywrch (talk) 19:06, 11 December 2015 (UTC)
96.  Support and in particular make it easier to see where the diff only consists of the addition or removal of spaces. It's hard enough looking for punctuation but spaces are impossible. Martin of Sheffield (talk) 22:52, 11 December 2015 (UTC)
97.  Support Frewaz (talk) 23:18, 11 December 2015 (UTC)
98.  Support mainly spaces and punctuations -- Juetho (talk) 11:57, 12 December 2015 (UTC)
99.  Support Nocowardsoulismine (talk) 16:30, 12 December 2015 (UTC)
100.  Support HoboMcJoe (talk) 00:29, 13 December 2015 (UTC)
101.  Support --NaBUru38 (talk) 03:40, 13 December 2015 (UTC)
102.  Support In ukwiki we use FlaggedRevs extension. And have to mark edits as reviewed and appropriate. But sometimes an editor does small edit to a page, like adding empty lines before the paragraphs, and this really looks like the whole article has been rewritten. And there's no way to compare the two revisions except by reading the whole article. A really time consuming and annoying thing.--Piramidion 12:16, 13 December 2015 (UTC)
103.  Support --ESM (talk) 16:13, 13 December 2015 (UTC)
104.  Support --Tgr (talk) 22:43, 13 December 2015 (UTC)
105.  Support --Davidpar (talk) 14:26, 14 December 2015 (UTC)
106. Comment: (strong support), and in particular, please make the diff-view *interactive* so that I can use the mouse (or the finger on touchscreens) to "pull" parts of the diff which were incorrectly positioned by the software, into the correct location. Make sure you field-test the new diff-view with BEGINNING editors, people who have never used git in their life, people who don't live on the command-line. The color-coding and visual cues of the current diff-view are terrible confusing for beginning-wikipedians, in my experience. Be bold in trying to improve this feature, it is crucial to any serious collaborative work on controversial topics (politics/religion/emacs-vs-vim/etc), and in the current primitive state is almost painful to utilize. Go whole-hog on this one, maximize the resources thrown at it. It will be tempting to just take whatever existing FLOSS code for diffs is easily available, and give that a few tweaks. Don't do that. Sure, draw on the existing diff-app-ecosphere: but wikipedia needs a rock-solid diff, one which rarely makes mistakes, is interactively fixable when it does make errors, and overall is instantly clear to beginners who may never have seen a diff-tool in their lives. Thanks, 75.108.94.227 15:09, 14 December 2015 (UTC)

Giúp dễ dàng trích dẫn các trang khác nhau từ một cuốn sách dưới dạng một tham chiếu

Tracked in Phabricator:
Task T100645

Khi tôi trích dẫn các trang khác nhau từ một cuốn sách trong một bài viết, tôi phải trích dẫn cuốn sách một cách riêng biệt nhiều lần. Chúng tôi có chức năng "trích dẫn sử dụng lại" cũng hoạt động rất tốt trong VisualEditor nhưng không hoạt động cho các trang khác nhau từ cùng một cuốn sách. Xem nhiệm vụ Phabricator phab:T100645 và phab:T15127. Cảm ơn, --Gnom (talk) 10:07, 12 November 2015 (UTC)

Earlier discussion and endorsements
Comment I think the English Wikipedia already does this with en:Template:Rp. Davidwr/talk 05:54, 16 November 2015 (UTC)  Endorsed I don't recall ever seeing this template used (although I'm sure I could find out how many transclusions there are), but I think most editors are unaware of it, and usage seems more complicated than should be necessary. The ability to name a reference, and then within the subsequent citations, to simply add "page=27" or whatnot would simplify this and help reduce reference clutter on articles that cite multiple pages from the same source. Etamni (talk) 06:14, 17 November 2015 (UTC)  Endorsed I've used en:Template:Rp, and I agree that it would be simpler to be able to write <ref name=blah page=42/>. And simplicity equals adoption. Swpb (talk) 19:47, 17 November 2015 (UTC) Comment Rather than limit things to <ref name=blah page=42/> allowing either that form or <ref name=blah note="page=42"/> where the "note" is arbitrary and can be "chapter=3" or, for non-book items like web sites that require clicks to "un-hide" content or which don't allow direct deep linking, instructions like "Click on 'show more' tab" or "click on News->Archives->June 2015->Storm destroys Atlantis". Davidwr/talk 18:43, 20 November 2015 (UTC)

Phiếu

1.  Support I've always found using the workaround template a pain. Samwalton9 (talk) 10:12, 30 November 2015 (UTC)
2.  Support TeriEmbrey (talk) 15:59, 30 November 2015 (UTC)
3.  Support --Isacdaavid (talk) 02:18, 1 December 2015 (UTC)
4.  Support--Shizhao (talk) 09:21, 1 December 2015 (UTC)
5.  Support. Anthonyhcole (talk) 10:09, 1 December 2015 (UTC)
6.  Support · · · Peter (Southwood) ^(talk): 14:03, 1 December 2015 (UTC)
7.  Support GoEThe (talk) 14:57, 1 December 2015 (UTC)
8.  Support — Quoth (talk) 15:16, 1 December 2015 (UTC)
9.  Support --Vojtěch Dostál (talk) 16:15, 1 December 2015 (UTC)
10.  Support Goombiis (talk) 16:25, 1 December 2015 (UTC)
11.  Support This is why I usually just cite an entire book, but individual page mentions would be very helpful for researchers using Wikipedia as a starting point. -- 2ReinreB2 (talk) 17:24, 1 December 2015 (UTC)
12.  Support in a big way! This was needed years ago. Stevie is the man! ^{Talk • Work} 17:24, 1 December 2015 (UTC)
13.  Support This would be a great improvement over the current situation. -- _{• • hugarheimur} 18:11, 1 December 2015 (UTC)
14.  Support --Warp3 (talk) 18:15, 1 December 2015 (UTC)
15.  Support --Coentor (talk) 18:22, 1 December 2015 (UTC)
16.  Support Jan.Kamenicek (talk) 18:49, 1 December 2015 (UTC)
17.  Support -- Akela (talk) 21:00, 1 December 2015 (UTC)
18.  Support Vätte (talk) 01:21, 2 December 2015 (UTC)
19.  Support Beyond My Ken (talk) 02:14, 2 December 2015 (UTC)
20.  Support Risker (talk) 03:50, 2 December 2015 (UTC)
21.  Support Antepenultimate (talk) 04:50, 2 December 2015 (UTC)
22.  Support--Barcelona (talk) 11:58, 2 December 2015 (UTC)
23.  Support--Manlleus (talk) 15:14, 2 December 2015 (UTC)
24.  Support HughD (talk) 16:02, 2 December 2015 (UTC)
25.  Support PamD (talk) 21:40, 2 December 2015 (UTC)
26.  Support Wittylama (talk) 22:19, 3 December 2015 (UTC)
27.  Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)
28.  Support Graeme Bartlett (talk) 04:17, 4 December 2015 (UTC)
29.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
30.  Support -- Fauzan^{✆ talk} _{✉ email} 16:47, 4 December 2015 (UTC)
31. Neutral or  Support if this means some more love shown to w:template:sfn, which is the best way to cite individual pages, except it's more time-consuming, there's no handy citoid way of doing it and it doesn't work well with the Visual Editor (see T114105 and related tickets). Halibutt (talk) 00:06, 5 December 2015 (UTC)
32.  Support -- Sir Gawain (talk) 14:27, 6 December 2015 (UTC)
33.  Strong support - This seems like a good project for the community wishlist. It's a big pain, it's an even bigger pain to teach someone to do, and it seems like it wouldn't be all that difficult to fix. What about just adding a parameter to the ref tag for "pages" such that <ref name="abc" pages="21-39"/>? (yes, yes easier said than done, but compared to some of the other projects that would make a similar kind of impact to editing, it seems reasonable) — Rhododendrites ^talk \\ 17:42, 6 December 2015 (UTC)
34.  Support--Joris Egger (talk) 21:08, 7 December 2015 (UTC)
35.  Support Gamaliel (talk) 15:49, 8 December 2015 (UTC)
36.  Support I cannot emphasize enough how much easier this would make editors' lives. Daniel Case (talk) 19:20, 8 December 2015 (UTC)
37.  Support - Bcharles (talk) 04:58, 9 December 2015 (UTC)

    I'm not quite seeing the issue here as it's not difficult to copy a full citation, and then paste it where needed, changing the page numbers. It's a simple click, change page number, click, change page number, etc. Whatever solution that is done, would involve the same amount of editing: copy the citation template, click it into place, edit the page number. SilkTork (talk) 09:38, 9 December 2015 (UTC)

38.  Support Override-able page numbers would deal with the majority of cases. In the longer term I'd like to see something much smarter though. - Pointillist (talk) 15:18, 9 December 2015 (UTC)
39.  Support AlbinoFerret 18:32, 10 December 2015 (UTC)
40.  Oppose Once there are multiple pages from the same source you should move the source citation to a different section and use {{sfn}} or {{harvid}} to define the pages. Martin of Sheffield (talk) 22:56, 11 December 2015 (UTC)
41.  Oppose As Martin of Sheffield says, this sounds redundant to {{sfn}} and the like, which is incredibly powerful and slick and ought to be used more. QuartierLatin1968 (talk) 04:42, 12 December 2015 (UTC)
42.  Strong support This request is not redundant with {{sfn}} and {{efn}} and friends. Sure, those are slick templates. And sure, you *can* make a multi-section ref-architecture, which "solves" the problem this proposal is aiming to solve. *If* you are willing to settle for an inelegant solution, with weird syntax, which doesn't make ANY sense to beginning-editors. Or even to intermediate-level editors, for that matter. See also, harvnb, #tag workarounds, and other such things. Anything involving curly-braces in addition to <ref>-tags, is basically a kludge. That goes for general-purpose efn/sfn/etc curly-brace magic. That also goes for special-purpose {{rp}} which kinda-sorta solves this specific problem... but again, in somewhat inelegant fashion. This proposal is to SOLVE the problem, in an elegant fashion: according to implementation-phase-one outlined in phab:T100645, the basic idea is to add to XML attribs to the <ref>-tag, so that editors can modify the underlying {{cite book}} parameters on the fly. Now that is elegant. Even more elegant, would be to add some additional power to the <ref>-tag attributes, so that *arbitrary* portions of the underlying {{citation}} form could be replaced on the fly. So for instance, the main use-case here is about writing an article, sourced to a 999-page book, and wanting to cite specific sentences-or-paragraphs of the article-prose, to specific pages of the book in question. Here is what would be ideal to be able to utilize: first, define the book as a reference. {{reflist|refs= <ref name=stokes'10>{{cite book |title=Isaac Newton |author=Mitch Stokes |year=2010 |isbn=1-59555-303-7 |page=111 }}</ref> }} Next, in the body-prose of the article, say things like <ref name=stokes'10 page=222 /> and later for a different factoid <ref name=stokes'10 page=333 />. Now sure, you can do SOMETHING kinda equivalent using {{rp}} or {{efn}} kludges, that is true. But those are complicated syntax, and *still* limited. Consider the power to override other cite-template-params, besides the page-num, using ref-tag-attribs: what if you were working from the paperback, not the hardback? Simply say <ref name=stokes'10 page=444 isbn=2-60444-292-8 /> to indicate page 444 in the paperback edition. What if you are working from books.google.com? You can override the |url= param like this: <ref name=stokes'10 page=555 url=https://books.google.com/books?id=zpsoSXCeg5gC&pg=PA5552 />. Being able to override the |url= param is *extremely* useful when citing television shows such as C-SPAN's video uploads, for instance, the 2008 POTUS debates: http://youtube.com/watch?v=DvdfO0lq4rQ#t=111s which is distinct from http://youtube.com/watch?v=DvdfO0lq4rQ#t=222s. I would also like to be able to override the |quote= parameter, for when I am pulling five distinct factoids from a 5000-word blog-post, *without* endlessly repeating all the cite-web params. Now, it would be exceedingly rare to need to override cite-template params in ALL these ways (page/isbn/url/quote/etc) during the course of editing a single article... but implementation-phase-two of this proposal, it to store the ref-data as part of wikidata, and thus be able to use the same cite-template-data in multiple wikipedia articles. Unless there is a way to override the cite-template-params, using the ref-tag, this second phase cannot be made to work. Strong support on this idea. See also the related proposal, Editing#Nested_tag_support (and phab:T3310), which would be another way to elegantly solve this problem, albeit probably more difficult to implement without breaking existing wikipedia conventions. 75.108.94.227 18:56, 14 December 2015 (UTC)

Hợp nhất bản dịch nội dung và trình soạn thảo trực quan thành một công cụ

Khái niệm về bản dịch nội dung rất tốt. Các phiên bản wikipedia lớn nhất (đặc biệt là tiếng Anh) là nguồn chính cho các bài viết bằng các ngôn ngữ khác. Nhưng trong bản dịch Nội dung hiện tại, bạn chỉ có thể dịch một bài viết nhưng không thể thêm thông tin từ các nguồn khác, thêm tamplates cục bộ hoặc thậm chí thay đổi/thêm tệp phương tiện cho đến khi bạn xuất bản bài viết. Đề xuất của tôi là hợp nhất bản dịch nội dung và trình chỉnh sửa trực quan thành một công cụ, trong đó dịch sẽ là một tùy chọn. בנימין (talk) 15:16, 10 November 2015 (UTC)

Earlier discussion and endorsements
Endorsed Do you think you could make a quick mock-up of what a unified UI would look like? I'm all for bringing the tools closer together: it would be nice for all wikis to be able to easily look at the article in a related language as they edit, for instance. Cscott (talk) 19:28, 11 November 2015 (UTC)

Phiếu

1. Comment This is easy to fix: phabricator:T115375#1838090. Nemo 18:34, 30 November 2015 (UTC)
2. Neutral Nemo's suggestion sounds worth exploring, before tearing up the v/e code. Stevie is the man! ^{Talk • Work} 17:32, 1 December 2015 (UTC)
3.  Support I work a lot with the translation tool and this feature would make things a lot easier. At the momement I have to block an article for other people with "inuse" after publication to avoid edtiting conflicts with eager authors who want to fix the same problems I'm going to sort out (have to sort out) after publication due to differences in the structure of articles in different languages. --Drgkl (talk) 11:49, 2 December 2015 (UTC)
4.  Support--Manlleus (talk) 15:14, 2 December 2015 (UTC)
5.  Support --AS (talk) 09:40, 3 December 2015 (UTC)
6.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
7.  Support Lester לסטר (talk) 18:06, 5 December 2015 (UTC)
8.  Oppose If Visual Editor becomes the only way to translate, I would stop using Content Translator. I'm not convinced Visual Editor is good for me.--MisterSanderson (talk) 01:31, 14 December 2015 (UTC)

Hỗ trợ thẻ lồng nhau

Một số phần mở rộng (ví dụ: mw:extension:Cite) thiết lập các thẻ (<ref> trong trường hợp này) được phân tách dựa trên giả định "một lần". Tức là các cấu trúc Primary text<ref>Outer footnote<ref>Inner footnote</ref> continuation of outer footnote</ref> continuation of primary text đơn giản sẽ không phân tích cú pháp, dẫn đến sự sợ hãi và không thân thiện

error

lỗi. Chắc chắn đó là thời gian qua để giải quyết một vấn đề cơ bản như vậy? AuFCL (talk) 00:32, 13 November 2015 (UTC)

Earlier discussion and endorsements
Just to extend the generality of the above I have also seen users attempt to nest <poem> tags within <poem> tags to similar levels of frustration (at least there is not a big red cryptic error in this instance but it still does not work.) AuFCL (talk) 05:25, 13 November 2015 (UTC)  Endorsed. If there are technical reasons for not being able to nest these tags, at least clean up the message and be more specific where the problem is. Etamni (talk) 06:17, 17 November 2015 (UTC)

Phiếu

1.  Support strongly, at least for <ref> tags. --Purodha Blissenbach (talk) 14:40, 1 December 2015 (UTC)
2.  Support Szalakóta (talk) 16:54, 1 December 2015 (UTC)
3. Comment What would be the purpose of a nested ref tag? Stevie is the man! ^{Talk • Work} 17:35, 1 December 2015 (UTC)
4.  Support Jan.Kamenicek (talk) 18:51, 1 December 2015 (UTC)
5.  Support --Usien6 (talk) 19:28, 1 December 2015 (UTC)
6.  Support Popcorndude (talk) 03:34, 2 December 2015 (UTC)
7. Comment As Stevietheman said, when does anyone ever use nested refs? Eman235/talk 21:21, 2 December 2015 (UTC)

   FWIW, I've wished for this capability on more than one occasion (e.g. being able to put a 'ref' inside an inline 'note'). But this isn't enough of a priority "wish" for me to vote "support" (at least, not yet)... IJBall (talk) 04:01, 3 December 2015 (UTC)

8.  Support I've run across this at least once. -- Fauzan^{✆ talk} _{✉ email} 16:49, 4 December 2015 (UTC)
9.  Support. There is a workaround though and I'm using it very often. Halibutt (talk) 00:08, 5 December 2015 (UTC)
10.  Oppose - A fine idea, but just not something that happens often enough (and when it does, there's a workaround as noted above) that it would make a markedly lesser impact than many of the other proposals — Rhododendrites ^talk \\ 17:45, 6 December 2015 (UTC)
11.  Support "When does anyone use nested references?" The advice page en:Nesting footnotes explaining that the obvious way to do this doesn't work receives a steady 40 or so views per day. Noyster (talk) 13:31, 7 December 2015 (UTC)

    I expect the link Noyster intended above might (indeed more specifically) have been: en:WP:Nesting footnotes#What_does_not_work? AuFCL (talk) 21:36, 8 December 2015 (UTC)

Cộng tác viên trang

Tracked in Phabricator:
Task T49721

Trước khi chuyển sang các phòng thí nghiệm công cụ (tôi đang sử dụng thuật ngữ đúng?), Chúng tôi đã có một công cụ nhỏ tiện lợi trên wikipedia tiếng Anh, nó vượt trội hơn nhiều so với những gì chúng tôi hiện có dưới 50 cộng tác viên hàng đầu.

Bằng cách nhấp một nút đơn giản, người dùng có thể xem tất cả người chỉnh sửa đã từng chỉnh sửa một trang được sắp xếp theo 8 cách khác nhau. Điều này rất hữu ích khi cố gắng đánh giá mức độ hoạt động của w:WP:WikiProjects, và có ích cho những người như tôi, người chỉ thỉnh thoảng tham gia vào một trang thảo luạn, nhưng khi họ muốn có một số nền tảng về đối tượng tiềm năng trước khi thực hiện một kẻ ngốc hoàn toàn.

Công cụ hiển thị danh sách các biên tập viên đã tham gia vào trang. Có 4 cột, mỗi cột có thể được sắp xếp từ trước ra sau và ngược lại:

• ID người dùng
• số lần chỉnh sửa cho trang
• ngày chỉnh sửa đầu tiên
• ngày chỉnh sửa cuối cùng

Nó đã nhanh chóng và hiếm khi (nếu bao giờ) thất bại, trong khi công cụ chúng tôi hiện chỉ liệt kê 50 biên tập viên hàng đầu, không thể được sắp xếp và bị hỏng rất nhiều.

Cảm ơn bạn đã xem xét đề xuất này. Ottawahitech (talk) 19:18, 18 November 2015 (UTC)

Earlier discussion and endorsements
Endorsed action=credits should be made fast and good enough to be enabled on Wikimedia wikis: a lot of interface, tools and external software or data users would benefit from it. Nemo 10:38, 22 November 2015 (UTC)

Phiếu

1.  Support--Shizhao (talk) 09:23, 1 December 2015 (UTC)
2.  Support I agree this should be built-in. Stevie is the man! ^{Talk • Work} 17:40, 1 December 2015 (UTC)
3.  Support Risker (talk) 03:51, 2 December 2015 (UTC)
4.  Support--Manlleus (talk) 15:17, 2 December 2015 (UTC)
5.  Support This would be incredibly useful. Eman235/talk 21:22, 2 December 2015 (UTC)
6.  Support --Misibacsi (talk) 04:43, 3 December 2015 (UTC)
7.  Support --YBG (talk) 06:10, 3 December 2015 (UTC)
8.  Support — Arkanosis ^✉ 13:57, 3 December 2015 (UTC)
9.  Support -- SantiLak (talk) 10:39, 4 December 2015 (UTC)
10.  Support Halibutt (talk) 00:09, 5 December 2015 (UTC)
11.  Support - I don't know the background about who developed it, which will almost certainly have bearing on whether this can be a wishlist project, but definitely a useful tool. — Rhododendrites ^talk \\ 17:49, 6 December 2015 (UTC)
12.  Support This would be very helpful. Corinne (talk) 03:05, 7 December 2015 (UTC)
13.  Support--Joris Egger (talk) 21:10, 7 December 2015 (UTC)
14.  Support SteveStrummer (talk) 01:47, 10 December 2015 (UTC)
15.  Support -- Llywrch (talk) 19:08, 11 December 2015 (UTC)
16.  Support -- Juetho (talk) 11:57, 12 December 2015 (UTC)
17.  Support --Sphilbrick (talk) 23:16, 12 December 2015 (UTC)
18.  Support -- NaBUru38 (talk) 03:42, 13 December 2015 (UTC)

Lưu sửa đổi trước khi xuất bản

Tracked in Phabricator:
Task T39992

Tracked in Phabricator:
Task T75241

Thường thì tôi nghĩ rằng tôi muốn lưu một bản chỉnh sửa - có nghĩa là tôi đã giữ nó trong hệ thống nhưng không muốn nó được xuất bản. Bạn biết sự khác biệt này từ Wordpress, nơi "lưu" khác với "xuất bản". Đặc biệt trong Trình dịch Nội dung, tôi muốn xem một tính năng như vậy. Nhân tiện, đôi khi tôi gặp phải sự cố khi tôi chỉnh sửa trong cửa sổ trình chỉnh sửa nhưng kết nối internet đã bị xóa; lưu văn bản chỉ vì sự an toàn sẽ là tuyệt vời. Ziko (talk) 23:41, 20 November 2015 (UTC)

Earlier discussion and endorsements
Endorsed BTW, Ziko, Content Translation saves your translation automatically ;) --KuboF (talk) 23:52, 20 November 2015 (UTC)  Endorsed. Helder 12:13, 22 November 2015 (UTC)

Phiếu

1.  Support 4nn1l2 (talk) 03:10, 30 November 2015 (UTC)
2.  Support בנימין (talk) 07:32, 30 November 2015 (UTC)
3.  Support Samwalton9 (talk) 10:27, 30 November 2015 (UTC)
4. Comment On the condition there will be no extra step in saving my edits. Debresser (talk) 13:02, 30 November 2015 (UTC)
5.  Support provided this is done only when the user wants it. עוד מישהו Od Mishehu 16:11, 30 November 2015 (UTC)
6.  Support --MGChecker (talk) 20:01, 30 November 2015 (UTC)
7. Comment Real-time preview and template parsing and offline storage and editing functionality already provided by Zhaofeng Li's elegant and easily used Scratchpad user script. Try it out with one line copy & paste to browser address bar; install as easily to enable bold editing of forked WP page, saved to browser, not Wikipedia. -- Paulscrawl (talk) 20:22, 30 November 2015 (UTC)
8.  Support. This would be very helpful. Most modern systems do work this way (e.g gmail, MSOffice.) DGG (talk) 02:18, 1 December 2015 (UTC)
9.  Support --Isacdaavid (talk) 02:20, 1 December 2015 (UTC)
10.  Support That functionality is already available in Extension:Drafts which I suggest to be installed on all WMF wikis. Btw. it serves us well on several nonpublic wikis.--Purodha Blissenbach (talk) 14:27, 1 December 2015 (UTC)
11.  Support Ckoerner (talk) 15:15, 1 December 2015 (UTC)
12.  Support --Dodi123 (talk) 16:51, 1 December 2015 (UTC)
13.  Support -- Tisfoon (talk) 17:47, 1 December 2015 (UTC)
14.  Support per Purodha. Stevie is the man! ^{Talk • Work} 17:50, 1 December 2015 (UTC)
15.  Support --Warp3 (talk) 18:32, 1 December 2015 (UTC)
16.  Support The scratchpad suggested Paulscrawl does not seem to be the full-blown alternative of what is requested in this proposal. Jan.Kamenicek (talk) 19:04, 1 December 2015 (UTC)
17.  Support Artem.komisarenko (talk) 19:38, 1 December 2015 (UTC)
18.  Support --Akela (talk) 21:03, 1 December 2015 (UTC)
19.  Support Yes. Regards, Kertraon (talk) 22:02, 1 December 2015 (UTC)
20.  Support Alkamid (talk) 07:39, 2 December 2015 (UTC)
21.  Support --β₁₆ - (talk) 11:48, 2 December 2015 (UTC)
22.  Support. Very useful to save a draft but not publish it for readers. Currently the only way to do it is either to publish somewhere in personal namespace or to save locally on your computer — NickK (talk) 14:50, 2 December 2015 (UTC)
23.  Support--Manlleus (talk) 15:17, 2 December 2015 (UTC)
24.  Support Yes, please add automatic saving of drafts ala Gmail. —Pengo (talk) 21:18, 2 December 2015 (UTC)
25.  Support. There has been more than one time that I have lost a large amount of work due to my computer crashing or something similar. Being able to save drafts would also be very helpful. Andrew Sheedy (talk) 00:55, 3 December 2015 (UTC)
26.  Support This seems like such a simple add-on, hardly demanding any resources. It would be more convenient than my old standby of copy/pasting & saving it in Notepad. Dcs002 (talk) 11:49, 3 December 2015 (UTC)
27.  Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)
28.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
29.  Support Jmatazzoni (talk) 17:38, 4 December 2015 (UTC)
30.  Support Halibutt (talk) 00:10, 5 December 2015 (UTC)
31.  Support Tar Lócesilion (queta) 12:58, 5 December 2015 (UTC)
32.  Support Plus i would suggest that there should a history of those saved edits just like in Etherpad. I have experienced problems when the text disappears in Content Translation and then it saves again and after half an hour all i have is an empty page.--Satdeep Gill (talk) 15:05, 7 December 2015 (UTC)
33.  Support O yes. Support this. And make it automatic so if I press the wrong button I only lose 5 minutes work, not half an hour! SilkTork (talk) 12:38, 9 December 2015 (UTC)
34.  Support --Ziko (talk) 13:48, 9 December 2015 (UTC)
35.  Support --Tgr (talk) 22:49, 13 December 2015 (UTC)
36.  Support --Kew Gardens 613 (talk) 22:59, 13 December 2015 (UTC)
37.  Support --Davidpar (talk) 14:30, 14 December 2015 (UTC)

Toán đơn giản trong bảng

Đó là sự hiểu biết của tôi rằng các nhà phát triển đang làm việc rất chăm chỉ để làm cho nó dễ dàng hơn để tạo ra các bảng trong trình soạn thảo trực quan. Chúng tôi chưa hoàn toàn có mặt ở đó và tôi đã thấy một trở ngại gần đây, nhưng chúng tôi gần như có thể sao chép và dán bảng hiện có từ bảng tính trực tiếp vào cửa sổ chỉnh sửa. Hiện tại, điều này cho phép di động bằng cách truyền dữ liệu di động, nhưng không cho phép một người thực hiện các chức năng bảng tính truyền thống như toán đơn giản (ví dụ tổng số mục trong một cột, tỷ lệ của hai ô). Trong khi chức năng đầy đủ của một bảng tính vượt quá phạm vi của những gì nên có sẵn trong wiki truyền thông, tôi thấy giá trị to lớn trong việc cho phép một số khái niệm đơn giản như tổng và tỷ lệ. (Tôi cũng muốn khả năng có các cột ẩn, mà tôi nghi ngờ là có thể về mặt kỹ thuật nhưng có thể không có ý nghĩa gì cả.)

Biên tập viên không theo sát các môn thể thao có thể không biết rằng chúng tôi có nhiều hàng trăm nếu không phải hàng ngàn bài báo với các bảng kết quả lịch sử cho các huấn luyện viên đội và các cầu thủ cá nhân. Một ví dụ, xem John Thurston.

Tóm lại, thách thức là, trong khi không khó để thêm một năm vào mẫu, hoặc cập nhật mẫu khi nhóm giành chiến thắng, tổng phụ của huấn luyện viên, theo hội nghị so với phi hội nghị, kết quả tích lũy tổng hợp và tỷ lệ phần trăm chiến thắng không được cập nhật tự động nhưng phải được chỉnh sửa riêng.

Thiết lập tạo hai vấn đề:

1. Khó hơn là nên —Cập nhật một trò chơi đơn giản là không dễ dàng - thay vì chỉnh sửa một trường, trình chỉnh sửa có thể cần chỉnh sửa tám trường. Hoặc có thể sáu, hoặc có thể bốn, nó phụ thuộc
2. Lỗi vẫn tồn tại —Nếu bất kỳ trình chỉnh sửa nào đều có lỗi, tổng số phụ và tổng số sẽ bị sai và chỉnh sửa tiếp theo làm cho tất cả các gia số đúng sẽ không khắc phục được sự cố nhưng vẫn giữ nguyên lỗi. (Ngoài ra, nếu một số biên tập viên ghi chú các tổng phụ sai và sửa chúng, chúng có thể sai vì một số mục nhập sai và bây giờ các tổng phụ là đúng nhưng mục nhập riêng lẻ là sai. Khi phần mềm không thực hiện tổng số, cá nhân mục và tổng số có thể không đồng bộ)

Để minh họa,

• Cách tiếp cận hiện tại khi trò chơi thắng:

1. Số lần giành chiến thắng tăng dần
2. Nếu một trò chơi hội nghị, số lần giành chiến thắng mùa tăng
3. Nếu giành được phần trăm mẫu, số lần giành chiến thắng tăng
4. Số lượng chiến thắng tăng huấn luyện viên
5. Nếu một trò chơi hội nghị, hội nghị mùa tăng dần giành chiến thắng tính cho huấn luyện viên
6. Nếu giành được phần trăm mẫu, tổng số lần giành chiến thắng cho tổng số huấn luyện viên
7. Tăng tất cả số lần giành chiến thắng
8. Nếu giành được phần trăm mẫu, tổng số lần giành chiến thắng cho tất cả tổng thời gian

• Cách tiếp cận được đề xuất khi trò chơi thắng:

1. Số tiền thắng gia tăng trong trường hội nghị, nếu một trò chơi hội nghị, hoặc trong trường không hội nghị nếu không hội nghị (phần mềm sau đó tính toán tất cả các tổng phụ và tỷ lệ).

Tôi đã trình bày điều này trong ngữ cảnh của các bảng thể thao, nhưng có rất nhiều bảng trong Wikipedia yêu cầu cập nhật không thường xuyên. Trong trường hợp các bảng này có tổng phụ và tổng số các vấn đề tương tự có thể tồn tại - các mục trong tổng phụ không đồng bộ. Biên tập viên nên sửa đổi các mục riêng lẻ và để máy tính thực hiện phép toán.

Tôi không biết liệu điều này có nằm trong phạm vi những thứ được xem xét trong phạm vi không. Nếu nó nằm trong phạm vi, tôi sẽ lưu ý rằng cuộc thảo luận ngắn gọn của tôi ở trên là không đủ, và tôi sẽ tình nguyện viết các trường hợp sử dụng được phát triển đầy đủ hơn và lấy thông số kỹ thuật.--Sphilbrick (talk) 17:23, 16 November 2015 (UTC)

Earlier discussion and endorsements
It may be possible to already do this via Lua Modules. I don't have much experience with writing Lua Modules myself, but maybe someone like Mr. Stradivarius would have a better idea. Ryan Kaldari (WMF) (talk) 03:03, 17 November 2015 (UTC) What Sphilbrick describes isn't quite possible in Scribunto. For someone to be able to edit certain rows of a table with VisualEditor and have other rows of that table updated by Lua modules, you would need to have one module invocation for each cell that you want updated. To do this, you would need to grab the latest wikitext revision of the page and then attempt to parse it to determine the module output. However, there are two problems with this: a) parsing wikitext reliably is really hard (for those who have never seen it, take a look at Parser.php), and b) the module output won't be updated on page preview, as it only uses the latest saved revision of the page. To do this properly in Lua you would need to replace the entire table with a template invocation. However, then you wouldn't be able to edit it with VisualEditor (at least not directly). — Mr. Stradivarius ♪ talk ♪ 07:43, 17 November 2015 (UTC) @Mr. Stradivarius: I was thinking about an all template solution. For example, why can't the Compact election box template on en.wiki compute all the percentages for you based on the votes rather than requiring you to compute and enter them as separate parameters? I imagine this could be handled with some math and rounding functions in Lua, right? FWIW, I don't expect spreadsheet features will be added into VisualEditor any time soon. I just don't think there's enough demand for it given the trade-off of making the table editing interface a lot more complicated (but who knows). I'm not on the Editing team, so I can't speak for them. Ryan Kaldari (WMF) (talk) 00:22, 24 November 2015 (UTC) @Sphilbrick:. "we are close to being able to copy and paste an existing table from a spreadsheet directly into an editing window." Can you link to any info on this? I wrote up a roundabout way to do this: Commons:Convert tables and charts to wiki code or image files. See section titled "Web to LibreOffice Calc to tab2wiki". I guess you can do something similar to solve some of the simple math stuff you are trying to do. Paste the wiki table into LibreOffice Calc, or into a tool at the Wikimedia Tool Labs. Then do the math there. Get the new table back in wikitext format directly, or by pasting the revised Calc spreadsheet into tab2wiki. --Timeshifter (talk) 14:31, 17 November 2015 (UTC)  Endorsed obvious need. Etamni (talk) 06:21, 17 November 2015 (UTC)  Endorsed Might have to use an intermediate tool at Wikimedia Tool Labs. --Timeshifter (talk) 14:35, 17 November 2015 (UTC)

Phiếu

1.  Support This, that and the other (talk) 13:23, 30 November 2015 (UTC)
2.  Support--Shizhao (talk) 09:25, 1 December 2015 (UTC)
3. Neutral I can see the value of this, but the development sink and unknown complexities scare me. Stevie is the man! ^{Talk • Work} 17:58, 1 December 2015 (UTC)
4.  Strongly oppose This proposal is all about making original research easier --Usien6 (talk) 19:33, 1 December 2015 (UTC)
5.  Support I would really like this as I often update tennis statistics. Basic arithmetic is not original research. It should be very simple though, e.g. adding named tags to two cells, and referring to these names in another cell to add the values. I don't think we should have all cells named by default as in common spreadsheets (A1, B2, etc). It is no problem if the initial creation of these tags takes some time, as it saves a lot of effort and errors in the long run. Gap9551 (talk) 20:39, 1 December 2015 (UTC)
6.  Support. And "simple math" is not considered to be OR. StevenJ81 (talk) 22:02, 1 December 2015 (UTC)
7.  Support Elections & disasters too. ...Aurora... (talk) 10:45, 2 December 2015 (UTC)
8.  Support In stories about current events, data updates can be frequent. This will help, and with lots of editors with varying levels of experience attracted to those articles, having an automatic check on the arithmetic is a good thing. Anything that facilitates and helps direct new editors' enthusiasm while building a better encyclopedia is thumbs-up! Dcs002 (talk) 12:04, 3 December 2015 (UTC)
9.  Support Having been frustrated by this more than a couple times in the past (and with a strong objection to the idea above that it's all about original research), I think this would be a great improvement. That said, I think revamping the way MediaWiki handles tables would make this a huge task, so it's probably most reasonable handled through templates (though I won't claim to know what I'm talking about :) ) — Rhododendrites ^talk \\ 17:54, 6 December 2015 (UTC)

Biến RefToolbar thành một phần mở rộng MediaWiki (hoặc thêm nó vào phần mở rộng WikiEditor)

Ngay bây giờ Reftoolbar chỉ có sẵn trên Wikipedia tiếng Anh (mặc dù có một phiên bản rất hạn chế trên Malayalam Wikipedia). Nó thường xuyên được yêu cầu rằng nó được biến thành một phần mở rộng để các dự án Wikipedia khác cũng có thể sử dụng nó.

Earlier discussion and endorsements
Endorsed +1 Yes we need to make adding references as easy as possible. Doc James (talk · contribs · email) 11:37, 27 May 2015 (UTC) Isn't mw:Citoid the extension that aims to cover Reftoolbar's feature set?--Qgil-WMF (talk) 08:13, 2 June 2015 (UTC) I don't believe so. Citoid is for automatic reference creation. RefToolbar is for (mostly) manual reference creation. Kaldari (talk) 17:13, 16 July 2015 (UTC) It looks like there isn't any chance of this happening, since the editing team is building a new WikiText editor that will have the VE citation-building interface. See bug T104479[1] (links from mw m w). Kaldari (talk) 18:41, 29 September 2015 (UTC) Citoid does the automatic reference creation part, but the 'Manual' tab in the cite inspector lets you choose Book/Website/Journal/... templates and uses TemplateData to make completing those easy on any wiki (not just English). As you can now seamlessly switch between VisualEditor and WikiEditor it wouldn't be sensible to invest any more time in RefToolbar, when we already have a superior feature in VE. ESanders (WMF) (talk) 04:46, 12 November 2015 (UTC)  Endorsed--Shizhao (talk) 07:58, 12 November 2015 (UTC)

Phiếu

1.  Support TeriEmbrey (talk) 16:00, 30 November 2015 (UTC)
2.  Support I generally support improvements which will make it easier for editors to add references. Making sure these capabilities exist in all languages is important. Count me as supporting this specific initiative, if a review of the various ways of improving inclusion of references identifies this as a good candidate.--Sphilbrick (talk) 17:02, 30 November 2015 (UTC)
3.  Support --Isacdaavid (talk) 02:21, 1 December 2015 (UTC)
4.  Support as per Sphilbrick. IJBall (talk) 03:35, 1 December 2015 (UTC)
5.  Support--Shizhao (talk) 09:26, 1 December 2015 (UTC)
6.  Support--Kimdime (talk) 12:12, 1 December 2015 (UTC)
7.  Support —Tito☸Dutta 14:46, 1 December 2015 (UTC)
8.  Support Ckoerner (talk) 15:14, 1 December 2015 (UTC)
9.  Support Goombiis (talk) 16:28, 1 December 2015 (UTC)
10.  Support –Krinkle 16:58, 1 December 2015 (UTC)
11.  Support love this tool on English Wiki. --2macia22 (talk) 17:07, 1 December 2015 (UTC)
12.  Support. We are talking about it on French Wikipedia. --Etiennekd (talk) 18:08, 1 December 2015 (UTC)
13.  Support Stevie is the man! ^{Talk • Work} 18:34, 1 December 2015 (UTC)
14. Comment There is a reftool bar on Czech Wikipedia that uses Czech citation templates and is customized for Czech Wikipedia needs. What would happen with it if this proposal was accepted? Would the RefTool bar that would become part of MediaWiki extension override the local Wikipedia RefTool bar? Or would there be two RefTool bars? Jan.Kamenicek (talk) 19:16, 1 December 2015 (UTC)
15.  Support --Usien6 (talk) 19:35, 1 December 2015 (UTC)
16.  Oppose We already have Citoid, which does a great job of inserting references automatically (from a URL) or manually (pretty much the same as RefToolbar). This would a duplication of that work. ESanders (WMF) (talk) 21:03, 1 December 2015 (UTC)

    It should be noted that Citoid is integrated into the Visual Editor that not everyone uses and is Opt-in. Stevie is the man! ^{Talk • Work} 22:40, 1 December 2015 (UTC)

    If you opt in to VE you can still use the wikitext editor for all your editing, and just switch to VisualEditor (mid-edit if necessary) if you want to add a citation. If you opt out of new features you don't get new features... ESanders (WMF) (talk) 00:26, 2 December 2015 (UTC)

    OK, but not everyone agrees that VE is a "new feature" but rather an optional one. In fact, many have rejected it for various reasons. It doesn't hurt VE users or Wikimedia projects to make the reftoolbar available to more wiki users. Stevie is the man! ^{Talk • Work} 17:41, 2 December 2015 (UTC)

17.  Support StevenJ81 (talk) 22:03, 1 December 2015 (UTC)
18.  Support Helder 23:48, 1 December 2015 (UTC)
19.  Support – Ham II (sgwrs / talk) 19:13, 2 December 2015 (UTC)
20.  Support This is a very useful tool and I'm surprised to hear that it's not available in other languages. Eman235/talk 21:26, 2 December 2015 (UTC)
21.  Support RefToolbar is so helpful, let's please share it with the other Wikis. PamD (talk) 21:39, 2 December 2015 (UTC)
22.  Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)
23.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
24.  Support — Rhododendrites ^talk \\ 17:56, 6 December 2015 (UTC)
25.  Support - Bcharles (talk) 05:14, 9 December 2015 (UTC)
26.  Oppose As mentioned above, refToolbar is already available on Czech wiki. It is available on Ukrainian Wikipedia and (I've just checked) on Polish and Russian wikis. So nothing really prevents people from adding refToolbar feature to their wikis. I guess, the Community Tech resources shouldn't be spent on such things.--Piramidion 12:55, 13 December 2015 (UTC)