Wikivoyage talk:One-liner listings

Please also see relevant discussion at Wikivoyage talk:Spelling

See also: Wikivoyage talk:One-liner listings/Archive

Relaxing the rules a bit

I'd like to consider relaxing the "preferably one phrase" rule for regions, and maybe even districts. One could even argue for relaxing it for cities at the lowest levels of the hierarchy only.

Why? Well, let's look at something like New York (state). Would single-phrase descriptions really give a traveler any sort of way to make a choice among the regions? Sure, at the continent level, these things are just navigation tools, but at lower levels of the hierarchy, the traveler might have some idea what area he wants to visit (say, New York State) but not know what the various travel sub-regions of the area have to offer. Yes, he can (and should) click through to find out all the details, but it seems to me that the descriptive text on the super-region page can help him narrow down his choices. I think the regionlist template also looks far better with complete sentences than with simple phrases uncapitalized and unpunctuated:

Subregion several quaint, historic towns and one BigCity

versus

Subregion With almost a dozen quaint, historic towns scattered among rolling hills and valleys, Subregion is a great place to explore after visiting the National Basketweaving Hall of Fame in BigCity.

I can see the logic behind keeping descriptions short for our lists of "Cites" and "Other Destinations", which are used for navigation only, but I think a sentence or two is much more useful to the traveler when we're talking about complete lists that the traveler must choose from to descend in the hierarchy.

-- (WT-en) LtPowers 12:00, 28 October 2009 (EDT)

If we could perhaps agree first that the description (be it one line or more) is a sentence (i.e it starts with a capital and ends with a full stop) then that would be a step forward I believe. Those uncapitalised, unpunctuated phrases have always looked very odd to me and I am sure I have (unintentionally) written proper sentences instead in some regional articles. I think LtPowers makes a very good point and that two sentences could be appropriate at times. --(WT-en) Burmesedays 12:15, 28 October 2009 (EDT)

I still prefer them in phrase "form." The second subregion description LtPowers used would be fine, IMO, if the period were removed and the first letter "de-capitalized." The point is simply to avoid having too much information included in the regions, cities, and ODs sections (since they are there only for quick navigation) when that information belongs properly in the see, do, buy, eat, drink, and sleep sections. For whatever reason, there has always been a general impulse to cram everything into the one liner lists, and I think this policy has been useful in deterring that. It's a fairly minor point, though, so I won't be inflexible; let the discussion continue ;) --(WT-en) Peter ^Talk 19:42, 28 October 2009 (EDT)

I totally agree in cases where they are only used for quick navigation. But my contention is that they should be used to impart actual, useful travel information in the article immediately above them in the hierarchy. And this just looks silly and unprofessional to me:

Subregion with almost a dozen quaint, historic towns scattered among rolling hills and valleys, Subregion is a great place to explore after visiting the National Basketweaving Hall of Fame in BigCity

-- (WT-en) LtPowers 22:24, 28 October 2009 (EDT)

We already have some pages like the second proposal, and I agree that it look much better. See Chugoku. It's still technically a one-liner for each prefecture listed, but there is enough to hint at the flavor of each. I also like the capitalization and period on this page. (WT-en) ChubbyWimbus 22:50, 28 October 2009 (EDT)

I think I'm a holdout here, so I'll go with the majority for the change to sentence form. How is this language: One-liner descriptions should be brief and to the point, preferably no more than one sentence. Further detail about the destination belongs should go in the rest of the article, as well as the article for the destination in question. --(WT-en) Peter ^Talk 22:31, 22 December 2009 (EST)

Well, for the record, I have no problem with short, fragmentary sentences for City and Other Destination lists in higher levels of the hierarchy. I think we should make that distinction. (WT-en) LtPowers 09:18, 23 December 2009 (EST)

I'm pretty sure that "*[[Maputo]] — the capital and largest city." is a complete sentence, with the mdash standing in for "is" (I could be mixing up Russian & English grammar, though). So basically the only change I'm now suggesting is to add periods to the end.

The regionlist template uses a wholly different form, where the description is on a different line than the name, and therefore is more appropriately capitalized.

As to relatively how much description to give where and when, within the confines of just one, at the most two sentences, I'd rather leave that to discretion, and I think we'll wind up achieving the result you are looking for. --(WT-en) Peter ^Talk 14:15, 23 December 2009 (EST)

I would still rather we come out and say that most Cities and Other Destinations lists should be short and sweet (one or two phrases), while immediate subregions (and maybe Cities and ODs for bottom-level regions) should have longer descriptions (one to three sentences). If we stick with your wording, we could get either of my two examples from the top of this section, when I think each is distinctly preferable in different situations. (WT-en) LtPowers 19:12, 20 January 2010 (EST)

