User talk:Jimp/Archive IV

From Wikipedia, the free encyclopedia

[edit] Template Convert protection

Hi Jimp,
After I switch template convert back to the new version, would you mind if I temporarily downgraded the protection so that all users can edit (in this case revert) it if necessary? —MJCdetroit 00:04, 13 November 2007 (UTC)

Go ahead. J ɪ m p 00:10, 13 November 2007 (UTC)

[edit] Now it's LIVE

You'll need to expand that explanation table at {{convert/doc}}. I would suggest stealing a much as you can from {{ConvertW}} and {{ConvertV}}. —MJCdetroit 03:39, 13 November 2007 (UTC)

I will steal ... for the time being. I've got something else besides the kind of table we've now got mind for the long run. J ɪ m p 03:41, 13 November 2007 (UTC)

Whatever is easiest and best. Question, when you replaced ConvertWeight, did you remember to |3unit= with a space? For example right now, I am swapping out ConvertVolume which uses a lot of US gallon to imperial gallon to Liter. Just wondering? I don't think the 3 unit conversions were common in ConvertW. —MJCdetroit 03:58, 13 November 2007 (UTC)

Yep. J ɪ m p 04:08, 13 November 2007 (UTC)

[edit] Convert template

Apparently, you changed conversion templates at Greg Skrepenak and Canon PowerShot TX1 incorrectly. I am not sure what you were trying to do.--TonyTheTiger (t/c/bio/WP:LOTD) 00:04, 13 November 2007 (UTC)

[edit] Category:Unit display/doc

Hi Jimp, I saw you were trying to figure out something in Category:Unit display/doc. I created that file. If you have any questions about it just ask. P.S. I wanted to help with your work on {{Convert}} but got busy outside Wikipedia. -- PatLeahy (talk) 03:06, 13 November 2007 (UTC)

It's not actually a category, it's a piece of template documentation, and as shoukdn't be in the category namespace. So I have copied it to Template:Unit display/doc, fixed the links, and nominated it for speedy deletion as an empty category. --BrownHairedGirl (talk) • (contribs) 12:40, 16 November 2007 (UTC)

I just put some of those up for WP:TfD —-- MJCdetroit (talk) 17:03, 16 November 2007 (UTC)

[edit] Error in L to gal conversion template

I've used {{L to gal}} for quite a few motorcycle infoboxes (e.g. Honda Ruckus) and found it very useful. However, it displayed an error for US gallons if the second parameter was not defined. I fixed up {{L to gal/1}} and it seems to work now. This might be moot if {{Convert}} is taking over but I thought I'd let you know in case you want to check my work. Brianhe (talk) 17:17, 22 November 2007 (UTC)

[edit] sqmi ha subtemplate

Hi Jimp,
When you get a chance can you create a subtemplate for {{convert}} of sqmi ha? Also, could you explain how the subtemplate codes work? For example, what does each of the letters (u, n, j, b, h, o, etc) mean? Yea, some are self explanatory and some I can venture to guess, but it would be helpful to have them documented somewhere so that others (like me) could more easily produce some more subtemplates as needed. —MJCdetroit 15:40, 4 December 2007 (UTC)

Had been meaning to explain how the template works. Sorry it's late in coming. I'll get onto it. sqmi ha is done. --J ɪ m p 18:08, 4 December 2007 (UTC)

Thanks. No need to rush, but at the moment you're the only one with a complete understanding of the subtemplates. It would be in your benefit to not be the only one; no reason to work more than you need to. —MJCdetroit 18:14, 4 December 2007 (UTC)

[edit] SI template

Jimp: Regarding the SI multiples template and this edit you made your stated purpose was to “allow μ= option”. I guess I don’t understand how to use the template because no matter what I type into the template fields in the Kilogram article, (µ µ µ mc), I can’t get the “µg” to display. Would you please change the entry in the Kilogram article so the “µg” uses the µ symbol? I much prefer the micro symbol (µ) over the Greek mu (μ). I come from a computer and typography background and understand the reason for the creation of the Unicode µ symbol in the first place. It should be the default option in the template IMO. Greg L (my talk) 03:48, 11 December 2007 (UTC)

