Wikivoyage talk:Internal links

Superceded by Project:Related articles?

Is this supercede by Project:Related articles? Should it be updated or redirected? (WT-en) Maj 23:54, 21 January 2007 (EST)

I don't think so, I think it should be expanded in fact, so that when we're judging a star nomination we have something to refer to. I'm curious what people think about internal links, especially excessive ones like on Pattaya - I personally don't like linking to other spots on the same page... and this page is in my opinion a little out of control... especially if it's about to become destination of the month, a lot more people will be seeing it and perhaps start copying that style of linking... (WT-en) ::: Cacahuate 09:15, 23 January 2007 (EST)

That page is crazy! Just one example. To have a link Do | Sports | "flying, paragliding & skydiving" under Pattaya#By_plane makes absolutely no sense. I think internal links to sections are fine, provided that they are used in moderation, when appropriate and never to another section within the same article. Linking within the same article is simply laziness and destroys the structure and readability of the document. Imagine someone trying to use a printed version of that article. A small amount of human readable text can easily replace 90% of those links and make the user experience a lot better. I got to Get In, By Plane, clicked the second link as I thought it would tell me where one would land, ended up reading about pool and fishing, lost my train of thought, lost my position in the article and still don't know how to get into Pattaya by plane. If google gave me that page as a "pattaya airport plane" search result I would close it within a minute and try the next page from the search results. (WT-en) NJR_ZA 09:43, 23 January 2007 (EST)

"Internal" here refers to links within Wikivoyage, not necessarily links within the same page.. Oops. Apparently, I don't know the difference between this and that. — (WT-en) Ravikiran 10:16, 23 January 2007 (EST)

Same page linking proposal

So to further the above, I'm proposing adding "please don't link to other sections on the same page" to this article... any objections? I haven't really come across a good example that shows why we should ever do this...

I would actually even further propose that we don't link to specific sections at all even on other pages (Pattaya#See), but surely that's more contentious...

(WT-en) ::: Cacahuate 09:27, 24 January 2007 (EST)

One thing at a time... but regarding links within a page, I agree that I can't really think of a very good reason to ever do this. (WT-en) Jpatokal 10:18, 2 February 2007 (EST)

I used it once in the Cincinnati guide (See Cincinnati#By_train. I linked to a short Taxi list since it's kind of hidden), but I agree that these links should probably be banned and make an exception for exceptions to the rule. -- (WT-en) Andrew H. (Sapphire) 02:37, 7 February 2007 (EST)

Two examples off the top of my head:

• Pelikan hotel in Virpazar is prominent both as a hotel, as a restaurant and as a place for sightseeing. Should we list it 3 times, separately in each section?
• same with Senator Ház in Eger--which is interesting both as a hotel and as a restaurant
• the following piece in Budapest:

The Danube Bridges (see Orientation above), especially the Chain Bridge (Széchenyi Lánchíd) are really attractive

• the following pieces in Eger:

"Valley of the Beautiful Women" - see #Drink section.

--(WT-en) DenisYurkin 13:35, 14 July 2008 (EDT)

For places with multiple functions, we're supposed to only list it once according to our policy (which I just came across a couple days ago and for some reason can't find right now). So either note that it's a restaurant (which also happens to have an ok bar) or a bar (that also happens to serve ok meals). The last 2 examples are exactly what this policy is hoping to avoid... see an old version of Pattaya for an idea of why I love the no internal links policy :) – (WT-en) cacahuate ^talk 23:24, 14 July 2008 (EDT)

• Certainly links within an article should be used very sparingly, but there are times when they are useful. For example, here is a paragraph from Xiamen#Orientation:

The main train station, long-distance bus stations, and ferry terminals are all on Xiamen Island, though there are less important stations in other areas. The airport is also on the island, up on the North side. The bus rapid transit system (BRT) has one line running East-West on the island and another that runs North, crosses a bridge and then forks to run through parts of Jimei and Tong'an. Other districts do not (yet?) have BRT service. See Get around below for more on BRT including a link to a map.

• I think some BRT info belongs in this section and giving an overview here, just below the map that is in that section, makes sense. The details are, and belong, elsewhere, so the link is fine. Pashley (talk) 00:00, 10 February 2013 (UTC)

New discussion on anchored links

Hmm, this one's a new one to me. It seems odd; linking to anchors is a very powerful feature of HTML and it seems useful. What's the rationale for prohibiting them. (WT-en) LtPowers 10:55, 9 June 2009 (EDT)

I would approach it from the other view and ask for an example of their greatness? – (WT-en) cacahuate ^talk 12:38, 9 June 2009 (EDT)

"Greatness" seems to be an unreasonably high threshold, but for an example of usefulness, just off the top of my head: In Walt Disney World#Climate, I link to #Weather to provide an easy transition for the reader from reading about the climate to reading about what measures are in place to assist guests during severe weather. (WT-en) LtPowers 13:28, 9 June 2009 (EDT)

The example linked above () is indeed a disaster. But I've never seen that happen anywhere else, and I don't think a rule is necessary to deal with it. I use anchored links all the time (albeit rarely more than once in an article). --(WT-en) Peter ^Talk 18:16, 9 June 2009 (EDT)

Yeah, I think we've used them to good effect in the Chicago articles (albeit not to excess). It's handy when you're dealing with a really long article. (WT-en) Gorilla Jones 19:51, 9 June 2009 (EDT)

Hm, this discussion dropped off my radar. Is it accurate to say we have consensus that linking to other sections within an article should be done sparingly but not avoided just for the sake of avoiding it? (WT-en) LtPowers 09:09, 2 February 2010 (EST)

