text:
Wikivoyage talk:Image resources

Untitled
The Perry-Castaneda collection is already listed on the Mapmaking Expedition. Do we need it here? --(WT-en) Evan 20:06, 16 Dec 2003 (PST)

Oh, duh. I think that's where I found out about it in the first place. (WT-en) Gjetost 21:54, 16 Dec 2003 (PST)

stock.xchng
I listed stock.xchng here for a few minutes, but it appears from their terms and conditions that their stuff is not compatible with our copyleft. Too bad! --(WT-en) Evan 15:08, 5 Feb 2004 (EST)

Flickr images
Actually, not just Flickr images, but all images from sources that allow users to change the displayed licensing. We have a license review template that anyone can add:

This provides a second pair of eyes that confirm that the license on the image page is correct at the time of review. But how do we get users to do this? Could we have a flickr review category? --Peter Talk 20:19, 17 December 2012 (UTC)

 * No one? --Peter Talk 20:22, 18 December 2012 (UTC)

 * As an experienced Wikipedian, I am pleased to draw your attention to a very useful tool used to search for properly licensed images on Flickr (and other places) and can even upload them directly to Wikimedia Commons. Experiment with it until you learn to use all the options. It will only find images that have appropriate licenses. Gamweb (talk) 03:02, 20 December 2012 (UTC)
 * Free Image Search Tool

Image Resources
As an experienced Wikipedian, I am pleased to draw your attention to a very useful tool used to search for Creative Commons or Public Domain licensed images on Flickr and other places, and can even upload them directly to Wikimedia Commons. Experiment with it until you learn to use all the options. It will only find images that have appropriate licenses attached. Gamweb (talk) 05:37, 28 December 2012 (UTC)
 * Free Image Search Tool

Bulk transfer of images to Commons
So what's the best procedure for getting bulk images from WV-old over to Commons? User:Travelpleb's contributions look solid (seem to be actual own work as far as my detective skills can tell) and would fill in a lot of obscure gaps. Jpatokal (talk) 01:03, 14 February 2013 (UTC)

 * Anybody? Jpatokal (talk) 05:16, 19 February 2013 (UTC)

 * Image transfer discussions are centralised at WTS. One problem is that a lot of people have uploaded images without a licence. If such files were uploaded before a specific date in 2007, they can normally not be copied to Commons. If they were uploaded later, they can often be uploaded to Commons, but this depends on the exact wording of MediaWiki:Uploadtext at the point when the file was uploaded. --Stefan2 (talk) 19:02, 19 February 2013 (UTC)

 * Ta, I've raised this on WTS-old. Travelpleb's images should be fine, as they all date from 2012. Jpatokal (talk) 22:41, 19 February 2013 (UTC)

Bump -- WTS seems to be down? Jpatokal (talk) 03:13, 25 February 2013 (UTC)

FYI - Links from Commons
I just realized Commons doesn't link back to us. I asked about it here: Commons:Village_pump Acer (talk) 21:20, 8 September 2016 (UTC)

 * The challenge is that Commons main form of organization is categories while Wikivoyage is articles, and Wikidata links articles to articles and categories to categories. If you look at places with articles on commons they do have links to Wikivoyage while smaller destinations with just categories do not. For example commons:Aberystwyth does link but commons:category:Aberystwyth and commons:category:Devil's Bridge, Ceredigion do not. Would you want to create an article in Commons for every location in Wikivoyage? --Traveler100 (talk) 06:08, 9 September 2016 (UTC)

 * There was a lot of controversy on Commons when Wikidata was to be introduced there, for more or less this reason. A Commons category is mostly about entities that could have articles in the Wikipedias, while the Wikipedias have categories only for some of the entities. Before Wikidata, categories were often linked to Wikipedia articles. There was to be some solution, but I missed the final discussion.

 * I think it is non-controversial to add old-style iw-links to Commons categories (à la Aberystwyth ). Probably mentioning the Wikivoyage article similarly or with a template (à la ) on the category description page should be uncontroversial too. Somebody should also research whether Wikidata does provide for some easy way to add these links (as an additional property or something).

 * Articles on Commons (or "galleries", as they are called over there) should be created only if one can add a good collection of images or if the gallery can be supposed to be maintained later.

 * --LPfi (talk) 09:24, 9 September 2016 (UTC)

Picture help
Hi. This goes out to all the picture and formatting experts. Due to a lot of recent edits of both myself and - what I presume to be - one person using more than one dynamic IP the article for rail travel in Germany is now much more up to date, has prose that is - hopefully - easier on the eyes and ears than before and has improved coverage. Unfortunately, the image distribution is rather bottom heavy with (next to) none at the top and (at least on my screen) more towards the bottom than there is text. So if you know anything about layout and photos, even if you don't know a thing about the topic in question, please have a look. As an aside, I hope to get the article ready for promotion to guide and a FTT nomination, but I don't think it's "there" yet. Hobbitschuster (talk) 16:33, 11 September 2016 (UTC)
 * True that, and there is a lot of room for photos higher up. If nobody is opposed to having pictures not related to the text next to it, that is. ϒpsilon (talk) 16:46, 11 September 2016 (UTC)
 * The aforementioned IP editor moved the ICE map from the very top to somewhere lower. Hobbitschuster (talk) 19:26, 11 September 2016 (UTC)

