User talk:Noetica/ActionMOSVP

From Wikipedia, the free encyclopedia

See a full draft of the proposal

[Stable draft; last amended 11:04, 27 March 2008 (UTC). Development page: WT:NOWRAP.] Better markup for the hard space A proposal to implement ,, as markup for the hard space (&nbsp;) 1. Overview 2. Technical details 3. Objections and replies 4. Implementation 1. Overview The hard space is an important but neglected element in good Wikipedia editing. It stops an unwanted line break, so it is also called no-break space, or non-breaking space. An example (one sort from very many): no line break should occur in "17 sq ft". At present there are two ways to achieve this: first, with the raw HTML &nbsp; code (17&nbsp;sq&nbsp;ft); second, with the {{nowrap}} template ({{nowrap|17 sq ft}}). These options are hard to remember, hard to input, and hard to interpret on the screen. Some cases are far more complex. The solution? Introduce simple new Wikipedia markup, similar to the existing markup for italic (''italic text'') and bold ('''bold text'''). Although these are converted by the system into HTML code (<i>italic text</i> and <b>bold text</b> respectively), the text always appears in the edit box with the markup '' or '''. The proposal simply adapts this useful and accepted idea, to include the hard space. Extensive discussion among interested editors, followed by a poll, shows that ,, (two ordinary commas) is the best markup. When it is implemented, one could type 17,,sq,,ft in the edit box, which would be converted internally to 17&nbsp;sq&nbsp;ft, so that the reader of the article always sees an unbroken "17 sq ft". Editing, we would always still see 17,,sq,,ft. This innovation is easy for experienced editors and welcoming to Wikipedia newcomers, since it is the same style as markup for bold and italics. Analysis shows that comma-based markup could be extended for other formatting and punctuation; but that is beyond the present simple proposal. 2. Technical details The system's existing parsing of markup for italics ('') or bold (''') is a little complex. Those markups are "dual", requiring distinct interpretations as either beginnings (<i>, <b>) or ends (</i>, </b>). Those markups have to coexist with the use of ' as a single quote mark and as an apostrophe. Italics and bold are often applied together: sometimes overlapping, but more often nested like 'this' (markup: ''nested '''like 'this''''''). The WP community accepts the occasional ambiguity, and where the system fails to parse as an editor intends, there are workarounds available. The proposed markup for the hard space will be much more straightforward – for originating editors, subsequent editors, and the system itself. There are no beginnings and ends, just single applications. Still, some slight complexities will arise, and they are easily dealt with. We start with the simplest case: The case of ,, Exactly two adjacent commas will always be parsed as a hard space, yielding the HTML code &nbsp;. Inadvertent typing of ,, instead of , will cause no serious damage: its effect can easily be detected and repaired. The case of ,,, The markup ,, must coexist with the use of , as an ordinary comma in the text, though it will rarely be adjacent to such a comma. If this ever does happen, the natural parsing of ,,, would be as comma + &nbsp;. This could conceivably be needed in a complex subscript, like this: W1, 2, 3, ... , n (markup: W<sub>1,,,2,,,3,,,...,,,n</sub>). It is hard to think of a case in which the reverse would be needed (&nbsp; + comma); but if that ever did arise, <nowiki></nowiki>, &nbsp;, and {{nowrap}} would always be available, as they are now. The case of ,,,, (and higher even numbers of commas) Sometimes more than one hard space is called for: in fine-tuning spacing in tabular work, for example. (This is deprecated by some, but often a convenient solution.) The natural parsing of ,,,, would be as &nbsp; + &nbsp;. A similar interpretation would apply to any string of 2·n commas: it would be parsed as n instances of &nbsp;. And similarly for longer even-numbered strings of commas. If the editor intended comma + &nbsp; + comma, the existing alternative resources should be used. The case of ,,,,, (and higher odd numbers of commas) The sequence ,,,,, would be most unlikely to occur, and might arise more often as an error than as meaning anything specific. But the natural parsing would be comma + &nbsp; + &nbsp;. And similarly for longer odd-numbered strings of commas. If the editor intended &nbsp; + comma + &nbsp;, the existing alternative resources should be used. In short, there is a single rational parsing for any comma-based markup that could arise; and in the rare cases in which no comma-based markup will yield the desired non-breaking HTML code, alternative resources will meet the need as they do now. 3. Objections and replies Objection 1 Hard spaces? I never use them! Why should I care? Good editing requires hard spaces, even if many editors know nothing about them. Wikipedia's Manual of Style (MOS) explains some of their uses; and more uses would be added there, if only the markup were simple enough. Objection 2 The no-break space can already be input with &nbsp;. Recently this code has been attached to a button for insertion, under the edit box. Isn't that enough? There are three points to make. First, the code &nbsp; is hard to remember, hard to type, and hard to interpret on the screen, especially to those who are unfamiliar with HTML. One simple example: an en dash often needs a hard space before it. Consider "89 sq in – 3 sq ft". To keep this from breaking improperly you need to type, or later edit, this code: 89&nbsp;sq&nbsp;in&nbsp;– 3&nbsp;sq&nbsp;ft. Under the proposal, you would simply type this instead: 89,,sq,,in,,– 3,,sq,,ft. Second, note that the goal of wikitext is to abstract HTML codes away from the user, especially for common markup such as ''italics'' and '''bold'''. If the hard space is to be used as often as MOS advocates, it also needs this treatment. Third, the new insert button does not help with interpreting the code seen in the edit box. It helps with inserting: but you still have to find the button, then find your place in the text again. Do you really want to do all that three times, for the example just given? Objection 3 Why not use the Unicode character for the no-break space, attached to an insert button? There is still a problem with insert buttons as a solution. In contrast to &nbsp;, the Unicode non-breaking space is visually indistinguishable from the ordinary space. This is unacceptable, since the editor needs to be able to see the difference in the edit box. Objection 4 There is also a {{nowrap}} template. Why not use that? This template may be useful in some longer phrases that shouldn't be wrapped at any point; but again it is too visually intrusive to be used extensively for single no-break spaces. With the example above, the code would be {{nowrap|89 sq in –}} {{nowrap|3 sq ft}}. And many cases are more complex than that. Currently, {{nowrap}} does not behave well, since a space at the start or end of the enclosed text is rendered in HTML outside of that text, leading to unexpected breaks. There are other templates similar to {{nowrap}} that cater for specialised requirements; but all of these come up against technical inadequacies in the template system itself. And they all use the HTML <span> tag, which is interpreted differently by different browsers with unpredictable results. Use of &nbsp; instead is simpler, more intuitively understandable, and more reliable in its results on the reader's screen no matter which browser is used. That is what the proposal for ,, achieves. Objection 5 I use a non-standard editor with aliasing, so when I want a hard space I type /h to get &nbsp;. Easy! So what's the problem? There are two problems. The code you make is still hard to read and edit; and not everyone can do what you can do. Objection 6 I'm used to &nbsp;. That's what I'll always type! You could do that, of course. You'd still make markup text that's hard to read and hard to edit. Some people (very few!) type <i> and </i> in the edit box. But they'd make life easier for themselves and others if they just typed '' instead. Objection 7 The proposal is technically too hard to implement, and is not standard anywhere. It is in fact easier to implement than '', ''', and other non-standard markup used at Wikipedia (see Technical Details). Wikipedia is the leader in these matters. Our developers have the capacity to innovate, and others would almost certainly respect their precedent, and follow it. Objection 8 The new markup is unintuitive, and unlike anything we have already. In fact it is quite intuitive, at least for editors who are already used to '' and '''. Beginners have to learn that markup: the new markup simply uses , instead of ': similar but distinct characters, both with their own stand-alone uses as apostrophe (or single quote mark) and comma, and both also used in markup. Objection 9 Markup with commas is impractical, and a dead end in development. The comma markup has potential to be extended in all sorts of useful ways. Because a comma hardly ever occurs without a space or a digit after it, it is quite readily available for alternative use. We might in future consider markup like this: ,., (to force a break: equivalent to <br>; ,--, (for an en dash: equivalent to – or &ndash;); and so on. Such markup could be combined: ,,,--, (for an en dash with a hard space before it: equivalent to &nbsp;– or &nbsp;&ndash;). But any such extensions would be negotiable. Accepting the present proposal does not commit anyone to any such extensions. Objection 10 German and some other European languages use the character „ as an opening quote. Markup with ,, could easily be confused with that; and that markup might be needed in future for „ or for some other purpose. In fact there is little likelihood of the two being confused. Their appearances on the screen in common fonts are less similar than the appearances of '' and " are: and we all live with those quite happily. As for reserving ,, for some other purpose, the present proposal makes its own strong case. If others want to make their claim as well, well and good. But we see no evidence of any such claim; and the hard space is of such importance that it is unlikely to be trumped by anything more pressing. After all, those who use „ already have their own established ways of inputting it, just as we do for ". Objection 11 Other changes in the wiki-markup system would be more sweeping and more "wiki-like". Certainly the suggestion is unusual in that it proposes substitution of the single HMTL-entity &nbsp; for the single marker ,,. But the fact that this is easy to implement is not a principled objection, and certainly not a convincing technical objection. The logic of the subsitution is laid out in full above. As for the possibility of overall changes that would make this change redundant, this can be no serious objection either. We have been promised solutions to problems like the one we address here for a long time; but they are not forthcoming, and there seems to be no consultation about them beyond the technical development community within Wikipedia. The present problem has been identified by serious, active editors concerned with style and ease of use, and we find that the proposed solution does all that is needed. If a better solution eventually comes along, no harm has been done in the meantime. Objection 12 It's all too hard! How can editors bring about a change like this? It is hard work to bring about such a change. But the rewards for this simple innovation are significant. And Wikipedia is made up of editors with good ideas that they pursue energetically. That's really what it's all about! Developers and decision-makers will take seriously a proposal that grows out of the concerns of competent and committed editors. 4. Implementation After appropriate discussion at WT:NOWRAP, and possibly at MetaWiki, the coding and system changes for the new markup are a matter for developers. This proposal simply outlines the desired behaviour of the markup (see full specification in Technical details, above), and responds to predicted and actual objections so far. Once the new feature is in place, it would remain harmless and unnoticed by most editors, since they would rarely if ever input two adjacent commas. (This is a virtue of the proposed markup, in fact.) The community will therefore need to be informed of the change. This can be done at a variety of forums, including: Village pump (proposals); Village pump (technical); Village pump (policy); and other Village pump pages Manual of style; Manual of style (dates and numbers); and other MOS pages and talkpages Various community noticeboards Helpdesk; New contributors' help page; How to edit a page; Cheat sheet; and other articles outlining basic editing and markup The details can be determined once the new markup has been accepted for incorporation. In the meantime, nothing is lost through uncertainty and confusion, since the proposal adds a feature, but does not take anything away. In this respect it is safer than almost any alternative. For example, :: has meanings in mathematics (and : has meaning in current wiki markup); ;; may occur when HTML entities fall adjacent to a semicolon (and ; has meaning in wiki markup); `` has a meaning in some existing systems of wiki markup; etc. By notifications as outlined above, and through general community interactions, the new ,, feature should soon become a part of accepted practice, just as '' and ''' are already accepted and appreciated.

