Wikipedia talk:Manual of Style

See also
Wikipedia talk:Writing better articles
Wikipedia talk:Article titles
Wikipedia talk:Quotations
Wikipedia talk:Manual of Style (dates and numbers)
Wikipedia talk:Manual of Style/quotation and punctuation

Hard-space proposal: invitation to comment

A completed draft

The working group on hard-space markup has completed a detailed proposal. Click "show" to see it:

We took the discussion elsewhere so we could work on the proposal without cluttering this page, and to keep things self-contained. But we now present our work for your comments and assistance, right here at WT:MOS. This is not a call for a vote, or for formal expressions of support or opposition.

Any thoughts on the proposal as it now stands?

– Noetica^♬♩ Talk 03:24, 21 January 2008 (UTC)

The use of ,, as a substitute for &nbsp; seems odd, and exactly counter to your examples of ''...'' for <i>...</i> and '''...''' for <b>...</b>. The more wiki-like technique would be something like ,,...,, (e.g., ,,17 sq ft,,) to turn all spaces within the markup into hard spaces. RossPatterson (talk) 05:27, 21 January 2008 (UTC)

Thanks, Ross. Yes, it isn't wiki-like if we assume that wiki markup must affect a whole block of text, rather than standing for a single entity. But single insertions of the entity   are what we need most pressingly.

– Noetica^♬♩ Talk 05:46, 21 January 2008 (UTC)

I think it would be better to devote improvement efforts to making the Wikipedia editor show Unicode hard spaces distinctively, and making them easy to insert. This would not only solve the problem of new text, but also allow editors to work effectively with articles that already contain Unicode hard spaces, or to work effectively with passages that are copied from other sources which already contain hard spaces. --Gerry Ashton (talk) 06:32, 21 January 2008 (UTC)

Nobody seems to have noted this comment, but I strongly agree with it. Rather than introduce new Wikicode markup, it would be vastly superior to just adjust the editor to display hard spacing in some distinctive way within the editor window, and to add a button to create a hard space. If the distinctive appearance of the hard spaces is well designed, this will be superior in readability to any wikicode markup, and easy to use.--Srleffler (talk) 16:30, 11 March 2008 (UTC)

The current proposal tends toward that sort of clear visibility, doesn't it? What will ,, mean, if not a hard space? It doesn't mean anything else at present. We never see it! If we didn't already have '', that markup would look just as suspect and counterintuitive. But we recognise it, insert it, and edit it very naturally. I'm interested in your mention of "articles that already contain Unicode hard spaces". Are there many of those, in fact? It's hard to research such a thing. In any case, if ,, were adopted surely bots could be deployed to convert both existing Unicode hard spaces and occurrences of &nbsp;. Soon all hard spaces would be very visible, and all would have the same appearance to editors. Thanks for your comment.

– Noetica^♬♩ Talk 07:01, 21 January 2008 (UTC)

Basically, Mr Patterson's proposal is reminiscent of the nowrap template, the deficiencies of which have already been indicated; the double double-commas idea, though less intrusive, would still present problems, including greater confusion in reading it and more mistakes in applying it correctly. Waltham, The Duke of 10:22, 21 January 2008 (UTC)

That equivalence is hard to understand. After all, there don't appear to be any acknowledged deficiencies of the bold and italic wiki markups after which my suggestion is modeled. If the working group's proposal is to stand on its own, perhaps it should explain why Wikipedia should introduce this new concept of "wiki character entities" before making arguments about which notation to use for it. RossPatterson (talk) 18:43, 21 January 2008 (UTC)

If this is intended for more Mediawiki projects than just English Wikipedia, here is probably not the best place to discuss it, because there may be issues with the proposed markup in other languages, e.g. ,, may look very similar to „, which is used as an opening quotation mark in some languages.

I think the underscore _, maybe doubled __, would be more intuitive, because it already represents (soft) spaces in links. _foo_ or __foo__ is used in some adhoc inline markups for underlining, though, and sometimes for Tex-like subscripts too (CO_2).

If we did character replacement markup, there would be some others I’d like to see: typographic quotation marks ("foo" → “foo”, for English) and apostrophes (foo's → foo’s), dashes (foo -- bar → foo – bar, foo---bar → foo—bar), ellipses (... → …), arrows (-> =>), Tex-inspired diacritics (f"oo or f\"oo → föo), superscripts (m^^2 → m²), fractions (3/4 → ¾, although also an OpenType feature), mathematical symbols (1deg * 2 N*m >= x → 1° × 2 N·m ≥ x) etc.pp. — Christoph Päper (talk) 12:46, 21 January 2008 (UTC)

Crissov's underscore for hard spaces may be a worthwhile idea; but to push for a large number of shortcuts at once is likely to capsize the whole thing. Hard spaces are our major concern, and I hope that we can keep to the original, specific issue here. Of course it needs to be taken elsewhere, but I think the matter has been raised here to generate constructive comments and much-needed support if this important initiative is to succeed. Let's see if we can succeed in this first addition to MediaWiki's code for a long time; with that experience behind us, more may be possible. Tony (talk) 14:05, 21 January 2008 (UTC)

I would love to see those automatic replacements too. The straight ' and " really make my eyes bleed. This could enhance significantly the typography of articles which is sometimes a bit unoptimal let's say. Med (talk) 00:39, 14 February 2008 (UTC)

• I also think underscore would be far more intuitive; though it would clash inside math tags, I'm not sure if that would pose real problems. I'm not convinced ,, is as intuitive as ''; and as for ,,,--, : yuck! Also, the date example in the exposition is infelicitous given MOS:DATE#Autoformatting and linking. jnestorius^(talk) 14:41, 21 January 2008 (UTC)

Several of the above comments start discussing the exact form the new markup should have. May I take that as an approval of the principle of adding some markup symbol(s) for hard to enter special symbols? −Woodstone (talk) 16:14, 21 January 2008 (UTC)

I don't think that's an appropriate argument by extension. There seems to be a significant difference between spaces (hard or otherwise) and everything else. In other words, the English Wikipedia would die if you were forced to type spaces as   (and to read them that way in the editor), but it will probably survive every other character-handling difficulty. RossPatterson (talk) 17:15, 21 January 2008 (UTC)

I think each additional symbol needs to be more intuitive to justify the mental cost of learning it. Far more people are familiar with HTML tags than Wiki markup. Replacing <BR> with markup seems pointless at best; it's mostly easier to read concatenated XML tags than long strings of punctuation symbols, and often easier to read character-entities too. In summary, I would quite like to see -- for en, --- for em, and _ for nbsp, but any more complicated markup, or any extra other replacements, seem unnecessary for the default edit mechanism; though clever mappings and substitutions in whatever layer may be useful options for particular users. jnestorius^(talk) 17:32, 21 January 2008 (UTC)

Many valuable observations! Already our request for comment has paid off.

Waltham is right that Ross's ,,...,, is relevantly like (not equivalent to) {{nowrap}}. I don't know if Ross's suggestion is serious or just illustrative; but let's note in passing that it wouldn't work well. Apart from problems of parsing (surmountable), consider an en dash, with hard space before and normal space after:

,, –,, ; or

,, ,,– .

And if the en dash were done another way (see below for --):

,, --,, .

All silly-looking! But then, consider the current options (setting aside direct use of a Unicode hard space):

 — ;

{{nowrap| –}} .

Does any of us like any of those? Under the current proposal:

,,— .

Stands up rather well, does it not? Then there is one possible extension touched on in the proposal, and mentioned above by jnestorius:

,,,--, .

The status of future extensions has been problematic in the proposal. It is important to address wider implications of ,,; but all we need is to show that more could be done, without attempting immediately to do it. Anyway, surely we can see the virtues of ,,— . If there is any option, current or mooted, to which jnestorius does not say yuck, perhaps it should be this last.

The underscore _ might be more intuitive than ,,, but unlike ,, it has too many existing applications, whether these are deprecated or not. Christoph raises other matters: the curly question of ‘’ and “”, for example. Again, we do need to have an eye to the big picture. Despite earlier exchanges in this forum, I am sympathetic to calls for better typographic substitutions. (Not all available ones: preformed … is inferior to ..., I think.) Regrettably, none of that seems achievable. Faced with this reality, we have attempted to solve a single pressing problem.

Ross makes a useful point by considering an extreme case: "if you were forced to type spaces as &#x20;...". Yes, WP can survive anything short of such absurd inconvenience. But that is no reason to refuse reforms.

Finally, jnestorius comments on intuitiveness. So have we all! But in the end, intuitiveness is not an intuitive matter. There is very little intuitive about ''...'' or '''...''', but they work. So might other markup, given a gentle push forward.

– Noetica^♬♩ Talk 22:26, 21 January 2008 (UTC)

I agree completely with Noetica, and should like to add the following:

• Although the underscore is indeed more intuitive than the double-comma, the latter is, nevertheless, much more intuitive than most other symbols, as it is restricted to the base of the line, much like an underscore; there are no dots or lines hovering above the commas.
• True, more people with Internet experience are more familiar with HTML than with Wiki-markup; however, there are infinitely more people without any experience with markup. This ought to be taken seriously into consideration when judging what would be easier for editors to use.
• The resemblance of the double-comma with a „ might indeed pose a minor problem, yet not nearly as great as one may imagine; the distinction in the edit box is quite clear, and if editors use the preview button (which is, of course, always recommended in every editing manual) they will immediately notice the effects of what they have typed; the position of hard spaces is also rather characteristic and quite different from wherever one might expect to find quotation marks. In my opinion, there is no obstacle here.
• Finally, in respect with the date example, I agree that there is an error there (one which had slipped under my radar until now); there is no practice of hard-spacing a day with a month in a date. However, it is still perfectly valid to use a hard space between the first date and the connecting en-dash.

Waltham, The Duke of 21:09, 22 January 2008 (UTC)

Waltham is right, I think, that the similarity of „ and ,, is a minor concern – compared to the potential for confusion of '' and ", in some contexts of WP work. We have to remind ourselves of the relative frequency of these things. A hard space will be required orders of magnitude more often than „ . In the few articles that use „ an inline note could be supplied at the head, to alert editors if confusion is at all likely.

Minor it may be: but we hadn't noticed it, and it's great to have such a thing pointed out.

[Corrected contribution]– Noetica^♬♩ Talk 01:23, 23 January 2008 (UTC)

Confusion between ,, and „ may be little (here and now), but choosing double comma for the no-break space makes it unavailable for other uses. (Obvious fact, but sometimes worth pointing out.) Such a future use might be entering „, if language-dependent replacement of " would not be implemented, but more ASCII character aliases as envisioned earlier were. — Christoph Päper 09:35, 23 January 2008 (UTC)

Thank you, Christoph. I agree: obvious facts should be on the table for discussion, so they are not neglected in the rush to address every last subtlety. I too had thought about unavailability, though not for „. Any system of coding, from the profligacy of hieroglyphics to the parsimony of binary, involves decisions so that what is important or common is given an easier representation than what is trivial or uncommon. I can't think of a character that needs reformed representation more urgently than the hard space. I know you are a crusader for other characters! I would be too, as I have said above, if Wikipedia were ready for huge changes. I'll just add this: the hard space supports many of those characters that interest you (and me), so that they sit properly with their adjacent text. Hence the privileged treatment some of us have given to the problem of the hard space. The difficulties with {{nowrap}} (see below) are yet more evidence that the whole thing has been neglected and misunderstood for too long – by developers of wiki markup, browsers, and HTML itself.

– Noetica^♬♩ Talk 12:14, 23 January 2008 (UTC)

Amendments to the draft, and problems with {{nowrap}}

I have made amendments to the draft, prompted by two considerations:

• Amendment 1. The date example has been disputed. MOS currently says this: "In compound items in which numerical and non-numerical elements are separated by a space, a non-breaking space (or hard space) is recommended to avoid the displacement of those elements at the end of a line." This is, quite properly, very general. On a reasonable reading it applies to dates (which have numerical and non-numerical elements). But since there are further contested guidelines for dates at WP:MOSNUM it seems better to remove that example from the draft. I have substituted "89 sq in – 3 sq ft". Which may look contrived (it is!) and unlikely (not necesarily); but it illustrates the sort of thing that can arise in real editing.
• Amendment 2. I discovered that the behaviour of {{nowrap}} is not as documented at Template:Nowrap; I have therefore added this text to the draft, at Objection 4: "Currently, {{nowrap}} does not behave as specified in its documentation, since a space at the start or end of the enclosed text is rendered in HTML outside of that text, leading to unexpected breaks." This fact is of some interest for the proposal and the discussion here. See my detailed report and request for amendment at discussion for {{nowrap}}.

– Noetica^♬♩ Talk 00:23, 23 January 2008 (UTC)

A point that I don't believe has been brought up is the handling of this markup within wikilinks. One might want to use a hard space in the name of a linked article, for one of the usual reasons. Could Mediawiki parse [[23,,Skidoo]] to link there without piping it as [[23 Skidoo|23,,Skidoo]]? 'Twould be nice. - JasonAQuest (talk) 19:18, 9 March 2008 (UTC)

This is a highly interesting proposition. Although I cannot think of any titles requiring hard spaces right now, it is reasonable to assume that there are. Pipe-linking is not a problem, of course, but any change that makes editing easier and removes code from the edit window is certainly welcome. If the double comma feature is enacted, I will definitely support such an idea, but I don't think it will be easily integrated into the main proposal. I believe that it will be better treated as... an afterthough. Waltham, The Duke of 02:50, 13 March 2008 (UTC)

Technical report: the nowrap template

As I mentioned above, there has been some action at discussion for {{nowrap}}. Woodstone, a key participant in the hard-space working group, has since joined me in exploring the behaviour of the template, and of the HTML code it generates. Here are our findings, and latest developments in documentation of {{nowrap}}:

• x{{nowrap| TEXT }}y generates this HTML code:

x <span style="white-space:nowrap">TEXT</span> y

This is against expectations, since the spaces are forced outside. This anomaly has now been added to the documentation. We are informed by editor Random832 that it cannot be corrected without radical changes to the parser.

• x<span style="white-space:nowrap"> TEXT </span>y is the expected code for the template to generate. But it too would be inadequate, because both Microsoft IE and Mozilla Firefox still allow a break before and after TEXT with this code.
• x<span style="white-space:nowrap">&nbsp;TEXT&nbsp;</span>y also breaks in IE before TEXT, but not after it. This does not occur in Firefox.
• x&nbsp;<span style="white-space:nowrap"><code>TEXT</span>&nbsp;y, quite remarkably, also breaks before TEXT in IE (but not in Firefox).[Correction: inadvertent <code> tag deleted from the code. See posts below.– Noetica^♬♩ Talk 09:57, 25 January 2008 (UTC)]

Conclusion 1

The template {{nowrap}} is irredeemably quirky, and deficient for some purposes.

We might think it doesn't matter if spaces at the start or end of the included text are allowed to break. What are they doing inside in the first place? But there are situations in which we do want them inside. In fact, such a situation arose in the last few days, here at WT:MOS. That's how I made the lucky discovery that prompted my enquiries.

Conclusion 2

The code  , along with markup that inserts it, is superior to {{nowrap}}.

Conclusion 3

The hard-space markup proposal should be supplemented and strengthened with these further facts.

We can do that some time later, perhaps.

Conclusion 4

Deficiencies in this template, and allegedly in the parser, suggest that template solutions to the hard-space problem generally will not work.

This is interesting, because we examined one such solution. It came second in our poll, in fact. Further research would be useful.

Conclusion 5

WP:MOS should alert editors to these deficiencies in {{nowrap}}.

Anticipating agreement on this obvious point, I'll make an addition right now.

Comments?

– Noetica^♬♩ Talk 09:28, 24 January 2008 (UTC)

Pure shock, sir...

...and, thinking of the increased acceptance of the double-comma solution this would bring about... Glee... (Evil grin) Waltham, The Duke of 15:15, 24 January 2008 (UTC)

I can't agree that case #1 is "against expectations"; Wikipedia's general template markup documentation makes it very clear that whitespace between and around parameters and their values is ignored. I.e. x<span style="white-space:nowrap"> TEXT </span>y is not the expected output, if you absorb the templating system more fully. This has its minor downside, but it is generally pretty helpful for most cases. For example it, it's what lets us do:

{{WPBiography|
|class=Start
|priority=Low
}}

instead of:

{{WPBiography|class=Start|priority=Low}}.

(The readability/usability importance of this may not be clear until one uses a template with 27 parameters...) The principal downside is that occasionally one wishes that the spaces were interpreted as literals, and the workaround for that is to use  .

Your second, "also breaks in IE before TEXT, but not after it", example: Well, what else is new? IE is just known to be severely broken. More than 300 (X)HTML and CSS bugs have been documented in it, and the ver. 7 "upgrade", while yes there were some security improvements, was mostly cosmetic plus addition of widgets (RSS parser, etc.); if you read the MS developer blogs and various other forums, it is clear that MS made a conscious decision to not f'ing bother fixing the CSS and other parsing bugs in the last long-overdue IE development round, despite it being clear that the most-needed IE fixes were precisely the ones they punted on. We (by which I mean web developers generally, not WPians in particular) cannot keep bending over backwards to account for IE's failures to follow the standards forever (and yes the abiguity of that phrase is intentional). If the result for MOS purposes is that some things will wrap in broken browsers, but will behave properly in standards-compliant browsers, then that's just fine. Inveterate, insistent users of IE are already used to having to mentally compensate for their preferred but weird browser's shortcomings, so this will be nothing new for them.

The third case – "quite remarkably, also breaks before TEXT in IE (but not in Firefox)" – is invalid markup, so who knows what would actually happen were it cleaned up. The tag order in that passage is: begin-template code nowiki span code /span /nowiki /code end-template; there is not only a missing /code, there is a span code /span /code overlap. With XHTML that broken, the results cannot possibly be predictable; different browsers have different failure compensation modes.

Hope that helps. — SMcCandlish [talk] [cont] ‹(-¿-)› 03:55, 25 January 2008 (UTC)

If I may "reconclude": Your conclusion 1 and 4 are incorrect with regard to there being something broken with the nowrap template or the template parser, and I remain neutral on conclusion 1's second point that the template may simply be deficient for some purposes (since I can't imagine all possible purposes :-) Conclusion 2: I've been saying that all along. Conclusions 3 and 5: Probably so, though I think these findings and the alleged deficiencies need to be seriously re-examined given what I've said so far. — SMcCandlish [talk] [cont] ‹(-¿-)› 04:01, 25 January 2008 (UTC)