Good Commons pictures
Wikimedia Commons has a rather large list of Featured pictures. Someone might go through them looking at which ones might be used here. Also useful, but less work, would be to just patrol the Main Page with its Picture of the Day to see if those are useful.

I look occasionally but do not have either the time or the visual judgment to take on the whole task. Any volunteers? Is someone perhaps already doing this? Pashley (talk) 23:50, 25 September 2016 (UTC)

 * I'm pretty sure that Ikan is already updating articles with featured pictures, but more people assisting in that effort would obviously be welcome. -- Ryan • (talk) • 23:58, 25 September 2016 (UTC)

 * Exactly. There are also a lot of good Quality Images which aren't featured but are really useful for our purposes. Ikan Kekek (talk) 01:15, 26 September 2016 (UTC)

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

title: Wikivoyage talk:Image resources


text:
Wikivoyage talk:Images in articles

What's wrong with Project:How to add an image? -- (WT-en) Sapphire • (Talk) • 06:28, 24 May 2007 (EDT)
 * One is help and the other is a style guideline. One will tell you how to align your image to the left and the other will tell you that you shouldn't, because we have decided through consensus(tm) that we like it on the right. — (WT-en) Ravikiran 10:05, 24 May 2007 (EDT)

 * I don't think it makes much sense to split these. The nitty-gritty style guidelines should be incorporated into the templates. (WT-en) Jpatokal 10:23, 24 May 2007 (EDT)

 * If we don't want people to put them on the left, we shouldn't tell them how. :) - (WT-en) Todd VerBeek 11:06, 24 May 2007 (EDT)

Photo Galleries
archived from Project:Travellers'_pub

I notice one of the Administrators is removing photo galleries with the notation that they do not follow the Manual of style. These were acceptable in the past at the bottom of a page and the gallery function still works on this site. I can find no mention of this in the manual of style. If that is true, then the gallery function should be disabled. (WT-en) 2old 14:12, 5 January 2010 (EST)

 * It's used on pages like Angkor and Okinawa, so I don't think it should be disabled. I can't find the policy either, but I seem to recall some opposition to general galleries somewhere. --(WT-en) Stefan (sertmann) talk 15:00, 5 January 2010 (EST)

 * They most often violate Image policy, and are rare enough where I've become prejudiced against them as deviant in style. --(WT-en) Peter Talk 17:00, 5 January 2010 (EST)

 * While I appreciate both of your statements. I distinctly remember that it was suggested in very early conversations that they be used at the bottom of articles, so they load last. Evan was even involved in that suggestion. I think they may be rare due to few people knowing how to implement them. Regardless, there is no mention of them in the Manual of style and any suggestion they do not follow the manual of style is bogus. (WT-en) 2old 09:49, 6 January 2010 (EST)

 * It is pretty rare to find a gallery that either doesn't overload the article with images, or that the images wouldn't be better off inline with the text. However, certainly in the two examples given, the gallery used appears to me to be fine.
 * Placing galleries at the end of the article to speed loading seems misguided. Most browsers will download the images simultaneously, and slow down the entire network connection anyway.  Except where there are many images inline, I doubt there would be a difference whether they were at the beginning or the end. --(WT-en) inas 22:49, 6 January 2010 (EST)

 * If the gallery is in a sub-article it will not overload the article with images, and should avoid the problem of bandwidth as the user would only look at them if desired. This was used in Diving the Cape Peninsula and False Bay/Pinnacle/Gallery after some discussion on Project:Star nominations and could be used as another option. I agree with Inas that the galleries mentioned above are appropriate as they stand. I think that galleries have their uses and should not be disabled. Perhaps a guideline on recommended usage would be appropriate. Cheers, (WT-en) Peter (Southwood) Talk 03:56, 9 January 2010 (EST)

title: Wikivoyage talk:Images in articles


text:
Wikivoyage talk:Information boxes

I have really, really strong opinions against using templates for content. I would prefer that we discuss this on Project:template policy. --(WT-en) Evan 23:37, 14 Nov 2004 (EST)
 * Agreed, I'd like to make sure were focusing our effort in the best way and that we're all on the same page before we start having stuff like this. (WT-en) Majnoona 23:46, 14 Nov 2004 (EST)

 * I've removed Project:information boxes from the Project:manual of style right now until we're sure it's a good idea to go forward with this. --(WT-en) Evan 00:29, 15 Nov 2004 (EST)

 * Almost a year has passed — infoboxes are now used in 50-odd articles and have been ported to de and ja, so perhaps it's time to formalize them? (WT-en) Jpatokal 05:44, 4 Oct 2005 (EDT)

Local Interest Infoboxes
Swept in from the pub by (WT-en) Ricardo (Rmx)

