User:Noetica/ActionMOSVP/Archive2

Let's try to keep the above table clear; feel free to bend my initial advantages/disadvantages slightly, by definition, the (dis)advantages I listed are subjective.

I'll clarify the meaning of some of my terms:

Intuitive

The characters somehow 'look' or 'feel' like a space.

Intrusive

Since they represent a space, I feel that the characters should not be too 'big' in the source text and attract too much attention. Additionally, a single character is better than multiple characters.

Easy to type

It would be nicest if we can use a single character found on the keyboard, or two identical ones; alternatively, e.g. `~ uses a single key twice, unshifted and shifted.

Used in wiki syntax

Some characters, such as _ and ~, are already used in MediaWiki syntax; others, like `, are used in other wiki syntax. This could cause problems.

Phaunt (talk) 11:20, 12 December 2007 (UTC)

Voting table, new markup for the hard space.

The vote has now ended. See the final results by clicking on "show", above. Ten editors voted; none changed or removed votes; some did not express all three preferences. Here is a summary of voting for each option:

Option 1 ( `` )

3 second-choice votes x 2 points (= 6)

3 third-choice votes x 1 point (= 3)

Total: 9 points

Result: eliminated

Option 2 ( `~ )

2 second-choice votes x 2 points (= 4)

1 third-choice vote x 1 point (= 1)

Total: 5 points

Result: eliminated

Option 3 ( ,, or ,,, )

8 first-choice votes x 3 points (= 24)

1 second-choice vote x 2 points (= 2)

Total: 26 points

Result: clear winner

Option 4 ( {{s}} )

2 first-choice votes x 3 points (= 6)

2 second-choice votes x 2 points (= 4)

4 third-choice votes x 1 point (= 4)

Total: 14 points

Result: clear second choice

[I suggest that we briefly discuss the outcome of the vote. It seems pretty clear to me, but perhaps an editor may think some angle has been neglected, or some option has not been dealt with adequately. Let's deal with that quickly; then we can start developing the details of a proposal.–N– Noetica^♬♩ Talk 08:36, 7 January 2008 (UTC)]

The clear winner has two forms: ,, and ,,,. Having thought it through, I believe that ,, is the obvious choice, for all sorts of technical reasons. Does anyone disagree? I can explain in detail if necessary. (Or someone else might.)

– Noetica^♬♩ Talk 08:36, 7 January 2008 (UTC)

An option which I don't think has been mentioned is having the regular   added into to "Wiki markup:" list below the edit box. It would have the advantage of saving typing without introducing any new code. On the other hand, ,, is shorter (an avantage when writing templates where pre-expand size is a concern). Jɪmp 09:03, 7 January 2008 (UTC)

I believe it has come up briefly (you might want to check the archive). The problem with this solution is that it disrupts the text flow in the edit window, making it harder for editors to comprehend its contents. The edit window is supposed to be easily read as it is, and this is why intrusiveness is one of the major markup choice criteria. Despite their usefulness and the fact that hard spaces are meant to be used quite extensively in Wikipedia (according to the Manual of Style), their spread is sadly limited. An easy-to-use markup that does not mystify most editors will certainly help the propagation of hard spaces, and correspondingly improve the layout of Wikipedia's articles.

By the way, my preferences lie with the two-comma solution. I have only proposed the three-comma option because there might be objections about the elevated danger of typos with such a heavily used key as the comma. I myself find this danger negligible and definitely inferior to the advantages of the double-comma solution.

Oh, have I mentioned? I am very content with the poll's result. ;-) Waltham, The Duke of 10:03, 7 January 2008 (UTC)

Good points. Yes, the double comma is the best of the options given. If adopted, I'll be using it. Jɪmp 00:02, 8 January 2008 (UTC)

[Moved to this subsection.–N]

I haven't seen an argument against asking the techs to do what is commonly done these days in newspapers and magazines, implementing a list of rules for hard spaces without markup (usually). We have already mentioned most of the rules; it's not that hard to list them. We could still use an occasional ",," in those cases where we think an exception to the rules is appropriate. Can someone give me a reason why the question shouldn't be asked? - Dan Dank55 (talk) 02:45, 10 January 2008 (UTC)

Dan, that is hardly an objection to the proposal for the ,,-markup. But I suppose it could conceivably weaken the case for it. Myself, I don't think insertion points for hard spaces should be automated, or put it in the hands of "the techs", even if this were feasible. With all due respect to them, they have ignored the hard space problem all this time. And when we finally got a button for   under the edit box (very recently; see #Other discussion), this was done out of the blue and without visible discussion.

In fact, the question of where to insert hard spaces is not trivial, and any algorithmic solution would need to be supplemented by human decisions (as you admit, Dan). To enable this, we would still need to see clear markup in the edit box, yes?

There. Now you have an argument against, as requested.

– Noetica^♬♩ Talk 08:06, 10 January 2008 (UTC)

"That is hardly an objection" sounds like you're surprised...you shouldn't be, I think I've demonstrated that I support the desire of everyone here to get easier markup, and I support the process. I think "it could conceivably weaken the case" is right, which would be a shame. No matter what else happens, you have all convinced me that prolific editors have different needs from the large majority of occasional editors, and so I now prefer a user-toggle-able edit screen, as I mentioned earlier, but I don't know if we can get it. ",," would be ideal for the "experienced" editor screen, and since we wouldn't be making the newbs learn new markup, that would take away the strongest arguments against it at WP:VP. One thing you said I don't understand at all...that proper line-wrapping _shouldn't_ be automated. I understand that we don't expect to get it, but are you saying that all the major newspapers and magazines are somehow making a mistake by automating proper line-wrapping rules (with occasional correction by copy editors, I assume, when the rules are wrong)? What would be the advantage to forcing all the copy-editors at Newsweek to insert hard spaces by hand into "p. 1"? - Dan Dank55 (talk) 13:20, 10 January 2008 (UTC)

Line breaking in newspapers normally includes syllable breaking as well. There is an essential difference between newspapers and the net. In a newspaper the final layout is fixed. In a browser, you never know how wide the user window is. So the line breaking needs to happen on the user's computer. That would necessitate to indicate all the places where a break may occur, including all syllable breaks. There is no practical way an editor could check all that. −Woodstone (talk) 13:34, 10 January 2008 (UTC)

Right, which is why automating it (again, with keen-eyed editors watching for exceptions) is more important on WP than in newspapers...more time saved, because there's more to check. - Dan Dank55 (talk) 13:52, 10 January 2008 (UTC)

The keen eye watching for exceptions must know where the automated system intends to allow line breaks. How would you display to the editors all those possible breakpoints in a line, including syllable breaks? There will be dozens on every line. You seem to underestimate the complexity of syllable breaking, which is language dependent. There will always be quite a few mistakes in an automated analysis, especially in an encyclopedia, full of unfamiliar words and snippets of other languages. −Woodstone (talk) 14:09, 10 January 2008 (UTC)

If I suggested syllable breaks, I didn't mean to, we're talking about hard spaces. My preference would be a user-toggle-able edit window with ",," in the "experienced editor" window showing the places where the system has automatically inserted hard spaces when the edit was done. Dank55 (talk) 14:22, 10 January 2008 (UTC)

That comes closer to feasibility, but there are still issues to be solved. How would you register deviations form the automated spacing. The experienced editor may add or remove system proposed hard spaces. How do we prevent that the system will undo those decisions every time casual editors save their edit? We would somehow need different codes for auto-no-break, editor-no-break and editor-allow-break. It may generate more complexity than it solves. −Woodstone (talk) 14:38, 10 January 2008 (UTC)

I'd be happy to leave that up to experienced editors to vote on. It seems to me we could easily get the simple rules (p. #, pp. #, etc) to work at least 99% of the time, and in that case, I would personally prefer to see either of two solutions: something relatively invisible (such as perhaps the unicode for nobreak space) 99% of the time and ",," in the exceptional cases, or ",," 99% of the time, and something more intrusive in the exceptional cases, such as "{{nowrap|}}" or " ". - Dan Dank55 (talk) 16:15, 10 January 2008 (UTC)

Might work. −Woodstone (talk) 16:26, 10 January 2008 (UTC)

Okay, very good news, I think. #wikia (one of the channels where I have been hanging out for a while) is different in a variety of ways from #wikipedia...one way is that we chat with techs just about every day, including the ones from Poland who can take down Mediawiki by breathing wrong (and often do :). One guy who doesn't want to be quoted was willing to answer my question in the negative: "Would preprocessing-rules that add some appropriate no-break spaces, for instance in 'p. 1' and '10 AD', whenever someone hits the edit button, be more of a drain on system resources than editing and re-editing pages by hand to add no-break spaces where we think they're needed?" If this opinion is supported by other techs, that's particularly great, I think, because it means that, even if we don't succeed in getting user-toggle-able edit windows, we still have one bulletproof argument over at WP:VP (and I'm not saying you do want this or should want this, I'm just saying it's important to have at least one bulletproof argument): if almost all hard spaces are unicode hard spaces, with the exceptions appearing as ",,", then it will be very hard for people to say that ",," will frighten anyone away. He suggested that I make a post at bugzilla.mediawiki.org if I want to get an "official" answer...does anyone have a problem with that, or does anyone want to suggest wording other than the way I asked the question above? I'm guessing the shortest, least offensive question possible would be best. I'll add in the request that I'm not asking anyone to commit to anything, just trying to get technical information so that the argument at WP:VP doesn't proceed in the dark. - Dan Dank55 (talk) 18:46, 10 January 2008 (UTC)

Now discussing the case that there is only one form of the edit panel. A great majority of spaces in the text will be soft spaces. So that has to look like a normal space. As said above, to enable checking by the experienced editor, the automatic insertions and the deviations from it must remain visible. So the inserted hard spaces must be visible. Can be by showing them according to the above as ,,. Possible corretions by the editor that must be preserved are:

• remove an incorrectly inserted hard space; e.g. there is a "p.1" that is not a page number; it was modified into p.,,1; the editor can change it to {{nowrap|p.1}}; the automatic spacer should ignore everything in the nowrap template; it works, but the meaning is quite counterintuitive.
• replace an incorrect hard space by a soft space; e.g. a sentence ends with "p." and the next starts with "1"; can be done by inserting &#x200B standing for a zero-width normal breaking space; it works, but is hardly understandable.

Are there more cases? Anyway, we must find a better solution to make this acceptable. −Woodstone (talk) 19:32, 10 January 2008 (UTC)

I agree that we will always want to be able to replace a regular space by a hard space, using the markup we choose, without worrying that we'll get 'reverted' by software. The argument in the other direction seems less critical. Are there really any cases where we absolutely must not have a hard space, where it will be really distressing if "p. 1" is forced not to wrap? And even if there were, couldn't we just amend the software rules then so that there won't be? - Dan Dank55 (talk) 19:44, 10 January 2008 (UTC)

More good tech news. Jesús Martínez points out that Mediawiki _already_ converts spaces to   before punctuation, and he doesn't see how adding more rules would be that difficult. - Dan Dank55 (talk) 20:14, 10 January 2008 (UTC)

• Okay, I agree with Noetica that the back-and-forth has been very useful. On the other hand, we all have lives. Let me see if I can summarize the consequences of everything I've seen today into one post:
• I have been told today by one paid staff and several admins at Wikia that they feel strongly about the issue of keeping markup just as "clean" as possible, so that new editors are not confused. (They will certainly be weighing in at WP:VP.) They understand that we insist on proper markup including hard spaces, but they really want it to be invisible to the casual user...at least, by default, even if we have to insert exceptions by hand. Obviously we haven't been discussing Wikia here, but also obviously, anything that affects Mediawiki potentially affects them as well.
• When I put this together with what I heard from two techs and my ongoing discussion with Woodstone, here's what I come up with for a "proposed proposal" to WP:VP. We say, politely but firmly: WP:MOS requires hard (i.e. nobreak) spaces all over the place (we give examples), and this appears to be a settled issue, in part because WP is now also distributed on DVD and in print, and everyone expects proper line-wrapping in a printed encyclopedia. Unfortunately, because   is long and hard to remember, and lots of people don't know proper markup, it's missing on most WP pages, even though it's official MOS policy. A bunch of editors have decided: we're not going to accept slackness on this issue any more. We are now patrolling for and inserting hard spaces.
• Now, we don't like the extra work ourselves, and we anticipate that there are two groups of people who may have a problem with this, and we have thought about your needs and we have something to offer you. The techs may feel that this campaign is just a lot of extra editing without a lot of gain that may slow down the servers. You have an easy solution: we can give you a specific list of rules for when hard spaces are appropriate (p. #, # AD), and you can have Mediawiki insert   automatically when people hit the "save" button. One of the techs has told us that this conversion already happens in Mediawiki for spaces followed by punctuation, so this would just be adding a few extra rules to the rule that you have already. This would be just a little more work than the servers are doing now, and less work than they would be doing to keep up with all the editing we'll be doing if the change is not made.
• The second group of people who may have a problem with this, understandably, are relatively new editors, people who really don't want to read markup rules before they get started. That's why we propose that (invisible) hard spaces be inserted automatically, in most cases. Keen-eyed editors will still need to go in and insert hard spaces manually for those cases that don't fit the rules, but usually, the rules will work, so we're actually doing a big favor for the newer users here, keeping stuff they don't understand like   out of most of the text.
• Now, in return, some of the high-volume editors would like to ask for a favor...for us and for everyone else too. Please remap ",," in the edit window to also code as a hard space (for new edits, you don't have to search existing pages). It would help us to do our jobs if we didn't have to type cumbersome strings like   for something as simple as a hard space that's been overlooked by the rules, and it would really help us to get new people on board with respecting rules for the hard space. We understand that typographical changes are slow to happen around here, but we respectfully ask you to notice that we are putting in a lot of time trying to pretty up WP, and it would be a very nice and appropriate gesture if you allowed ",," to work, which we agree unanimously is easier on our eyes and our fingers than current markup.

Okay, how does that sound? - Dan Dank55 (talk) 21:50, 10 January 2008 (UTC)

It does not seem to be a summary of the discussion. The whole point was that   is very intrusive and makes reading the text awkward, especially for novice editors. Therefore we would like the hard spaces to keep being displayed in the edit panel as ,,. And this should be accompanied by some measures to allow a permanent escape from the automatic insertion. −Woodstone (talk) 23:06, 10 January 2008 (UTC)

Right, I didn't mean for that to stand on its own, I meant for that to be a reflection of my approach given what I now know about what we're going to face at WP:VP. I'm only one person here, you can mix and match my approach with other points that have been made here in any way you like...and I hope you will. It was already long enough, time to let other people weigh in. - Dan Dank55 (talk) 23:26, 10 January 2008 (UTC)

Feel free to amend this section heading to something more suitable and remove this notice

Before we write the proposal proper, shall we first list some criteria we feel it should meet? Phaunt (talk) 12:41, 7 January 2008 (UTC)

[Contents of "Explaining necessity and addressing common criticisms" is now moved to #Objections and replies.–N]

While defining the specific mark-up for hard space, we should keep an eye open for extensions. I would like to consider including some more special symbols. For example we might define:

This... This is big. I think it is beyond the scope of this page to propose the adoption of markup for all these characters, but... Well, I don't know. In any case, it seems to me that we can confidently dismiss the following:

• The ellipsis is discouraged on Wikipedia altogether. For good reason, in my opinion; it does not display well (and I don't mean in the edit window).
• The zero-width space is similarly inadvisable. The simple line break makes it quite redundant in my opinion. And you can tell that it is just not used only by looking at its extremely complex syntax (I should have said "code" but it would ruin my sentence).
• The soft hyphen is another obscure character. Why should hyphenated words break when we have no word division practices in place? Either you break words or you don't.

Apart from these, there is the much-used line break, which, however, I feel is very-well represented by the short, intuitive, and moderately used <br />.

The hard space we are dealing with in this page. Which leaves us with...

The dashes. Honestly, I believe that the only problem with the Unicode versions is that it is hard to discern the difference between them (because there is a difference). Although I am not overly enthusiastic about changing that, I could hear some proposals (like this) for the dashes. But probably for nothing else.

Unless, that is, you can persuade me otherwise. (I can be bribed, too.) Waltham, The Duke of 15:14, 8 January 2008 (UTC)

Comments on the above remarks:

• Ellipsis: agree more or less
• zero-width space: just allows a break; if you have a very long word that may result in ugly layout, you can indicate preferred break points, without a hyphen being inserted (e.g. useful in long url's.). Especially useful in table cells and in languages that write no spaces between words.
• soft hyphen: since we have no automatic word breaking, very long words may result in ugly layout; you can indicate preferred breakpoints, where the browser will insert hyphens if needed. Especially useful in table cells.
• the dashes are much less obtrusive than the &xxxxx; codes; easier on the eye for the editor

−Woodstone (talk) 15:35, 8 January 2008 (UTC)

I changed the table to avoid confusion over the exact proposal for the no-break space. The choice for the zero-width space had to be moved out of the way. I also added the no-break hyphen that came up elsewhere in the discussions and moved the soft hyphen out of the way for it. Of course all these are just proposals for later detailed discussions. −Woodstone (talk) 23:48, 18 January 2008 (UTC)

[Text brought into the navbox:–N]

What's this hyphens nonsense. We don't even have hyphens that do break, so why would you want a "no-break" hyphen when that's all we have. And the soft hyphen you talk about is one that doesn't show up unless there is a break. Is there any way currently where we can get a hyphen that is visible, and which might break at the end of a line? If you want to push for a change, push for that; it's a hell of a lot more important than a soft, usually invisible hyphen. Gene Nygaard (talk) 04:40, 19 January 2008 (UTC)

Even more, how about em dashes that can break afterwards? En dashes? Gene Nygaard (talk) 04:41, 19 January 2008 (UTC)

Gene, I think these extensions are more to do with an idealised wishlist than a reflection of actual behaviour of hyphens and other entities as they are implemented in HTML. Note, incidentally, that the terms soft hyphen and hard hyphen are sometimes ambiguous, and that there is a third term: non-breaking hyphen (see Hyphen#Hyphens_in_computing.) Perhaps the terms have different meanings in traditional typesetting, in wordprocessing, and in online work.

It seems that late versions of IE and Firefox behave differently, which may explain the mismatch between Woodstone's and your assumptions here. The ordinary hyphen (-), ­, en dash, and em dash all break in IE; but none of these breaks in Firefox.

Please think about this before claiming that the table above represents "nonsense"!

I propose to archive this discussion soon along with other material that is not on the current agenda item. So I'll duplicate it at the talkpage, for any follow-up that is needed. But note: Woodstone's work on extensions shows admirably the sort of thing that could be done in future. That's all we need it to do.

–N– Noetica^♬♩ Talk 06:55, 19 January 2008 (UTC)

[No more discussion in this section, please: about to be archived.–N]

Proposal summary

Discussion of amendments to the summary

To be able to work on the proposal separate from discussion about it—I notice you added the tag "Version 1", and editing it here or posting version upon version seems like a horror when we have a perfectly fine versioning system in this wiki—I suggest we create another subpage just for the proposal summary. In fact, being bold, I did just that.

Now: on the proposal itself.

Globally: nice text! This is a solid basis we can work on. Thank you!

Comments:

• The text "[o]ur analysis shows that (...) is the best markup" seems a bit too assertive to me. Maybe reword it to mention that this is the result of a poll among interested Wikipedians?
• The same goes for "[o]ur research shows". I wouldn't really call this research. I feel we should name them for what they are: just some suggestions.
• Cosmetically: maybe use <code> tags instead of bolding? It's a bit too much bold to my tastes now.
• Also cosmetically: it could do with splitting into a two or three paragraphs.
• I suggested above that we add something of a FAQ, addressing common objections. I didn't get any response from other participants, but I myself still feel this would be a good idea. What do others think?

Regards, Phaunt (talk) 01:45, 10 January 2008 (UTC)

(Addendum: I could have edited the proposal itself, but it's way past my bedtime. Later. Phaunt (talk) 01:47, 10 January 2008 (UTC))

I have edited the proposal mostly for style. Tried to use consistently "quoted text" for text seen in the wiki artcle by normal readers, bolded text for the invisible HTML version, and fixed font text for text seen by editors in the edit panel. Toned down the research bit per above comment. −Woodstone (talk) 09:17, 10 January 2008 (UTC)

I like the proposal's working version as it stands now, but I have united the last two sentences of the second paragraph in an attempt to better stress the point and improve text flow. Waltham, The Duke of 15:42, 10 January 2008 (UTC)

Update: I have just noticed a redundant space between <b>bold text and </b> in the second paragraph. I have now removed it, but I am also considering adding a "respectively" after it. I don't know. Waltham, The Duke of 15:46, 10 January 2008 (UTC)

Sticking my nose in and expecting a reversion - I've made some changes that I would describe as strategic:

1. Don't say anything is "invisible", that could be scary - instead say it is converted on output, same as the q-q-italics-q-q are.
2. Enphasize its simplicity for the new wiki user, mastering the style for bold and italics leads to mastering this similar use of wiki markup. Possibly enhance to state that it is non-html-savvy-user-friendly.
3. At the very least, use a new paragraph to discuss all the other things this markup style could be used for. These are valid and wide possibilities but keep them separate from the main proposal, don't scare the developers and don't confuse those seeing this proposal for the first time. I've heard "too complicated" enough from my RL proposals, I would recommend the KISS method here.
4. To top it off, I've eliminated any description at all of possible further applications of the new markup method, Watson and Crick just said that the implications of DNA structure hadn't escaped them, they kept their paper nice and simple and let others fill in the blanks. Franamax (talk) 06:49, 16 January 2008 (UTC)

Welcome, Franamax! Great to see you here. Interesting points. What do others say?

–N

I agree. The extensions ought to be in a different paragraph. I also believe that too much detail about them is rather detrimental to the proposal's purposes, so I shall simplify the paragraph a little. Waltham, The Duke of 11:26, 16 January 2008 (UTC)

after e/c

I very much concur with your second point; I would also propose adding something to that extent to the second objection, in compontent 3 below (to supplement "hard to remember, hard to type, and hard to interpret"). The whole point of wiki markup is to be a level between the user and the cruel world of HTML; if we want hard spaces to be used as often as we advocate, it's inevitable that it be added to wikitext markup.

I think I misunderstand your third and fourth points; they seem contradictory to me. You want to discuss "all" other possible uses, and yet you want te eliminate any descriptions of possible future applications? Do you mean that they should go unmentioned in this first section, but must be included elsewhere? Phaunt (talk) 11:30, 16 January 2008 (UTC)

I'm trying to say, don't confuse the main objective with the many other possibilities this new markup raises. From the coding perspective, once you see the first comma, that is an "escape" character, just like ' or < or [ or & are characters that cause the following character(s) to be interpreted differently, you're in my territory now, it's not language, it's a sequence of 0's and 1's. The possibilities are endless - so say as little about those possibilities as you possibly can. Focus on the goal at hand. There may be wider implications to this proposal, I'm suggesting you will not be well served by presenting them all in your initial proposal, and I advise you to present as few as possible. Franamax (talk) 12:31, 16 January 2008 (UTC)

Rename component to "introduction"?

At this point, the component is no longer a summary of the entire proposal; not all points made in objections/replies are included, not all possible future extensions are proposed, etc. And I feel this is a good thing; but then, maybe we should rename it an "introduction", and precede it by a (very) brief abstract as I propose below? Phaunt (talk) 12:02, 16 January 2008 (UTC)

In my opinion, this is relatively unimportant. I mean, this name does not even appear in the box. In any case, there are two ways to look at it.

1. Theoretically speaking, it could be argued that it is not any more of an introduction than it is of a summary, because this part essentially is the proposal, the other three components functioning more as appendices: they support the proposal and delineate the provisions of its application should it be approved by the community (and the developers, probably, in view of the recent rollback hubbub).
2. We look at the relative size of the components, and the purpose of the box (which is to explain the proposal and, hopefully, rally support for it), and see that it does functions as an introduction, but not so much to the proposal per se, as to our argument in its favour.

Yes, you have just met the real Duke of Waltham: a great proponent of incessant ranting about more or less everything of interest (or not). Waltham, The Duke of 14:45, 16 January 2008 (UTC)

Woodstone, you have quite understandably restored the material on extensions in the summary (or introduction). I read through the discussion here, and it seemed to me that there was not strong support for retaining it exactly there, and Franamax has expressed serious reservations (see above). So I don't think this deletion was "undiscussed". My own inclination is now to leave it out of the summary, since it is introduced unobtrusively in the reply to objection 9. I strongly agree with you that extensibility and the big picture are important. They must be considered and mentioned: but not, I think, prominently and in detail. It may seem as if our plans are grandiose. I am for a politically smart push to get this first reform in place, since without it nothing more can be achieved.

That said, I want us to have consensus; and of course I will suppress my opinion if it is outweighed. I think we all want to proceed like that, don't we?

So, what do others think? Let's all converge on a solid consensus, here: to maintain forward momentum, and to enable us to take the next major step.

–N– Noetica^♬♩ Talk 11:54, 18 January 2008 (UTC)

Agree with leaving the extensions out of the summaryintroduction. I'm not sure about objection 9, honestly: I wonder if this is really a realistic objection? Who would object to implementing something that's a "dead end in development", therefore won't have spin-offs? It just means your work is done when it's done, which isn't something to object to in my opinion. Phaunt (talk) 13:29, 18 January 2008 (UTC)

As discussed earlier, component 1 may serve as a summary or an introduction. It doesn't need a label in the final version, and it doesn't matter much what we call it now.

In working towards a strong consensus version, I now see opposing tendencies: one for extensions to be given more prominence, and another to have them not even mentioned in reply to objection 9 (since that objection is unrealistic). I'll give my opinion of each tendency.

Woodstone did excellent work in proposing a whole system of comma-based markup. I support the essential idea, with reservations. The most serious is that it made , , the markup for the hard space. It is not a fatal objection to this that we had not considered it. I just think it wouldn't work well. Consider how the markup would appear: it might break in the edit box! That would lead to confusion. It is also longer on the screen than ,, and has less of the appearance of a single character, a space. The first comma, followed by a space, would often seem at a glance to be an ordinary use of a comma – especially where it breaks in the edit box. We need markup that is instantly recognisable. Also, it would be hard to specify all the combinations that might arise involving commas and spaces. It may turn out that there is a rational system of parsing, but it would not be as simple as for ,,. For these reasons I doubt that we could get consensus for it here or in the wider community. What's more, while there should be some better arrangement for the zero-width space (for which Woodstone had proposed ,,), I think the need for it arises very rarely. Even if it had better markup, I doubt that people would use it much. Yes, it is good for breaking long URLs, for example. But there are always workarounds: does the URL really need to be visible in its natural form, unbroken except at chosen points? If it does, set it on its own line. If it does not, make it invisible to the reader.

Phaunt does not like objection 9. But we can see that Woodstone and I at least, and therefore very likely others, are interested in the story beyond the hard space. This is only one of ten objections, and I think it does have its place. Woodstone's suggestions are valuable, and I would like to see them acknowledged: we offer more than a mere band-aid solution to a trifling problem.

The balanced solution is to leave things as they now stand, it seems to me.

Any more discussion on this? Any other points? I want to make changes in a few hours and move things forward. The reconfigured draft can still be discussed then, remember.

–N– Noetica^♬♩ Talk 21:42, 18 January 2008 (UTC)

The potential for further extensions of the markup does need to noted somewhere. I had slimmed it down and separated it in my suggested wording. If it's not in the summary, then it seems to only appear in objection 9. Maybe objection 9 could be "What's the point of all this just to handle the nbsp?" and the answer could be "Ah, but there's more..."? Franamax (talk) 22:09, 18 January 2008 (UTC)

What do you mean by "as it stands"? Your last proposal (on top), or the edited one by participants (below)? I realised of course that , , (with the space) is not such a good code for a hard space (as you say, it may break in the edit box). I never brought it up, because it's not the essence of my extensibility proposal. I support reserving ,, (just two comma's) for the hard space. For the zero width space we might make another choice like ,^,. It may be rarely needed in English, but for example Thai is an alphabetic script, but does not write spaces between words. Without automatic syllable breaking, layout can be very ugly. So a simple way of indicating allowed break points (that do not insert a hyphen) is helpful. Do you want me to modify that in the extensions table? Parsing with the comma as paired delimiter would be ok as long as it is limited to only a few sequences of special characters. A "nowiki" tag would cover the exceptions. I would still prefer at least a minimal mention of possible extensions. −Woodstone (talk) 22:19, 18 January 2008 (UTC)

Arghhh... I realised as soon as I went offline that what I said was ambiguous. I meant "in the stable version as it now stands".

Hugely busy in The World at the moment. It looks to me as if this is all easy to fix, especially given that Woodstone is solidly behind ,, for the hard space. I'll be back in three hours, and I'll work all new comments into a consensus stable version of the whole proposal. I'll leave that here for final comments before going more public at the MOS talkpages, OK? Please do then sign off on that version, or make small suggestions, so that we can get on with it. It's looking pretty positive, I think!

– Noetica^♬♩ Talk 22:56, 18 January 2008 (UTC)

OK, thanks to Woodstone for modifying the section of this page that concerns extensions. Very rational now, it seems to me. I have altered both versions of the "summary" for balance and consensus. See what you think. I have to go again now, but will soon make those big structural changes to this page that I have mentioned.

– Noetica^♬♩ Talk 02:54, 19 January 2008 (UTC)

Technical details

Discussion of amendments to the technical details

Objections and replies

----

[Phaunt's earlier points deleted, since they are now incorporated in the text above.–N]

[Discussion moved from #Implementation (see the reason at that section–N):]

There is an issue how to store the markup internally, linked with how to deal with existing occurrences of &nbsp;. For efficiency I would consider to convert all markup to HTML upon save. So ,, would be replaced immediately by &nbsp;. When showing the text in an edit panel it would be converted back to markup. As a consequence, all existing occurrences of &nbsp; will appear as ,, to the editor immediately upon implementation of this proposal. This may raise a storm of protest. There may also be some unexpected impact on complex cases where commas are adjacent to hard spaces. What do other participants think? −Woodstone (talk) 13:56, 12 January 2008 (UTC) --

First, I want to note that this is really a developer thing; there may be consequences or considerations unknown or unforeseen by us.

That said, I feel this should be stored the same way as other wikitext is stored: ''emphasised text'' and :indentation for example. Why treat this differently? Also, it's usually a bad idea to try and outsmart the user. If she wants to use   instead of ,,, she may have a reason for it. Remember also that there are already two ways to input the no-break space: by using HTML   and the unicode character. Would you also advocate converting the unicode character into HTML? Phaunt (talk) 21:38, 12 January 2008 (UTC)

Woodstone, those are indeed developer issues, as Phaunt points out. Like Phaunt, I think that the markup should be treated exactly as other markup is: like '' for italics, which generates <i> or </i> (depending on the context), but which is always seen by the editor as ''. And yes, there might be occasions for still using &nbsp; (see extremely rare contingencies covered in #Technical details, just as there are occasions when <i> and </i> are handy in certain circumstances, now. Personally I do not use these; but they do work as markup, alongside ''.[–Noetica said that.]

Wow! I really like what you have done with my humble proposal for a FAQ. I have made a few more additions. Phaunt (talk) 11:50, 16 January 2008 (UTC)

Implementation

Discussion of amendments to the implementation component

I have two points:

• These "em-spaces", or whatever they are, do not show well in all browsers. Right now, for example, I see them as a series of boxes. Perhaps a simple series of colons would do the job.
• Perhaps an entry in Centralized discussion would be in order, although this probably has to do with the proposal's discussion and not so much with its implementation... Now that I think of it, it should probably stay out of the box. Forget what I've said.

Waltham, The Duke of 11:36, 16 January 2008 (UTC)

Add an abstract?

I feel that the proposal could benefit from adding a brief abstract at the beginning, of maybe four sentences. This would not be too dauntingly large to quickly read, and hopefully interests (or outrages) the reader enough that he reads the rest of the proposal (or parts that interest him, such as objections and replies) as well.

A first rough suggestion:

In this proposal, we suggest the addition of the markup ,, to wikitext for the non-breaking space, often entered as  . The main reason behind it is that if non-breaking spaces are to be used with the frequency prescribed by the Manual of Style, any other entry method has so many downsides as to render it impractical. The proposal further discusses technical details of our choice, lists and addresses common objections, and suggests how to proceed when this proposal is adopted.

If you agree with adding an abstract, please feel free to move it to a subpage as with the other components, and please keep it short. Phaunt (talk) 12:09, 16 January 2008 (UTC)

We could begin it with "Fellow Wikipedians" and end it with "God bless Wikipedia", but that might prove unpopular. :-D

In any case, I agree with Phaunt. I am not lazy enough not to create the subpage myself, but I think I will wait for a second editor to concur first.

P.S.: Maybe—I don't know, maybe—we could substitute "our suggested markup" or "our suggested solution" for "our choice". It might just be me, but "choice" looks to me as if we are trying to impose this on others. Waltham, The Duke of 14:21, 16 January 2008 (UTC)

Agree with the rewording of "choice". Phaunt (talk) 14:40, 16 January 2008 (UTC)

[Please put all discussion that does not address the current agenda item in this section.–N]

& n b s p ;

  Peter Blaise ways: On the one hand, why not "teach" PHP and or HTML interpreters to respect multiple, regular ol' spaces? On the other hand, I just get used to typing & n b s p ; ... or am I missing something? I think this is all a compromise where no one has matured a WYSIWYG engine that lets us click and edit IN PLACE anything we see. Instead, we are transported to an edit window with what we were just looking at GONE and replaced by some other reformatted noise. I think the greater challenge is IN PLACE WYSIWYG. Just a thought.

-- Peter Blaise peterblaise (talk) 12:50, 12 December 2007 (UTC)

Just to clarify, since I'm not exactly sure what you mean, this is not about multiple spaces, or using &nbsp; for layout purposes (the horror!), but to prevent line breaks at certain points, like in "sq. mi." or "St. Peter".

That means there are two types of spaces: hard and soft ones. Phaunt (talk) 13:05, 12 December 2007 (UTC)

Colour me clueless

Either I'm tired or I've had one too many glasses of red wine but I've begun to wonder why we're here. As far as I'm concerned, I have no trouble, whatever, with the &nbsp[;] syntax since it's intuitive, from an HTML perspective, and workable in wikimarkup, but ugly. What I'd thought we were discussing was sort of an alias that we could type and that would automagically be replaced with the equivalent of &nbsp[;], if you get my drift. In that case, I really think it's less critical what we choose as the surrogate. Now, I agree that the surrogate should also encourage use. But, if I'm completely lost as to what we're talking about, will someone please slap me upside the head? — Dave (Talk) 06:24, 13 December 2007 (UTC)

Since no one else is here to take up the challenge Dave, I'll be the one to box your ears. It may be useful for others, too. So:

What are we here for, again?

We are talking about suitable markup for the source – the code, or text, that we as editors type in and modify in the edit box. Among the genuinely useful (even indispensable) characters we need to input, the hard space is uniquely difficult. It is invisible, so it cannot be distinguished on the screen from an ordinary space. So, while it is possible to paste a hard space in from elsewhere, it is not possible to see the result of this directly. Makes editing hard, wouldn't you think? So of course, there is the code "&nbsp;" that you mention. Why is that not OK, you ask? Well, far from it being easy to type in, you have to hit seven keys to get it. And one of those keys is the awkwardly placed "&". Admit it, folks: we all have to hunt around for that one, unless we type in special codes as a job or hobby. Hardly satisfactory, given that it should go with ellipses, some quotes, between initials of a person if you have a space between them, in "p.&nbsp;21" and the like, in compound scientific units, between a number and the following unit ("500&nbsp;sq&nbsp;ft"), and many other places.

Now, you might be comfortable with this, but many are not; and very many editors have no idea that hard spaces even exist. Certainly the developers of the current system seem oblivious to its importance, though they have made provision for a host of obscurities whose significance we can only guess at. I mean this sort of thing, under the edit box: ฿, ₯, ₴, ₰, ₪ – and my personal favourite, ৳.

Currently, to type in a properly spaced em dash or en dash (as I often have above), you need to touch on thirteen keys, a few of them of less usual, and hard to find quickly. Either that, or do it half by typing and half by hunting and clicking with the mouse under the edit box, then finding your place again in the box. But we really want editors to do this sort of thing, rather than just making a dash like this: " - ".

That one is a common use; but when you get to symbolic work – in maths, logic, chemistry, and so on – it can become a toilsome nightmare to input or edit. Hence the quest for better markup. We do it for italics and bold; we should do it for the hard space too, because it too is common – or at least should be.

So we want reform.

Better now?

– Noetica^♬♩ Talk 10:00, 13 December 2007 (UTC)

(after edit conflict: this is a reply to Dave's question, above)

You make some interesting points. I'll state my points of view:

• You have no problem with the   syntax, and neither do I; but presumably, neither do you have problems with other html character entities, or html markup for that matter. This is a wiki, and we want to keep wiki markup as simple and intuitive as possible; someone should be able to click 'edit' and immediately grasp (for the most part) what happens in the wikitext. I don't think   fits in this image. For this reason, it would be desirable to represent hard spaces in wikitext some other way. (This is what I term intuitiveness)
• I think that with good use, hard spaces can become quite pervasive; for example, I would also use them before the word "I" if it is the last word in a sentence (as in "as do I."). The wikitext may become rather cluttered if there are so many  s floating around. (I term this intrusiveness, or, desirably, lack thereof).
• However, there is the possibility of using the unicode symbol for the hard space in wikitext, which would mean we don't have to introduce any new machinery, just a link below the edit box for entering it. The main problem with that is that it's indistinguishable from an ordinary space. I'll add it to the list of suggestions, though.
• Finally, even if we were to make up an alias that would be transformed into   upon saving the page, we would still have to take care not to break existing wikitext (consider editing and saving a page in which existing wikitext coincides with the alias). For this reason, I believe we could just as well go the whole way and represent all hard spaces with some wikitext symbol(s).

Regards, Phaunt (talk) 10:13, 13 December 2007 (UTC)

I have to observe that the &foo;-style character entities are part of MediaWiki markup as well as HTML; the distinction being drawn is a false dichotomy. I don't have any particular objection to something like ~~ also being usable to do this. The {{nbsp}} {{s}} option is fine. I agree with Phaunt's concern that the unicode hard space isn't visually distinguishable from a regular one, so if the edit box has an option for this, it should probably insert something else (e.g. &nbsp;, or whatever "~~"-like option we might settle on.) it should probably insert {{s}}. — SMcCandlish [talk] [cont] ‹(-¿-)› 20:23, 13 December 2007 (UTC)

Design goals for the new markup

Does everybody agree with the goals I stated above? intuitiveness, lack of intrusiveness (can we replace this with a positive term? 'transparency' maybe?), ease of entry and compatibility with wikitext? Are there any more we should take into account? Phaunt (talk) 10:28, 13 December 2007 (UTC)

Yes, very good. But can you make it clear that one of these is a deal-breaker (compatability with wikitext) and that the other three are desirables that will have to be balanced against each other? IMO:

• Ease of entry is the most important of these three (otherwise, why not stick with the current hedgehog hunt and peck code?). There are two aspects for ease of entry: one is brevity, i.e., as few keystrokes as possible; the other is the avoidance of odd or awkward keys or sequences, or keys that may not be on all keyboards (especially laptops, which typically don't have an alphanumeric keyboard at right). But frankly, if everyone has the key top left for Noetica's little glyph and tilde, it's easy and convenient once learnt.
• Then lack of intrusiveness (is "visual smoothness" better?).
• Then last, intuitiveness, which is a luxury if it can be found. Tony (talk) 12:17, 13 December 2007 (UTC)

I don't buy the "intrusiveness" argument at all. Lots of things about MW markup, along with all markup languages are "intrusive" in this sense (e.g. piped links), and we get along just fine with them. Their very intrusiveness allows them to stand out. This is one reason that I explicitly use &ndash; and &mdash instead of their Unicode counterparts which in many fonts are literally impossible to distinguish from each other. That said, something ridiculously intrusive, like "Template:Non-breaking space" would be a bit much, though the real problem with that would be usability, really, not intrusiveness per se - no one wants to type that much for a space character. — SMcCandlish [talk] [cont] ‹(-¿-)› 20:28, 13 December 2007 (UTC)

Also, I wouldn't put intuitiveness last, since that seems to be the main source of the "rebellion" against &nbsp; to begin with. :-/ — SMcCandlish [talk] [cont] ‹(-¿-)› 21:00, 13 December 2007 (UTC)

I agree about intrusiveness, SMcCandlish. The same argument is used against footnotes and in favour of endnotes; many academic publishers therefore design books that compel the serious reader to flip to and fro between text and notes. A cursed nuisance. To communicate well, we all have to compromise on such things. Intuitive input counts; and so does intuitive appearance, which is quite separate from intrusiveness.

– Noetica^♬♩ Talk 04:43, 14 December 2007 (UTC)

Three kinds of hyphens

Dan raised the matter of hyphens in our main discussion, above. We may need to clarify. There are three kinds:

H1. The hyphen that only appears when it needs to, at the end of a line (optional hyphen).

H2. The hyphen that always appears, sometimes followed by a line break.

H3. The hyphen that always appears, never followed by a line break (non-breaking hyphen).

I think we have called H3 hard hyphen; and Dan intended that, right? But others call H2 hard hyphen (see Hard_hyphen#Hyphens_in_computing).

Just so long as we're clear. Any difference between hard and non-breaking seems irrelevant as applied to spaces, but not to hyphens. I propose that, for convenience and certainty, we refer to H3 as NB hyphen, if it comes up again. And perhaps we should call H2 normal hyphen.

– Noetica^♬♩ Talk 20:53, 16 December 2007 (UTC)

No shortcut any more

The redirect page ActionMOSVP has been deleted, apparently because such a redirect breaches policy. No problem. Just so you know.–N

New miscellaneous topics

[Moved from discussion of current agenda item:] One more potential alternative that would perhaps be easier to implement in the software. I noticed that the code '' '' is not rendered as single italic blank, but as a normal blank. There is already an exception in the parsing for italic markup to exclude blanks adjacent to the mark. We might modify this into making it a hard space. For example p.'' ''23 markup would result in p. 23 with a hard space. −Woodstone (talk) 13:02, 1 January 2008 (UTC)

I currently favor {{nowrap|}}. Again, the discussion here has been intelligent and useful, and I support the decision to proceed with a vote on the current options so that the discussion can move back into WP:MOS_Talk, but for anyone who's interested, my reasons are on my talk page. — Dan Dank55 (talk) 20:47, 2 January 2008 (UTC)

Question about the point of this whole process

[Moved from discussion of the current agenda item. Participants, please retrieve those parts of it that are on-topic there, and work them into the discussion again.–N]

added heading: didn't belong to the heading it was moved under Phaunt (talk) 11:56, 8 January 2008 (UTC)

First, I support the process here at ActionMOS. ",," seems to be the top-vote getter, and we needed a while to get there, and the discussion has been intelligent and useful. Congratulations to everyone for sticking it out, and especially to Noetica for devoting so much time to this.

A few days ago, I noticed that Noetica said in MOS_Talk: "...to be replaced by &nbsp;". If some people were interpreting this whole discussion to mean that we and others would both read and write ",," in the edit window and see a no-break space on the page, but the markup would change back to &nbsp; after we're done, perhaps with the help of a bot like AWB, then I'm sorry I missed the point. After giving this some thought, it seems to me that the arguments we're going to run into against ",," as permanent markup are very strong (and I apologize for not thinking about this earlier, I'm annoyed by my slowness):

1. Our slogan is "The free encyclopedia that anyone can edit." Okay, someone pulls up an edit page and sees single quotes around italics and bold and = around headings...from context, it's obvious what those mean. There are templates they don't understand at the top of the page, but that's not going to stop them from editing. But wait a minute, there are double-comma's inserted into words, what is that? A couple of hours spent learning about no-break spaces and Wiki markup will fix the problem...but now we're not an encyclopedia that anyone an edit any more, we're only for people who want to educate themselves first. Millions of Wikipedia users don't know and will never care about no-break spaces, despite the fact that we know and care.
2. There's no reason to treat this as a fight, because everyone can get what they want. Many prolific editors already use bots such as AWB to help with routine editing chores, and anyone clued-in enough to understand the fight over no-break spaces can be clued-in enough to use a bot to make no-break spaces and anything else easier on the eyes and fingers, while they're editing. We can't expect the same from the uninitiated.
3. I agree that {{nowrap|}} takes too long to type. If you don't want to use a bot, what's wrong with using a browser add-on (I currently use abcTajpu for Firefox) to remap ",," to the nowrap template? We're going to run into that objection for sure at the Village Pump.
4. Does anyone enjoy reading a user's manual where the writers think that it's their job to educate you, rather than to use words that you already know? I'm guessing that the number of Wikipedia users who understand what "not wrapping" means is a few million more than the number who currently understand the phrase "hard space" or "no-break space", much less ad-hoc markup for a hard space, which I think makes the nowrap template (or NoWrap or notwrapping, if you think those are clearer) the elegant solution, the one that doesn't require the user to look it up.
5. If we can talk the techs into accepting a solution that will require more pre-processing, it would be really nice to join the modern world and have Mediawiki software calculate correctly where the lines should break. That is, there would be some page where we argue over the rules for no-break spacing, and those rules get applied to all pages. (So, p. #, # AD, # sq ft would all be examples.) If the techs argue that it already takes longer than they like for pages to display, perhaps we could say: okay, then decide which pages will and won't wrap correctly...if you only want to do the pre-processing on Good and Featured articles for now, then do that, but over time, we'd like for more and more pages to wrap correctly. Maybe we could talk them into allowing us to toggle the edit window so that it displays the way we want it...with ",," for no-break space and anything else that's easier on the eyes and fingers, for us.

- Dan Dank55 (talk) 14:05, 7 January 2008 (UTC)

(above comment moved down from the list it broke) The essential point is that in the edit panel it should be visible if a blank is hard or soft. Otherwise it would be very difficult to ensure the right hard spaces are in place. Editors already have to learn (on fly and from context) what ''x'', '''x''', [[x]], {{x}} and ==x== mean. I think it would not be too hard to learn an additional ,,. However, in view of extensibility, we might make it ,x,, where x may also be codes for other things for which no clear symbols are available (like en or em dashes, soft hyphens, or line breaks). −Woodstone (talk) 14:45, 7 January 2008 (UTC)

Basically, I do not believe that a double comma is all that different from the rest of the markup. Although double and triple apostrophes can be quickly identified as markup for italicised and bold text, link markup is a little more complex, image links are often even more complex, and tables are much, much more complicated. Not to mention how strange templates must look to most people, or how confusing the categorisation system usually is for newbies. The fact is that there are quick reference guides in Wikipedia, the most concise one being the Cheatsheet, where any newcomer can quite easily learn the basic elements of Wiki-markup. And I can assure you that a single sentence, if phrased properly, can be of much assistance to new Wikipedians; they are not stupid, you know. An example off the top of my head: A hard space is a space which ensures that the two words it separates will stay together in text and not end up on different lines, and it is used between numbers and their units, as well as... [whatever other uses]. This most probably suffices to inform the editors of what a hard space is, what it does, and why it is useful, without using any special vocabulary; for those who want to learn more, there is the link to the article about hard spaces, and there will probably be links to the relevant sections of the Manual of Style and editing help as well.

In any case, it is my opinion that, as markup, and in order to spread its usage more efficiently, a button for hard space ought to be added to the toolbar above the edit window. That is, if our proposal passes. Hard spaces are much more needed than what their current usage suggests; the button would be useful not only to encourage editors to use hard spaces, but simply because hard spaces are supposed to be used in a great number of articles (probably much more often than block quotes, which already have their own button).

Finally, it would certainly be a gain of resources if we could do all this without using any bots. I know that performance is not that much of an issue, but I am rather frugal with edits by nature. Why do something in three edits if you can do it in one? (As you can probably guess, I use the preview button rather heavily.) Waltham, The Duke of 10:27, 8 January 2008 (UTC)

A short response from me, too. Yes, the no-break space will be rendered as   in HTML, but also yes, it will remain as ,, in the wikitext. The reason not to translate to   in the wikitext is that this is even more confusing to newbie editors (who you can't expect to be knowledgeable of HTML—that's the whole point of wikitext) than the double-comma, not to mention a lot more visually detracting to everybody (in my opinion, of course). I gather from your text that this means you'll oppose our proposal; your opinion is respected, and so be it. Phaunt (talk) 11:56, 8 January 2008 (UTC)

Important recent change to the edit screen

[Moved from current discussion.–N]

The regular   has been added into to "Wiki markup:" list below the edit box. Thanks whoever did that. Jɪmp 00:35, 8 January 2008 (UTC)

Wow! When did that happen??? Who was responsible? How can we find that out? Useful, though not a final or optimal solution.

We'd have to think that someone is paying attention to our discussions, here and there, wouldn't we? THAT is encouraging!

For my part, I am now convinced that the markup ,, is the best solution, and I hope we will all push hard and steady till we get action on it.

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

Not sure when but recently, in the last few hours it seems (and definitly no longer than 20 hours ago). Jɪmp 01:32, 8 January 2008 (UTC)

Well spotted then, Jimp. I have placed the following request for information at WP:VPT, since they're the most likely folk to know such things:

New "nbsp" below the edit box

The code &nbsp; has recently been added to the resources below the edit box, in the section "Wiki markup", just between #REDIRECT [[]] and <s></s>. That's great!

I'm with a group of editors who are currently interested in the hard space: its markup and its uses in editing.

Some questions:

   *Exactly when was that change made?

   *Who made it?

   *Where are such changes logged?

   *What is the very best place to propose such changes? (Seems to be WP:VPR; am I right?)

Any authoritative information on these will be of great value.

– Noetica^♬♩ Talk 01:41, 8 January 2008 (UTC)

The contents of the insert box is controlled by MediaWiki:Edittools Nohat (talk) 01:41, 9 January 2008 (UTC)

Click show on the grey band to see the editable draft of the whole proposal. Discuss changes below.

Discussion of the draft of the whole proposal

I have added a one-line subtitle to serve as a minimal abstract of the proposal, in response to suggestions. I have listed the four components at the top, and I have re-named the first component Overview. That seems to be a good compromise, since it serves as an introduction but it could also be used independently as a summary or synopsis of the whole proposal. The names of these elements are as subject to negotiation as anything else; but I do hope we can very soon settle on a finished version that we can present at other forums. Best to make small changes only, now.–N– Noetica^♬♩ Talk 09:02, 19 January 2008 (UTC)

As it stands now (see timestamp), I approve of the working version. I have little time at the moment, so I cannot compare it with the draft at the top of the page, but from what I have seen I think they are identical. One note: we will discuss carefully the way the proposal will be submitted to the community, will we not? This must be planned well, lest it explodes in our faces and we end up with the bitterness we have just seen in the rollback debate. I am saying this because I have been thinking of Centralised discussion, but this has more to do with the conversation rather than the implementation of the proposal, so it does not exactly belong to the draft. Waltham, The Duke of 16:24, 19 January 2008 (UTC)

Sorry about leaving the "in use" tag in place when I finished editing. (Huge distractions in the world.)

Waltham, as I write this the working version is the same as the stable version [Ah, not quite.–N]. I copied one to the other. A good technique is to test replacing one text with the other in editing, and then click "changes" under the edit box instead of "preview".

Again, the management of this page is experimental. I'd know better next time how to do it.

Yes, we do have to discuss what to do next. I have some ideas on this, and I'm sure others do as well. See modified item 4 of the agenda: we have to devise a strategy. Let's have some exchange of ideas on the talkpage, yes? I do think we have to put the refined draft up at WP:MOS for comments there. See talk.

– Noetica^♬♩ Talk 21:10, 19 January 2008 (UTC)

A point of procedure: Since there is now so little that needs changing, it will be convenient to show our edits in the working draft itself. I have used strikethrough (<s>...</s>) and underline (<u>...</u>) to mark one recent change, and some new ones that I now propose (see below). Please do the same, as we make the last small changes. Where a changes needs discussion here you might also mark it with <font style="background-color: Aqua;">...</font>, as I have. Only a few more of these. Let's be patient and careful.–N

• I have applied italics in mentioning one component of the proposal within another component, for consistency.
• I have cut out uses of "we", etc., that suggest this is our thing alone. But no: we are writing a proposal for others to take ownership of, and to endorse publicly.
• For now I have left Woodstone's change (marked in aqua) in Overview, but I don't think it reflects consensus. Let's work on getting the wording perfectly balanced here. This seems to be the last sticking point. I don't like the term interpunction (rare or obsolescent in English: SOED), because it is unfamiliar and may be confused with interpunct. Apart from that, there is still concern from some of us that we need to play down extensibility. We need to give it just the right weight. Ideas?

–N– Noetica^♬♩ Talk 03:11, 20 January 2008 (UTC)

The WP:MOS has a section on "Punctuation". That might be the right term to use. −Woodstone (talk) 10:26, 20 January 2008 (UTC)

So is everyone perfectly happy with something like Woodstone's addition, but with the word punctuation instead of interpunction? Personally, I think the single unadorned word "purposes" would be best: it is already a compromise to mention extensions at all in the Overview. But I'll go with what the majority is happy with. Woodstone, will you accept a ruling on this when others have spoken, or do you still want to insist on a fuller mention of extensions such as you have put forward?–N

Noetica, it can still be shortened, but "other purposes" is too vage. There should some indication what those purposes are. How about something like "... to simplify other elements that are now awkward to enter". I will leave the final decision to you. −Woodstone (talk) 13:32, 20 January 2008 (UTC)

Multiple commas

I've been wondering for a while whether the use of multiple no-break spaces is really justified. I remember reading in some style guide that this should not be used for lay-out purposes. I don't object to the proposed way to handle long strings of commas, but I wonder whether we should mention that multiple no-break spaces are only seldom justified? Phaunt (talk) 11:17, 20 January 2008 (UTC)

It is not our role to teach good markup. People will do what they can to achieve the formatting they want. In fact, I resorted to strings of hard spaces in these transcluded texts: Waltham found that em spaces didn't work in his browser, and I didn't know how to fix the formatting by "approved" means. (Remember that the text has to work between blockquote tags, which is tricky at WP and elsewhere.)

How about a short bracketed mention like this "...(deprecated by some)..."? I'll do that if I hear no objection. Let's get this thing moving now.

–N– Noetica^♬♩ Talk 13:18, 20 January 2008 (UTC)

Hm, I don't know. Perhaps it's better to leave it as it is. Never mind. Phaunt (talk) 18:24, 20 January 2008 (UTC)

At this point we are not describing how to use the hard space as in the MOS. We just need to make sure there is a clear definition of how the double comma would work in various contexts. The text on that as it stands is fine. −Woodstone (talk) 19:19, 20 January 2008 (UTC)

I have in fact included a short statement about multiple hard spaces being deprecated. It shows that we know such things, and are not completely naive!

I have modified the working version to reflect consensus the best way I can; and I have copied the result to the stable version. As I write, the two texts are therefore the same.

Please let me know if there are any errors. Apart from that, let's not edit the proposal any more at this stage. See secretary's noticeboard.–N