I think that is accurate. --(WT-en) inas 02:01, 28 May 2010 (EDT)

But I wonder what is sparing enough; do we have any criteria when it becomes not sparing any more? --(WT-en) DenisYurkin 15:38, 28 May 2010 (EDT)

Its nice to be able to read an article straight though. As a matter of writing good prose it should avoid breaks in the flow, and too many references to other article sections. Where we have seen that it makes sense to reference another section in an article, then there is no harm in internally linking to it. --(WT-en) inas 01:32, 29 May 2010 (EDT)

Then, can we rewrite it to something meaning "any [[#section|link like this]] is fine (but not See [[#Section]]), as long as it's no more than one link per paragraph"? I still believe we need more clarity here. --(WT-en) DenisYurkin 16:09, 5 July 2010 (EDT)

It's impossible to anticipate all of the situations in which we might want to use such links, making any attempt at setting a hard limit problematic. (WT-en) LtPowers 17:00, 5 July 2010 (EDT)

Do you mean both linking style and limit on how often we should use them? --(WT-en) DenisYurkin 17:06, 5 July 2010 (EDT)

I suppose I do. Both linking styles are useful in different situations. (WT-en) LtPowers 20:01, 5 July 2010 (EDT)

Then I still need clarity on "should be done sparingly"--currently it seems not any more clear to me than "I know it when I see it", which is not very helpful. --(WT-en) DenisYurkin 15:34, 6 July 2010 (EDT)

Shortcuts

It has always been that we've had some shortcuts that redirect from the main namespace into the Wikivoyage: namespace in contravention of Wikivoyage:Internal_links#Other namespaces. However, now it has gone over the top, with literally hundreds of these redirects "shortcuts" that pollute the main namespace.

If we are going to persist with all these shortcuts, then they should move into the Wikivoyage namespace, like happens on the other WMF wikis. --Inas (talk) 05:08, 8 February 2013 (UTC)

I think the better path is just to desist with all the pointless shortcuts. Our shortcuts had until very recently developed as patrollers needed them for edit summaries. So we had some for the extremely common ones like dt, mos, xl, and 7+2. Those are awful handy, and I'd love to keep using them without adding WV: before all of them. --Peter ^Talk 05:37, 8 February 2013 (UTC)

While I wholeheartedly agree with you, your approach appears to be failing quite spectacularly. Do you agree one path or the other is required? Continuing to add so many redirects to the main namespace can't continue without impacting the main guide. Some of the current ones in use could be real search terms. --Inas (talk) 12:34, 9 February 2013 (UTC)

I do not see them as much of a problem in most cases if they are not a likely destination or travel-related search term. It makes sense to not have them on WP because you never know when you'll end up with an article for an acronym like wiaa or mos or a band called 7+2. But here those are never going to be needed for another purpose here. Plus some of the shortcuts are Intuitive in helping new users who are searching for policies or consensus or copyleft, etc., and have not yet figured out that all those kinds of things will be in the wv: namespace. Texugo (talk) 14:44, 9 February 2013 (UTC)

The main namespace is for our travel guide. The project namespace is intended for the management of it. That is the essence of this policy that we currently don't allow these internal links. You should be able to grab a dump of the main namespace, and just have travel info, nothing else. --Inas (talk) 21:38, 9 February 2013 (UTC)

Well, we do allow these internal links. That's been a matter of fact over many years. This policy page is just so rarely looked at that we never updated it. --Peter ^Talk 23:31, 9 February 2013 (UTC)

Not true. We've allowed a few exceptions to slip through the cracks, because they are useful and did little harm. We've never allowed widespread links from the main namespace into the project namespace. --Inas (talk) 00:13, 10 February 2013 (UTC)

So, to summarise the current "Shortcut" policy as I understand it:

1. Shortcuts can be useful, both in edit summaries and discussion pages for pointing folks succinctly towards relevant Wikivoyage policies without, for example, having to wear out one's fingertips typing all of Wikivoyage:How to handle unwanted edits
2. These Shortcuts should always just point towards the whole policy article in Wikivoyage namespace and never to the precise sub-section or paragraph that we mean to actually reference with our shortcut. That way, there is every chance that the newbie (or ignorant oldtimer) will plough through the whole screed and learn a lot that they didn't know before along the way
3. These Shortcuts should always be prefaced by the two letters wv so as not to pollute main namespace, thus WV:times or wv:times
4. An exception can be made for those Shortcuts (such as and at) that are already polluting main namespace and are listed here. If you wish to pollute main namespace even further by using shortcuts that are not preceded by the two letters wv, then the pollution must first be proposed and agreed there.

Have I got that right, please? -- Alice^✉ 02:10, 10 February 2013 (UTC)

That is as I understand it. --Inas (talk) 02:19, 10 February 2013 (UTC)

So, putting all that together, can I put a toe back in the water and safely create WV:ue and wv:ue as redirects to Wikivoyage:How to handle unwanted edits without a big beast charging up muttering "bloody newbies polluting our guide with alphabet soup!" and then accusing me of edit warring after he deletes my newly created utilitarian shortcut and I then restore it - or is there some nuance I'm still missing here, Sir? -- Alice^✉ 05:23, 10 February 2013 (UTC)

No, that's not the policy. We've had a Wikivoyage:Shortcuts page for the past five and a half years, with shortcuts like dt, xl, etc., the consensus for which was established in discussion in 2007, and which have been used on a daily basis by regular contributors and admins ever since. It's been our practice and policy all that time. Finding that a dusty, obscure policy page hasn't taken that into account does not make them against policy—it at most means we should update this page. Revising our policy on how to handle shortcuts is fine, but the notion that they've "been against policy all this time" does not jibe with how we do things. --Peter ^Talk 05:59, 10 February 2013 (UTC)