Many dead-tree travelguides will have a sidebar with little blurbs containing say, little bits of history, or local interest stories that add dimension and character to a destination. What is Wikivoyage's policy on things such as this, if any? I do not see many, if any of these on the site. Is this sort of thing wanted here? I can think of many examples of such blurbs in my area that may interest a traveller and add some insight to the area but they do not fit within the context of the current template style. Any thoughts on this? -- (WT-en) bulliver 03:07, 20 March 2006 (EST)

 * I make a habit of sprinkling these into articles I write (see. eg Kawasaki, Cape Ashizuri) and they've so far managed to survive deletion. The main issue is that the Infobox template used to create them has never been formally accepted, due to Evan's resistance to the use of templates, but this seems to be less of an issue these days.  See Project:Information boxes. (WT-en) Jpatokal 03:16, 20 March 2006 (EST)

 * Yeah, that's exactly what I am talking about. So if I understand here, it is not the information in, well, a box that is the point of contention, but the use of templates to create them? Is there not strait wiki markup that can be used? I feel quite strongly that these things can be very effective if not overused. Using an obvious example here, consider the Ogopogo. It is not a place you can visit or a thing you can do, but is still tangible information that draws tourists to the region and contributes largely to its charm. -- (WT-en) bulliver 03:45, 20 March 2006 (EST)

 * I like those a lot - after seeing the Singapore article I started using them and have put them on Las Vegas, South Georgia and others and think that they make the article more interesting. And if we're gonna do them, a template should definitely be used to keep things consistent -- what was the argument against the infobox template? -- (WT-en) Ryan 22:51, 20 March 2006 (EST)

Shared infoboxes
The creation of Boleto turistico – which is included by template in a few different articles to which it applies – raises the question of A) whether to allow this, and B) if so, how to support it. One of main problems is that they show up as "orphaned", which would probably require manually maintaining an index of them. (ugh) - (WT-en) Todd VerBeek 13:38, 4 June 2006 (EDT)

 * For the case of Boleto turistico this kind of reusable content seems useful, but I would imagine we want to implement some very restrictive guidelines to avoid having zillions of these types of articles show up on the site. Off the top of my head:

 * Any content put into a shared infobox should be highly important information for travelers. For example, any visitor to sites around Cuzco must have a Boleto turistico, so that information must be included in each article and is therefore a good candidate.  Something like the National Parks Pass, which allows free entrance to US national parks, is not required to visit a park - a user who did not know about that pass could still visit the park by paying the normal entrance fee.
 * The content should include information that changes on a regular basis, such as costs, contact information, and attraction entrance information. The goal of having these shared infoboxes should be to make it easier to keep important information up-to-date.  For example, a warning about AIDS in Africa, while important information, does not change frequently enough that it should need its own infobox.
 * The content should be important to three or more articles. If only two articles need to include the infobox just include the content within the article.
 * The content should not be about subjects that Wikivoyage normally avoids, such as train or bus schedules.

 * Those are just suggestions to hopefully move this discussion along... as to the "orphaned" issue, does the MediaWiki software still overlook inclusions? If so, a manual list would probably be the only solution. -- (WT-en) Ryan 12:29, 16 June 2006 (EDT)

Funfact
Would it be ok to use an info box for fun facts? Like ... Place 4GH671XT has over 4J3OP4109GHEIW festivals, did you know? (WT-en) edmontonenthusiast [ee] .T.A.L.K. 17:29, 19 December 2008 (EST).

Boxes not rendered well by pdf export?
Apparently cautionboxes, infoboxes and the likes are not rendered well when users create "books" by converting articles into pdfs. I'd be loath to see them go. How do we fix this? Edited to add: User:Ceever has been converting such boxes as are not rendered correctly in pdf form into flowing text. I have asked he not do that until we address the issue here. He's of course very invited to weigh in here. Hobbitschuster (talk) 14:56, 31 March 2017 (UTC)

 * What's the status of the changes to the pdf-rendering tool? Did it change recently, or is it going to change soon?  WhatamIdoing (talk) 16:19, 31 March 2017 (UTC)
 * Apparently the issue is that it doesn't render boxes correctly now I know neither whether that problem has always existed nor what causes it. I also only know it through description by User:Ceever, among them edit summaries. Hobbitschuster (talk) 17:43, 31 March 2017 (UTC)
 * Johan, do you know anything about this issue? WhatamIdoing (talk) 16:49, 1 April 2017 (UTC)
 * The new renderer might not solve the problem either, or are we certain about that? Couldn't we have a look into the definition of the boxes? It seems like all kind of have the problem, so maybe a simple fix will do. I have created boxes made of html myself without the templates and their content is not lost during the rendering. Ceever (talk) 12:35, 2 April 2017 (UTC)

Alignment
The template infobox can also be aligned to the left now, after I've done some modifications to the template. I remember reading some archived discussions on someone wanting the infobox to also be on the left, but the template can now handle it. So will align it to the left as you see to the left. SHB2000 (talk | contribs | meta.wikimedia) 11:11, 4 September 2021 (UTC)

title: Wikivoyage talk:Information boxes


text:
Wikivoyage talk:Information for LGBT travel

