Wikivoyage talk:Manual of Style/Archive 2003-2013

From Wikivoyage
Jump to navigation Jump to search

Area codes and phone numbers

Is there a standard format for telephone numbers? (203) 555-1212? 203-555-1212? 203.555.1212? (WT-en) Hanzo 11:08, 30 Oct 2003 (PST)

I think the international format is +1 203 555-1212. The '+' stands for the international access code (which will be 00 for most countries, but not all). The 1 stands for the country code, the 203 for the area. (In countries where the area code starts with a 0 it is not normally dialed from a location outside that country. It can be indicated like '(0)203'). A European (Belgian) example would be: +32 (0)15/12.34.56 (BTW, this is not my number :-) (WT-en) D.D. 12:15, 30 Oct 2003 (PST)
HOLY CARP, that's long and complicated. Americans are going to hate that. But, I guess, it's pretty fair. -- (WT-en) Evan 12:23, 30 Oct 2003 (PST)
Do we agree that this international format should be used for all telephone listings on the site? If so, then maybe it should be added to the manual of style. Or maybe it's not that important to standardize this? (WT-en) Hanzo 12:20, 30 Oct 2003 (PST)
I prefer standardizing everything -- I think it stops silly arguments real fast. That international format seems funky to me, but maybe we should use it. In most of the listings it says to leave off the area code if it's not different from the "main" area code for the city, so I think this might be a change. I dunno. DD? -- (WT-en) Evan 12:23, 30 Oct 2003 (PST)
If I'm trying to call a place in NYC, I have no idea what the main area code is or how to find out. I definitely prefer to have all of the information there in my printed-out copy of my Wikivoyage page. (WT-en) Hanzo 12:29, 30 Oct 2003 (PST)
We should definitely always list the full, international telephone number. ie: +11 222 3333-4444. Where: 11: Country code; 222 area code; 333 phone number; -4444 extension. There is really no alternative to this. -- (WT-en) Nils 08:57, 6 Apr 2004 (EDT)
I agree with Hanzo. If I have to make a phone call in a foreign country , I'd like to have all the information I need at hand. And it's not even that complicated once you get used to it. How do you think we manage in all those little countries in Europe with all those different country/area/city codes ;-) (WT-en) D.D. 12:50, 30 Oct 2003 (PST)
Coming to think of it, a compromise could be to include the international access code and country code in the country article. (WT-en) D.D. 12:54, 30 Oct 2003 (PST)
But then again the problem is that this is not a traditional travel guide. People can choose not to take a printout of the country article with them on their travels... (WT-en) D.D. 12:58, 30 Oct 2003 (PST)
Well, does everyone already know that US phone numbers are +1? If so, we could institute a UScentric double-standard of 203 555-1212 for US numbers, and +32 (0)15/12.34.56 for everywhere else. Or, we could just get used to the international standard. (WT-en) Hanzo 13:06, 30 Oct 2003 (PST)
Personally, I hate US- or "whatever other country-centricity". I say let's go for international-centric. (WT-en) D.D. 13:10, 30 Oct 2003 (PST)
I agree. Let's standardize. Evan? (WT-en) Hanzo 13:19, 30 Oct 2003 (PST)
I'm down with it. Why don't you write it up on the Man of Sty page, Hanzo? -- (WT-en) Evan 13:25, 30 Oct 2003 (PST)

So the "usual" way travel guides deal with this is to list the country code in the intro/general information about a country (ie our "Communicate") and then list the numbers in listings how you would dial them from the area. There are some places where you cant dial the full number from that area and what you should dial isn't always clear e.g. in Geneva you always have to dial the area code, even if it's the same as the phone you are calling from, but you drop the initial 0 if you are calling from outside the country. So we list "+33" as the country code for France (and also mention it on the city pages in France), and the area code in the article about an area, and just the local number in the actual listing. Otherwise I'd have to say go with the full international number everywhere (not everyone knows that the US and Canada have the same country code for example).

just my +41 (0)79/555.0002 cents. (WT-en) Majnoona

Hey, so, did your browser put in all those escaped quotes, or did you do it? -- (WT-en) Evan 13:46, 30 Oct 2003 (PST)
Well, now I'm confused. It seems to me that most of the time, a person calling one of places in this guidebook would be calling from the general area of the place. If you're calling a restaurant in Boston, you are probably in or near Boston. So, the most useful listing would be the one that works from that area. (WT-en) Hanzo 06:34, 31 Oct 2003 (PST)
Yeah, I'm with (WT-en) Hanzo. We shouldn't try and write all phone numbers as they are dialed internationally, because that doesn't work locally, and so becomes confusing. I believe that the manual of style should direct people to write all phone numbers as they should be dialed locally, and specify somewhere else ("Know" or other section?) how to dial the numbers from further afield (Country code, and area code if not part of local dialing.) (WT-en) CL 00:26, 2 Nov 2003 (PST)
This sounds right. Whether the area code needs to be dialed varies with location. In my part of North Carolina you used to be able to dial 588-2353, but they added an area code, so now you have to dial 704-588-2353. Numbers in 980 and some numbers in 803 can be dialed without the 1 prefix, but other numbers have to be dialed 1-214-748-3648. The area code should be specified in Contact. -(WT-en) phma 19:00, 6 Mar 2004 (EST)

It seems to me that for the US, +1 (789) 234-5678 is better, in that if you dial all these digits locally, it should work fine. Plus, you don't have to cross-reference a different part of the article or a different article altogether, either of which you might not have if you've printed something out. Or if you're looking at an extract that has lost the context of the listing (and thus lost the area code information). Also, almost all Americans will realize that the +1 (789) part is optional, if you are in the same area code. Personally, I would be very grumpy if I tried calling a number "locally" from my 415-area-code cell phone, and it didn't work, and I had to dig through a pile of information to find the proper area code. I would also be unhappy (though less so) if I were calling in from out of state or internationally. Also, people who write reviews don't necessarily know whether or not to include the area code (since they may not be from the area), and it's much worse when it's missing than when it's there but unnecessary. Most places where the local phone system is not well-standardized seem to indicate which digits are significant to whom with a combination of ()s and []s and things. To me, it seems better to say "the system is complex, but here is all the information you need to use it; refer to a footnote if you are confused" than "the system is complex, so here is only part of the information you need; refer to a footnote if you want the rest". You only need to learn "() means optional for local calls" once, and it's easy to remember, but memorize a list of area codes for the cities you are going to be visiting this week is much more annoying. -- (WT-en) Beland 22:18, 23 Aug 2004 (EDT)

New discussion (2011)

The standard is ITU_T E.123 detailed [here]. The access code is 011 from US and Canada and 00 from much of the rest of the world. Use a + to designate that. 80.42.230.218 08:55, 2 August 2011 (EDT)
The format +32 (0)15/12.34.56 is NOT valid. Use +32 15 123456 for international numbers OR (015) 123456 for national numbers. Spacing within the subscriber number is optional. The key point is that parentheses are not allowed in the international format. More information [here] 80.42.230.218 08:55, 2 August 2011 (EDT)

Sub-articlization

Why are there so many small sub-articles? I might be better to have them all on one page. (WT-en) Guaka 18:32, 1 Feb 2004 (EST)

It used to be all on one page, and it was really long, hard to edit, and hard to read. Also, it's a lot easier to reference a rule or idea if it has its own page. --(WT-en) Evan 19:52, 1 Feb 2004 (EST)

Style help?

Is there a standard place to ask questions about Style? If yes, maybe it should be added to Project:Help? : (WT-en) Colin 17:42, 6 Mar 2004 (EST)

Referring to highways

In the Death Valley web page, some references to roads say stuff like "the 395." I thought putting "the" in front of road numbers is strictly a Southern California idiom. Should this idiom be avoided? I think it makes some sense for LA and San Diego since travellers to those regions will encounter the idiom frequently. I think it doesn't make sense for Death Valley since visitors from afar may not be familiar with the "the" idiom, and may enter the region through, for example, Reno where the idiom is not used.

So my questions are

  1. Are there other regions which use the "the road-number" idiom?
  2. Will the idiom confuse anyone? It doesn't confuse me, but what non-proficient users of English?
  3. Is this too pedantic to care about?
  4. Should (WT-en) Colin switch to decaf?
(WT-en) Colin 17:42, 6 Mar 2004 (EST)
"The 395" - I'm expecting a noun after that, such as "the 395 reindeer left". Normally we say "Route 40" or "I-77". -(WT-en) phma 19:00, 6 Mar 2004 (EST)
I think maybe "highway 395" is clearer, you're correct. 395 is a really great drive, by the way. It'd make a good itinerary page. --(WT-en) Evan 01:47, 7 Mar 2004 (EST)
I can't find any other place discussing it, so I'll just kind of stick it in here. I've been using (at least in the US articles) what I think is the official designation system. Interstates are prefixed with "IH-", Non-interstate federal highways are prefixed with "US-", state roads are prefixed with "SH-" (I had to kick myself several times to stop using the prefix "TX-", which we Texans know isn't really official, but use any way), and others that might not be so popular across the country (I really don't know), like County Road ("CR-" here), Farm-to-Market Road ("FM-"), and Ranch Road ("RR-") are just spelled out. I wouldn't mind having a stated consensus on this though, especially with "FM-" (In Houston, at least, if you ask for "Farm to market road one nine six zero", you'll get a blank stare about half the time, but everyone knows of "FM ninteen sixty"). (WT-en) Jordanmills 13:25, 10 April 2007 (EDT)

Units of measure

Do we have a standard for measurements? My suggestion is to use metric always, since 99% of the world uses this. As a compromise -most americans are as ignorant about the metric system as everybody else is about the Imperial system- we could use metric first, then imperial in brackets. -- (WT-en) Nils 08:57, 6 Apr 2004 (EDT)

If you're in the U.S., your going to have to deal with miles on signs and weather forecasts in Farenheit anyway, so U.S. distances should be in miles. For the same reason, I think metric countries should use metric measurements. I must say that metric temperatures give me a headache though. -- (WT-en) Colin 13:12, 6 Apr 2004 (EDT)
I did propose the compromise to deal with that. But really, all the world uses metric instead of the US, so I think it should be quite clear what the primary system should be. -- (WT-en) Nils 13:17, 6 Apr 2004 (EDT)
I appreciate your willingness to compromise, but I don't think it's actually a good idea. It's too much effort to maintain two sets of each measurement. In an ideal world, there would be a special markup [ [distance:24 km] ] which would auto-convert to the format you want (where you could select use metric, use english, or use country's own style in your preferences) on demand. And [ [phone:us:408 555-1212] ] too!
There are lots of interesting differences in the world. That the majority does things one way is not much of an argument for doing something in a universal manner. I'm probably showing my own cultural bias towards doing things ad-hoc though :-) -- (WT-en) Colin 15:44, 6 Apr 2004 (EDT)

Rollback

So, I rolled a couple of things back. First of all, I rolled back the hierarchicalization of the list. I don't think that the listings formats (say) are somehow "part of" the article templates. In addition, hierarchical lists have always been deprecated on Wikivoyage -- instead, we express hierarchy through separate page sections or separate pages. (I'm realizing that that tradition should probably be codified into Project:express hierarchies with separate pages). So, I'd hate to see this list hierarchicalized!