Thanks very much, SMcCandlish. We have needed someone with sufficient knowledge to address template matters. A request at talk for {{nowrap}} was ignored. Some comments and queries for you, though. Your text in italics:

I can't agree that case #1 is "against expectations"; Wikipedia's general template markup documentation makes it very clear that whitespace between and around parameters and their values is ignored. I.e. x<span style="white-space:nowrap"> TEXT </span>y is not the expected output, if you absorb the templating system more fully.

The normal experienced editor's reasonable expectation is that a template will do what its documentation says it will do. This one did not, and that has now been acknowledged and rectified. The documentation for templates and the templating system as a whole is generally poor, and impenetrable to non-geeks. Is this satisfactory, when templates are supposed to be a service to all editors?

[...] The principal downside is that occasionally one wishes that the spaces were interpreted as literals, and the workaround for that is to use  .

Well, yes. And in the present case, which is all about spaces, that should have been accounted for and pointed out. We could ask for greater clarity in the documentation. Question: would it have been possible for {{nowrap}} to use multiple instances of   instead of span tags? If so, could the system be made to pick up a first or a last space and do that with them? After all, it seems to be able to identify them in order to drop them outside the span tags, yes?

Your second, "also breaks in IE before TEXT, but not after it", example: Well, what else is new? IE is just known to be severely broken.

That's certainly true. I wouldn't use IE except to test things. Relevantly for this whole discussion, in IE x – y and x — y will not break after the first  , but will before the second  . And x … y (preformed ellipsis) will not break at all. None of these will break at all in Firefox.

[...] If the result for MOS purposes is that some things will wrap in broken browsers, but will behave properly in standards-compliant browsers, then that's just fine. Inveterate, insistent users of IE are already used to having to mentally compensate for their preferred but weird browser's shortcomings, so this will be nothing new for them.

Perhaps. But we should remember that we write for all browsers, no matter which we use ourselves. Despite IE's serious shortcomings, it does seem to behave better with   (at least breaking after a dash rather than before, as explained) than with {{nowrap}}. We should document this for editors, and take it into account, shouldn't we? To excuse ourselves on the ground that a major browser is a non-compliant "outlaw" seems a bit rash and unrealistic.

The third case "quite remarkably, also breaks before TEXT in IE (but not in Firefox)" – is invalid markup, so who knows what would actually happen were it cleaned up. [...]

So sorry. I input the code wrongly here and at talk for {{nowrap}} (fixed now), with a stray and unmatched CODE tag. The corrected code:

x&nbsp;<span style="white-space:nowrap">TEXT</span>&nbsp;y

Do you acknowledge that this is valid code that might turn up in attempts to circumvent IE's and WP's deficiencies? This code is what I tested, with the result that I report. And it is generated by:

x {{nowrap|TEXT}} y

So I still think there are more deficiencies in WP's existing options for the hard space than are acknowledged or documented. For the non-expert, it takes an extraordinary amount of time, cunning, and effort to hunt these things down. This just reinforces the need for better analysis in the first place: and better documentation, coding, and understanding of what a sound editing system demands. That is not being delivered – certainly not for the hard space, certainly not for most editors. Hence our attempt at reform. So far we have seen many invaluable comments here; but I have to say: I see nothing compelling against the proposed markup with ,,. They would have to be an improvement over the present arrangements, surely?

– Noetica^♬♩ Talk 06:54, 25 January 2008 (UTC)[Amended contribution– Noetica^♬♩ Talk 07:10, 25 January 2008 (UTC)]

Well, if we can't sort this out here or at Template_talk:Nowrap I might make some enquiries at WP:VPT. It's important for us to sort out just what these templates can and can't do. How is it, I ask, that a template can shift spaces but not convert them (to  , say)? Can anyone help with an answer?

– Noetica^♬♩ Talk 05:32, 28 January 2008 (UTC)

This process of development

The process of working on the hard-space proposal has been unusual. We set up a page in userspace (a subpage of my own userpage: User:Noetica/ActionMOSVP). Our experience, I think, has been positive: we were able to educate ourselves and each other, and keep to a system that appears to have been fruitful. We are not closing that page, but transferring discussion to here for now, before making the proposal even more public in the wider WP community.

Any thoughts, positive or negative, on that process? I think it's independently interesting.

– Noetica^♬♩ Talk 03:24, 21 January 2008 (UTC)

Indeed, it is. Ignoring for the moment the possibility of a multitude of unchartered "working groups" and Wikipedia's mixed opinions on experts or expert groups, I like it. But if you expect the proposal to derive some credibility from the group's status, membership, deliberations, etc., it might have been helpful to start with a set of stated goals. The User:Noetica/ActionMOSVP archives imply that the proposal itself is the goal, but given the numerous alternatives considered, I doubt that was the case at the beginning. As things stand right now, I expect you're going to have to recapitulate the private discussions "in public", so it will be interesting to see how the working group members handle the concomittant frustration. But thanks for giving it a try! RossPatterson (talk) 17:32, 21 January 2008 (UTC)

Please see my message in the next section (item #1: idea about project page). Waltham, The Duke of 21:09, 22 January 2008 (UTC)

I think it would have been preferable to conduct the whole process here, with more users, a simpler structure, a lot less text, and a greater level of pro-active presumption with invitations to criticise. In my experience, relatively fast-moving, stratified democracy is the best way to garner expertise and opinion from a wide range of people without losing momentum. It did lose momentum, I'm afraid, and I found the page unnecessarily difficult and time-consuming to negotiate, when all I wanted was to be clearly directed—like a sheep—to the decisions already made, the issues that needed input, and the plans for action. Only early on when we were asked to vote on candidate codes was it easy to see what was going on and to contribute. Even then, it would have been simpler to ask people to list their first, second and third choices in one simple row separated by commas (4, 1, 5) and to sign once than to negotiate the table in the edit-box. Keep it simple and quick is my advice. We still don't know how/where/who further down the line, and it's this lack of a big-picture strategy that put me off. IMV, one-to-one legwork to produce options for where to take the proposal would have made a difference, not open-ended discussion lacking fine-grained goals and interim deadlines.

However, I support the proposal, thank Noetica for taking the initiative, and look forward to progress. Tony (talk) 09:05, 23 January 2008 (UTC)

Thank you, Tony. Interesting and useful to have your views concerning our experiment recorded here. I will not give my detailed response, though there is much to challenge in what I have just read. I'll wait for others to give opinions.

– Noetica^♬♩ Talk 11:50, 23 January 2008 (UTC)

"Recording" my views wasn't uppermost in my mind; just responding to your call for feedback. I didn't see it as combative. Tony (talk) 23:00, 23 January 2008 (UTC)

Combative? I didn't see it that way either. You have indeed responded to my call for feedback, and I have thanked you. But in my assessment you raise some questions on which we disagree, and which it is not profitable to pursue right here, right now. Good to have a range of opinions recorded.

– Noetica^♬♩ Talk 23:28, 23 January 2008 (UTC)

Enough with the "recording" idiocy, both of you; we are not at Abbey Road here. Focus on the subject, please. Waltham, The Duke of 15:18, 24 January 2008 (UTC)

How to promote the proposal

The working group would appreciate your thoughts on how to move forward with the completed proposal. Certainly your interest and help are important, for a start. We had thought Village Pump (proposals) would be a proper place to present it. But that may not be best. It needs a big vote of support, from editors who have studied it and have come to see the need for this simple change.

Suggestions?

– Noetica^♬♩ Talk 03:24, 21 January 2008 (UTC)

In my opinion, this proposal is even more embracing than the rollback tool, for it concerns a markup: it is meant to be used by literally everyone, regardless of status, and as a part of the regular editing process. Therefore, I believe that it ought to receive maximum publicity. These are the steps I think we should take:

1. Create a page in the project namespace, thoroughly explaining the proposal and the procedure by means of which it has emerged. The discussion on the proposal and any potential straw polls will take place there. The page shall, of course, be appropriately tagged; it might also have a shortcut.
2. Leave messages in the Village Pump's Technical, Proposals, and Policies sections, referring to said page.
3. Leave messages in the relevant Manual of Style talk pages: here, in dates and numbers, and in mathematics.
4. Leave a note in the Community Portal's bulletin board calling editors to comment on the proposal.
5. Leave a message in the Administrators' Noticeboard similarly calling sysops to comment.
6. Create an entry in Centralized discussion regarding the proposal.
7. Leave messages in the talk pages of all the relevant WikiProjects (ideas including the League of Copyeditors and the Punctuation and Typo projects).
8. Leave messages in whatever other relevant pages' talk pages we can locate.

I do not find it necessary to ask an administrator to create a watchlist note; we could mention it somewhere, but if the proposal does gather momentum, someone will probably do it on their own accord anyway.

Anything I have left out? All this might sound slightly excessive, but, seriously, we are talking about a major change here; we need all the input we can get. Waltham, The Duke of 21:09, 22 January 2008 (UTC)

Perhaps seeking an article in the Signpost would effectively bring it to the attention of a large number of committed editors. Franamax (talk) 00:19, 23 January 2008 (UTC)

Indeed. However, it will probably be hard to gain more than a mention in the Signpost; a full article will be written if this becomes a story worth including, which will only happen if and when a lot of activity takes place. See what happened with the rollback debate: after the discussion, the poll, and the reactions, and only then, was the story published. Waltham, The Duke of 15:52, 23 January 2008 (UTC)

Now that I think of it, maybe this kind of treatment would be excessive; after all, this is just one of tens of such proposals being made every year (not to say hundreds). However, if we are to discuss it in the Village Pump (instead of creating a separate page in the project namespace), we probably ought to prefer the Technical section, as more relevant. Waltham, The Duke of 22:37, 23 January 2008 (UTC)

My experience of that is that the entry will soon be covered in a swamp of others, possibly without comment. Tony (talk) 22:58, 23 January 2008 (UTC)

Yes, Tony. Being swamped is the problem: just as the developing proposal would have been lost in noise if it had been pursued here, as experience shows for other such efforts.

Waltham, looking at the various pages of Village Pump, I don't think this belongs primarily in the technical area. There are certainly technical implications, but the immediate question is to do with policy: in general, the kinds of markup that WP should embrace, and then the specific suggestion for one change, regardless of the deep technical mechanisms involved.

– Noetica^♬♩ Talk 23:40, 23 January 2008 (UTC)

• No, Noetica, it could have been managed here, and experience has shown that reforms have been worked through successfully here. I'm not interested in the bickering though, so let's concentrate on moving forward the hard-space reform. Tony (talk) 23:59, 23 January 2008 (UTC)

Interesting to see your further opinion recorded, concerning what can and cannot be achieved here (and at WT:MOSNUM, perhaps?). I see no bickering, but sure: let's work on the job in hand.

– Noetica^♬♩ Talk 00:09, 24 January 2008 (UTC)

Hey guys, do I detect an inability to play nice together? Tony, the best way to show you're not interested in bickering is to not bicker, especially in the immediately preceding sentence. Noetica, if you see no bickering present, best not to introduce your own example. Did either of your most recent posts here get us farther toward implementing double-comma? Just asking. :) Franamax (talk) 00:17, 24 January 2008 (UTC)

No, they didn't; Interesting to see your rejoinder recorded here, Noetica. What else are we going to record? Tony (talk) 00:21, 24 January 2008 (UTC)

Tony, you are aware that every time you click "Save page" the text you entered is recorded in perpetuity? That's how wikis work and it's a correct statement, I hope you're not accusing Noetica of making a correct statement. Are you trying to pick a fight? Maybe this isn't the best place to do so. :) Did that last post help with the double-comma proposal? Let's cool down a bit. :) Franamax (talk) 00:34, 24 January 2008 (UTC)

Or are you being combative now, Franamax? I just object to the continual explicit framing of my contributions as recordings, rather than current engagement in discourse. The mild put-down is not helpful, and nor is your "recording". For example, I could frame your entries as "html code", although even that would not carry same negative connotation as "recording". Understand? Tony (talk) 00:54, 24 January 2008 (UTC)

(e/c I think this is the right spot)Umm, I guess the short answer is: no I don't understand :) I'm certainly not trying to be combative, I was actually trying to defuse a potential off-topic fight I saw developing. Obviously I've failed in that effort, but I don't mind failure, in fact I've honed that skill throughout my life. :) I'll include my recent posts in the question "are we advancing the subject of the thread?", the question applies to all of us, and I'll offer apologies if I've offended you. Franamax (talk) 01:21, 24 January 2008 (UTC)

For the record, I say (and said) that it is a Good Thing to put useful and relevant opinions on record. We are all doing that. I asked for that, more or less. Tony, you think it is a put-down to label a contribution as an act of recording? I didn't see it that way. Sorry if you were offended. I simply wanted to record that I disgree with you on some matters, and also that I don't want to engage with you about those, at this stage.

– Noetica^♬♩ Talk 01:07, 24 January 2008 (UTC)

For the record, I should like to add that you are all being ridiculous, and amusingly so, too. (chuckles) Seriously, can we go back on-topic, please? I fail to locate the reason for this distasteful digression.

Now, do we, or do we not, agree that this page is suitable enough to serve as the main forum of discussion for the hard space proposal? Please answer this question, and no other. Believe me, it is for the best. Waltham, The Duke of 15:06, 24 January 2008 (UTC)

I don't find it amusing. I hope that, having insulted each other, Noetica and I can very soon move on and resume our very productive friendship. Tony (talk) 10:23, 26 January 2008 (UTC)

{{nowrap}}, {{nowraplinks}} and {{nowrap begin}}

