MediaWiki talk:Edittools/Archive 7

This is an archive of past discussions about MediaWiki:Edittools. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 5

Safari 4.0

Cross-posted with revisions from en.wikipedia Village pump (technical):

Anyone else having problems with the edit window now, after upgrading to Safari 4.0 on a Mac? Instead of the drop-down menu with the clickable Edittools, I'm just getting the full list of them in a single view and non-clickable. Really a royal pain to have to type in all that coding by hand ... Mlaffs (talk) 18:01, 15 June 2009 (UTC)

Are you sure you have JavaScript enabled? --MZMcBride (talk) 18:08, 15 June 2009 (UTC)

It ought to be — I have it working properly in other places. It seems to only be with the Edittools and some of the scripts in my Monobook where I'm running into problems. I'll check when I get home though, and deliver a hefty dose of self-trout if it turns out to be that I'm THAT stupid... Mlaffs (talk) 18:41, 15 June 2009 (UTC)

Okay, yes, both Java and JavaScript are enabled. Upgrade to Safari 4.0 is the only difference in my setup that I can think of before the problems started. Mlaffs (talk) 03:54, 16 June 2009 (UTC)

Separate the Insert and Wikimarkup sets

Perhaps the "Insert" set could be moved out of, and above, the drop-down entries, so that the "Wiki markup" set is displayed as the default drop-down entry. Hence, the "Insert" and "Wiki markup" sets would both be available at once, without clicking required. Is that easily possible? Would there be any problems? -- Quiddity (talk) 19:42, 26 August 2008 (UTC)

I like the sound of that. -Eric ^talk 23:55, 15 September 2008 (UTC)

above copied from Archive 6

I'm not sure if this suggestion was missed or just unfavored. I've copied it out of the archive to give it another chance. (I still find myself switching back and forth between the two sets regularly.) -- Quiddity (talk) 23:02, 15 June 2009 (UTC)

I too find myself switching a lot between those two sets. But I would not like to have them both shown as default. One of the points of the compact javascript based version is to make this compact.

So I suggest we instead copy the "insert" symbols to the start of the "wiki markup" set, thus having a small and a large set. Note that <ref></ref> is already in both sets. And note that if you choose "wiki markup", then your browser remembers that setting, so you can sort of choose if you want the small or large set as your personal default. And to make it clear that the first few symbols are a repeat, I would like to make the "wiki markup" set look like this:

Insert: – — ‘ ’ “ ” ° ″ ′ ≈ ≠ ≤ ≥ ± − × ÷ ← → · § ~~~~ <ref></ref> Wiki markup: {{}} {{{}}} | [] [[]] [[Category:]] #REDIRECT [[]] <s></s> <code></code> <pre></pre> <blockquote></blockquote> <ref></ref> {{Reflist}} <references/> <includeonly></includeonly> <noinclude></noinclude> {{DEFAULTSORT:}} <nowiki></nowiki>

And making it like this is easy and requires no change in the javascript logic.

--David Göthberg (talk) 23:14, 22 November 2009 (UTC)

Support. Great solution. -- Quiddity (talk) 23:54, 22 November 2009 (UTC)

Done - I have updated the code, and it looks very nice. I didn't bother to force the browsers to drop the cached version, since most people will get this version on their next browser restart anyway. So bypass your browser cache to see the new version, if you don't already see it.

--David Göthberg (talk) 18:33, 3 December 2009 (UTC)

So much better. Thanks. -- Quiddity (talk) 20:08, 4 December 2009 (UTC)

Can the recent edits to MediaWiki:Edittools.js please be reverted until a broader consensus for these changes can be made? I keep the "Wiki markup" set up by default and the duplication of the "Insert" set inside this has really thrown me off since everything is in a different place. It would be nice if such changes with such wide-ranging effect were made with a bit more notice (other than this somewhat obscure talk page) and a bit more sitewide consensus. If the duplication is really thought necessary perhaps one of two things could be changed:

Move the duplicated "insert" set to the end of the "Wiki markup" set so that those of use who are used to the positions of the "Wiki markup" menu items are not inconvenienced by such a change.
Or, failing that courtesy, just create a completely new "Insert and Wiki markup" set that includes whatever it is y'all want in it but keeping the other sets as they were before the changes were made. — Bellhalla (talk) 03:00, 7 December 2009 (UTC)