With all due respect, now you're pulling policies out of your ass. Where is this tradition written, who's this "we", and why should such an inane policy apply to a table of contents, of all things? In small doses hierarchies are good: they help the reader because a) they break down a lengthy list into digestible chunks (ever heard of seven plus or minus two?), and b) it makes it faster to scan the list, because you can skip subsections that are obviously not of interest. (WT-en) Jpatokal 09:41, 23 Jan 2005 (EST)
The tradition isn't written, but see for example the history of British Isles for a change from hierarchical lists to organization by separate pages (I think this version is where it got the worst). The value of having it apply to the ToC of the MoS is that we avoid giving people bad ideas on the page that's supposed to be giving them good ideas. --(WT-en) Evan 17:11, 23 Jan 2005 (EST)
Cry me a river. "Avoid giving people bad ideas"? I thought we were supposed to be a user-friendly travel site, so please tell me why hierarchies in a ToC are a bad thing. Yeah, the British Isles thing looks pretty ugly, but I see very little relevance here. (Incidentally, this very discussion is hierarchical; isn't it much easier to follow with indenting?) (WT-en) Jpatokal 23:17, 23 Jan 2005 (EST)

Second, Wiki markup is not a style issue. It's a technical issue. The MoS is a list of things we could do lots of different ways, but we chose to do this way (viz. restaurant listings). Wiki markup isn't a choice; it's just the way our software works. --(WT-en) Evan 08:24, 19 Jan 2005 (EST)

Actually, it is a choice, because you can also write <B>bold</B> etc in raw HTML (for which we of course have the Avoid HTML policy, but that's another kettle of fish).
More importantly though, I think you're looking at this from a terribly formal point of view. Is there something wrong with pointing to the same document from several places? I've been here for over a year and I often have problems finding some specific policy document, because the division doesn't make sense and the indexes are pathetic. There are way too many policy/guideline/help/hint/whatever pages and way too few links to and between them.
Case in point: this question in the Pub. I dare you, pretend that you're Richard and find your way to the answer starting from the Main Page. (WT-en) Jpatokal 09:41, 23 Jan 2005 (EST)
There are three major sections of the Wikivoyage namespace: Project:Help, which gives mostly technical help. Project:policies and guidelines, which gives our important collaboration policies, and Project:manual of style, which links to style guidelines. Site organization is important; if we link all the items on Project:Help on Project:Manual of style, and vice versa, they each become diluted and less useful.
So why is "Avoid negative reviews" a style issue, and "Article naming conventions" a policy issue? "Avoid HTML" is style, how to use images is policy, "Internal links" is style, but "External links" is style and policy? What's the logic?
Avoid negative reviews is about what kinds of listings to put into destination guides. It's a writing style issue. Avoid HTML is about how best to do formatting. It's a formatting style issue. I've taken ext links and article naming conventions off the policy page; good catch.
Image policy is a tough one; it was started mostly to make sure we kept all our images redistributable under CC-by-sa, but it's grown to include various non-legal things like file naming, etc., as well as help information. It may make sense to break it up into several pages. --(WT-en) Evan 09:55, 24 Jan 2005 (EST)
Wikipedia, a far larger project than us, has a single-page Manual of Style. I think this would be much better here too: Layout on Manual of Style, Content in the policy pages. (WT-en) Jpatokal 23:17, 23 Jan 2005 (EST)
It was smart of you to add the interwiki info to the markup page, by the way. --(WT-en) Evan 17:11, 23 Jan 2005 (EST)
Thanks Dad. I can also put on my underwear the right way around, all by myself. :rolleyes: (WT-en) Jpatokal 23:17, 23 Jan 2005 (EST)

"Buy" listings

We need a format for "Buy" listings. How do we say that Persian rugs in Teheran can be bought from Shop 1 , Shop 2 or ordered online ? --(WT-en) Ravikiran 07:44, 25 Sep 2005 (EDT)

Each of the shops should get it's own complete listing, follow roughly the same pattern as for restaurants. The online shop does not get a listing at all, since it's not about travel but about buying something at home over the internet. -- (WT-en) Mark 08:27, 25 Sep 2005 (EDT)

Time and date

I linked Project:Time and date formats since the "proposed" standard appears to merely document the time formats as already established in Project:Attraction listings and elsewhere, so technically this is not a change to the MoS. -- (WT-en) Colin 15:53, 24 February 2006 (EST)

Listings format

Hey all, I've noticed that in listings a lot of people seem to like to leave any leading word "the" out of the bold part of the name of an attraction, like this:

  • The World Famous Giant Ball of Twine, 2555 State road 5. +1 etc.

Rather than bolding it along with everything else like this:

  • The World Famous Giant Ball of Twine, 2555 State road 5. +1 etc.

From a graphic design point of view the version with the "the" stranded between the bullet point and the bold looks like crap. At least my fairly well trained eye sees it that way.

This is just a heads-up. Some point in the near future unless I hear any reasonable objections I intend to Project:Plunge forward and add some language to the listing format pages which strongly discourages stranded "the"s. -- (WT-en) Mark 02:03, 8 March 2006 (EST)

I have no opinion on this. I looked over Penticton and there's a few similar items you might want to address while you're at it to make sure all the bases are covered...
  • The Penticton Roundabout
  • Penticton Museum & Archives
-- (WT-en) Colin 04:46, 8 March 2006 (EST)

Thumbs up on infoboxes

Thanks for adding that one, Ryan; if used properly, it's a nice feature, and by now there seems to be adequate precedent for using it properly. This is a keep. -- (WT-en) Bill-on-the-Hill 20:47, 28 March 2006 (EST)

Do we really want the Wikipedia link to Wikipedia's Manual of Style? I'm not sure I support having it, because we have a lot of Wikipedians that come to Wikivoyage and get upset about POV/NPOV, I'm weary that this may support experienced Wikipedians, but new Wikivoyagers, to use Wikipedia's MoS instead of Wikivoyage's MoS. Thoughts? - (WT-en) Andrew Haggard (Sapphire) 17:12, 29 May 2006 (EDT)

Yeah, I roughly agree. I don't think we have a link to Wikipedia:About on Project:About, and I'm not sure we need one here. Is the idea of a "manual of style" better elaborated by having this link? I don't think so. --(WT-en) Evan 17:37, 29 May 2006 (EDT)

Price ranges instead of actual prices?

Wikivoyage currently gives actual prices for all restaurants, hotels etc, but many guidebooks use price bands like "$, $$, $$$" or "A, B, C" to rank comparative prices instead. Given the raging inflation in many countries and that even stable prices like Singapore have seen hotel prices shoot up by 20% in the last two years thanks to supply and demand, would it make sense to adopt this in Wikivoyage too? (WT-en) Jpatokal 13:14, 3 June 2006 (EDT)

No, I really hate those ranges. The ranges are too big. And they only make the prices even less precise. Even if the prices are up 20%, I would like to know which hotel was $75 and which was $90 two years ago --(WT-en) elgaard 19:24, 3 June 2006 (EDT)
But how do you distinguish the hotel that was $75 two years ago and the hotel that is $90 now? (WT-en) Jpatokal 23:19, 3 June 2006 (EDT)
I really prefer having actual prices on listings, too. I think that ranges are too imprecise; what seems "budget" to you might seem astronomically high to me. We've got a suggestion of putting listings into "bands" (budget, mid-range, splurge), which does about what price ranges do. --(WT-en) Evan 10:47, 4 June 2006 (EDT)

Listings

I'm new-ish and this may have been done before, but wouldn't it make sense to list listings of shops, bars, restaurants and hotels on separate subpages, particularly for very large cities? It's just that some of the page sizes are monstrous, the current situation involves lots of links, etc. It should at least make it easier for people to actually find what they're looking for... (WT-en) No more bongos 22:08, 19 July 2006 (EDT)

The main reason we don't do this is to keep everything together for someone who (for example) wants to print the article for whatever city they're visiting, and get it all in one go, rather than having to print each section individually. When city articles get truly monstrous, we break the city up into districts, but keep all the various kinds of info for each district together, figuring that someone might be going to just the Bloomsbury district of London, and wants to know what to see and do, and where to eat, drink, and sleep there. - (WT-en) Todd VerBeek 22:17, 19 July 2006 (EDT)
(weird, I have no idea how I moved this up and somehow killed Todd's reply... I'm some sort of walking wiki bug this evening... anyway what I said was (eta agreement with Todd):) Welcome! While Todd's right on all accounts, if you're interested, heck out the discussion at Wikivoyage_talk:Article_templates#The_best_Wikivoyage_articles_are_too_damn_long. You are not alone in your thinking... tho the "click vs scroll" argument is as old as the web. (WT-en) Majnoona 22:22, 19 July 2006 (EDT)

One-liner listings

discussion moved to Project:One-liner listings

Requests for information in article content

Swept in from User talk:(WT-en) DenisYurkin:

Hi Denis, Sorry if I've missed the conversation somewhere else, but I noticed you've been adding requests for more information into the body of articles like Renting a car. This doesn't follow our current Project:Manual of style and makes the guides harder for travellers to use, especially offline or in print. Would you mind moving (or if I moved) you're comments to either the article talk pages or the Project:Articles needing attention page? Thanks! (WT-en) Maj 21:24, 15 November 2006 (EST)

Could someone to point at specific place where this policy is detailed? Am I right that the main reason for RFIs-should-be-avoided is cluttering an article (making it harder to read)? If so, I think I have a solution for this--both allowing RFIs and leaving articles as readable as now. The reason I believe RFIs are useful is that even an active contributor taking a offline copy with him to his trip never prints out a discussion page. At the same time, RFIs help to show people what concrete pieces of information are missing here and would be particularly welcome. We can discuss guidelines for non/placing RFIs around if there's initial interest in the community to think in this direction. --(WT-en) DenisYurkin 05:27, 17 November 2006 (EST)
I think in general we write for the traveller, not for other contributors. I'm happy to hear your argument for this, but until we decide to add RFIs, please hold off. --(WT-en) Evan 08:58, 17 November 2006 (EST)
> Make the case first, please
This is initial draft on how I propose RFIs that doesn't clutter the page: RFIs#If the car brokes -- compare it to the current edition of Renting a car#If_the_car_brokes.
The whole idea is to have small markers in the text that can be detailed in the footer of page for those who are willing to share their experience as they go.
Sorry for placing it at wikipedia--I used REF tag implemented there; it can be adopted for our needs of course.
--(WT-en) DenisYurkin 12:19, 17 November 2006 (EST)
I understand your motivation for this, but I have two problems with it. First, as Evan mentioned, we want to write for the traveller not the contributors. A useful end-product (ie a travel guide) has always been our goal and you'll have a hard time with any suggestion that moves away from that goal. Secondly, having RFIs on some pieces of content suggest that we are not looking for contributions in other areas. In fact all the content in the guides is always open for edits/additions. I think the "edit" links convey this well enough. (WT-en) Maj 12:41, 17 November 2006 (EST)
  1. In my belief, for all articles except Star and Guide-rated we may (and should) explicitly state what information is missing, and as long as they remain in non-Star/Guide status, we would like every traveller (even when he prints a copy for offline use) to be a contributor also--until article reaches Guide rank.
  2. When we ask for specific information, we improve chances that a person who knows about a particular subject will share his knowledge with us--compared to having a general "[edit]" link that suggests to fix if there's anything wrong in existing text, but doesn't welcome to add anything new--nor specify what new would (or would not) fit here. I agree that along with RFIs we should state that any other improvements would be also welcome--RFIs are there only to help magnetize the most obviously requested ones. BTW, [edit] links are not shown in printed edition--that's logical, but further decreases chances for contribution.
  3. Probably we should not allow RFIs for stub and star/guide articles: stub needs to much information, RFIs will leave no attention to content that already exists; star/guide are already complete by definition.
--(WT-en) DenisYurkin 19:14, 17 November 2006 (EST)

I was actually just thinking about this earlier today, and while I agree with Maj that we don't need to flag every section that needs expanding, I do think it would be very useful to adopt a Wikipedia-style {{fact}} template for flagging dubious-sounding facts in need of verification by an expert. For example, in the South Korea guide, it states that the Korean for "overnight stay" (in a by-the-hour hotel) is sukbak; I'm not at all convinced that this is correct, but neither do I know for sure that it's wrong and it seemed to work when I tried it. How to flag this for the next reader who comes along and knows enough Korean to confirm or fix it, but doesn't read Talk pages? (WT-en) Jpatokal 03:38, 24 November 2006 (EST)

This is exactly what I thinked of proposing LocalExpertiseWanted template. And, as it will move us towards my ideas here in "Requests for information in article content", I am willing to support this. What about {{verify}} name and [verify] marker next to the text in question?
I would also vote for highlighting text piece in question so it'd be easier to understand which part of sentence specifically needs evidence. I also have an example, from Istanbul in my case:
Sultanahmet (old city) part of Istanbul has a high number of stray cats, so no matter where you wind up sleeping[verify] you are likely to be rocked to sleep by a lively feline chorus.
In this example, I am not sure however how can I ask "where exactly is this experienced" and "what time of year known experiences refer to?". --(WT-en) DenisYurkin 11:15, 24 November 2006 (EST)
(WT-en) Jpatokal, how can we progress with implementing your idea? How can I help to move it bit forward? --(WT-en) DenisYurkin 04:03, 9 January 2007 (EST)
I have been thinking about this, too. I think it might be great to put all tasks for an article -- facts that need to be verified, reformatting of listings, parts that need a rewrite, reorganization -- into a "TODO" section of the talk page. That way, there's one place to look for new things to do. It also doesn't get in the way of the reading experience. That's that talk pages are for, after all. --(WT-en) Evan 10:23, 9 January 2007 (EST)
I also came up to the same pattern as a first step. I will use it next time I need it in the articles I edit--and will share my experience here. And you -- did you have a chance to try this approach somewhere at Wikivoyage? --(WT-en) DenisYurkin 11:48, 9 January 2007 (EST)
This is my first attempt: Talk:Eger#ToDo. Welcome to comment, improve and criticize. --(WT-en) DenisYurkin 18:16, 9 January 2007 (EST)
I don't think a Todo list on a talk page serves the point I was after: alerting the traveler to something dubious or unconfirmed. (WT-en) Jpatokal 22:54, 9 January 2007 (EST)

To plunge forward with (WT-en) Jpatokal's ideas, I have just created a verify template that attempts to implement what we discussed. I have just used it in Istanbul#Sleep, and will also apply to one or two articles on Hungary--will name them here. --(WT-en) DenisYurkin 16:52, 20 January 2007 (EST)

I have just applied it to several pieces in Hungary and Budapest that already had a request for verification on respective talk pages. Does anyone find things like this useful? --(WT-en) DenisYurkin 17:14, 20 January 2007 (EST)
I have to say I still really don't like this. I seems to me, that everything could have a verify tag to it the way you use it in your examples. And it's not clear what is required to "verify" something? 2 users? 10? a citation? I still say that all the content in the guides is always open to editing/updating and that this confuses the issue. If something is really "dubious or unconfirmed" to the point where you're not comfortable, pull it out to the talk page. (WT-en) Maj 17:59, 20 January 2007 (EST)
In the cases so far, we already have a question on Talk page on a piece of information having a verify tag, but we still allow that this piece may be true (and we did not remove it to Talk page until having confirmation). I am not sure this is a good criteria for non/using this tag on whatever fragment, but so far it applies.
This pattern is especially good for few-/no-maintainers articles where most edits are contributed by people who don't ever return after their only edit, and none except them is available to verify/clarify on their contribution. Having verify tag, we'll invite readers to contribute/comment on this specific piece--without cluttering an article. --(WT-en) DenisYurkin 18:17, 20 January 2007 (EST)
I agree with Maj in that the examples you've picked are really bad: how on earth can that cat thing be "verified"? This should only be used for cases with true-false/black-white verifiable correctness. (WT-en) Jpatokal 06:01, 21 January 2007 (EST)
I'm having trouble thinking of any example where this would work. I mean, if you doubt something, pull it out to the talk page. If you have a vague question about something, leave it in and then put a comment on the aforementioned talk page. This all seems pretty basic to me. (WT-en) Maj 20:38, 21 January 2007 (EST)
A few examples: "Americans can receive a visa on arrival." "Blorgzzap is Quechua for "please give me a discount"". Pulling these out means that the traveler loses potentially useful info, while not flagging them means that the traveler receives potentially incorrect info. (WT-en) Jpatokal 05:23, 28 January 2007 (EST)
Thanks for your real-life examples, Jpatokal. --(WT-en) DenisYurkin 14:42, 28 January 2007 (EST)
In articles like Hungary, using verify tag is is a way to keep content in doubt in the acticle, while indicating that community already not sure whether it is true or not. Talk page has a tenth of article readers, and my questions at Hungary#Talk demonstrate that sometimes leaving a question on talk page just gives no progress on the matter for weeks. Indicating that some piece in article is questionable to attract more attention for its resolution, while still enabling reader to use it on his own risk is where I believe verify tag would help. --(WT-en) DenisYurkin 00:46, 22 January 2007 (EST)
Editorial comments go on Talk pages. That's why we have talk pages. I'd be happy to support formalizing some fact checking process on the talk pages, but I'm really not happy putting little "not true" flags all over Wikivoyage articles. If you think some statement in an article is too sketchy to be defended, plunge forward and verify it, or remove it and put it in the talk page for further discussion.
Tagging facts for verification in the pages sets up social situations that I don't like. Whose information needs to be verified and whose word counts as verification? By flagging certain facts as needing verification, do we give an implicit guarantee to readers that the other 99.9999% of Wikivoyage is accurate? Readers should take any statement on Wikivoyage (or in any other travel guide, or anywhere) with a grain of salt. I don't know if we need to remind users of that fact in every sentence in the guide. --(WT-en) Evan 11:17, 28 January 2007 (EST)
We can start with allowing verify tag only for contributor's own fragments. As for "when it's verified?", I think we definitely need a comment on talk page from a person who has something to say on fragment in question. And after that we can remove verify tag when there's a clear consensus on the matter reached on the talk page. --(WT-en) DenisYurkin 14:42, 28 January 2007 (EST)

(re-indenting) I'm with Evan and Maj on this one - it's tough for me to imagine any content for which a "verify" tag couldn't be added, and then once it's verified, do we add a citation or some other tag? If we go with Denis' suggestion that a user should only add "verify" tags to their own contributions, I think a better solution would be for users to not contribute content that may be inaccurate; the talk page could be used instead for that kind of info. Also, if a fact seems dubious it can always be removed from the main article and moved to the talk page for discussion. Opening up articles to editorial markup seems like a way to really make a mess out of articles without adding much real benefit. -- (WT-en) Ryan 14:54, 28 January 2007 (EST)

Oops, I just found that I already had a better idea earlier: we can start using verify tag only for a fragment that already have an open discussion on Talk page, but was not considered questionable enough to remove the fragment from article (as desided by those who put verify tag in the article). And once the discussion gave some good answer, verify tag is simply removed--optionally with edits clarifying original fragment. --(WT-en) DenisYurkin 16:29, 28 January 2007 (EST)
I also agree that this sounds really messy, I think it should be avoided (WT-en) cacahuate talk 02:21, 13 March 2007 (EDT)

Templates for areas of low population

Based on the discussion surrounding the status of Berneray, (See: Project:Star nominations) I wonder whether a new template could be designed for regions like this, possibly based on the 'small city' format. As the centers of population in a place like Berneray are no more than a few houses, there is insufficient information to designate each hamlet their own page, as in say the listings for cities in a country. At a stretch, all the guest houses could be listed under the 'sleep' section, though as they are all of similar design, charge a similar nightly rate and there are no street names, this would only be a list of names. Possibly the 'see' section could have information about which mountains or lakes are visible from a particular village. Otherwise, every hamlet is pretty much the same. Also, I wonder of the benefit to the traveler of having this information spread out over 7 or 8 pages. In the 'small city' format, all information is conveniently included on the one page, irrespective of its location within the city - for example, the western part of town may have beaches, while to the north there might be a castle. However, as neither of these districts have enough attractions to constitute being individual pages within themselves, they are included under the general heading of the city in which they are located. As Cacahuate rightly says, this situation is going to arise again and again in places like Mozambique, Siberia and the Himalayas. It would useful to have a template designed specifically for such regions. Anyway, just throwing out some ideas here.... (WT-en) WindHorse 22:13, 20 December 2006 (EST)

This is an interesting idea; call it the "Rural Area" template or such. I could have benefited (and could still benefit) from such a thing for articles about the sparsely populated, but traveler-attracting, boonies of my home state of New Mexico, and much of the western US could probably use it as well. One objection is that titles of "Rural Area" pages may not be easy to design in a way that is descriptive yet familiar to the traveler. Berneray is a bit of an exception in this regard, being an island, and I can see ways to do it for New Mexico rural areas too, so maybe it's just that I don't know enough of the rural areas of Mozambique, Siberia and the Himalayas, to use your examples. Anyway, let's discuss. -- (WT-en) Bill-on-the-Hill 22:31, 20 December 2006 (EST)
Not necessarily a bad idea. Iya Valley is one example of a rural area that was deemed OtBP-worthy. (WT-en) Jpatokal 22:59, 20 December 2006 (EST)
Some more examples - Havelock Island, Saint Martins Island, Bazaruto Archipelago... on most, all of the see and do will likely not have any phone number, etc. Of course all of these are small islands, but surely this will arise on others like WindHorse listed too... one of the issues with Berneray was whether it's acceptable to format the "see" and "do" the way that it currently is in that article, or if it must be converted to a listings format as per the MoS. In that instance, some of us agree that it works better (almost as an itinerary) the way that it is... you could walk around the island from sight to sight using that article. (WT-en) ::: Cacahuate 01:46, 22 January 2007 (EST)
I'm not sure a whole new template is needed; the best-fitting template of the present ones can be adapted in most cases by adding or removing a section as needed. Templates are starting-points, not straightjackets. Likewise with listing formats; if the way the locals describe the location of a lodge is "half a mile upstream from the bridge on the west slope of Mount Baldy" then that's the "address". - (WT-en) Todd VerBeek 11:11, 4 March 2007 (EST)

when to districtify a city

I've proposed draft of recommendations on where (and how) to districtify a city:

Project:Huge city article template#recommendations on when to (not) districtify a city

Please comment right there. Thanks. --(WT-en) DenisYurkin 05:45, 11 February 2007 (EST)

Valid values for government type

Do we have any policy on that matter? I am asking this because incidentally, I have Belarus on my watchlist (I must've been doing some minor edit there) and recently somebody changed the government type to «Democratic social state with the rule of law» (from «Dictatorship», which I believe was taken from the CIA factbook). I reverted it because it's neither democratic nor «with the rule of law» and then the user in question changed it back to «Republic». And he's right with this, because as long as there's still president Lukashenko, not «emperor Lukashenko» or some other fancy title. it's not a monarchy. But I feel it's deeply uninformative for a potential visitor. What do you think? (WT-en) CandleWithHare 17:14, 25 August 2006 (EDT)

My view is the traveller comes first. Since it's just a couple of words, it should be words which convey the most acurate description of the government as can be wildly simplified into a couple of words. The goal of these few words is to convey the most accurate meaning to the traveller, not appease people with doctorates in political theory. If there are complexities the traveller should understand, put them into the Understand section. -- (WT-en) Colin 17:24, 25 August 2006 (EDT)
Agree with Colin that TTCF, but a lot of noise is being generated right now (largely by one peculiar zealot) over nuances of language on government type, and it would be nice to lay this to rest so that people can get back to doing what's important here. Wikipedia has a good analysis of this question, with some definitions that are useful in practice. Candle, to get back to your specific case, I'd recommend letting the government form in Belarus (in which I have traveled, btw) stand as "Republic" but making sure that relevant oddities -- if and only if they affect travelers -- are highlighted in appropriate places in the article. -- (WT-en) Bill-on-the-Hill 17:33, 25 August 2006 (EDT)
My point is that there's a big difference between Republic of Belarus and, say, Republic of Ireland and the description should reflect that. I think that it would be most fruitful for Wikivoyage to stick to the descriptions used by the CIA (ie. dictatorship in this case). Such information is relatively unimportant for a travel guide but it nevertheless shouldn't be misleading if it's present. I saw it being changed, I felt it was wrong, I wanted to have a second opinion if something should be done. But if you say keep, let's keep it. I'm not a zealot and I couldn't care less about Belarus. (WT-en) CandleWithHare 17:58, 25 August 2006 (EDT)
From a purely legalistic perspective, the difference between the two is not large. From a practical perspective, you are correct, it's enormous. And that's what the text of the article is for: in the appropriate sections (Understand, Cope, Respect, etc.), put in the things that make it clear what those differences mean to the traveler. I too couldn't care less about the Belarus article (and have no desire to go there again), but one should do the things that drive the project forward. My main interest is in avoiding a Project:Edit war as seems to be happening with some other "republics" of dubious legitimacy. That's not what we're here for. -- (WT-en) Bill-on-the-Hill 18:28, 25 August 2006 (EDT)
I don't think we need to worry about heading off an edit war yet -- these are just occasional nuisances at this point. The kind of person who offended by political descriptions and "corrects" stuff is a lot like the kind of person who gets offended at lively descriptions and deletes them. Generally, a serious person stays around and discusses these things, and the drive-by corrections can be easily reverted. Let's wait until there is an edit war before forestalling this. For now, let's stick to what helps the traveller and keep the quickbar a quick and comprehensible read. -- (WT-en) Colin 20:05, 25 August 2006 (EDT)
A similar issue came up on Talk:China, likely elsewhere as well. (WT-en) Pashley 06:31, 25 September 2006 (EDT)
What if all the government types were to match the following regex:
(Federal)? (Democratic|Authoritarian|Totalitarian) (Republic|Monarchy)
(WT-en) CandleWithHare 10:41, 9 October 2006 (EDT)
Not bad at all, although I'd add the optional qualifiers "Constitutional" and "Absolute" for monarchies (not that there are many absolute monarchies left). Is anything missing here? The few obvious cases that don't fit in (e.g. Vatican City) can be handled on a one-by-one basis without too much controversy, I expect. -- (WT-en) Bill-on-the-Hill 10:48, 9 October 2006 (EDT)
But that would deprive us of the "Dear Leader". -- (WT-en) Mark 12:04, 9 October 2006 (EDT)

html infoboxes

I asked this already on Talk:Paris#arondissements_infobox but figured maybe it belongs here instead... I'm wondering if the arondissements box (actually it was created as a template back in 2004 ("Template:Paris arrondissements") is unecessary. I'm thinking the districts should just be (and are) listed in the "districts" section, like every other article. we recently removed a similar thing from Warsaw, and I'm sorta thinking in general things like this aren't necessary and should be avoided... thoughts? (WT-en) - Cacahuate 03:02, 12 March 2007 (EDT)

Whatever we do, we should standardise, and not have hundreds of templates as Wikipedia does. (WT-en) Ravikiran 07:56, 12 March 2007 (EDT)

Region maps / color key

I've noticed the style in use at Texas#Regions and Nevada#Regions for color coding being used more and more, is this an agreeable way of doing this that should be followed, or does anyone have objections to it? I kinda like the way it looks, but the MoS says to avoid HTML... the alternative would be to just write the name of the regions on the map itself (WT-en) - Cacahuate 03:07, 12 March 2007 (EDT)

I don't care either way, but I could write up a template.... that way if people agree it's a nice thing to keep around and we don't want the html we can use templates. The upside to that is that new contributors don't get confused and think we promote the use of html. -- (WT-en) Sapphire(Talk) • 03:16, 12 March 2007 (EDT)
yeah, if we do keep it around the template would be a good idea... (WT-en) - Cacahuate 03:25, 12 March 2007 (EDT)
Another option I've seen around is to just color the text on the link such as on Europe#Regions, though I'd recommend a less obnoxious color scheme than on that page, if we go that route (WT-en) cacahuate talk 00:30, 14 March 2007 (EDT)

Bolding the district/region names

I've been thinking about this for awhile anyway, but today's log made me think it's even more of a good idea. We need to call more attention to the district articles... we've already created the new {{printDistricts}} template to place at the top of huge cities, I'm proposing now that we always bold the districts names in the district section. Especially when there's long descriptions, the unbolded text sort of gets lost and is easy to scroll past that section. I've taken the liberty on the Bangkok page... see India#Regions for another example of why I think it's necessary. (WT-en) cacahuate talk 21:34, 8 April 2007 (EDT)

Alright, I'm gonna start bolding them when I come across them, speak up if you disagree (WT-en) cacahuate talk 03:01, 15 April 2007 (EDT)
Right. I'm starting too. (WT-en) Upamanyuwikivoyage( Talk )( (WT-en) Travel ) • 03:06, 15 April 2007 (EDT)
Me too. (WT-en) Jpatokal 21:08, 18 April 2007 (EDT)

Images in articles

Do we need a formatting guideline for Project:Images in articles? I mean things like:

  • Lead image - recommended size - (400px?), what it should contain (iconic image of the city, etc.), where it should be placed.
  • Spacing out of the images through the article (I have been using the informal guideline of one image or map per printed page.)
  • Size of the images. (I have been sizing wide images at 240 px)
  • Whether images should be relevant to the section they are in, and if so, what happens when we have a pileup of images in one section and too less in another section.

(WT-en) Ravikiran 08:49, 22 May 2007 (EDT)

I've also been sizing images at 240px, but the "correct" solution for this would be change the default to something more reasonable (now it's too small). And yes, images should always have some relevance to the section they're in. Eat should have food pictures, See should have sights, etc. (WT-en) Jpatokal 10:01, 22 May 2007 (EDT)

I've been doing a lot of sizing and resizing in articles, and for the most part have been doing 400px for the opener (though maybe we should assess if this is still appropriate with the new TOC. For all other pics I've been removing the size indicator to use the default (currently set at 200px)... I agree that if we want it to be bigger than we should just change the default, that would make things a lot simpler. 250px does look good.

According to Project:How_to_add_an_image#Sizing, images should be (maximum):

  • Normal images: 250px
  • Lead pic: 400px
  • Map w/small detail: 500px (I rarely do that, too large for most articles... I think 300 or 350 looks good, usually)

I usually try to place images in the relevant section of the article if there's room, but I don't think it has to be that way if there isn't room and all the images are good technically and relevant to the article.

Re the lead pic, I think it should be a combination of the most iconic image of the place and the most alluring photo that we have for that page... which ideally would be the same image. But I would probably opt for the better picture over the better landmark, if it isn't. Though I guess it really depends on the article. I'm definitely in favor of expanding/tightening the guidelines. (WT-en) cacahuate talk 14:56, 22 May 2007 (EDT)

Icons

I think it would be really cool if we could have icons for standard information. For instance, a little picture of a telephone before a phone number, a little circle with 'FAX' in it for a fax number, maybe a clock for open hours, any others...? (WT-en) Sailsetter 13:20, 16 March 2008 (EDT)

The telephone icon is already available when a Project:Listings tag is used. The other suggestions require some technical changes, which can be requested on the Wikivoyage Shared site. -- (WT-en) Ryan (talk) 13:27, 16 March 2008 (EDT)
Thanks, I didn't know about that. It seems not many people are using it, but I'll start, and I'll check out the others available. (WT-en) Sailsetter 14:55, 16 March 2008 (EDT)
Having looked at the attribute list, my first reaction is that it would be really useful if each attribute had an example listed with it. (WT-en) Sailsetter 15:03, 16 March 2008 (EDT)
There's a form-based listings editor in the works that should come out soon (fingers crossed), which will simplify the process drastically. --(WT-en) Peter Talk 17:44, 16 March 2008 (EDT)

Is there a standard for whether links ought always to include text? For instance, which of these should be used:

The British Museum ...

or

The British Museum ...

Because I keep seeing both, sometimes in the same list!

(WT-en) Sailsetter 15:00, 16 March 2008 (EDT)

My understanding is that we'd ultimately prefer to have no front-linked external links. That is, they should all look like this: Google . The policy in question is available at Project:External links.
If you'd like to look at articles that are verified to be formatted correctly (perfectly, in fact), check out the list of star articlesmost other articles here have plenty of imperfections! --(WT-en) Peter Talk
British Museum is how we write it in Listings. British Museum is how we write in when the museum is mentioned in text. Ugh. -- (WT-en) Colin 18:14, 16 March 2008 (EDT)
OK thanks, since the style manual says pretty clearly not to use front-links I assume it's ok to change them when I see them if I want to take time while editing my own contribution. A related question: is it possible and within policy to add a See Also link pointing to a Section of another Wikivoyage page, for instance, a link from some other Greece page pointing to the Athens page Do section? I think it would be very useful sometimes. I know you can do this with HTML with the pound sign, but experiment seems to show this doesn't work in the Wiki internal link markup, and I haven't seen any examples. (WT-en) Sailsetter 18:31, 16 March 2008 (EDT)

Since I wrote the above I think I did find an example on the Athens page:

 * X92, X93, X95, X96, X97 (the airport buses)

Is this according to policy and is this the right way to do it? (WT-en) Sailsetter 19:28, 16 March 2008 (EDT)

Yes, that's the right way. And it often doesn't work the first time you click it or something wacko like that. -- (WT-en) Colin 20:09, 16 March 2008 (EDT)

North East vs. North-East vs. Northeast

Dictionary.com seems to indicate that most dictionaries prefer the un-hyphenated, un-spaced "northeast", and judging by Google hits, "northeast" is more than twice as common as the other two spellings combined. Similarly, across Wikivoyage so far, there are 1,570 instances of "northeast", while the other two variations together total only 932. I haven't run statistics on the other ordinal directions but I imagine they probably have a similar distribution.

Nitpicky, I know, but the editor in me is screaming that, except in cases where it forms part of a proper name, we should choose one orthography and stick with it. For consistency's sake, and especially because I want to see professional-looking WikivoyagePress books, I'd like to see an established preference outlined here, similar to the way we have preferred time, date, and currency formats, and an established preference for American spelling over the British one. I hate to see a haphazard assortment of orthographies being used, especially for words that come up so often when talking about travel. Anyone agree? (WT-en) Texugo 06:54, 9 April 2008 (EDT)

It might also be wise to include a reminder that direction words need not be capitalized unless forming part of a name or article title. There seems to be a lot of folks who capitalize them all the time. (WT-en) Texugo 07:23, 9 April 2008 (EDT)

Ideally, all Wikivoyage should be standardized on a single style manual. The best choice might be The Chicago Manual of Style, which is still one of the most common standards. Unfortunately it's available on line only by paid subscription, so people would actually have to consult the book. (A "book" is a bunch of sheets of paper with printing on them bound together between covers.) Does anyone know if there's some other standard complete style manual available free on line that might be used? (WT-en) Sailsetter 10:48, 9 April 2008 (EDT)

Incidentally, previous discussions of standardizing on American spellings nearly resulted in a second War of 1812. (WT-en) Sailsetter 10:50, 9 April 2008 (EDT)

Order of Listings Guidelines?

Are there any style guidelines on the order of listings in theSee or Do sections? I know that Sleep listings are broken down by price (a smart idea). Even there, within the price categories the hotels are randomly listed. I'm wondering if there should be at least some policy on the order of listings? Are we just leaving it to be random...whatever is posted first stays on top for no other reason? Should there at least be some policy? Alphabetize maybe? Some other criteria? For example, "must see" verses "if you have time" subcategories for the See section?

I've searched all over and couldn't find any policy on the order of listings. If it's out there somewhere, I apologize. (WT-en) Spmenic 17:24, 29 July 2008 (EDT)

I think what you are looking for is Project:One-liner listings. That page is practically orphaned, so I'm not surprised that it's hard to find! I suppose that doesn't deal with see/do listings, but we almost always go with alphabetical order (with the occasional east-to-west or north-to-south geographical order), just to deter touts from moving their listings to the top. As for order of subsections within see/do sections, I don't think there's ever been a discussion on that, and we're probably not following any kind of standard practice across articles in their orderings. --(WT-en) Peter Talk 17:32, 29 July 2008 (EDT)
Thanks, Peter. You're right...I didn't even look at the Project:One-liner listings. However, after you pointed it out, I checked all style pages for types of listings. I also found that since last October, the Restaurant listings style guidelines suggest listing in alphabetical order. However, it says nothing on the style guideline pages for 1) Accommodation listings, 2) Activity listings, 3) Attraction listings, and 4) Bar listings. If no one objects, I'll add the same guideline to these four pages. Basically, for any list within a section or subsection (like pricing subsections for accommodations), if no other criteria for ordering is being used, alphabetical order should be the standard. Does that sound reasonable? (WT-en) Spmenic 19:45, 30 July 2008 (EDT)
Sounds good to meit sometimes takes a long time for our practices to, er, filter down into policy! --(WT-en) Peter Talk 22:48, 30 July 2008 (EDT)