Jimp: Thank you for the fix on the SI template. Regarding you post on my talk page, the µ sign was the beginnings of an effort to eventually encode math and technical symbols so computer systems can translate to other languages by understanding the meanings of characters. Another example of this for instance, is the special “Kelvin” symbol (K), which is different from the uppercase K (here's the two side-by-side: KK. Hardly anyone uses the special kelvin symbol because it looks so damn similar to the normal Latin K. You make a good point about Latin symbols for things like “mega” (M). The Unicode committee for practical (usage and compatibility) reasons left those alone—for now. Since the µ (micro) character looks quite distinct from the Greek mu (μ), all professionally typeset material and good Web sites use it vs. the mu. It’s what a trained eye expects. Greg L (my talk) 07:35, 11 December 2007 (UTC)

P.S. Oh, another benefit of having computers understand the text, is in speaking it. I don't own a speaking algorithm myself with the capability (and don't know if one currently exists), but computers could use the special kelvin (K) character to read “36.9 K” as “thirty six point nine kelvin” rather than “thirty six point nine K.” The mu character (μ) is used for other mathematical purposes (such as representing a Möbius function) so using μ to represent µ (micro) would subvert the ability of computers to easily understand. Proper use of Unicode also gives computers the capability to convert unit symbols in print to their full unit names (“36.9 K” = “36.9 kelvin” or “45 µg” = “45 micrograms”), create lists, and other features I can’t imagine at the moment with much greater ease and reliability because computers won’t have to divine intent and meaning via context. None of these potential benefits are all that important to me. As stated above, my main point is that μ µ appear quite distinct from each other and typographically really stand out and look poor when the wrong one is used.
Again, thanks for your efforts on {{SI multiples}} and {{Convert/µW·h}}. I couldn’t imagine being able to easily parse and figure out how to make templates like that and really admire and appreciate those of we volunteers who are willing to quietly go about and help others by working on these templates. Greg L (my talk) 16:47, 11 December 2007 (UTC)