As a webmaster and Wikipedia editor I have worked a lot with line breaking issues. In the end I created {{nowraplinks}} and {{nowrap begin}} and their helper templates to solve/handle the problems with {{nowrap}}. (I just wanted to mention those since most of you don't seem to be aware of them.)

I took a look at the suggestion above to use the wikimarkup 34,,kg to mean 34 kg and it seems to me it is a good suggestion. Although as others have pointed out it has to be discussed with the other language wikipedias too of course, especially those languages that use the low double quotation mark: „Quoted text“

Of course what really is needed is that the World Wide Web Consortium (W3C) finally accept and standardise the old well working and easy to use HTML markup <nobr> + + </nobr>.

--David Göthberg (talk) 10:05, 26 February 2008 (UTC)

Thanks for joining the discussion, David. I see that you have also commented at Template_talk:Nowrap. As you can see, the discussion has paused for a while. The whole matter of hard spaces has been argued over at length in another context, at WT:MOSNUM. That discussion centred on extent of use rather than means of inputting. Since it grew long and heated, I suggested that the whole thing be put aside for now. But we should resume it soon, in a more integrated form.

I wrote (see above):

Well, if we can't sort this out here or at Template_talk:Nowrap I might make some enquiries at [[WP:VPT]]. It's important for us to sort out just what these templates can and can't do. How is it, I ask, that a template can shift spaces but not convert them (to  , say)? Can anyone help with an answer?

This was about spaces at the start or finish of the string enclosed in a {{nowrap}}. The spaces are dropped outside when the HTML is generated. If that can be done, why can't such a space be converted to a &nbsp;? I'd be grateful if you would answer that!

I note your remarks about reform of HTML itself. But let's not wait for that! As for „ , surely at German Wikipedia for example they don't use two commas to input that character. And ,, and „ are surely no more confusable than '' and " are. We all live with these, all the time.

– Noetica^♬♩ Talk 22:26, 26 February 2008 (UTC)

Well, it is not the {{nowrap}} template itself that move the leading and trailing spaces outside the span-tag it creates. It is the MediaWiki rendering that does it. And from what I read and experienced that is the default behaviour for MediaWiki rendering for all things that internally in MediaWiki rendering uses span tags, such as bold and italics too. I am not sure if that is a good or bad default behaviour for the span-tag rendering for bold and italics, but yes in the nowrap case it seems to be a bad thing. But note if you need more control we now do have the {{nowrap begin}} + {{wrap}} + {{nowrap end}} templates. Simply enclose the whole line of text in {{nowrap begin}} + {{nowrap end}} and then insert {{wrap}} where you want to allow line breaks.

Currently we can not process and convert characters in input to templates, thus converting spaces to   is not possible from just template programming. To make that possible the MediaWiki functions for template programming would have to be extended with a whole new set of string handling functions. Again, it seems to me the situations were you want spaces converted to   is the same situations where I would currently use {{nowrap begin}} + {{wrap}} + {{nowrap begin}}. (Yeah I know that might in some cases look very ugly when we edit the pages, but at least it is clear.) But yes, using ,, for   would in many cases be a much nicer solution and give the editors much more control.

And I more than agree that ,, is a good notation for  , see at least in the three web browsers I have I can see the difference between ,, and „ but I can not see the difference between '' and ".

Also, the ,, notation would make it easier to use hard spaces which probably would make people use them more often, which I think would be a good thing.

By the way, as you already have seen this kind of suggestion causes a lot of discussion and needs a lot of examples and explanations. You already have spread this discussion and examples over many different pages. Therefore I suggest the same as someone suggested above, move all these examples and discussions to a single page + talk page. You can see how we did with for instance the article message boxes standardisation project. We put the examples and draft write ups at Wikipedia:Article message boxes and put all discussions at Wikipedia talk:Article message boxes. Then we advertised that all over Wikipedia. That would also make it easier to get people from other language Wikipedias to join in since we could ask them all to come to that one single place. You kind of started that by using User:Noetica/ActionMOSVP, but if you put it on a more official address instead of in user space it would be more inviting. Come to think of it, even more correct would be to move all this to Wikimedia Meta-Wiki.

So I suggest you move all this to say meta:Wikimarkup for hard spaces and its talk page. And I mean literally move it as in cut and paste all the discussions from the different pages (including this page) to that talk page. And of course put a notice in the old pages: "This discussion has been moved to meta:Talk:Wikimarkup for hard spaces." If you don't want to go as official as using Meta-Wiki then at least move all this to say Wikipedia:Wikimarkup for hard spaces and Wikipedia talk:Wikimarkup for hard spaces.

--David Göthberg (talk) 07:39, 27 February 2008 (UTC)

Thanks for your thoughtful response. I'll think through all that you have said. We will take this up again, and I'll advise you when we do so. I look forward to your continued involvement, and your very useful contributions.

– Noetica^♬♩ Talk 09:35, 27 February 2008 (UTC)

Discussion of markup for hard spaces to continue

There has been a trickle of continued contributions here in recent times, and some heated commentary earlier about whether and when to use hard spaces at all. I myself have been happy to wait for these, and to accumulate all that we can from this exposure of the issue here at WT:MOS. In about ten days I want to open up User:Noetica/ActionMOSVP again, for us to digest some of these suggestions, and so improve our full proposal. All editors will be very welcome to join in, as always. The mood here and at WT:MOSNUM has been difficult lately, so I think we may then need to move this forward at yet another place, as David Göthberg proposes above. As secretary to the group working on this I'll notify everything here.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 22:07, 11 March 2008 (UTC)

With the risk of sounding harsh (but I say this since I like your proposal and want it to succeed): This talk page (Manual of Style) is not really the place to discuss your proposal, among other things since it will get mixed up between many other unrelated discussions. (And it will disturb those other discussions.) And neither is User:Noetica/ActionMOSVP since it is in your user space. So you really should move this proposal discussion to say Wikipedia:Wikimarkup for hard spaces. As long as you don't move it to an official page you are seriously hampering the discussion. Trust me on that. We succeeded with the Wikipedia:Article message boxes and I think that in many senses was a much bigger project/proposal than your "Wikimarkup for hard spaces".

--David Göthberg (talk) 23:37, 11 March 2008 (UTC)

I think Noetica is just trying to be cautious here and not "go public" with a proposal that has easily pokable holes in it. That said, I'm thinking MetaWiki might not be a bad place to go next. (And of course, it's easy enough to make the feature optional for different language wikis). Franamax (talk) 00:10, 12 March 2008 (UTC)

Thank you, Franamax.

And thank you too, David. David, if you had followed all of the dismal history of this matter you might hold back from such a seemingly harsh judgement. Those of us involved in User:Noetica/ActionMOSVP did everything we could here before starting up that page; we sought comments on every move, and reported here zealously. We sought discussion of all available options; and at the time, no one so much as hinted at the move you have since suggested. I myself volunteered my services, with no dissent from my going on to facilitate as I did. Some found the excess of consultation excruciating! And hard work it was for us all.

The result is a thoroughly researched proposal. No one pretends that it is a consensual one; but to get this far we needed to act as we did. For the third or fourth time now, thank you for your very useful input! I look forward to more. We will move things elsewhere, as you have suggested and as I agree we must. Meanwhile, we'll polish the proposal we had developed, and present that to a new forum.

(Call any of that "hampering"? Some of our reflex enemies here will seize on that with glee!)

 

: )

 

I really do look forward to working with you on this. Please let us tidy things at the page I made, and then we can proceed. For reasons to do with The Real World, I have to wait ten days now.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 01:06, 12 March 2008 (UTC)

[Revised above, and re-indented the following after edit conflict.–_⊥^{¡ɐɔıʇǝo}Noetica!^T–]

(Note: this was written before Noetica's reply was posted—check the times.) 01:05, 12 March 2008 (UTC)

Naturally; an entire namespace (Portal) is restricted to the English Wikipedia, surely the same thing can be done for a lousy character.

As far as the venue is concerned, you know that I support the centralised format: one well-advertised page where the proposal can be presented properly and in depth, with a talk page for all the discussion about it. I have no great problem with using Meta space for the proposal, although this will limit participation on the part of the English Wikipedia, which I consider crucial in these early stages. Don't forget that most Wikipedians have no account in Meta (including me). My idea is to use Project namespace, discuss the idea, and if it is approved by the community and the developers, the feature can be activated for us and the proposal moved to Meta, to be taken from there to the other Wikipedias, which will decide individually.

Finally, I don't believe the holes are as pokable as some might think, knowing that we have already submitted the proposal to a fair degree of scrutiny and most counter-arguments have been successfully rebutted. And it's not like we'll go to battle unprepared... Waltham, The Duke of 01:01, 12 March 2008 (UTC)

I started actively editing on Wikipedia in early December, and I saw this new little proposal to figure out new markup for no-break spaces, and I thought, "Neat, what a simple, technical, non-controversial issue, what a perfect little project to start on before I know much about Wikipedia". Ouch!

Our current long-running conversation at WT:Layout on the subject of ordering of end sections may contain some helpful hints on how to make progress with no-break spaces ... I would link it, but it's long and most of it isn't relevant, I'll just copy some of my comments here. My fear about no-break spaces before was that it would turn into a conflict that never got resolved and never went away (and I admit that I got too pushy at various times, trying to avoid that fate), but we have a new weapon: people are getting more serious about Wikipedia 1.0, which will be a (largely) printed version, and people are more sympathetic to look-and-feel issues (possibly including no-break spaces) when we're trying to make a printed encyclopedia look nice. And that might get us past the opposition at Wikia ... we have to look nice on paper, they don't, so as the Duke points out, maybe the techs can apply this markup just to Wikipedia. Anyway, here's my take on a similar issue from WT:Layout, feel free to cherry-pick any of these arguments that might be helpful.

When printed sections of Wikipedia's Version 1.0 come out, Wikipedia will get even more criticism from journalists and publishers who feel that their place in the world is being threatened. TV news and newspapers prefer to criticize style over substance, so the look-and-feel of the printed Wikipedia is likely to be very important to Jimbo and the Foundation ... and it would be a matter of pride even if there were no criticism at all. - Dan

Any disagreement with Rlandmann's suggestion to put a message on the talk page of every wikiproject? (That's a huge number btw, there are for instance around 160 active science and tech wikiprojects and more inactive ones...could a bot do this? Do we want to post the notice other places as well?) - Dan

I may be missing something, but hasn't everyone made their points already? Isn't there consensus to gather information and get on with it? If we put something about "order of end sections" on a bunch of wikiproject talk pages and other places besides, people are going to think the issue is too narrow and accuse us of spam. We can get more done at once, and get a better reception, by giving a link instead of an argument, "Go to X page to give your input...", and making the subject a bit more widely relevant, so first we should invite people to a page to make their case for which other questions are also "printed look-and-feel" issues ... perhaps at Village Pump (misc). - Dan
- Dan Dank55 (talk) 15:59, 12 March 2008 (UTC)

Another bit I'm copying over from WT:Layout: On second thought, it wouldn't hurt to ask first how widely we should ask around! Lots of people have been flamed for being too spammy on the one hand or not notifying a wide enough audience on the other hand, I'll go ask over at WP:VPP what the target audience is, and whether WP:VPM or WP:VPP is better for discussions that are part policy and part not. - Dan Dank55 (talk) 20:15, 12 March 2008 (UTC)

WikiProject Manual of Style

I have promised in a few places to take forward the idea of a WikiProject to coordinate the multiple pages of the Manual of Style and facilitate communication between its editors. I think this is an approach which may work; it is, at the very least, worth trying. For it to be successful, it needs to have its scope clearly defined and to have the support of a wide range of editors involved with Manual of Style issues. Also, although the following is not a requirement for starting a WikiProject, it is common to propose new WikiProjects at Wikipedia:WikiProject Council/Proposals. I think doing that would be helpful in this case, but I also think that first it would be a good idea to have some discussion here. For information, I would also note that suggestions for starting new WikiProjects can be found here and here.

A first thing to agree on is the name of the proposed WikiProject. I was really hoping to think up an excuse for calling the project MoS DEF, but I see that this joke has already been made, so I suggest instead a straightforward title following the heading of this section. I'm not sure about the capitalization, but think it's best to follow the usage here and elsewhere.

As a tentative scope, I suggest something along the lines of "The purpose of this WikiProject is to coordinate the multiple pages which form part of the Wikipedia Manual of Style and to provide a forum for editors interested in the Manual of Style to resolve discrepancies and discuss related issues", but that is just a starting point to stimulate discussion. I have no wish to play a leadership role in the proposed project, but will be happy to facilitate in a Wikignome-like way and would encourage those who like the idea to do the same. In particular, I think it is very important that the project is as inclusive as possible, and is supported by editors with a wide range of views: it shouldn't, in my view, take a stance in the debate between those who want a more prescriptive Manual of Style, and those who want a more flexible one; instead it should provide a neutral forum for discussing such issues as they apply in each particular case. But these are just my thoughts: many other thoughts are needed! Geometry guy 17:50, 17 February 2008 (UTC)

I guess the priority could be discrepancies and those points having been highlighted as most contentious (?) initially. Not a bad idea I guess as issues seem to crop up from time to time. cheers, Casliber (talk · contribs) 19:55, 17 February 2008 (UTC)

No opinion on Project name, but I hope the Project's scope will include discussion of how pages are added to {{style}} and how discrepancies are identified and discussed. SandyGeorgia (Talk) 19:58, 17 February 2008 (UTC)

I supported this above; this should probably be the place where ironing out discrepancies happens. Let's see a draft; it would be nice if it mentioned the princriple on which Jitse settled the AD 1066 matter above: we shouldn't make any rules unless necessary. Septentrionalis PMAnderson 20:08, 17 February 2008 (UTC)

How about "MOS DEFRAG"? Considering all the fragging that arises over this issue, defragging would be a pointer in the right direction. Askari Mark (Talk) —Preceding comment was added at 20:24, 17 February 2008 (UTC)

I'd like to suggest that the WP:UE be the first addressed in regards to article titles since there is an increasing tendency to use languages other then English in titles based on citation of policies by national governments and international organisations, but not taking into account teaching practices of the English-speaking world. It seems to me that an article begins with a title, and as the Lewis Carroll saying goes "Begin at the beginning and go on till you come to the end; then stop." ;O) —Preceding unsigned comment added by Mrg3105 (talk • contribs) 23:59, 17 February 2008 (UTC)

I wouldn't be in favor of the Project addressing any particular guideline first; the initial goals in my mind would be to discuss how pages get listed at {{style}}, discover where inconsistencies and overlap may exist between pages, how to streamline and maintain consistency, etc. I don't think the Project should be set up to "police" a given guideline, or it will certainly fail. (Does anyone remember the Extra-Long Article Committee? That is not what we want and hopefully not a goal.) SandyGeorgia (Talk) 16:03, 18 February 2008 (UTC)

Having a central place where people can nuke it out regarding MOS issues sounds like a good idea. I'm not sure if that would be better accomplished by a WikiProject or a noticeboard (although the difference would be quite arbitrary). As long as there are no self-appointed rulers with veto powers over whether something is changed or added to the MOS, it should be all right. Titoxd^{(?!? - cool stuff)} 09:33, 18 February 2008 (UTC)

I support this move. At the very least, a page where users can point out inconsistencies between the MOS and its sub-pages is required. The project could organise its membership to audit selected sub-pages for inconsistency, overlap, and internal structure (reporting back their findings, and not necessarily taking unilateral action). The project might develop guidelines for how pages might become affiliated with the MOS in the first place. Tony (talk) 14:04, 18 February 2008 (UTC)

Starting with a sound explanation of which there should be any barrier to becoming "affiliated with MOS" in the first place. (Empire-building, of course, is not a sound reason.) Septentrionalis PMAnderson 14:45, 18 February 2008 (UTC)

• I support the move to start a WikiProject to sort out the sprawling and unmanageable hydra that MOS has evolved into. Personally I would like a title with the idea of coordination in it: WP:MOSCOORD or something like that. The terms of reference and the agenda should not be set now, except in the broadest way. There is a great deal that is very general to work out, before we get down to specifics.– Noetica^♬♩ Talk 06:14, 21 February 2008 (UTC)
  • Including coordination in the title is setting the terms of reference. We have discussed the idea of having this talk page coordinate all of MOS, and we disagree over that at least as much as anything else; I would prefer not to begin with the assumption that a new page, about which we know nothing, will do so. Septentrionalis PMAnderson 19:11, 21 February 2008 (UTC)

I apologize for my slowness in following this up, given the general support for the project idea. It seems to me that "WikiProject Manual of Style" is the right title, but several useful shortcuts have been suggested here. I agree with all comments that the mission and/or terms of reference of this WikiProject should not be set in stone. However, we have to start by saying something about why the project is needed and what it will do. Its role will evolve according to perceived needs and benefits. If the project does not have the support of editors of manual of style pages, it will just become a talk shop, so I think we are safely within the grounds of "primum non nocere" here!

I am willing to initiate a proposal/draft taking into account comments made here, but have been distracted by a few other things in the last couple of days. Geometry guy 21:18, 21 February 2008 (UTC)

WikiProject Style would be shorter, and allow us to discuss more than this unfortunate Manual. Phillip Bard Shearer has long since questioned whether calling this a Manual encourages the bullying tone so characteristic of these pages; and this should certainly be one of the things under consideration. Septentrionalis PMAnderson 00:09, 22 February 2008 (UTC)

I've now formally proposed this WikiProject at WP:WikiProject Council/Proposals#Manual of Style and have made a draft project page here. Please feel free to express your views on the draft and tweak it. Please also indicate your interest in the project on the WikiProject Council page, and the draft itself. Thanks, Geometry guy 23:41, 25 February 2008 (UTC)

WP:WikiProject Manual of Style is now up and running, and discussions are beginning at WT:MOSCO on its principles and how it will operate. I encourage editors here to contribute, bearing in mind the coordination issue that the project has been set up to address. Geometry guy 10:17, 28 February 2008 (UTC)

Right-facing images and {{Toc right}}

The current text of MOS includes suggestions to place right-facing portraits on the left, even at the beginning of the article, and suggest using {{Toc right}} if that interferes with "navigation elements". IMO, this is unacceptable. Wikipedia articles aren't stand-alone works, they're a part of a wider work, i.e. the encyclopedia. It is important for all articles to have the same basic visual structure and placement of the TOC. Aesthetics are an entirely secondary concern. Unless somebody provides a good reason for these suggestions to stay in the guideline, I will remove them. Zocky | picture popups 03:22, 23 February 2008 (UTC)

Go ahead, they are taken far too prescriptively. However, I cannot agree that the same placement of the TOC is essential; some articles develop large areas of white space which can most easily be resolved by moving the TOC. Septentrionalis PMAnderson 04:03, 23 February 2008 (UTC)

• (edit conflict) I strongly suggest that this exception remain in the MOS - without the exception, the MOS will dictate that all articles begin with an image on the right. Aesthetic principles dictate that right-facing portraits do not "look off the page" (in this case, the screen) as it leads readers' eyes away from the page. It is a principle followed in the layout of art books which we would do well to follow as well. Aesthetic concerns such as these are important as they keep readers' attention focused on our articles. Such exceptions have already been debated and consensus achieved for FA articles such as Joseph Priestley (both before the FAC and at the FAC), if that is any indication of community support. My personal experience with this issue has been that primary article contributors tend to endorse left-alignment as they are working daily with the article layout and thinking about it while it is gnomes and other editors who make small clean-up changes who endorse right-alignment. Clearly the needs of consistency need to be balanced with those of aesthetics, but I don't think that an image, a lead, and a TOC in various arrangements is so very confusing. It is those three elements that we like to have at the top of all of articles for our readers. Achieving the best balance between those three elements for each article is the goal - sometimes this means restricting the TOC, sometimes this means shifting the image to the left, and sometimes this means granting extra room for the lead. We need to be flexible to allow for each article's individual needs. Awadewit | talk 04:07, 23 February 2008 (UTC)