Avoid HTML

Please see discussion at Project:Avoid HTML on deprecating that page and leaving a simple comment somewhere else in the MOS that simply instructs editors to use MediaWiki markup instead of HTML where possible. (WT-en) LtPowers 10:53, 9 November 2009 (EST)

But the manual of style really is just a link to lots of small-ish guidelines. The advantage of having them as separate articles, is that you can easily link to them from edit comment and so on, rather than having to link to a subheading within an article. --(WT-en) inas 20:44, 9 November 2009 (EST)
But the current "Avoid HTML" guideline is out of date and incorrect; adjusting it leaves what is effectively a one-liner. Isn't there some other MOS page that can accommodate a single line about which markup to use? (WT-en) LtPowers 21:46, 9 November 2009 (EST)
(It might fit in Project:Wiki markup, for instance.) (WT-en) LtPowers 21:49, 9 November 2009 (EST)
Sounds like a great place for it. --(WT-en) Peter Talk 21:55, 9 November 2009 (EST)
Seconded. -- (WT-en) Ryan (talk) 22:49, 9 November 2009 (EST)

Just give me a link I can point people who make edits like this to, and I'll be happy. Perhaps you can just redirect Project:Avoid HTML, to wherever you move the info to, so I can find it easily. --(WT-en) inas 01:07, 11 November 2009 (EST)