If you think it worthwhile, please go ahead and add that. --(WT-en) Peter ^Talk 22:12, 20 January 2010 (EST)

Have a look: [1] (WT-en) LtPowers 10:15, 21 January 2010 (EST)

Agree with LtPowers, the Cities, OD and Get outlists should be brief (one sentence, no dot and not capitalized), but I think this looks weird when using the "regionslist" template. There I'd rather just see a full sentence. --(WT-en) globe-trotter 14:13, 21 January 2010 (EST)

Peter, in English, sentences must contain verbs. "Maputo — the capital and largest city." is not a sentence, and therefore should not end with a full stop. Students and other writers sometimes get a joke comment about this from their teachers or editors: "No verb this sentence".

On a related point, "Maputo is the capital and largest city." is a complete sentence (subject+verb+complete thought) and therefore requires both capitalization of the first letter and a full stop. Punctuation needs to be determined by grammar, or we'll look sloppy and unreliable. WhatamIdoing (talk) 16:10, 8 November 2015 (UTC)

Back to dashes

The last question still unresolved for this policy is that of the hyphen v. mdash. I've probably already made this point, but the hyphen is grammatically incorrect, as its sole purpose in the English language is to hyphenate. Whereas one of the several functions of an mdash is precisely what we are using it for in these one-liner lists—a parenthetical serving to define or clarify the preceding phrase or term. Per WP, mdashes can be used where a full stop (or "period") is too strong and a comma too weak. Em dashes are sometimes used in lists or definitions.

This may seem like hairsplitting, but this policy is really all about splitting hairs—defining our standard, preferred formatting. --(WT-en) Peter ^Talk 22:12, 20 January 2010 (EST)

The emdash is just harder to type. Simplicity over pedantry I say. --(WT-en) inas 23:11, 20 January 2010 (EST)

A single hyphen is too short; the em dash is much more readable. Star articles should use em dashes, but I certainly wouldn't reprimand anyone who used a hyphen (or, preferably, two or three); it's easily fixed. Maybe we could include the em dash (and maybe non-breaking space) in the click-to-insert grouping at the bottom of the edit page? (WT-en) LtPowers 10:01, 21 January 2010 (EST)

The correctness of using mdashes as proposed cannot be disputed. They are just a pain in the ass to compose, so few bother. A quick click-to-insert feature is a good idea.--(WT-en) Burmesedays 10:07, 21 January 2010 (EST)

I actually think the em dash use seems about as common nowadays as the hyphen, especially since more experienced editors have been adding them, and regular users are the more likely to create region articles. Inas' argument would apply to punctuation anywhere in the article—I think its fair to say that writers will often use incorrect punctuation, grammar, formatting not in line with our standards, etc., but I see no reason we shouldn't aim to correct that when polishing up an article.

I've added a char-insert for * — [[]] to the edittools box. We can revert that if we determine to use a different format. --(WT-en) Peter ^Talk 14:04, 21 January 2010 (EST)

Isn't there a way to make it easier to type such a dash? For example, make it that typing --- automatically turns into a dash while the page is saved. --(WT-en) globe-trotter 14:21, 21 January 2010 (EST)

There's always — (and its cousin –), which requires no hard-to-find key combinations, though I don't know if a seven-character replacement can honestly be called "easier". — (WT-en) D. Guillaime 14:26, 21 January 2010 (EST)

I know mdash by now, but I think for most newer users it is a bit of a complicated combination. --(WT-en) globe-trotter 14:31, 21 January 2010 (EST)

* — [[]]? Shouldn't it be * [[]] — ? (WT-en) LtPowers 17:07, 21 January 2010 (EST)

Indeed, fixed. --(WT-en) Peter ^Talk 17:13, 21 January 2010 (EST)

I think some wiki's set up a template so — results in an emdash. Perhaps this template, or even a more general template for one liner listings could resolve any formatting differences? --(WT-en) inas 17:27, 21 January 2010 (EST)

What is a char insert? The template sounds like a very good idea. --(WT-en) globe-trotter 18:15, 22 January 2010 (EST)

Character insert, I should say. It's down below the edit window below the one-click listings templates (with {{}}, |, #REDIRECT [[]], etc.). --(WT-en) Peter ^Talk 18:21, 22 January 2010 (EST)