Contents 1 what are the proposals? 2 Option 5 3 Support 4 My thoughts on how to proceed 5 Technical discussion as in computers... 6 Sections in document 7 Extensions discussion 8 How to take the proposal to the community 9 Archiving: no more editing of the proposal 10 New section at WT:MOS

The page looks pretty nice! Hey sorry about earlier again... I don't know why Twinkle did that... Good Luck! - Jameson L. Tai ^{talk ♦ contribs} 07:22, 12 December 2007 (UTC)

[edit] what are the proposals?

OK I've spent 5 minutes & I still cannot find any specific proposal --JimWae (talk) 01:16, 6 January 2008 (UTC)

Look at the voting table, and you'll see the shortlisted options, numbered 1 to 4. The earlier large table shows more alternatives (click "SHOW" to see it), from which these have been selected by negotation. Also read the agenda. It shows where the process is up to, right now.

– Noetica^♬♩ Talk 01:30, 6 January 2008 (UTC)

Good grief. I have the same problem. I followed your link, and wonder of wonders, I learned that our four options are:

1. Option 1
2. Option 2
3. Option 3
4. Option 4

Extremely helpful!!! Gene Nygaard (talk) 15:56, 6 January 2008 (UTC)

Look in the Code column. Phaunt (talk) 16:16, 6 January 2008 (UTC)