And really, the solution to this particular problem is just: "Alice, stop creating tons of shortcuts for no reason." --Peter ^Talk 06:08, 10 February 2013 (UTC)

Please do not pretend you can not understand the fundamental point of having a shortcut, Peter.

Also a "shortcut" can be viewed as an anchor - it can, and should, provide a precise and exact link to a particular section of what may be a very long policy or MoS guideline and that is why I fundamentally disagree with my formulation number 2 in my summary above.

You personally might never need to be pointed to our relevant section on wv:aou but if a newbie is asking what that funny " " is, it's going to be so long-winded to write "please go to our policy page Wikivoyage:Measurements and then read the second sub-section down entitled "avoid orphaned units" for an explanation - especially when someone may have come along in the meanwhile and changed the subsection's title. Shortcuts are more likely to survive subsection title changes and re-organisation since usually they will be moved if the section moves or is amalgamated.

No, we shouldn't have shortcuts for everything - but we should have precise (and relatively immutable) anchors for important sub-sections of our MoS and policies.

Now please stop faffing around and either state exactly why my summary above is wrong or state the correct summary below. (And please, no nonsense like "It's policy that whatever Alice does is wrong.") -- Alice^✉ 06:31, 10 February 2013 (UTC)

Peter - I don't much mind about shortcuts in the WV space, so I'll leave that part to you and Alice to discuss. My concern is only in polluting the main namespace. Support for creating shortcuts in the project space isn't supported or otherwise by this policy, and as far as I know we don't have such a policy. However, it is a policy to prevent their proliferation in the main namespace. I'm fine with having a few exceptions defined at the shortcuts page as exceptions. I absolutely dispute that our current shortcuts create a precedent for linking from the main namespace to the project namespace. They don't. They are just what they are. --Inas (talk) 07:05, 10 February 2013 (UTC)

If their constant use by just about every patroller doesn't make it clear, Wikivoyage_talk:Shortcuts#Abbreviated redirects for common policies makes it clear as day that our current shortcuts didn't simply "slip through the cracks," but are instead were established by consensus.

The really short shortcuts are very helpful for the difficult job of patrolling, and I say that having spent something like a hundred hours over the past six years patrolling. Why would we make the job more difficult on our patrollers just to reign in one annoyance? I'd say this is an example of bad cases making for bad laws. --Peter ^Talk 16:09, 10 February 2013 (UTC)

See also Wikivoyage_talk:Shortcuts Pashley (talk) 14:26, 10 February 2013 (UTC)

We have a policy on Internal Links, that says we don't link from main to project namespace. This is the way the wiki software is intended to work. We've developed an exception (in my opinion a poor one) to save a couple of characters for patrollers, to have some shortcuts in the main namespace. I don't like that, but I accept it, and I use it myself.

However, to say that in any way invalidates this policy by way of precedent and that this policy is obscure, ignores that the Shortcuts policy itself is obscure, and that this policy just states the divisions between namespaces as they are supposed to work. You can't invalidate that to save patrollers a couple of keystrokes. --Inas (talk) 22:28, 10 February 2013 (UTC)

I absolutely say that establishing a consensus for a practice invalidates prior policies that contradict that consensus. That's how our decision-making process works. That's how you change a policy.

Our policies are determined by consensus. We had a discussion about this (in 2007), developed a consensus, created project pages based on that consensus, and developed the practice of mainspace shortcuts to policy pages, which has been used by everyone who patrols, on a daily basis for 6 years. That's the opposite of obscure or something slipping through the cracks. Forgetting/not realizing that there was a contradiction on this page does not invalidate that consensus, nor make the practice against policy—it means this policy is out of date, and should be changed.

Actually, simply deleting this page might make sense, since it's of such low importance/use. It illustrates that having too many policy pages makes them hard to keep up to date. --Peter ^Talk 20:59, 11 February 2013 (UTC)

We plainly disagree. The shortcuts policy only formed a consensus for the handful of shortcuts it created. It didn't create a consensus anywhere near as broad as you are suggesting. When you want to change a fundamental rule of the way the mediawiki software works - such as separation of project and main namespaces - you want to demonstrate a consensus to do that. Not just ride on a handful of trivial shortcuts to change a policy at the essence of how the wiki operates. This policy is of far greater significance than the completely insignificant shortcut policy, that barely received any attention over the years. --Inas (talk) 22:41, 11 February 2013 (UTC)

Not that it is of interest, but I cleave more to Inas's stance, now it has been explained, that one "should be able to grab a dump of the main namespace, and just have travel info, nothing else." There was never any real attempt to achieve a consensus by actually addressing the issues raised here before the "policy" was suddenly and hastily changed. Inas has sound reasons for his position, while I have yet to see any real rationale advanced other than "I don't like it" for those suggesting that this fundamental policy be trivially exceptioned.

Yes, we do need shortcuts to save editors considerable time in their patrolling edit summaries and these should be prefixed by wv:. Then we can also have expanded templates named with the same character combination that follows the wv: prefix for the shortcut that will expand to provide polite and educational advice if the patrolling editor needs to leave a message on the ignorant/miscreant editor's talk page.

