text:
Wikivoyage talk:External links/Audio guides

See also:
 * Project:Goals and non-goals

Audio guides - "otherguide" status
What not to link to currently states: "In particular, avoid links to other travel guides."

Should a note be added clarifying that this includes/excludes links to audio tour guides (eg www.audiotravel.com)?

 * I don't think that's necessary; it seems pretty clear that it does include audio guides. --(WT-en) Evan 11:18, 16 November 2006 (EST)

 * Perhaps the "confusion" results from thinking of it as an "audio tour" rather than an "audio guide", and listing it in a "tours" section, alongside other types of tours, eg bicycle tours, walking tours, etc, which I would guess the audio guide/tour people must regard as competitors (and which travellers would probably see as alternatives?) ~ 61.91.191.11 11:55, 16 November 2006 (EST)

 * Yes, I developed the audio tours as an alternative to guided tours. The audio tour shows travelers around the city just like a personal guide except that there’s no rigid schedule or large group to follow. The audio tour listing would provide Wikivoyage visitors, who like to travel independently, an alternative to the other guided tours that are listed. For this reason, I think the listing is a good fit in the tours section and I would like to re-list it. (WT-en) Dina 05:20, 30 November 2006 (EST)

I just came across the slowly growing list of audio guides on the London page, and then found this old conversation... I'm with Evan, this seems no different than linking to any other kind of guide, which we don't do... it doesn't matter that it's audio and fits on your ipod - I'm going to remove it, and if anyone disagrees, speak up here (WT-en) - Cacahuate 17:09, 16 February 2007 (EST)

 * I believe audio guides are much less our competitors than LPs or even Michelin restaurant guides. Audio guides can afford much more details then we have space for at wikivoyage in its current format, and I believe we won't be close to that level of details even in Star articles in foreseeable future. Besides, I think (although I didn't research the subject thoroughly) that audio guides focus on History, Understand and Attractions -- but never on practical side of travel, like hotels, restaurants or activities. And finally, audio guides provide framework, sequence and point of view--while we at Wikivoyage give much more freedom to the traveller (which is therefore a benefit for audience we target, and a shortcoming for consumers of audio guide).

 * In a nutshell: I believe we don't actually compete with audio guides, and helping a traveler to find an audio guide if he prefers that makes us more helpful for him--remember Traveler Comes First? --(WT-en) DenisYurkin 20:17, 17 February 2007 (EST)

 * So then what do you think sets apart audio guides from any other of the external links that we don't allow on the pages? (WT-en) - Cacahuate 03:07, 18 February 2007 (EST)

 * First is media we are not going to be in in foreseeable future (audio). Second is content structure and sequence we don't use here in most cases, except, rarely, iterinaries (which are normally very specific, compared to general-overview format of an audio guide). --(WT-en) DenisYurkin 03:30, 18 February 2007 (EST)

 * Competition isn't the issue, we're giving away our content for free. I think it's more about keeping the guides focused, and keeping any relevant traveler info in the guides, instead of linking to others, whether they be in text format, audio or otherwise (WT-en) - Cacahuate 06:08, 18 February 2007 (EST)

 * Yeah, I agree with Cacahuate. We don't not link to external guides because we fear competition, it's just one of our core non-goals to be a link directory and a core goal to be useful offline. It seem we have this discussion over every single different type of web media ("video is different!" "photo galleries are different!" "blogs are different!" "audio guides are different!"). A link is a link. (WT-en) Maj 11:24, 18 February 2007 (EST)

I suggest to include links to audioguides as a service to our users. Audioguides, like organised tours, are a way to enjoy your holiday. The only difference is that the 'story' comes on an ipod for the audioguide and trough a person in case of an organised tour. From a travelers perspective there is no difference so let's help them by pointing them to the relevant information and include the audioguides as we include the organised tours. Also, please be aware that audioguides do not compete with travel books or Wikivoyage as the content and presentation are vastly different. --(WT-en) Frank Gerritsma 16:30, 21 February 2008 (EST)

I'm not sure I agree, I've tried a few tour podcasts, mostly downloaded from torrents cause I suspect the quality varies greatly, and I don't want to shell out good money, on poor quality, when I can have multiple beers for the same price. Anyway, several of the ones I've tried were surprisingly good and provided in-depth information about the attractions, something which is more or less a non-goal for us - unlike say Lonely Planet - which more or less strives to be the exact same thing as we do. I've actually inadvertently broken this policy myself with a link to Audiowalks in the Copenhagen do section, since I know for a fact that they are good quality for the price, we can root out spam, just as we do with other listings which are generally accepted. --(WT-en) Stefan (sertmann) Talk 11:30, 3 February 2009 (EST)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Wikivoyage talk:External links/Hidden links

I have a question. I've noticed that some editors have been changing explicit links (http://www.massport.com/logan/) to buried links (Logan International Airport). Doesn't this make the page less usable when printed?

 * Good question. I think I'm going to have to hack on the Printable version code for MediaWiki to take something that renders like

text

 * and make it render like this

text (url)

 * I think that this is more of a technical problem than an editing problem, though. Let's keep doing the more readable links for now, where possible. -- (WT-en) Evan 11:54, 8 Nov 2003 (PST)

 * A URL in a printed guide is useful only if you're on the web, and if that's the case, then you can just go to the online Wikivoyage (using the URL printed on all Wikivoyage pages) and follow the link from there.

 * Of course this assumes that the URL on your printed version hasn't be removed in a newer on-line edition. On the other hand, the URL on your printout might be obsolete, but it's been updated online. -- (WT-en) Paul Richter 08:10, 7 May 2004 (EDT)

So.... does this policy page need to be edited to reflect a new consensus? I'm inclined to Paul's reasoning, though Huttite expresses an issue with doing this on User talk:(WT-en) Huttite. -- (WT-en) Colin 20:14, 21 May 2004 (EDT)

 * What new consensus? I'm lost. --(WT-en) Evan 20:39, 21 May 2004 (EDT)

 * I think the best way to do it is like this: use "readable" URL links in the External Links section with text next to them explaining them, for example:

 * http://www.tallinn.ee City of Tallinn

 * In all other sections of the article, we should use "buried" links. For example: one of Europe's undiscovered tourism gems is The City of Tallinn. This way, the URLs won't muddle up the integrity of the text when used in a paragraph, yet they will be understandable when used in external links. By the way, I remember hearing or seeing some time ago that URLs actually get printed in brackets alongside the link. Is this a Mozilla feature or is it part of the MediaWiki printable version style? (WT-en) Ronline 21:09, 21 May 2004 (EDT)

Unpacking URLs
''This conversation moved here from my talk page. -- (WT-en) Huttite 00:28, 22 May 2004 (EDT)''

Regarding User talk:(WT-en) Nzpcmad:

Hidden links are automatically printed in the "Printable version". So in the on-line version, visible URLs just clutter things up, I think.

Also, Project:External_links does not say that URLs should be explicitly included in article text. Rather, it's information such as addresses and phone numbers contained on the linked webpage that needs to unpacked.

Hidden links are fine on a webpage but useless on a printed page.