And now we have moved things along, and we have this more developed summary (transcluded, so it will update here). See the top of this talkpage.[– Noetica^♬♩ Talk 22:14, 19 January 2008 (UTC)]

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

[edit] Option 5

I'm abstaining for want of anything I'd want to vote on. None of those options seem desirable to me. Instead I'd rather see some sort of push to get the regular   included in the "Wiki markup:" list down in the edit box ... an option seemably not yet thought of. Jɪmp 08:41, 7 January 2008 (UTC)

[edit] Support

On a quick pass, and then a second, slightly more meditative read, I see nothing to which I could object. No reasonable second use of two consecutive commas comes to mind. I like it, and will support it. Currently I'm using the nbsp method, but I always have to look at the exact markup (absentminded, I know--why is it I can remember an entire movement of a Mahler symphony, but not how to format a non-breaking space?) Good idea! Antandrus (talk) 04:03, 11 January 2008 (UTC)

Thanks, Antandrus. We will need wide support from admins and master editors as we move this forward. Good to know that you see the value of what we're up to here. I have taken the liberty of including you on the list of participants. Feel free to remove that, of course. But your presence is valued!

– Noetica^♬♩ Talk 04:26, 11 January 2008 (UTC)

I've just come across this - apologies if I'm revisiting arguments that have already happened. I support the general idea. How would we link to, say, http://politics.guardian.co.uk/funding/story/0,,2239202,00.html? It appears nobody suggested "\ " (backslash space) which would perhaps be more memorable and equally extensible? "17\ sq\ ft". But yes, in principle. --RobertG ♬ talk 12:40, 11 January 2008 (UTC)

Yes, the "\ " (borrowed form TeX) has been proposed and rejected somewhere in the process, for doubtful reasons. Coding your URL would work by replacing one (or both) of the commas by %2C. −Woodstone (talk) 13:17, 11 January 2008 (UTC)

• Support the double commas. Great idea. Tony (talk) 13:44, 11 January 2008 (UTC)