A more reasonable alternative to deleting the Wikivoyage:Shortcuts page, would be to stop pretending that it is a policy page at all rather than just a helpful aide memoire of just some of the more fatuous main name space pollutions. Better still would be to create new redirects in the wv namespace of all of those listed there now and delete all those policy variant shortcuts. One could then create another, table (so that it can be alphabetically sorted on either the shortcut or the first word of the page it directs to) of the policy-compliant, wv-prefixed shortcuts as a simple aide memoire and make quite clear at the top that it was not a policy page and add a reminder that anyone creating shortcuts from wv namespace into either wv namespace or user namespace should ideally remember to list them there.-- Alice^✉ 23:50, 11 February 2013 (UTC)

I've done a 2 column draft sortable table here: User:Alice/Kitchen/Shortcut but I'm reluctant to add the third column with templates for polite, helpful messages until (if?) we get a consensus on relaxing template use... -- Alice^✉ 08:22, 12 February 2013 (UTC)

For the record, I don't see a problem with a relatively small number of mainspace shortcuts to project space. It's far better than the alternative. LtPowers (talk) 19:04, 16 February 2013 (UTC)

What is "relatively small". I agree 5-10 shortcuts to the main namespace are a small problem on a wiki that at any one time has several hundred other pieces of detritius that float around the main namespace. It is not elegant design, but not harmful. However, even before Alice started adding links to subsections, other users had already added tens of these things over the years, with combinations that come close to real search terms. Again, unpleasant, and putting the needs of the editor/patroller above the needs of the traveller. But vaguely tolerable in perspective. We're allowing an exception to the way wiki namespaces work to make a job easier for the patroller. You can allow exceptions to a policy without invalidating it. This is the only lens through which the shortcuts policy make sense. --Inas (talk) 03:17, 17 February 2013 (UTC)

I agree with Inas. I was searching for a destination, and some of these redirects came up in the search results as if they are real articles. It was confusing to me, so it probably also is for those not as accustomed to our site processes. Many of these "shortcuts" could be legitimate travel topics, e.g. Attractions, Apartment rentals, GLBT, Sex tourism], Time, Tour. Others are legitimate destinations. Mos, while actually one of the few useful shortcuts we have, is a town in Spain. Apt is a town and canton in France. As are towns in Belgium, Norway, Finland and the Czech Republic. Tone is a town in Japan. IL, I'd say it should redirect to either Illinois or Israel, but no, it goes to this page. I think these should be enough examples why redirects from the main space to another namespace should not be allowed. Globe-trotter (talk) 07:01, 18 August 2013 (UTC)

Do we no longer allow redlinks?

Swept in from the pub

It has always been encouraged to link to articles, even if they don't exist, because it draws attention to them which will hopefully result in someone clicking them and creating an article. It's also more convenient to have articles that mention a destination already link to it upon creation rather than trying to find the city name in every article after the article is created. Edits like this which remove links seem counterproductive. Was there some sort of change or can I re-add the links? ChubbyWimbus (talk) 01:52, 6 March 2014 (UTC)

They should be always left in red, as far as I know. Texugo (talk) 02:14, 6 March 2014 (UTC)

As far as I know, there was no discussion around 'not allowing redlinks', which makes the title of this section a completely loaded question.

Definitely red links are part of the fabric of WikiMedia, and they have a use in identifying potential new articles. Do bear in mind however that an article with a very long list of Red Links may not have actually been designed very carefully. The Hubei example you use was actually excessively using red links out of the regions correct hierarchy that I have since fixed. Andrewssi2 (talk) 14:44, 6 March 2014 (UTC)

If those links were outside of the region's hierarchy, why did you only de-link them instead of removing them altogether? If they are not in that region, they should not be listed at all. 179.153.223.88 14:46, 6 March 2014 (UTC)

The links were in the region's hierarchy, just not at that level. Cleanup exercises do not have to happen in one go. Andrewssi2 (talk) 15:09, 6 March 2014 (UTC)

Hmm.. ok, but in the Cities section, every town listed should generally be linked, whether an article exists yet or not. If it doesn't belong in the list, remove it. Unlinked cities have no place there in any case. Texugo (talk) 15:16, 6 March 2014 (UTC)

I would say that listing (and linking) every town and village in China (and doubtless other countries) is probably not the way to go in WV. Are you saying that if town XYZ exists then it must be red linked? If so then that should really be part of a policy that can be referenced. Andrewssi2 (talk) 23:12, 6 March 2014 (UTC)

What about redlinked counties? Red links to non-cities or to topics like hang gliding? K7L (talk) 15:38, 6 March 2014 (UTC)

There shouldn't be redlinks for counties or other subdivisions unless they are part of a comprehensive no-gaps-no-overlaps subdivision scheme that isn't overly fine-grained, because otherwise they may not necessarily deserve their own articles. I'd think it better not to link topic articles that don't exist though, because topics that don't make it past outline status tend to get deleted again, thus the question of whether they deserve an article is a little harder to clearly answer in advance. Texugo (talk) 15:53, 6 March 2014 (UTC)

Wikivoyage:Internal_links and Wikivoyage_talk:Internal_links would be a good place to continue this discussion. Andrewssi2 (talk) 23:12, 6 March 2014 (UTC)

Sub section link

Swept in from the pub

I know I can link to a section of an article from another article, for example Long Island#Get in, but how can I link to a subsection? How can I link to the "By train" sub-section of the "Get around" section of a page. Long Island#By train will not work as this will jump to the same named sub section of "Get in".--Traveler100 (talk) 07:54, 11 January 2016 (UTC)

@Traveler100: This is a serious problem with Wikivoyage/Wikitravel and how the guidelines at these two sites conflict with MediaWiki software. Another option is to link to Foo#bar_2 to link to the second instance of a certain header or to make a phantom anchor with a template. Both of those options are a little cumbersome and can change at a moment's notice as other users edit. —Justin (koavf)❤T☮C☺M☯ 07:56, 11 January 2016 (UTC)