Bellhalla: That we are changing the edittools has been announced repeatedly at the different Village pumps during the last few months, with links to this discussion page. (And probably before that too, but I haven't checked further back in the archives.) And this particular suggestion have been announced here since August 2008. Well, the final version of it was just announced for two weeks, still that is usually considered plenty of time.

What mostly seem to annoy you is that you now have to point your mouse to a slightly different spot than before to select each item. But give it a week or so and you will be used to the new positions. When we do changes we can't take such habits into account, instead we do what is the best from now on, otherwise Wikipedia would still look like it did in 2001. Having the insert group before the wikimarkup group is more logical, thus that is where it belongs. And creating a new group is unnecessary, since the insert group is short thus it doesn't take up much space in the wikimarkup group.

--David Göthberg (talk) 16:34, 8 December 2009 (UTC)

So two people want it, and I (and anyone else who object) can just go jump off a bridge, is what your saying? Fine… — Bellhalla (talk) 18:41, 8 December 2009 (UTC)

I'm not a big fan of this new change either. —TheDJ (talk • contribs) 20:05, 8 December 2009 (UTC)

Belhalla: Ehm, two? I see three names above: Quiddity, Eric and me (David). And up until you wrote here, no one against. But anyway, do you mind explaining what you find bad about it, apart from that you now have to move your mouse pointer to slightly new positions? And TheDJ, could you also explain what you find bad about it?

Note that before we did the change those of us who for instance use the dashes recommended in the Manual of Style (in the insert set) and wiki markup had to do a lot of clicking back and forth between the two sets. That's much harder than you having to relearn the exact positions of the items. When the compact javascript edittools were added there were lots of users that complained that they now have to click back and forth between the different sets. For many of us the old full set was more useful. The change we now have done makes the edittools at least reasonably easy to use.

--David Göthberg (talk) 21:47, 8 December 2009 (UTC)

I was looking only the people who were involved in this calendar year, so, yeah, I count just two. My main problem is that to compensate for one group's annoyance with the compact edittools, the change is forcing an annoyance on other users that had no problem with the setup as it was. Yes, my major dislike of the change is where the items are (now) located, but if my first suggestion above were implemented, I could turn your logic around and ask why you (and Quiddity and Eric, if he is still around) couldn't just get used to moving "your mouse pointer to slightly new positions" with the 'insert' set at the end. You would still save on the extra mouse clicks (does your browser not let you tab to the menu and select a set by typing it's first letter like mine does?) since you'll still have the same set, and you won't piss off any more people who liked it the way it was. — Bellhalla (talk) 23:19, 8 December 2009 (UTC)

Would a simple linebreak after the 'insert' set be a reasonable/efficient compromise? That way the items appear in the same order, and in the same layout. -- Quiddity (talk) 00:06, 9 December 2009 (UTC)

So like this?

Wiki markup: {{}} {{{}}} | [] [[]] [[Category:]] #REDIRECT [[]] <s></s> <code></code> <pre></pre> <blockquote></blockquote> <ref></ref> {{Reflist}} <references/> <includeonly></includeonly> <noinclude></noinclude> {{DEFAULTSORT:}} <nowiki></nowiki>  
Insert: – — ‘ ’ “ ” ° ″ ′ ≈ ≠ ≤ ≥ ± − × ÷ ← → · § ~~~~ <ref></ref>

That would work for me. — Bellhalla (talk) 13:59, 9 December 2009 (UTC)

Bellhalla: Do you use tab also to select the items within the sets?

In my browser I can't use tab even to reach the menu, since if I start from the edit window then there are about 100 items that come before in the tab order (about half of the items on the page, including all links in the preview). And shift-tab doesn't help either, since there are about 50 items between the edit window and the insert menu when going that way.

Since the insert set comes before in the menu, and is the shorter set, then I find it more logical to show it above the wikimarkup set, not below it.

Personally I would slightly prefer a line break between the insert and wikimarkup set, since it would look nice. For me it makes no practical difference in the screen resolution I use, but in some other screen resolutions that would make the wikimarkup set one line higher, and that's something I am pretty sure many editors would dislike. (Have you noticed that they changed the article message boxes so they now don't have line breaks after their heading?) So my guess is that more users prefer to not have a line break.

--David Göthberg (talk) 15:22, 9 December 2009 (UTC)

No, I can't tab within the sets. And, contrary to your opinion, I think because the "Insert" set is a duplicate, it should go below/after the "Wikimarkup" set for reasons outlined above. — Bellhalla (talk) 13:12, 13 December 2009 (UTC)

Other edittools sets

Please add to this list.

A few links to other sets of edittools, or related pages, worth considering when making changes to our sets. -- Quiddity (talk) 23:16, 15 June 2009 (UTC)

mercilessly

Add "mercilessly" back. It has always been a charming part of Wikipedia. (I'm a veteran under a new account.)Pzrmd (talk) 04:11, 16 June 2009 (UTC) {{sudo}}

Done for now since there was no consensus to remove it and the change is disputed (BRD and all). But why do we need this? A similar sentence is already present above the edit tools box. It is just redundant and I'd be in favor of removing one or the other. - Rjd0060 (talk) 17:46, 16 June 2009 (UTC)

Concur in the request. If there's any dispute about consensus, one simply needs to point to that lack of consensus for the recent change. :-) --MZMcBride (talk) 17:21, 16 June 2009 (UTC)

TOS summary part deprecated for new system message

Wikimedia Foundation wikis now display MediaWiki:Wikimedia-editpage-tos-summary below the save/summary section of the edit screen; this is for extended ToS type information that doesn't need to be directly above the buttons. Sorry for the inconvenience for en.wp as we're standardizing these messages now in all languages. Accordingly, Mediawiki:Edittools should really only be used for, well, editing tools and related help.--Eloquence * 21:34, 29 June 2009 (UTC)

Quotation marks

copied from Village pump (proposals) archive

The toolbar for inserting special characters has quotation marks listed in two sections: "Insert" and "Symbols". Currently the quotation marks are listed in the following order:

‘ “ ’ ” «»

while I suggest that they should be listed as

‘’ “” «»

The symbols by themselves are quite tiny so it's not too easy to click them with a mouse, especially when they are interspersed. However if we group them so that opening and closing quotation marks are inserted simultaneously (similarly to how «» works now), editing of articles might become somewhat easier. // Stpasha (talk) 01:17, 8 July 2009 (UTC)

Er, isn't usage of these sorts of quotation marks discouraged? Why would you need to use them anyway? - Jarry1250 ^{[ humourous – discuss ]} 17:01, 10 July 2009 (UTC)

This should be proposed at MediaWiki talk:Edittools. See/point-to Wikipedia:MOSQUOTE#Quotation marks (in the subsection "Quotation characters") for confirmation that curly-quotation marks are deprecated/not-recommended.

See also this older thread on the same topic: MediaWiki_talk:Edittools/Archive_5#Curly_quotes_problematic? which got them removed in 2007.

I've asked User:Random832 to comment on why he added them back in again, though. Perhaps they have an alternate common-usage in some subfield? (I can't see anything, after a quick glance through Quotation mark glyphs). HTH. -- Quiddity (talk) 21:28, 11 July 2009 (UTC)

end of copied thread

I've copied this thread here, before I forget about it. Something ought to be done, but I'm not sure what. User:Random832 seems to be on wikibreak, but I've pointed him here in case he comes back. -- Quiddity (talk) 22:32, 18 July 2009 (UTC)

Hmm. There's an unpleasantly long thread (which summarizes/links many of the archived threads) currently ongoing at Wikipedia talk:Manual of Style#Punctuation: Quotation marks: “regular” vs. "straight". I'm going to slowly try and round up some relevant details. I'll make notes here if I find anything pertinent/insightful/helpful. -- Quiddity (talk) 19:39, 23 July 2009 (UTC)

I don't like those curly quotation marks, I can't even see the difference between them unless I ask my browser to zoom the page a lot. The curly quotation marks are currently available in both the "insert" and "symbols" section. Having questionable symbols getting preferential treatment like that is strange. No other symbols are shown in both places. So I would like to remove them from the "insert" section and only keep them in the "symbols" section.

But as long as those curly quotation marks are in there, then they should at least be shown in a logical order. So I have fixed the order of them in MediaWiki:Edittools and MediaWiki:Edittools.js, both in the "insert" and "symbols" section. And Stpasha's request above to also lock them together is logical, so I have done that too. (But note that locking together only works in the compact javascript version of the edittools.) Although grouping them made the pair of single-curly-quotation-marks ‘’ look just like one straight quotation mark ".

By the way, I just discovered that the two symbols after the ° are the prime symbols: ″ ′. (Just mentioning this, since they confused me.)

--David Göthberg (talk) 22:36, 22 November 2009 (UTC)

Simplifying edit window instructions

I was watching one of the videos from usability study how one person was thoroughly confused with our instructions and links below the edit window. I propose to simplify/re-design it. It seems there are several mediawiki pages at work:

MediaWiki:Edittools
MediaWiki:Wikimedia-copyrightwarning: Content that violates any copyrights will be deleted. Encyclopedic content must be verifiable. You irrevocably agree to release your contributions under the Creative Commons Attribution/Share-Alike License 3.0 and the GFDL. You agree to be credited, at minimum, through a hyperlink or URL when your contributions are reused in any form. See the Terms of Use for details.
MediaWiki:Wikimedia-editpage-tos-summary: If you do not want your writing to be edited, used, and redistributed at will, then do not submit it here. Any text that you did not write yourself (apart from brief citations) must be available under terms consistent with Wikipedia's Terms of Use before you use it.
Something that shows "This page is a member of x hidden category(ies)"
Something that shows "Templates used in this preview" / "Pages transcluded onto the current version of this page"

My proposal: (a) merge the other two mediawiki pages to a sleeker version of edittools & (b) collapse the lists of hidden categories and template transclusions. Edittools would look like this (feel free to edit):

Once you click the Save button, your changes will be visible immediately.

For testing, please use the sandbox instead.
You irrevocably agree to release your contributions under the Creative Commons Attribution/Share-Alike License 3.0 and the GFDL.
You agree to be credited, at minimum, through a hyperlink or URL when your contributions are reused in any form. See the Terms of Use for details.

Please note:

If you don't want your writing to be edited mercilessly or redistributed for profit by others, do not submit it.
Content that violates any copyrights will be deleted without notice.
Only public domain resources can be copied without permission—this does not include most web pages or images.
Encyclopedic content must be verifiable.
See our policies and guidelines for more information on editing.

I have no idea, though, how to put the list of templates used into collapsible list -- but I am certain it must be done. At some point editing any article with Template:Infobox Settlement produced a list of hundreds of items (because of country data templates) -- all of which makes zero sense to a new editor. Ideas? Renata (talk) 23:36, 8 August 2009 (UTC)

I think we would be wise to synchronize any such effort with the usability team. —TheDJ (talk • contribs) 23:43, 8 August 2009 (UTC)

I don't think it has much to do with them. I just got inspiration from their video. Renata (talk) 16:30, 9 August 2009 (UTC)

Well I know they were gonna make some suggestions about this. —TheDJ (talk • contribs) 00:44, 10 August 2009 (UTC)

Removal of the symbol √

I see that √ has been removed from the short list of high-use mathematical symbols, with this reason in the edit summary: "should use latex".

I strongly suggest that it be put back. Non-specialist editors, working in non-specialist articles, may have to use the symbol incidentally – directly, or in quoting some use from a printed source. They have no idea how to use LaTeX, and it is unreasonable to expect them to learn. For anyone, in fact, special markup would be both disruptive and inconvenient in continuous text. Please see this from the common editors' point of view, not just the tech-head stance.

We who are working to help editors with uniform standards at WP:MOS are frustrated by this sort of difficulty. And after all, if only "official" ways of doing things were permitted by the edit tools, several other entities should not be here – like the pre-formed ellipsis (…), and the curly (or directed) quotes and apostrophe (‘ “ ’ ”), all deprecated at WP:MOS. But even sticking with mathematical symbols that presumably "ought" to be done in latex, how are ≈, ≠, ≤, ≥, ±, −, ×, and ÷ justified, if √ is not? How are m² and m³ justified, when guidelines call for the use of superscript instead? The rest of us would appreciate some consistency and rationality with these tools. And above all, some consultation with the expert copyeditors who work through issues at WT:MOS.

Thank you!

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 11:34, 16 August 2009 (UTC)

:The edittools box should not include symbols that violate guidelines. The better solution would be to have a dropdown for mathematical symbols that use the proper coding. ---— Gadget850 (Ed) ^talk 11:56, 16 August 2009 (UTC)

Something more thoughtful than a brief kneejerk reply would be helpful, Gadget. See also my remarks in another section, above. Not all editors should have to learn mathematical markup. They may have an occasional and incidental need for √, just as they do for ≈, ≠, ≤, ≥, ±, −, ×, or ÷. Please be considerate and consistent.

Meanwhile, we do not have "a dropdown for mathematical symbols that use the proper coding". Please be realistic also.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 12:22, 16 August 2009 (UTC)

I agree with Noetica - it does no harm to have the symbol there, and not every use should require the user to use LaTex. bd2412 T 13:39, 16 August 2009 (UTC)

Thanks BD, and thanks for reconsidering your short comment, Gadget.

Where in Wikipedia is there a guideline (let alone a policy) requiring LaTeX for casual or isolated use in non-specialist articles? MOS:MATH is the relevant part of our Manual of Style, and it is explicitly a guideline concerned with preferred markup for mathematical articles. I still request that the symbol √ be restored. It was apparently removed on a whim for ill-considered ideological reasons. We want a convenient and practical solution, and we want consistency. This is a call from a committed and deeply involved editor of WP:MOS; respond to it, please.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 23:40, 16 August 2009 (UTC)

I removed it on request... somewhere I don't recall. I think the problem was that having the symbol will cause it to be used for mathematical symbology where latex formatting should be used. I disagree it is unreasonable to expect people to be able to use latex, admittedly I do not fully understand it, but I would look it up if I needed to use it. If you feel that the symbol would be a net positive, feel free to add it back. Prodego ^talk 00:39, 17 August 2009 (UTC)

Thanks for explaining, Prodego. But ... you don't recall where you had the request to remove this common symbol? And you say: "admittedly I do not fully understand it". Yourself, even? I put it to you that you have been careless. The present request is here, public, and fully understandable. Please consider the matter of consistency that I raise: ≈, ≠, ≤, ≥, ±, −, ×, and ÷ are all present, and so are the MOS-deprecated symbols …, ‘, “, ’, ”, m², and m³. Why should √ be omitted, then? It is needed for incidental use in non-technical, non-mathematical articles.

And please answer my direct question (see above): Where in Wikipedia is there a guideline (let alone a policy) requiring LaTeX for casual or isolated use in non-specialist articles?

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 01:00, 17 August 2009 (UTC)

I've gone ahead and restored it for now, as I see no harm to having it there. You may need to refresh your browser window to see it. Cheers! bd2412 T 01:41, 17 August 2009 (UTC)

Much appreciated, BD. Thank you. Soon I intend to open a wider discussion about the management of the edittools resource (possibly at WP:VPT). The edit facility is used by all Wikipedians, and it deserves closer consideration than it gets now. In particular, I think there should be consultation with experienced MOS editors, and signalling of proposed changes at WT:MOS.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 02:48, 17 August 2009 (UTC)

I think the removal was on my request at VP. There is a world of difference between the inclusion of ≈, ≠, ≤, ≥, ±, −, ×, and ÷ and the inclusion of √. Whereas ≈, ≠, etc. render correctly √ does not, e.g. it'll give you "√2", notice the missing line over the two. This is going to be a great mess to clean up. Please get rid of it again. I can certainly understand how difficult it may be to use LaTeX, I've spent way too much time here and am still a LaTeX beginner. Sure, we want a simple way of producing square roots but don't we want something that looks right? How about ~~a template~~ adding <math>\scriptstyle \sqrt{}</math> instead? JIMp_talk·cont 06:38, 22 August 2009 (UTC)

Having the √ symbol is a good thing. That allows our maths people with LaTex expertise to search for √ and fix new such cases. It is better that article editors insert something that is about right, that we later can fix, instead of them not being able to insert text at all. So having the √ allows the wiki-process to work.

--David Göthberg (talk) 04:42, 22 November 2009 (UTC)

Pre

{{editprotected}}

Could we add <pre> & </pre> to the second row, please? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:30, 17 August 2009 (UTC)

Done — Martin (MSGJ · talk) 22:20, 23 August 2009 (UTC)

That'll save me a lot of bother; thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:23, 23 August 2009 (UTC)

New row: cleanup

Could we add an additional row, in slot 3, to contain cleanup/ citation templates like {{cleanup}}, {{unreferenced}}, {{refimprove}}, {{npov}}, {{fact}}, {{who}}, {{when}}, etc. I appreciate that there are a lot to chose from, but we could perhaps use the most-often transcluded. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:38, 17 August 2009 (UTC)

I strongly oppose that. People should spend time improving articles instead of plastering them with boxes complaining about them.

--David Göthberg (talk) 04:32, 22 November 2009 (UTC)

hbar

How about adding "ħ"? JIMp_talk·cont 07:04, 22 August 2009 (UTC)

It's under Latin and again under IPA. kwami (talk) 09:20, 22 August 2009 (UTC)

Thanks. JIMp_talk·cont 13:57, 22 August 2009 (UTC)

Tidying up editing instructions

Could we simplify and tidy up the editing instructions on this page just a little? It seems to be a product of years of tinkering by many different people, each with their own adjenda. Why is the first line formatted as ? Why is some text emboldened? Why do some links link to the "Project:" namespace? And what is the significance of the horizontal line? Something like this might be a little better:

Please note:–

When you click Save, your changes will immediately become visible to everyone. If you wish to run a test, please edit our Sandbox instead.
Please post only encylopedic information that can be verified by external sources. Please maintain a neutral, unbiased point of view.
Please do not copy and paste from copyrighted websites – only public domain resources can be copied without permission.
If you do not want your writing to be edited, read or redistributed by other people, then do not submit it here.

(My horizonal line is to seperate out the messages from the template and hidden category lists.) It isn't a major change, but I feel it will help newbies gain a basic grasp of our rules quicker, and removes a bit of visual clutter form the edit page. It also takes up less vertical room. – Anxietycello (talk) 05:09, 2 September 2009 (UTC)

See #Simplifying edit window instructions for some past discussion on a related matter. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 19:29, 2 September 2009 (UTC)

I have read that one, yeah, but mine is less of a major change, I feel. -- Anxietycello (talk) 13:36, 3 September 2009 (UTC)

Does anyone here agree that this is a step in the right direction? I posted a similar (but more radical) proposal to the Usability Initiative, and was met by unanimous support for change. I feel this is the place to start that change, if any admins agree? -- Anxietycello (talk) 23:08, 24 September 2009 (UTC)

{{editprotected}}

Can you post the exact proposed text here? — RockMFR 15:57, 26 September 2009 (UTC)

The exact text I propose, to replace all the text following the toolbox, is this:

Please note:–

When you click Save, your changes will immediately become visible to everyone. If you wish to run a test, please edit our Sandbox instead.
Please post only encylopedic information that can be verified by external sources. Please maintain a neutral, unbiased point of view.
Please do not copy and paste from copyrighted websites – only public domain resources can be copied without permission.
If you do not want your writing to be edited, read or redistributed by other people, then do not submit it here.

Anxietycello (talk) 16:23, 26 September 2009 (UTC)

Done. Cheers, Skomorokh 17:44, 26 September 2009 (UTC)

Link proposal

I'd like to link the newly created Wikipedia:Copy-paste (a summary document) to the word "copied" in "Only public domain resources can be copied without permission—this does not include most web pages or images." I'd welcome input on the appropriateness of this link. --Moonriddengirl ^(talk) 20:54, 10 September 2009 (UTC)

Strong support. Yes, this is definitely needed, I've seen it too often and new users need to be educated on this. Copy-pasting is a major problem and the more exposure this page gets the better. -- œ ^™ 21:41, 20 September 2009 (UTC)

Fixed - I see that someone has added that link, and also improved that sentence since then. Wikipedia:Copy-paste is a good text, so I agree with that addition. I just wanted to note that the change has been done, to save others from checking it.

--David Göthberg (talk) 16:56, 8 December 2009 (UTC)

Typo

{{editprotected}}

"encylopedic" —Noisalt (talk) 03:33, 27 September 2009 (UTC)

Fixed. -Trevor MacInnis ^contribs 04:54, 27 September 2009 (UTC)

Add an inner div

Resolved.

I intend to add a <div id="editpage-specialchars-inner">, inside the first div in this message.

Currently when loading an edit page this happens: The full static edit tools flashes, then the JavaScript in MediaWiki:Edittools.js kicks in and changes it to the compact edit tools. This is very noticeable on slower computers, where it costs rendering time and causes the scroll bar to jump up and down, since the page changes length.

We can't use CSS to hide the outer div, since then the JavaScript doesn't add the compact edit tools. Adding the inner div will allow using CSS in ones personal /monobook.css to hide the full message, but still get the compact edit tools.

I have tested this, it causes no visible change for users that have JavaScript disabled, not even the padding changes.

Here's the CSS you would add to your personal /monobook.css:

/* Prevent the larger edit tools to flash. */
#editpage-specialchars-inner {
    display: none;
}