• One more time. Save '| ?', and you'll see that Mediawiki renders it to '| ?'. We have an opinion from Jesús Martínez that additional rules for when to auto-insert hard spaces should be possible. Is there anyone who would actually prefer that Mediawiki _not_ do this automatically? (Woodstone objects that the rules might insert hard spaces that we don't want, I counter that all we have to do is not have any rules that we're not certain about.) Would anyone prefer that we do something in WP:VP prior to asking the techs for this at bugzilla.mediawiki? And who would like to make this proposal at bugzilla? I'll do it if there are no objections and if no one else wants to. [reproduced on the talk page because we seem to be talking over here today] - Dan Dank55 (talk) 14:06, 11 January 2008 (UTC)

Before we ask for automatic substitution we must make sure that the unavoidable cases where the mechanism fails can be permanently overridden by an editor. In my experience it is not reasonable to expect we can make perfect rules for such context dependent parsing in a body of text as variable as an encyclopedia. In general I am hesitant to implement language dependent automation rules in software as mediawiki. Not every language abbreviates pages to "p". −Woodstone (talk) 14:16, 11 January 2008 (UTC)

I'm only proposing this for English language sites; since I'm not fluent in other languages, I can't speak for them. I hope people will listen to what you're saying about being hesitant, Woodstone...we don't want a long list of rules that "look pretty good" but give unexpected results. But can you think of a single case where the string 'p. 1' should not be rendered with a hard space? When would you actually prefer for that "1" to appear by itself at the start of the next line? My point is that we need to listen to you and be careful not to give rules we're not absolutely sure about, but it should not scuttle the request at bugzilla. "Be bold". Wouldn't it be a good idea to make the initial proposal with bulletproof rules, and put off discussion of exceptional cases until if/when we get the coding change we want? - Dan Dank55 (talk) 14:27, 11 January 2008 (UTC)

(a late comment on the above question: see for example in English Electric Lightning and PZL P.6, where a P.1 should not be split) −Woodstone (talk) 21:46, 11 January 2008 (UTC)

(I hope Dan will forgive me for correcting his post's indention)

Personally, I am against automation. It is not foolproof, it might have unexpected results, thorough rules will have to be made for it to work, and it generally supports a trend towards giving more and more responsibilities to bots, something I am against. This encyclopaedia is supposed to be written by people, not by programmes.

And listen to this: what we are doing here is try and make the hard space easier for editors to manage; proposing an automation process is like shooting ourselves in the foot as far as this proposal is concerned, in the sense that it will not be considered as necessary to change the markup if bots are to do half the work anyway. I should not see it that way, but I am certain that many people will. Waltham, The Duke of 14:39, 11 January 2008 (UTC)

Okay Duke. I assume good faith, both because I'm supposed to and because I actually do, but if you prevail, here's how the issue will look when it hits WP:VP. You had a choice between two paths, one path was an attempt to deal with the problem that required a lot less work from editors, would give more consistent results, and wouldn't present new users with markup they don't know on almost every page, and you chose the path of greatest intrusiveness. - Dan Dank55 (talk) 15:18, 11 January 2008 (UTC)

I did not understand the part about the new editors and the unknown markup. If both the double-comma markup and the automatic introduction of hard spaces do get approved, then the double-comma will replace all instances of HTML hard spaces, which means that, by whatever means the hard spaces are introduced into articles, they will appear as double commas in the edit box. Plus, for new editors, all markup will be unknown, including double and triple apostrophes.

And, for your interest, I am not adamant as far as my opposition against automatic hard-spacing is concerned. I am willing to compromise, if necessary. I order you to calm down. Waltham, The Duke of 15:27, 11 January 2008 (UTC)

First apologies, I was just editing my reply to try to appear less hostile but you beat me to it. I don't mean that _I_ think you're a bad person and headed down the wrong path...you have a solid argument, which is that if most of the hard spaces are inserted automatically (and I'm talking about the hard space that Mediawiki already inserts in the case of '| ?' at the moment), then it makes ",," more exceptional, and that means fewer people will know about it, and I believe the consensus here is that that is a _bad_ thing. I really am not challenging you to a duel, your Grace. What I'm saying is that, as far as I can tell, there is uniform opposition to the idea of forcing everyone to learn new markup that would appear on every page over at Wikia, _if_ there is an acceptable way around it, because the admins complain that they spend their lives explaining markup to newbies and they have been campaigning for years to make that job less burdensome, not more burdensome. I'm trying to give you a heads-up for what I think you're going to hear at WP:VP. I also, personally, don't buy the idea that if ",," occurs less often, that that will be a bad thing. People who care will learn about it, and people who don't, won't, just like always. People are generally highly resistant to being educated about things they don't care about. Finally, I'm saying that even if you disagree with me, wouldn't it help your chances of success to show that you're listening, you care, you're looking for compromise, as a first step? - Dan Dank55 (talk) 15:40, 11 January 2008 (UTC)

(de-indent) Ha, ha, I have beat you to it, and now everybody will see your true colours. Mwahahahaha! :-)

To our topic now. I do agree that double commas appearing rarely is a bad thing for our cause here, but it is not what I was talking about. I was supposing, and quite plausibly in my opinion, that if the double comma markup were to be approved, then it and only it would be officially promoted as the code for hard spaces in Wikipedia. I have never supported, and do not intend to, a double usage model, where bots will use the HTML and editors the double comma—one of the main arguments in favour of the double comma is that it makes text in the edit box from hard to understand to fairly illegible, depending on the case. I have thought so far that our intent was to banish the HTML from edit boxes; if I am wrong on this, I am probably wrong on many other aspects of the matter as well. I certainly do not enjoy this kind of surprises.

I have also been operating based on the thought that markup is something natural on Wikipedia, an integral part of the editing process, and a concept that is taken for granted by Wikipedians. Of course it needs some getting used to for newcomers. I never imagined that, with all these carefully developed, well-written, very clear help pages that exist on markup, and which not only form a part of the tutorial but are also readily available from the Help and linked to from the welcoming messages, learning markup would actually be anything close to a problem. As I see it, this is either an exaggeration on your part or an inability on the administrators' part to effectively redirect these editors to the proper pages.

In any case, you are free to tell people that I am willing to listen, to care, and to compromise. You can yourself safely ignore any such rumours. ;-)