OK, as far as I can see, we have the following arguments:

The layout should be kept standard

• It makes finding standard pieces of information easier
• It makes it easier for bots to maintain articles and extract information from them

The layout should be customized to the article

• It makes prettier articles
• It can save space
• We shouldn't follow arbitrary rules
• We should follow an arbitrary rule of aesthetics

AFAICS, the reasons for customizing the layout are either subjective (the prettiness), irrelevant (Wikipedia is not paper, and saving space is not essential), or contradictory (we should ignore our arbitrary rule in favor of another (at least as) arbitrary rule, i.e. an "aesthetic principle". Am I missing anything? Zocky | picture popups 04:50, 23 February 2008 (UTC)

I came here via the Jane Austen talk page, so forgive me for intruding. Zocky, I think you're taking Awadewit's fairly valid points and twisting them to fit your own agenda. I do not think that ensuring that an article fulfills clearly established and precedented aesthetic values is merely a matter of making the article "prettier". It's a matter of academia, which is what Wikipedia, as an encyclopedia, should aspire to above all things. All articles are different, not only in quality but in substance, and should be considered on a case by case basis. This is why stringent rules regarding infoboxes and image placement simply cannot apply to each and every article. For examples, articles as broad as Austen's tend to attract crufty infoboxes in which original research by way of synthesis (influences and influenced fields) and other un-encyclopedic entries often find a home. In a well written article all important information will be listed in the lead section; the reader won't even have to scroll.

I agree with the idea that Wikipedia is not paper, but integrity should outweigh conformity. One article is different than the next; all images simply do not belong on the right side and all articles do not necessitate an infobox -- because of these reasons, you will find it highly difficult to reach a consensus on both of these matters. I for one support the optional placement of infoboxes and the choice to put a right-facing image on the left side of the lead. Bots are not readers and are therefore not our priority, readers are capable of reading through an article if they are dying to find important and key facts about a subject, and strict standardization on these issues will never reach a consensus. María (habla conmigo) 05:14, 23 February 2008 (UTC)

First of all, I have no strong feelings on the infobox issue. I can see how it can be useful, and I can see how it can be annoying. But let's not mystify the "aesthetic issue" of the right-facing pictures having to go to the left. It's a more-or-less arbitrary rule intended for paper books. The likelyhood of a reader's eyes being drawn to the right of the article on a computer screen is minimal and in all likelyhood entirely irrelevant for our purposes.

Oh, and a thought about bots: Our mission is to collect and arrange information, so that the free knowledge can be used by people. One way that the people need to use the knowledge is for creating more free knowledge by extracting bits and pieces from hundreds or thousands of articles. Examples include Google Earth layers with markers representing Wikipedia articles, computer-generated lists of people from a certain profession, etc. Enabling these uses is a part of our core mission, and standard layout and infoboxes are among the ways that we accomplish that. The need to have information about Jane Austen included in those computer-generated compilations of knowledge should obviously trump the need to have her portrait face into the article. Zocky | picture popups 05:33, 23 February 2008 (UTC)

As I understand it, bots are not affected by the visuals of the article as they run on the "code". Please explain which bots you think this would affect and how. Usually bots are not affected by such things. If they are, they should be fixed. Awadewit | talk 06:05, 23 February 2008 (UTC)

You achieve the visual changes by changing the code. A bot that extracts information from intros may not be aware that you're using non-standard (for articles) ways of displaying the TOC and may thing that the code for it is a part of the article text. That can be fixed in the bot code, of course, but the more variations, the harder it becomes to do. OTOH, information that could be extracted from a template call (i.e. an infobox) can't be extracted from text by a program at all. Zocky | picture popups 06:09, 23 February 2008 (UTC)

This doesn't really make sense because many articles (such as stubs) don't even have introductions. In fact, the majority of articles are "non-standard". Please give examples of bots that would be affected so we can see the real ramifications of this. Your speculation might indeed be pointing to a serious problem, but the problem is hard to see right now. I am not inclined to endorse to change a policy for bots over readers when we haven't even pointed to specific examples yet. Awadewit | talk 06:13, 23 February 2008 (UTC)

The question is not whether such a bot exists at this moment or not, the question is, are we enabling it to potentially exist. The bot that scrapes geographical articles for coordinates to produce the Google Earth layers didn't exist before we standardized the information, because there was nothing for it to scrape. The added information that can be produced by scraping data from multiple articles emerges from the standardization. This makes the standardization of data a good thing in itself, regardless of how it's currently used. Plus, what Stradivarius said below. Zocky | picture popups 06:26, 23 February 2008 (UTC)

I don't think that it is a good idea to design policy around a yet-to-be-designed bot. Policy should think of readers first, editors second, and everything else third. We can design bots to do whatever we want. Awadewit | talk 06:42, 23 February 2008 (UTC)

Policy should think of encyclopedia first, encyclopedia second, and encyclopedia third. The goal of the project is to write an encyclopedia and to produce free knowledge, not to please readers. Zocky | picture popups 06:51, 23 February 2008 (UTC)

But the encyclopedia is for readers - not for bots. We need to think about their needs. Awadewit | talk 07:00, 23 February 2008 (UTC)

More than my eyes being "led off the page" by a right-facing, right-aligned portait, my eyes have an initial difficulty locating the beginning of the text block if it doesn't start at the top left corner of the article frame. If keeping right-facing portraits on the left side of the page is really that important, I suggest that they be coded to appear a bit lower, so that there are at least a few lines of text that start flush left. Strad (talk) 06:21, 23 February 2008 (UTC)

I don't mind having text above left-aligned portraits, however I don't know if it is really necessary. Readers are already used to having adjust right to find text because of the menu bar on wikipedia (and most websites). It is not a big adjustment to keep looking a little further right. Awadewit | talk 06:44, 23 February 2008 (UTC)

Hmmm, I think we need a clarification here. Awadewit says that the majority of articles are non-standard, but this is incorrect. The standard, as far as humans are concerned, is to have the text start in the top left corner, and for the TOC to follow the intro section, flushed left. The standard, as far as bots are concerned, is for the article text to begin in the first P tag in HTML, and for the TOC to be included in the DIV tag right before the first section break, (i.e. a H2 tag). The vast majority of articles follow this standard, simply because it's the default behaviour. Only a tiny share of articles, probably well under 1%, uses non-standard layouts. Zocky | picture popups 06:38, 23 February 2008 (UTC)

• That's not what I meant. When I said "non-standard", I meant that most articles don't have an image, a lead, and a TOC. Because most articles are stubs, most don't have a lead and a TOC, for example. Awadewit | talk 06:41, 23 February 2008 (UTC)
  • Well, they do have a lead, they just don't have the article body ;) But, most articles aren't stubs. The vast majority of articles (clicking on the random article link suggests 90-95%) have at least one section header, and the majority (70-80%) have a picture or an infobox. Whether the TOC gets shown for articles with at least one or at least four section headers depends on your user preferences. (BTW, user preferences and personal CSS styles are another reason not to mess too much with the layout.) Zocky | picture popups 06:49, 23 February 2008 (UTC)
    • But it is still not clear to me why left and right-alignment would mess up any of these things. Please provide evidence of that. Thanks. Awadewit | talk 07:00, 23 February 2008 (UTC)
      • No, I'm arguing for the standard way of doing things. The claim that it's easier to work with standardized information, whether for readers, bots or CSS is self-obvious and doesn't need proof. What you need to do is argue that deviating from that established standard in the case of right-facing portraits brings net benefit. Your argument so far seems to be based purely on aesthetics, and that is simply not enough. Zocky | picture popups 07:05, 23 February 2008 (UTC)
        • But standardization isn't necessarily the best way to present information and that is the primary goal of the encyclopedia. Articles should be laid out in the way that best presents information on that particular topic. I would also like to point out that I am not arguing that we deviate from an established standard. I am arguing that we keep the current wording of the MOS, which agrees with established artistic principles, which is indeed important. I'm asking you to demonstrate how the current MOS regulations are harmful. You want to change them because you say without standardization bots will not be able to function. That is a claim that needs to be proven. 07:50, 23 February 2008 (UTC)
      • P.S.: As for aesthetics: are you aware that different users use different skins? When you change the layout of an article, do you check that it looks right in all skins? Do you expect other editors to do that? Zocky | picture popups 07:08, 23 February 2008 (UTC)
        • Yes, I do know about different skins. However, this is a minor percentage of users - most users come to us from something like google search and see the "classic skin" so I tend to check layouts in that skin. I was also under the impression that skins only changed the colors and design of the space surrounding the article. I did not think that skins changed the articles themselves. Awadewit | talk 07:42, 23 February 2008 (UTC)

(de-indenting). I concur with those who support flexibility here. "Aesthetic principles" are hardly "arbitrary rules", but rather is a fancy way of saying "We should design the encyclopedia in such a way that it is readable," which is indisputable. I disagree that we should promulgate a rule that will require making our pages uglier for the benefit of some hypothetical, poorly-written bot. As with article content, this is an area where we have to rely on our editors to use their judgment. If a picture on the left looks better on a given article, then the editors should be able to put it there. Nandesuka (talk) 08:48, 23 February 2008 (UTC)

"Standardization" on wikipedia is only meaningful when speaking about humans. Wikipedia articles are not created in a parseable markup language. While there are still many bits of information that might be parsed from them by a "bot", articles are designed for people. Whether or not the MOS guidelines under discussion affect bots is a red herring, and doesn't need to be proven, because it doesn't matter. The human argument seems to come down to aesthetics on both sides, and I don't doubt someone can find a vague reason that left-aligned portraits affect accessibility or usability. Examples would be good. (After learning from the MOS that left-aligned images in the article body should be placed before headers, so the header indents with the paragraph below it, I later saw someone change this based on accessibility.) It's a wiki. Not everything is going to be the same everywhere, and few people but the self-selecting wiki editor niche even notice these differences. This is what no one gets. So if we're going to consider "the reader" (a good idea), such alignment issues should perhaps be scheduled for their eighth discussion on behalf of the reader sometime after wikipedia has 50,000 featured articles on major subjects of human interest. –Outriggr § 10:41, 23 February 2008 (UTC)

Of course articles in Wikipedia are created in a parseable markup language. I'm not sure what that argument is supposed to mean, anyway.

And you talk as if bots work for themselves. They don't. They work for humans. When a bot parses a page to extract information, it's a human using the information with a bot. Thus the argument that standardization to facilitate data extraction is not human-oriented is simply wrong. We're creating a volume of free knowledge. The fact that most of the time most of us access that knowledge through a web site and a web browser is coincidental. Standard formatting of information is information in itself.

In effect, varying the layout of the standard pieces of information reduces the total amount of information for users, readers and data-extractors alike. It should be done only for good reasons, and this particular aesthetic principle (which is also somewhat dubious in our setting) doesn't seem to be one. Zocky | picture popups 01:10, 25 February 2008 (UTC)

As right-aligned TOC have problem with printing and you can see it if you try to print Jane Austen article on A5 pages. And as I tested and I feel it's not much different wethere to right-align or left-align a right faced picture. I think it's a good idea to try to have TOCs left aligned as much as possible. however i believe it depends on the article and shouldn't be discussed totally. Moreover I believe bots aren't important in right-aligning or left-aligning images or TOCs and for machine readable contentes another way except than wikipedia articles should be used. only a few visitors are such those bots and its bot's problem in that case.--Soroush83 (talk) 14:10, 25 February 2008 (UTC)

The discussion of bots is interesting, but I don't think it's the primary issue here. My concern is that the choice of image placement and its impact on article formatting affects readers. About three months ago, the layout of Jane Austen was changed to left-align the only authentic portrait of the subject, which initiated a cascade of other changes to work around this choice, most signficantly, removing the infobox and right-aligning the TOC. Since then, the article has been edited repeatedly in obviously good-faith attempts to (in their eyes) correct a formatting mistake. Clearly many readers find this layout objectionable. The subject has been brought up on the Talk page, but objections there are dismissed by references to this guideline... which is odd, because most of what it says here argues against the change.

The guideline currently states, "Portraits with the head looking to the reader's right should be left-aligned (looking into the text of the article) when this does not interfere with navigation or other elements." This is a sound recommendation. Graphic design professionals know that it's better to have the people in pictures looking into the page, not out of it. But those working in user interface design know there's also the question of usability to consider, which is why the caveat about navigation elements is important. Like I said: so far, so good.

Strangely, the next sentence flatly contradicts this, suggesting that the TOC – a navigation element. – be shoved out of the way to make room for a left-aligned image. Now, I don't claim to the world's foremost expert on user interface design, but I have taken classes in the subject, in which I was told that it is a Bad Thing for user interface elements to move around the screen, because that can be disorienting and it requires the user to spend more time looking for them. My professional experience supports this. It's less-than-ideal that the TOC moves up and down to accommodate the length of the intro, but that's tolerable because readers quickly come to expect it within WP. However, having seemingly-random articles substitute left-placement of the TOC for right-placement is confusing to many readers. After all, the rule about which way portraits should face is not generally known, nor is it self-evident. But the rules that UI elements should stay in place, and that articles should be formatted consistently unless there is "a compelling reason to do otherwise" (WP:MOS#Images, line 1), are intuitively understood. The suggestion to move the TOC just to accommodate a face pointing the wong way is (IMHO) bad UI design, and should be removed in favor of statement that precedes it. - JasonAQuest (talk) 03:52, 9 March 2008 (UTC)

New prohibition against regionally variant terms in articles

See the archived discussion Wikipedia talk:Manual of Style/Archive 92#"Press up" and "Push up:" Are articles limited to one country's term?. In a long duration sub-3RR edit war at Press up there has been disagreement about whether it is permissable to use at all (other than mentioning it in the introduction) any term which is a regional variant for the term used in the article's title, or the main term used in the article, where there is variation between English-speaking countries. See the talk page of Press up, in the section "Sub-3rr edit war." The North American term "Push up" has been repeatedly removed and replaced by the British term "Press up" in photo captions of a U.S. Marine doing the exercise with the argument that WP:ENGVAR does not allow any variation of terminology. The WP:ENGVAR section of the manual of style had been cited to justify the numerous reversions in Press up which removed any use of "push up." I pointed out the WP:ENGVAR section of MOS does not prohibit use of a variant regional term, that it only disallows variation of grammar or spelling. Matt Crypto recently changed the Manual of style [1] to disallow such variation of terminology, in addition to these previously disallowed variations of grammar and spelling. I reverted to the previous version of the MOS because I feel such a restriction should first arrive at consensus here on its talk page. The archived discussion cited above did not support the recent change. In a number of articles, one country's term has gained the title, and is the main term because of priority in editing the article, or for other good reasons, but the other country's term is allowed to occasionally appear where appropriate. Examples where Matt's new rule would allow large changes in the form of purging all but the main term are the article Rooster (U.S. term) where the British term "cock" appears many times, the article Eggplant (U.S. term) where the British term "aubergine" appears many times, the article Elevator (North American term) where the British term "lift" appears many times, the article Windshield (U.S. term) where the British term "windscreen" appears numerous times, and the article Wrench (North American term) where the British term "spanner" appears several times. I expect there are other articles where the British term is the main one for the article but other regions' terms are also allowed to appear , such as Maize (term used in Britain) where the U.S, Canadian and Australian term "corn" appears several times. This change to the Manual of Style would indeed make it easier to keep "push up" from being used in a photo caption showing a U.S. Marine doing the exercise in the Press up article, but it might be a license to similarly purge regionally variant terms from numerous other articles, and therefore deserves a careful examination here. Edison (talk) 08:09, 2 March 2008 (UTC)

I for one feel that the situation has become silly. However, it is complex. For consistency and style, an article shouldn't mix up equivalent terms willy-nilly, whether they're regional variations or general synonyms. However, in a caption or section which clearly applies more closely to one term, it's sensible to switch for that section or caption (or whatever). This is especially obvious if there's a quote using that variation. SamBC(talk) 12:30, 2 March 2008 (UTC)

The reason for ENGVAR is two-fold. Anglo-American edit wars are silly and unproductive (and implicitly discourage part of the English-speaking world from editing; anyone can edit, remember?). On the other hand, flipping back and forth from British to American without a good reason can be disconcerting to the reader. (One such is noting the existence of two terms, as the article does.) Here there is a reason, and I think a good one; U.S. Marines doing press-ups is also disconcerting to the reader; if it were not, this controversy would never have arisen.

I have tried putting "push ups" in quotes, as the dialect local to the picture; will that settle it? Septentrionalis PMAnderson 16:53, 2 March 2008 (UTC)

Would it be equally appropriate to put "cock" in quotes in the Rooster article or "lift" in quotes in the Elevator article? This style guide should apply to all articles equally. Edison (talk) 01:48, 3 March 2008 (UTC)

Yes, of course, provided we are preferring to an obviously and solely British usage; if we have a picture of the lifts to the London Underground, for example, I would not even use quotes in the caption. Septentrionalis PMAnderson 16:46, 3 March 2008 (UTC)

Heh - should be "Press-up" anyway, if it's BrE, with the hyphen. Just to be annoying ;) Carré (talk) 09:30, 3 March 2008 (UTC)

Even the "push up" in quotes has been reverted out of the Press up article with the rationale that no instances of the regional variant are allowed (in that one article, at least.) That is why it is important to get a consensus here either that the non-title regional variant term is strictly forbidden (as has been the practice in Press up) or that it is allowed within reason, as has been the practice in the numerous other articles cited above. Anything which causes passions to rise as this has in a few articles is not as silly or trivial as it may seem. Set a guideline and then have it apply equally to all articles. Edison (talk) 19:33, 3 March 2008 (UTC)

Well, there certainly seems to be no consensus for that interpretation here, at least. I say that alternative terms should be allowed within reason. How much is reasonable is for each article to determine but "none at all" is probably never reasonable. Especially where the two terms are so darn close to one another... SamBC(talk) 22:17, 3 March 2008 (UTC)

As a data point, I would like to note how we have the article on Airplanes (or Aeroplanes) at Fixed-wing aircraft. There's certainly no valid basis for rejecting one regional term in favor of another one across the entire encyclopedia. The only reason we have articles titled Press up, Gasoline, etc, is that there is no ambivalent title available (and not for lack of trying) as there is for fixed-wing aircraft. —Random832 20:00, 3 March 2008 (UTC)

Following this side point, why not have the main article for that one at "Petroleum spirit", I thought that was a technical, non-regional term? But lets not get sidetracked. SamBC(talk) 22:17, 3 March 2008 (UTC)

I have set up a straw poll at Talk:Press up#Straw poll, with four options. Septentrionalis PMAnderson 23:46, 3 March 2008 (UTC)

Vague proposal

Given that this strange and frustrating situation has occured, is it not perhaps worth clarifying the guidance to indicate that this does not mean that articles must religously and strictly stick to one form of a term, especially where that term is (used for) the subject of the article? SamBC(talk) 15:19, 4 March 2008 (UTC)

WP:ENGVAR already permits exceptions. A general point on Consistency within articles like

Each article should generally be consistent within itself; it should not change from one variety of English to another, one form of citation to another, or one stylistic choice to another, unless there is good reason to do so. Arbitrary shifts will be disconcerting to readers, who will look for reasons.

would permit most of calls for consistency to be subsumed, which would shorten and simplify this document. Septentrionalis PMAnderson 18:22, 4 March 2008 (UTC)

In the case in point, Press up, WP:ENGVAR has been cited as justification for refusing to allow a caption to say a U.S. Marine is doing a push up, or that Paddy Doyle did the most back of the hand pushups in one hour, cited to Guiness Book of World Records [2]. If the reference calls them pushups, it should be permissable to use that term in the article. Edison (talk) 21:48, 5 March 2008 (UTC)

Edit warring is back

Two users seem to be entering a new revert war [3] [4] [5] over whether the term 'push up" can be used in the Press up article in a caption of a U.S. Marine doing said exercise. Any suggestions how to resolve this in light of the above discussion? Edison (talk) 03:17, 13 March 2008 (UTC)

Where is the change in spelling out nine to ten?

The verbosity here is a killer, and there is (as yet) apparently no attempt to summarize changes to long-standing guidelines so that others will be in the loop. Will someone kindly point me to the part of the discussion that resulted in a change to the spelling out of single digits only, from nine to ten, and the consensus for that change to the long-standing guideline? Thanks, SandyGeorgia (Talk) 21:57, 4 March 2008 (UTC)

Sandy, the verbosity may be a killer. But so is any simplistic approach to complex or contentious issues. Discussion is done with words; and sometimes many are needed, especially when editors here ignore what is plainly said or asked the first time.

I have called for a register of MOS changes to help all editors keep track, and especially to help with your FAC work. My suggestion was met with stony silence. (Few enough words for you?) The issue of a register may be dealt with at WP:MOSCO, when that page is more developed.

There has been no substantial change concerning figures or words for numbers. PMAnderson has altered some details, that's all. But the whole thing is disorderly and complex. There should be changes, so that your work and everyone else's will be helped. Let's hope we can negotiate a genuine and rational guideline for this. And then for centuries, also.

– Noetica^♬♩ Talk 22:33, 4 March 2008 (UTC)

OK, so 10 is still a digit, and nine is spelled out? Thanks, Noetica. If the goal of some here is to kill MoS via verbosity, it may succeed. SandyGeorgia (Talk) 22:36, 4 March 2008 (UTC)

The guideline is not that simple, in fact. A pity it can't be! But there must be exceptions to any edict so draconian as that.

Kill MOS? Certainly not my goal! I want straight and respectful discussion, towards rational, simple, suitable guidelines. Hard to get such discussion, with many words or few.

– Noetica^♬♩ Talk 23:23, 4 March 2008 (UTC)

Yes or no: can someone please point me to when, where and why the boundary between nine and ten changed (from the previous wording):

In the body of an article, single-digit whole numbers (from zero to nine) are given as words; numbers of more than one digit are generally rendered as figures, and alternatively as words if they are expressed in one or two words (sixteen, eighty-four, two hundred, but 3.75, 544, 21 million).

Thank you, SandyGeorgia (Talk) 23:54, 4 March 2008 (UTC)

Genuinely sorry, Sandy. The text was indeed changed on 24 February by User:Centrx, in this edit, from this text:

In the body of an article, single-digit whole numbers (from zero to nine) are given as words; numbers of more than one digit are generally rendered as figures, and alternatively as words if they are expressed in one or two words (sixteen, eighty-four, two hundred, but 3.75, 544, 21 million).

To this text:

In the body of an article, whole numbers from zero to ten are spelled out in words; numbers greater than ten may be written out if they are expressed in two or fewer words (sixteen, eighty-four, two hundred, but 3.75, 544, 21 million).

Centrx's edit summary: "Use previous language, which is more accurate and concise".

Of course, the text is not more accurate, since it is not strictly clear what the boundary is any more. (Is Centrx American, and therefore likely to express an inclusive range like this: whole numbers from zero through ten? I don't know!) I trusted the edit summary, which we sometimes cannot do: so I did not know that the substance was changed.

There was no consensus for that change; I'll now restore the wording that we had.

Centrx, please don't do that again.

– Noetica^♬♩ Talk 03:49, 5 March 2008 (UTC)

So I'm not entirely crazy :-) Thanks, Noetica; I thought I was blind or missing it among all the verbosity. It was another one of those "gotchas" that was getting me at FAC. SandyGeorgia (Talk) 03:55, 5 March 2008 (UTC)

No problem, Sandy. It took me a long time to track down that rogue edit. It just highlights the need for big reforms like a register of changes, doesn't it?

May your words be few but heeded. :)

– Noetica^♬♩ Talk 04:06, 5 March 2008 (UTC)

welllll ... when a basic, common, used-every-day sorta thing (like the boundary between spelling out numbers and digits) changes, we need to know about it at FAC :-) Thanks again. No matter how much I tried to get through, um, more of the usual from the usual, I couldn't find a consensus or discussion for that change on this page :-) SandyGeorgia (Talk) 04:11, 5 March 2008 (UTC)

Since that barrier is both disputed (discussions above have argued for nine, ten, and one hundred as the upper bound of mandatory words) and permeable, in both directions, in special situations (sentence boundaries, a function other than counting discrete objects), it would be better to rephrase. FA should not be imposing any rule, but considering specific situations. Septentrionalis PMAnderson 02:04, 7 March 2008 (UTC)

So why not make ten and 10 both acceptable? Anderson, it's "boundary", not "barrier". Tony (talk) 11:25, 7 March 2008 (UTC)

Depends on the vehicle of the metaphor; see potential barrier. Septentrionalis PMAnderson 16:47, 7 March 2008 (UTC)

• As for the substance, 10, ten, 9, nine, 1, one are all acceptable under the right circumstances; a careful writer may use 9 where he would not use 1, and 10 where he would not use 9; but that is why we should indicate the general tendency, with sample "rules", rather than pretending to legislate. Septentrionalis PMAnderson 16:47, 7 March 2008 (UTC)

Where is the change in spelling out ten to nine?

Will someone kindly point me to the part of the discussion that resulted in a change to the spelling out of numbers up to ten, to spelling out single digits only, up to nine rather than to ten, and the consensus for that change to the long-standing guideline?

Rhetorical question, of course. I've already found the answer as pointed out #Lack of jurisdiction above. It was the real undiscussed change of a longstanding guideline. Gene Nygaard (talk) 17:12, 7 March 2008 (UTC)

---

Wrong as usual, Gene. And wantonly careless. Interesting how you select your "facts". Without trawling through all of the archives to demonstrate how conscientiously Tony has discussed and consulted on such matters, I refer interested editors to this section of WT:MOSNUM (yes, that is MOSNUM!). Since you have perpetrated such a slander, Gene, I reproduce parts of the section here. Sorry if that seems to take up too much space, but the facts need to be shown clearly. (I add bold and underlining for emphasis):

[Tony initiates discussion; section header:] Proposed revision of "Numbers in words"

I don't understand the title. Please provide feedback on this new version. Don't you all think it's time to bite the bullet on "billion"? (Except that it doesn't quite belong under the new title.) Should there be guidance on hyphenating spelled out fractions? I've added something, and I'm unsure about it. And what about hyphens in numbers such as "twenty-four"—mandatory or optional?