I think I know how to add CSS from JavaScript, before the page renders. That could stop the edit tools from flashing for all JavaScript users, even without adding code to their personal /monobook.css. But the method I know means using "importStylesheetURI()" to load an extra style sheet, which seems inefficient. (But I am not sure if that loads the CSS before page rendering, I would have to test that.)

--David Göthberg (talk) 02:06, 12 November 2009 (UTC)

Regarding "personal css" approach: there is no need for another div since you can simply add the class:

<div id="editpage-specialchars" class="edittools-text" ...> in MediaWiki:Edittools

and use div.edittools-text {display:none} in users' monobooks.

But let's try better solutions. Appending the CSS with appendCSS (preferrably in Common.js) can hide the div even before its displayed on the page:

var etCSS = appendCSS('div#editpage-specialchars {display:none}')

After that we can simply use a different id for JS-generated div.

If the id really needs to be the same (I don't see why though), then we need to disable our CSS:

etCSS = etCSS.sheet || etCSS //for Webkit compatibility, if I remember correctly
etCSS.disabled = true

Or maybe remove our CSS:

$j(etCSS).remove() //since we have jQuery anyway

I'm not sure which way works better, might need some testing in different browsers. — AlexSm 04:51, 12 November 2009 (UTC)

Oh, you are right. I thought JavaScript could not operate on objects marked with "display:none;", but now that you pointed it out I tested it and fortunately I was wrong. So I have now added "edittools-text" to the classes in the outer div. And since there now is the "edittools-text" class I tested to add this to my personal JavaScript page:

  appendCSS('div.edittools-text { display:none; }');

That worked fine. It hid the div before the page was rendered. But the div added by the JavaScript in MediaWiki:Edittools.js doesn't have that class, thus the compact edit tools are still visible. So we don't need to remove the appended CSS.

There seems to be two good places we can put that line of code: Either in MediaWiki:Common.js, right before the line "importScript("MediaWiki:Common.js/edit.js")", or in MediaWiki:Common.js/edit.js right before the "addOnloadHook(){}" that loads the MediaWiki:Edittools.js. I lean towards adding it in MediaWiki:Common.js/edit.js since that keeps the related code in one place, and then that line of code will only have to be transferred to our editors, and not to our readers.

--David Göthberg (talk) 06:09, 12 November 2009 (UTC)

Hmm.. right after I pointed out that you can use the class I completely missed this option in my own solution. Yes, I guess the appendCSS should work fine in .../edit.js as well. — AlexSm 06:22, 12 November 2009 (UTC)

Well, that's teamwork. I identified a problem, you came up with most of the solution, I refined the solution. That's why I like to discuss things on the talkpage before I do changes. :))

So, I have added the "appendCSS()" code to MediaWiki:Common.js/edit.js. All seems to work.

--David Göthberg (talk) 07:17, 12 November 2009 (UTC)

Doesn't this break the case where users have disabled the JS edittools with window.noDefaultEdittools = true ? —TheDJ (talk • contribs) 12:02, 12 November 2009 (UTC)

TheDJ: Oops, you are right, good catch. So I did a little testing and came up with a solution. I added this code at the proper place inside the "addOnloadHook()" in MediaWiki:Common.js/edit.js:

//Show the static edittools again for users with "window.noDefaultEdittools=true".
appendCSS('div.edittools-text { display:block; }');

The edit comment I used when adding that was slightly incorrect. This new code doesn't cause the static edittools to flash off and on for those users, instead it just slightly delays when the static edittools are shown. I did a search and currently there is only one user that uses "window.noDefaultEdittools=true". The delay is so short that I doubt that user will notice it. While for all the rest of us, we are still relieved from the old flashing of the large static edittools before the compact edittools are loaded.

--David Göthberg (talk) 19:07, 12 November 2009 (UTC)

Ellipsis

Per WP:ELLIPSIS the use of the … symbol is not recommend. As such I have removed it from the list. Hopefully this is not a big deal, but if anyone objects, feel free to revert and discuss. --ThaddeusB (talk) 02:45, 22 November 2009 (UTC)