PS: I do not know if it is because we are talking about markup, but you seem to be using underscores instead of proper italics. That means italics, right? And asterisks mean bold. I remember it from a couple of Project Gutenberg e-books. Waltham, The Duke of 16:28, 11 January 2008 (UTC)

I agree, I believe we have been, up to this point, discussing replacing every occurence of any markup for hard space by ",,". We have also hinted that there is more new markup to come. What I am saying is that I am introducing new information into the conversation, and asking people if this means we now believe it's in our interests to make a trip to bugzilla before we make a trip to WP:VP. Again, our "cloistered" process here was the right process, because we needed a while to come up with ",," as our proposal, but our process may have produced the downside that we're not in touch with how things are going to go at WP:VP.

I think I'm about out of steam here. What I'm saying is that there is opposition against your proposal at Wikia, and therefore, I suspect, opposition on Wikipedia. And as I said, now that I know there's a chance of success with this, I would also prefer a solution where the correct hard space markup is invisible most of the time and visible some of the time, mostly just because I'm trying to support the desires of the folks at Wikia and I can see their points. I'm not trying to be a wet blanket, I believe in many of your goals, just not the particular goal of having lots more visible markup on pages. If you want to take your shot at WP:VP first, go ahead. - Dan Dank55 (talk) 17:17, 11 January 2008 (UTC)

Woodstone just added an example above of a page where "p.1" (no space, but you see where he's going) doesn't mean "page 1". Good catch, Woodstone. I was just told over at Wikia that the nowiki tag gives us complete control to stop mediawiki from inserting the hard space unicode...see for yourself by pulling up the source for this: A ?. - Dan Dank55 (talk) 22:12, 11 January 2008 (UTC)

How would you make a link like PZL P.6 work? "Nowiki" destroys the link. The automatic hard space also destroys the link. −Woodstone (talk) 23:08, 11 January 2008 (UTC)

Guys, I'm going on vacation/holiday today, I probably won't have any time for the discussion until I get back in 11 days. One thread you may want to follow up is the 2-screen solution. Jimbo and Angela are devoting a lot of their energy and money to their new search engine these days, and some people assume that search will mean two screens, one for people that keep in-the-loop on what tags mean and another for people who either don't care or aren't good at it. (The first screen might be only for people who arrive at Wikipedia via search.wikia.com.) If you can get markup like ",," into the heavier-markup screen, great. If you can't and you're stuck with one screen, then you've got the burden of raising approval up to over 90% (conservatively) before the techs will even look at your proposal (historically), and the approval rate for your proposal is less than 10% (conservatively) at Wikia at the moment, based on the perception that it would mean more markup at both WP and Wikia, resulting in more work for everyone, even if the goals are noble. - Dan Dank55 (talk) 12:12, 13 January 2008 (UTC)

Zomg, an immediate and incredibly helpful reply from Angela. I love Wikia. I'm asking now for her permission to share, because it was in a Wikia-specific mailing list. Basically, she confirmed the rumor. "I hereby declare" that I am doing a 360 [sic]. I am 100% behind ",," and anything else that puts more markup into the edit window...and the more intrusive, the better (as long as no one actually blames me :). The more stuff that shows up in the edit window that forces Wikia staffers to spend their days answering edit questions from newbies, the faster we get that second screen that Angela considers desirable. (And anyone who quotes me out of context to imply that I actually want to make their lives harder, dies.) - Dan Dank55 (talk) 14:43, 13 January 2008 (UTC)

[edit] My thoughts on how to proceed

This is mainly prompted by some of Dank55's moves in the last couple of days. (See immediately above.)

Dan, I think it's useful to have some inside knowledge about the high politics of Wikipedia, and how they might affect our modest proposal. I am concerned, though, that we are exposing our push too widely in its delicate formative stages. Let's face it: until recently even many of our participants did not have a good grasp of the issues, or of where we had got to in our deliberations. How can we expect outsiders to our discussions here – even those who live and breathe WP! – to come to terms properly with any of this? Again we must remind ourselves: neither the community at large nor developers and policy-makers had so much as noticed this deficiency in markup! At least, we have found no public evidence that they had.

I would advise caution, and patience. Our detailed proposal is growing very well indeed, in the hothouse we have set up for it. It is unwise to expose it too soon to the wide world. It isn't yet fully formed. Though our deliberations are proceeding very well, there is still more to do. That includes consideration of strategy for gradually achieving the groundswell of support that is absolutely necessary if we are to succeed.

Please, let's not pre-empt our consensus about how to take this to the community, and to the decision-makers.

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

[edit] Technical discussion as in computers...

I've kinda stumbled in to this party late but I do have a question about the band:

Who exactly is going to write the code for this? I think this is a great idea - is there any specific developer who is on-side and ready to actually do it if it is approved? My impression is that all good ideas go to bugzilla, there is a voting procedure there also, then someone has to actually accept the work, do it, test it and release it.

Has anyone made contact with the developers and discussed the actual mechanics of how this will work? It looks to be be a very simple code change but I'd be interested to see the thread. Franamax (talk) 07:10, 16 January 2008 (UTC)

I'd be interested in having a look at the MediaWiki code myself; I've done some dabbling before. But I feel it's important to first properly specify what we want, regardless of implementation details as long as it stays in the realm of the possible. If it turns out that what we want is insurmountably hard (which I don't expect to be the case), we can always try to find a compromise. Phaunt (talk) 14:39, 16 January 2008 (UTC)