...

EXISTING

Numbers in words

*Whole numbers from zero to ten should be spelled out as words in the body of an article. Use numerals in tables and infoboxes.

*Numbers above ten may be written out if they are expressed in two or fewer words, except in tables and infoboxes. Example: "sixteen", "eighty-four", "two hundred", "twenty million" but "3.75", "544", "21 million".

*Proper names and formal numerical designations should instead comply with common usage. Example: Chanel No. 5, 4 Main Street, 1-Naphthylamine, channel 6.

*Within a context or a list, style should be consistent. Example: "There were 5 cats, 12 dogs, and 32 birds" or "There were five cats, twelve dogs, and thirty-two birds", not "There were five cats, twelve dogs and 32 birds".

*It is considered awkward for a numeral to be the first word of a sentence: recast the sentence or spell the number out.

*Fractions standing alone should be spelled out unless they occur in a percentage. If fractions are mixed with whole numbers, use numerals.

...

NEW

Spelling out numbers

General rule

*In the body of an article, single-digit whole numbers (from zero to nine) are spelled out; numbers of more than one digit may be spelled out only if they are expressed in one or two words ("sixteen", "eighty-four", "two hundred", "twenty million" but "3.75", "544", "21 million"). Many people prefer all multi-digit numbers to be expressed generally as numerals, within the bounds of the exceptions below.

Exceptions

*Dates and times.

*Numerals that open a sentence are spelled out; alternatively, the sentence can be recast so that the number is not in first position.

*In tables and infoboxes, all numbers are expressed as numerals.

*Within a context or a list, style should be consistent (either “There were 5 cats, 12 dogs and 32 birds” or “There were five cats, twelve dogs and thirty-two birds”, not “There were five cats, twelve dogs and 32 birds”).

*Fractions are spelled out unless they occur in a percentage or with an abbreviated unit ("3.5 mm", “⅛ mm”) or are mixed with whole numbers.

...

*Proper names and formal numerical designations comply with common usage (Chanel No. 5, 4 Main Street, 1-Naphthylamine, Channel 6). This is the case even where it causes a numeral to open a sentence, although this is usually avoided by rewording.

...

[[User:Tony1|Tony]] 04:47, 12 July 2007 (UTC)

I have no objection other than the one you probably read under the previous heading #Contradictions II. Nobody is arguing that 0-10 should always be expressed as words, so that rule should mention that there are exceptions. Art LaPella 05:03, 12 July 2007 (UTC)

I didn't read that previous entry, actually. Um ... can you be explicit as to your objection? I don't think this new version changes much WRT the ten/11 boundary for spelling out numerals, does it? If I could have it my way, I'd insist on numerals above nine as the norm, but I think too many people would object. Am I right?

So we need to know what change you'd require for this new version to have your total support. [[User:Tony1|Tony]] 09:11, 12 July 2007 (UTC)

...

*Looks good to me. [[User:SandyGeorgia|Sandy<font color="green">Georgia</font>]] ([[User talk:SandyGeorgia|Talk]]) 14:50, 12 July 2007 (UTC)

...[suggestions from User:Jimp]...

*Jimp, I like your suggestions; I've tweaked and incorporated them. Please note:

(1) I've stuck my neck out by changing the ten/11 boundary to nine/10, because it's so simple to conceive the spell-out-single-digits rule. Happy to hear objections on that.

(2) "What does it matter what editors prefer"? It's a polite way of strongly recommending a usage without making it mandatory.

...

[[User:Tony1|Tony]] 02:09, 14 July 2007 (UTC)

...

Interested editors can see the whole comprehensive, public, and inclusive discussion for themselves, if they like.

The conclusion is inescapable: Tony's continued attempts to bring reason and reform to MOS, MOSNUM, and related pages have been consultative and consensual. (So, by the way, have mine. So have those of several others.) Editors like Gene Nygaard and Centrx, on the other hand, have typically not consulted, and have sought to reinstate old and superseded guidelines, with the risk that hard-won consensus will be subverted.

Editors should beware of Gene Nygaard's glib assertions, and look to the hard facts concerning our efforts at consensus-building by checking the archives.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 00:10, 8 March 2008 (UTC)

Okay, you've convinced me it was discussed, and it had some support. I wasn't about to try to dig trhough 108 archive pages to see if it had been. Gene Nygaard (talk) 00:56, 8 March 2008 (UTC)

This insulting response is mentioned above, at #Lack_of_jurisdiction. Please stop fragmenting the discussion. In fact, let's just drop this futile and slanderous exchange. And then perhaps you can set about fixing the damage to WP:MOSNUM that you have been party to, Gene Nygaard.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 05:16, 8 March 2008 (UTC)

That discussion has nothing about "numbers of more than one digit are generally rendered as figures"; it does not use the terms "figure" or "given as"; and the trend of the discussion is that "ten" ought to be the maximum rather than "nine". —Centrx→talk • 20:57, 9 March 2008 (UTC)

Centrx, your edit summary on 24 February purported to be about wording, but you changed the substance. You changed the substance without any discussion, anywhere. Your edit was reverted for that reason, basically. Even setting aside substance, your wording was no improvement, and also was not discussed!

The "trend of the discussion" was not, as you claim, that the boundary should be between 10 and 11. One editor said, as the complete last entry in the section, "ten/11 is not at all arbitrary: ten is the greatest number childrens may count on their fingers. After "ten" begins the abstraction of the number." That was User:Taxipom, who took no part in the discussion until then. Jimp had said, in argument against it, that it was "a seemably arbitrary choice". A very limited point, which got a limited and isolated answer. That's all!

Don't allege a trend on such a flimsy basis, Centrx. And if you won't discuss things lucidly on these talkpages yourself, don't carp at those who are committed to doing so. I remind you yet again (since you seem to need repetition): you edited on a key issue without ANY discussion, and you therefore caused the present difficulties.

I must now resist repeating things to you though, and having any discussion with you. It has no good effect, and takes up space and valuable time.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 21:32, 9 March 2008 (UTC)

Do you have any objection to the other changes? —Centrx→talk • 22:59, 9 March 2008 (UTC)

Yes I do. Wording is not as important as substance, but your wording was not good. We (including you) had been talking about just this matter in connection with centuries; and then we began a discussion of the entire subsection on numbers as figures or words. Some of us thought that should be revisited, at least to enable a rational dialogue about centuries. PMAnderson and I were talking about a new draft. But that cannot continue under present circumstances, as I note at the relevant section of this page.

The proper procedure, as you should know, would be to leave the guideline as it is right now, and as it was established by due discussion earlier, then join the conversation about any changes. But that conversation is stalled, for now.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 23:36, 9 March 2008 (UTC)

How is "single-digit whole numbers (from zero to nine) are given as words" better than "whole numbers from zero to nine are spelled out in words"? Why shouldn't examples be italicized to distinguish them from the mainstream text? —Centrx→talk • 23:46, 9 March 2008 (UTC)

What have italics got to do with this? Your undiscussed edit did not affect italics at all!

But this is a conversation we can have when you and Gene Nygaard have restored normality and stability by getting your undiscussed altered guideline at WP:MOSNUM reverted, so that the guideline there is consistent with the established guideline at WP:MOS. And see to it that WP:MOSNUM is unprotected and editable, OK? Then we can all work through the whole matter, in a properly named section either here or at WT:MOSNUM. Fragmenting the discussion just complicates the issue, and alienates editors who might be interested – no way to get durable consensus.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 00:05, 10 March 2008 (UTC)

Italics: [6]. We do not need to wait to discuss changes. If you have objections to an edit, explain them or improve the edit. —Centrx→talk • 01:07, 10 March 2008 (UTC)