Just use a shortcut like html to [[Project:Wiki markup#Avoid HTML]] or whatever it will be. --(WT-en) Peter Talk 07:38, 11 November 2009 (EST)

time for recommendations on prose?

I frequently re-write/reformat introductory prose to See-Eat-Drink-Do (most often for countries) with the following points in head:

  • give a reader idea of what's this paragraph about and whether it applies to a reader as early as possible
  • emphasize a keyword on what's this paragraph is all about--I assume that most readers have little time on way to destination/already there, and they scan articles more often than they read them carefully and with no hurry
  • therefore, every paragraph should cover only one topic--if reader is not interested in keywords/idea expressed by a first sentence, he will skip the paragraph (and we should help him)

(Feels like there's something else, but I can't add anything off the top of my head)

So how much are these principles shared by other editors here?

And if so, wouldn't it help to write down these principles for newcomer contributors, in the hope that sometimes they will follow? --(WT-en) DenisYurkin 17:39, 6 February 2010 (EST)

I'm not sure why you assume someone is only skimming a guide. (WT-en) LtPowers 20:51, 6 February 2010 (EST)
Not everyone, but that's absolutely valid (and frequent) scenario, and I believe we'd better support it -- to make the guide usable by more categories of readers. --(WT-en) DenisYurkin 02:26, 7 February 2010 (EST)
These points seem like general elements of good writing prose. Introduce sections well, include summary sentences, cover one point per para, guide readers to the the information they are seeking. I'm sure we could maybe find a link to s reputable site on good writing style that would include this sort of stuff? --(WT-en) inas 04:40, 7 February 2010 (EST)
I don't mind if we have a link to a reputable source for details, but I feel that we'll still need to summarize the key points we seek. At least, I don't feel an expert to suggest any specific external source, but I think we can add value even by listing the key recommendations we adhere and ask to follow. If there's a consensus that it would be useful, of course.
So if there are objections to the above suggestion, please voice them. --(WT-en) DenisYurkin 07:40, 7 February 2010 (EST)
I think it would be a good idea to give some guidence on writing introductions. General advice on the prose as suggested by Denis above could fit in, but in my opinion it is more important to give guidence on what kind of information to give in the introduction and maybe also to show a couple of well written introductions, (WT-en) ClausHansen 11:39, 7 February 2010 (EST)
Certainly I have no problem with wiiting guidlines being here - but I'm sure someone has done a better job than we could on how to write effective prose. We can focus on guidelines on Content and Tone. Certainly our Star articles should be our example. Without checking them all, I'm confudent that the majority of these contain these introductory para's. --(WT-en) inas 15:18, 7 February 2010 (EST)

OK, to start with: where should we stick it? I'm not sure about a right place--any suggestions?

And after that simple rules done, perhaps we could move on to more advanced recommendations on introductions (which I also feel useful, although not have too much to contribute). --(WT-en) DenisYurkin 17:44, 7 February 2010 (EST)

SHOUTING

The writing style section does not seem to say anything about NO SHOUTING. I guess a guideline is given somewhere on this, but should it not be here? --(WT-en) Burmesedays 09:57, 7 February 2010 (EST)

I think it's more of an internet-standard than a Wikivoyage-standard - "don't shout at someone" is common sense - but adding it to the MOS would make sense given the number of all-caps edits we get. -- (WT-en) Ryan (talk) 12:09, 7 February 2010 (EST)
Common sense isn't big on the internet. Our rowdy editors are mainly touts whom I suspect doesn't make much of an effort to read such pages, but it might turn out to be a useful explanation when they try to figure out why their edits were reverted. Though to that end, it might be more useful in the "If your edits are reverted" section of business owner page --(WT-en) Stefan (sertmann) talk 12:15, 7 February 2010 (EST)
I do not support this policywe shouldn't prohibit South Asian Wikivoyageers from contributing here. --(WT-en) Peter Talk 13:12, 7 February 2010 (EST)
 :) It is compulsory in India I believe:). Good edit to Project:Welcome, business owners, but I think it should be in the MoS as well. Writing in caps and the use of grotesque frontlinks are the most widespread style infringements here.--(WT-en) Burmesedays 20:12, 7 February 2010 (EST)