As Koavf notes, Long Island#By train 2 will work. -- Ryan • (talk) • 08:19, 11 January 2016 (UTC)

Great thanks. Was not aware of the adding a number functions. --Traveler100 (talk) 08:56, 11 January 2016 (UTC)

Linking to other articles multiple times in the same article

I realize that we don't want to link every instance of a placename in any given article. That gets excessive, especially for closely related places that are mentioned frequently in each other's articles. But the current advice of only linking the first instance doesn't account for how readers may jump around to different sections and not always read the section (often Get In or Understand) that has the first link. I think we should loosen this guidance somewhat. Powers ^(talk) 15:29, 30 October 2016 (UTC)

Agreed. Do you have a suggested wording that would be better? Does Wikipedia have guidance on this subject that would could follow? -- Ryan • (talk) • 15:34, 30 October 2016 (UTC)

w:WP:REPEATLINK says "Generally, a link should appear only once in an article, but if helpful for readers, a link may be repeated in infoboxes, tables, image captions, footnotes, hatnotes, and at the first occurrence after the lead. ... However, in glossaries, which are primarily referred to for encyclopedic entries on specific terms rather than read from top to bottom like a regular article, it is usually desirable to repeat links (including to other terms in the glossary) that were not already linked in the same entry ...."

I would submit, though, that our travel guides are probably read in a less linear way than even an encyclopedia article, and we generally have fewer links than a Wikipedia article as well. So the issues that lead to WP wanting to avoid repeat links may not apply to us as much.

I'm not ready to propose wording until I get an idea for how restrictive we'd like to be. If people are okay with linking once per section, that will have different wording than simply "link if it's been a while since the last link" or something like that.

-- Powers ^(talk) 17:45, 31 October 2016 (UTC)

I think Wikivoyage is often too eager to eliminate subjective judgement when writing policies, so I'd hope that whatever wording is chosen allows for some latitude. As you've noted, "once per article" is often too little, but "once per section" might only make sense for a star article that contains 20 screens of text and not for an outline that contains a single screen of text. -- Ryan • (talk) • 18:01, 31 October 2016 (UTC)

Fair enough. Here's the current text:

Links to other Wikivoyage pages should be incorporated into the text of an article if relevant and useful for readers. Generally link only the first instance of a link target, although where there are lists—for example, of country-names, further on in an article—it may be acceptable to relink items to avoid a patchy visual effect.

Don't overlink. Avoid adding unnecessary links to potential articles that don't fit with our goals and that won't have travel content. Wikivoyage has specific goals, and content that doesn't have much to do with travel is probably never going to have an article in Wikivoyage. Even if there is an article on a common term, such as railway station, think carefully about why a reader would use the link before adding the square brackets.

Here's a go at a rewrite:

One of the most important features of a wiki is the network of links connecting every page on the site. Links to other Wikivoyage pages are called "internal links" (as opposed to external links that send the reader away from our site). A robust network of internal links is critical to our readers' navigation of the site, not to mention the boost it gives to our pages' rankings in search engines. Use a link anytime you think the linked article would be relevant and useful for readers.

However, it's important that we don't overlink. Avoid adding unnecessary links to potential articles that don't fit with our goals and that won't have travel content. Wikivoyage has specific goals, and content that doesn't have much to do with travel is probably never going to have an article in Wikivoyage. Even if there is an article on a common term, such as taxicabs, think carefully about why a reader would use the link before adding the square brackets.

You also don't need to link an article every time it's mentioned in the text. For most travel topics, linking just once per article is sufficient, unless the references are widely separated in the text. For placenames (that is, places that have or could have Wikivoyage articles), you should always link them the first time they appear in the article, and link again if it's been a while since the last link (usually no more than once per major section, max). An exception applies for lists of places, where you should be consistent; do re-link a place if its neighbors are all linked too, to avoid a patchy visual effect.

-- Powers ^(talk) 15:12, 1 November 2016 (UTC)

I think that suggested update is excellent. My one addition would be to slightly expand the exception list to make it very clear what is meant by "list of places" and thus prevent people from getting overzealous and removing links from things like routeboxes:

"An exception applies for lists of places, including special page elements like routeboxes, where you should be consistent..."

-- Ryan • (talk) • 15:30, 1 November 2016 (UTC)

Linking to cities versus linking to airports

Swept in from the pub

In the "by plane" section of "get in" (and rarely "get around") we often have a list of airlines and cities (KLM connects Amsterdam with Atlanta), which in its current form irks me at three different points. First, it should be KLM and second it should be Amsterdam Schiphol Airport instead of Amsterdam. When we look for plane connections and there are airport articles, pointing people to the city article is less than useful to our readers. Now I have been fixing those on and off when I come across them, but the sheer number of articles makes this a daunting task and absent any clear (and enforced) policy or style guide, new editors are likely to presume what the preponderance of existing articles does to be our standard (de facto or not), so which policy where would we have to change to get this at least somewhat known and is this a dumb idea for some reason? Oh also, the third thing of the above that irks me is that the link goes to Atlanta instead of the busiest airport in the world. So can we please at least make this a new policy (or part of the appropriate existing policy) even if actually fixing it will take some time? Hobbitschuster (talk) 19:05, 2 February 2017 (UTC)