I've also now made "Template:-", so you can enter — to automatically create an em dash. It's advantage over — is that it doesn't leave the ugly — html code visible when editing. The disadvantage is that it seems just a little slower to type (in QWERTY anyway). If you don't like the html in the edit screen, copy a — from the article or elsewhere and do a Find + Replace to get all of them in the article. (I'm really loving FoxReplace [2].) --(WT-en) Peter ^Talk 18:27, 22 January 2010 (EST)

This is less of a concern, but I'd like to know to be sure. Should we leave spaces before and/or after mdashes, i.e. which of the following is the (most) correct:

• Foo—beautiful city (no space)
• Foo— beautiful city (space only after mdash)
• Foo — beautiful city (spaces at both ends of mdash)

I think the third form is the most esthetically superior, though I am almost always inclined to use (and really get used to) the second form after, if I'm not mistaken, User:(WT-en) MarinaK, who said to be experienced at publishing commercial guidebooks, made a number of proofreading edits that use the second form.—(WT-en) Vidimian 10:53, 26 January 2010 (EST)

I agree that the 3rd example looks the nicest. I think (only think) that the 2nd example is strictly correct though; the dreaded mdash is treated like a comma with no space, then a space. Both here and at Wikipedia you often see the 1st example format as well :). --(WT-en) Burmesedays 11:03, 26 January 2010 (EST)

We have been using the third form for one-liner lists, and I think there's universal support to keep those spaces. In prose, both the first and third formats are acceptable in modern publishing—use without spaces is more conservative and favored by (if I'm not mistaken), Chicago, Harvard, Oxford, and me. The second form is not correct. --(WT-en) Peter ^Talk 12:39, 26 January 2010 (EST)

Peter is absolutely correct, although I admit I didn't realize that the third form was acceptable to some guides. But for one-liner listings, it's what we should use because it's serving a different function than it does in a sentence. (WT-en) LtPowers 18:34, 26 January 2010 (EST)

The template — is interesting, but don't we try to avoid leaving templates in articles? Meaning you would need to type {{subst:-}} which then isn't much of a shortcut? – (WT-en) cacahuate ^talk 03:01, 28 January 2010 (EST)

Routeboxes, ispartOf, etc?? --(WT-en) inas 07:03, 28 January 2010 (EST)

Yeah, it's still not ideal. I added an em dash char insert to the edit tools window, although of course you would still need to scroll down to click it (I wish we had control over the buttons that display at the top of the edit window...). In Linux and MacOS, I believe, you can set up your keyboard to type em dashes and en dashes pretty easily [3]. I'm sure there's a way to do so in Windows too. But like I said, if someone wants to clean up the html or wiki markup used to create dashes, you can just do a find and replace, which takes all of one second if you can do it in your browser. (Otherwise you'll need to take the extra step of pasting it into a text editor.) --(WT-en) Peter ^Talk 14:26, 28 January 2010 (EST)

If anyone is really keen to do this, the simplest solution would be use a key-redefiner. Eg, you could set Ctrl+Q to type & m d a s h ; the 7 characters required to compose an emdash. That is probably the simplest solution for the lazy. I think that is the only way to type an emdash using a single keyboard action in Windows. There is a suitable shareware app here. --(WT-en) Burmesedays 21:30, 28 January 2010 (EST)

Given that it is somewhat rare to get this form of agreement on something grammatical, should we now move the essense of this consensus (that is, the actual formatting preferred) to the main article? --(WT-en) inas 02:41, 2 June 2010 (EDT)

Yes.

I've just added:

• Use an em dash, not a hyphen — with one space at each end

Done --W. Frank^e-mail_talk 15:06, 31 August 2013 (UTC)

Update

I've just changed the text to be "not wrong". The options are:

• An em dash with no spaces: This—the example here—is correct.
• An en dash with spaces on either side: This – the example here – is also correct.

I don't care which one people want (they're both equally easy on a Mac keyboard), but we shouldn't choose the one that is rejected by all typography sources and reputable style manuals as being incorrect. WhatamIdoing (talk) 16:14, 8 November 2015 (UTC)

As pointed out in the prior discussion, the rule you're citing is for prose. The em-dashes here are serving a different purpose, and aesthetically it's best for them to be spaced. Furthermore, you're wrong that the open (spaced) em-dash is rejected by "all typography sources and reputable style manuals". According to Wikipedia, the AP Stylebook and the NYT Manual of Style support open em-dashes. Powers ^(talk) 01:29, 10 November 2015 (UTC)

Wikipedia allows spaced en dashes between parts of list items, which I personally like. Just saying. Nurg (talk) 07:25, 10 November 2015 (UTC)