Thousands

I can't find a definitive reference for all numbers anywhere, but I assume that numeric thousands should be separated by a comma? Ie. 10,000 and not 10000? On the currency page it says to do this, but in measurements there is an example of "good practice" that does not use a comma separator. Clarification or correction required? --(WT-en) Burmesedays 09:11, 14 February 2010 (EST)

The examples at Project:Measurements use the comma very consistently. The only time they don't is when there are only four digits, which is apparently a widely-accepted standard. (That is, one writes: "5280" but also "15,280".) I would say there is consensus site-wide to use commas, with them being optional in the case of a four-digit number. (WT-en) LtPowers 10:13, 14 February 2010 (EST)
Thank you for that. It does seem odd that it is OK to write 8000 and 80,000 (rather than 8,000 and 80,000) in the same article, but if that is a widely accepted standard, then fair enough.--(WT-en) Burmesedays 10:21, 14 February 2010 (EST)
I only know about that standard because of Wikipedia (Wikipedia:Manual of Style (dates and numbers)#Delimiting (grouping of digits)). As noted there, years with four digits are never written with a comma, but years with five digits are. I think it's because four digits are easy enough to parse without the comma. =) (WT-en) LtPowers 19:55, 14 February 2010 (EST)

Minor grammatical points

It would be great if we could agree these 3 points, write them into the Manual of Style once and for all, and never have to talk about them again. This is prompted by a discussion here.

  • Serial commas. I think there is a broad concensus here that we should use serial commas. This has been discussed in several Star nominations, eg: Talk:Bali#Star_nomination_2. Any objections?
  • Single spaces between sentences. Could there possibly be any objections?
  • Mdashes. This debate has been going on for a while, and is not helped by the fact there seems to be no widely accepted standard. This discussion is relevant. An issue seems to be whether an mdash in an block of text should have a space before and after it or not. I could not give two hoots, but so we never have to talk about it again, could we please decide?--(WT-en) Burmesedays 12:26, 6 May 2010 (EDT)
  1. I can't find any discussion of serial commas in the Bali star nom; the commas discussed there involved those preceding independent clauses. I am strongly in favor of serial commas in general; although both formats can be misinterpreted, including the serial comma is usually less ambiguous and allows for more ways to rearrange the list to avoid ambiguity.
  2. I see no reason to have a rule about this at all. HTML ignores consecutive spaces. In fact, since the edit window uses a proportional font, double-spacing in the code is actually quite helpful, for the same reason the double-space convention arose in the first place: typewriters use a proportional font.
  3. Most major style guides use an unspaced em-dash. Some do not, and some say either is acceptable, but I'm pretty sure the former is most common. (WT-en) LtPowers 13:28, 6 May 2010 (EDT)
-- (WT-en) LtPowers 13:28, 6 May 2010 (EDT)
There are major style guides both ways on serial commas, and one of my concerns is that they are yet another American-centric feature, and I would be resistant to seeing them mandated. It is easy enough to add the comma when if and when it resolves potential ambiguity. I find it looks a little ugly, elsewhere. I find no need to impose it as a matter of Wikivoyage style, and if we get to the point of judging a star by whether it uses serial commas or not, IMO our criteria are fundamentally misplaced. I'm happy to go with the flow on emdash'es. --(WT-en) inas 20:30, 6 May 2010 (EDT)
1) We have come to a consensus, I would say, on using the serial comma at Project:Spelling#Harvard Comma, and that has been in effect for quite some time. (And for what it's worth, Inas, the Oxford Style Manual prefers the serial comma, and actually refers to it as "The Oxford Comma"—it's the traditional use of the punctuation, not an Americanism).
2) As LtPowers says, spacing after periods is irrelevant here, as it will display the same either way.
3) I don't like the tyranny of universal formats, and prefer that we use local standards for articles. This is why I supported (also on the Project:Spelling page) the move to use Commonwealth spelling in British articles and American spelling for U.S. articles. My punctuation predilections are conservative, so I tend to favor the style guides put out by Chicago and Oxford, both of which state that em dashes used in prose should never be spaced. Actually, virtually all the major English language style guides for publishing (UK, Canada, U.S., Australia) state that they should not be spaced—those in disagreement tend to be the style guides of specific journalistic organizations, which prefer a more liberal use of punctuation and more generally the English language. This is getting long-winded, so I'll get to the point, and say that I prefer we use the most common local English publishing standard by country, and this will generally be an unspaced em dash.
Lastly, we should probably move this discussion to Project:Spelling, as that is where we have had our ever-engaging discussions on the finer points of punctuation in the past. --(WT-en) Peter Talk 20:39, 6 May 2010 (EDT)
There is no consensus there for a serial comma. A couple of people expressing support, a couple of people thinking that it really is too prescribed for a policy. As always, these trivial points get ten times the focus they should, when people could be adding travel info rather than worrying about where a comma comes in a list. The Ocford style guide is very much at odds with every other outside of North America - much like it is with the 'z' vs 's' debate, as I'm sure you are aware. --(WT-en) inas 20:52, 6 May 2010 (EDT)
It is those very discussions about trivial points that I am trying to banish forever by enshrining a policy. It does not really matter does it? So why not write into the MoS and forever remove these debates which keep cropping up. I could not give a stuff either way on serial commas and spaced mdashes for example. But we ought to be consistent. --(WT-en) Burmesedays 21:58, 6 May 2010 (EDT)
I really do appreciate your point, but I also think being prescriptive about these things causes unnecessary time wasting debate as well, and having Americanisms imposed on people does very much tend to annoy some. I really was serious when I suggested over at Project:Spelling that all Commonwealth countries should use American spelling, and all American use Commonwealth. After all, what is the point of being a Wikivoyager just to insist that everything is done the way I'm used to. I would like the spelling guideline to say that it really doesn't matter which type of spelling we use, but don't use words that have shades of meaning in different parts of the world. I would like the serial comma policy to say, we don't care what type of comma you use, but anything you can do that makes the sentences clearer, do. I would argue that people that can't cope with a serial comma in or out of place should be issued with a pedantry passport for their journey through Wikivoyage. P.S. Meaning no offence (offense) to pedants, some of my best friends are pedants.. --(WT-en) inas 22:29, 6 May 2010 (EDT)
 :). And the debate will go on forever and silly edit wars will no doubt rear their head. I am about as far from a grammar pedant as you will find, but I do like consistency. --(WT-en) Burmesedays 22:50, 6 May 2010 (EDT)
Consistency and resolved issues are admirable aims, but you don't get rid of the debate in these sort of cases by making a decision one way or the other, you just annoy those contributors who feel imposed upon. WT had prescribed American spelling for ages - for a while I even acquiesced to the stupidity of "Sydney Harbour is a harbor in Sydney" - however, there were many that resented this as an imposition, and many other editors making edits and reversions on this basis. I think the issue may even have got rid of a few contributors. --(WT-en) inas 23:23, 6 May 2010 (EDT)
[Bangs head on desk] Ian, the serial comma has been established as our preferred format in that discussion, in others, and applied as a low importance issue on multiple starnoms. Declaring that "there is no consensus" is quite a stretch, and as you consider these issues trivial and potential time-wasters, why on earth would you want to revise history to try and work around consensus to reopen a trivial (i.e., potentially intractable) issue that has been for all intents and purposes resolved for a good two years? Stating that you don't like it, and would prefer we conform to local publishing standards would make sense, and I'd be very sympathetic, but denying that we've preferred the serial comma for years doesn't align with reality. --(WT-en) Peter Talk 23:36, 6 May 2010 (EDT)
  1. Starnoms are not where policy or consensus on policy is determined.
  2. I'm not working around consensus. What I'm saying here isn't contentious. Reality is better observed in the vast majority of actual articles around Wikivoyage. Reality is that articles will always be a mixture of these styles, and the task of every getting even a small fraction to have a consistent use of commas is hopeless. If people making working on a starnom want to have consistent commas and they agree on that, then that is great too. The star is no doubt better for the internal consistency, and there is already a strong guideline that stars are grammatically consistent. I don't think we need any more than that.
  3. I'm not trying to reopen a trivial debate - I'm actually trying to stop it reopening by objecting to a prescriptive addition to the mos, where I don't believe it is a serious enough issue to be prescribed. I realize there is a certain paradoxical recursion involved in arguing in order to prevent an argument. I'm not quite sure I have my head around that.
  4. I personally find it ugly, but I accept that it likely my prejudice, and I certainly wouldn't want to prevent anyone else using it on that basis. I'm sure I use both styles on WT, and that I read both styles without being overcome by the need to hit the edit button.
  5. Hope the forehead doesn't bruise :-> --(WT-en) inas 00:00, 7 May 2010 (EDT)