Insensitive?
This: other queer people seems highly insensitive! Is there another way to address the GLBT and those who identify with them other than "queer." I know that WikiTravel apologizes in advance if you find this term offensive, but I think we can use "GLBT". There are benefits to this people will be less offended and its one letter less than "queer" so you save time by writing "GLBT." (WT-en) Sapphire 17:45, 16 Apr 2005 (EDT)

 * Um, from the article itself:

 * We use the word "queer" here to refer to GLBT people. It's not meant to be hostile or dismissive, and is used in North America and other English-speaking regions as a positive name. If you're offended or worried by the term, we're sorry in advance.

 * Not being a delicate shade of lavender myself I'm not the best person to consult on the merits of said terms, but I will oppose "GLBT" just because it's such an monstrosity of an acronym. Would it be too hard to just stick with plain old "gay", or will transgendered crossdressing lesbians get their panties in a twist from this? (WT-en) Jpatokal 17:56, 16 Apr 2005 (EDT)

 * I think "GLBT" is probably a lot more inclusive than the plain old gay, which is apparently specific to males. Also it it is probably less inclusive than the even more monsterous acronym, GLBTI, which also includes intersex people, and we haven't got as far as hermaphrodites... Unfortunately most of the other word on this subject are either big, insensitive or both. There probably is no word better for the inclusiveness concept than the rather vague queer but then there are not a lot of other sensitive small words to choose from. Though this also reflects the social attitudes that a lot of the cultures have to queer people. -- (WT-en) Huttite 20:36, 16 Apr 2005 (EDT)

Info for editors, info for travelers
I moved the really nice map from this meta page to Gay and lesbian travel. This page is part of our Manual of style, saying where to put GLBT info in the main guides. Gay and lesbian travel is a travel topic (kind of a catchall right now... should probably be broken up soon). --(WT-en) Evan 20:11, 4 Jul 2005 (EDT)

GayGuide in Template
"I dont understand why gayguide should not be part of the template for all cities instead of being just a part of smaller set of information? Gaypopulation has particular interest in certain bars, clubs, gay-friendly accomodation/restaurants places and is usually suffering from homophobia in many even western countries (unless thay are instructed where to be open about their identity and where to be more private). Hope to hear back from you!" - Zb's question, on my talk page [Lionfish].

Should I have deleted these? They didn't have much content, and they broke the template. Also, there was already alot on the topic under "Drink" in Cologne, for example (also could be under "Understand").
 * Cologne with 'Gayguide': [].
 * Berlin with it: [].
 * Prague with it: [].

Someone else can decide about this. -- (WT-en) Lionfish 10:59, 16 Apr 2005 (EDT) (17:00 BST)

 * Hey, take a look at Project:Information for gay and lesbian travellers for the current policy on this. I also posted this link on Zb's talk page... (WT-en) Majnoona 11:25, 16 Apr 2005 (EDT)

 * If (WT-en) Zb wants to change the template for articles to include a section for GayGuide then it should first be discussed at Project:Article templates. Frankly, I do not see the need for such a section. Information like this should be included in the specific listing, or an appropriate section, such as Understand or Stay safe. Having a section devoted to a special interest group could see Wikivoyage as being biased and skewed to a particular group of travelers. Wikivoyage should cater for everyone, so our articles should be written from that viewpoint - neutrality - including all cultures, genders and orientations. In many respects, Zb's approach smacks of segregation and discrimination rather than inclusiveness and acceptability of diversity. I question if Zb has really thought that approach through properly and the downstream implications. Besides if (WT-en) Lionfish had not deleted the sections, someone else would have, (like me), and not even felt guilty about it. Also the removal is justified because it's not policy, yet. -- (WT-en) Huttite 17:37, 16 Apr 2005 (EDT)

 * I think the guidlines say it pretty well, but I just want to reiterate the fact that we do want this information in our guides-- it's just a matter of where it shows up and in what context. This is probably clear already, but I wanted to say it again... (WT-en) Majnoona 19:41, 16 Apr 2005 (EDT)

 * Thanks Maj and Huttite for sorting this out! I'm only an occasional contributor, and don't feel like I have the authority to deal with stuff like this ;P TY! (WT-en) Lionfish 05:42, 17 Apr 2005 (EDT) (11:43 BST)
 * Glad we could help. But really, you do have the "authority" (whatever that means on a wiki!) to make any changes you feel are needed. Of course, everyone else also has the same authority to change it back ;-) (WT-en) Majnoona 09:57, 17 Apr 2005 (EDT)

Lesbian And Gay Travel Info
First of all I would like to mention that I am a complete Wiki NewB - so please feel free to inform me if I am asking questions in the wrong place or generally making a mess of things - I will try not to be offended :)

I thought that a small piece in a countries entry about it's gay and lesbian policies might be helpful to some visitors to WikiTravel. It could be concidered vital info for those visitors and could prompt more detailed info to be made available in other areas such as regional and city guides etc.

I could start with info about New Zealand where I lived most of my life for instance, and I am sure that every region has at least one contributor who is has knowledge on this subject. Even non-gay editors are likely to know the law/attitudes in their own country.

Off subject - I will try to help fill in some of the general info that has been requested about New Zealand's South Island over the next few months. I can see that it is sadly lacking in some areas.

Again, please inform me if I don't do things in the correct way. I may be new to Wiki's but I am not not new to the internet and have developed a thick 'cyber skin' over the years :)

 * Check out Project:Information for gay and lesbian travellers which covers the basic policy of what we really do want to cover and where to put it. Also Gay and lesbian travel covers some of the travel topics and pointers that could be of help.

 * The "Stay Safe" section is pretty important for many reasons, but it often lacks content. For example it's only recently that we added warnings for countries where Homosexuality is punished with death -- a pretty serious omission. We appreciate any contributions you have on this topic!-- (WT-en) Colin 22:04, 15 January 2007 (EST)

OK - I see a point - but are you not limiting the Wiki?

I got the idea that a Wiki should strive to be "a point of reference for all people' - ask a question and hopefully the Wiki will have the answer.