Jimp: Regarding your recent post on my talk page, I don’t know why micro and mu (µ & μ) were made to look different. I know that it’s been that way for a long time (at least to 1986). I use a Mac. It has long been that on a Mac, one uses the Symbol font to type Greek characters. But to type common math symbols, you can do it from the Mac keyboard in any font without having to go through the cumbersome process of going to a Windows-style character palette where you hunt for what you want. For instance, I can type “∆ 50 µΩ” with typographers’ quotes, the delta symbol, the ohm (omega or Ω symbol), non-breaking spaces, etc., all from the keyboard in seconds. That was option-[ for curly quote, the option-j option-space (for the non-breaking space), 5, 0, option-m, option-z for the Ω symbol, and shift-option-[ for the curly close-quote. At least since 1986, just typing option-m has yielded the µ symbol. And I’ve long seen that professionally typeset materials have the very same appearance for µg because typesetters all used film fonts (and later, digital fonts) from the same small group of professional font foundries. Greg L (my talk) 17:32, 11 December 2007 (UTC)

[edit] re: Template:Infobox Ship

I noticed that you've done several updates today to Template:Infobox Ship. But from what I understand from WP:SHIPS, that template is being deprecated and replaced with the template shown at Template:Infobox Ship Example.

From talk at WP:SHIPS, it appears that no one expects Infobox Ship to go away anytime soon because of how widespread it is used; but the long term goal is to migrate all articles using it to the newer one.

Disclaimer: I'm new to WP:SHIPS, and not a member of the project as yet. I just saw your updates and thought I would point this out in case you weren't aware as yet. --- Barek (talk • contribs) - 16:57, 11 December 2007 (UTC)

Re: your reply on my talk page ... I saw that on Infobox Ship's talk page too; but the deprecated/not deprecated talk is dated Jan 2006, almost two years ago, so I didn't weigh those comments too highly. I think the more current conversation at Wikipedia_talk:WikiProject_Ships#Deleting_obsolete_templates? is more relevant (at first it says Infobox Ship isn't going anywhere, but halfway down deprecating it is brought up). --- Barek (talk • contribs) - 17:37, 11 December 2007 (UTC)

Note:I've archived the discussions in Infobox Ship's talk pages that were dated 2006, as they appear to be non-ongoing discussions and seem to conflict with more current conversations elsewhere. --- Barek (talk • contribs) - 17:51, 11 December 2007 (UTC)

[edit] “tl” Markup

Jimp: What does the “tl” in {{tl|SI multiples}} stand for and is there an equivalent syntax to do the same thing with links to images? Greg L (my talk) 20:53, 13 December 2007 (UTC)

FYI: Tl stands for Template link (per documentation at {{Tl}}. For images, are you wanting more than just insterting a colon ":" before the word Image in the image link? The nearest relative I could find for similar links to images is {{li}}; but that one adds several additional links related to the image, so may not be what you want. --- Barek (talk • contribs) - 21:07, 13 December 2007 (UTC)

Well, let’s see… How about this CG-genenerated image? Yup, the magic colon. I didn’t know about that one. Thanks Jimp. Greg L (my talk) 00:09, 14 December 2007 (UTC)

Oops. Thanks to you both. Thanks Barek, for your above answer (that’s exactly what I was looking for) and thanks to you Jimp for your post on my talk page. Greg L (my talk) 00:15, 14 December 2007 (UTC)

[edit] Format number

I hope I have a solution to formatting numbers you approve of. Please see this update, as well as the post immediately preceding that one. Greg L (my talk) 01:01, 20 December 2007 (UTC)

[edit] …and boy do some articles need it!

Jimp, check out this part of Font size. As far as I can see, this article has been using decimal-delimited formatting since this 1 April 2006 version. As you can see however, the article has been using simple spaces (not even the non-breaking type). I submit that Wikipedia could really benefit from an easy-to-use template. I took a peak at perl, it appears to be totally beyond my expertise. Would making one take a crap-pile of time? Greg L (my talk) 03:30, 24 December 2007 (UTC)

The spaces appear to be non-breaking to me.

--206.54.145.254 (talk) 18:27, 24 December 2007 (UTC) (User:AlanH)

Oops, I guess many are indeed non-breaking. Some though, are simple-ass spaces, as shown in this subsection, Didot's point below:

* '''0.376 065 mm''' (0.0249% larger than Didot's point) — the traditional value in European printers' offices

* '''0.376 000 mm''' (0.0076% larger) — used by [[:de:H. Berthold AG|Hermann Berthold]] (1831–1904) and many others

* '''0.375 940 mm''' (0.0084% smaller) — [[Jan Tschichold]] (1902–1974), who used 266 points in 100 mm

* '''0.375 000 mm''' (0.2584% smaller) — proposed in 1975, but never adopted

Besides, my main point is that large spaces spaces (whether breaking or non-breaking) truly do look inferior. In the above example, the non-breaking nature wouldn’t matter; no one will set their browser window so narrow to need it. However, the plain ol’ spaces are—typographically wise—too wide and also produce strings that are no longer true, Excel-pasteable, numeric strings. My point also is that I wasn’t in search of examples of decimal delimiting when I stumbled across this article. Upon finding it, I noticed the delimiting method used in numeric strings and recognized it as a good show piece for something I’ve been advocating lately: a number-delimiting template.

It’s clear that the simple use of full-width spaces isn’t an uncommon technique whatsoever on Wikipedia. Even though the regular-size spaces are large and make numeric strings appear like separate values, it seems readers readily understand and adapt. This common-sense observation flies in the face of SMcCandlish and his reasoning for opposing a template. He wrote “It [delimited decimal strings] is not understood by most readers”. Hogwash. Many Wikipedia articles have displayed numeric strings for years that have had full-width spaces in them. So it’s obvious on the face of it that using em-based span control to delimit would make it even easier for readers to recognize and understand what they’re looking at.

I think Font size is a textbook example of how Wikipedia could benefit from a template for delimiting numeric values with proper-size, em-based pair kerning (span control). It would make editing much easier, harmonize numeric strings across articles, make numeric strings much easier to understand, make numeric strings look more professional, and make numeric strings true, Excel-pasteable numeric values. Greg L (my talk) 09:15, 25 December 2007 (UTC)

[edit] Jerry Beck's Not Just Cartoons: Nicktoons!: It could give enough info to create separate character articles

I found a book in the bookstore called Not Just Cartoons: Nicktoons! by Jerry Beck. I'm not going to buy it and join the project, but I will ask the other members to get the book so that they can add real world information about various fictional characters.

This makes the creation of separate articles for *many* fictional characters feasible. Having information about the development of the character will make the articles satisfy Wikipedia:Notability (fiction)

In this case, the source has a lot of information about Ren and Stimpy and one could possibly write separate articles for each character. WhisperToMe (talk) 06:39, 25 December 2007 (UTC)

[edit] Convert st lb (lb/kg)

Merry Christmas and happy New Year Jimp,

Can the default be switched on this 'st lb' subtemplate so that it reads X st X lb (X kg/X lb)? I am not asking that it be done (yet), just if it is easily possible? I think that someone may have been hinting that the lb (X lb/... confuses them.

{{convert|13|st|7|lb|0|abbr=on|lk=on}} to produce 13 st 7 lb (86 kg/189 lb)

Regards, —MJCdetroit (talk) 14:25, 27 December 2007 (UTC)

Merry Christmas & a happy New Year to you too MJCdetroit,

Yes, it can be done ... no ... it was able to have been done but no longer since it's already done and 'twas easy enough ... easier than typing this convoluted sentence. I'd thought that since the first was not really a conversion as such—merely expressing the same thing in different terms—it aught to come first but a cause of confusion, I can see that. P.S. it's {{convert/and/lb}} not {{convert/st lb}}, the latter gives you conversions to both stones and pounds, e.g. {{convert|100|kg|st lb}} gives 100 kilograms (16 st/220 lb). J ɪ m p 19:18, 27 December 2007 (UTC)

Thanks, but Question #2: Is there a way to have convert display something like this: 185 pounds (13 st 3 lb/84 kg). Right now it only shows stones in the decimal way{{convert|185|lb|st kg}} 185 pounds (13.2 st/84 kg) Regards, MJCdetroit (talk) 04:08, 28 December 2007 (UTC)

Also, conversions to pounds & ounces and feet & inches. Of course, there is a way, always a way. The much awaited conversions the other way. Still in the planning phase, though (I'd thought that this should be easier but I think I thought wrong ... won't be hard though). J ɪ m p 16:45, 28 December 2007 (UTC)

[edit] Back at ya (re formatnum or “delimitnum”

Jimp, nice to hear from you. My response to your post is here. Greg L (my talk) 20:46, 27 December 2007 (UTC)

Jimp: I’ve clarified and better-organized the “nutshell” on my talk page regarding a “delimitnum” template/parser function (magic word). Thunderbird2 reports that due to our lobbying and arguments, the momentum at MOSNUM is shifting our way. He has pledged to maintain “low key lobbying at MOSNUM.” Is the parser function a task that you’re still interested in undertaking? Greg L (my talk) 04:40, 8 January 2008 (UTC)

[edit] bleh

		The da Vinci Barnstar
		I thought I knew how to code complex templates... then I saw {{convert}}. This is for not going insane. —Random832 16:47, 11 January 2008 (UTC)

[edit] Barnstar for template construction

		The Template Barnstar is bestowed upon you
		For the HUGH overhaul of {{convert}}. Wikipedia is better off for having you— the 800 lb (363 kg/57 st 2 lb) gorilla of template construction— around. — MJCdetroit ^(yak) 00:34, 13 January 2008 (UTC)

[edit] Please verify

Jimp,
Could you please verify my copy, paste, and tweek technique of {{Convert/ha sqmi}}? That will also need the category added to it.

Also, could you create an explanation page of what all the sub template parameter letters mean? Some are ease to figure out, b= is base in an SI unit, where area is in sq meters, but others are not so easy. Like what is j=? In any case, an explanation page is very much needed. Thanks —MJCdetroit ^(yak) 18:03, 14 January 2008 (UTC)

Looks okay ... did fix it though. Yeah, sorry for not getting around to that yet. This might give you a hint {{convert/unit}}. j = log₁₀(b) i.e. the logarithm of the conversion factor to the base SI unit used for default rounding. J ɪ m p 18:13, 14 January 2008 (UTC)

Thanks. It's been years since my last math class. That being said, how did you know to use 4 instead of 6? —MJCdetroit ^(yak) 18:47, 14 January 2008 (UTC)

If j = log₁₀(b) then b = 10^j.

1 ha = 10⁴ m²

So for the hectare j = 4. For the square mile it's not so easy to figure out: you'd need a table of logarithms, a (decent) calculator, to be really good at arithmatic or a computer. I stick "1609.344" in A1 and "=log(A1)" in B1 in Excel. A1 is b & B1 is j. J ɪ m p 23:42, 14 January 2008 (UTC)

Thanks, I think I get. I think in your example it should have been "2589988.110336" in A1 because we are talking about how many square meters in a square mile and not about how meters in a mile. Thank again. —MJCdetroit ^(yak) 21:11, 15 January 2008 (UTC)

[edit] Please verify part deux: Population density

Hi again Jimp,

I've created a series of sub-templates based on population density. They are some what subdivided into a "/unit" and a "PD/unit". The "PD/unit" will added the words "inhabitants per unit X. Think that everything is correct but a second set of eyes (yours) can't hurt. However, I am getting one weird error/oddity with the /acre and PD/acre templates. They don't abbreviate like they should, i.e /acre and not per acre, etc—see below. Can you please proofread the following subtemplates? P.S. I haven't created any multiple sub templates yet, so no converting per acre into per sq km and per sq mile.

{{convert|100|/sqkm}} -> 100 per square kilometre (260 /sq mi)

{{convert|100|PD/sqkm}} -> 100 inhabitants per square kilometre (260 /sq mi)

{{convert|100|/ha}} -> 100 per hectare (40 per acre)

{{convert|100|PD/ha}} -> 100 inhabitants per hectare (40 inhabitants per acre)

{{convert|100|/acre}} -> 100 per acre (250 /ha)

{{convert|100|PD/acre}} -> 100 inhabitants per acre (250 /ha)

{{convert|100|/sqmi}} -> 100 per square mile (39 /km²)

{{convert|100|PD/sqmi}} -> 100 inhabitants per square mile (39 /km²)

{{convert|100|/sqmi|/acre}} -> 100 per square mile (0.16 per acre)

{{convert|100|PD/sqmi|PD/acre}} -> 100 inhabitants per square mile (0.16 per acre)

{{convert|100|/acre|/sqmi}} -> 100 per acre (64,000 /sq mi)

{{convert|100|PD/acre|PD/sqmi}} -> 100 inhabitants per acre (64,000 /sq mi)

{{convert|100|/ha|/sqkm}} -> 100 per hectare (10,000 /km²)

{{convert|100|PD/ha|PD/sqkm}} -> 100 inhabitants per hectare (10,000 /km²)

—MJCdetroit ^(yak) 16:43, 21 January 2008 (UTC)

Template:Convert//ha (edit|talk|history|links|watch|logs)
Template:Convert//acre (edit|talk|history|links|watch|logs)
Template:Convert/PD/acre (edit|talk|history|links|watch|logs)
Template:Convert//sqmi (edit|talk|history|links|watch|logs)
Template:Convert/PD/sqmi (edit|talk|history|links|watch|logs)
Template:Convert//sqkm (edit|talk|history|links|watch|logs)
Template:Convert/PD/sqkm (edit|talk|history|links|watch|logs)

Thanks. I've checked the above & made some adjustments: hyphens & singular for h (this is for adjectives) and exact figures (i.e. fractions) for b (do you calculations with excat figures and round at the end).

On a different note, metric ton vs metric tonne. Well, neither are terms we use in Austrtalia, so I'm wading a little out of my depth perhaps, but in (current) English there is no other tonne than 1000 kg so the metric bit in metric tonne would be redundant. On the other hand, the metric bit makes perfect sense if you're considering the tonne to be a kind of ton to be distinguished from the short and the long ones.

Well, there's glory for you (as Humpty might say) but it'll be a cold day in Hell before the English language conforms to "logic", so I Googled the terms. Metric ton won by about 5:1.

J ɪ m p 00:36, 22 January 2008 (UTC)

How did you come up with the fraction (78125/316160658)?

Here in the U.S. and in Canada, a ton is 2000# for 99% of the population unless you work on boat or just got off of one (the last part was sarcasm that you may not get). 1,000 kg, when it is mentioned, it is always referred to as a "metric" ton or metric tonne. Have you ever seen the movie, Austin Powers? Powers describes "fat bastard" as weighting a metric tonne. I do agree that metric tonne is a little redundant for the folks who are used to tonne. But having metric in front does help some of my fellow yankees. In my personal opinion, I think that having "tonne" by itself maybe viewed incorrectly as the "British way" of spelling ton; much like program vs. programme. That's probably why we always hear the term metric t... If you want to switch it back to ton, it wouldn't upset me in the least bit. I was just trying to use the tonne term with the metric term. —MJCdetroit ^(yak) 02:11, 22 January 2008 (UTC)

I'd been meaning to see that movie. Some interesting points there. Yeah, tonne mistaken for some British spelling of ton, I could see that ... of course, links and/or context (especially other metric units) might help to clear that confusion up ... if it's not already obvious from the fact that this is a conversion (likely to or from a short and/or long ton). We've got three possible terms:

tonne
metric ton
metric tonne

I prefer 1, 2 is a distant second but I'll cope with it in the appropriate context, as for 3 ... it just seems plain wrong like dairy milk, aquatic fish, feline cat, etc. Though, it's not as if it's never used ... chai tea ...

So, interesting arguement for metric tonne over tonne but what about metric tonne vs metric ton? You write you "always hear the term metric t..." Actually, what do you hear, metric tonne (rhyming with gone) or metric ton (rhyming with gun)? I haven't spend long enough in North America to guess the answer and Google says only so much.

What are our options, then? It seem to me that we've got two reasonable options at hand.

a. We could make allowances for all three.

b. We could choose between metric ton or metric tonne.

If it's to be b. then perhaps my talk page ain't the place to decide which (nor even convert's talk, we should take it to WT:MOSNUM). I don't think that disallowing plain tonne is an option: this is the normal name for the unit outside North America neither metric ton or metric tonne is ever used in Aussie English. J ɪ m p 03:38, 22 January 2008 (UTC)

An acre is a furlong by a chain. A chain is 22 yards & a furlong 220. A yard is 0.9144 metres. so an inverse acre is

¹⁰⁰⁰⁰⁄₉₁₄₄×¹⁰⁰⁰⁰⁄₉₁₄₄×¹⁄₂₂×¹⁄₂₂₀ m⁻²	= ¹²⁵⁰⁄₁₁₄₃×¹²⁵⁰⁄₁₁₄₃×¹⁄₂₂×¹⁄₂₂₀ m⁻²
	= ¹²⁵⁰⁄₁₁₄₃×¹²⁵⁄₁₁₄₃×¹⁄₂₂×¹⁄₂₂ m⁻²
	= ⁶²⁵⁄₁₁₄₃×¹²⁵⁄₁₁₄₃×¹⁄₁₁×¹⁄₂₂ m⁻²
	= ^625×125⁄_{1143×1143×11×22} m⁻²
	= ⁷⁸¹²⁵⁄_316160658 m⁻²

J ɪ m p 03:55, 22 January 2008 (UTC)

It's ton pronounced like 'gun'. Like I said, I prefer having the term metric before ton/tonne. I am kind of indifferent about ton/tonne, but your arguement is making lean toward 'ton' for an unseen/stated affect that metric tonne may have on editors removing the "metric" part. That being said maybe I should revert that spelling change. —MJCdetroit ^(yak) 04:25, 22 January 2008 (UTC)

[edit] Hyphens

Thanks for the heads-up. 4u1e (talk) 10:09, 15 January 2008 (UTC)

[edit] Hard spaces again

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 ( )

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   code (17 sq 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 (italic text and bold text 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 sq 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 (, ) or ends (, ). 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  . 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 +  . This could conceivably be needed in a complex subscript, like this: W_{1, 2, 3, ... , n} (markup: W1,,,2,,,3,,,...,,,n).
It is hard to think of a case in which the reverse would be needed (  + comma); but if that ever did arise, <nowiki></nowiki>,  , 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   +  . A similar interpretation would apply to any string of 2·n commas: it would be parsed as n instances of  . And similarly for longer even-numbered strings of commas. If the editor intended comma +   + 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 +   +  . And similarly for longer odd-numbered strings of commas. If the editor intended   + comma +  , 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  . 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   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 sq in – 3 sq 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  , 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  tag, which is interpreted differently by different browsers with unpredictable results. Use of   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  . 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  . 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  and  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 ; ,--, (for an en dash: equivalent to – or –); and so on. Such markup could be combined: ,,,--, (for an en dash with a hard space before it: equivalent to  – or  –). 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   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.

Progress, yes? Hope to see you there, Jimp.

– Noetica^♬♩ Talk 07:18, 16 January 2008 (UTC)

[edit] TfD nomination of Template:Aust Beer Glass

Template:Aust Beer Glass has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you. -- Mark Chovain 08:18, 17 January 2008 (UTC)

[edit] Conversion template

Thanks for your note. Can you tell me why it's been removed though? Thanks AreJay (talk) 12:36, 17 January 2008 (UTC)

Nevermind...I realize why it was removed now. Thanks! AreJay (talk) 12:38, 17 January 2008 (UTC)