Any URL is useless on a printed page, until you type it into a computer connected to the web. In which case you can just go to the corresponding on-line Wikivoyage article and follow the links from there. --(WT-en) Paul Richter 09:55, 21 May 2004 (EDT)

 * Thanks for pointing that out. - What I was objecting to was that User talk:(WT-en) Nzpcmad had shown URLs behind the word here - i.e. here rather than Huttite's talk page. I was going off the Project:External links article, which I interpreted to mean that URL's should be shown explicitly. I had not realised that the printed version also shows the hidden URL printed in parenthesis following the hidden link.  Having now looked at the printed version I realise the External links article is unclear and I misinterpreted it.  Having now thought about it, I think it is even more important to write text so that the URL is able to be mentioned explicitly on the printed page.

 * I also contend that showing a URL is necessary on a printed page because there may be situations where Wikivoyage is not available but the site in the URL can be accessed. E.g. Internet outage, Wikivoyage server down, using a corporate intranet with restricted internet access. (I experience this latter issue at work, where access is confined to only relevant top level domains.) -- (WT-en) Huttite 19:29, 21 May 2004 (EDT)

 * OK, now I'm confused, The backpacker's link is explicit i.e you can see the http string on the page. The YHA is still hidden - you've simply "moved" it from under "here" to under "YHA". What's the difference? and which one is correct? --(WT-en) Nzpcmad 22:25, 21 May 2004 (EDT)

 * Perhaps I am confused too by the guidelines. After rereading them and trying to understand what was happening, I came to the following choices.

 * I chose to show the backpack link as a straight URL as it was not referring to a particular organisation or name that really fitted in the text, just a website URL that logically needed to be shown at that point.

 * I chose to hide the URL for the YHA under their name, as it would show as YHA (YHA website URL) on a printed page.

 * Here are the details: With the edit I made to New Zealand, I had a challenge. I had to rework the hidden links so the printed URL would show in an appropriate place.

 * The text I encountered was :
 *  There are a number of Youth Hostels (62 in 2004 - information here) and Backpackers (information here) accommodation around the country,

 * This prints as :
 * There are a number of Youth Hostels (62 in 2004 - information here (http://yha.org.nz/)) and Backpackers (information here (http://www.backpack.co.nz/)) accommodation around the country,

 * One can see that putting the hidden link under a word like "here" means it appears as here (URL) in printed text. On a printed page, that means that the text would not flow effectively as the URL would appear in an odd place. Also any reference to clicking on a word would not be logical in print as it could not be done.

 * I changed the text to :
 *  There is a wide range of Backpackers accommodation (more information at http://www.backpack.co.nz/ ) around the country, including a network of Youth Hostels that are members of the Youth Hostel Association (62 in 2004),

 * My revision now prints as :
 * There is a wide range of Backpackers accommodation (more information at http://www.backpack.co.nz/ ) around the country, including a network of Youth Hostels that are members of the Youth Hostel Association (http://yha.org.nz/) (62 in 2004),

 * I hope this is clearer now. I was confused by the intent of the Project:External links article as I initially understood it to mean that URLs should be shown explicitly and had not realised that they displayed when printed. This is not explained in the article. But it has implications for how external links should be hidden in article text. I think this guideline may need a rewrite to clearly state how external links should be formulated to minimise the impact of what happens to URLs when hidden links are printed. -- (WT-en) Huttite 00:28, 22 May 2004 (EDT)

 * No apology needed. I agree your change reads better. Maybe this page needs to be updated to reflect the official policy? Cjensen also asked this question!

--(WT-en) Nzpcmad 04:24, 22 May 2004 (EDT)

I added an explanation of buried links, trying to be as policy-neutral as possible. It seems like much of the misunderstanding is merely because people are unaware that buried links are printed. -- (WT-en) Paul Richter 08:02, 24 May 2004 (EDT)

Discussion continues in Project:External links/Links in listings.

Printing and external links
So, it's actually false that external links show the URL when printed. This only happens with the "printable version". If you do it with the regular version, the URL doesn't show up. Worth noting, I think. --(WT-en) Evan 15:54, 24 Aug 2004 (EDT)


text:
Wikivoyage talk:External links/Links in listings

Moved from Project:External links by (WT-en) Evan

Old discussion: Project:External links/Links in listings/Archive

Another alternative
How about writing external links as

 * Climb up to Arthur's Seat (web), an extinct volcano. Wonderful view of Edinburgh.

It would be nice to be able to write this in markup as

 * Climb up to Arthur's Seat [web:http://www.scottishsport.co.uk/walking/arthurseat.htm], an extinct volcano. Wonderful view of Edinburgh.

and have the external URL automatically displayed as a footnote in the printed version. Presumably that would mean adding it to the external links section with a reference to it in the text where the markup appears such as [1]. Is that too complicated? It would presumably require a code change to Wiki. The reason I'd prefer not to have the text Arthur's Seat as the link text is that that should be reserved for links to Wikivoyage topics such as Edinburgh in the example. Wikivoyage links could use a different font in the printed version.

With this scheme the URLs would be accessible in both the Web and printed versions but we would avoid ugly URLs embedded in the text. We would also distinguish between Wikivoyage and offsite links, which seems worthwhile.

There is one problem I can see. Sentences of the form: don't fit this format. They would have to be rephrased slightly as (eg)
 * Online visual traffic information is available at http://www.sytadin.equipement.gouv.fr/
 * Online visual traffic information is available (web)

A small image could be used instead of the word "web", if desired. (WT-en) Bobkemp 21:13, 1 Oct 2004 (EDT)

 * Hi Bob. In a couple of days (WT-en) Evan is planning to upgrade the Mediawiki software on which Wikivoyage runs.  When he does that all of the numbered links like this one  will become neat little images.

 * Meanwhile the listing format is meant to have a lot more information than a description and a link. Specifically it's:

 * Title, Location information. Contact information. Hours and days. Description. Price range.

 * The URL used to go at the end, but some people have prefered to link it out from the title. Me, I think that looks terrible especially in the wikitext and prefer to put the URL in the contact information.  I think we are going to compromise on putting it in the location information instead though, because some of us (not me) think that URLs are more important than the other contact information. -- (WT-en) Mark 08:31, 2 Oct 2004 (EDT)

 * Hi Mark. Yes, I understand that the listing information is more complex than in my example.  The idea was to keep it simple.  I didn't know about Evan's change (there's so much here to read) but it sounds good!  Presumably one can choose the image and hence use some standard one for external web links. (WT-en) Bobkemp 18:18, 2 Oct 2004 (EDT)

Wikimedia 1.3.5
We're now finally running Wikimedia 1.3.5 and, at least in the Monobook skin, you finally get nifty little external icons (Whee!). I think this would be a good time to decide on a format Once and For All.

I suggest this:

 * Title, Location information. Contact information, . Hours and days. Description. Price range.

When printed, this looks like this:
 * Title, Location information. Contact information, (2) ( http://www.site.com ). Hours and days. Description. Price range.

Two questions:
 * 1) Do we agree on the overall style — a numbered, clickable footnote with an extlink image?
 * 2) How about the exact location: after title, after location or after contact?

Comments welcome. (WT-en) Jpatokal 23:44, 10 Oct 2004 (EDT)

 * I personally don't like the "numbered" aspect of this format. I think a lone icon like Bob suggested above would parse better. As for the location of the icon, I think it works well there (or it could also be immediately after the title). -(WT-en) nick 01:01, 11 Oct 2004 (EDT)

 * Now that I see the wiki code, my initial practical problem with numbers is gone, but I still don't like the looks of it. I don't have any specific suggestion for improvement though, as I think the little link symbol would be too small by itself.  Maybe something like link or website, printing simply as ( http://www.google.ca ) might work.  The location is a good compromise though.  Keeps the website with the practical information, but still has the neat, consistent start to each line.  I expect there'll still be a lot of editing required to change work by new users to conform to MoS.
 * -- (WT-en) Neil 01:14, 11 Oct 2004 (EDT)

 * Can the number be automagically be replaced with a string like "web"? (The shorter the better.) 193.64.153.73 01:34, 11 Oct 2004 (EDT)

 * It shouldn't be too hard. I'll see if I can come up with a patch. Of course whether or not to apply it should be a community decision. -- (WT-en) Mark 04:26, 11 Oct 2004 (EDT)

 * How does this work with screen-readers that sight impaired people use? They generally prefer, as far as I know, to have meaningful text associated with links ("2" conveys little meaning, and nor does "small icon"), but I am no expert. -- (WT-en) Hypatia 04:57, 11 Oct 2004 (EDT)

 * I haven't used one either so I'm just guessing, but it seems to me that a screen reader would use its own CSS, and since the data's all there it would do something sensible with that data. -- (WT-en) Mark 05:04, 11 Oct 2004 (EDT)

 * Quite possibly, it's just that "Name of attraction... [intervening text]... link that happens to be to attraction" doesn't seem to me to give the CSS a lot of data to work with. I don't think you can indicate in CSS the association between that name and the link, which I imagine the screen-reader would want.

 * For example, I believe it's possible to get screen-readers to read out just the links on a page -- having it read "1, 2, 3, 4, 5" or "pic, pic, pic, pic, pic" isn't helpful. The association between Name of attraction and "link a little while later" is obvious to sighted readers, it's obvious to a program that explicitly recognises Wikivoyage conventions, but I don't see how it's obvious to CSS or anything that only has the DOM tree to work with.

 * If possible I'll get hold of a screen reader and try it out if someone can give me a good sample page, but I'd be a novice user. -- (WT-en) Hypatia 06:21, 11 Oct 2004 (EDT)

 * . Hi. I've just looked at the spec for HTML 4.01 and it seems that the 'title' attribute of the HTML 'a' tag is what we need to set, ie ... . That is what 'audio user agents', as they call them, are supposed to speak. (HTML title attribute defn).  Currently we put the URL in there but presumably BigCo web site could be made to set the title attribute to 'BigCo web site'. (WT-en) Bobkemp 21:14, 11 Oct 2004 (EDT)

 * It's not so much links of the form BigCo web site that worry me, it's the links proposed for attraction listings and so on, which are of the form (ie, no name, just the link). So, for example this wiki text:

 * BigCo's Bar, 100 Something St. ph 000 000 000. . Big Co's bar is the most happening place in town. $5 cocktails.

 * The HTML output of the wikitext will be something like: [3] ; there's no title tag for the screen readers, and the nearest appropriate meaningful text is right back at BigCo's Bar . As best I can tell, the only option the screen readers have  to describe [3] is to read out "link to double u double u..." or "link to square bracket three square bracket", or perhaps "unlabelled link" when they encounter links in the proposed listing style.

 * Of course I realise that the existing listing style has exactly the same problem. However, I thought I'd raise it because the trend seems to be very much towards "external URLs in listings should have as little text associated with them as possible, and we will in particular not associate titles with them". And for sighted web users and print users it is easy to look back to the beginning of the listing for the title, but screen readers tend to rely on links having meaningful text either HERE or  . Neither the existing or proposed new listing format support that. -- (WT-en) Hypatia 14:43, 19 Oct 2004 (EDT)

 * . Mea culpa. The example I gave wasn't so appropriate for listings.  I was more concerned with what had to go into the low-level HTML.  What we need, it seems, is a way of specifying text for the link and for the title separately -- assuming we go with a terse link text like 'Web'.  See below for my next suggestion (See also) which may avoid this problem.

 * . How about a more concrete (and slightly hacked) example in your suggested format

 * Auberge du Pont de Collonges, 40 Quai de la Plage., Tel 04 72 42 90 90, Fax 04 72 27 85 87. Open 11am-3pm,7pm-1am every day. Paul Bocuse's restaurant, one of the most famous restaurants in France.  From €100.

 * Using text instead of the number would leave it as

 * Auberge du Pont de Collonges, 40 Quai de la Plage. Web, Tel 04 72 42 90 90, Fax 04 72 27 85 87. Open 11am-3pm,7pm-1am every day. Paul Bocuse's restaurant, one of the most famous restaurants in France.  From €100.

 * That looks nice but would it be better if we used images instead of 'Tel', 'Fax', 'open', etc.  There is an 'alt' attribute to HTML image tags for use by browser (alt attr defn), so the system can generate HTML that screen readers can interpret.

 * With text (or image) instead of the number and possibly images for Tel, Fax, etc personally I think the web version would look good.

 * Not so sure about the print version. If the URL is short it would look okay inlined but if it's long and complex it will look hideous. Even putting all URLs as footnotes in the printed version might produce half a dozen footnotes which would look awkward especially if they're short enough to look okay inline.  Could there be some option in the wiki markup to force it to a footnote?  I noticed that the markup for images has some options, eg [[Image:Paris_arrondissements_overview.png|thumb|350px|The Layout of Paris by district]] .  How difficult would it be?  An option to flag the URL as cumbersome would allow the writer some flexibility. (WT-en) Bobkemp 22:37, 11 Oct 2004 (EDT)

 * Actually, Unicode has a large set of Miscellaneous Symbols and Dingbats that could also be used with much less overhead. ☎ Tel, ✉ E-Mail, etc. The major problem with these is that there's no fallback if the user's browser doesn't support them, they'll just get a "?". (WT-en) Jpatokal 04:27, 12 Oct 2004 (EDT)

 * . Well, unless we wanted to get into browser-specific code perhaps the images aren't so practical then. I was just throwing up ideas to see what people thought. (WT-en) Bobkemp 22:38, 15 Oct 2004 (EDT)

 * . Part of the 'problem' is that a link on a web site is usually displayed differently to a phone number, ie you don't usually see the URL, just some explanatory text. In contrast, you can't usually click on a link to ring someone.  That's one reason why links on a website should probably be treated differently to a phone number.  However, what happens if there's also a Wikipedia entry?  That's another URL, in addition to the company's own one and there may be others.  Using 'Web' won't solve it either because there may be several non-wiki sites.  How about using text like See also BigCo web site, BigCo at the end of the entry for external links.  If the example looks unlikely, think of entries in the Michelin restaurant guide, etc.  The previous concrete example then becomes something like

 * Auberge du Pont de Collonges, 40 Quai de la Plage. Tel 04 72 42 90 90, Fax 04 72 27 85 87. Open 11am-3pm,7pm-1am every day. Paul Bocuse's restaurant, one of the most famous restaurants in France.  From €100.  See also the Auberge du Pont de Collonges web site or Michelin Guide entry.

 * Is that a runner? Or too repetitious?  To address Hypatia's concerns (above) about screen readers, we need to say somewhere (link text or title) whose web site it is.  Repeating that for a Michelin Guide entry would look bad but would it be needed?  (I have no experience of screen readers, so cannot comment).  Being able to distinguish between link text ('Michelin Guide entry') and the title for a screen reader ('Michelin guide entry for XYZ') might still be useful.

 * If the descriptive text (Paul Bocuse's restaurant, one of the most famous restaurants in France) was quite long this might not look so good because it would then separate the website links from the other contact info but if the description is that long perhaps it could go in a new paragraph and the 'See Also' part could tag on after the main contact details.

 * By the way, note how unreadable the Michelin Guide URL is. Would you want to see that in a printed listing?  Even in a footnote it would be useless. To produce a readable printed version, perhaps we need a way of reproducing the URL inline, as a footnote or omitting it depending on a wiki markup option. Omitting would be awkward.  What do people think about creating Wikivoyage page for the printed version describing key external sources -- like an appendix?  This appendix could list home pages of Michelin Guide, National Trust, National Tourism Offices,etc and, in the printed version, an unreadable URL would just display as the link text which would mention (as in the example) the Michelin Guide and leave it to them to remember the appendix.  It might be awkward however to keep everything in sync.  (WT-en) Bobkemp 10:25, 21 Oct 2004 (EDT)

 * Terribly verbose and in the wrong place. I also see no reason to link to Wikipedia entries for attractions, since they're unlikely to contain much practical information (opening times, admission fees, maps etc).

 * I still think the simple automated "Web" in the contact info section is by far the best proposal anybody has come up with. (WT-en) Jpatokal 11:28, 21 Oct 2004 (EDT)

 * I like that best too, but I do wish there was a way to make the HTML come out as Web rather than Web . That's all that is needed to solve the screen-reader issue: it's standard meta-data for anything that wants to grab the links on the page without scanning the content and getting meaning like a (sighted) human reader does. -- (WT-en) Hypatia 11:45, 21 Oct 2004 (EDT)

 * . Yes, it is verbose but that's partly because I was trying to make the link readable for a screen reader. If we had some other way of handling that, we could write See also their web site or Michelin entry which would be less excruciating.
 * It's also true that Wikipedia references for restaurants would not be much use but what about the 'See' section. The Eiffel Tower has history as well as opening times.  Am I being overly general here?  For restaurants, hotels, etc no contest but for historical features Wikipedia can provide more detailed historical data that we probably don't care to duplicate.
 * Despite that, if the vote is for the simpler version, that's fine by me. (bobkemp with new sig) (WT-en) Bob 16:04, 21 Oct 2004 (EDT)


text:
Wikivoyage talk:External links/Links in listings/Archive

How should links be shown:

 * to someone reading the printout I made when I clicked on "printable version" ? (should we even show links at all ?)
 * to someone browsing the web ?

Currently they look very different for "embedded external links".

Some people propose changing the software to make them look even more different. Others would prefer both to look as similar as possible.

Suggest style guideline for links
The current style guidelines indicate that external links to bullet-listed attractions (hotels, restaurants) should be placed as bare URLs (automatically turned to links by Wiki) at the very end of the list item. While this standard is not explicitly stated, it is used in all the examples : Project:Attraction_listings

I propose that external links instead be embedded in the attraction name.

That is,

 * Name of Attraction, Address ...

instead of

 * Name of Attraction, Address ... http://www.attraction.example.com/

An embedded link is the very essence of an HTML web page. It says "Click ME to see more about me. You don't have to go to a footnote at the bottom of the page, or type in a URL in a separate window. Just click ME and I will take you there."

A Wiki bare URL link, besides creating redundant HTML, breaks this fundamental property of hypertext. It needlessly displays an ugly string. Furthermore, placing it at the end, separate from the actual name of the attraction, is bad user interface design (if you can call a hypertext link an interface). It's almost as bad as (if not worse than?) the dreaded "click here for a cool on-line travel guide."

So, why are bare URLs used in attraction listings? I suspect the main reason is for printed articles. (I am a big advocate of supporting Wikivoyage in print form.) By including the bare URL, it's available to users who only have the printed article. But in fact, the Printable Version of a Wikivoyage article automatically expands embedded external URLs. So there's really no need to include bare links for print compatibility.

I think another reason for bare links is influence from printed travel guides. It's common for them to include them, and when I see an attraction listing with a URL, I instinctively think, "Hey, that's great, it includes the web site." But there is no need for it. Printed documents include bare URLs only because they are print documents.

Embedded links make for better-looking and more functional web pages, as well as fully usable printed documents. I think we should use them. --(WT-en) Paul Richter 11:51, 24 Jun 2004 (EDT)

 * So, here are my main reasons for wanting to keep URLs bare and separate.

 * First, I agree that keeping the print version clear is important. However, I also think that with a printed guide, having the URL right after the name is not that useful. In fact, the URL is of very low importance for a printed guide -- it's much less important than the address, phone number, or review. That's why it's at the end of the listing, not the beginning.

 * Second, I like emphasizing the print aspect of Wikivoyage guides. Getting people out of the idea of making a Web site and into the idea of making a travel guide is a good thing, IMHO. Concessions to the "webbiness" of Wikivoyage aren't, for me, a high priority. I'd rather our guides looked like print guides displayed on the Web than vice versa.

 * Thirdly, I think the listings just look better with a bold heading rather than a link. It's aesthetic, I know, but they seem more pleasing to the eye that way. (That may have something to do with my exasperation seeing a whole page of front-linked attraction listings: "Great! There's a half-hour off my life, reformatting those listings!" B-))

 * Lastly, and kind of selfishly, I think that separating URLs from labels discourages Wiki spam. Google Page Rank is closely linked (ha ha) with the text of the anchor tag. If we keep URLs separated from labels, we're not really a good leg-up for Wiki spammers. It's a gentle way of saying, "we want your information, but we're not here to boost your Google ranking."

 * Now, to controvert myself: it's a pain changing listings from front-linked to end-linked. I hate it. Maybe since people instinctually want to put links on the names, we should just do it. It might be time to just quit fighting this. --(WT-en) Evan 13:48, 24 Jun 2004 (EDT)

 * I have mixed feelings on this issue. When I started contributing, I at first preferred and used the 'bare and separate' approach, because it seemed to me that it clearly differentiated between internal links (which are invariably embedded) and external links. However as I continued, I somewhat changed my mind, for the following reasons:

 * The use of 'bare links' was in any case inconsistent. In more general text (as opposed to bulleted attraction/restaurant/hotel/etc entries) embedded links were already the norm.

 * Putting the 'bare link' at the end of the attraction/etc entry divorced it from the rest of the address information (street address, telephone, etc) which is where it naturally seems to belong, and which the mos says should come immediately after the name. In the printable view, the URL for an embedded link on the names is directly next to the other addressing info.

 * In some case I found I was putting secondary links as embedded links in the text of the attraction, with the primary link as a bare link at the end. These seemed perverse, and gave more prominence to the secondary info over the primary.

 * Some of the URLs I was putting in as bare links were very long and ugly, and embedding them hid that, at least in the non-printable view. For example:

 * http://www.english-heritage.org.uk/default.asp?wci=mainframe&URL1=default.asp%3FWCI%3DNode%26WCE%3D107

 * I now almost invariably use embedded external links. I don't think this is perfect answer, but on balance I feel more comfortable with it than the bare link approach. -- (WT-en) Chris j wood 14:46, 5 Jul 2004 (EDT)

 * I think having to put out the full URL for links is a good thing. If it looks bad on the Web, it's going to look bad on the printed page.

 * Having now spent some time looking at the output of the printable version, I agree. I think that if an organisation cannot be bothered to provide decent URLs for deep links, we should honour their (deliberate or unthought) desire not to have such links. To put the example above into context, I think that if I was now writing that attraction entry, instead of saying:

 * Wolvesey Castle, tel 854766. This palace was the chief residence of the Bishops of Winchester and its extensive ruins still reflect their importance and wealth. Open Apr-Sep 10am-5pm. Free.

 * I would instead say something like:

 * Wolvesey Castle, tel 854766. Now owned by English Heritage, this palace was the chief residence of the Bishops of Winchester and its extensive ruins still reflect their importance and wealth. Open Apr-Sep 10am-5pm. Free.

 * and let the reader wade through their website until they found Wolvesey Castle. But if anything, that amplifies the basic issue. If I'm only to use bare links appended to the attraction entry, how do I concisely express the fact that this is a bare link for the whole of English Heritage, and not a direct link for their Wolvesey Castle property. -- (WT-en) Chris j wood 20:01, 5 Jul 2004 (EDT)

 * Another thing I was thinking about was the issue of parallelism. Not every attraction has an accompanying URL (startling, I know). So if we decide to do this, we'd have listings that looked like this:

 * Attraction 1, Description text.

 * Attraction 2, Description text.

 * Attraction 3, Description text.

 * Attraction 4, Description text.

 * I don't think that looks good.

 * Lastly: would someone like to summarize the pros and cons of front-linked listings on this page? --(WT-en) Evan 19:06, 5 Jul 2004 (EDT)

 * Bit too tired to try that right now. I'll give it a go in the morning. -- (WT-en) Chris j wood 20:01, 5 Jul 2004 (EDT)

 * Ok, here goes (as the following section) -- (WT-en) Chris j wood 08:47, 6 Jul 2004 (EDT)

Definitions
A front-linked list entry is a bulleted list entry for an attraction, restaurant, bar, hotel or similar where the name of the attraction/etc (which the mos already says is the first element of the entry) is an embedded external link. An example would be:

 * Somewhere Interesting, Some Street, tel 999999. This is a really exciting place to visit. Open Su 1am-2am. $100.

A bare-linked list entry is a similar entry, where the url is instead appended to the entry, thus:

 * Somewhere Interesting, Some Street, tel 999999. This is a really exciting place to visit. Open Su 1am-2am. $100. http://www.the-somewhere-company.com/somewhere-really-interesting/

An un-linked entry is a similar entry, without an external link to the attraction/etc, thus:

 * Somewhere Interesting, Some Street, tel 999999. This is a really exciting place to visit. Open Su 1am-2am. $100.

In any given list there are always likely to be un-linked entries, because the attraction/etc doesn't have a web site or we don't know its url. The question is whether, where we do know a url, we should use the front-linked format or the bare-linked format. The mos mandates the bare-linked format, but front-linked entries happen quite a bit.

Complicating this question is the fact that any of the above three formats may contain secondary links within the description to urls that are related to, but not directly about, the attraction/etc. By more or less universal practice these are always written as embedded links. For the purposes of this discussion, I call these secondary-linked. Examples would be:

 * Somewhere Interesting, Some Street, tel 999999. This place, run by the Somewhere Company, is a really exciting place to visit. Open Su 1am-2am. $100.

 * Somewhere Interesting, Some Street, tel 999999. This place, run by the Somewhere Company, is a really exciting place to visit. Open Su 1am-2am. $100. http://www.the-somewhere-company.com/somewhere-really-interesting/

 * Somewhere Interesting, Some Street, tel 999999. This place, run by the Somewhere Company, is a really exciting place to visit. Open Su 1am-2am. $100.

Pros Of Front-linked Listings

 * Front-linked listings are more concise in the normal view, and not significantly less concise in the printable view.

 * Use of front-linked listings means that we consistently render external links in the same way, as use of embedded links is almost universal in other parts of the wikivoyage content (ie. both secondary links in list entries as defined above, and links outside lists such as in 'understand' sections.

 * In the printable view, use of front-linked listings means that all 'address' type information for an attraction/etc is adjacent. (With bare-linked listing the street address and phone comes at the beginning of the entry; the url at the end).

 * Use of front-linked listings correctly expresses the order of precedence between the primary link (first) and any secondary links (following); bare-linked listings reverse this order.

 * Use of front-linked listings is good web practice. As Paul Richter says above An embedded link is the very essence of an HTML web page. It says "Click ME to see more about me. You don't have to go to a footnote at the bottom of the page, or type in a URL in a separate window. Just click ME and I will take you there.".

 * Contributors seem to intuitively want to do front-linked listings. So, having this be our style guideline for listings means a lot less work switching around the links.

Pros of Bare-linked Listings

 * Bare-linked listings result in closer similarity between the normal and printable views, which makes editing for both formats easier and more reliable. (BUT it only does this for list entries; we probably need to address all the other places embedded external links are used).

 * An mixture of bare-linked and un-linked entries in a single list is more aesthetically pleasing than a mixture of front-linked and un-linked entries, because the names of all entries are identically decorated.

 * Bare-linked listings help to strongly differentiate between external links and internal links, which are always embedded. (BUT this only works for list entries; we probably need to address all the other places embedded external links are used).

 * Bare-linked listings do less for the targets google ranking, and hence using them will discourage people spamming wikivoyage in order to benefit their ranking. (BUT this only works for list entries; we probably need to address all the other places embedded external links are used).

 * This is the current Wikivoyage Manual of style style.

Opinion
I have tried to be as impartial as I can in the above. So here are my opinions having had to think about this.

I firstly don't rate the anti-google-ranking-spam argument for bare-linked listings at all. If a link is genuinely useful to our readers, then I rejoice in the fact that we are helping that site's google ranking. If it isn't, then the link shouldn't be there in the first place and we don't appear to be short of editors prepared to police this.

I think all the other arguments are good ones, but at the end of the day I personally feel that the pro-front-linking ones outweigh the pro-bare-linking ones. -- (WT-en) Chris j wood 08:47, 6 Jul 2004 (EDT)

 * That sounds great. Thanks a lot for doing this. I'd like to get some more attention on this page. One thing I changed: bare-linked URLs are mandated by the MoS at this point: see Project:restaurant listings, Project:attraction listings, Project:accommodation listings, Project:bar listings. --(WT-en) Evan 10:46, 6 Jul 2004 (EDT)

 * OK! -- (WT-en) Paul Richter 04:49, 7 Jul 2004 (EDT)

I don't like the new "front linked URLs". I'm afraid that for me the arguments in favor of keeping it the way it is now outweigh the arguments in favor of making the change. Besides I don't think it's worth the hassle. -- (WT-en) Mark 17:16, 8 Jul 2004 (EDT)

I prefer the current Bare Linked form. Google rank-spamming is a serious issue that we already face. Front linking will make it worse. Also, I think it looks terrible to have a mix of both linked and unlinked stuff in the list (for those items which have no extlink) -- though perhaps this could be mitigated with a change to the style. -- (WT-en) Colin 18:12, 8 Jul 2004 (EDT)

 * Surely anyone inserting a link into Wikivoyage purely for the purpose of google-rank-spamming is going to go ahead and insert an embedded link anyway. I don't think spammers take much notice of manuals of style, so I don't see how changing the mos is going to make any difference to the amount of spam we see. -- (WT-en) Chris j wood 16:06, 9 Jul 2004 (EDT)

 * If the MoS requires barelinks and someone inserts an embedded link, it's a clue you're dealing with either an inexperienced user or a link spammer. In either case, that's a clue that the link should be investigated to make sure it is appropriate.   I, for one, don't want to follow every link added by a user I don't recognized to check appropriateness.  It's a small point perhaps, but for me it's worth mentioning.  For others, no doubt it's not so influential. -- (WT-en) Colin 18:21, 9 Jul 2004 (EDT)

My preference is for the Front-linked and hidden URLs - the arguments summarised above for them are fairly compelling on the whole. Yes, it may involve some work.... but who's frightened of a bit of gradual change divided between all active contributors? Another reason for including front-linked hidden URLs is that many URLs are extraordinarily long and complex, detracting from the sense of the written word..... (WT-en) Pjamescowie 12:37, 9 Jul 2004 (EDT)

Another thought, contra a supposed advantage of bare-linked URLs: "Bare-linked listings help to strongly differentiate between external links and internal links, which are always embedded". Couldn't the Wikivoyage stylesheet be easily amended to distinguish between internal and external links, should the option to use hidden front-linked URL's be adopted? A colour distinction (blue = external, green = internal, for example) would, I think, prove too "busy" visually. Internal links, however, could be given an additional "hover" background attribute, so that when a user's pointer is over the link, the link "glows" a light blue colour behind it. The links on my website provide a good example of this in action: http://www.ancientneareast.net/ External links would simply display as blue lettering and underlining. (This is just one suggestion, of course - others may have other ways of signifying the distinction....) (WT-en) Pjamescowie 12:47, 9 Jul 2004 (EDT)

My thoughts on this are that the current bare linked is best approach. I think having hidden URL linking is a good idea for deep linking onto a specific relevant page, but that it shouldn't be done in the title. I think that having the title look different depending on whether it has a website or not is not a good idea. I think some of the other problems can be addressed other ways. For example to deal with long url's to the attraction page I would suggest something like the following:

 * Vancouver to Nanaimo Ferry BC Ferries runs a ferry from Horseshoe Bay near Vancouver to Departure Bay near Nanaimo. This ferry runs every 2 hours.  Cost is $10 per person and $35 for a car.  more information at http://www.bcferries.com.

In my opinion this looks a lot better than hidden url's in the title.

 * I disagree completely -- this is verbose, redundant, and butt-ugly to boot. The point of a link is to link somewhere relevant, not tell you the name of the server, and isn't it already obvious that you'll get "more information" if you click on it? (WT-en) Jpatokal 00:51, 23 Jul 2004 (EDT)

I also think that with the way that the printed form of wiki works having expanded (and sometimes very ugly) URL's right after the attraction name is a very undesirable appearance. I actually would like to be able to turn off the printing goes expanded version. In my example above I would turn off expansion for the more information link as nobody would type in the long version, but would navigate from the companies front page. -- (WT-en) Webgeer 00:19, Jul 23, 2004 (EDT)

 * In this case the printed version should be changed to append the link to the end of the paragraph, which is just a matter of some Perl magic. (WT-en) Jpatokal 00:51, 23 Jul 2004 (EDT)

 * Or maybe even in the HTML-generating code with a user preference: external links in lists embedded or at the end of the paragraph.

 * Of course this is a slippery slope to the kind of software which is too flexible/wishy-washy to set any user interface policies and ends up letting the user configure everything. But the more I think about it, the better it sounds... -- (WT-en) Paul Richter 21:54, 5 Aug 2004 (EDT)

Change management
So, one last point about front-linked URLs: it's a change from the existing style. We'd have to go through all 2000 articles (!) and make sure they have the new front-linked style. Admittedly, a lot of them do already, but it is going to be a not-insignificant amount of work. Tedious, mind-numbing work. Then again, it's easier to do now than when we have 10,000 or 100,000.

One possibility is writing a script to do it, but that'd be kinda tricky.

This should probably factor into a decision. Is having front-linked listings worth the effort? --(WT-en) Evan 15:35, 8 Jul 2004 (EDT)

 * It could also be a gradual process of converting to the new style. Yeah, it'd be a bit sucky at first though.  -- (WT-en) Colin 15:50, 8 Jul 2004 (EDT)

 * Yeah, I'd guess it'd take a couple of months. --(WT-en) Evan 16:00, 8 Jul 2004 (EDT)

Where Are We With This?
Just noticed that (WT-en) Hypatia has gone through the Sydney/Darling Harbour article and changed See/Sleep/Eat/Drink list entries from embedded links to raw links. Which is fine if that is the way the consensus has gone; something I would be hard put to call either way from this discussion.

But, the same article still has embedded links in 'Get In' and 'External Links' sections. If we are going to go for raw links for all external links; fine. But allowing them in some sections but not in others seems positively perverse.

Opinions -- (WT-en) Chris j wood 20:51, 5 Aug 2004 (EDT)

 * First, the end links is still the manual of style guideline (per the listings format pages). So it makes sense to change articles to fit the guidelines right now.

 * Second, the way that links work in regular paragraph text is different from how it works in listings. I think it's consistent. Listings are more structured than regular text. --(WT-en) Evan 00:29, 6 Aug 2004 (EDT)

 * I actually did that before I was aware of this discussion, and if I had been I might have left it. However, when I started Sydney/Darling Harbour I used end links, and one of the later authors changed all the listings to front links. A conclusion to this discussion would be nice, since this "formatting war" where links are changed to front links and are changed back to end links is unproductive. (WT-en) Hypatia 05:48, 6 Aug 2004 (EDT)

My thoughts on this... perhaps the code can be changed so that external links display a small icon to the right of the text so that it is clearly external. Like this:

 * Somewhere Interesting [[Image:External link 1.png]] 123 Fake St. (Springfield), 456-7890. This is a really exciting place to visit. Open Su 1am-2am. $100.

Then on mouseover the link can be highlighted or whatever. This is similar to what Wikipedia does. This could be a good compromise... thoughts? -(WT-en) Nickpest 16:25, 7 Aug 2004 (EDT)

 * This has been an interesting discussion to read through. As someone who recently started contributing, and have only read parts of the MoS, I have been instinctively using front-end links.  I had a few thoughts on the discussion up to now.
 * I don't much care to see entire links, long or short, as a I think they're ugly.
 * Having used the London guide to some extent on my recent trip, I also don't see much use for URLs in the printed version, as if I'm in a position to visit a website, I'll have access to the hyperlinked article, and if I'm visiting more than one, it's easier to load it up on wikivoyage and then follow the links instead of typing each one in off a printed page.
 * As a new contributor, I'd have to say reading the entire MoS before starting (especially since it's easy to get distracted by side pages), is unlikely. I mostly started by grabbing page templates and working off what I saw on other pages.  Thus, as long as there's a fairly common inconsistency, I'm more likely to use what comes naturally.  (Which would be front-end links).
 * Nickpest's last suggestion seems the best to me, as it preserves the front-end simplicity, but doesn't provide the inconsistent formatting (which I don't much mind anyway). -(WT-en) Neil C 18:36, 7 Aug 2004 (EDT)

 * So, these are great comments. Here are my main responses: first, although I don't like the way front-linked listings look, I find the idea that people "instinctually" make front-linked listings is a convincing argument. I'm really sick of having to change them -- it's really tedious.

 * I also don't expect people to read the MoS entirely. MoS style is a goal to aim for rather than a set of rules you have to learn before making a single contribution. If you add something that's not MoS, that's great -- we want all the info we can get -- but it's likely that someone else will bring it more in compliance.

 * We use the MoS to resolve conflicts on more or less arbitrary problems (formatting, layout, naming, etc.) and provide consistency. We don't have to argue on each and every guide what the layout, formatting, and content is supposed to look like -- we just defer to the MoS. Most of the stuff in there is pretty arbitrary and more about form than content.

 * Anyways, that's my main feedback. My final feeling: I'd like to change to front-linked listings, even though I dislike it aesthetically, if we can overcome objections. --(WT-en) Evan 14:31, 8 Aug 2004 (EDT)

 * I, too, dislike the front-linked listings for aesthetic reasons, but I think my suggestion somewhat overcomes that if it can be implemented. I, for one, never had a problem with having a bare link at the end of a listing; in fact I like it because it gives a "printed travel guide" feel.. but I totally understand people's objections to it. -(WT-en) Nickpest 15:00, 8 Aug 2004 (EDT)

 * I like Nickpest's suggestion for external links using the Wikipedia type graphic. I think this would be a nice solution that maintains the distinctiveness of Wikivoyage articles vs. external links and keeps nice consistent formatting. (These are my two objections to the inline formatting).  -- (WT-en) Webgeer 13:01, Aug 9, 2004 (EDT)

So is this settled now? -- (WT-en) Beland 02:38, 16 Aug 2004 (EDT)

 * I'll cast another vote in favor. Now the only thing missing is the implementation...! (WT-en) Jpatokal 04:48, 16 Aug 2004 (EDT)

 * I think there are a few hold-outs. Personally, I hate making these kind of tedious changes on really minor, arbitrary formatting issues, and I just don't think it's worth the effort. But, yes, the Mediawiki 1.3 external link format makes for a much nicer presentation -- good job, Nickpest! --(WT-en) Evan 16:08, 16 Aug 2004 (EDT)

I'll change my opinion to neutral on this issue... (thus removing me from the dissenting opinions) -- (WT-en) Colin 15:54, 16 Aug 2004 (EDT)

Vote Opinion Summary So Far
I decided to do a vote summary so I could make heads or tails of the discussion. The opinions expressed were rather complicated, though, and I'm not sure I did it right. Please check below to see if you are accurately classified, or if you want to change your vote. -- (WT-en) Beland 18:27, 18 Aug 2004 (EDT)

 * Hidden
 * Paul Richter, Chris j wood, Pjamescowie, Beland, Elgaard
 * Hidden, with icons for external links
 * Nickpest, Neil C, Webgeer, Jpatokal
 * Hidden if objections can be overcome
 * Evan
 * Bare, before proposal to have icons for external links
 * Mark
 * Explicitly neutral
 * Colin
 * Unknown
 * Hypatia

 * I thought we weren't going to vote on things on Wikivoyage.

 * That said, although I still like the listings with the link at the end the old way I would be perfectly happy with the Mediawiki 1.3 icon format. -- (WT-en) Mark 01:58, 19 Aug 2004 (EDT)

 * Yes, we don't normally vote on things on Wikivoyage. Perhaps "Opinion summary" would be a better term here, so I've subbed it in for the title. Otherwise, it looks like we're moving towards consensus here.

 * I'll put some information about the 1.3 upgrade somewhere soon. It's going to be something of a pain, but I'd like to do it before we start any new language versions. --(WT-en) Evan 17:06, 19 Aug 2004 (EDT)

 * So it seems we now have consensus for hidden links, pending the 1.3 upgrade. Should this be written into the official policy now?  Should we start writing things in the new style in the meantime? -- (WT-en) Beland 21:44, 23 Aug 2004 (EDT)

 * Yes, I'll go ahead and change all the listing formats. There's tons of work to do in changing old articles. I really hope the people who've made a big deal about this are prepared to help out with the execution of the plan. --(WT-en) Evan 15:37, 24 Aug 2004 (EDT)

 * So, I changed all the listing formats, and y'know what? I think the printable version with front-linked listings looks really awful. (See here for an example). I feel pretty foolish not to have actually checked that before. Am I alone on this? I'm still reluctantly in support of this, but I'm really holding my nose on this one. --(WT-en) Evan 16:01, 24 Aug 2004 (EDT)

 * I agree, but there's not much that can be done besides reverting back to the bare listing format or hacking the Wiki code to automagically detect a linked listing and move its URL to the end of the paragraph .. doable, but not necessarily a trivial task. -(WT-en) nick 18:44, 24 Aug 2004 (EDT)

 * A real page like Østerbro is even worse. But I think the front-link way should be easyer to hack. Can we get get rid of the magnifying glass in printable versions. And get the pictures bigger than thumbnails since they can not be enlarged. The links still get underlined when I print with firefox. Konqueror does it right. -- (WT-en) elgaard 21:13, 2004 Aug 24 (EDT)

 * I guess I wasn't clear about my opinion. I really hate linking out the header of these listings without the little icon thing.  With the icon thing I find it sort of tolerable.  Can we ditch the front-linked stuff and just go back to the old way?  -- (WT-en) Mark 03:55, 26 Aug 2004 (EDT)

 * If you're going to hack code to de-uglify the print version so that front-links look nicer (such as moving the URLs to the end), then remember that in-line embedded links will be affected as well. So a non-bulleted paragraph with three embedded links will have three URLs scrunched at the end, and no visual connection between them and the links in the paragraph... yuck.

 * Frankly, the print version is ugly in its entirety, and that can't be helped. But front-links make the on-line version cleaner and more usable, IMO. -- (WT-en) Paul Richter 04:52, 26 Aug 2004 (EDT)

 * It should be possible to match bulletet links so only those are moved to the end. But the more I look at both ways the more I would like an option to just not have URL's in the printed version. I would never type an URL into a browser anyway, I would just go to wikivoyage.org, search for the right page and have all the clickable links on one page. -- (WT-en) elgaard 06:31, 2004 Aug 26 (EDT)

 * I can't handle it looking this way. Writing off the printed version is not an option for Wikivoyage (see our goals for why). Nobody seems to like the printed version with an URL in the middle, and the only ideas for how to make it better is to hack the Mediawiki code to put the link... at the end! Where we have it on most listings already!

 * I have read the Goals and non-goals and I do not see why there have to be URL's on paper.
 * Wouldn't it be possible to run printed version trough something like:

perl -pe 's#^\*\s*\[(http://\S*)\s(.+)$#\*\[\2 \(\1\)#g;' -- (WT-en) elgaard 19:48, 2004 Aug 26 (EDT)
 * I'm reverting the changes to the listings formats. I just don't think this is tenable. --(WT-en) Evan 13:34, 26 Aug 2004 (EDT)

 * Right on! -- (WT-en) Mark 13:50, 26 Aug 2004 (EDT)

 * Loud objection! I see no consensus at all for this, just you & Mark.  End links look horrible online, and the problems with the printed version are fixable with Perl hacking. As Elgaard says, why don't we just drop URLs entirely from printed listings? (WT-en) Jpatokal 21:53, 26 Aug 2004 (EDT)

 * Sorry Jpatokal, but I don't think we really had a consensus for changing it in the first place. That said I think that we can get there, like I said I won't resist the links with the icon.

 * I will on the other hand resist the idea of not having URLs at all in the print verion. Basically that's us putting a limit on what we can publish which our competition, like say Lonely Planet do not have.  They can publish URLs in their print version, so why shouldn't we ?  Imagine this scenerio:  You're in a new city and you you have a print version of the guide.  You have found an internet cafe, and you want to look up the site of one of our listings.  Why should our policy make you have to come to the Wikivoyage site first?  Heck, the Wikivoyage site might be down.  -- (WT-en) Mark 07:42, 27 Aug 2004 (EDT)

 * After all this debate and a decision, the guideline is going to be reverted simply based on how it looks in the printed version? I think that's kind of weak. Yes, you should have checked that before. Please see my comments (Content vs. Presentation, More on Printing) below. -- (WT-en) Paul Richter 05:17, 27 Aug 2004 (EDT)

 * Yep, I shoulda checked it. After bringing it up, there was pretty much unanimous agreement that it was really, really ugly in the printable version. The work really hadn't started to get things changed over to the front-linked format, so I figured it was safe to change back to the end-linked version. --(WT-en) Evan 14:18, 27 Aug 2004 (EDT)

Summary: Related Developments
These places may need to be updated once this question is resolved: Project:restaurant listings, Project:attraction listings, Project:accommodation listings, Project:bar listings.

There has been a proposal to improve handing of URLs in printed versions (by moving them to the end of the paragraph or page).

Seeking Consensus
So, Mark, does the proposal for denoting external links with icons change your mind? What about the claim that people usually intuitively make hidden front-links? It need not be a hassle to change styles for anyone who doesn't want to help. If we prefer a quick rather than gradual transition, someone (maybe me) could write a script to find all bare links on wikivoyage, and for listings, suggest a fix. (I'd prefer a human look over the suggestions before implementing them, but that's still orders of magnitude faster than fixing everything manually.) -- (WT-en) Beland 18:27, 18 Aug 2004 (EDT)

Content vs. presentation, and the end-linking hack
Placement of the URL with or apart from the text is a presentation issue. If it's so important that URLs in print don't look ugly, maybe there ought to be code to pull out an embedded URL and stick it on the end (on-line and print), and a user preference to do that. As a structure issue, though, it is eminently better to keep them together. Having them separate just doesn't make sense. Yet in separating them end-linking sacrifices structure for presentation, and as far as I can see, that's all it does.

As elgard writes in a previous thread, the front-link format should be easier to hack, i.e., the user option would be to a) pull apart embedded links or b) do nothing. So if a front-link/end-link user option were implemented, it will be up to front-linkers to do the work changing the pages. Viewers with the end-link option on should notice no difference.

I took a look at Wikipedia to see what their guidelines are. It turns out end-linking isn't addressed because it's never done anyway. Bare URLs are used only for single-line External links, and even then it's preferred to make them embedded instead of bare. And the idea of having a keyword with a link separate from it is, rightly, not even considered. -- (WT-en) Paul Richter 04:56, 27 Aug 2004 (EDT)

 * Hi Paul, I don't think I agree that non-embedded URLs in listings are so bad from a structural point-of-view. After all the phone numbers aren't embedded, nor the descriptions, so why should the URLs be?  Just 'cause you can do that in HTML (and hence Wiki markup)?

 * This would be structural markup:

Cool attraction

or maybe:

|Cool Attraction|+5 55 555 5555|this is a great place to go|attraction

or better yet (the least markup, thus the most Wiki):

*Cool Attraction, +5 55 555 5555. This is a great place to go! http://www.attraction.com

 * Our consistent listing format is a stuctural markup if it is applied consitently, but one which can handle a lot more information that just a URL. I think we're just used to thinking of the URL as part of a tag, but that is HTML thinking, not Wiki thinking.

 * The templates are perfectly capable of recognizing a URL, or a phone number for that matter, so why not let them do the work? -- (WT-en) Mark 07:42, 27 Aug 2004 (EDT)

 * Meanwhile I do use embedded URLs all the time, just not in the listings. -- (WT-en) Mark 07:50, 27 Aug 2004 (EDT)

 * Phone numbers are not embedded because usually you cannot dial a number by clicking it (although I could make my softphone do just that). And URL's are often long and ugly, whereas phone numbers are short strings of mainly digits.
 * Email-adresses can often be clicked in browsers, but now always and not on SMS->gateways, some terminals in cafes and airports etc, so it makes sense to have email adresses bare. Actually i would like them as mailto: links as well. -- (WT-en) elgaard 2004 Aug 27 (EDT)

 * It's important to realize that Wikipedia has different norms, in that they downplay the importance of printed versions ("Wiki is not paper"). So comparing Wikivoyage guidelines to Wikipedia ones isn't always a fair comparison. --(WT-en) Evan 14:54, 27 Aug 2004 (EDT)

More on Printable Versions
There's no need to configure Wikivoyage to move the URLs to any particular location; embedded links should appear as normal (no need for any "external link" icon, though; that just clutters things up). When someone actually goes to print the Printable Version, their web browser will handle links in an appropriate fashion. I believe that most web browsers will show URLs as numbered footnotes. At least in text-only browsers like lynx, you can disable the printing of these footnotes.

Not outputting the usual "a href=" style of URL risks disassociating the URL from the text to which it refers, especially for links embedded inside paragraphs (as opposed to links in listings, where it's a little more clear...unless there are multiple links in the same listing, which is quite possible if special directions or feature are noted). -- (WT-en) Beland 18:27, 18 Aug 2004 (EDT)

Regarding the role of a printed Wikivoyage, I think it's important to differentiate between a) making a printout of the on-line Wikivoyage, and b) publishing a printed travel guide based on Wikivoyage content. (In the Project:Goals and non-goals article, a) is "individual article printouts" and b) is "ad-hoc travel guides" and "inclusion in other travel books".)

The first, I think, is not very important, certainly its appearance. Web pages are designed to be viewed with a browser, not printed, and as long as the Print Version is still HTML rather than PDF, it will always be ugly, clumsy, and inadequate.

The second role is the one that we need to keep from being too web-centric -- e.g., being a link directory, reliance on multimedia. The important thing is to have the same content available in print and on-line, not that it be presented or formatted for print. Anyone who decides to publish a printed travel guide based on Wikivoyage has the freedom to move/replace/include links (and anything else) in any manner they want, so let's just supply the content in the most usefully structured form and let the print publisher present it in the best way for print media. -- (WT-en) Paul Richter 05:10, 27 Aug 2004 (EDT)

 * I agree. There are all kinds of ways www and especially now-web versions will be produced from the Wiki markup that is typed in. For example I would probably not use the printable version. I would use User:(WT-en) Mark/Wix to download a country and generate latex with parsewiki (once wix becomes recursive).
 * Therefore it is important that we have wiki-text that makes it easy to generate different versions, even versions we are not considering now. Separating URL's from text makes it harder.
 * I am not too worried that the printable version looks ugly as long as it can be made pretty without editing the content of WikiTravel. I would make it pretty by just removing URL's, but I do not argue that others should have to do that.

-- (WT-en) elgaard 10:16, 2004 Aug 27 (EDT)

 * One-off printouts from the browser are always going to be important for Wikivoyage. I realize they're not important to everyone, but they are part of our essential goals. I think that our printable versions actually look pretty good. --(WT-en) Evan 14:28, 27 Aug 2004 (EDT)

 * It's important for me too. I would use it for shorter trips, for a longer holidays I think wix would be easier.

The printout does look very good, depends a bit on the browser but html2ps is perfect for this. I still think magnifying glasses is pointless on paper. I just think it should be possible to make every version look good, we do not have to make one version look less good to make another verison look better -- (WT-en) elgaard 21:16, 2004 Aug 27 (EDT)

Proposal: No external links allowed
Crazy, crazy idea: What if all wikivoyage articles were "no external links allowed" ? After all, you can't click on them after they're printed out.

Then "the style of external links" becomes irrelevant.

(I'm not talking about *deleting* links. Some of them are very helpful. I'm talking about *moving* them to a more appropriate place: the "Talk:" page, or the Wikipedia sister page.)

We might apply this ban only to articles discussing actual physical locations; the Travel_topics section would be exempt. http://en.wikivoyage.org/wiki/article/Wikivoyage_talk:External_links/What_to_link_to#Proposal:_No_external_links_allowed

 * Yeah, let's ban phone numbers and physical addresses while we're at it. For that matter let's not allow anybody to talk about any place of business.  It's not like we have very many hotel listings now anyhow, so we won't have to delete much.

 * This should make it much easier to finish any given destination page. We could just have a script do it. -- (WT-en) Mark 17:06, 28 Aug 2004 (EDT)

Front vs back-linked listings, part XVII
I remain entirely unsatisfied with the current state of affairs. Here's how I see it. In the Web listing, which is the way most people see Wikivoyage...
 * Front-linked listings are clean, short, obvious and easy to use
 * Back-linked listings add in verbose computery gobbledegook which adds no value to the user compared with the front-linked listing http://64.233.167.104/search?q=cache:yYHKVIiLrvIJ:wikivoyage.org/+wikivoyage&hl=en

In the printed listing...
 * you have verbose computery gobbledegook spewed onto the page no matter which way you choose.

So the front-linked listings are obviously better. Mark and Evan, can you convince me otherwise? And please note that the Project:External links page currently doesn't say which is better, so I shall religiously revert any changes to the status quo until this is sorted out once and for all. (WT-en) Jpatokal 09:59, 1 Sep 2004 (EDT)

 * It's in the Project:Manual of style, which at the moment says to use bare urls. As far as I can tell a link is no more gobbledegook than a telephone number is.  They go at the end because they can get kindof long, but a really long URL probably indicates that the page it points to doesn't really belong to the entity being listed, meaning that it probably shouldn't be there at all.  Project:External links is about what to link to, not how to do the links from listings.

 * So it sort of bothers me that we have a DOM which does not follow the MOS. Maybe we should pick a different one until we get this worked out?  Or maybe we should just make it match the MOS until we get this worked out?  Either way. -- (WT-en) Mark 23:26, 1 Sep 2004 (EDT)

 * In my opinion there are 3 problems with front linked listings type of listing.

 * Offsite vs. Onsite. Wikivoyage generally uses the front-link listing apearance for more wikivoyage pages. (Cities, Areas, are always done like this, attractions which have a whole page about them have also been done like this) Therefore, when one navigates around wikivoyage, one would expect the link to go to a wikivoyage page about the attraction.  Instead we are sending people off-site.
 * Inconsistent appearance. Making attractions with websites linked appear in a different colour/formatting from attractions without website links to me looks very hodge-podge.
 * Printing. To me this is the least of the concerns.  But having the gobbldegook appear at the end of the listing is better than right after the title where it looks out of place.

 * As mentioned before, my preferred solution is to use an icon. With the below option either replacing the [1] with an icon or even just leaving it.  If #3 above can be sorted out with programming I like the look of the first option shown below.  Otherwise I think the second option is the best way to go

 * Attraction 123 any road, 555-555-5555, [[Image:External link 1.png]] . Best to keep the link right with the other contact information, but have it display very different from on-site links. Does not change the overall appearance of the list, puts it with the contact information where one would expect information directing you to the site.  The use of an icon in the online version (with the url in the print version) is the best solution.  However, if it is too much to hack wiki I think the simple numbering system  is ok too.
 * Attraction 2 Alternatively, if we can't address the printing issue and we don't want to have the webpage in the middle of the listing. Put the link and the end, but have it either be a numbered link or use an icon.

 * We will have to wait until Evan gets back to discuss how doable this is, but personally I think this is the best option.  -- (WT-en) Webgeer 12:22, Sep 1, 2004 (EDT)

 * Yes, I think you've pretty much nailed the reasons why front linked listings are bad. I like the icon solution too, and the numbers look reasonably good too, but maybe there's another possibility:

 * Attraction 2, 55 Avenue A. +5 555 5555. [Website] Alternatively, if we can't address the printing issue and we don't want to have the webpage in the middle of the listing. Put the link and the end, but have it either be a numbered link or use an icon.

 * -- (WT-en) Mark 23:39, 1 Sep 2004 (EDT)

The way WikiPedia does it is: An externel link in wikicode looks like: * Attraction foo bar The HTML looks like: Attraction (http://www.example.com/) foo bar If we don't like the underlining we can use a different stylesheet. If we also do it this way, we can use frontlinking and discuss style-sheets and transformations for print versions. -- (WT-en) elgaard 17:48, 2004 Sep 1 (EDT)

If we're going to go this route, let's make external links open up in a separate window so you're still on the Wikivoyage site. Or maybe have that as a user preference. -(WT-en) nick 03:24, 6 Sep 2004 (EDT)

 * This discussion page is getting quite confusing, so I'm not sure whether I'm putting this in the right plave, but here goes nothing....

 * Where are we in terms of achieving consensus re the style of external listings? Yesterday I made some link additions to the Paris/1st_arrondissement and these were speedily converted into number links by Mark. Mark also informed me on my talk page that this basically reflected the new consensus for external links..... Now, I can find no real evidence of any such consensus emerging in discussion on this page.... I can find some minor discussion re the suggestion of a number or icon display of ex links, but no evidence of anyone other than Mark and maybe one or two others jumping on this particular bandwagon. (Just for the record, if we do go down this road, let me state that I prefer an arrow icon à la Wikipedia for external links - the numbers just look confusing and get lost in the text.....).

 * I had thought that hidden, front-linked listings were achieving more of a consensus, both in discussion (see above) and in practical application..... Any thoughts on this? Where do we stand? (WT-en) Pjamescowie 06:46, 13 Sep 2004 (EDT)

 * My comments above are not designed, by the way, to take away from the sterling work that Mark has been doing on the Paris pages..... (WT-en) Pjamescowie 06:49, 13 Sep 2004 (EDT)

 * Thanks, Pjames. The reason that I think we'll wind up with the numbers links (which will turn into arrows when we upgrade the software) is that some people here object very strongly to bare URLs at the end of listings, while others of us (Evan and myself for instance) object very strongly to front-linked listings on astetic and typesetting grounds.  As well as others.

 * The idea of putting the link in at with the rest of the contact information seems to have illicited no objections, and has the additional advantage of being very logical, since it neither relegates the link to the back, nor gives it preference over the other contact details up front.

 * Since we're talking about a consensus, in which we all more or less agree then the idea with no objections would seem to me to carry the day. The ideas with strong objections (like front-linked listings) are not likely at all to achieve a consensus. -- (WT-en) Mark 07:29, 13 Sep 2004 (EDT)

 * Thanks for that Mark - I hadn't worked out from the discussion that the numbers will convert to arrows once the software is upgraded.... So it will look like Wikipedia? Great! I'm with you on this one then.... It appears to be an effective, visually-appealing compromise, avoiding objections from both sides.... I'll use this approach from now on and endeavour to revise previous contributions. Any idea yet as to when the software will be upgraded? (WT-en) Pjamescowie 07:37, 13 Sep 2004 (EDT)

 * I have to admit that I'm assuming that that's what will happen. If not I'll write a script which will make it happen.

 * As for when the upgrade will happen, that'll be Evan's move. -- (WT-en) Mark 07:41, 13 Sep 2004 (EDT)

 * Could we at least put the number/arrow right after what is itemized, not after phone numbers, emails etc. Otherwise it will be harder later figuring out where the link belongs. Also it takes longer to eg go through a list of hotels and find the ones with web-pages.

I don't have a big problem with the visual expression of the web or printed version. But I still think it is ugly and unnecessary to write it directly in the wikitext. -- (WT-en) elgaard 09:38, 2004 Sep 14 (EDT)
 * Why is the number on the printed version (in addition to the bare URL)?

 * I'm not really sure I understand what you are saying in the last sentence there. Can you clarify? -- (WT-en) Mark 11:05, 14 Sep 2004 (EDT)

 * Look at a front linked page: Østerbro, then look at http://www.agol.dk/elgaard/Osterbro.html. Apart from pictures missing and a font-problem, I only changed two lines of CSS. Now if you add an arrow whereever you want I am happy.
 * I want the the wiki-code (the text you see in edit mode) to be tidy and keep as much information as possible because this is the source of web-pages, printouts, and all other formats. Making the transformations from wiki to web, print, etc should not be too difficult. And even if we do not get it right the first time, we can always improve the transformations without editing every single wikivoyage page. -- (WT-en) elgaard 18:05, 2004 Sep 14 (EDT)

Order of contact info
You might notice that the contact info is in order of importance to the traveler on the ground.

 * Name, address, other location info. phone, fax, email. [URL]. description

One of the problems I have with the front-linked listings is that they put the URL before any other information in the wikitext. To my eye that looks absolutely hideous. It makes more sense to me to put it in with the contact info, especially if we are going to be hiding it in brackets (under a number or later a nice little graphic). -- (WT-en) Mark 11:11, 14 Sep 2004 (EDT)

 * It only make some sense if you insist that the printed versions and www versions should look the same.
 * When reading wikivoyage online an URL is a lot more important than say the fax number.
 * This is also true for the traveler on the ground. When I travel I could use my cheap GSM-phone to browse wikivoyage and external
 * links, although it would be expensive. I usually also have access to the net from the hotel, public terminals or internet cafes.
 * But I have never used a fax machine while traveling. -- (WT-en) elgaard 18:18, 2004 Sep 14 (EDT)

 * I respectfully dissagree. I think that for most travellers a URL is not terribly useful at all.  Perhaps Denmark is more advanced (I think it probably is) but in most of Europe hotel reservations which are supposedly handled over the web must still be confirmed with a phone call, and often by faxing a copy of one's credit card.  I've had to do this a couple of times.

 * That's why I think that for all of the beauty and simplicity of URLs and browsers on palmtops that the URL is still in our day last on the list of importance in contact information for travellers.

 * Anyhow, I guess I've realized that another objection that I have to front-linked listings is that in the raw wikitext the URL is the very first thing. I think the name should go first.  Actually I think that's really important.

 * If you insist, I am very willing to compromise by agreeing to put the link right after the name of the place and before the other contact information but I really do not want the name of the listing itself linked because that has the effect of putting the link first before the name in the wikitext, and in bold to boot.

 * I guess for me it's important that the wikitext source itself also look good and be easy to use. I guess I'm also looking at the listings as being a sort of a unit, including the URL, so I don't really see why the URL should need any specific markup since its really easy to recognize a URL with regex, and that the Mediawiki software already does that.  I'm also thinking in terms of offline editing because I very often edit pages in Vim], rather than in the browser window.  At any rate I really think it's important to preserve a visual hierarchy of some sort within a given listing.

 * At any rate, I'd really like to come to a consensus on this, and I'd like as well to underscore that I have a great deal of respect for the work you've done for Wikivoyage, as well as for your skill as a graphic-designer as demonstrated by your excellent map of Copenhagen. -- (WT-en) Mark 11:54, 15 Sep 2004 (EDT)

 * I guess the importance of URL's is subjective. I have never used a fax to book hotels (except for documentation to get a visa to Russia). I have used the www to book hotels in Greece, Belgium, USA, Finland, Russia, and France. And I have used the www to choose hotels in many more countries. I just like to see a web-page before I choose a hotel unless I can just walk by.

 * You can recognize a URL with a regexp. But what is it a URL for? I guess that if we have a policy that there can be at most one bare URL (= [ http: //example.com] URL that become number/arrow) in each entry and that it is an URL for the first bold text, there is no loss of information.

 * OK, I won't object to this. Of course someday there might come a wikimedia version that let us write external links with the URL's last and can generate all kinds of HTML formatting and I will suggest that that we run a perl-script to "clean up" the raw wiki-text :-)

 * I am happy that you like my work, but I cannot take credit for the train-maps in Copenhagen
 * They are the maps used by danish public transportation I got them from Jørn Damsgaard, who was very helpful. I just exported them from GIMP. But I can recommend everybody to just ask your local traffic organizations for permission to use this kind of material on WikiTravel.
 * I think it is best that kind of request comes from locals in the native language. But maybe we could make a template. I.e. making sure the CC-sa license is mentioned.

 * The Copenhagen/Østerbro map required more work than skill. It is based on autotrace on a PD map from one of the sites mentioned in the map expedition page. It seems there are advantages of living close to the US embassy.

-- (WT-en) elgaard 17:41, 2004 Sep 15 (EDT)


text:
Wikivoyage talk:External links/vacation rentals

Vacation apartments, self-catered rentals, etc.
It looks like we may have a little logical conundrum with potential listing (or not) of this sort of accommodation. The problem is that most of the ways which people find out about the availability of such short-term apartment rentals is through various websites which collect listings from individual owners and from each other. The websites usually charge a fee either to the owner or to the renter, and it's usually pretty steep.

Another fact to note about these sites is that they are fiercely competative with one another, and engage in some questionable business practices, like copying the apt. listings from one another. If we were to accept listings of these services we would likely wind up being turned into a constant battle ground in their competition for google rankings. We have enough server load and bandwidth problems already without letting that happen.

Generally we wouldn't want to link to such sites anyhow, because of the "other guides" rule. However it does seem to be OK with everybody to list pre-web brick-and-mortar operations which do the same thing for a particular destination (like the bike shop in Amsterdam or the two non-profits in Paris). Maybe this is OK just because they aren't going to use us to fight each other on google.

The real rub here is that we probably don't want to list individual apartments either, as there would just be way too many of them. Attempting to do that would turn Wikivoyage into more of a free apartment directory than a travel guide, and that is a non-goal if I've ever seen one. Ideally maybe somebody will start a travel apartement wiki, since it seems this would be a good medium for such ads, just not on Wikivoyage. Until that happens though I guess we need to think about this problem a bit. Right now this seems to be the consensus:

 * Vacation apartment websites are not to be listed, as they are "other guides".

 * Individual apartment listings are not welcome, as there would be too many of them if everybody did it.

 * Pre-web brick-and-mortar apartment rental services can be listed.

 * Sources of apartment ads can be mentioned so long as they appear only on paper, and do not have a website. (Sometimes links to websites belonging to paper sources are OK too, maybe.)

Am I right that this is the consensus? As with concert listings I think it's kindof funny to be able to tell travelers about printed materials and not the web, but maybe that's just me. -- (WT-en) Mark 05:21, 13 Nov 2004 (EST)

 * Mf. I happen to also disagree with the concert listings policy, nightlife guides can be invaluable to some cities and the info in them is so short-lived that Wikivoyage can't hope to keep up.

 * That said, I'm not sure about what to do about apt listings either, I think an artificial division into paper and non-paper makes little sense. Perhaps it'd be best to allow one section per country (or region of suitable size) with a vetted list of major operators, and direct cities and specific destinations to that section.  This would at least minimize the bloat. (WT-en) Jpatokal 08:06, 13 Nov 2004 (EST)

 * I think that vacation rental services are far enough out of our sphere that they fall outside the "other guide" rule.

 * We have a very simple and reasonable rule we have for every other kind of external link: that is, we only use primary links. If we're talking about the Hotel St. Paul in Montreal, we don't link to a review in the Cleveland Plain Dealer about the hotel -- we link to http://www.hotelstpaul.com/ . Note that a link's domain name doesn't determine whether it's a primary or secondary link; in our guide to Cleveland, it may make a lot of sense to add a link to the Cleveland Plain Dealer.

 * Similarly, if there is a place where we're talking about general, world wide vacation rental services, of course we will provide links to those services -- as many as we can write about and as is reasonable. I think it would make a lot of sense to make a Vacation rental services page, which lists and describes services, just like Hospitality exchange.

 * If there are rental services local to a city or region, it may even be reasonable to list some of them in the Sleep section of a destination.

 * What's not reasonable is to throw links to general services into each destination guide they cover. "Example.com has restaurant reviews for this city!" "Example.net has hotel listings for this city!"

 * I think the question of whether to add individual vacation rentals to accommodation listings should be discussed in more detail on Project:accommodation listings.

 * I've just tried to expand the discussion on Project:external links about what to link to. Hopefully it's a little more clear.

--(WT-en) Evan 12:43, 13 Nov 2004 (EST)

Please see Wikivoyage_talk:Accommodation_listings for proposed guidelines. (WT-en) Maj 13:55, 29 December 2006 (EST)