"Realize"? — you can't be serious :). At this moment I am truly regretting starting this discussion as it is having the precise opposite effect to that desired. --(WT-en) Burmesedays 00:15, 7 May 2010 (EDT)
I do not care at all about whether we use serial commas or not, or whether we use mdashes with or without space, or for that sake whether we use US or UK spelling. But I think consistency is important. It looks strange if we do not have the same style in different articles and it annoys me as a contributor and patroller that I in principle have to know about a number of local spelling and punctuations standards. Therefore, I would prefere to have clear policies on these matters stating what is the prefered style, but also stating that it is low priority. Such policies would help us avoid these pointless discussions popping up in the future, --(WT-en) ClausHansen 00:51, 7 May 2010 (EDT)
I could not have written that better myself Claus. Anyone who doubts the sense of having a consistent policy might want to read the comments and intentions of a new user here. --(WT-en) Burmesedays 03:13, 7 May 2010 (EDT)
And look at the discussions at Project:Spelling, and elsewhere for how worked up people can get when "foreign" spelling conventions are imposed on them. Having a rule for consistent American spelling failed, and the "pointless discussions" recurred regularly. How many people announce their appearance on a travel site with their position on the serial comma, and do you really think such a person would really be kept satisfied if we amended the policy to ban the existence of a serial comma on Wikivoyage? Unlikely. Consistent, but ineffective. --(WT-en) inas 01:11, 10 May 2010 (EDT)
In six years we've been unable to come to an agreement on a spelling policy, much less serial commas, whitespace, etc, so I'd be in favor of language such as the following:
Recognizing that Wikivoyage editors all have their own writing styles, and that spelling and grammar vary from country-to-country, Wikivoyage does not specify any rules with respect to spelling and grammar other than be consistent within an article. However, since from experience we realize that there will always be cases where it is impossible to come to agreement on a standard for an article, the following guidelines should be used in cases of edit wars or unresolvable disagreement:
The idea being that everyone has their own preference, so let's recognize that but also have a written guideline to fall back on in case of disputes. As to specific guidelines to use, Burmesedays's list above looks fine to me, with the caveat that people don't seem to care about whitespace between sentences. For my part I don't care at all, I'd just like to have some guideline that helps resolve conflicts while emphasizing that this issue is low on the importance scale for the majority of articles. -- (WT-en) Ryan (talk) 01:28, 10 May 2010 (EDT)
That looks fine to me, --(WT-en) ClausHansen 02:11, 10 May 2010 (EDT)
I like the sentiment, but the obvious issue is the grammar pedant simply forces the edit war, and then effectively forces the style. Would anyone consider partly Ryan's text, but adding something to the effect of. Wikivoyage does not advocate a particular style guide, but aims for a style that is widely understandable and clear. Edits purely to change or impose a particular style on an article that do not add travel information, clarity or consistency are highly discouraged. Where multiple travel editors cannot agree on a style, they should first look to the Oxford Style Manual for assistance in resolving particular disagreements. This gives us a baseline, marginalize the pedants, and still allows the current stars and stars-to-be to keep their current style. --(WT-en) inas 02:26, 10 May 2010 (EDT)
Inas's text works for me (or is it "Inas' text" :-P ). If there is agreement for this text it would also be helpful to have a few examples from the Oxford guide for those (like me) who don't care enough to bother looking them up. -- (WT-en) Ryan (talk) 10:12, 10 May 2010 (EDT)
The "text by Inas" :). I suppose we have to deal with those damn s's as well. I think Ryan's proposal achieves what I hoped for here. We may have to reference the policy of America versus other spelling as well. I say that as I think the Oxford Style Manual comes down in favour of z's overs s's, eg: marginalize rather than marginalise. We do not want to open that whole hornet's nest again, so we should make clear that the policy about English American versus the rest, supercedes this.--(WT-en) Burmesedays 10:40, 10 May 2010 (EDT)

Agreed. Where we have a policy, it takes precedence. I think all of these are at []. --(WT-en) inas 19:12, 10 May 2010 (EDT)