I think I agree with that removal, since I agree with what the Manual of Style says: Use three unspaced periods instead. Then we should also remove the ellipsis character from the compact version of the edittools: MediaWiki:Edittools.js. I can do that, but I'd like a comment from some more user first.

--David Göthberg (talk) 04:26, 22 November 2009 (UTC)

I made the original suggestion at WP:VPR, so needless to say I have no issues with the change.—NMajdan•talk 19:24, 22 November 2009 (UTC)

Nmajdan: Thanks for linking the Villag pump discussion. So it has even been well announced. Okay, I have removed the ellipsis from MediaWiki:Edittools.js.

By the way, that line now looks a bit empty, is there any other useful symbols we could add there instead?

--David Göthberg (talk) 21:35, 22 November 2009 (UTC)

No objections here. –Juliancolton | ^Talk 22:44, 22 November 2009 (UTC)

Hmpf, I miss the ellipsis, I've been using it regularly on user pages and hate punching in codepoints on my laptop keyboard. Anyway, if the idea is to pro-actively prevent MOS violations, the typographical quotation marks need to be removed in the same spirit (WP:MOS#Quotation marks and also #Quotation marks above). Or we need namespace dependent edittool definition. Amalthea 01:46, 12 December 2009 (UTC)

We could add it in the "Symbols" section instead. But having it in the "Insert" section would be bad. But why do you need it? Using three periods is so much simpler.

--David Göthberg (talk) 13:42, 13 December 2009 (UTC)