To quote a paragraph from one of the links you gave - "Finally, there are any number of different kinds of travelers who may have special needs -- senior travelers, travelers with children, disabled travelers, etc. Having different sections for each would make the destination pages unnecessarily cluttered, and would probably cause some duplicate information.".

The Wiki, I thought was to make as much information as possible available to as many people as possible.

The script that makes a Wiki possible leaves the options open to create simple links to info for gay, disabled, single female etc travelers. So why not? :)

Rather than make a page "unnecessarily cluttered", its making more info more relevant to more people - --(WT-en) Damian 22:59, 15 January 2007 (EST)

 * What info do you think is lacking? Only things that are exclusive to a particular country should go on that country (or city) page, everything else can go in one of the pages that Colin mentions above. Beyond specific safety info that is specific to that destination and isn't just common sense, and the occasional hoppin' gay bar listed in the drink section, what else is specific to g&l's that doesn't apply to everyone else? (WT-en) Cacahuate 23:55, 15 January 2007 (EST)

I am not sure what you are saying? - "Only things that are exclusive to a particular country should go on that country (or city) page"

That seems very odd. Every Country, City or Region has a template that makes sure there is info that is consistent with the site as a whole. Thats very noble - but I am also gay, unfit and my partner is/was in a wheelchair. Maybe you cant cover all those scenarios on one page, but why restrict WikiTravel to just 'able bodied 18-30 heterosexuals'?. I would have thought that the whole concept of a Wiki demands that all persons have a say in its production.

Again - the alternative is a Wiki for Gay travelers, disabled travelers, single females etc etc - the format is available here on 'WikTravel' for all of that to be covered - its just a simple link. Its such a simple thing to do - who here doesn't know what the rights of a disabled traveler to your city center is? You can share that info or not.

 * Yes, nobody's arguing with anything you just said. Maybe I was just being overly helpful in trying to point out to put 'general' info about GLBT travel into the Gay and lesbian travel topic page, and info that is specific to a certain destination on that page.

 * Regarding your above comment about the comment about cluttering up pages with all of those sections, if there's something very relevant for one of those groups then list it in the appropriate place on the page. The policy is simply saying not to create an entire section in an article for one of those groups. For instance, in Sudan you can be executed for homosexuality, so that's something you would want to mention in the "stay safe" section on the Sudan page. West Hollywood may have a hotel that is "gay friendly", so if that's relevant then mention that in the hotel's description, but there's no need to create a whole section of "gay friendly hotels", since heterosexuals likely stay at those hotels too.

 * But enough talking in generalizations, add some stuff you think is relevant, and if anyone disagrees or things it belongs in another place then we can talk about a solution then! :)  | (WT-en) Cacahuate 05:20, 16 January 2007 (EST)

 * Our policy for information for gay and lesbian travellers is that we want to have such information included in the main guide articles for a place, not spread out over several different articles. There are a lot of reasons: firstly, about 98% of what gay and lesbian travellers are going to do, they'll do the same as anyone else (go through customs, ride the metro, see the museums). There would be a lot of unnecessary duplication and redundancy if we had separate guides for gays and lesbians. Second, it's very easy to tag bars, restaurants, and hotels as gay-friendly, without separating them into a different section or guide. Most such establishments will also cater to other people, too. Thirdly, wiki works best when everyone is working on the same article -- not working on umpteen little personal articles.

 * That all said, I think that if there's some location that has so much information specific to one particular sub-group of travellers (travellers with children, senior travellers, disabled travellers, gay and lesbian travellers, women travellers) that it overwhelms the "general" destination guide with information that may not be useful at all to travellers not in that group, we may want to consider moving that info to a separate travel topic. We already do it with fields of pursuit, like Literary London and Off-road vehicles in California. I think we'd have to be careful to keep information synched with the main destination guide, however. --(WT-en) evanp 08:46, 16 January 2007 (EST)

LOL - and I'm off..... "How to p#s$ off the natives in one ez lesson" :)

I will leave the whole L&G thing for another day - I have spent most of my life in New Zealand so perhaps my time would be better spent at least starting the stubs for some of the amazing places we have down their :) Looking forward and beyond - Damian