I like it in that context. In this one, I think the added separation of the em-dash is a better fit. Admittedly, we could go either way, but we've used spaced em-dashes for a very long time and there's nothing wrong with them. Powers ^(talk) 19:34, 10 November 2015 (UTC)

Actually, the AP Stylebook explicitly rejects this use of the spaced em dash: "An em dash, like an ellipsis, has a space before and after, except when used to introduce items in a vertical list." The New York Times uses spaced em dashes in print only, explicitly due to line-wrapping limitatins (according to their style book). They do not use it on their online copy (which uses spaced en dashes). So, yeah: All the reputable sources, including the two that allegedly say the opposite. WhatamIdoing (talk) 02:10, 11 November 2015 (UTC)

A Google search failed to reveal examples of what AP means by using an em-dash to introduce items in a vertical list, but as near as I can tell they mean immediately preceding the entire list, not embedded within the list. (Regardless, since your example sentence does not involve a vertical list, the AP would use spaced em-dashes, rendering your blanket claim strictly incorrect.) I will accede to your analysis of the NYT style guide (without access to the books, I can only go by what others say about them), but suggest you update the Wikipedia article on dashes accordingly. All that aside, however, I reiterate that our use of the em-dash here is outside the scope of the usual style-guide advice, as it is not running prose. Powers ^(talk) 18:51, 11 November 2015 (UTC)

Clearer language: "no dots"

It is not only folks with English as a Mother tongue that read here.

When I read on the article page here this bald and enigmatic phrase:

"* No dots — these are concise descriptions, not full sentences"

I was very puzzled as to what it meant.

Ellipsis? Aposiopesis?

What sort of "dots" was the article writing about?

I had to read for more than half an hour to discover that, because the topic was short, summary, one-line phrases, our style policy was that they should not be terminated with either a "full stop" (UK English) or a "period" (US English) lest they "grow like topsy".

That is why I made the following edit in an attempt, to make things clearer: http://en.wikivoyage.org/w/index.php?title=Wikivoyage%3AOne-liner_listings&diff=1893481&oldid=1893472

I was reverted without further discussion but perhaps someone, with better language skills than I, could hone the language here. I agree it needs to be short and punchy - but not by risking clarity. It is a policy page, after all, and should be quickly intelligible. --W. Frank^e-mail_talk 21:53, 2 October 2012 (CEST)

I've had a go. I think it is clear enough now. --Inas (talk) 02:38, 3 October 2012 (CEST)

Ndashes, not mdashes

This guide is incorrect in recommending spaced mdashes. See en:w:WP:DASH and en:w:dash for instance. Hyphens are certainly wrong but so are mdashes in this context. —Justin (koavf)❤T☮C☺M☯ 16:43, 3 November 2017 (UTC)

What do you mean "incorrect"? It's house style; each house gets to define its own style. And anyway, the general rule that you only space en-dashes and never em-dashes applies to prose; here the em-dashes are used as graphical elements separating a name from a description; it would look very strange unspaced, don't you think? Powers ^(talk) 17:48, 3 November 2017 (UTC)

@LtPowers: Styles can be incorrect tho: we could have a style to use semicolons for listings. One of the functions of ndashes is to use as graphical elements separating a name from a description. I agree that they should not be unspaced: they should be replaced with ndashes. —Justin (koavf)❤T☮C☺M☯ 17:50, 3 November 2017 (UTC)

We've been over this before, four years ago. Even reviewing the discussions above, I'm not sure how em-dashes got the nod over en-, but they did. As I said four years ago, if we're going to change a longstanding convention it has to be done by consensus. Powers ^(talk) 18:48, 3 November 2017 (UTC)

@LtPowers: I agree. That's why I posted here... —Justin (koavf)❤T☮C☺M☯ 18:57, 3 November 2017 (UTC)

I strongly support changing to en dashes. Em dashes are unnecessarily long. As a visual element, the en dash is perfectly adequate to my eye, and the em dash a bit of overkill. There is a small disadvantage with em dashes. Some one-liner lists have a map to their right. For readers who have a somewhat narrow browser window, the map forces the one-liner list into a fairly narrow and long block, with some amount of word wrapping. Em dashes cause slightly more word wrapping than en dashes, and I think this undesirable. I am strongly in the Robert Bringhurst camp – his The Elements of Typographic Style is quoted at en:w:Dash#En dash versus em dash, saying the em dash "belongs to the padded and corseted aesthetic of Victorian typography." Nurg (talk) 02:07, 4 November 2017 (UTC)

I support changing to spaced en-dashes too. —Granger (talk · contribs) 14:57, 23 February 2018 (UTC)