Simplicity doesn't factor into this, it's semantically wrong to use three dots, just as using two dashes (--) instead of an emdash (—) or using accents (` or ´) instead of apostrophes (' or, properly, ’) is. The MOS is what it (currently) is though, and it makes sense to make characters that are explicitly discouraged by the MOS less readily available, so I'm not pushing for bringing it back (but I do hope though that we'll eventually get the MOS to agree that we want properly typeset articles and encourage editors to input them as such, while of course welcoming editors to just use the characters they find on their keyboards and let other perfectionist/OCPD editors worry about bringing them in line).
Anyway, the same reasoning applies to the typographical quotation marks. Any objections to removing them as well? Amalthea 13:35, 14 December 2009 (UTC)

Yes, I agree with removing the curly quotation marks from the "Insert" set. They are available in the "Symbols" set, and we can probably keep them there.

--David Göthberg (talk) 16:43, 14 December 2009 (UTC)

I agree with Amalthea and David. It seems there's not much difference between ellipsis and curly quotes, except the MOS says the ellipsis is "too small in some fonts", which has been pointed out before as being a rather weak rationale. Which fonts are problematic, exactly, and why are we still concerned about them? Font inadequacies/non-coverage really don't seem to be preventing a plethora of other characters from being implicitly recommended in the edit tools.

I propose the following: 1. Since they're "not recommended", remove curly quotes from Insert, but leave them in Symbols. 2. Reinstate ellipsis, but only in Symbols for now. 3. Get someone from the WP:MOS community to defend and reconsider the recommendation against the precomposed ellipsis character. I've gone ahead with #3; please comment there if you have an opinion one way or the other. —mjb (talk) 10:51, 8 January 2010 (UTC)

Copyright symbol

Would it be possible to have the © symbol added to the "Symbols" set? It's something I tend to use and at the moment I'm having to copy/paste it from elsewhere, so adding it here would be a plus. PC78 (talk) 15:08, 6 December 2009 (UTC)

I've tried to do this - I added © ® ™ to the wikicode, but it is displaying that I've actually added ♭ ♯ ♮ which are probably useful symbols, but not what I added!? —Preceding unsigned comment added by Thryduulf (talk • contribs) 16:14, 6 December 2009

There is a difference between MediaWiki:Edittools and MediaWiki:Edittools.js. —TheDJ (talk • contribs) 16:29, 6 December 2009 (UTC)

Marvelous, thanks to you both! PC78 (talk) 16:38, 6 December 2009 (UTC)

We used to discourage these symbols being included in these sets, because they aren't generally used in articles, per WP:Manual of Style (trademarks): "Do not use the ™ and ® symbols, or similar, in either article text or citations, unless unavoidably necessary for context (for instance, to distinguish between generic and brand names for drugs).". Having the symbols obviously available generally led to over-use, with casualeditors adding them to every trademarked name until taught otherwise.

2 mentions (1, 2) in this page's archives. I'm sure there were more - where else was this discussed in the past? (just fyi: this thread is following from the current VP thread WP:VPT#Copyright_symbol). -- Quiddity (talk) 21:05, 6 December 2009 (UTC)

I'm not seeing any substantial discussion about these symbols in those old threads. I'm inclined to think that this is a hypothetical concern rather than a real one. The MOS does not prohibit their use in article space and indeed recognises that there will be legitimate uses of them, and if you look again it also discourages the use of other symbols such as ♥, which are also included in these sets. It's the same argument that's given in other threads on this page and at VP, i.e. that just because the MOS says we shouldn't normally use them in article text, it doesn't mean that they should never be used. PC78 (talk) 12:05, 7 December 2009 (UTC)

It was probably more of a concern back when all the 'sets' were displayed at once. Now that the 'Symbols' set is one of the non-default sets, casualeditors will be less likely to see it and make assumptions. (I have removed the symbols before, and seen a few other edits where people were reverting the addition of the symbols. I've even seen articles created with ™ in the pagename.)

However, I mostly just wanted to point out the history of these symbols here, and ask for further detail/comment. If nobody else objects, then I'm fine with them. :) -- Quiddity (talk) 20:10, 7 December 2009 (UTC)

Math and logic

Copied from mathsym in the same order, but with internal spaces removed:

'Math and logic': '= ≠ < > ≪ ≫ ≤ ≥ ∝ + − × · ÷ ⁄ ± ∓ √ |…| ||…|| ∣ ∤ || # ♯ ℵ : ! ~ ≈ ≀ ◅ ⋉ ⋊ ∴ ∵ ⇒ → ⊃ ⇔ ↔ ¬ ˜ ∧ ∨ ⊕ ⊻ ∀ ∃ ∃! := ≡ :⇔ ≜ ≝ ≐ ≅ ≡ {,} {:} {|} ∅ {} ∈ ∉ ⊆ ⊂ ⊇ ⊃ ∪ ∩ ∆ ∖ → ↦ ∘ ℕ N ℤ Z ℤn ℤp Zn Zp ℚ Q ℝ R ℂ C &#55349;&#56642; K ∞ ⌊…⌋ ⌈…⌉ ⌊…⌉ [:] [] [,] [,,] () (,) (,) ],[ (,] ],] [,) [,[〈〉<>〈,〉<,>〈|〉<|> (|) ∑ ∏ ∐ ′ • ∫ ∮ ∇ ∂ δ <: <· T ⊤ ⊥ ⊧ ⊢ ⊗ * x <math></math>'

Note, the last character x should have a bar over it. -Ste vertigo 23:00, 8 May 2009 (UTC)

This seems like a useful addition to me. —TheDJ (talk • contribs) 23:35, 8 May 2009 (UTC)

Yeah, adding a "Math and logic" section below the "Symbols" section could probably be nice. I have asked the people over at WikiProject Mathematics to come here and comment, since we could need some help to get the details right.

--David Göthberg (talk) 13:56, 13 December 2009 (UTC)

I'm a mathematics editor at WP:WPM, and I think this would be a very welcome addition. A perhaps more comprehensive list can be found User:KSmrq/Chars, but I don't notice any major omissions. Disclaimer: I am not a characterset–typography geek. Sławomir Biały (talk) 14:27, 13 December 2009 (UTC)

Looks good. Could the math template, e.g. {{math|...}}, be added as that's very useful; ideally with the same behaviour as format and markup tags.--JohnBlackburne (talk) 14:43, 13 December 2009 (UTC)

I am concerned about these, because I don't know what percentage of our readers are able to see symbols such as ℤ. Unfortunately I have never found any data on that, either. — Carl (CBM · talk) 15:28, 13 December 2009 (UTC)

Yes, it would be great to have at least the basic math symbols in Edittools! I'd suggest that you check that you have at least all symbols with HTML 4.0 entities in the list; these should work fairly well in modern web browsers. — Miym (talk) 17:04, 13 December 2009 (UTC)

As someone who does primarily math editing, my experience is that I mostly use what is already there. Italics, super- and subscripts, Greek letters and a few symbols that are already in the Insert section cover nearly all of my needs since more complex expressions need to be in LaTeX anyway. But I'm sure each of these symbols is used by someone who will appreciate not having to hunt through Unicode tables to find it. One thing I would like to see more accessible is the non-breaking space so expressions don't come apart at the end of a line. I noticed that overlines are left out from the mathsym page. If there is a reason this can't be implemented I understand, but if they can be implemented then I think they would be as useful as most of the symbols on the list. Also, the N, Z, Q, R, C, & K should probably be boldface; that might have been hard to see in the mathsym page. Another thought, in cases there there is more than one symbol for the same thing, it might be better to pick just one rather than offer every choice, that might encourage more uniformity in the articles and be less confusing for readers. In particular, WP:MOSMATH discourages the use of ℕ, ℤ, ℚ, ℝ, and ℂ, so maybe they should be left out.--RDBury (talk) 18:31, 13 December 2009 (UTC)

Don't leave the blackboard bold ℕ, ℤ, ℚ, ℝ, and ℂ out. These serve a useful purpose in order to maintain consistency throughout an article. Indeed, the main reason that MOSMATH discourages the use of these symbols is their lack of availability by conventional html shortcuts. If these were in the template, then it is possible that opinion on their use might change. At least for now, they are handy for getting rid of inline PNG's like

\mathbb {R}

. Sławomir Biały (talk) 18:58, 13 December 2009 (UTC)

If the reflected form of ⊢ is available, it would be appreciated in category theory (see e.g. lede of Adjoint functors where it is done in LaTex). Charles Matthews (talk)

U+22A3: ⊣. Algebraist 19:58, 13 December 2009 (UTC)

There's an overline template for overlining one or more characters. There are a few of them in the category, all of which you could make a case for but I think adding them all would be a bit much. The only other one I think is needed is =. --JohnBlackburne (talk) 20:24, 13 December 2009 (UTC)

Very nice, I hope this goes ahead. Looking through the list, I don't see ⇐, ℙ, ℍ, ≃, or the not versions of the commonly used set relations like ⊈, all of which would be good to have since they're used so often. Cheers, Ben (talk) 19:27, 13 December 2009 (UTC)

These would be good additions too. Sławomir Biały (talk) 20:06, 13 December 2009 (UTC)

I think we should only implement this set in the compact javascript version of the edittools. Since there it costs no extra space and most users have javascript enabled in their browsers anyway. (The static edittools are already a bit large, see MediaWiki:Edittools.)

I think we should leave out the "symbols" that can be easily typed on a keyboard. For instance [:] [] [,] [,,] () (,) (,) ],[ (,] ],] [,) seem unnecessary.

Carl: I use WinME, so I am one of the users who can't see the new Unicode characters. I have the same problem in all my browsers. Of the characters mentioned here so far I can't see these: ≪ ≫ ∝ ∣ ∤ ♯ ℵ ≀ ◅ ⋉ ⋊ ∴ ⇒ ⊃ ⇔ ∧ ∨ ⊕ ⊻ ∀ ∃ ∃ ⇔ ≜ ≝ ≐ ≅ ∅ ∈ ∉ ⊆ ⊂ ⊇ ⊃ ∖ ⌊ ⌋ ⌈ ⌉ ⌊ ⌉ 〈〉〈〉〈〉 ∮ ∇ ⊤ ⊥ ⊧ ⊢ ⊗ and ⊢ ⇐ ≃ ⊈. As you can see I can copy and paste them, but all I see is question marks "?". But I think you guys should use them anyway, since most users have newer operating systems, and if Wikipedia uses them it forces the browser and OS manufacturers to get their stuff right.

JohnBlackburne: Sure, we can add "{{math|...}}" if you guys need that.

Everyone: Since you guys are the maths experts, could you put together complete examples here so we can just cut and paste it into the code? Just like Stevertigo did in the first example above. Since I guess that some of the symbols you guys are suggesting fits best in a certain place in that list, right?

--David Göthberg (talk) 20:16, 13 December 2009 (UTC)

I recall there was a problem that at least one set of glyphs from the mathsym page (the angle brackets) were from an incorrect character set. There is some discussion of this at Talk:Hilbert space, which I won't pretend to understand. I have requested input from User:LutzL who first noticed this problem. But it would be a good idea to run this by the character set Geeks to make sure that everything is ok. Sławomir Biały (talk) 23:29, 13 December 2009 (UTC)

I'm no unicode expert, I only reported what I found on the net, after having problems with the 3008/3009 pair. One of my older sources is this page of utf8 vs. latex symbols. The other source were tables like [1].--LutzL (talk) 08:26, 14 December 2009 (UTC)

Any word on this? Cheers, Ben (talk) 22:36, 2 January 2010 (UTC)

What's the status of this proposal? Are we waiting for more feedback? Should this be advertised again on WT:MATH? — Miym (talk) 16:52, 22 January 2010 (UTC)

Well there is broad agreement that they should be added. I think it just needs someone to take the lead and make a clear request on which symbols they want adding. — Martin (MSGJ · talk) 17:44, 22 January 2010 (UTC)

Ok, thanks, I pinged WT:MATH; let's wait a couple of days until the proposal in #Sandbox below stabilises, and then we can make a concrete request. — Miym (talk) 18:05, 22 January 2010 (UTC)

Done - But this is just a first version, suggestions for improvements are always welcome.

MSGJ: We have that clear request already, it is the "sandbox" you see below.

Everyone: I (and I guess most of the other guys that understand this javascript page) simply have been busy elsewhere so we haven't gotten around to do it, sorry for the delay. This proposal has been up for quite some time now, and announced in some places, and it seems everyone likes this, and there is no better way to get feedback than deploying. And today I am editing from my girlfriends computer so now I see the characters, so I took the chance to deploy this today when I see what I am doing. I also added the "<math></math> {{math|}}" tags and also added them to the sandbox below, since they have been suggested above.

--David Göthberg (talk) 18:31, 22 January 2010 (UTC)

Many thanks, looks great! Let's see what kind of feedback we get when people start using the new toolbar. Everyone: when you spot any bugs/omissions/inconveniences, please update the sandbox below. — Miym (talk) 19:17, 22 January 2010 (UTC)

Sandbox

Here is a sandbox where we can edit the list. I have taken the original list, removed things that are easy to type (or create by combining symbols that are in the list) and added some symbols that were suggested in the discussion. Please go ahead and add your own favourites. — Miym (talk) 21:09, 13 December 2009 (UTC)

− × ÷ ⋅ ° ∗ ∘ ± ∓ ≤ ≥ ≠ ≡ ≅ ≜ ≝ ≐ ≃ ≈ ⊕ ⊗ ⇐ ⇔ ⇒ ∞ ← ↔ → ≪ ≫ ∝ √ ∤ ≀ ◅ ▻ ⋉ ⋊ ⋈ ∴ ∵ ↦ ¬ ∧ ∨ ⊻ ∀ ∃ ∈ ∉ ∋ ⊆ ⊈ ⊊ ⊂ ⊄ ⊇ ⊉ ⊋ ⊃ ⊅ ∪ ∩ ∑ ∏ ∐ ′ ∫ ∬ ∭ ∮ ∇ ∂ ∆ ∅ ℂ ℍ ℕ ℙ ℚ ℝ ℤ ℵ ⌊ ⌋ ⌈ ⌉ ⊤ ⊥ ⊢ ⊣ ⊧ □ ∠ 〈〉 ^a⁄_b   − <math></math> {{math|}}

I've tried putting it in a more logical order: easier stuff at the front, grouping related and visually similar things together, putting some stranded chars in better places. I don't know if it's much better, but it's easier to compared side by side with the previous version. I also added one, º, and removed one, ~. --JohnBlackburne^words_deeds 19:48, 22 January 2010 (UTC)

Why º? I think it would be good to have ordinal indicators º and ª somewhere, but I they aren't really math symbols. — Miym (talk) 20:38, 22 January 2010 (UTC)

º for degrees. I used it just two days ago here. It's one of those like ≤, ≥, ≠, √ which I can type but only with odd key combinations. ~ is ASCII so is not needed.--JohnBlackburne^words_deeds 20:49, 22 January 2010 (UTC)

º is an ordinal indicator. It is not a degree symbol. ° is a degree symbol. I've changed your list accordingly. Algebraist 20:53, 22 January 2010 (UTC)

You're right, thanks. Not sure how long I've been mistaking the two (º is option-zero on a Mac, ° is shift-option 8). --JohnBlackburne^words_deeds 21:00, 22 January 2010 (UTC)

Some tweaks: (1) The character &frasl; seems to be appropriate only in combination with superscript/subscript text: ^a⁄_b. If you tried to use it like "a⁄b", it looks strange (depending on the fonts, a and b may overlap with the slash and/or the slash may look too oblique). Hence I have replaced the character &frasl; with the combination ''a''&frasl;''b'' in the above list, to make it more clear what is the intended use. (2) I have added " ", which is very often needed in HTML math. (3) I have also added "−", which is strictly speaking a duplicate of "−" which we already have. However, I have noticed that many people prefer to use the HTML entity, which makes it much more clear that one hasn't mixed up characters like - – — −, some of which are near-indistinguishable in some fonts. — Miym (talk) 12:21, 24 January 2010 (UTC)

{{editprotected}} About time we added this. Please replace the Math and Logic section with the following (copied from above).--JohnBlackburne^words_deeds 15:25, 5 March 2010 (UTC)

− × ÷ ⋅ ° ∗ ∘ ± ∓ ≤ ≥ ≠ ≡ ≅ ≜ ≝ ≐ ≃ ≈ ⊕ ⊗ ⇐ ⇔ ⇒ ∞ ← ↔ → ≪ ≫ ∝ √ ∤ ≀ ◅ ▻ ⋉ ⋊ ⋈ ∴ ∵ ↦ ¬ ∧ ∨ ⊻ ∀ ∃ ∈ ∉ ∋ ⊆ ⊈ ⊊ ⊂ ⊄ ⊇ ⊉ ⊋ ⊃ ⊅ ∪ ∩ ∑ ∏ ∐ ′ ∫ ∬ ∭ ∮ ∇ ∂ ∆ ∅ ℂ ℍ ℕ ℙ ℚ ℝ ℤ ℵ ⌊ ⌋ ⌈ ⌉ ⊤ ⊥ ⊢ ⊣ ⊧ □ ∠ 〈〉 ^a⁄_b   − <math></math> {{math|}}

Done — Martin (MSGJ · talk) 09:36, 6 March 2010 (UTC)

Unfortunately, the text above and as implemented in MediaWiki:Edittools.js seems to have progressively lost two types of markup:

We've lost both + and the \ in <math>+</math> {\{math|+}} (missing too from the text above). The backslash is presumably intended to prevent transclusion in the code itself (though this doesn't seem to have resulted); the pluses are necessary to assist wrapping symbols around selected text.
The implemented code uses a⁄b instead of ''a''⁄''b''. I'm guessing that this is inadvertent and not a workaround for some undiscussed limitation in inserting multiple pairs of tags. The advantages of super/subscripting are discussed above.

Maybe a sandbox page would be helpful to check future changes before going live. There have been minor issues with other changes which a full sandbox page might have prevented, particularly where there is a need to distinguish between raw code and rendered text. It would then also be possible to show the non-javascript and javascript rendering on the same page for easy comparison.

By the way, there's currently a question at WP:VPT#Editing Question relating to entering wikimarkup from the toolbar. This may be unrelated to yesterday's change.

— Richardguk (talk) 19:15, 6 March 2010 (UTC)

Thanks for the report. I did notice those subtle changes when I made the edit, but assumed it was deliberate. I think I'll wait for User:Miym or User:JohnBlackburne to comment before reverting or trying to fix it. A sandbox would indeed be useful, but I don't know how we could properly test it. — Martin (MSGJ · talk) 08:23, 7 March 2010 (UTC)

I've had a look at the history and the "+" and "\" never must have been inserted last time as the math section was added, as they weren't on this page but they're not in Edittools.js now. As for a/b it was never properly inserted in the list. The following I think is correct, though I can't test it. I've put nowiki tags around the complex elements so they display properly, which should be removed if this is copied from the page source. Thanks.--JohnBlackburne^words_deeds 10:24, 7 March 2010 (UTC)

− × ÷ ⋅ ° ∗ ∘ ± ∓ ≤ ≥ ≠ ≡ ≅ ≜ ≝ ≐ ≃ ≈ ⊕ ⊗ ⇐ ⇔ ⇒ ∞ ← ↔ → ≪ ≫ ∝ √ ∤ ≀ ◅ ▻ ⋉ ⋊ ⋈ ∴ ∵ ↦ ¬ ∧ ∨ ⊻ ∀ ∃ ∈ ∉ ∋ ⊆ ⊈ ⊊ ⊂ ⊄ ⊇ ⊉ ⊋ ⊃ ⊅ ∪ ∩ ∑ ∏ ∐ ′ ∫ ∬ ∭ ∮ ∇ ∂ ∆ ∅ ℂ ℍ ℕ ℙ ℚ ℝ ℤ ℵ ⌊ ⌋ ⌈ ⌉ ⊤ ⊥ ⊢ ⊣ ⊧ □ ∠ 〈〉 ''a''/''b''   − <math>+</math> {\{math|+}}

I tried to implement the list above and the whole thing stopped working. (There were no edit tools shown at all.) So perhaps the sub and sup is breaking it somehow? If anyone can fix up a sandbox for this thing, it would be very helpful. — Martin (MSGJ · talk) 10:38, 7 March 2010 (UTC)

(edit conflict) The apostrophe pairs may have been getting converted to a javascript literal apostrophe. For the sake of simplicity, I suggest removing the apostrophe pairs altogether, as editors can choose to apply their own italics, and italics are not appropriate if the fraction is numeric.

Also, the code above had the fraction slash inadvertently replaced by an ordinary slash.

Below, I've replaced the nowiki tags with source tags at beginning and end and replaced "&" with "&", so the wikitext and rendered text are both identical to the proposed code, including the surrounding 'Math and logic': '...'. Hopefully this reduces ambiguity.

Try this:

     'Math and logic': '− × ÷ ⋅ ° ∗ ∘ ± ∓ ≤ ≥ ≠ ≡ ≅ ≜ ≝ ≐ ≃ ≈ ⊕ ⊗ ⇐ ⇔ ⇒ ∞ ← ↔ → ≪ ≫ ∝ √ ∤ ≀ ◅ ▻ ⋉ ⋊ ⋈ ∴ ∵ ↦ ¬ ∧ ∨ ⊻ ∀ ∃ ∈ ∉ ∋ ⊆ ⊈ ⊊ ⊂ ⊄ ⊇ ⊉ ⊋ ⊃ ⊅ ∪ ∩ ∑ ∏ ∐ ′ ∫ ∬ ∭ ∮ ∇ ∂ ∆ ∅ ℂ ℍ ℕ ℙ ℚ ℝ ℤ ℵ ⌊ ⌋ ⌈ ⌉ ⊤ ⊥ ⊢ ⊣ ⊧ □ ∠ 〈 〉 <sup>a</sup>⁄<sub>b</sub> &nbsp; &minus; <math>+</math> {\{math|+}}'

As to creating a sandbox page, I'd forgotten that javascript here is not customisable per-page. The main javascript could detect the sandbox page and branch to include the sandbox code instead if the page title matches, but it doesn't seem right to complicate the live code with sandbox branching. Editors could customise their own javascript and, though it would be a bit fiddly, it would be easy to leave instructions on such a page for anyone interested. Maybe that's worth pursuing.

— Richardguk (talk) 11:31, 7 March 2010 (UTC)

Added and looking good. The only further point I would make is that the a⁄b is quite long, and it would be good to have that in the code but to only display a⁄b (or ^a⁄_b), if that is possible. — Martin (MSGJ · talk) 18:31, 7 March 2010 (UTC)

It is possible to make it much more compact: replace it with template:frac, i.e. with {\{frac|+||}}. That's the most general version with the insertion point at the first point anything is added, so editors can type what they need then delete any surplus lines. It's arguably nicer to use, and as a template is more future-proof. The line becomes:

     'Math and logic': '− × ÷ ⋅ ° ∗ ∘ ± ∓ ≤ ≥ ≠ ≡ ≅ ≜ ≝ ≐ ≃ ≈ ⊕ ⊗ ⇐ ⇔ ⇒ ∞ ← ↔ → ≪ ≫ ∝ √ ∤ ≀ ◅ ▻ ⋉ ⋊ ⋈ ∴ ∵ ↦ ¬ ∧ ∨ ⊻ ∀ ∃ ∈ ∉ ∋ ⊆ ⊈ ⊊ ⊂ ⊄ ⊇ ⊉ ⊋ ⊃ ⊅ ∪ ∩ ∑ ∏ ∐ ′ ∫ ∬ ∭ ∮ ∇ ∂ ∆ ∅ ℂ ℍ ℕ ℙ ℚ ℝ ℤ ℵ ⌊ ⌋ ⌈ ⌉ ⊤ ⊥ ⊢ ⊣ ⊧ □ ∠ 〈 〉 {\{frac|+||}} &nbsp; &minus; <math>+</math> {\{math|+}}'

--JohnBlackburne^words_deeds 18:59, 7 March 2010 (UTC)

Sounds good. Let's wait for comment from Richardguk or others? — Martin (MSGJ · talk) 19:01, 7 March 2010 (UTC)

Looks OK to me. Two comments regarding {{frac}}:

From the documentation (which is out of date since  was abandoned), parameters 2 and 3 are optional, so maybe {\{frac|+|}} or {\{frac|+}} would be more appropriate; either way, some editors will fail to guess the exact syntax; but I can see that the proposed form has merits in being the most complete.
From the talk page, there have been some long-standing objections to various aspects of the output that {{frac}} produces (use of display:none for an invisible separator with mixed numbers as a+b⁄c; enlarging the fraction slash as <big>⁄</big>; possible line-height issues). Though the comments are from some time ago, it's not clear to me that they have been addressed. Is the template widely accepted in use?

But these are only points of caution; there's no conclusive reason not to go with the latest form proposed above, unless anyone feels these points deserve further comment.

— Richardguk (talk) 22:39, 7 March 2010 (UTC)

I suspect it's not as widely known as it could be, but anyone not familiar with it will I think look at the documentation, as I did when I first encountered it, or work it out from examples. As for usage it's used in at least 10,000 articles (20 × 500 'what links here'). A lot of infoboxes, some with heights which use conversion templates which use it.--JohnBlackburne^words_deeds 22:54, 7 March 2010 (UTC)

I have now implemented this. — Martin (MSGJ · talk) 14:45, 9 March 2010 (UTC)

For reference, it's quite simple to make your own sandbox edittools. If you put this code into your monobook.js:

if ( ( wgAction == 'edit' || wgAction == 'submit' /*previewing*/ ) && wgPageName == 'Sandbox Test Page' ) {
   window.noDefaultEdittools = true;
   hookEvent ('load', function () { importScript('SandboxEditToolsJavascriptPageOfYourChoice.js') });
}

then you will load that JavaScript page (which you can copy from MediaWiki:Edittools.js and edit as you wish) instead of the standard edit tools whenever you edit the set page. Ale_Jrb^talk 22:56, 7 March 2010 (UTC)

Thanks I will try this next time. — Martin (MSGJ · talk) 14:45, 9 March 2010 (UTC)

Proper sandboxing

Following the above discussion about the advantages (and complication) of having a separate sandbox page to test script changes, User USERNAME:Monobook.js has been suggested as a way to include a test script. But this would require editors individually to create or mess with javascript in their userspace, which would be intimidating for casual and technophobic editors who might reasonably want to comment on proposed changes.

Would the new withJS URL parameter (recently added to Common.js) be a more appropriate way to activate an alternate script?

Not sure exactly how withJS is intended to work, but I think it would allow us to link, say, from this page to any sandbox page appending &withJS=MediaWiki:Edittools/sandbox.js or similar (assuming that the imported code can be written not to conflict with the code already loaded from Edittools.js).

Something like this: http://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit&withJS=MediaWiki:Edittools/sandbox.js

Of course an admin would need to create and update MediaWiki:Edittools/sandbox.js but if withJS works how I think it works, maybe this would be the best way forward.

— Richardguk (talk) 23:23, 12 March 2010 (UTC)

Full IPA coverage

Could we add full IPA coverage? I use that menu a lot, and it's quite annoying to have to constantly clip and paste symbols from the IPA article. Tone, for example, is completely missing, so there is no support for most East Asian languages. Plus there's no need for letters like "a" and "k" in the IPA menu. Wiktionary is better, though still a bit redundant (letter-diacritic combinations, maybe not a bad thing) and not very complete (most diacritics still missing). Buttons as on Commons might make the diacritics easier to enter, as they can be hard to select by themselves.

Also, the labels Wiktionary has in their Latin section are useful. A lot of people mix up haceks and breves, for example, because they can't tell the difference by the display of their screen font. kwami (talk) 06:06, 11 June 2009 (UTC)

I agree that Wikt's organization is a bit better than ours, though I'd really like to have a chart-like representation on a submenu. Sometimes you want to find your consonant by place of articulation rather than manner, or sometimes it's easier to remember a symbol's position relative to other symbols as represented on the IPA chart. But, in general, I agree with Kwami; adding the missing diacritics would be awesome. —/Mendaliv/^2¢/_Δ's/ 15:07, 11 June 2009 (UTC)

A chart would be cool, but if it means that we have to scroll the window up and down each time we select a letter, in might be more a pain than it's worth. kwami (talk) 00:21, 16 June 2009 (UTC)

Unrelease

I can't get IPA ̚ to work properly. I hate to keep editing this over and over.

Can we give sub-section guides? Like "tone" etc. within the IPA section?

Also, can we enter characters through &#x...; that WP won't allow us to copy & paste? On preview, it looks as though we'll get the coding rather than the character. (I'm thinking of angle brackets, which WP subs with CJK characters.) kwami (talk) 10:19, 24 November 2009 (UTC)

Since no one else has answered, then I guess it is the same for the rest as it is for me: Sorry, I don't understand what you are talking about, but I don't use and can't even see the IPA symbols on my computer, so it's probably not your fault that what you said is unclear to me. But, if you tell us exactly what you want us to change or add, then we might add that. At least to the javascript version of these edittools, since there we don't have a lack of space. So, could you explain more and give the exact characters you want added?

--David Göthberg (talk) 16:42, 8 December 2009 (UTC)

To clarify the first point: the diacritic ̚ does not work in the javascript version of edittools. It shows up in the list (... ʰ ʱ ʷ ʲ ˠ ˤ ˀ ᵊ k ̚ ⁿ ˡ ...), but it is not clickable, and clicking on the base letter "k" just inserts "k" (which is not particularly useful). There's nothing obviously different about it, other diacritics work fine using the same coding, it's positively weird. — Emil J. 17:45, 25 January 2010 (UTC)

I've just had a look at it in Safari's (version 4.0.4, OS X 10.6) Web Inspector (right-click and "Inspect Element" over something - you may need to enable the Developer menu). It's useful as it shows the source (JS which all looks valid) but also highlights each entity as you select the block or line of HTML source that is associated with it. And at any font size (up to the 2x or 3x as big that Safari goes) that character has zero width, so cannot be clicked on. It looks the same in the source, i.e. it has no width in the JavaScript. As Safari uses the same rendering engine as number of browsers it probably looks the same in others too, though I've not tested it.--JohnBlackburne^words_deeds 18:01, 26 January 2010 (UTC)

The character by itself has zero width because it is a diacritic (combining character in Unicode terminology). It is not expected to make a clickable entry in the list by itself, but that the combination k̚ will make a single link which inserts both the base character and the diacritic. There are several similar combinations in the list (t̪ d̪ s̺ s̻ θ̼ s̬ n̥ ŋ̊ a̤ a̰ β̞ ...) which work this way without any problems. — Emil J. 18:15, 26 January 2010 (UTC)

Ah, then it is not working properly. In the JavaScript and as you select lines of JavaScript as an entity it is entirely separate from the 'k', which appears on the line of code above. As you select it, which you can only do in the JavaScript, it highlights a zero-width region just to the right of its symbol. Even with that hint though, and with the page zoomed so everything is 2 or 3 x bigger, it's impossible to click on. The others that you list all appear as combinations in the JS. See the screenshot where I've selected the line immediately above the 'k'.--JohnBlackburne^words_deeds 18:27, 26 January 2010 (UTC)

I had a look at the logic used by the JavaScript to parse the insert strings (createTokens()). If I understand it correctly, multicharacter sequences like "k̚" are only recognized when surrounded by spaces, so this may be the root of the problem. Please, can someone try to replace the substring "ᵊk̚ⁿˡ" in the IPA section of charinsert with "ᵊⁿˡ k̚"? — Emil J. 13:20, 27 January 2010 (UTC)

{{editprotected}} As above - looking at the history spaces were inserted on 24 Nov but the k̚ was added immediately after so was not fixed, and also needs spaces around it.--JohnBlackburne^words_deeds 16:34, 27 January 2010 (UTC)

Seems to be fixed. k̚k̚k̚k̚k̚ — Martin (MSGJ · talk) 18:29, 27 January 2010 (UTC)

Great, thanks. — Emil J. 18:55, 27 January 2010 (UTC)

Arrangement of Latin characters below edit window

At 05:53, 13 January 2010 (UTC), I presented at Wikipedia talk:Manual of Style the following arrangement for Latin characters below the edit window. By using both dimensions, we can accommodate both orders (alphabetical order and type-of-diacritic order). Please see the preceding discussion at Wikipedia talk:Manual of Style#Ordering the Latin symbols at Edittools.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Á   Ć   É       Í     Ĺ   Ń Ó     Ŕ Ś   Ú       Ý Ź
À       È       Ì           Ò           Ù
Â   Ĉ   Ê   Ĝ Ĥ Î Ĵ         Ô       Ŝ   Û   Ŵ   Ŷ
Ä       Ë       Ï           Ö           Ü       Ÿ
Ã       Ẽ       Ĩ         Ñ Õ           Ũ       Ỹ
    Ç       Ģ       Ķ Ļ   Ņ       Ŗ Ş Ţ 
                                        Ů
Ǎ   Č Ď Ě       Ǐ     Ľ   Ň Ǒ     Ř Š Ť Ǔ         Ž
Ā       Ē       Ī           Ō           Ū       Ȳ
Ă       Ĕ   Ğ   Ĭ           Ŏ           Ŭ
    Ċ   Ė   Ġ   İ                                 Ż
Ą       Ę       Į           Ǫ           Ų
      Ḍ       Ḥ       Ḷ Ṃ Ṇ       Ṛ Ṣ Ṭ 
a b c d e f g h i j k l m n o p q r s t u v w x y z
á   ć   é       í     ĺ   ń ó     ŕ ś   ú       ý ź
à       è       ì           ò           ù
â   ĉ   ê   ĝ ĥ î ĵ         ô       ŝ   û   ŵ   ŷ
ä       ë       ï           ö           ü       ÿ
ã       ẽ       ĩ         ñ õ           ũ       ỹ
    ç       ģ       ķ ļ   ņ       ŗ ş ţ
                                        ů
ǎ   č ď ě       ǐ     ľ   ň ǒ     ř š ť ǔ         ž
ā       ē       ī           ō           ū       ȳ
ă       ĕ   ğ   ĭ           ŏ           ŭ
    ċ   ė   ġ   ı                                 ż
ą       ę       į           ǫ           ų
      ḍ       ḥ       ḷ ṃ ṇ       ṛ ṣ ṭ

-- Wavelength (talk) 16:00, 13 January 2010 (UTC)

Since no one has taken up the discussion that Wavelength refers to, at WT:MOS, I am starting a new section here. The discussion belongs naturally here, anyway.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 01:17, 18 January 2010 (UTC)

Rational and friendly ordering for the Latin characters

{{editprotected}}

[Updated and rewritten.–_⊥^{¡ɐɔıʇǝo}Noetica!^T–]

At present, searching though the Latin list for a target character is needlessly difficult. Not all orderings are equally rational, or equally adapted for use by real human editors (for whom these lists exist).

Wavelength has usefully shown (see preceding section) the interaction of two categorical variables: base letter (upon which almost universally accepted alphabetical ordering can be imposed) and type of diacritic (for which no widely accepted ordering applies). The edittools are not organised to implement such a two-dimensional array, though. The best we could have is a sub-sequence of all A-forms, then of all a-forms, then all B-forms, b-forms, C-forms, .... Within each sub-sequence there could be uniform ordering by type of diacritic.

Here is the arrangement I propose:

A Á À Â Ä Ǎ Ă Ā Ã Å Ą Æ Ǣ a á à â ä ǎ ă ā ã å ą æ ǣ B b C Ć Ċ Ĉ Č Ç c ć ċ ĉ č ç D Ď Đ Ḍ Ð d ď đ ḍ ð E É È Ė Ê Ë Ě Ĕ Ē Ẽ Ę Ə e é è ė ê ë ě ĕ ē ẽ ę ə F f G Ġ Ĝ Ğ Ģ g ġ ĝ ğ ģ H Ĥ Ħ Ḥ h ĥ ħ ḥ I Í İ Ì Î Ï Ǐ Ĭ Ī Ĩ Į i í ı ì î ï ǐ ĭ ī ĩ į J Ĵ j ĵ K Ķ k ķ L Ĺ Ŀ Ľ Ļ Ł Ḷ Ḹ ḹ l ĺ ŀ ľ ļ ł Ḷ Ḹ ḹ M Ṃ m ṃ N Ń Ň Ñ Ņ Ṇ n ń ň ñ ņ ṇ O Ó Ò Ô Ö Ǒ Ŏ Ō Õ Ǫ Ő Ø Œ o ó ò ô ö ǒ ŏ ō õ ǫ ő ø œ P p Q q R Ŕ Ř Ŗ Ṛ Ṝ r ŕ ř ŗ ṛ ṝ S Ś Ŝ Š Ş Ṣ ß s ś ŝ š ş ṣ ß T Ť Ţ Ṭ Þ t ť ţ ṭ þ U Ú Ù Û Ü Ǔ Ŭ Ū Ũ Ů Ų Ű Ǘ Ǜ Ǚ Ǖ u ú ù û ü ǔ ŭ ū ũ ů ų ű ǘ ǜ ǚ ǖ V v W Ŵ w ŵ X x Y Ý Ŷ Ÿ Ỹ Ȳ y ý ŷ ÿ ỹ ȳ Z Ź Ż Ž z ź ż ž ß Ð ð Þ þ Ə ə

I now formally request that the Latin characters be reordered in this way, to be friendly to all editors.

This would be far more usable: anyone looking for some variant of E, for example, can see immediately where it will be found. We readily spot a cluster of variants of E or e, but not a cluster of characters with an acute, say; or with the accustomed dot missing, as happens with ı.

Note:

Characters without diacritics or modifications (A a, B b, ...) are included, as points of reference when one scans through the list alphabetically.
Some characters may appear more than once, because they are rendered the same in lower case and upper case (no harm in that duplication).
Some characters intentionally appear twice: ß Ð ð Þ þ Ə ə. They appear once in the strict sequence, and again at the end. (There may be no certain base character, or an editor may not know it; once more, a gain in utility, and no loss.)
I have added some characters that do not appear in the original sequence (upper case was present, but not lower case). More could be added, of course.
Although I have taken great care, the sequence may need checking.

A challenge:

Try to find these characters in the list I propose, then in the list as it appears at present:

ł ṛ ą ì ī į, ı

I believe almost everyone will find this new ordering more usable.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 07:28, 19 January 2010 (UTC)

This is soooo much better. Can it be implemented soon, please? Tony (talk) 10:02, 19 January 2010 (UTC)

Yes, please. — Cheers, JackLee ^–talk– 10:12, 19 January 2010 (UTC)

You don't want any separation in there ? It's a rather large string like this. Also I point out that we cannot influence what the usability team does on this, with the new WikiEditor. I suggest filing a bugreport on bugzilla to make sure the upcoming wiki editor is equally complete. —TheDJ (talk • contribs) 13:56, 19 January 2010 (UTC)

DJ, I propose an arrangement (a grouping and an ordering; observe the spacing). But I do not fully understand or specify the technical implementation. I made a single string, just to display that arrangement.

Visitors to this talkpage will make requests without knowing how to implement them. That is not our role: we are not permitted to edit the edittools. I, and those who endorse this proposed change, would like those who have the technical knowledge, and the power, to fix all that. Please do!

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 21:40, 19 January 2010 (UTC)

What does that have to do with it ? I just couldn't see the difference between your thinspace and your emspace at this fontsize. —TheDJ (talk • contribs) 23:51, 19 January 2010 (UTC)

Doing... — Martin (MSGJ · talk) 22:30, 19 January 2010 (UTC)

Hmm, having a few problems. For some reason there are no spaces between the characters and you cannot select them individually. — Martin (MSGJ · talk) 22:51, 19 January 2010 (UTC)

Update: it's still not working properly and I can't see why. I've asked someone for help on this, but otherwise it will need to be reverted. — Martin (MSGJ · talk) 23:03, 19 January 2010 (UTC)

A million thanks, MSGJ.–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 22:46, 19 January 2010 (UTC)

MSGJ asked me to take a look. I think I have found the culprit. I will do some live testing, brace yourselves.

--David Göthberg (talk) 23:35, 19 January 2010 (UTC)

You'd have to leave out the ASCII chars for it to work as before, or the javascript needs to be changed to recognize the new tokens. Logic that is responsible for inserting the javascript links is:

	else if (token.length > 2 && token.charCodeAt(0) > 127) //a string of insertable characters
	   for (var j=0; j < token.length; j++) addLink(token.charAt(j), '');

Since i.e. the new token "AÁÀÂÄǍĂĀÃÅĄÆǢaáàâäǎăāãåąæǣ" starts with the ASCII "A" which has a charCode of less than 128, the branch isn't executed anymore, and a token with the whole substring is inserted. Amalthea 23:44, 19 January 2010 (UTC)

Ah, I just wanted to insert spaces to split of the ASCII chars, but David has already done so. :) Amalthea 23:46, 19 January 2010 (UTC)

Done - I have now fully deployed the fixed version, so all browsers should see the new version immediately.

And here's my explanation how to handle character groups in that code:

Groups of characters are only split up if beginning with a character code > 127 and not ending with a colon ":", else we need to manually add spaces.

But that code is scary, I don't fully understand it.

--David Göthberg (talk) 00:16, 20 January 2010 (UTC)

Thank you, all who have enabled the new arrangement of Latin characters. -- Wavelength (talk) 16:01, 22 January 2010 (UTC)

Note the subsequent objection by User:Parsecboy at #Accent versus alphabetical ordering below. For consistency, please reply in that sub-section, not here. — Richardguk (talk) 01:03, 4 March 2010 (UTC)

Please do not copy and paste from copyrighted websites

The 'Please do not copy and paste from copyrighted websites' content is bogus. So is the 'only public domain resources can be copied without permission' content.

The latter phrase is technically true in a sense, but is highly misleading. Free content licenses provide the necessary permission allowing licensed content to be copied, but the whole sentence indicates that only public domain content is allowed, and that's far from true. The former phrase is simply providing false guidance. It's often perfectly fine to copy and paste content from copyrighted websites. (Consider free content sites such as congresspedia (AKA OpenCongress Wiki); the content is not in the public domain, but is Wikipedia-compatible).

The improper instruction of the first half of the sentence, "Please do not copy and paste from copyrighted websites" is not rectified by the second half. The sentence is sufficiently badly worded that I think we need to tackle improving it. I don't think the linked content does or could address the problems of the sentence. I know we have to keep things simple. But "Use few." is not a useful sentence, unlike "Use fewer words."--Elvey (talk) 11:11, 19 January 2010 (UTC)

I don't have a specific proposal yet. Here are a few ideas:

1) Please do not copy and paste from copyrighted websites without permission. Only public domain content is allowed, with a few specific narrow exceptions for Wikipedia-compatible content that only experienced editors should attempt to invoke.

2) Please do not copy and paste from copyrighted websites without permission. Only experienced editors familiar with the exceptions for Wikipedia-compatible license content should add anything other than their own original writing.

3) ~~Please do not copy and paste from copyrighted websites without permission. Only experienced editors familiar with the detailed Wikipedia license rules may violate this rule.~~

Oh, and a heads up: The "When you click Save, your changes will immediately become visible to everyone" text will not be true once the flagged protection level testing begins. (WP:FPPR)--Elvey (talk) 11:11, 19 January 2010 (UTC)

I agree, the current sentences are not entirely true and needs fixing. The wording is the hard part. Here's a tweaked and shortened version of your example 1 above:

1 b: Please do not copy and paste from copyrighted websites without permission. Only public domain content is allowed, with a few narrow exceptions for Wikipedia-compatible licensed content.

Although I like the stuff about "experienced editors" and "original writing", so here is a tweaked version of your example 2 above:

2 b: Please do not copy and paste from copyrighted websites without permission. Only experienced editors familiar with the exceptions for Wikipedia-compatible licensed content should add anything other than their own original writing.

I couldn't make your third example above sound right, I don't like the wording "violote". But I like that it is short.

--David Göthberg (talk) 12:00, 19 January 2010 (UTC)

Reference to "experience" is inappropriate and liable to offend new editors (who cannot help being inexperienced but who may be more knowledgeable of copyright licensing than some "experienced editors").

If the situation is complicated, then it is fair to allude to that fact, alongside a link to assist those interested in learning more.

But if the wording is changed to become more accurate but less comprehensible, there is a danger of it being more often ignored. Many well-intentioned editors will not digest legalese, or warnings of more than one line.

— Richardguk (talk) 19:01, 19 January 2010 (UTC)

Which wording do you think is best? The current one? I think removing 'experienced' is fine. Short is good; I worked hard on that. From http://thesaurus.reference.com/browse/violate , I like 'breach'.

3c) ~~Please do not copy and paste from copyrighted websites without permission. Only editors familiar with the detailed Wikipedia license rules may break/violate this simple rule.~~ (There would be no violation; editors would be relying on the 'without permission' clause.)

4c) Please do not copy and paste from copyrighted websites without permission. Only editors familiar with the detailed Wikipedia license policies should ever copy text.

5c) Please do not copy and paste from websites without approval. Only editors familiar with the detailed Wikipedia copyright policies should ever copy text.

6c) Please do not copy and paste from websites without approval. Only editors familiar with approved Wikipedia copyright rules should ever copy text.

7c) Please do not copy and paste from websites without license. Only editors familiar with Wikipedia copyright licensing should ever copy text. (Shorter, but I prefer 6c.)

8c) Please do not copy and paste from websites without license. Only editors familiar with copyright license policy should ever copy text. (Also shorter, but I prefer 6c.)

9c) Please do not copy and paste from websites without permission. Only editors familiar with Wikipedia copyright permission details should ever copy text.

Are we there with 6c? I think it's short, simple, true, and clear. I think it has the right tone. 'Wikipedia copyright rules' would link to 'em. (Would link to WP:Copyrights#Using_copyrighted_work_from_others ~~(or perhaps to the whole page - WP:C, or to [2])~~).--Elvey (talk) 21:27, 29 January 2010 (UTC)

I like the first link. It's a shame the section doesn't have a page of its own but we can easily create a quick anchorlink, maybe WP:COPYUSE → Wikipedia:Copyrights#Using copyrighted work from others (in case the section gets renamed).

The word "familiar" perhaps isn't quite right – it's not necessary to be (very) familiar if one has established the position in the particular case; and it's not enough to be familiar if one still fails to understand or apply the rules! Might still put off new editors.

Let's compare the marked-up possibilities. The text currently in use:

Please do not copy and paste from copyrighted websites – only public domain resources can be copied without permission.

Your version 6c:

Please do not copy and paste from websites without approval. Only editors familiar with approved Wikipedia copyright rules should ever copy text.

How about the following?

Do not copy and paste from other websites unless permitted by Wikipedia copyright policy.

Advantages: brief, comprehensive. I think "Please" is unnecessary when warning people not to break the law. Disadvantages: unspecific, no reference to copy-pasting from sources other than websites, no explanation of public domain and other exemptions. But anyone relying on public domain exemptions can reasonably be expected to have enough diligence to check the detailed rules.

For the sake of brevity, the text is deliberately ambiguous about who must have "permitted". This is intended to combine the notion of the source site permitting copying and the notion of Wikipedia policy permitting pasting.

I've changed "copyrighted websites" to "other webites" because casual users may not know that most (or all) websites have copyrights, so it is safer and simpler to cover everywhere – except Wikipedia itself. Or are there some common exempt websites from which such a simple notice might deter casual editors from copying?

The important thing here is to firmly deter potential abusers, briefly guide casual users, and usefully steer diligent users.

— Richardguk (talk) 12:22, 30 January 2010 (UTC)