I can't really agree with the phrasing "Edits purely to change or impose a particular style on an article that do not add travel information, clarity or consistency are highly discouraged." That would mean most of the edits done by regular users over the years with the edit summary "mos" would be highly discouraged ;) The problem comes when someone is trying to change a style that is already acceptable per our guidelines. I think that our Consensus#Status quo bias already takes care of that problem neatly.
As for which manual of style to use, I think the two good options are to a) just pick an answer to the three–four outstanding punctuation issues, or b) stick to local publishing standards. For the U.S., I think the obvious choice would be the most commonly used publishing style guide, the Chicago Manual of Style. (I assure you that I in no way favor this style guide because it's the only one with which I have familiarity from prior publishing experience.) For other countries? It looks like Canada and Australia are straightforward, but not so the UK. Ultimately, though, these types of extremely fine levels of style granularity are only going to be relevant when we're trying to format an article for offline publishing or putting it through a starnom (with the associated "perfection" criterion), so for the most part, I say let people write in whatever style comes naturally to them, unless they're shooting for the stars. --(WT-en) Peter Talk 20:28, 11 May 2010 (EDT)
I think the sentiment "let people write in whatever style comes naturally to them" is exactly what we are trying to get across here. Although the status-quo bias may already express this implicitly, since we seem to have a general agreement, can it hurt to just state this explicitly?
I think when we are talking about style here, we are not referring to mos style edits, but rather obtuse aspects of grammar. We should make this clear (as I and others suggested) that the mos overrides all, and is an entirely valid reason to edit.
If an article already has a consistent style in line with our formatting guidelines and mos, there is surely no need to impose a grammatical style guide on it for it to become a star?
As far as the Chicago/Oxford choice, I'd prefer to avoid parochialism again. I'm sure most of the elements of style that may concern us are entirely reasonably dealt with in both, I just see the Oxford as a possible compromise to avoid having a style guide for each region. --(WT-en) inas 23:01, 11 May 2010 (EDT)

Time-bound contributions

I come across many contributions, and am perhaps guilty of some myself, that fail to consider that Wikivoyage will, we hope, be around in 5-10 years. Thus you have lots of statements like:

  • has recently opened
  • will open in December 2008
  • is due to close in October

These would be fine if the people writing them remembered and went in later to update their statements. But, realistically, this is unlikely to happen, with the exception of a few major articles. Is there any advice on this in the Manual of Style. If not, is it needed? (WT-en) Shep 02:41, 28 August 2010 (EDT)

Good question. In most cases, I don't think it's a big deal, as long as there's a year included. And we shouldn't presume that it will go out of date, even though they often do; temporal references are not inherently bad. (WT-en) LtPowers 09:07, 28 August 2010 (EDT)

how to emphasize prose keywords in listings

Per LtPowers suggestion, please join us in discussing how we can emphasize keywords in prose for listing (for restaurants in my case). And yes, my original proposal is to use underlines (which means little amount of HTML). --(WT-en) DenisYurkin 16:22, 1 December 2010 (EST)

I wouldn't support using HTML outside of a template on article pages. I think it is quite against the wiki way. --(WT-en) inas 00:38, 2 December 2010 (EST)
I'd agree with Inas that we should discourage direct HTML usage as much as possible. Bold or italics have in the past been the preferred method of calling out a key word or phrase. -- (WT-en) Ryan (talk) 00:55, 2 December 2010 (EST)
But bold emphasizing of keywords would mix with establishment names, thus making scanning the listings more effortful (and keywords less effective). Deriving from "traveller comes first", I would even allow underlining HTML for this specific case -- especially that they are part of <listing ...> tags which are clearly much more HTML (even if they allow friendly field-by-field editor). --(WT-en) DenisYurkin 03:56, 2 December 2010 (EST)
My concern with HTML usage is that I think it would be a slippery slope that could give new users the impression that adding HTML to pages is standard practice. For example, a new user who sees underline tags might assume that any HTML is OK as long as it makes the article "look better", and thus might start adding font tags, italic tags, break tags, and other tags that break standard formatting. The listing tags are XML, but not HTML, so a user who sees those shouldn't be tempted to use HTML as a result. -- (WT-en) Ryan (talk) 11:13, 2 December 2010 (EST)

This is to demonstrate 3 styles: User:(WT-en) DenisYurkin/EmphasizeKeywords#Splurge

  1. my original proposal: keep establishment names as they are; underline keywords
  2. what is suggested in the above discussion, as I understood it
  3. an attempt to find a compromise: what if we modify listing tag templates so that they underline establishment names rather than bold them--I tried to mock up that, as I can't modify CSS(?) which defines how listing XMLs are translated into HTML

In my belief both #1 and #3 looks readable (try printing them to make sure), while #2 is clearly much more difficult to skim when on the run.

If we can't change how listings are processed (per IB issue), maybe we could reach a consensus on establishment a clear exception for underlines only, for emphasizing keywords in listings? --(WT-en) DenisYurkin 15:42, 2 December 2010 (EST)

I'm happy with the view, but still not convinced by the html. I'm loathe to suggest a tech request to IB? --(WT-en) inas 17:26, 2 December 2010 (EST)
If we are OK to wait a year with it, I'm fine. Do I need to gain a wider consensus on this change prior to posting a tech request to IB at shared:? If so, where would you suggest to ask for further comments? --(WT-en) DenisYurkin 17:36, 2 December 2010 (EST)

MOS article incorrectly titles "Manual of style in US"

I believe "US" is to be abbreviated as U.S., according to what I've read about abbreviations. Someone might want to make a quick change... (WT-en) Zepppep 14:43, 7 March 2012 (EST)

The Chicago Manual of Style, 16th edition, made headlines two years ago by "reversing" its previous insistence on the dots. Usage in the US is gradually moving towards no dots. Please note that outside North America, the dots are usually not used. Tony1 (talk) 13:57, 10 January 2013 (UTC)Reply
Very true. However, for the initial decade or so, there was a powerful US voice in favour of the more tedious style here, first at Wikitravel and then on the new, forked Wikivoyage. Gradually we have swung round to being more streamlined, but Abbrev.#Countries still specifies "United States of America" is an exception to our general rule that abbreviations should not include full stops or periods and should be abbreviated as U.S. (with periods, and not US nor USA nor U.S.A.). I'm one of those who would like it changed to the shorter, more consistent style.
PS the draft policy of having a separate US Manual of Style was nuked only very recently. -- Alice 06:28, 13 January 2013 (UTC)
Powerful U.S. voice in favour? Have we been on the same site? I'd say 99% of people here don't give a toss, and are just happy for it to be one way or the other and not endlessly rehashed at the expense of actually improving the travel information. --Inas (talk) 09:30, 13 January 2013 (UTC)Reply
Why not just make it optional, given the number of instances of U dot S dot there are. Another issue is the use of the full, legalistic United States of America (I've been reverted on that once already). So I formally propose that all instances of United Kingdom be made United Kingdom of Great Britain and Northern Ireland. There are others, too. Tony (talk) 23:54, 13 January 2013 (UTC)Reply
Now there's an idea!
Would anyone object if the current Abbreviations#Countries section was deleted in its entirety?
Would anyone object if I then made a consequent and subsidiary change of removing completely the recent subsection heading of "U.S. routes" and subsequent text of "Numbered highways in the U.S. are abbreviated as follows:" and then amalgamating, in alphabetical order, the three abbreviations listed in the sub-section of "Interstates: I-80", "National highways: US-395" and "State highways: CA-49" ? -- Alice 04:28, 14 January 2013 (UTC)
Tony, I've explained why that change was reverted. It was nothing at all to do with formality. If you want to write US, rather than U.S. in your contributions, go right ahead. Thousands of others have, and up until now there has been no one going around and adding and removing dots. --Inas (talk) 04:52, 14 January 2013 (UTC)Reply

Alignment of images - left or right?

Swept in from the pub

Hi folks. Can someone please point me to the policy about the alignment of images? Cheers. --(WT-en) SaxonWarrior 07:08, 9 September 2011 (EDT)

Structure of the MOS

Colleagues, on looking through this very useful resource, two things occur to me. First, some of the linked submanuals could do with some drastic rationalisation, debloating. And second, this central page could give a brief round-up of the main points of each, rather than totally relying on users clicking through to the outlying pages.

Your thoughts? Tony (talk) 13:28, 12 January 2013 (UTC)Reply

Both good points; it often takes a fresh eye to see these things. However, tread cautiously and politely (not, as an experienced Wikipedian you need this redundant advice); here be dragons of conservatism lurking (grin). Some editors have been here a long time and are very stuck in a rut. -- Alice 06:21, 13 January 2013 (UTC)
I wasn't aware that my post here was either incautious or rude. Tony (talk) 06:24, 13 January 2013 (UTC)Reply
It's not, Tony. That's why I used the word "redundant" above. -- Alice 06:30, 13 January 2013 (UTC)
Tony, please give some examples, so that we can discuss them. And no, it isn't rude to bring these kinds of things up for discussion. Ikan Kekek (talk) 07:09, 13 January 2013 (UTC)Reply
Hi Tony. Have you seen Wikivoyage:Directory of policies and guidelines? Is that the kind of thing you were thinking off? --Inas (talk) 09:32, 13 January 2013 (UTC)Reply
Inas, well yes, that's much better. I'm wondering why the MOS can't be more like that. I think mainly of new/occasional editors, who are likely to be put off by the current sprawling structure of the MOS. Would it be possible to have the basics, as short as possible, against each of the links in the MOS? People could still link to the outlying page if they want more info. And some of those pages are pretty short in terms of substantive info. I'd opt for rationalising and shortening the text. I could give some examples, but perhaps in a little while if people are interested in the notion of making the policy structure easier and shorter for newcomers—where appropriate, of course. Tony (talk) 12:07, 13 January 2013 (UTC)Reply
I'm certainly interested. Ikan Kekek (talk) 20:30, 13 January 2013 (UTC)Reply
I'd be happy to make the MOS a link the appropriate section of the above directory. --Inas (talk) 00:48, 14 January 2013 (UTC)Reply

Photographs

What guidelines are there for including photographs in the articles? --Lbeaumont (talk) 17:11, 15 January 2013 (UTC)Reply

Please see Wikivoyage:Image policy. Thanks for your interest! LtPowers (talk) 18:33, 15 January 2013 (UTC)Reply

Incorporating large part of the WP manual of style

I'd like to suggest that there are many stylistic items that make little difference to a travel guide. We tend to get distracted by these trivialities, and some users are even angered by them. None of the discussions further the development of a travel guide.

In many cases, the arguments here duplicate what has already been decided on Wikipedia. I'm not saying WP is any more right. Just that in cases where there isn't a right or wrong, we may as well move the argument somewhere else.

So, I'd like to propose we adopt the WP Manual Of Style, as our baseline. And then we amend the styles by local policies when the style of a encyclopaedia differs.

We keep our tone policy, of course, but we no longer have abbreviations, units, spacing, time format policies. Anyone who want to argue them can do so on WP.

We abandon our British/American spelling and other spelling policies. We simply follow whatever the WP default is for an article on that geography.

My point here is these things don't matter, and are fairly arbitrary. So, we shouldn't spend time on them, when we could be spending time focussing on travel content, and style consistent with travel content. --Inas (talk) 23:40, 3 October 2013 (UTC)Reply

I'd be in favor of deferring to Wikipedia for anything not specific to a travel guide, given that these copyediting concerns take up a huge amount of energy, never seem to go away, and often seem rather arbitrary. Some suggestions for policies to consider applying this to:
Note that we also have Wikivoyage:Use of pronouns, but our guidance differs from Wikipedia. -- Ryan (talk) 00:05, 4 October 2013 (UTC)Reply
I'd be delighted to adopt WP standards on the things you linked to, which - and argument about which - I find mind-numbing, and which as Inas points out have taken up a ridiculous amount of time. Ikan Kekek (talk) 01:55, 4 October 2013 (UTC)Reply
I have no objection in principle. WP MoS is quite large and I don't know it all, though I work on WP as much as here, so it would make my life a little simpler. The specific items are subjects I don't have particularly strong opinions about anyway. Peter (Southwood) (talk): 09:22, 4 October 2013 (UTC)Reply
I'm sorry; I appreciate the impulse, but I have to strenuously object. WP's MOS is a source of constant conflict. If you think the distractions here are bad, WP is ten times worse. Furthermore, our I would argue that all of those policies you listed except Romanization and Spelling are specific to a travel guide. Those would be the only two I might support offloading to WP. LtPowers (talk) 12:20, 4 October 2013 (UTC)Reply
(a) The conflict can be there, rather than here. (b) Why do you think we need our own separate policy on currencies, units of measurement, or time and date formats? Ikan Kekek (talk) 12:23, 4 October 2013 (UTC)Reply
(a) I don't want to participate in the conflict there. It's a mess. We shouldn't be a part of it, nor should we be encouraging our editors to be a part of it. (b) Our policies are designed to reduce the amount of textual space things take up, in order to make compact listings. WP's priorities are different. LtPowers (talk) 12:30, 4 October 2013 (UTC)Reply
Furthermore, WP's MOS is extraordinarily complex. I don't think it's fair to force new WV editors to wade through all that just to find out how to format a listing properly. LtPowers (talk) 12:31, 4 October 2013 (UTC)Reply
I agree with LtPowers. I am used to Swedish Wikipedia and often frustrated with the amount of guidelines and policies on English Wikipedia. We should write our own rules on things we find important and rely on common sense for most of the rest, not give a blanket mandate for wiki lawyers to pettifog using those guidelines. A See also entry may be useful though, for some matters. --LPfi (talk) 14:05, 4 October 2013 (UTC)Reply
Before we discard this proposal, consider the magic of farming out the arguments about these petty, mind-numbing matters of format to WP and telling people that if they want to dispute them, they need to go there. Unless any of us are masochists, we won't take part in the disputes on Wikipedia, just defer to Wikipedia and tell the users who want to waste time in petty arguments about such things to make the arguments there. Ikan Kekek (talk) 21:02, 4 October 2013 (UTC)Reply
I'll echo Ikan's sentiments - one person's "compact" is another person's "cryptic and obscure". After years of watching these fights I'm convinced that these copyediting decisions are 70% subjective and 30% objective, and given that reality I'm happy to defer to Wikipedia because
  1. I don't think most of these copyediting decisions affect the quality of our guides in any significant way.
  2. If it's not a terribly important issue then agreeing on a standard, be it Wikipedia, ISO, an international grammar book, or whatever, and then just following that has the benefit of allowing us to focus on more important issues.
  3. If we follow Wikipedia then we get the additional advantage of having a pool of users familiar with the needed styles, as well as a bunch of bots and tools that can now be used here to free the rest of us from the need to deal with copyediting fixes.
I get that for some people these copyediting issues are hugely important, and so as someone who doesn't really care perhaps my opinion shouldn't count as strongly, but I also think that the majority of editors here view these issues as relatively unimportant, and thus removing them as an issue for our project to deal with may best reflect the wants and needs of the editor community here. -- Ryan (talk) 21:45, 4 October 2013 (UTC)Reply
Before forming an opinion on this, I would like to see a more detailed rundown of which of these things are already the same as WP, which are different, and of those that are different, which we would intend to keep different and which we would change to conform to WP. On the one hand getting rid of these debates would be kind of nice, but on the other hand, I think having too complex a hybrid of WP and unique policies could be more confusing than beneficial. I'm also inclined to think that our debates on these topics have been somewhat artificially exacerbated of late by the very type of troll we are learning to deal better with, and I personally don`t find them to be a huge distraction anyway. And regardless, since any adaptation of WP style policies would inevitably be some kind of hybrid (since we would be keeping some points and not others), it would still leave the door open for determined style obsessives to continue arguing for us to configure various points independently. I also don't want to risk giving newbies the general idea that we do things like wikipedia does overall, nor send people to WP's massive complicated MoS digging for clarification or digging up justifications for changing other things we've decided not to change here. Texugo (talk) 22:24, 4 October 2013 (UTC)Reply
(ec) I get that it's easier from a policy making perspective, but I'm not convinced it is from other perspectives. For instance:
  1. Wading through all the WP rules isn't user-friendly for newbies. There's a lot of rules there and I can see it being overwhelming. And parts of it aren't even relevant to travel writing (e.g., scientific style) so you have to work your way through those parts, too.
  2. WP's rules appear to be more developed and numerous than ours. Patrollers need to know and understand these rules in order to patrol effectively.
  3. What happens when changes are made to WP's styles? I don't know how often this occurs, but it means their styles have to be monitored and then we have to go through the task of updating our guides because WP changed their style.
  4. What works for WP isn't always appropriate for WV. Consider a couple of rules/guidelines in WP Currencies: (1) On first occurrence, consider including conversion to US dollars, euros, or pounds sterling, and (2) Generally, use the full name of a currency, and link it on its first appearance if English-speakers are likely to be unfamiliar with it. In the first case, shouldn't currency translations be covered in a specific section each time since currencies are very important in travelling? In the second case, we don't have pages for specific currencies, so the rule wouldn't apply. If we need to start writing exceptions to the WP rules, then we end up with policy discussions again and rules in two different places.
I'm not saying I don't support it at this time, but I'd like to see more clarification about how a style guide written for an encyclopedia interacts with the sometime divergent requirements of our project. Otherwise, I'm concerned we could end up making it easier from a policy-setting perspective but more confusing to the editor and patroller. And if our editors and patrollers are confused, it'll probably be reflected in our guides (not that there isn't confusion now!). -Shaundd (talk) 22:42, 4 October 2013 (UTC)Reply
You guys are making good points. But I don't think anyone's proposing to farm out all of our MoS to Wikipedia, only those parts we reasonably can. What we could do, instead, is state that x, y, and z are based on the Wikipedia standards as of such-and-such a date, and simplify the language as appropriate for WV, but direct people who object to the policies to argue about them at Wikipedia and then mention in the appropriate talk pages on this site if the policies change, at which point we could consider changing our policies but wouldn't be automatically bound to do so. Ikan Kekek (talk) 00:09, 5 October 2013 (UTC)Reply

I think the fact that the proposal is for farming out "only x, y, and z" is one of the things that troubles me most. It makes our policy more complicated, less transparent, and less in our control. And telling people "not our problem, take it to WP" seems a bit like a "la-la-la-i-can't-hear-you" kind of lame response. Texugo (talk) 00:39, 5 October 2013 (UTC)Reply

I'm happy with "la-la-la-I-can't-hear-you." I'd like a show of hands: How many of you would like to waste more time with incessant arguments about unimportant matters of formatting, instead of spending time working on travel content? And let's remember, these unimportant issues have prompted a disproportionate amount of the virtual yelling and screaming from problematic users. So whatever decisions we make have to be informed in great part by avoiding further time-wasting, user-losing debates on unimportant issues. Ikan Kekek (talk) 00:49, 5 October 2013 (UTC)Reply
Not to repeat myself, but I'd still like to see a lot more detailed info on what items this proposal would or would not involve before we get much further. Texugo (talk) 01:59, 5 October 2013 (UTC)Reply
As I said above I do not like to make Wikipedia rules local policy. I think most of the benefits can be gained with wordings as "see also the more detailed advice at w:Wikipedia:Romanization, which mostly is applicable". This would make following or not following Wikipedia a matter of common sense and possible local rules and conventions. Wikipedia guidelines could be used where somebody wants advice - in the areas where our issues are the same as theirs - but it would not be policy.
But when looking at the linked guidelines, I see they are full of issues specific for Wikipedia. E.g. for spelling, archaic style is an issue with wording in old sources needing modernisation when used in an article, for us it might be a way to get the right feeling at a monument. For Romanization of Arabic I notice it is mostly about page titles and thus with totally wrong focus. What Wikipedia guidelines would be usable without a lot of commentary?
--LPfi (talk) 09:52, 5 October 2013 (UTC)Reply

I think it's very important that editors concentrate on those issues they are interested in and care about and don't spread themselves too thinly.

Sometimes the reason discussions stall, is that some of the participants in them do find them mind numbing (sometimes its just because they are participating in so many disparate discussions they have inadvertently forgotten to answer a question).

People are different and have different areas of interest, expertise and competence.

Of Ryan's suggested list the only three that I'd like to see farmed out are:

I can't avoid commenting that I do find it a bit ironic that some of the opposition to sparse, clearly-signalled and relevant in-line links to Wikipedia has been on the grounds that we don't want to send our readers (even temporarily) to another website - but here we are discussing sending our editors to the same site to learn the basics of their craft or argue the toss. --W. Frankemailtalk 20:54, 8 October 2013 (UTC)Reply

Yeah, I see the irony, too, but it has to do with treating content differently from mind-numbing (in my view) matters of style. Ikan Kekek (talk) 22:19, 8 October 2013 (UTC)Reply
I had previously mentioned Romanization and Spelling as possible off-loading I might support, but I don't support moving Foreign words, as it has very clear travel-specific advice. Personally, I think our style policies have actually been relatively stable, and it's only been the move to WMF that has brought in a few editors with perhaps undue interest in such matters. This is a problem that should work itself out. LtPowers (talk) 15:33, 9 October 2013 (UTC)Reply
I'm with LtPowers here. I don't see this as a huge problem, and I have definite issues with to WP. Texugo (talk) 15:38, 9 October 2013 (UTC)Reply
Yes, you're certainly right about Wikivoyage:Foreign words becoming just a soft re-direct to w:Wikipedia:Foreign words#Foreign terms LtPowers, since I now see that, not only is our own article easier to understand, it does also have travel-specific advice - especially about how we name our articles, so my list of possibles are reduced to two. --W. Frankemailtalk 17:06, 9 October 2013 (UTC)Reply
Well, I would disagree that we don't currently have a problem. We've taken up so many words and time on these things. There are people who like the copyediting stuff, rather than the travel content. Our style guides are clearly insufficient for their use, and the amount of people contributing to the discussions isn't sufficient to generate a meaningful consensus. We have people making changes to guides, and proposing policy changes that aren't any better or worse, they are just different. And weren't not proposing half-assedly farming things out. We're testing the water, seeing what support we're likely to get for such a move, and if we make changes they will be well considered.
I also disagree that the editors coming across from WP is a temporary phenomenon. We've linked up with these guys, and I expect many of our editors to come from that direction. --Inas (talk) 22:01, 9 October 2013 (UTC)Reply
I completely agree - from WP and also from Commons and other Wikis. And we've already gotten several great editors from WP/Commons/etc. Ikan Kekek (talk) 22:11, 9 October 2013 (UTC)Reply
By "half-assedly", I mean farming out select portions of the MoS, instead of all of it (which is obviously not feasible). Texugo (talk) 22:21, 9 October 2013 (UTC)Reply
Hmmm. Seems like an odd expression for that. It is the same model applied with much success elsewhere, focus on your core mission, and outsource the rest, lest it lead you to distraction. When NASA outsources their stationery printing, I don't think they do so half-assedly. Where the style guide reflects on travel writing, then we're working at the right level. When we start arguing the toss on spaces between units and numbers, then we've lost it. So, my proposal would be that where WV guides are silent on style, we tend to follow WP style. Day 1 nothing really changes. We can then work on eliminating the minutiae that we really don't want to be bothered with. --Inas (talk) 23:29, 9 October 2013 (UTC)Reply
That's an excellent example to pick, Inas. Not only is the WP page on units too complex a page to be sending newbies to (their eyes will glaze over with its complexity and pedantic detail as has already been alluded to above), but I think we could also follow our current HTML policy and be more consistent (no space between the degree symbol and either C or F or before Volts, Amperes or Hertz, are the exceptions that are currently preferred) by specifying a mild preference for no space between an amount and its unit. That way, newbies would not see those pesky non-breaking space HTML entities and we could maybe also get rid of wv:aou at the same time. --W. Frankemailtalk 23:46, 9 October 2013 (UTC)Reply
Just because we're a travel guide doesn't mean we don't have a responsibility to maintain certain professional typesetting standards. (It's bad enough people want to abandon professional cartographic standards in favor of dynamic generation!) LtPowers (talk) 01:37, 10 October 2013 (UTC)Reply
Well, cartographic standards aren't really relevant, but I guess it wouldn't surprise you that I think the dynamic generation will get us to travel maps we couldn't have dreamed of before. And the rendering is improving by new rendering techniques by the day. Professional typesetting standards I completely concur. Are you seriously arguing that our standards are somehow superior to those advocated on WP? My earlier suggestion (years ago) was that we adopt something like the Chicago Manual of Style as our default style. However, I appreciate that going down that path may be bound for style guide wars. I don't think our current style is in any way superior from a typesetting point of view. --Inas (talk) 02:16, 10 October 2013 (UTC)Reply
No, I'm not arguing anything of the sort. I'm arguing against Frank's idea to abandon spaces between numerals and units. LtPowers (talk) 14:28, 11 October 2013 (UTC)Reply
Have you recently read a printed edition of The Economist? If so, do you think it fails to maintain "certain professional typesetting standards" ? --W. Frankemailtalk 19:57, 11 October 2013 (UTC)Reply