"Queer" is totally weird here
It has unfortunate historical and other associations, and above all is not necessary. It can easily be substituted. Why bother to use the four-letter abbreviation at the top, then use queer? Tony  (talk)  03:55, 13 January 2013 (UTC)
 * It sometimes is added to the four-letter abbreviation to give LGBTQ, with Q as queer (used as a wildcard for various labels) or 'questioning'. Another common usage is T* where T is transgender and * is the wildcard as used in computer file naming, so TV, TG, TS... K7L (talk) 05:37, 13 January 2013 (UTC)
 * Where is this done? Not in the common parlance, or the mainstream press. If you're referring to arcane academic practices in the field of gender studies, I think that's not appropriate for the usership of this project. Why not choose a term and keep to it throughout, if for no other reason than textual cohesion? Tony   (talk)  06:00, 13 January 2013 (UTC)
 * Textual cohesion is good but difficult to achieve in practice on a Wiki without reverting to a committee drafted or Encyclopaedic style of writing. We do have some very good (if idiosyncratic) authors here and we have historically preferred a more florid and colourful style. "Queer" was (and still is in some places) a commonly used self-label. These fashions come and go. GLBT is short enough and inoffensive enough to take it's place, I agree. -- A l i c e ✉ 06:43, 13 January 2013 (UTC)
 * The standard abbreviation in the US in the 80s and still the abbreviation with the most Google results is LGBT, with the most politically correct version being extended to LGBTQIA . I'm sure we wouldn't want to use _that_ long abbreviation throughout. I vividly remember ACT-UP demonstrations where one of the standard chants was "We're here! We're queer! Get used to us!" But if "queer" is offensive in some parts of the world, it should be used in this article only in quotes, if at all. If it's not objectionable to ask, where is it purely offensive and not accepted at all by gay and lesbian communities? Ikan Kekek (talk) 07:03, 13 January 2013 (UTC)

 * I agree it isn't necessary. The meaning is conveyed quite well without it.  I also haven't heard of LGBTQ as a common expression.  --Inas (talk) 09:06, 13 January 2013 (UTC)
 * Ikan, yes, and as well as ACT-UP, there was Queer Nation, although its wide news coverage at the time belied the fact that it was a hoax! Nevertheless, I agree that GLBT would be a nice neat, cohesive and accessible way of expressing the concept. It's not only used in the US. Tony   (talk)  12:14, 13 January 2013 (UTC)

I've changed "Queer" to "Gay" or "GLBT" throughout. The positive usage of "Queer" is a niche usage among the highly politicized; unfortunately, the use as a disparaging term is still the most common usage in English. We're here to inform, not to create unintended offence or force language change. -- 212.126.151.188 13:20, 13 January 2013 (UTC)
 * You are correct. Ikan Kekek (talk) 20:33, 13 January 2013 (UTC)

Wikivoyage should have LGBT city articles
This policy page was written back in 2004, and should be reconsidered. First, Wikivoyage should accept LGBT guides for individual cities, such as LGBT Stockholm. There are already city guide articles with a demographic theme, such as London with children, and since many huge cities (New York, Berlin etc) are popular LGBT destinations, the LGBT information might drown in their massive articles. /Yvwv (talk) 14:33, 17 January 2013 (UTC)

 * My interpretation of this policy page is that it does not forbid LGBT-specific travel topics, like LGBT Stockholm. We may need to clarify this, though.

 * The guideline talks about not creating a specific LGBT section in the general travel guide for a destination, mainly on the basis that it makes the structure of the article too complex. Travel topics, which stand apart from the parent travel guide, are a different matter. As you point out, travel topics are well established. I don't think the people who formulated this policy intended to prevent the creation of LGBT travel topics in particular (hence the creation and continued existence of LGBT Stockholm).

 * I hope others weigh in with their own interpretations. Athelwulf (talk) 19:21, 17 January 2013 (UTC)
 * We, the community, make policy and we can clarify it. Why ever would you not have GLBT Stockholm (and linked clearly from our Stockholm article)? On a tiny, trivial point, it might be neater if we chose a standard abbreviation, (GLBT or LGBT) and then the name of the destination, for these topics. -- A l i c e ✉ 19:45, 17 January 2013 (UTC)

 * The fundamental problem would be the unrestricted import of policy pages. Policy needs to be made here on Wikivoyage. /Yvwv (talk) 23:48, 17 January 2013 (UTC)

 * I'm confident the policy is specifically intended to keep the information together. If by preventing a separate section in existing articles, we force an entirely new article duplicating much of the same information, then it certainly is a failed policy.  --Inas (talk) 00:10, 18 January 2013 (UTC)

 * I don't believe it's a failure of policy, any more than creating New York City with children was a failure of policy. I think the standardized article format is useful, and the policy of not allowing additional subsections to prevent unneeded complexity seems fair. Maybe it's not an ideal way of developing content, but is there a better way? Athelwulf (talk) 00:47, 19 January 2013 (UTC)

 * I would encourage gay-oriented city guides, travel topics or maybe sometimes itineraries, for much the same reasons I like articles like New York City with children and I wrote a separate Retiring abroad article rather than trying to add retirement info in many country articles. Any of these might be mentioned in a city article — both Toronto's "gay village" and its attractions for kids should be, for example — but they are of zero interest to many travellers so they should not overwhelm the main articles. Pashley (talk) 01:15, 19 January 2013 (UTC)
 * Spot on, Pashley! (Just as long as there is sufficient information right from the minute of creation and not a proliferation of bare-bone stubs). -- A l i c e ✉ 20:00, 19 January 2013 (UTC)
 * I'd say GLTB articles are pretty important to a not-inconsiderable proportion of en.WV readers, and should be included in the project. The issue then becomes, does the current policy on sex tourism present any problems for such articles? GLTB cultures are more overtly defined by sex (I don't mean gender, I mean sex) than non-GLTB culture in just about every society, I think. It's natural that GLTB night-spots in which sex might be a theme, for instance, will feature more often than in other articles. Tony   (talk)  13:28, 21 January 2013 (UTC)
 * The project:sex tourism policy seems to target primarily sex-for-money and underage activity as problematic. While I will disagree with the claim that "GLTB cultures are more overtly defined by sex (I don't mean gender, I mean sex)" unless you remove T - which has *everything* to do with gender - from that, there is no reason why an LGBT wiki expedition would need to generate the sort of content (such as dirty old men buying the favours of 14-year-old boys in third-world slums) which would cause trouble policy-wise. See Project talk:Sex tourism policy. K7L (talk) 13:58, 21 January 2013 (UTC)