The creation of Airport articles has a somewhat high bar, and as such the casual contributor would have no idea whether an airport article exists for city X or not. Therefore to achieve this policy amendment you would have to require all contributors to research each connecting city ( or look up here : Wikivoyage:Airport_Expedition#Articles ) in order to determine if a corresponding airport article exists. I would say that requirement goes far beyond reasonable policy. --Andrewssi2 (talk) 19:33, 2 February 2017 (UTC)

I may have been misunderstood here. Even when linking to cities that have no airport articles, it is much more helpful to link to the #By plane subsection of said article (because the point of the link is to tell people there is an air connection between A and B, not that city B exists) and if one clicks on that section, the link is soon found. And if the link is not there, that is a failure on part of the person creating the airport article. What I am saying is that when the topic is specifically how to fly into a certain place, airport articles and by plane sections should be linked, not city articles. Hobbitschuster (talk) 19:40, 2 February 2017 (UTC)

Fair enough, but that should still be a recommendation on the destination template for the 'Get In' section rather than enshrined in policy? --Andrewssi2 (talk) 19:47, 2 February 2017 (UTC)

Call it what you want (I am content if it is not a policy but rather a preference or recommendation), but I think we should point that out somewhere (I am raising this here, because I would not begin to know where this might be found). Hobbitschuster (talk) 19:52, 2 February 2017 (UTC)

WV:Article templates/Sections#Get in might be the place, but the issue seems more specific than the current content. Is there some yet unlinked page that fits better? --LPfi (talk) 20:22, 2 February 2017 (UTC)

I'm not sure why we need to link to the #by plane section. I thought the point of the link was to enable users to get more info on a connecting city if they wanted. Shouldn't all the info they otherwise need be in the Get in section? We don't link to #by train, #by car or #by bus either. I can see a point to link to a specific airport where there are two serving the city (London Gatwick is quite different than London Heathrow), but otherwise I'm don't see why it's all that useful. -Shaundd (talk) 22:11, 2 February 2017 (UTC)

I agree. If you're referencing a city as a destination, link the city, even if you're talking about getting there by air. We should only link airports (or #By plane) when the airport is specifically being referenced. Powers ^(talk) 03:07, 3 February 2017 (UTC)

Red links

Swept in from the pub

Continued from Talk:Red Sea Coast

What’s the line on red-linking places? They’re most often seen in lists of cities on a Region page. They’re an ugly wash of red ink and create a wrong emphasis on the least informative aspect of that page. Many such lists look to be Wikipedia category dumps from away back. My approach is only to retain a red link if the place so obviously needs its own page that I’m prepared to build it myself in the near future. Anything in the category of “nice to do, if someone else would put in the work” can’t be that important. Grahamsands (talk) 13:50, 23 April 2020 (UTC)

Often, you might not be able to create that article because you don't know anything about the place, but someone else might be familiar with it, even an anonymous user who decided to contribute because that person knows about that destination. While I can understand the reasons to remove red links in some cases, I think that removing almost all of them is a large task not worth doing. --Comment by Selfie City (talk | contributions) 14:01, 23 April 2020 (UTC)

I suppose the red colour is chosen to make them highly visible, making them "an ugly wash" and "create a wrong emphasis". Could we perhaps change in the CSS files to make them stand out less, instead of removing them? I think there is a point in laying out what articles are needed in a region, so that anybody can see what is not yet covered, and somebody knowing the region can contribute by creating one of those without figuring out what cities belong to a certain WV region. I am asking myself not what I’m prepared to do in the near future, but what should be done to make the region reasonably covered. If a region lacks articles on most important cities, we should not hide that. Then, of course, we should not redlink every tiny village in the region. --LPfi (talk) 14:36, 23 April 2020 (UTC)

If there's a reason for a name to be prominent, then let it be prominent - eg if it's misspelled and fails to link. (It's really useful to have that check on preview.) But if there's no reason, let it be plain text, not some in-between dull mauve. Agreed that coverage needs to improve in many areas, but if candidates for new pages are mapped on the "region" page, would contributors not notice the difference between blue and black text? They would when they tried to clink on it. Grahamsands (talk) 20:29, 24 April 2020 (UTC)

As I understand it, the rationale for the conspicuous color is that it encourages readers to plunge forward and create an article about the destination, if they have the knowledge to do so. Of course that has to be weighed against the other considerations you mentioned. —Granger (talk · contribs) 22:28, 24 April 2020 (UTC)

Personally, I do not think the color is particularly important. I am not sure it creates the "ugly" impression for readers who are not editors, and if so, is it such a dreadful concern that we must remove every (or nearly every) single red link we see? --Comment by Selfie City (talk | contributions) 14:31, 25 April 2020 (UTC)

I agree with SelfieCity. If the color is offensive (to you; it doesn't bother me), then let's change the color in CSS, but let's not remove appropriate links. WhatamIdoing (talk) 15:35, 25 April 2020 (UTC)

"Red links for subjects that should have articles but do not, are not only acceptable, but needed in the articles. They serve as a clear indication of which articles are in need of creation, and encourage it." -- w:WP:REDLINK Powers ^(talk) 18:53, 25 April 2020 (UTC)

Thanks, Powers. That's a good summary of the reason why we include red links. Could we incorporate those sentences into our own Wikivoyage policy to settle the debate if there is consensus for its inclusion? --Comment by Selfie City (talk | contributions) 00:39, 26 April 2020 (UTC)

Support, it then becomes a question of which places meet the criterion of "should have articles", and these can be discussed case by case. For if they should, let that status be prominent in red-link, uniform with Wikipedia. Ditto if there's a current debate about whether a particular place does or doesn't stand. Contributors will vary in their propensity to highlight places in that way, and my own definition of "and I'm prepared to write it myself" lies at the parsimonious-going-on-Occamist end of the spectrum. But we seem to be agreed that the other extreme of "just about every place-name" isn't sensible. Grahamsands (talk) 11:50, 26 April 2020 (UTC)

That is why we have the can you sleep there? test. That would, I believe, also qualify which pages are allowed to be red-linked. --Comment by Selfie City (talk | contributions) 16:04, 26 April 2020 (UTC)

I don't think this should be about what is allowed, but how to make the judgement call. There could be lots of towns and villages where you could sleep, but which should not be listed, in a region with say five major cities, two of which have articles.

I'd think about it like districtification of cities. Redlink the major cities and some towns with important attractions and forget about the rest until the region is better developed. If it is not clear in which city article listings of some areas should be placed, the scope of each city article could be briefly explained in the city list, perhaps with some namedropping of minor places.

--LPfi (talk) 17:16, 26 April 2020 (UTC)

I think by "allowed" and "judgement call" we mean the same thing. --Comment by Selfie City (talk | contributions) 17:58, 26 April 2020 (UTC)

I usually prefer to think of it this way: All editors are permitted, but never required, to add (red) links to places for which we ought to have articles. Editors are not permitted to remove links to places for which we ought to have articles, unless these links would be removed even if the article currently existed. WhatamIdoing (talk) 22:45, 26 April 2020 (UTC)

Too many resorts are marred by part-built developments that will clearly never be completed let alone inhabited. The development was permitted, but not a good judgement call; if only that time and labour could have been put to better use. And many pages on WV look similar, hence my parsimony. But it's easier to remedy e-text than a sprawl of rust-stained concrete, so what we come to is much the same as "What is an article?" I'm thinking to amend my own test thus: if someone created this place as a page, would I send a thank-you, shrug and move on, or entreat the writer to reconsider? Anything in the third category should go from red link to plain text, to avoid attracting the cement mixers. Grahamsands (talk) 07:21, 27 April 2020 (UTC)

If there was an outline article, say with one or two listings, would you be wanting to merge it into a neighbouring article. If the answer is yes, then there shouldn't be a red link. If a region has poor coverage, it would be good to only have 3-5 red linked cities, rather than the 20 that are "possible articles", to focus editor's attention on the most needed articles. I think that we should be more selective about red links in other articles (not regions), and travel topics should only have very few. AlasdairW (talk) 21:55, 27 April 2020 (UTC)

We have a longstanding practice of tolerating redlinks as a way of encouraging content creation, and according to this discussion we also have a strong consensus to continue with the status quo. It's time to move on from this issue. -- AndreCarrotflower (talk) 02:46, 28 April 2020 (UTC)

I'm with AlastairW and the others here but would add another thought: if there is a usable-plus page in another language, then a red link might draw attention to that, perhaps supplemented by a note somewhere. In the example of Red Sea Coast that sparked my inquiry, there is well-developed content on WV-DE that could swiftly populate absent or outline pages. That's perhaps because German speakers continued to visit during a period when English speakers were deterred, so I look forward to similar great contributions from WV-RU in future. Grahamsands (talk) 07:55, 29 April 2020 (UTC)

Policy on shortcuts

Following the discussion on Wikivoyage:Votes_for_deletion#Wikivoyage:ALL, I am proposing to add a new section to this policy. Ground Zero (talk) 11:57, 23 April 2023 (UTC)

Proposal: Shortcuts

Shortcuts have been created to commonly used policy pages to make easier to cite policies in discussions and comment lines, for example, you can type wv:bold or wv:italic instead of Wikivoyage:Creating emphasis. (A partial list is found at Wikivoyage:Shortcuts.) To make it easier for new readers to understand the discussions, shortcuts should use words instead of acronyms, e.g., for Wikivoyage:Avoid long lists, wv:lists is more understandable than WV:ALL.

To avoid creating deadlinks in old discussions, acronym-based shortcuts created before 2023 haven't been deleted, but:

1. new acronym-based shortcuts should not be created,
2. users are encouraged to stop using the acronym shortcuts, and
3. acronym-based shortcuts should be removed from policy pages to discourage their further use, and replaced by word-based shortcuts if needed.

Discussion

• Support as proposer. Ground Zero (talk) 11:57, 23 April 2023 (UTC)
• Support, provided that shortcuts are still permitted in a non-raw format (i.e. something like "[[WV:TDF|time and date formatting]]"). --SHB2000 (talk | contribs | meta) 12:06, 23 April 2023 (UTC)

I don't see a problem with that. An explanation is even better than using just the shortcut. Ground Zero (talk) 12:17, 23 April 2023 (UTC)

Thanks for the clarification; good to know.

BTW, regarding Special:Diff/4651143, I'm pretty sure the convention for shortcuts has always been to use all caps (though I couldn't find the exact policy stating such), despite this spurious capitalization violation claim. It just so happened to be that no-one's created those shortcuts. SHB2000 (talk | contribs | meta) 12:24, 23 April 2023 (UTC)

Yeah, I'm not sure if there is a policy here. All caps just makes it more difficult to type, IMHO. Ground Zero (talk) 12:36, 23 April 2023 (UTC)

TBF, I don't see why we can't have both, though. SHB2000 (talk | contribs | meta) 21:49, 23 April 2023 (UTC)

• Support, and agreed that an explanation is better than a shortcut. Ikan Kekek (talk) 06:56, 24 April 2023 (UTC)

I also want to thank Ground Zero for proposing this guideline. Ikan Kekek (talk) 07:20, 24 April 2023 (UTC)

Support, though old & heavily used things like the ttcf or wia shortcuts should be kept. Pashley (talk) 08:54, 6 May 2023 (UTC)

I'd replace the ALL shortcut with "lists" and "WV:TDF" with "time" and "date". I'd also never include "WV" in any shortcut name; the whole point of a shortcut is to be easy to use. Pashley (talk) 09:00, 6 May 2023 (UTC)

The whole point of excluding "WV" is to avoid cross-namespace redirects, which are more confusing than initialism shortcuts (which are apparently also very confusing...). Such redirects could also confused bots – it's why such redirects are speedily deleted on various other WMF projects. Why this wiki allows such shortcuts has always been a mystery to me. SHB2000 (talk | contribs | meta) 10:28, 6 May 2023 (UTC)

Alternative proposal

• Since shortcuts are undesirable, I'm against truncated-title shortcuts as well. I don't think they're more intelligible and intuitive than acronym shortcuts. In that case I favor discouraging using all (what will then be legacy) shortcuts in discussions by adding something to that effect to Wikivoyage:Using talk pages ("Do not use shortcuts in discussions"), removing all shortcuts from all pages, and not making any changes to Wikivoyage:Internal links. Alalch E. (talk) 22:08, 23 April 2023 (UTC)

  Oppose for reasons mentioned on the relevant VFD thread and my comment above. SHB2000 (talk | contribs | meta) 23:39, 23 April 2023 (UTC)

  Oppose Writing out Wikivoyage:The traveller comes first every time it is invoked in a discussion is excessively burdensome to discussion. Banning all shortcuts is going too far. Ground Zero (talk) 00:05, 24 April 2023 (UTC)

  I think that that specific acronym (ttcf) is well established, and something like WV:TRAVELLER doesn't help making the target more obvious. I don't know what to do, but I don't think that "ttcf" is used in communication with newcomers. Half a dozen acronyms can be learnt when lurking around as new user – its the dozens that have been created lately that are the problem. –LPfi (talk) 06:31, 24 April 2023 (UTC)

• Mildly oppose. I think I seldom use ttcf without the full phrase, unless maybe I'm involved in a discussion that seems to have participation only by longtime users, but I think we can tolerate a small number of very basic, longstanding initialisms, with the emphasis on small number. Ikan Kekek (talk) 07:00, 24 April 2023 (UTC)

  I'm probably the wrong user to suggest this (given that I only became a regular user in 2021 and you know...), but if anything, WV:TDF, WV:TTCF, WV:TOUT, WV:DOTM (inc. OtBP and FTT), WV:MOS and WV:VFD have been longstanding on this site and would oppose outright banning those in communication. SHB2000 (talk | contribs | meta) 08:07, 24 April 2023 (UTC)

• I don't find it hard to type things out in longhand, and it aids communication. I think ttcf, dotm (etc.), mos and vfd are tolerable. tout is obvious, so it's ok. I hate ALL CAP text, which is SHOUTING and, as Ground Zero says, harder to type. Ikan Kekek (talk) 08:17, 24 April 2023 (UTC)

  As I said above, why can't we have both? SHB2000 (talk | contribs | meta) 08:22, 24 April 2023 (UTC)

• ISN'T IT RUDE? Ikan Kekek (talk) 08:39, 24 April 2023 (UTC)

but by having both, we'd have things standardized with other wikis, including wikipedia, wikimedia commons, or wikibooks, per se (and won't have users looking for them). shb2000 (talk | contribs | meta) 00:22, 24 april 2023 (utc)

Am I wrong that most of our guidelines are not the same as other wikis? We have long resisted becoming just like Wikipedia, and one of the ways we've resisted that is not to have so many policies or so many obscure links. Anyway, yes, I think both normal capitalization and SHOUTING should work as links, but don't they both work, anyway, regardless of which one is used as "the shortcut"? Ikan Kekek (talk) 03:19, 25 April 2023 (UTC)

They work if you type them in in the search box and have Javascript enabled. The wrong case does not work for links (other than for the first letter). –LPfi (talk) 15:12, 25 April 2023 (UTC)

Do Wikipedians need to be able to link our guidelines before they have learnt that much about the site, or checked the guideline they are going to cite enough to notice what shortcuts we use? I think that if they just throw in a WV:NPOV or WV:V, then they didn't read the guideline that we have (that is indeed a problem at Commons). –LPfi (talk) 15:18, 25 April 2023 (UTC)

As a wiki, we should be making life easier for Wikipedians, not harder. In this case, it's the entire Wikimedia network (consisting of >750 wikis) that use ALL CAPS for shortcuts (if a wiki has shortcuts). --SHB2000 (talk | contribs | meta) 10:54, 30 April 2023 (UTC)

• Oppose This is going too far.

As for the premise "Since shortcuts are undesirable", having too many is undesirable & some specific ones may be, but the broad statement is false. Pashley (talk) 09:03, 6 May 2023 (UTC)

Resolving this discussion

This discussion has been open for two weeks. It looks to me like there is support for my proposal, but not for the alternative proposal. Is that how other people see the result of this discussion? Ground Zero (talk) 22:01, 7 May 2023 (UTC)

I think it's clear that there is a consensus in favor of your proposal and against the alternative proposal. If no-one has more to say pro or con, I think we can take action in 24 hours. Ikan Kekek (talk) 22:19, 7 May 2023 (UTC)

Agreed; the alternative proposal (Alalch E.'s) has no support as of writing this. SHB2000 (talk | contribs | meta) 11:04, 8 May 2023 (UTC)

I've adjusted the policy page accordingly. Ground Zero (talk) 20:14, 8 May 2023 (UTC)