[unindenting]
It seems we are now talking about these:

The WP Romanization page is mostly a list of script specific pages. As I noticed above, w:Wikipedia:Naming conventions (Arabic), linked from the WP Romanization page, is unsuitable. There is also w:Wikipedia:Manual of Style/Arabic, which could be linked but is much too detailed to be a guideline here and also describes use in different sections of Wikipedia articles, which is irrelevant and confusing for us. The linked guideline pages for many other languages are even less suitable. Thus any linking to WP pages should be done only if that specific WP page is useful, and the most useful page may or may not be one referenced in the WP guidelines. As this is a judgement call, it has to be decided in the process of developing our own guidelines, not as a blanket deferral.

w:Wikipedia:Manual of Style/Spelling is a guideline, but is not written as one. It describes differences in spelling between English variants, and may be a valuable resource. Similar guidance can be got from a good dictionary or one's own feel for the language. Where it gives guideline-like advice, it gives it from an encyclopaedia perspective. I see no reason to use it instead of or in addition to our own guideline.

So, in principle, I think we could use some of the policy work on Wikipedia, but in practice, we cannot rely on anything over there without case by case consideration. As so little is suitable, I think any general deferring to Wikipedia will make more harm than good.

--LPfi (talk) 12:09, 10 October 2013 (UTC)Reply

Inas: I think you have highlighted at least two interesting possibilities above:
  1. That where Wikivoyage guides are silent on style, we should tend to follow Wikipedia style at least until we have developed our own guidance. (An example of such an omission in Wikivoyage would be MOS:HEAD) and
  2. Make use of authoritative non-WMF style guides especially where they are appropriate and easily available. Because the Chicago is so expensive, I would instead commend to WV editors the Economist Style Guide which is accessible on-line without payment and where I have always thought the introduction offered some useful tips. The Abbreviations section in particular has some interesting advice.
LPfi: I think you are broadly correct in writing that "so little is suitable".
In regard to variations of English, I have now gone back to my original contribution above in this section and explicitly added (in a Green serif font) what I had already thought was implicit in Ryan's original proposal; that we should adopt WP's suggestion to use opportunities for commonality and also adopt wholesale, WP's advice that, in general, disputes over which English variety to use in an article are strongly discouraged (since such debates waste time and engender controversy, mostly without accomplishing anything positive.) I really do think that it would be a step forward to mandate that, when an English variety's consistent usage has been established in an article, it is maintained in the absence of consensus to the contrary. With few exceptions (eg, when a topic has strong national ties or a term or spelling carries less ambiguity), there is no valid reason for such a change.
What would be of particular utility is the tie-breaker that "When no English variety has been established and discussion cannot resolve the issue, the variety used in the first non-stub revision is considered the default". I realise this is highly controversial and part of the reason that Tony1 got perma-banned was for suggesting this, but I really would commend the principle that "If no English variety was used consistently, the tie is broken by the first post-stub contributor to introduce text written in a particular English variety." The variety established for use in a given article could then be documented by placing an appropriate "Established variety of English template" on its discussion page. If that concept was adopted, we could then go on to more clearly and authoritatively suggest that an article should not be edited or renamed simply to switch from one valid use of English to another and that editors who alter an existing variety can be advised of this guideline (perhaps via the placement of a suitable templated notice on their User talk page?)
Unlike, Alice, I'm only familiar with Germanic and Italic languages, so I will now defer to your judgement on Romanization and strike that suggestion from my tentative approval, LPfi.
--W. Frankemailtalk 13:02, 10 October 2013 (UTC)Reply
Tony1 got banned for acting like a jerk. Nothing more. LtPowers (talk) 14:28, 11 October 2013 (UTC)Reply
The problem with the "first non-stub revision" is that placing {{subst:smallcity skeleton}} and walking away is enough to advance an article out of "stub" into "outline" here. In that respect, our article classification does not match Wikipedia's. Nonetheless, a uselessly empty page with a template on it is still empty. I think we should be looking for the language in which the bulk of the original text was written. K7L (talk) 16:03, 11 October 2013 (UTC)Reply
You're right, of course; good point! --W. Frankemailtalk 16:24, 11 October 2013 (UTC)Reply

I think I now understand why so many different people are accused of being Frank. It's a bit like the middle ground in politics in any mature democracy - it's a crowded area where the general consensus lies.

It does seem blindingly obvious re-reading all those old (and typically inconclusive discussions) that most of the opposition to sparse, clearly-signalled and relevant in-line links to tertiary sources such as Wikipedia or the on-line version of the Encyclopaedia Britannica has been on the grounds that we don't want to send our readers (even temporarily) to another website - but here we are discussing sending our editors different sites "to learn the basics of their craft".

That said it's very difficult to ever reach a consensus if the opposition just stick with a version of "I don't like it" and don't answer clear questions.

Frank proposed:

1) That where Wikivoyage guides are silent on style, we should tend to follow Wikipedia style at least until we have developed our own guidance. (An example of such an omission in Wikivoyage would be MOS:HEAD) and
2) Make use of authoritative non-WMF style guides especially where they are appropriate and easily available. Because the Chicago is so expensive, I would instead commend to WV editors the Economist Style Guide which is accessible on-line without payment and where I have always thought the introduction offered some useful tips. The Abbreviations section in particular has some interesting advice.

Powers did not like Frank's idea to

3) Abandon spaces between numerals and units so that we could avoid the confusing-to-newbies HTML of wv:aou and also not have to have exceptions for degrees of temperature and electrical units.

However, when Powers was asked if he had recently read a printed edition of The Economist and, if so, whether he thought it failed to maintain "certain professional typesetting standards" I can not trace a reply from him or anyone else.

It would be a pity for this initiative from Inas to peter out inconclusively, so what exactly are the remaining objections, if any, to these three proposals ? --118.93nzp (talk) 03:07, 22 November 2013 (UTC)Reply

I don't think so. The essays on irrelevancies and sideswipes that you indulge in exactly the same way as User:W. Frank and User:Alice is what holds us back. Clear and concise proposals and objections drowned in a sea of discussion including inline links to wikipedia, regional variations of spelling, first editor and whatever else. Things that aren't even at issue here. Our consensus policy clearly says it is insufficient to hold the status quo just by virtue of objecting with no supporting reasons. I don't see that as the problem. --Inas (talk) 03:20, 22 November 2013 (UTC)Reply

A long time ago, Frank got me to agree not to comment on any policy discussions where he had commented in the hope that such a gagging or self-censorship agreement between us would ameliorate the false sock/meatpuppet allegations. That reasoning has failed spectacularly and I now consider myself to have the normal wiki freedom to comment on any topic (and I've messaged Frank accordingly).

If Inas is correct that our consensus policy clearly says it is insufficient to hold the status quo just by virtue of objecting with no supporting reasons, then after more than two months of no reasoned objection, it seems clear that we should now change our advice about spaces between numerals and units so that we can avoid the confusing-to-newbies HTML of wv:aou and also not have the exceptions for degrees of temperature and electrical units.

I would also like to see progress with the original idea of Inas, but it seems clear that in practice there is very little other than MOS:HEAD that we can adopt. I like the idea of using the "Economist"'s online style guide - or, indeed, any other free to use, authoritative online MoS other than Wikipedia's. -- Alice 02:46, 26 January 2014 (UTC)

Actually, MOS:HEAD includes "Section and subsection headings should preferably be unique within a page", which is contrary to our policy such as at Article templates/Sections#Get around, which says to use the same subsection headings in Get in and Get around. Nurg (talk) 04:45, 26 January 2014 (UTC)Reply