Centrx, I note your continuing strong aversion to fresh, rationally organised discussion; and I have reverted your latest undiscussed changes! If you want to edit-war, and persist in altering the guideline that had been established for MONTHS, and had CONSENSUS and WELL-DOCUMENTED DISCUSSION, you will be responsible for the consequences. But don't expect the rest of us to appreciate your unruly and uncollegial acts, or to stand idly by.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 02:02, 10 March 2008 (UTC)

If you want to discuss it, discuss it. All you do is talk about how it ought to be discussed and how it was discussed in the past, but you don't actually discuss it. You do blanket reverts without accommodating any change, even the obvious italics. It is unproductive and it is a waste of everyone's time, yours most of all. I have opened a section below for you. —Centrx→talk • 02:32, 10 March 2008 (UTC)

What on earth is going on here, and how many places do you want to spread the discussion? Centrx changed a long-standing issue with no discussion, left a deceptive edit summary, it was changed back, and now apparently Centrx and one other editor are trying to reinstate it here and at MOSNUM without consensus. Please stop this silliness, and if you want to change, please discuss and gain consensus. Thank you, SandyGeorgia (Talk) 02:22, 11 March 2008 (UTC)

I think you mean Tony1. —Centrx→talk • 02:26, 11 March 2008 (UTC)

I don't have a preference between the versions, but as with many MoS issues, it doesn't appear that there have ever been enough participants in the discussions on this issue to demonstrate a meaningful consensus for either version. I think it would be best to approach the issue with no preconceptions and see if a genuine consensus can be developed. If there isn't sufficient interest to generate a consensus, it's a good issue that people don't care about the issue, and it isn't a good topic for a guideline. Christopher Parham (talk) 02:34, 11 March 2008 (UTC)

I have no pony in the race either as to what the final conclusion is, but these constant changes to long-standing consensus appear intended to confuse and render MoS useless. From one day to the next, we need to know what the guideline is, and we need stability on these pages. A few parties constantly edit war here and insert instability. Changes should be based on consensus so the rest of us don't have to guess from day to day what the guidelines are. Centrx, please stop inserting changes without discussion, and with deceptive edit summaries. If you want to change something, pls gain consensus first. SandyGeorgia (Talk) 02:37, 11 March 2008 (UTC)

I'm fast becoming FED UP with your attitudes and accusations, Centrx. It has been plainly pointed out to you that I did gain consensus at MOSNUM for the change, some time ago. Now behave like an adult, or MOS will be frozen, just as MOSNUM has been—due to you. Tony (talk) 02:38, 11 March 2008 (UTC)

While you certainly attempted to discuss the issue, I don't agree that you gained a consensus on the topic. If you propose a change that affects 2000000+ articles edited by thousands of people, and 5 people participate in the discussion, it demonstrates indifference, not consensus, even if the participants were unanimous in support (and there does appear to have been a quiet dissenting voice at the end). Christopher Parham (talk) 02:49, 11 March 2008 (UTC)

Numbers in words

Please explain below what is wrong with the changes in wording made to the section on numbers represented as words, all of which were reverted without exception. —Centrx→talk • 02:32, 10 March 2008 (UTC)

To start with, there were problems in your wording. Tony (talk) 02:50, 10 March 2008 (UTC)

What exactly are they? A pithy declaration like this is useless. —Centrx→talk • 03:26, 10 March 2008 (UTC)

Centrx!!! No no! Pay attention: We need a completely fresh discussion, don't you see? There's nothing wrong with using italics for mentioning; I do it all the time! I insisted that we get rational and consistent about doing that (search the archives, if you like). Try again. Leave things as they were before your undiscussed alterations of 24 February; fix it at WP:MOSNUM also (and get rid of that protection: no one will edit-war, provided only that the current consensus guideline is left alone). Off you go! Come back when the current damage has been undone.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 02:53, 10 March 2008 (UTC)

This is a fresh discussion, in a fresh section. Present the reasons why you reverted or do not revert. That is all. —Centrx→talk • 03:26, 10 March 2008 (UTC)

It is not a fresh discussion. PMAnderson and I were doing one of those (look and learn!). This, on the other hand, is a pusillanimous attempt to dwell on italicising and such minute matters, which have nothing to do with the topic as a whole, and for which there are clear principles already in place. All that can be fixed easily.

I'll not try any more to get this matter addressed rationally. Plague someone else for a while, Centrx. I have better work to do. I'll come back when things are restored to proper order, and your damage has been undone. That is all.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 03:40, 10 March 2008 (UTC)

I made an edit, which you reverted. You have not explained anything wrong with the edit. —Centrx→talk • 03:49, 10 March 2008 (UTC)

I haven't??? Amazing. Sorry, Centrx. Too late. Talk to someone else.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 03:59, 10 March 2008 (UTC)

Single quotation marks

Everything about quotation marks and the usage of single and double ones revolves around quotations. Everything. There is not a single sentence about the usage of single quotation marks in any context other than quotations. Well, except for this:

If a word or phrase appears in an article in single quotes, such as 'abcd', Wikipedia's search facility will find that word or phrase only if the search string is also within single quotes. This difficulty does not arise for double quotes, and this is one of the reasons the latter are recommended.

But it's not very clear, is it? Yet single quotation marks are used for all sorts of terms and names. From the above excerpt I can only infer that they are not supposed to be thus used, but it is not clear enough, and it has obviously not affected the flourishing current practice. I have replaced single quotation marks with double ones in some cases, but only tentatively; it actually took me some time to locate this little sentence and fully realise what it said.

I think that it ought to be more clearly shown in the MoS what exactly the guidelines are on single quotation marks. I mean, there are guidelines, right? Waltham, The Duke of 01:27, 11 March 2008 (UTC)

In general, single-quotation marks are used where double-quotation marks might mislead the reader into thinking text was quoted where it was not, or in other words in situations where a word is to be somehow distinguished as not being used in it ordinary sense or as a use-mention distinction. Italics are often better as we have that formatting option. —Centrx→talk • 02:28, 11 March 2008 (UTC)

I agree that italics are usually better, and I use them very much myself. But shouldn't this be mentioned somewhere? I'm tired of seeing single quotation marks everywhere, and people will keep adding them unless instructed otherwise.

Note that the italics in my message are just for emphasis. :-) Waltham, The Duke of 11:09, 11 March 2008 (UTC)

Common mathematical symbols: spacing

The section Common mathematical symbols says that the times symbol (×) should be spaced on both sides. I'm fine with that in equations, but it should not be spaced when it appears inside numbers in exponential notation (e.g. 2×10⁴). This is a single entity, and should not have internal spaces. This prescription in the MoS has caused someone to change the {{e}} template (for exponential notation) to add spaces, which makes numbers ugly and sometimes confusing when they appear in text. The template currently renders as 2 × 10⁴.--Srleffler (talk) 16:41, 11 March 2008 (UTC)

I added spaces in response to a request (Wikipedia:Village_pump_(assistance)/Archive_7#Template:e, but I agree that the general rule does not necessarily apply inside numbers in exponential notation. Do you have examples where it is confusing?--Patrick (talk) 17:43, 11 March 2008 (UTC)

It is customary in mathematical typesetting to place a space on either side of binary operators (+, −, ·, ×, etc.) in order to improve readability and make the structure of the formula clearer at first glance. In the case of 2×10⁴, I usually would not use spaces, as such a constant in a formula is semantically a single object and therefore the space distracts rather than contributes to readability, especially if there are other operators nearby.

Good: 2×10⁴ m/s − 3×10⁴ m/s (space to separate quantity and unit as well as to distinguish outer operator)

Bad: 2 × 10⁴ m / s − 3 × 10⁴ m / s (spaces inserted in mindless rule following everywhere)

Maybe: 2 × 10⁴ m/s − 3 × 10⁴ m/s (no spaces around operators in units)

In the second example, the use of spaces provides no useful information to the reader. Likewise, we also do not use spaces around binary operators that occur within units of measurements (i.e., km/h and not km / h). There is ultimately only a single criterion on which any typographic convention should be judged: whether it offers any benefit to the reader or not. Markus Kuhn (talk) 19:48, 11 March 2008 (UTC)

I don't agree; if there's a problem, you can always enclose each compound item in curly brackets, but that would not normally be necessary. Tony (talk) 03:37, 12 March 2008 (UTC)

Clearly the version without the spaces within the constants and units is easier to read and better typography, though. I propose adding an exception to the MoS prescribing no spaces within constants in exponential notation, nor within units.--Srleffler (talk) 04:03, 12 March 2008 (UTC)

The squashy version is harder to read, IMV. Tony (talk) 08:01, 12 March 2008 (UTC)

Bearing in mind here that I'm a mathematician, I find the second version mildly easier to read, apart from the spaces inside the units; there really shouldn't be spaces inside units, even compound ones, regardless of the operators. Otherwise, the spacing is slightly better, and anyone with the knowledge to understand the expression at all will know what is meant because there's only one way to read it that makes any sense. SamBC(talk) 12:37, 12 March 2008 (UTC)

For what it's worth, my opinion is that "2.3×10⁻¹³" is a single number, rather than a product of numbers. So it makes sense to not include the gaps. The only reason spaces were imposed is because of the Wikipedia standard, MoS.

Springer, a reputable publisher of scientific books, does not use spacing in exponential notation.[7] Then again, there are some journals[8] that do include gaps. My personal preference would be to do away with the gaps for exponential notation.—RJH (talk) 15:46, 12 March 2008 (UTC)

I agree – a number in scientific notation is a single entity. Bubba73 (talk), 01:40, 13 March 2008 (UTC)

I’m commenting here at Tony (Tony1)’s request: I, too, agree that we should omit the spaces in scientific notation. I’ve reverted the template back to its original (non-spaced) behavior for the time being, at least. — Knowledge Seeker দ 09:12, 13 March 2008 (UTC)

And you've acted improperly by not gaining consensus for (re-)introducing and inconsistency WRT to MOS. FAs have to comply with MOS, and this was the original reason that RJH requested the change. Now, if you want to judge for yourselves just how ugly and hard to read squashed-up scientific notation is—at least on a computer monitor—here are examples from the article Ampere, the first linked article to the E-template that I looked at:

μ₀ $\ {\overset {\underset {\mathrm {def} }{}}{=}}\$ 4π×10⁻⁷ H/m

6.24150948×10¹⁸

1.60217653×10^-19 ± 0.00000014×10^-19 C

This is unacceptably difficult—squint material, all the more given that our text does not appear in hard copy, and is designed to be read by a wider audience than the highly specialised audience that Knowledge Seeker et al. here are clearly thinking of. Not fair to our readers, I say. I don't buy Sleffler's idea that the squashed-up version is somehow "better typography" (run that argument past me again?). Nor do I buy the argument that these expressions are single numbers and thus should be squashed up; they can be seen as either single or composite expressions, just like 2.1 × 2; you may wish to make professional distinctions on this basis, but I think they might elude most of our readers, and it is they who count.

Here are the spaced versions, as currently required by MOS:

μ₀ $\ {\overset {\underset {\mathrm {def} }{}}{=}}\$ 4π × 10⁻⁷ H/m

6.24150948 × 10¹⁸

1.60217653 × 10^-19 ± 0.00000014 × 10^-19 C

Tony (talk) 10:05, 13 March 2008 (UTC)

And here is the form used (but not prescribed) by the BIPM in their brochure on SI:

μ₀ $\ {\overset {\underset {\mathrm {def} }{}}{=}}\$ 4π × 10⁻⁷ H/m

6.241 509 48 × 10¹⁸

1.602 176 53(14) × 10^-19

— Preceding unsigned comment added by Woodstone (talk • contribs) 05:35, March 13, 2008 (UTC)

The space-less version looks perfect to me, except that I would also remove the whitespace around the ±, since it is used here between a number and its tolerance rather than between two values in a mathematical expression. (But that is a debate for another day.) If you have to squint, perhaps you have the fonts set too small on your computer? :)--Srleffler (talk) 17:06, 13 March 2008 (UTC)

It looks like the extra spaces have already been stripped from the {{e}} template. Does that mean a consensus has been reached not to use spaces?—RJH (talk) 21:22, 13 March 2008 (UTC)

No, as I've complained on the template talk page and here, Knowledge Seeker has arrogantly stripped off the spaces (thus causing MOS breaches en masse) with the say-so of only one of his friends there. It's the kind of behaviour that mop-people should be resisting, not perpetrating, and is another example of the use of petty admin powers in a dysfunctional way. If KS had any decency, s/he would revert it NOW and wait for the discussion to evolve here and/or there. The fact that Srleffler thinks the squashed-up version is just fine, thank you, is is disregard of what a semi- or non-expert might say. Tony (talk) 01:45, 14 March 2008 (UTC)

I'm not sure what a "mop-person" is, but I do hope it's not a derogatory term. Your usage seems rather uncivil. --Srleffler (talk) 02:21, 14 March 2008 (UTC)

An admin (Knowledge Seeker) reverted the template to the version without spaces, on the grounds that the addition of the spaces had not had consensus.--Srleffler (talk) 02:21, 14 March 2008 (UTC)

Um ... just why you and KS represent consensus against at least three people who came down on the opposite side is totally beyond me. That is why I suspect that this behaviour was arrogant. In addition, the change goes against MOS, rendering all FACs a failure unless they strip the template from their text. It's not behaviour that befits a mop-and-bucket person (that's the name some admins use themselves—don't blame me). Tony (talk) 06:14, 14 March 2008 (UTC)

PD quotation clarification

As apparent at Wikipedia talk:Citing sources#Return of PD text style, the Quotations section needs clarification that reused text from public domain sources such as EB {{1911}} do not need to be walled off inside quotation marks. Or else a bot needs to go wrap quotation marks around a bunch of articles and city descriptions. -- SEWilco (talk) 17:52, 11 March 2008 (UTC)

Units if surrounding text is italics

I was most perplexed when I just discovered the recent addition of a new very strict never-italic-unit-symbols rule:

• Unit symbols (abbreviations) are never written in italics, even if the surrounding text is in italics.

How was this justified? I am, of course, very well familiar with the SI and ISO 31-0 rule of using an upright font for unit symbols in order to distinguish them in equations from variables and quantities, which are normally written in italics. That rule makes perfect sense as the advantage to the reader is obvious: in "m = 1 m" we know – thanks to the rule – exactly that m is a variable and m is the unit meter.

But what can possibly be the justification for strictly always using upright type for a unit name even outside equations (i.e., no italic quantities nearby) in the middle of a fully-in-italics sentence? What is wrong with a 30 km/h speed limit? I don't get it and I've never seen anyone outside Wikipedia write: What is wrong with a 30 km/h speed limit? Please explain to me what advantage to the reader this surprising new rule has. Unless someone has a good explanation for the practical advantage to the reader, I propose to rephrase the rule into:

• Unit symbols (abbreviations) are never written in italics, unless the surrounding text is in italics.

Markus Kuhn (talk) 20:06, 11 March 2008 (UTC)

Thanks Markus. Yes, that is an unruly change indeed, and not discussed first. I have therefore reverted it, along with another undiscussed change to a provision currently under dispute.

This whole matter of italics for unit symbols no matter what was discussed at length some time ago. There was no consensus for the absurd suggestion that symbols stay upright no matter what! If this must be talked through yet again, so be it. But I hope editors will restrain themselves in the meantime, and will revert all non-consensual changes. MOS needs stability.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 21:44, 11 March 2008 (UTC)

Exactly, Noetica. How ridiculous is the notion that ISO's erroneous wording (I'm convinced that it is a mistake) should be parrotted here. ISO almost certainly intended that symbols not normally be italicised. The writer(s) of their guideline were probably irritated by the normal italicisation of the symbols, and in intensifying the wording, changed the meaning completely. Tony (talk) 00:56, 12 March 2008 (UTC)

And there's nothing wrong with italicising a symbol for emphasis, either. Why not mirror our wording for quotations and italics? ("a quotation is not italicized inside quotation marks or a block quote just because it is a quotation")?

Do not italicize unit symbols (abbreviations) just because they are unit symbols.

Tony (talk) 01:00, 12 March 2008 (UTC)

This is not limited to ISO. NIST gives this recommendation:

The typeface in which a symbol appears helps to define what the symbol represents. For example, irrespective of the typeface used in the surrounding text, "A" would be typed or typeset in

• italic type for the scalar quantity area: A;
• roman type for the unit ampere: A;
• italic boldface for the vector quantity vector potential: A.

An example of them following their own advice is this: "...the recommended symbol for the liter in the United States is L". Here they are discussing the symbol, rather than using it, yet it is not in italics. --Gerry Ashton (talk) 03:53, 12 March 2008 (UTC)

Also, a recommendation from NIST is not absurd. I consider this a deliberate insult from Noetica, which I will not forgive. --Gerry Ashton (talk) 04:13, 12 March 2008 (UTC)

Sorry for changing the guideline first without bringing it up here; I know better than that. Tony, this is not simply an error by ISO. NIST's guide to SI units (SP811) is explicit about this. Gerry has quoted it already, but did not quote the clearest statement in that document. Section 6.1.1 "Typeface" reads "Unit symbols are printed in roman (upright) type regardless of the type used in the surrounding text." In NIST's opinion, it is never correct to write an SI unit symbol (abbreviation) in italics. I propose that Wikipedia's style guide should comply with this standard. Note that spelled-out unit names are not precluded from appearing in italics, only unit symbols.--Srleffler (talk) 04:16, 12 March 2008 (UTC)