[unindent to resume this discussion 7 years later:] The claim in this thread is that "The guideline talks about not creating a specific LGBT section in the general travel guide for a destination, mainly on the basis that it makes the structure of the article too complex." By that's not what the guideline says. Instead, it says this:

''However, we feel that sectioning off LGBT information is somewhat discriminatory – almost as if we're saying, "LGBT people go here, and the rest of us will go to all the other places on this page, where you're not welcome." Similarly, some attractions that are LGBT-oriented or LGBT-friendly are open to non-LGBT people, too. Segmenting those attractions off into an "LGBT" section would give the indication to non-LGBT folks that they're not welcome there, either. Travelers should be given information about events and attractions, and decide for themselves whether they want to go there.''

So if sectioning off LGBT information in one article implies segregation, that is surely more true when an entire article is separated.

I should say, I do consider "LGBT [Name of Place]" a legitimate travel topic, but nowhere in this thread do I see any attempt to deal with the segregationist implications of such topics.

In terms of complexity, though the word isn't used on the page, there is this:

Finally, there are any number of different kinds of travelers who may have special needs – senior travelers, travelers with children, disabled travelers, etc. Having different sections for each would make the destination pages unnecessarily cluttered, and would probably cause some duplicate information.

That would seem to be an argument in favor of a separate "LGBT [Name of Place]" article when the amount of LGBT information for a destination gets beyond a certain length. And the page does explicitly state that "Nothing in this policy precludes the creation of travel topics such as LGBT Stockholm." But I still think that raising the specter of discriminatory segregation when discussing merely a separate section within an article for LGBT and then permitting that information to be segregated into its own article is illogical, and if we are going to keep the guidelines the way they are, we should probably remove the paragraph about sectionalization amounting to discrimination. Ikan Kekek (talk) 07:33, 25 January 2020 (UTC)
 * I agree. No one actually sees "LGBT travel" as meaning "LGBT people go here, and the rest of us will go to all the other places on this page, where you're not welcome". It's a rather extreme position that gives merit to banning the use of "LGBT" altogether as "discriminatory", but it's a word (or rather acronym) that is actually used to help LGBT individuals find places that cater to them rather than to mark them to be ostracized. It takes a position of "inclusivity" that unintentionally promotes dismantling LGBT venues as "for everyone". While that is in fact the height of inclusivity, it ignores the fact that it is not "the rest of us" that benefit from the separation but rather the LGBT people. Their venues are not exclusive per se, but they actually do want to and need to maintain a predominant image of LGBT exclusivity in their venues in order to prevent them from becoming regular bars/clubs/etc. where you cannot easily find other LGBT people. It's well-intentioned but ill-thought logic, so I support getting rid of that part. ChubbyWimbus (talk) 10:37, 25 January 2020 (UTC)
 * Yes, well stated. Ikan Kekek (talk) 11:14, 25 January 2020 (UTC)
 * I agree as well. Just as you've said, LGBT establishments (by which I mainly mean bars/clubs) are typically sought out mainly by LGBT people, and so it's beneficial for them to be clearly grouped into a subsection of an article rather than having to read through a long set of listings looking for specific details in each one. And if allies want to go to an LGBT establishment, they are welcome to read that section and go to one of those places (and hopefully the listings would make it clear which places welcome allies and which places will give them the cold shoulder). Further, while we typically prefer to group the Eat section by price, that doesn't really make a lot of sense for the Drink section, and articles typically divide some other way such as "coffee / taverns / clubs", and having LGBT as a subsection of Drink doesn't hugely break that kind of categorization. --Bigpeteb (talk) 17:55, 27 January 2020 (UTC)
 * I support Ikan Kekek's proposal. Ground Zero (talk) 18:56, 27 January 2020 (UTC)
 * Bigpeteb, right now, there is no consensus behind a separate "LGBT" subsection in "Drink" sections. I wouldn't be opposed to it in the instance that there are a very large number of bar listings to navigate through, but we normally avoid long lists, right? That said, if you'd like to propose an end to the guideline against having such sections, please go ahead and make that proposal in a separate (sub)thread. Meanwhile, do you disagree with my proposed change in language in the interim? Ikan Kekek (talk) 19:10, 27 January 2020 (UTC)
 * I guess I didn't understand. What change are you proposing to the policy text? Apparently it wasn't clear to me what would be added/removed/changed. --Bigpeteb (talk) 23:52, 27 January 2020 (UTC)
 * The Information for LGBT travel section is at issue:

 * The Wikivoyage article skeleton templates don't have a "Gay" or "LGBT" section for travel articles. This is by design. Admittedly, it may be convenient for LGBT travelers to find all the LGBT-related information for a destination in one spot.

 * However, we feel that sectioning off LGBT information is somewhat discriminatory – almost as if we're saying, "LGBT people go here, and the rest of us will go to all the other places on this page, where you're not welcome." Similarly, some attractions that are LGBT-oriented or LGBT-friendly are open to non-LGBT people, too. Segmenting those attractions off into an "LGBT" section would give the indication to non-LGBT folks that they're not welcome there, either. Travelers should be given information about events and attractions, and decide for themselves whether they want to go there.

 * Finally, there are any number of different kinds of travelers who may have special needs – senior travelers, travelers with children, disabled travelers, etc. Having different sections for each would make the destination pages unnecessarily cluttered, and would probably cause some duplicate information.

 * I'm proposing to delete the middle paragraph. We'd end up with this:

 * The Wikivoyage article skeleton templates don't have a "Gay" or "LGBT" section for travel articles. This is by design. There are any number of different kinds of travelers who may have special needs – senior travelers, travelers with children, disabled travelers, etc. Having different sections for each would make the destination pages unnecessarily cluttered, and would probably cause some duplication of information.

 * Ikan Kekek (talk) 00:18, 28 January 2020 (UTC)

 * I just realized, this change was never made. It seems like there was no objection, so I'll make the change, probably within 24 hours, unless someone raises an objection. Ikan Kekek (talk) 07:10, 1 March 2020 (UTC)

 * Done. Ikan Kekek (talk) 09:36, 2 March 2020 (UTC)