You can get the software here. Be prepared, it's pretty dense stuff. The main action is in the /includes directory. The file Parser.php handles page output, if you search for "function doQuotes" you will see how bold and italics are handled. The ,, markup would be handled somewhat the same except there would be no need to match pairs. Franamax (talk) 01:17, 17 January 2008 (UTC)

Yes, thanks for the links, but I already fixed a couple of bugs; admittedly pretty easy fixes, but at least I have seen and delved the code before. I'm not looking into it now but at least I could give it a shot at some point.

The reason I'm not looking into it now is that I'll defend my MSc thesis (Comp. Sci.) in a week and a half; and after that, I'll be gone with the Netherlands Student Orchestra for nearly a month (including a tour to St. Petersburg), to conclude my long student years. But at the beginning of March, I could have a look at it, if matters have progressed to that point and somebody else hasn't done it yet. Phaunt (talk) 09:37, 17 January 2008 (UTC)

Sorry for making an assumption on your level of expertise, it seemed best to reply from first principles. At some point it may be desirable to have an opinion, not that this is doable, but that this is easily doable and can be quickly done. Developer difficulty is likely to be one of the quick objections raised when the wider community gets a look at the proposal, better to have the answer ready to hand. Franamax (talk) 22:16, 18 January 2008 (UTC)

No problem, and "sorry" back if I was a bit uppish maybe. It would be nice if somebody could gauge the difficulty of implementing this (though it won't be me just now); on the other hand, I stand by my claim that unless the complexity turns out to be insurmoutable, the amount of work required shouldn't matter too much. I figure that one of the harder parts will be dealing with existing occurrences of the double-comma,if there are any—but on a project of this size, there are bound to be. Phaunt (talk) 10:33, 19 January 2008 (UTC)

I am no expert, but from what I have seen it would appear that the double comma is unsearchable with the existing search machines. We probably ought to employ a bot if we want to look for extant occurences. I could ask for help at either the Technical section of the Village Pump, or at the Bots page, but this would blow away the cloak of secretiveness we are striving to maintain over the project. Besides, I think that someone will search it on their own once we do submit the proposal to the community. Waltham, The Duke of 16:34, 19 January 2008 (UTC)

A search is complicated by the fact that double-comma inside, e.g. code tags, should be ignored. I imagine that the bot group would tell you to use a database dump. I will go ahead and write some code to at least make a statistical estimate by examining 20,000 or so random pages. Franamax (talk) 18:58, 19 January 2008 (UTC)

Fabulous idea, Franamax. Let's do it with our own resources if possible. I predict that you'll find ,, to be extremely rare. I cannot remember ever having seen it. Might it occur in some URLs? If so, that's no problem, because URLs ought to be parsed differently anyway.

It would surprise me greatly if there were any genuine technical difficulty with ,, or its possible extensions. Much more likely is that people will just claim it is difficult; and we should prepare to counter any claims like that if they are ill-founded.

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

[edit] Sections in document

It may just be me, but I cannot find the current version of the proposal summary in the complex document structure anymore. I see the changes in a "differences" view, but cannot find it by clicking on the "show" buttons. Up here in the discussion, I see only an old version. −Woodstone (talk) 14:34, 16 January 2008 (UTC)

I don't really like all that clicking on 'show' links either, but I am able to find it: under "Component 1: Summary of the proposal", click 'show' next to "Active discussion" (in an aqua bar); then, click 'show' next to either "current consensus version" or "current working version" (in grey bars). Phaunt (talk) 14:37, 16 January 2008 (UTC)

I have finally got accustomed to the whole "structure" (it is not really a structure if it is collapsible, right?)... I think it works, but it does have its disadvantages. Perhaps an easier way to navigate would be to de-collapsiblise (!) the proposal component sections and add small tables of contents to the beginning of each, each linking to the rest of these sections. It must be easy enough for those experienced in tables; I have, for some time now, wanted to learn how to make custom tables of contents, but have neglected to actually get to it. Waltham, The Duke of 14:57, 16 January 2008 (UTC)

Thanks Phaunt, I never noticed the "show" buttons in the small size grey bars. −Woodstone (talk) 20:12, 16 January 2008 (UTC)

The structure of the page is experimental, and we're learning as we go. Your comments above are helpful! Hard to balance competing needs: keep discussion rationally organised and keep everything visible at the same place and time (so people don't find that their contributions have been dismissed).