Yes, but here we're not beholden to any particular guideline (and nor is NIST in developing its own, for US usage, I presume). WP has different conditions both for writers and readers. Give me one good reason that symbols should not be italicised for emphasis or where the surrounding text is in italics. I'm not interested in blindly following an external guideline—whether NIST or ISO or whatever—unless there's good reason to. Tony (talk) 07:58, 12 March 2008 (UTC)

Yes, we are not beholden to any particular external guideline, but it behooves us to look at the best practices of other organizations in the course of forming our own guidelines. Printing unit symbols in italics leads to confusion, since italics are normally used for variables in mathematical writing. It is also unnecessary. Units rarely require emphasis, and the use–mention distinction can be marked just as well by quotation marks as with italics. Proper typography is important because it is not uncommon for a math or physics article to use symbols that are distinguished only by the typeface. One may use "m" for mass and "m" for metres simultaneously without confusion, for example, only because of consistent application of this rule. If italics are permitted for emphasis, one creates situations where the reader may be unsure whether m is a mass or a distance. It goes beyond single symbols as well. An expression like 2 dm could otherwise be mistaken for "two decimetres", but in fact is a product of a constant and two variables (perhaps a distance and a mass). --Srleffler (talk) 01:39, 13 March 2008 (UTC)

There is a genuine problem, Srleffler, and it is not to be lightly dismissed. But it is not to be heavily dismissed either! I mean that heavy-handed and one-size-fits-all approaches are not helpful. Very often, in casual use, unit symbols fit seamlessly into the surrounding text, and nothing is gained by making them non-italic when surrounded by italics. Usually such contexts will be non-technical, and the unit symbols will not be highly esoteric.

Apart from that consideration, think of these two factors:

• We are dealing with a large number of volunteers who need straightforward and memorable guidlines. They will, like it or not, use italics in mentioning or emphasising all sorts of things, regardless of the problems we can see arising from that practice. It is unfortunate that the relevant authorities have invested mere styling (italics, bold, etc.) with semantic significance. That was a mistake, I say, and bound to end in tears. But good everyday editors need a good everyday way to deal with this.
• For anyone, though, the matter of singling out some items as always non-italic is fiddly and error-prone. You might have to leave a solidus (/) or other maker in italics (because overall the text is italicised), sandwiched between romans. It could get pretty ugly in markup! And the result could often be unreadable or misinterprested, when a font or a browser is used that tends to overlap italic and roman elements, as we sometimes see with this sort of thing: " '...to speak of' ".

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 03:59, 13 March 2008 (UTC)

I understand your point here, and it is a good one. There is merit in a simpler prescription that is more likely to be implemented correctly by editors unfamiliar with this standard, rather than a less intuitive rule that would be broken more often. On the other hand, there is merit in having the MoS uphold a standard even if individual editors sometimes fail to meet that standard. Errors can always be fixed later, and it isn't so critical if some are overlooked.

Regardless of what we decide on the larger issue of whether unit symbols can sometimes be italicized, it seems to me that having the MoS section on unit symbols filled with examples of symbols in italics is a bad idea, because of the same issue of inexperienced editors. I hope we would both agree that when unit symbols are used normally (rather than mentioned or emphasized), they are in Roman type, and that the SI standard is clear on this. The current MoS section might leave a new editor with the impression that unit symbols are supposed to be in italics, since nearly all of the unit symbols in it are shown in italics. I understand the use-mention distinction, but lots of editors do not. It's also unnecessary, since "mention" can be denoted just as well by quotation marks. Editing the section to remove most or all of the italicized symbols would set a much better example of proper SI usage, regardless of one's opinion on whether it is acceptable to italicize unit symbols for emphasis.--Srleffler (talk) 02:52, 14 March 2008 (UTC)

Ah, Gerry Ashton. You need to be a little more careful. I said: "There was no consensus for the absurd suggestion that symbols stay upright no matter what!" The recommendation from NIST does not explicitly say that they must. It may be interpreted that way, but it is not clear. As I will show, its own practice illustrates this uncertainty beautifully. "Surrounding text" is one thing; a styling that is applied in blanket fashion – say, in giving the title of a book – is another. Gerry, you offer this example of NIST's own mentioning practice to support your case: "...the recommended symbol for the liter in the United States is L" (p. 12, as I find). What you do not say is that in the same document NIST has text like this: "The liter (L) is a special name for the cubic decimeter (dm³)" (p. 23). Here the word "liter" is also mentioned, not used: and it too is unitalicised. Symbols are not treated exceptionally. But in fact, NIST is inconsistent in its mentioning practice, and therefore is a poor model for us to appeal to, being itself so deficient in that department. Sometimes, as we have seen, it has no special marking for mentions (words as words); but sometimes it uses double quotes, as this small selection shows:

...the spellings ‘‘meter,’’ ‘‘liter,’’ and ‘‘deka’’ rather than ‘‘metre,’’ ‘‘litre,’’ and ‘‘deca,’’ and the name ‘‘metric ton’’ rather than ‘‘tonne.’’ (p. iv)

Similarly, standardized mathematical signs and symbols such as are given in Ref. [6: ISO 31-11] are used, for example, ‘‘tan x ’’ and not ‘‘tg x .’’ (p. 6)

Note the difference between ‘‘surface’’ and ‘‘area,’’ ‘‘body’’ and ‘‘mass,’’ ‘‘resistor’’ and ‘‘resistance,’’ ‘‘coil’’ and ‘‘inductance.’’ (p. 6)

...under the name ‘‘International nautical mile.’’ (p. 52)

This inconsistency is a departure from BIPM's more careful practice:

The multiples and submultiples of the kilogram are formed by attaching prefix names to the unit name “gram”, and prefix symbols to the unit symbol “g” (BIPM, The International System of Units (SI), 8th edition, 2006, p. 106)

NIST's own bibliographic practice is decidedly unusual. It does have digits in roman, surrounded by italics:

Letter symbols to be used in electrical technology, Part 1: General (p. 73)

And the very NIST document that cites in that fashion has its own title presented in uniform italics:

NIST Special Publication 811 / 1995 Edition Guide for the Use of the International System of Units (SI)

Consistency would demand that "811", at least, be in roman, not italics!

And in any case, as Tony suggests immediately above, we are not constrained to respect anything from NIST (National Institute of Standards and Technology: for National, read American, and the publication is produced for the United States Department of Commerce).

You'll never forgive me, Gerry Ashton? I think I can live with that. :) But such a public display of inflexibility cannot reflect well on your attitude as an editor, I fear.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 12:55, 12 March 2008 (UTC)

None of what you write really addresses the fact that NIST's document directly prescribes the use of Roman type for unit symbols "regardless of the type used in the surrounding text". Inconsistencies in NIST's adherence to its own standards are not a valid argument against the merits of those standards, especially when those inconsistencies do not involve a single instance of unit symbols being presented in italics.--Srleffler (talk) 01:39, 13 March 2008 (UTC)

You think not, Srleffler? It does address it, I think. I said, in effect, that "surrounding text" may be taken in more than one way. To disambiguate, we have to look at examples in NIST's own practice. And right there, on the title page and the next page, we see evidence that it allows "blanket italicising" for titles, at least. No unit symbol occurs in the title, but digits do – digits that NIST elsewhere treats as needing to be in roman.

As for NIST's inconsistencies, that might be taken as a mere ad hominem or a tu quoque; but in fact, given the difficulty of interpretation, and the absence of strong corroboration from the BIPM document, we have to resort to such measures. In any case, examining the practice of a supposed "authority" is a perfectly legitimate move. Would you trust the grammatical advice of an incompetent user of the language?

And of course there are no examples of NIST using unit symbols in italics, for mentioning and the like. When I explain things in detail, with chapter-and-verse evidence, please pay attention: I pointed out that NIST's general practice is not to italicise in mentioning. It appears always to use other means (and inconsistently!).

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 03:36, 13 March 2008 (UTC)

Your argument is empty sophistry, and adds nothing to the discussion. You admit that there are no examples of NIST using unit symbols in italics, and have offered nothing else of value.

Contrary to what you imply, the BIPM also unambiguously prescribes that unit symbols be printed in roman type "regardless of the type used in the surrounding text".[9] They introduce their standard for the presentation of unit symbols with the text

General principles for the writing of unit symbols and numbers were first given by the 9th CGPM (1948, Resolution 7). These were subsequently elaborated by ISO, IEC, and other international bodies. As a consequence, there now exists a general consensus on how unit symbols and names, including prefix symbols and names, as well as quantity symbols should be written and used, and how the values of quantities should be expressed. Compliance with these rules and style conventions, the most important of which are presented in this chapter, supports the readability of scientific and technical papers.[10]

Wikipedia's house style should comply with the standards for the SI system, and with the international consensus on how SI unit symbols are rendered.

As stated in that same BIPM document: "Unit symbols are mathematical entities and not abbreviations." They follow different rules from English prose because they are not prose. Unit symbols are presented in roman type in the same way that scalar variables are presented in italics, independent of whether they appear in an equation or in text.--Srleffler (talk) 04:42, 13 March 2008 (UTC)

For the record, since I'm not sure it has been referenced here already, the prescription that unit symbols are presented in Roman type is officially part of the SI system, described in Resolution 7 of the 9th CGPM (1948) (Comptes Rendus de la 9^e CGPM (1948), 1949, 70).[11] Noetica will of course point out that it does not explicitly say that this is regardless of context. The information cited above is sufficient to demonstrate the way this standard is interpreted by international standards bodies.--Srleffler (talk) 04:49, 13 March 2008 (UTC)

Srleffler, you write: "Your argument is empty sophistry, and adds nothing to the discussion. You admit that there are no examples of NIST using unit symbols in italics, and have offered nothing else of value." Yet you ignore the answer that I have already twice given concerning the absence of italicised unit symbols in the NIST publication. It inconsistently uses two alternative systems instead (in the superseded version that has been cited!). I have also argued, effectively, that we can get little guidance from an American-based organisation making prescriptions for professional writing in circumscribed contexts, which itself exhibits inconsistency. Hardly a good example for Wikipedia – an international encyclopedia pieced together by volunteers in a very general setting, where consistency is much harder to achieve. To label my arguments "empty sophistry" will advance things not at all. In your sophistic response, you fail to mention the other points I have made, concerning the special needs of Wikipedia as a generalist, HTML-based encyclopedia.

You also ignore the points I have made that acknowledge the problem we face, and that address in detail the particular issues at the coal-face. It is a characteristic of empty rhetoric that it does not confront hard details; I do, but so far you do not, apart from in carefully selected citation without page numbers.

You cite the relevant BIPM brochure, but you sophistically suppress the context. Here is the paragraph in full (emphasis added; and note: I do give page numbers, something others might consider doing also):

Unit symbols are mathematical entities and not abbreviations. Therefore, they are not followed by a period except at the end of a sentence, and one must neither use the plural nor mix unit symbols and unit names within one expression, since names are not mathematical entities. (p. 130)

You seek to hijack the selective quotation, lacking what I here show in bold, to your own purpose:

They follow different rules from English prose because they are not prose.

As if that were BIPM's intent! No, they do not claim that unit symbols are "not prose"; they do not even mention prose, anywhere in the document. Careless at best, Srleffler. At worst, deceptive.

Your assumption that I have not looked at this in some detail, and deliberated about it with care, is unfounded and does you no credit. Let me stress the main point yet another way, to see it that will get across any better. You cite the BIPM brochure:

Compliance with these rules and style conventions, the most important of which are presented in this chapter, supports the readability of scientific and technical papers. (p. 130)

If only we could apply exactly the same rigorous standards to our Wikipedia articles as BIPM seeks to impose on "scientific and technical papers". But we cannot. Journal articles are written by professionals, and are subject to rigorous review and editing before coming under the glare of public scrutiny. We simply cannot match that standard, and must therefore compromise. There are alternative ways to deal with all this. When I have reason to believe that we can look at the matter dispassionately and flexibly, I may well offer a suggestion or two.

If on the other hand you and other editors think that adherence to those draconian standards will magically evaporate all our concerns, I look forward to MOSNUM and MOS including BIPM's firm and unequivocal requirement that sans-serif fonts be used for dimensions – strangely not reflected in our guidelines. Surely we must require markup to impose sans-serif in dimensional analysis, yes? (There's probably some template somewhere, but how can we know such things?)

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 06:50, 13 March 2008 (UTC)

OK, let's step back a bit from this. I recognize that your comments about NIST's inconsistent use of italics were motivated by Gerry Ashton's use of a single unitalicized L to support his argument. I agree with you that that was a poor and insufficient example. Clearly an unitalicized "mention" of a unit symbol proves nothing without evidence of consistent use of italics for mentions in other cases, and you have shown that is not the case. I disagree, though, with the apparent attempt to imply that NIST's inconsistent use of italics for mentions says anything about the merits of their opinion on SI typography standards.

I'm not sure if there are still worthy points you have made that I haven't responded to. This discussion is rather long and unsequential. I have responded to a rather good point you made, above. I'll respond to other things as I find them.

Regarding page numbers, note that I was working from HTML versions of most of these documents, and that I provided links. In most cases the links go to short web pages containing a small section of text; less than one printed page. In other cases I cited section or chapter numbers, which should be sufficient because the sections are shorter than one page, and are preferable because pagination can change when material is reprinted or transferred from one medium to another.

About the "selective quotation": I stand by what I wrote. Material quoted from the BIPM document is in quotation marks. Material I wrote is not. I do assert that it was BIPM's intent to imply that unit symbols follow different rules from English prose because they are mathematical entities. They make the comment about unit symbols being mathematical entities in the context of discussing why they do not obey other normal rules such as pluralization or periods for abbreviations, but I feel the principle applies just as well to the issue of why they are not italicized for emphasis, etc.

I see what you are getting at about the distinction between a scientific/technical journal and Wikipedia. Perhaps there is some room for compromise. The MoS should, however, definitely say that unit symbols are (normally) to be in Roman type, since this is a requirement of the SI standard. (For simplicity, Wikipedia should apply the same rule to non-SI units.) I also strongly feel that, independent of the general policy on italicizing symbols for emphasis or to denote "mention", the unit section in the MoS should be rewritten so as not to require any symbols to be italicized. This will avoid confusion on the part of editors who might assume that these symbols should always be entered in italics, based on the examples in the MoS.--Srleffler (talk) 04:13, 14 March 2008 (UTC)

Srleffler, thank you for your thoughtful recognition of, and reply to, some of the points that I have made. I would dispute some of the details, but there is no need to press any of that. I think we might come to agree on essentials. I have applied a dispute tag to the relevant section at WP:MOSNUM, and to the corresponding section here, but just to alert editors to the disparity between those, and to the fact that we are working towards a solution here.

Often there are opposing forces affecting our guidelines, and this is one such case. I have a couple of ideas that might help alleviate the stress those forces induce. We should really be looking at different fonts at MOSpages, for all sorts of short examples. And we should, I think, more often use new lines for longer examples, separating them from maintext rather than relying on italics or quote marks (which can bring their own problems). A simpler version of such practice could be generalised to mainspace articles, with modified guidelines for quoting certain sorts of technical matter. And then, perhaps there will remain some innocuous cases in which uniform italicising will be the best solution.

And we should keep all of that simple!

Give me a little time to read through all of the above once more, and to think about it. I might then put forward a compromise proposal, OK? Or you might have something in mind before I get there myself.

Collegially,–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 06:52, 14 March 2008 (UTC)

Romanisation

I have encountered at least ten mentions of romanisation on this page so far, and yet nobody has seen it fit to explain what exactly romanisation is in this context. Although I have a vague idea, I do not really trust myself to draw accurate conclusions in such matters. Waltham, The Duke of 03:07, 13 March 2008 (UTC)

Romanisation is giving a Latin-alphabet version of text that is originally in another script. We normally speak of romanisation with Chinese and Japanese. When the source script is alphabetic (like Greek or Russian), we normally use the narrower term transliteration. Whether our articles mark this distinction adequately is another matter.

I suppose some people might use romanisation in the sense of de-italicising, since normal, non-italic styling is called roman. SOED gives this definition, at "Roman":

3 (Now usu. r-.) (Of printed type) of a plain upright kind resembling that of ancient Roman inscriptions and manuscripts, esp. as distinguished from Gothic and italic; (of handwriting) round and bold. E16.

But given the more established meaning associated with transliteration, it is better not to use romanisation in this alternative way.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 03:21, 13 March 2008 (UTC)

Waltham: I did a computer search with my browser and found neither romanisation nor romanization. Can you give a searchable example? --Gerry Ashton (talk) 03:12, 13 March 2008 (UTC)

I think our noble young colleague is licensing himself to nominalise for convenience. The noun romanisation does not itself appear here. I'm glad he asked the question, though. Good for us all to be accurate with our terms, and to have an occasional reminder.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 03:25, 13 March 2008 (UTC)