text:
Wikivoyage talk:Interface issues

More than one way to skin a Wikivoyage
So, I've been thinking about the user interface on Wikivoyage, and I think there are some things that could stand changing or rearranging. As some may know, MediaWiki has a skinnable interface -- we can modify the UI to make it more customized to Wikivoyage. Writing a skin is hairy, but I'd make that effort if we had a good design to work with.

I have my personal beefs with the Cologne Blue skin for MediaWiki we use:

 * the confusing overabundance of links, and search boxes
 * the huge amount of dead space at the top of the page
 * the fact that the layout area doesn't have a prescribed width
 * there's no good place to put our logo
 * the color scheme doesn't go with the logo, anyways

I'm sure that lots of other people have things they'd like to see changed, too.

I'm wondering if people with HTML skills would be interested in doing a skin design contest. People could submit HTML mockups for a new interface, and we could discuss them and vote on them. We could take the top one or two or three candidates and make them into skins, and make the top one the default for not-logged-in users. Obviously, people could choose to continue to use the skin they want.

Would anyone be interested in this? I don't want to start a contest if nobody's gonna participate. B-) --(WT-en) Evan 16:32, 8 Mar 2004 (EST)

 * So, uh... let's just scupper this contest. Maj and I started working on a new skin this weekend; you can see the work in progress here. Any comments or criticisms are more than welcome. --(WT-en) Evan 13:48, 14 Mar 2004 (EST)

 * Yes, I like it and links are much easier to find. (WT-en) Yann 13:55, 14 Mar 2004 (EST)

 * Nice. I'd like to see the table of contents laid out like Cologne Blue ( ie a border, maybe a background colour )but it might not look good hard up against the navigation box on the left hand side. --(WT-en) Caffeine 16:01, 15 Mar 2004 (EST)

 * I just noticed that the signatures have EST time stamps - I guess that's EST North America (UTC-5), not EST Australia (UTC+10) or EEST Europe (UTC+3)? That's not a very clear naming scheme eh? --(WT-en) Caffeine 03:41, 16 Mar 2004 (EST)

Proposed new skin
Hi all, so as some of you know I've been working on a new skin for Wikivoyage. This one will let us switch style-sheets on the fly, and other users should be able to contribute their own stylesheets for it.

There's a demo installation of Mediawiki with my Wikivoyage skin here.

So far it only works correctly in Mozilla/FireFox and IE 6.x. I'm tuning it for KDE's Konqueror next. It might be reasonable to have user-selected stylesheets for other browsers, or perhaps I should work those into the main three styles. -- (WT-en) Mark 06:21, 30 Oct 2005 (EST)

title: Wikivoyage talk:Interface issues


text:
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 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), 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. 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 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:
 * 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, 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  link like this  is fine (but not See ), 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 Internal_links. 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: Have I got that right, please? -- A l i c e ✉ 02:10, 10 February 2013 (UTC)
 * 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 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.
 * 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 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? -- A l i c e ✉ 05:23, 10 February 2013 (UTC)

 * No, that's not the policy. We've had a 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 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.") -- A l i c e ✉ 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 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 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.-- A l i c e ✉ 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... -- A l i c e ✉ 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?
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)
 * 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
I know I can link to a section of an article from another article, for example Long Island, 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 will not work as this will jump to the same named sub section of "Get in".--Traveler100 (talk) 07:54, 11 January 2016 (UTC)
 * 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 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 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
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 : Airport_Expedition ) 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 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
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 Votes_for_deletion, 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 Creating emphasis. (A partial list is found at Shortcuts.) To make it easier for new readers to understand the discussions, shortcuts should use words instead of acronyms, e.g., for 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

 * as proposer. Ground Zero (talk) 11:57, 23 April 2023 (UTC)
 * , provided that shortcuts are still permitted in a non-raw format (i.e. something like " 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 Using talk pages ("Do not use shortcuts in discussions"), removing all shortcuts from all pages, and not making any changes to Internal links. Alalch E. (talk) 22:08, 23 April 2023 (UTC)
 * for reasons mentioned on the relevant VFD thread and my comment above. SHB2000  (talk | contribs | meta) 23:39, 23 April 2023 (UTC)
 * Writing out 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)

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

title: Wikivoyage talk:Internal links