Now that we've come this far, I'll simplify the structure, archive some older things, and just have a focus on the whole draft proposal, with provision for commenting on it and editing it. Sounds OK?

I'll do that soon, and also update the stable version with a couple of uncontroversial fixes. Then more updating, when we have more comment towards consensus. Souldn't take too long at all. Then on to the next agenda item.

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

[edit] Extensions discussion

I have copied the entire discussion of extensions here. There have been recent additions, but I am about to archive that section along with other material that is not relevant to our current agenda item. To continue the discussion of extensions, click on the bar below, and add new contributions inside the navbox. (The matter of extensions as it affects the text of the proposal is now dealt with.)–N– Noetica^♬♩ Talk 07:02, 19 January 2008 (UTC)

Continuing discussion of extensions

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: mark-up converts to html symbol meaning example one line two lines ,, hard space &nbsp; space that prevents line break a b,,c d a b c d a b c d ,., hard line break <br /> forces line break a b,.,c d none a b c d ,^, zero-width space &#x200B; allows line to break without hyphen a b,^,c d a bc d a b c d ,~, soft hyphen &shy; inserts hyphen if line breaks a b,~,c d a bc d a b- c d ,-, no-break hyphen &#x2011; hyphen that prevents line break a b,-,c d a b-c d a b-c d ,--, n-dash &ndash; – ,---, m-dash &mdash; — ,.., ellipsis &hellip; … ,?, what else? 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 (-), &shy;, 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. – Noetica♬♩ Talk 07:02, 19 January 2008 (UTC) Indeed, in MS-IE line breaks routinely occur after a normal hyphens. There are cases where this is undesirable. It can be suppressed by a "nobreak" template, but easier would be some simple markup (proposed ,-,). The "soft hyphen" is one that only appears if a line break occurs. It is a way to allow linebreaks when long words make the layout ugly. It is often used in table column headings, where wrapping is necessary on narrow screens. If no soft hyphens are inserted, at some point the display will start to scroll horizontally, which is detrimental to the reading experience. The point where that happens can moved to much smaller screens by adding some soft hyphens (proposed ,~,). An optional break after a dash (as needed in Firefox) can be created by addding a zero-width space after it (proposed ,^,). Concluding: the table is not a vague wish list phantasy, but a list of often needed and used markup, which currently can only be included by rather terse HTML. Adding simple markup for these elements would be most welcome. −Woodstone (talk) 12:45, 19 January 2008 (UTC) Woodstone, you know that I am a strong supporter of your extensions work, and that I don't regard your table as representing a mere "vague wish list phantasy". It does show changes that we could wish for! And yet it is quite realistic. But I have also made clear my view that we should focus on the present limited proposal. The immediate role of those extensions, I think, is to show that what we offer has a bright future, and is not ad hoc. I'm glad you have shown that. Others will criticise the details, but that's no problem; and you have changed some details yourself. Perhaps we should not dwell too much on extensions right now, but instead be confident that when the ,, markup is secured we will have a platform for more innovation along the same lines. Play it softly, for now. – Noetica♬♩ Talk 22:07, 19 January 2008 (UTC)

---

[edit] How to take the proposal to the community

I have re-worked the page, and archived a lot. I hope it's more streamlined now.

I think the development of the proposal itself is nearly complete. This brings us to two questions of procedure:

• I want to take the proposal, after one or two points of wording are ironed out, to WT:MOS (with a link from WT:MOSNUM to WT:MOS). It needs to be exposed there to constructive criticism so it acquires ownership beyond the working group at this page. This has to be managed with care. I want to put it there as transcluded text, and ask for focused comments and suggestions, without opening up a huge debate about alternatives that we have set aside, or new alternatives. And I want to point out that this is not an invitation to vote (oppose or support). We just want wider involvement in final shaping of the details. I propose that we then continue our work at this page, rather than handing over to WT:MOS, where things get too chaotic for serious development work. Another great advantage of exposing it there is that we get valuable experience in defending it (and taking good criticism) in other forums.

  Is all of that OK?

• I had thought that we would take the proposal to WP:VPR, which seems to be the most suitable of the Village Pump pages. But it might be too quickly swamped or dismissed there. We don't want to squander opportunities. My preference now is to make a page where editors can read the proposal and sign a petition in favour of it. Do that for a while, and then present it to developers and decision-makers as having solid community support. A few hundred signatures should not be hard to get. We could make up an "activism package" for transclusion or pasting at talkpages (users' or other). This could give a summary, and a link to the full text. It could give a link to the petition page. And finally, it could have instructions for passing the package itself on to others. This is all benign: it is not spamming, since anyone passing the package on would do so with consideration of the receiver's potential interest in this issue, and it could be customised for the receiver, to explain it in appropriate terms. I like this approach because it does take a little time for the message to sink in. Just look back at some of our own vaguenesses; and at the dismissals this topic has had in the past from the relatively well-informed editors at WT:MOS and WT:MOSNUM.

  How does that sound, then?

–N– Noetica^♬♩ Talk 00:27, 20 January 2008 (UTC)

Sounds very good. But isn't there some contradiction between "this is not an inviation to vote" versus "editors can ... sign a petition in favour". −Woodstone (talk) 10:08, 20 January 2008 (UTC)

The way I read it, first we take it to WT:MOS to invite comments and criticism, but not votes. When those have been dealt with and incorporated, and the propasal has gained broader ownership, we submit it to some place where a petition can be signed.

I agree with the first part. For the second part, though we may not like it, I feel it must be possible for people to somehow show that they oppose (and give reasons for their opposition). I expect that simply omitting a channel for people to vent their opposition will almost certainly be worse for us, as they will find their own way. Further, tallying opposers gives us information about both the relative numerical importance of our supporters, and another set of objections to address. Phaunt (talk) 11:08, 20 January 2008 (UTC)

Quick response before sleep. The petition idea does seem problematic, a page to register support would seem to be an especially good place for others to put objections and questions in the spirit of WP:BOLD, so we should assume this will happen. Also, placing any links on any talk pages will result in a wide readership and possibly wide response-ship (my word :). Back Monday. Franamax (talk) 11:19, 20 January 2008 (UTC)

Yes, I meant first to give the proposal exposure at WT:MOS, and invite discussion there, rather than here. That's the first thing, and if there's no opposition I'll do that quite soon – as soon as we have that bit of text in the Overview sorted out. They might have suggestions that are useful, and we want them to "own" this proposal, yes?

Meanwhile, separately, we should think what to do after that, perhaps in consideration of advice from editors at MOS. My idea was a petition, but I'd be just happy with a vote. I would be confident of the proposal getting more support than opposition. What do people think about the self-propagating activism package that I mentioned?

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

• This all sounds fine. Expect it to be swamped and/or ignored at VP, but a link to the discussion at MOS is a worthwhile formality there, as would be another notice and link when it comes to asking for support, which might be best at MOS. I think the proposal at MOS should be kept as short and simple as possible, with invitations to comment briefly or object in the first instance, and notice that unless better ideas come up, it will be morphed into a list of supporters (within, say, a week). Just where that list should be submitted is the burning question. We're dealing with MediaWiki here, not just WP. While WP is a force at MW, it may be best to garner support first from ?ArbCom? I'm unsure. Tony (talk) 13:30, 20 January 2008 (UTC)

Thanks Tony. All well worth considering. Any other thoughts?

–N– Noetica^♬♩ Talk 02:37, 21 January 2008 (UTC)

[edit] Archiving: no more editing of the proposal

I have archived the recent fine-tuning discussion, including this final comment from me:

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

I'll now post something at WT:MOS. Let's all pay close attention to what happens there. Let's keep things well organised, and respond thoughtfully but in brief to reactions there. Most editors will not have considered things as closely as we now have. This page should stay dormant while we have discussion at MOS, I think. I'll make that clear in the page itself: at the Agenda and the Secretary's Noticeboard.

–N– Noetica^♬♩ Talk 02:45, 21 January 2008 (UTC)

[edit] New section at WT:MOS

Done! See here. I have borne in mind the need to keep things simple, but pre-emptively made three subsections. That way we can move contributions around if things get disorderly. Please help with discussion there!

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