(de-indent) Thank you for your quick reply. I was obviously asking about the alternative version, as you cannot really have expected me not to have looked for the Romanization article before asking here (although one can expect anything from Wikipedians). As you were all talking about Latin, which is already using the Latin alphabet (any surprises there?), the basic definition looked simply irrelevant in this case.

By the way, sorry about the confusion, Mr Ashton; if you had happened to look, the last mention of the term (in a different form, obviously) was in the message immediately preceding mine. Waltham, The Duke of 13:47, 13 March 2008 (UTC)

Noetica's reference to the SOED is helpful, that does give some support, but Gerry brings up an interesting point. In the Wikipedia entry on Romanization, and in the first 3 pages of a Google search on the term, including all the online dictionaries I usually use, there is no hint that it means "de-italicize". The 5 thesauruses I looked in didn't give a single antonym for "italicize" (other than things like "de-emphasize"). So, I'm stumped. - Dan Dank55 (talk) 20:31, 13 March 2008 (UTC)

The Online English Phrase Checker is quite good for this type of search:

• with the s; and
• with the z. Tony (talk) 01:40, 14 March 2008 (UTC)

The question is "How widely is the term used with the alternative meaning?" Perhaps the Wikipedia article should include a note, or at least the Wiktionary entry, in which case a box linking to it ought to be added in said Wikipedia article. Waltham, The Duke of 14:58, 14 March 2008 (UTC)

Non-breaking spaces

In the current version of this MOS page there is a section called "Non-breaking spaces" that talks a little about how to handle line wrapping. We now have a detailed technical how-to guide about line wrap handling at Wikipedia:Line break handling.

I would like that the section "Non-breaking spaces" of this MOS page in some way link to Wikipedia:Line break handling. Perhaps as a "see also" link at the top of that section?

--David Göthberg (talk) 23:01, 12 March 2008 (UTC)

That Wikipedia:Line break handling is a very welcome development, David. I agree: it should be linked from WP:MOS, and also from WP:MOSNUM. I think a "see also" is most apt, rather than a "main article" link. At this stage, the new page focuses more on technical matters, and does not fully address issues of usage.

Have you made the standard shortcuts yet for Wikipedia:Line break handling, and for its talkpage?

All of this will help enormously when the discussion of ,, as markup for the hard space gets back to full speed.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 00:11, 13 March 2008 (UTC)

Yes, as the shortcut box says on Wikipedia:Line break handling it has the shortcut WP:NOWRAP. And now that you mentioned it I fixed so its talkpage has the shortcut WT:NOWRAP.

"... does not fully address issues of usage"? Oh? I would love if you could elaborate on what you mean by that on the talk page of the how-to guide.

--David Göthberg (talk) 01:40, 13 March 2008 (UTC)

Ah yes, good to see both shortcuts deployed.

All I meant by ... does not fully address issues of usage is that the page is so far about how to force or prevent line breaks, not whether or when to do so, except what is implicit in examples. (See how I contrasted usage with technical matters, above.) That is in no way a negative! MOS and MOSNUM have so far had to give guidelines on both questions; but they will not have to do so much any more, since the new page deals very well with the question of how.

We could extend WP:NOWRAP to cover all of that, of course. Not a bad idea! Was that your ultimate intention? The wording at the top all points to confining the page to methods.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 03:10, 13 March 2008 (UTC)

Right, when I wrote the how-to guide I tried to stay away from almost all the style issues and stick to the technical issues. The big reason was that it was more pressing to explain the technical issues and advertise the how-to guide in all the relevant places, since I see that people do lots of technical mistakes in their wrapping handling.

But yeah, the other reason was to avoid controversy. For instance I did not mention the main case where I like to use two empty lines (between the last article text row and the first navbox) since I know that is controversial.

But I guess we could add a section with less controversial wrapping style advice and style examples to the how-to guide. Like I don't think it is controversial to state that formulas and equations should be completely surrounded by {{nowrap begin}}+{{nowrap end}}. Off course that can already be inferred from the 2+2=4 and |2|<3 examples and also from the Manual of Style, but I guess it wouldn't hurt to state it more clearly.

--David Göthberg (talk) 04:12, 13 March 2008 (UTC)

An ally, finally. I have long now been using two empty lines before succession boxes or, in their absence, article series boxes. I once tried to bring the subject up in the Village Pump, but the ensuing discussion did not last long. There didn't seem to be any real disadvantages to this practice, from what I remember, but you know how these things are... I hope we can co-operate in the future in order to take this idea one step further. Waltham, The Duke of 14:20, 13 March 2008 (UTC)

David, your involvement in both the non-breaking space issue (shortcut for it) and the MOS project would be greatly appreciated. Tony (talk) 14:32, 13 March 2008 (UTC)

Since no one protested I boldly went ahead and added "See also: Wikipedia:Line break handling and Wikipedia:Manual of Style (dates and numbers)#Non-breaking spaces" to the top of the "Non-breaking spaces" section.

Waltham: Yeah, unfortunately most people seem to dislike "air" in texts, web pages and source codes. After studying lots of people when they read pages I have come to this preliminary conclusion (and I am not joking): They seem to not have enough motor skills to click and drag the scrollbar with enough precision, thus they have problems scrolling a page at a time. I guess that is why scroll wheels have become so popular, although the scroll wheels are slower so then lots of air is annoying to them. And most users of course have never learnt to use the keyboard to scroll or page down. So you and I perhaps have to accept that people want as much text as possible squeezed together on each screen full.  :((

Tony: Yes, I have done a lot of work on line wrapping here at en.Wikipedia the last year so I like to share my knowledge.

I think I migth do a work over of the "Non-breaking spaces" sections at WP:MOS and WP:MOSNUM some day. (I will of course first discuss my changes at these talk pages before I actually do them.) Now that we have the technical how-to guide Wikipedia:Line break handling to point to we might be able to shorten the "Non-breaking spaces" sections to mostly contain style recommendations. Perhaps we should change the title of those sections to something like "Line wrap handling"?

--David Göthberg (talk) 16:04, 13 March 2008 (UTC)

Perhaps you are right about the "air"; people tend to be this ridiculous. However, all we are talking about is a single space at the bottom of the page. Surely they will not object to that on such grounds?! It is one lousy row, and half the readers won't even get to reach that part of the article. I certainly don't think we should lose hope; after all, it will improve the appearance of articles, which, as has been mentioned, is becoming increasingly important. Waltham, The Duke of 16:33, 14 March 2008 (UTC)

Images

I swear not long ago it said to avoid stacking images in a row on the right (one on top the other). Was this removed, or is it simply in another guideline/policy? VanTucky 00:57, 13 March 2008 (UTC)

I see Wikipedia:Picture tutorial#Avoiding image .22stackups.22. -- SEWilco (talk) 04:36, 13 March 2008 (UTC)

Would anyone be opposed to adding this to the guideline then, since it's already a part of the tutorial? The text I'm thinking would say (verbatim): Avoid stacking images directly on top of each other. This can can conflict with the readability of the text. VanTucky 18:33, 13 March 2008 (UTC)

Observation

I suppose there was a reason, long ago in the Paleozoic era of Wikipedia, that these little discussion-subworlds came to be known as "talk" pages. As I look at many of them, especially within documents like the MoS that are intended simply to guide editors in the creation and improvement of this project, there seems to really be little more than...talk.

For instance, as I add these words, this (apparently well-named) "talk" page is bordering on 395 kilobytes in size. The cursor is literally pausing as I type, even at cable broadband speeds, because it's struggling to keep up.

Is there something wrong with simply discussing a problem or query, coming to consensus (or determining that it hasn't yet arrived) and just moving on? For those who will say that this page just needs to be archived, I think that misses the point. Remember, we're at 395 kilobytes in just about three months. When actual articles (the reason we're all here, right?) are mandated to stay under 30K, that seems very counterintuitive.

And for those who apparently enjoy seeing their words (all of them, it looks like) in print on the screen, I'd suggest working on improving articles rather than spending an evening debating the finer points of how to render obscure Latin phrases or whether some bit of English punctuation will conflict with usages in Catalan. Honestly, it's more satisfying for me to have actually created something in the end.

Thanks for hearing me out; now feel free to grapple over which dictionaries and style manuals are or aren't regarded as canon. Meanwhile, I'll be somewhere else in the wiki-ether, improving my craft and editing others' as well. Duncan1800 (talk) 06:39, 13 March 2008 (UTC)

At first I thought I should just remove this useless rant. Obviously the only reasonable response is "so don't hang out here". The problem is not that there is too much discussion here; the problem is that the scope of the MoS is too large and this single page doesn't really meet the discussion needs. The scope of the MoS and the associated talk pages should be partitioned. Nohat (talk) 07:20, 13 March 2008 (UTC)

...and therefore Duncan1800, Nohat, and all other editors with a view concerning the role of MOS and other MOSpages are encouraged to sign up at WP:MOSCO, and to have their say on these important issues at WT:MOSCO.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 08:47, 13 March 2008 (UTC)

I second Noetica's suggestion. Please see the proposal for the systematic auditing of our uncoordinated tangle of MOSpages; volunteers are urgently needed to end the chaos by reportage and discussion at MOSCO. And yes, this talk page needs to be archived more often. Tony (talk) 09:11, 13 March 2008 (UTC)

I third the suggestion, if there is such an expression. I intend to start helping out with the assessment myself within the following days. A note to Nohat: the rant is perfectly in the spirit of this page, as demonstrated (in the rant itself), so your removing it would have resulted in a series of unpleasant legal threats on my part. Thank you for reconsidering. :-D Waltham, The Duke of 14:07, 13 March 2008 (UTC)

I fourth that, forthwith, and I'd also like to put a positive spin on Duncan's position. I look at the backlog at WP:GAN, and see Version 1.0 coming fast, and I really wish that all these incredibly talented people didn't need to spend so much time here. There's so much to do and so little time. But, it's all about the journey, and I concur with the optimistic tone in these replies that things really are getting done that will help avoid conflict and confusion in the future. - Dan Dank55 (talk) 19:30, 13 March 2008 (UTC) P.S. Note that I'm sucking up to everyone at once, which is completely acceptable, and completely unlike sucking up to Raul, as Giano does here (fnord). - Dan Dank55 (talk) 20:00, 13 March 2008 (UTC)

Note for the postscript: If you want us to stop taking you seriously, you're trying too hard. (evil grin) Waltham, The Duke of 15:21, 14 March 2008 (UTC)

default thumb size of images

Is it fair for someone to go around removing a custom size of any image they find? They keep claiming this page states they are right, but as far as I can tell, the standard thumb size is simply the default preference, and is not a rule to be rigidly followed. Thoughts? Timeshift (talk) 00:31, 14 March 2008 (UTC)

It's a guideline and not a policy for a reason. The "don't force thumb size" rule can be ignored if there is a compelling reason. VanTucky 00:44, 14 March 2008 (UTC)

I note the term "not recommended" was recently changed to "not necessary" the reasoning being that a number of FA's already have set pixel size. That’s like not making seat belts in cars mandatory because many cars don’t have them.--Merbabu (talk) 00:56, 14 March 2008 (UTC)

So it's not cast in stone despite some editors beliefs that it is? Excellent :-) Timeshift (talk) 00:57, 14 March 2008 (UTC)

Correct - "if there is a compelling reason" it can be ignored. But, remember the guideline is there for a number of good reasons. --Merbabu (talk) 01:09, 14 March 2008 (UTC)

Indeed! But thanks for shifting the goalposts, at least now you won't just be blindly removing custom image sizes without discussion first :-) Timeshift (talk) 01:16, 14 March 2008 (UTC)

Incorrect - I don't "blindly remove image sizes" and I see no need to change the way I approach it. If anything the onus is on those going against the MOS to establish "compelling" grounds to do so, especially when this leads to images making certain articles look awkward for readers with smaller screens and/or higher font sizes. If you want higher image sizes for your own reading, change your preferences (which of course one can't do if pixel size is specified). --Merbabu (talk) 01:26, 14 March 2008 (UTC)

Not at all - MOS is a guideline not a policy, and if someone (note the minority, you) has a problem with it, it is up to them to gain concensus. Thankyou :-) Timeshift (talk) 01:30, 14 March 2008 (UTC)

This is getting off the topic but if I'm the "minority" who is the "majority" - you perhaps? Again, you don't seem to understand *why* there is a preference for these image guidelines, nor specifically why your insistence on going against the guideline (without compelling reason i might add) is a problem on the Brendan Nelson page. --Merbabu (talk) 01:39, 14 March 2008 (UTC)

You are the only one that wants to change it. I want it kept at a larger size, and nobody has disagreed with me, and kept the status quo. Nobody agreed with you on the BL talk page. Thus, as the images are at the non-default and only you want to change it, yes, you are the minority, and by default I am the majority. I've already given my reasons for a larger size on the BL talk page. Let's get this clear - to change something from the status quo that is disputed, you need consensus. You do not have consensus. Is that clear enough for you? Have a good day :-) Timeshift (talk) 01:42, 14 March 2008 (UTC)

Another unclear but significant change

We discussed this once, but it's lost in archives. WP:MSH is a much used shortcut for proper section headings, and I'm suddenly seeing errors and confusion all over articles again, so I came over here to see what happened, and lo and behold, another example of long-standing wording that seems to have gone missing again. What happened to:

Avoid restating or directly referring to the topic or to wording on a higher level in the hierarchy.

When did it get deleted, why, and where is the discussion?

Months ago we had a clear WP:MSH section which explained: 1. Don't use "a", "the", etc. 2. Don't repeat wording from a higher level 3. Capitalization of first word only, yadda, yadda ...

A lot of that got merged into the top of the article, and lost from WP:MSH. Even though it's still linked, people don't see it. Further, the business about repeat wording is now completely gone, so section headings are showing up a mess. Can someone point me to the discussion that resulted in dropping the business about repeat wording ? The section just is not clear any longer, and not effective. MoS needs to have a monthly digest of changes made, or risk becoming obsolete as people stop trying to keep up. SandyGeorgia (Talk) 02:33, 14 March 2008 (UTC)

• I really think the same old issues should not be stamped out twice in full within the space of three subsections at the top of MOS. That was the reason for the rationalisation and, thus, the cross-references between the Article and Section Heading subsections. I've copy-edited and strengthened the cross-reference; but why not make MSH link to the top subsection instead? Tony (talk) 03:09, 14 March 2008 (UTC)

• That issue continues to confound, but why/when did we lose the sentence about not repeating words? As I refer editors to WP:MSH, I'm seeing they're not comprehending, and now I see why. SandyGeorgia (Talk) 03:26, 14 March 2008 (UTC)

• The fact that the content behind these shortcuts is subject to change at any time is a good reason to use them infrequently. See Wikipedia:WTF? OMG! TMD TLA. ARG!. Christopher Parham (talk) 03:14, 14 March 2008 (UTC)

• Not relevant; whether you link to the acronym or the actual section heading, the problem is the same. SandyGeorgia (Talk) 03:27, 14 March 2008 (UTC)

• But but: the "Avoid restating" point is there:

* Avoid restating or directly referring to the topic or to wording on a higher level in the hierarchy (Early life, not His early life).

Tony (talk) 03:35, 14 March 2008 (UTC)

Archiving this elephant

That was getting ridiculous: I've just archived 236 Kb, at Wikipedia talk:Manual of Style/Archive 97, leaving 185 Kb here. Tony (talk) 09:21, 14 March 2008 (UTC)

According to the request at the top of this page, MiszaBot archives after 20 days. -- SEWilco (talk) 13:33, 14 March 2008 (UTC)

Thanks, but 400+ Kb is too much. Tony (talk) 14:11, 14 March 2008 (UTC)

There appears to be a certain problem with the organisation of the archiving process for this page. Archive 97, you said? The directory listed the contents of archives up to number ninety-four. (I have already fixed that, but it does show a lack of attention.) Furthermore, Archive 96 was only 88 kilobytes in size while the previous ones range from 250 to 400 KB. I have thus moved the entirety of the contents of 97 to 96, leaving the former empty for the next archiving (with the template at the top, which was missing).

As thematic archiving is not an issue here, I suggest that we should specify a standard size for the archives. Furthermore, if nobody objects, I shall add an archive navigation template at the top, under the archive template, and add a second archive template to the bottom. This will make the archives more navigable and is consistent with current practice and the suggestions in WP:ARCHIVE. I have applied this to Archive 96, as a sample for the esteemed editors to comment on.

PS: I've just got wound of the exitstence of {{talkarchivenav}}, which combines {{talkarchive}} and an automatic variant of {{archive-nav}}; we could use that instead of the two last templates for the top of the pages, although I don't have a clear preference. Waltham, The Duke of 16:23, 14 March 2008 (UTC)

Thanks guys for archiving this elephant. It was getting slow to load even on my 2 Mbit/s ADSL connection...

--David Göthberg (talk) 16:42, 14 March 2008 (UTC)

Em dash

"Em dashes are normally unspaced on Wikipedia." Lately I have defended that position twice at WP:ERRORS, but the rule as written is a bit silly because it is false as written - by my count spaced em dashes are about twice as common as unspaced em dashes. If it's a good rule, then it should probably say something more like "Em dashes should be unspaced on Wikipedia." Art LaPella (talk) 23:51, 14 March 2008 (UTC)