Wikivoyage:Travellers' pub

From Wikivoyage
(Redirected from Pub)
Jump to: navigation, search
Welcome to the Pub

The Travellers' Pub is the place to ask questions when you're confused, lost, afraid, tired, annoyed, thoughtful, or helpful. To start a new topic, click the "Add topic" tab, so that it gets added at the bottom of the page, and sign your post by appending four tildes (~~~~)

Before asking a question or making a comment:

  • If you have a question or suggestion about a particular article, use the article's talk page to keep the discussion associated with that article.
  • If you'd like to draw attention to a comment to get feedback from other Wikivoyagers, try Requests for comment
  • If you want to celebrate a significant contribution to Wikivoyage by yourself or others, hold a party at Celebrate a contribution.
  • Discuss issues related to more than one language version of Wikivoyage in the Wikivoyage Lounge on Meta.

Pull up a chair and join in the conversation!

Experienced users: Please sweep the pub

Keeping the pub clean is a group effort. If we have too many conversations on this page, it gets too noisy and hard to read. If you see an old conversation (i.e. a month dormant) that could be moved to a talk page, please do so, and add "{{swept}}" there, to note that it has been swept in from the pub. Try to place it on the discussion page roughly in chronological order.
  • A question regarding a destination article should be swept to the article discussion page.
  • A discussion regarding a policy or the subject of an expedition can be swept to the policy or expedition discussion page.
  • A simple question asked by a user can be swept to that user's talk page, but consider if the documentation needs a quick update to make it clearer for the next user with the same question.
  • A pointer to a discussion going on elsewhere, such as a notice of a star nomination or a request to comment on another talk page, can be removed when it is old. Any discussion that occurred in the pub can be swept to where the main discussion took place.
Any discussions that do not fall into any of these categories, and are not of any special importance for posterity, should be archived to Project:Travellers' pub/Archives and removed from here. If you are not sure where to put a discussion, let it be—better to spend your efforts on those that you do know where to place.
QA icon clr.svg

Contents


Automating warning boxes[edit]

Hello!

As a (future at least) major source of information regarding travel we have a big responsibility to make sure that our guides provides accurate and up-to-date information regarding security information. As of now this is a manual process were any user can add the warningbox-template to articles. This can be quite tedious as a single warning might effect dozens of articles. For example the current outbreak of Ebola in West Africa should be added to all articles about places in Guinea, Liberia and Sierra Leone. As you all understand that takes a lot of time and more often then not articles are lacking important safety information.

So, what I think we should introduce is a script when a warning box i added to country/region all pages that's under it automatically get warning boxes too. As articles already is categorized by which region they belong it seems the same mechanism could be used for this.

However, they are of course some exceptions. For example we would have warning boxes regarding the current ISIL offensive on the Iraq page as well as all northern regions. But it makes no sense adding it to it's southern regions were we have more of a general warning. Those types of issues would have to be sorted out.

Overall, I do think this is quite an important issue to look into. Especially as Wikivoyage hopefully will be a major source for travel information. Jonte-- (talk) 12:04, 27 June 2014 (UTC)

This sounds like overkill. Consider a directly travel-related safety event like 9/11: Would you have added the same warning to absolutely every town in the US? I could see adding it to US, DC, and New York; I could maybe even see adding it to every US state, or possibly to every city containing a commercial airport (because airports were closed). But every single tiny little town? I don't think so. WhatamIdoing (talk) 15:41, 27 June 2014 (UTC)
We need to be careful to not position ourselves as an authoritive guide to travel safety, quite simply because we are a volunteer group and few of us (if any) are really in a position to speak with authority or update the relevant articles in a timely manner. Obviously we do it sometimes for major news events, but to automate the process and have warning boxes everywhere doesn't seem to be the right direction. Andrewssi2 (talk) 03:53, 28 June 2014 (UTC)
Also per the Reuters, South Africa have banned travellers from Guinea, Liberia and Sierra Leone. --Liuxinyu970226 (talk) 07:09, 22 August 2014 (UTC)

Travellerspoint[edit]

This group is doing work very similar to us. Have we reached out to ask if they are interesting in collaborating yet? Travel Doc James (talk · contribs · email) 09:51, 29 June 2014 (UTC)

Their terms of use are not extremely restrictive, however I would say restrictive enough to prevent much collaboration.
My amateur take would be that unless they also adopt a creative commons license then any such collaboration would be difficult. --Andrewssi2 (talk) 13:27, 29 June 2014 (UTC)
This is CC BY SA [1] Travel Doc James (talk · contribs · email) 02:08, 30 June 2014 (UTC)
It seems articles have the creative commons logo at the botton of each, but there is no reference to creative commons in the terms of use.
Is the presence of a logo (and nothing else) sufficient? (I really don't know the answer) Andrewssi2 (talk) 05:09, 30 June 2014 (UTC)
The example page at least now has the text "Except where otherwise noted, content of this article is licensed under a Creative Commons Attribution-ShareAlike 3.0 License" by the logo. Has it been added later? --LPfi (talk) 07:51, 9 July 2014 (UTC)
I'm all for collaboration here! It may not score as high on Alexa, but it's got a lot of convenient information. I'm thinking about WikiTravel, too - which ranks much higher than WikVoyage. Any ideas? Cheers, Horst-schlaemma (talk) 16:35, 2 September 2014 (UTC)
Please read Wikivoyage:Wikivoyage and Wikitravel. That's a website which has engaged in frivolous and vexatious litigation against our volunteers in the past, so does not represent a possible collaboration partner. Sorry. K7L (talk) 16:43, 2 September 2014 (UTC)
Alright, I see. A wondered for a while what this Wikivoyage-Wikitravel oxymoron is about. Well, then they should just dump it, huh... Horst-schlaemma (talk) 11:37, 3 September 2014 (UTC)

Promote via open projects?[edit]

One of this project's founders, User:EvanProdromou, went on to do several Open Source social networking projects; the current one is w:Pump.io. There are also several other projects aimed at building social networks not under commercial control; Forbes lists three; w:Diaspora (social network) is probably best-known. See also w:FreedomBox for a project aimed at wide deployment of small cheap home servers to make the net more secure and more under personal control.

To me it seems fairly obvious that the goals of these projects align with the goals of WV, WMF and open content projects in general, where the goals of Facebook and other commercial projects do not. This implies we should support the open projects wherever possible. Pashley (talk) 16:11, 30 July 2014 (UTC)

I completely agree that we should support open projects when we can. Promoting Wikivoyage is a plan to provide webcasts for chambers of commerce in the US explaining what Wikivoyage is and easy ways to keep their town current. My request for Facebook was to use a tool already in place to aid the chambers in asking questions. I didn't find any open projects to support my plan. If you know of some that would be appropriate, please message me?--Tbennert (talk) 02:53, 31 July 2014 (UTC)
Mainly, the WMF as well as WV are free content, not free software organisations/projects. Wikimedia projects do not have Twitter or Facebook accounts to support these services, but to promote themselves, and I don't think we should explicitely promote anything that is not related to the WMF itself.    FDMS  4    05:08, 1 August 2014 (UTC)
The WMF has been great about doing this kind of thing. I agree that Open Source and Open Content projects go hand in hand -- WMF's support of open protocols and open file standards has been above reproach. Is there a specific project we want to orient WV towards? --EvanProdromou (talk) 03:28, 6 August 2014 (UTC)

A resorts article?[edit]

Big resorts like Club Med are not my preferred type of destination, but they are very popular with some travellers. Areas like Montego Bay or the Yalong Bay area in Sanya seem to be mostly such resorts. We have an article on cruise ships, another all-inclusive way to holiday, and one on GLBT-friendly beach resorts. A search for "resort" turns up many Disney resorts and a few other things. A search for "Club Med" turns up many mentions but no article.

I'd say an overview article on such resorts would be a good idea. —The preceding comment was added by Pashley (talkcontribs)

It is certainly a useful travel topic. Resort holidays are popular, but I believe that an almost invisible percentage of WV's current readers and editors are people who frequent resorts. One just has to look at the state of our Caribbean articles, given the fact that they AFAIU are certainly not off the beaten path for North American visitors, the same goes for places like the Canary Islands, Spain's south coast and so on. Also, the status of our articles of cities towns and regions next to ski resorts, even the most popular ones in the Alps etc. don't reflect the amount of visitors they get. So we might very well even attract some new editors. I must admit I don't really have much experience of this kind of travel, either. ϒpsilon (talk) 16:45, 26 July 2014 (UTC)
Me neither, but yes, definitely a great idea for an article. Ikan Kekek (talk) 23:01, 26 July 2014 (UTC)

Neat idea. But please don't confuse it with the term Seaside resort that often refers to resort towns. Btw, how are you feeling about creating such an article on state-accredited resort towns? It's a crucial traveller's topic and many guides solely cover those. Cheers, Horst-schlaemma (talk) 14:10, 2 September 2014 (UTC)

That sounds like the situation with Cruising on small craft and Cruise ships, two articles with related names but little content overlap. They should link to each other so that if a search leads a user to the wrong one the problem is easily corrected, but other than that they can be developed independently.
The difference is that for cruising we have two articles, for resorts zero. Volunteers? Pashley (talk) 14:44, 2 September 2014 (UTC)
I'm not experienced with topic articles on Wikivoyage. But I'll definitely help to extend and create content for both a vacation resort and seaside resort town guide. Cheers, Horst-schlaemma (talk) 14:52, 2 September 2014 (UTC)
Answering a question from User:Horst-schlaemma on my talk page, I suggested this but am not volunteering to do it. I do not know much about such resorts and am not greatly interested in them. Pashley (talk) 16:29, 18 September 2014 (UTC)
Since there's nothing of magnitude at Wikipedia either, it could be a great project for the Wikivoyage community. -- Horst-schlaemma (talk) 18:57, 19 September 2014 (UTC)

Finding and adding Commons categories to articles[edit]

Hi, everyone. For the last few hours, I've been looking at articles I edited back in 2009 and seeing whether they have sidebar links to Commons. Many of them - surprisingly, including Philadelphia - did not. So if any of you would like a particular task to perform, that's a helpful one, and then if you feel like adding (more) photos from the selection you've found, you can do that, too.

One topic for additional discussion: For articles without corresponding Wikipedia links, we've been inserting a template showing that there is no Wikipedia link. Should we also be doing that for articles with no corresponding Commons link?

And a second topic for discussion: For articles on topics that have Wiktionary definitions, should we be linking the relevant Wiktionary page? Ikan Kekek (talk) 13:20, 31 July 2014 (UTC)

Regarding your two topics for discussion, Ikan: I think it's an excellent idea to add the template about Commons links, but doing the same for Wiktionary strikes me as overkill. -- AndreCarrotflower (talk) 14:20, 31 July 2014 (UTC)
(edit conflict) I've now got AWB set up and running through all the articles without commons links and automatically adding the commons link listed on wikidata, if there is one. If we do in fact want to tag the ones without, that'll be easy to do as well, just give me the word. As for Wiktionary definitions, I don't think we currently have it mapped so that those could be put in the sidebar automatically, but at any rate, I'm not very convinced of the utility of such a link anyway. Any definition that is related to travel should already be more than adequately covered here, and providing links for exploring the unrelated aspects shouldn't be any more important than ensuring we link to WP disambiguation pages, which is to say, it's out of scope. Texugo (talk) 14:22, 31 July 2014 (UTC)
That's great that you've got AWB set up to take care of Commons links automatically, although will it find non-identical matches, such as, say, Commons:Category Cityname, Countyname, Statename as well as identical matches? In terms of Wiktionary, I was thinking about looking for a definition for a term like Art Deco, or for that matter, Architecture. Ikan Kekek (talk) 20:42, 31 July 2014 (UTC)
Ikan, it will put exactly what has been entered into Wikidata as being the corresponding page on Commons, whatever that may be. If nobody has filled that data in yet, it skips over it and does nothing. Basically I just modified the routine I previously used to fill in the WP links/tags. Texugo (talk) 20:55, 31 July 2014 (UTC)
I just patrolled recent changes - great work on the Commons links! Little did I know that I should have just asked you to do this in the first place. :-) Ikan Kekek (talk) 21:22, 31 July 2014 (UTC)
I ran them through "Lu...". I'll try to get the rest of them tomorrow. Texugo (talk) 22:24, 31 July 2014 (UTC)
Nice work, Texugo! Pashley (talk) 17:58, 1 August 2014 (UTC)
Silly question, but shouldn't we be picking up the Commons link automatically from Wikidata rather than having to run a script? Powers (talk) 19:02, 1 August 2014 (UTC)
Not a silly question at all. I suggested long ago that we have a single, simple "sister links" template for all articles to automatically use the WP and commons links directly from Wikidata without our having to maintain them manually. I don't remember where that was exactly, but somehow I was under the impression that it was your opposition to the idea that ended up halting the discussion. I'd love to be wrong though. I've used such a template over on pt: for over a year now, and it's very nice not to have to mess with those things manually. Texugo (talk) 19:06, 1 August 2014 (UTC)

Proposal[edit]

  • Prototype template to automatically use the WP and Commons links as informed by Wikidata: {{sisterlinks}}
  • Can be put in all main namespace articles and in our article templates instead of maintaining the various links manually
  • Wikidata-reported links can be overridden manually by using wp= and commons= attributes.
  • Adds to Category:Articles without Wikipedia links for articles where WD reports no corresponding WP article. (Can be adjusted to do the same for missing Commons links, should we create a corresponding maintenance category for it)
  • Used experimentally at Hamamatsu.

Alternatively, since the language interwikis were made to appear there automatically, it seems like we should be able to request that WP and Commons links do likewise, in which case we wouldn't need any code in our articles at all. The drawbacks would be that it would be a little more complicated to override, and we wouldn't have a vehicle through which to manage the maintenance categories. Texugo (talk) 19:56, 1 August 2014 (UTC)

Just for information, in fr.voy, the links are managed by wikidata in the pagebanner template because it's the only template witch was already present on all the pages.--Adehertogh (talk) 20:57, 1 August 2014 (UTC)
Might be worth taking a look at mw:Extension:Wikibase Client#Other_projects_sidebar? It looks to be a one-line change to one of the server config files, listing which Wikidata links are wanted for the sidebar. No need to touch the actual articles. K7L (talk) 01:21, 2 August 2014 (UTC)
Ah yes, I guess that's what I was referring to in my alternate suggestion above. Note, however, that this method does not allow for overriding what is listed in WD. Texugo (talk) 01:41, 2 August 2014 (UTC)
Considering the links on WD were largely populated by our own data to start with, that may not be an issue. With the modification K7L mentions, though, would the Commons and Wikipedia links appear under "Languages" or under "Related sites"? Powers (talk) 02:04, 2 August 2014 (UTC)
According to the mediawiki.org page, the id of the sidebar is "wikibase-otherprojects". It doesn't appear under "languages". K7L (talk) 02:13, 2 August 2014 (UTC)
To be honest, I'm having trouble imagining any situation where we would want to have an article connected to a given data item but intentionally show a different WP or commons link. Unless somebody can present some case examples, I might be fine doing without a manual override. Texugo (talk) 03:30, 2 August 2014 (UTC)
There are some scope issues with the connection between Wikivoyage and Wikidata. From what I've seen, Commons and Wikidata both have a strong tendency to follow Wikipedia's lead when it comes to defining topics and divvying up locations, whereas we break from this tendency much more often to benefit the traveler. As an example, our article entitled Wasatch Range covers both the mountain range and the urban strip next to it more commonly referred to as the Wasatch Front. Wikipedia has a separate page for each, so of course Commons and Wikidata do as well. I'm not sure which set of sister links is best in this specific case, but it demonstrates the type of situation where we should want to at least have the technical capability to override Wikidata.
Thatotherpersontalkcontribs 02:44, 3 August 2014 (UTC)
Texugo, the Chiusure article is an example of intentionally showing a different WP and Commons link - in this case, to articles about the Abbey of Monte Oliveto Maggiore, which is usually the only reason that people visit Chiusure, but since we have the policy of not giving abbeys their own article, and furthermore, some of the accommodations within town limits are at a convent and an agriturismo place, it is quite right for us to have an article under the name of the village and not the abbey. However, since last I checked, neither WP nor Commons have topics on Chiusure but both have topics on Monte Oliveto, I strongly believe that's a close enough topic match to post the links. Ikan Kekek (talk) 03:26, 3 August 2014 (UTC)
Wikidata also has the dmoz property. Should this also be included in the template? -- WOSlinker (talk) 12:37, 3 August 2014 (UTC)
I'm not sure what to make of dmoz - presumably there would be a different DMOZ page for each language (so dmoz.org/Regional/Europe/United_Kingdom/ becomes dmoz.org/World/Français/Régional/Europe/Royaume-Uni/ and others in other languages). Can we assume P998 DMOZ always points to the English-language DMOZ category? If so, a template would work while adding DMOZ to a server configuration file as a "sibling" would not. K7L (talk) 16:04, 3 August 2014 (UTC)
One other oddity with commons; there are two plausible ways targets to link there: the main space (rarely used, unless someone manually makes a gallery page for one topic) and the category space. Wikidata seems to prefer linking to mainspace for some reason; a template could make either link. K7L (talk) 04:32, 13 August 2014 (UTC)
Sorry, I kind of blanked on this one. Ikan and Thatotherperson, those are convincing enough examples of why we would want to retain override control, so that looks like another advantage to the template approach proposed above. Are there any other concerns that should be addressed? Is there any convincing reason not to automate this with a template? Texugo (talk) 20:18, 12 August 2014 (UTC)
I'm totally good with standardizing this template, with the possibility of a manual override. Ikan Kekek (talk) 03:09, 13 August 2014 (UTC)
K7L, I'm not completely sure I know what you mean by mainspace and category space. I think what you mean is that there is usually a category for a particular subject on Commons, but occasionally (probably less than 10% of the time), there is instead a non-category page, instead. Is that what you mean? When I've posted Commons links, I've always chosen the non-category page when there was one. Ikan Kekek (talk) 04:44, 16 August 2014 (UTC)
There are two ways to store a link to Commons in Wikidata. The #sitelinks-commons section of the standard Wikidata page links to a commons page, not a commons category. d:Property:P373 links to a commons category. If there usually isn't a non-category page, we do need to be able to fall back to the P373 property, which is a category link, using a template. K7L (talk) 12:52, 17 August 2014 (UTC)
Ah, you're absolutely right, K7L. That hadn't occurred to me. I think when I originally created this for pt: there was at that time only one property being used for this. It should be quite easy to set up the template to fall back on the category like that. Don't know if I'll get to it immediately, but I can take care of it. Texugo (talk) 15:04, 17 August 2014 (UTC)

Article subheadings[edit]

A proposal: Should the subheadings under "get in" and "get around" be changed to match Wikivoyage imperative style, ie:

  • By car → Drive
  • By air → Fly
  • By train, by bus, by camel → Ride (by train, by bus...)
  • By horse → Trot, Jump, Gallop
  • By bicycle, by motorcycle → Bike
  • By sea, by ferry → Sail
  • By public transit (subway, taxi, streetcar, rickshaw) → Ride

It would make us look a little more different from other travel guides, but I'm unsure if there's a better word than "Ride" for the numerous public conveyances. K7L (talk) 18:47, 31 July 2014 (UTC)

The enforcers of British English will hate "Ride," because they change phrases like "cab ride" to "taxi journey" all the time. But I disagree with putting all these disparate forms of transportation under "Ride," too. Ikan Kekek (talk) 20:45, 31 July 2014 (UTC)
Should we collect basically all forms of land transportation where someone else is controlling the vehicle under a single "Ride" heading? I don't think it would be a smart idea at all. ϒpsilon (talk) 20:58, 31 July 2014 (UTC)
We should not. The heading for bus and train should be "Take the bus" and "Take the train" if they need to be imperatives for some reason. 2001:5C0:1000:A:0:0:0:100F 22:52, 31 July 2014 (UTC)
A 'ride' to me implies something done for fun, rather than utilitarian transportation. Linking motorcycles and pushbikes is also unhelpful. I like the idea, but the fact seems to be that there aren't imperatives to match each of the modes of transport. --Inas (talk) 23:03, 31 July 2014 ( TC)
I don't support any change at this time. I don't think any of the suggestions above would do anything but make the headings more cumbersome. Texugo (talk) 23:05, 31 July 2014 (UTC)
The imperative is in the heading "Get in", and "by ..." is the right qualifier eg "Get in by train". Also "ride" is a verb I am more likely to use for a bike than a train. It would be far better to spend the time improving the information in "Get in" in some articles - too many articles have only one way of getting in when others are available. AlasdairW (talk) 23:18, 31 July 2014 (UTC)
What is the actual benefit in changing subheadings to imperatives? Copying WP style for the sake of it doesn't actually help us. I recall there was some discussion before that changing subheadings 'may' improve SEO results. Andrewssi2 (talk) 01:32, 1 August 2014 (UTC)

<indent reset> But really, there are so many different things to put our attention and effort to. This particular proposal doesn't hold water for the reasons mention above, and our current headings do serve us well. New, better, original content not only "may", but does help our SEO, and it helps bring in and retain readership and generate positive buzz with a snowball effect. There are still many articles on important destinations that are quite shambolic. PrinceGloria (talk) 15:14, 1 August 2014 (UTC)

For SEO, it would be far better to change headings so that they contained likely search terms. get in->transport to & from, get around->local transit, eat->restaurants, sleep->hotels, etc. There would be problems with that, & details to be worked out, of course.
From that viewpoint, using "ride" would be appallingly stupid, replacing several fairly common search terms with one no-one is likely to use. Pashley (talk) 18:11, 1 August 2014 (UTC)
Although I agree that is what 'should' happen with SEO when changing articles headings, do we have any actual evidence that it would? Andrewssi2 (talk) 00:36, 4 August 2014 (UTC)
Here is a link to an experiment last year. As far as I can tell it didn't succeed, although the sub headings that were chosen were probably not the wisest choices if they were looking to improve SEO. Andrewssi2 (talk) 00:44, 4 August 2014 (UTC)
That experiment was, I think, mainly to see if making section headers different from WT improved search engine rankings, presumably mainly by avoiding the penalty the engines apply to duplicate/copied content. User:W. Frank who created the page thought it showed evidence of success.
As I see it, the headings chosen there were remarkably bad for SEO, probably because he was trying to stay with our policy of using verbs. Changing Eat to Dine. for example, is dumb but harmless. Things like Buy to Spend up! or Drink to Quench are worse; they remove somewhat likely search terms and replace them with even less likely ones.
I'd say drop the policy of using verbs (which was an arbitrary, if reasonable, choice anyway) and make changes aimed mainly at getting likely search terms into headings. Pashley (talk) 01:58, 4 August 2014 (UTC)
I'd happily run an experiment at Xiamen if others think that is a good idea. 02:03, 4 August 2014 (UTC)
There's nothing inherently magical about using verbs. We used them originally because we thought it'd make us look different from other travel guides, supposedly? If so, their existence on both WT and WV (with just "connect" and "go next" as minor differences) defeats that objective. We're no better off with these than with the stock (attractions, activities, shopping, restaurants, nightlife, accommodation) standard header set from any printed guide. K7L (talk) 02:36, 4 August 2014 (UTC)
If the only reason to do this is to 'look different' in a minor aesthetic sense, then I'd say the change isn't particularly compelling. High effort, near zero benefit. Andrewssi2 (talk) 02:45, 4 August 2014 (UTC)
If there's the suspicion that this might help SEO, and anyone prefers to put their energy in this rather than one of the countless other tasks on this site, I see no reason to not try. Why can't we just repeat the test Frank tried to do with more likely search terms? What's the harm? JuliasTravels (talk) 11:32, 4 August 2014 (UTC)
I support Pashley for his proposed experiment article above. Andrewssi2 (talk) 11:58, 4 August 2014 (UTC)
I don't oppose an experiment with likely search terms, but I don't think Pashley's suggestions above (Ride, etc.) are quite worthy of even testing. I don't think testing will produce respectable, actionable results unless we:
a) use likely search terms - "Ride" or "Gallop" are less likely search terms than we currently have
b) use terms which could be substituted without tedious reorganization of the content of every article - i.e. neither "Bars" nor "Nightlife" could be used in place of "Drink" because that section often contains other things as well (cafés, info on water quality, local specialty beverages, etc.); neither "Restaurants" nor "Cuisine" are a good replacement for "Eat" because it contains info on both, etc.
c) run the same test on a group of articles - Since SEO rankings tend to vary over time and depend on many other factors as well, an arguably positive result on a single article is not going to convince me anyway. The test, the exact same changes need to be implemented on a number of articles, say at least 10 or so, including destinations of different types (popular searches, less popular ones, different sizes, region/city, etc.).
If we do all the above and the overall results demonstrate a quite significant improvement across the board, only then might I be inclined to think this type of change to be worth the trouble. Texugo (talk) 12:22, 4 August 2014 (UTC)
That makes sense. Any ideas on which search terms would be best? We have over 25000 articles and these experiments don't make them less useful for a traveller to any specific destination. We could even have 2 or 3 groups of articles to test different headings, if we'd want. I'd say as long as we document the experiments well, so they don't end up forgotten, it's all no problem. And then how long should we wait to have results that can mean something? JuliasTravels (talk) 12:38, 4 August 2014 (UTC)
Personally, I'm rather attached to the headers we have and skeptical that such a change will make a difference that's worth the effort, so while I don't necessarily oppose such testing, I don't feel very compelled to push it forward either. Texugo (talk) 12:51, 4 August 2014 (UTC)
I did not suggest Ride; in fact I pointed out that it was a bad choice for SEO.
I will go ahead with an experiment; see Talk:Xiamen for details. Pashley (talk) 14:56, 4 August 2014 (UTC)
Oh, sorry. My mistake. But what headers do you plan to use? And why bother with such a necessarily long-term experiment on only a single article, knowing that results from only a single page will not be reliable or scientific enough to convince everyone of its effectiveness or lack thereof?
Why not do this:
  • first, come up with a workable set of replacements
  • implement them as suggested above in a variety of different articles, at least 10 or so
  • choose another equal number of comparable articles as control articles (which don't implement the proposed change)
  • put all the starting stats in one place for tracking, say, a subpage of Wikivoyage:Search Expedition
  • track the stats for all, monthly, for a few months
  • see how it goes
Yes, it's more work, involving 20 or more pages etc., but at least I might believe you when you come back months hence and tell me whether it works or not. Texugo (talk) 15:13, 4 August 2014 (UTC)
I agree we probably need to do all that eventually. Talk:Xiamen#Headings_experiment is initial exploration. 15:57, 4 August 2014 (UTC)

Interwiki link leads to disambiguation page[edit]

Yuryev-Polsky leads to w:en:Yuryev-Polsky, which is a disambiguation page. Can this be fixed? I'm not sure which of the pages to link it to. WhatamIdoing (talk) 02:25, 5 August 2014 (UTC)

It seems to have already been fixed. Texugo (talk) 02:34, 5 August 2014 (UTC)
Incidentally, there is actually a category full of these cases waiting to be fixed. They have to be fixed both in the manually inserted Wikipedia link at the bottom of the articles here and on Wikidata as well. Texugo (talk) 02:45, 5 August 2014 (UTC)
Can you give me a pair of diffs showing how to make these changes for an article? WhatamIdoing (talk) 16:31, 8 August 2014 (UTC)
Well, to fix the WP link on the article here on the WV side, just edit the article, go to the bottom where the link is, and change it from [[wikipedia:Wrong article title]] to [[wikipedia:Right article title]]. However, that's not all there is to it, since it will likely still be connected to the wrong Wikidata item, and unfortunately I can't show diffs for that. There is more than one way to do it too, but you can follow the Wikidata item link from the left column, remove the en:wikivoyage link from that item, and find the wikidata item for the correct WP (I usually go to the correct WP article first and follow the left-column WD item link), and add the en:wikivoyage link there. Texugo (talk) 17:26, 8 August 2014 (UTC)

Guide articles lacking pagebanners[edit]

Hi, everyone. I believe that all Guide-level articles should have custom pagebanners, but right now, 97 do not. So your mission, if you choose to fulfill it, is to create pagebanners for one or more of these Guides. While we're at all, adding at least one well-chosen photo for the body of the article, if there isn't already one there, would be a great thing to do as well. Ikan Kekek (talk) 13:21, 5 August 2014 (UTC)

UserMerge permissions removed[edit]

Hi,

Today we removed the "usermerge" right from all bureaucrats on Wikivoyage. The UserMerge extension was used during the transition period when some users had two accounts and this let them reclaim their contributions. However, it has not been used for some time, and was blocking the eventual m:SUL finalisation, in addition to possibly causing database inconsistencies. If a user must be merged, you can contact m:User:Hoo man for assistance. Please let me know if you have any questions or concerns on my meta talk page.

Thanks, Legoktm (talk) 14:58, 7 August 2014 (UTC)

This really should have been raised here *before* breaking things, instead of merely presenting this after the fact as a fait accompli. K7L (talk) 15:04, 7 August 2014 (UTC)
This has still been used occasionally, including quite recently. This is a bad move, and should be reversed. Ikan Kekek (talk) 18:12, 7 August 2014 (UTC)
While it has been used somewhat recently, it's pretty rare. If it was blocking SUL finalization, then it has to go. The chances of someone with an editing history (significant enough to make merging worthwhile) finally coming by after nearly two years are pretty slim, and if it does happen, we can talk to User:Hoo man. Powers (talk) 21:33, 7 August 2014 (UTC)
If people would like to know what's going on, they should subscribe to m:Tech/News. There are more than a dozen developer teams (involving both volunteers and paid staff) supporting 800+ wikis in about 300 languages. Realistically speaking, they cannot separately raise all issues "here" for every change. However, they do make general announcements for many things, and they often contact directly affected groups (in the case of SUL, the global stewards, who are getting stuck with all the extra work). WhatamIdoing (talk) 16:55, 8 August 2014 (UTC)
The usermerge issue affects Wikivoyage specifically in a way that it doesn't affect all "800+ wikis in about 300 languages" because of a quirk in this project's history. We have a mess of imported edits from (WT-en) and (WV-en) users that no other Wikimedia project (outside WV) has, so we have a greater need to merge users. The same would be true if a change were to specifically affect a Wikivoyage-specific extension (RelatedSites, RelatedPages, Insider, MapSources) that no other WMF project uses. WV, and not just the global stewards, is a directly-affected group. K7L (talk) 17:20, 8 August 2014 (UTC)
Even so, there's 16 Wikivoyages, most of which used that extension... --Rschen7754 03:21, 10 August 2014 (UTC)
...a far cry from 800 wikis. How much of Wikivoyage:User account migration and Wikivoyage:Changing username is incorrect now? K7L (talk) 03:43, 10 August 2014 (UTC)
...and this is far from that team's only task. As I said, if you want to know what tech issues will affect this community, you need to be looking out for changes, not assuming that the devs will bring everything to you in advance.
Also, as a practical matter, if your bureaucrats aren't worried about a change to a tool whose use was "somewhat rare", then you probably shouldn't worry about it either. The work can still be done, just not in the old way. WhatamIdoing (talk) 16:03, 11 August 2014 (UTC)
That's a fairly condescending attitude that I, for one, don't appreciate. Regardless of whether the bureaucrats are concerned or not, I think the points raised by the rest of the community are quite valid. -- AndreCarrotflower (talk) 16:20, 11 August 2014 (UTC)
I'll just chime in to say that, having worked on various software projects, I understand & fully support WhatamIdoing's comments above. There is no need at all for a tempest in this particular teapot, and anyone who cares about other changes should be reading m:Tech/News. Pashley (talk) 16:59, 11 August 2014 (UTC)
This is a very small issue, compared to recent events happening elsewhere on Wikimedia... --Rschen7754 03:50, 12 August 2014 (UTC)
  • It seems that there will soon be a tool to merge global accounts (see mw:SUL finalisation/Global account merge), so I assume that users simply will have to wait until that tool is available and then request a global merge. --Stefan2 (talk) 10:39, 7 September 2014 (UTC)

Change name of Category:Articles needing attention[edit]

Does anyone object if I change the name of Category:Articles needing attention, to make it a more accurate description of what it contains? It contains categories regarding not only articles but also files, categories, and other non-article pages, and there are some types of maintenance categories which should not necessarily imply that their contents need direct or immediate attention. I think something simpler like Category:Maintenance would be better. (Note that this change wouldn't show up anywhere except on the maintenance category pages themselves.) Texugo (talk) 11:31, 8 August 2014 (UTC)

I see no reason to change this. We have a long history of not using categories at all, having adopted them on any real scale only in the last year or two and then only to facilitate carrying out specific maintenance tasks. The current naming reflects this. K7L (talk) 14:01, 8 August 2014 (UTC)
This category has been around since 2006. Are you sure you aren't being a bit obstinate because of our other disagreement? The current name does not reflect inclusion of categories, files, etc., and there are a couple of other maintenance categories which are homeless simply because they do not technically fit with this name. What is the harm in making it accurate? Texugo (talk) 14:07, 8 August 2014 (UTC)
I am fine with either name, and I find categories very useful. I believe that "we have a long history of" should never be an argument in any discussion here, btw. We should do what is the best and most logical, and continue to evolve to serve the travellers best. Articles and other pages and features do need attention and maintenance, an categories, even if hidden from the reader, can be very helpful with that. PrinceGloria (talk) 14:15, 8 August 2014 (UTC)
The name "Articles needing attention" has a specific meaning. We don't create categories here for the sake of creating them; a category like "telephone numbers with missing country codes" is a request to the user to plunge forward and fix the problem. The same is true of other items in "articles needing attention"; the name and purpose is by design. K7L (talk) 17:29, 8 August 2014 (UTC)
Nobody is creating categories for the sake of creating them. We include Category:Has default banner, but we have to exclude Category:Has custom banner and Category:Has standard banner because they don't require direct attention. And we've included files and categories here, but they are not articles needing attention. Why would you be so attached to such an inaccurate name which excludes similar maintenance categories the user might be interested in? Texugo (talk) 17:38, 8 August 2014 (UTC)
The banner-related categories are requesting user attention, implicitly; they're asking users replace default banners with custom banners. Nothing neutral about that. K7L (talk) 17:46, 8 August 2014 (UTC)
You missed the point, which is that only one out of the set of three categories appears there, excluding the other 2 since they two do not technically "need attention" despite their usefulness in maintenance. I still see zero advantage in keeping a limited, outdated moniker which does not group all the maintenance categories together. Texugo (talk) 18:23, 8 August 2014 (UTC)
I don't think I really understand your concern, K7L. It seems to me that making the category-name more general (like Texugo is proposing) will rather make extra categories redundant and thus supports your overall goal of limiting the use of categories? I'm not particularly bothered by using this category also in cases where the name is not 100% accurate, but if Texugo wants to change it to better fit the content, that's fine with me. JuliasTravels (talk) 20:49, 8 August 2014 (UTC)
`Attention needed`, would maybe be a good name for it? (Ypsilon) 213.176.149.177 22:09, 8 August 2014 (UTC)
That would be slightly better than the current title, but still wouldn't be appropriate for the maintenance categories which do not actually need direct attention. Texugo (talk) 22:58, 8 August 2014 (UTC)
I suggest Category:Maintenance categories. One advantage is that it makes it clearer that the category should not directly contain any pages. One disadvantage is that all of its subcategories will refer to Pages, which disrupts the usual category semantics. Powers (talk) 00:14, 14 August 2014 (UTC)
Don't all of our hidden categories exist just for maintenance purposes, including the geographical hierarchy? K7L (talk) 02:58, 14 August 2014 (UTC)
In a sense, mostly, but there is of course a difference between the nested category tree which keeps the geographical hierarchy in order and the set of categories which directly group pages because they share a given property. If that distinction is actually important, I suppose we could call the latter Category:Tracking categories, in keeping with the already existing Special:TrackingCategories. I would be fine with Category:Maintenance categories as well, but now that it occured to me, I think Category:Tracking categories would be the best solution. Texugo (talk) 14:48, 14 August 2014 (UTC)

Dynamic map templates[edit]

According to Nemo_bis comment on meta there's a privacy violation with the use of current dynamic maps (and all the equivalent templates on each voy language version).

Please take part to the discussion to understand how to proceed in a coherent way within the whole wiki-project. Thanks, --Andyrom75 (talk) 05:31, 9 August 2014 (UTC)

As I suggested over there, there is a replacement called WikiMiniAtlas that can possibly be used. However, this is a serious issue that should be addressed ASAP. --Rschen7754 01:15, 14 August 2014 (UTC)

A mobile app with Wikivoyage content - more publicity for us![edit]

Someone is interested in using WV's content in a mobile app. I think it sounds really cool not to mention that it's something that would get more people familiar with Wikivoyage. However he is confused about licensing and attribution. Someone more knowledgeable about it should reply to him ASAP. ϒpsilon (talk) 15:47, 11 August 2014 (UTC)

DotM banner for Karachi[edit]

I have combed through Commons, Flickr, and locally-hosted material on Wikipedia and have not found one single CC-compatible image of Karachi that's high-quality enough or dimensionally appropriate to use as a banner. I don't know if this is a freedom of panorama thing or what, but to my knowledge this has never happened before with a DotM nominee and I'm at a loss as to what to do here. Any help would be greatly appreciated. -- AndreCarrotflower (talk) 19:30, 11 August 2014 (UTC)

Saqib, some time between now and October would you be able to take some appropriate photos yourself and upload them to Commons? -- AndreCarrotflower (talk) 19:34, 11 August 2014 (UTC)
Sidebar: going forward, should we weigh the availability of suitable banner images as a factor in supporting or opposing feature article nominations? -- AndreCarrotflower (talk) 19:42, 11 August 2014 (UTC)
The couple of photos currently in the article are indeed of a surprisingly low resolution. Saqib has taken good photos for Mohenjo-daro and other destinations. I think he would be happy to take some nice photos for Karachi's DotM banner.
Concerning your suggestion about availability of banner images - I hate to say it but without a Main Page feature banner I guess we cannot feature it. Tangentially, I think it was Ikan Kekek who recently suggested articles should have a custom banner in order to be eligible for Guide status (which, in turn, is a requirement for featured articles). If I'm not mistaken, banners for the article itself must have a higher resolution (at least 2100px wide) than what is required of the feature banners. Now that would solve all the problems, if we're desperate we could use the same photo for the feature banner as for the article's own banner. ϒpsilon (talk) 19:53, 11 August 2014 (UTC)
The pagebanner itself looks like it may well have been a last-resort selection: [2] -- AndreCarrotflower (talk) 19:58, 11 August 2014 (UTC)
Hey, it's one of Ypsinardo da Vinci's first banners! :D ϒpsilon (talk) 20:03, 11 August 2014 (UTC)
(editconflict) Well, we could start with just holding off on an otherwise accepted destination until someone has found a suitable picture, as in, not putting in the slot. If we really can't come up with anything over some time, we can discuss how to proceed. The promise of a feature might make it easier to persuade copyright holders to change the license for cases where suitable pictures are available but use is restricted.
If all else fails, I suppose I would incidentally find it acceptable to use a picture of a more general nature, even when it was not taken at the destination itself, if it represents the atmosphere of the place. Say, a colourful bazaar for a Moroccan city, or something. In the case of Karachi, it would be nice if Saqib happens to be in the area. If not, it might be good news that Wiki Loves Monuments will have a Pakistani edition this year in September. If we are to wait for that however, we might want to move the feature a few months further along the line, to not put pressure when it's not needed. JuliasTravels (talk) 20:05, 11 August 2014 (UTC)
Ypsi: your suggestion was unexpectedly productive. To my great surprise, the source image for the pagebanner actually makes for a mighty fine DotM banner. Check it out. It would still be great if Saqib could go out with his camera and take some banner photos himself, but at least we have a fallback option in case all else fails. -- AndreCarrotflower (talk) 20:12, 11 August 2014 (UTC)
Nicely done, AndreCarrotflower! :-) JuliasTravels (talk) 20:14, 11 August 2014 (UTC)
Yep, that definitely works. In terms of your question above, Andrew, yes, it would be perfectly reasonable to provisionally oppose featuring an article, pending the availability of a suitable file for creating a banner. Ikan Kekek (talk) 20:17, 11 August 2014 (UTC)

(edit conflicts...) Elegant banner, Andre! And Julia, Saqib lives in Karachi (I think) and he has really put a ton of effort into the article so we will probably have a couple of nice photos to choose among in the next couple of weeks. ϒpsilon (talk) 20:21, 11 August 2014 (UTC)

Surprised to see a thread has been started about Karachi. I'm sorry for not being very active on Wikivoyage as I'm busy with organizing the world's largest photography competition in Pakistan this September. I can imagine, Commons soon going to host thousands of CC-licensed photos from Pakistan including of Karachi. Andrew, can you wait for just 3 more weeks and then you'll have plenty of beautiful high quality photos to choose from otherwise if you're in hurry, I can take some photographs but I think its worth to wait. --Saqib (talk) 20:26, 11 August 2014 (UTC)
Saqib: In a few minutes, I'm going to place the banner that I created for Karachi on the banners page, with a blurb summarizing everything said here for those who haven't followed the discussion. In three weeks' time, when the new Pakistan photos materialize, we can make a second, third, and fourth banner (or maybe more) and choose between them. -- AndreCarrotflower (talk) 20:35, 11 August 2014 (UTC)
Sure Andrew. You've created a nice banner but I bet you're going to see many beautiful photos once the Wiki Loves Monuments Pakistan take off on September 1st. --Saqib (talk) 20:38, 11 August 2014 (UTC)

Attention native speakers of Canadian English[edit]

Other than districting Buffalo, my main project on Wikivoyage has been elevating the Gaspé Peninsula to Guide status with a view to nominating it for OtBP sometime next summer. The first phase of that project is complete - namely, expanding the Gaspé Peninsula article itself, with a mixture of material translated from fr: (where it is a star article) and my own experiences visiting there in 2012.

en:'s policy is to write articles in the same dialect that is spoken in the destination. Though I am familiar with Canadian English, as an American it's not my native dialect, so I may have slipped up and forgotten a "u" here and there or whatnot. Could someone who is a native speaker of Canadian English (Pashley? K7L?) perhaps take a look at the article and correct any oversights on my part? Also, if there's anyone native to the area (Amqui?) who might review the article's factual accuracy, that'd be great too.

-- AndreCarrotflower (talk) 14:32, 14 August 2014 (UTC)

Looks like you've added a huge amount to the article, thanks. Our coverage of Québec is sporadic at best - even on fr: - once one leaves the Ottawa-Montréal-Québec City beaten path. Distances are "metre" and "kilometre" (a "meter" is a measuring device, such as a voltmeter, water meter or parking meter) and the St. Lawrence River runs from the western tip of Wolfe Island to Pointe-aux-Pères, just past Rimouski. Anything further downriver would be in the Gulf of St. Lawrence. The claim that "Anticosti is part of the north shore" reads strangely, as Anticosti is an island. Maybe it should have its own "go next" entry. I suppose the real (huge) task will be getting the individual articles under Gaspé up to 'usable' status? K7L (talk) 15:34, 14 August 2014 (UTC)
Running a Microsoft Word spellcheck for Canadian English turned up nothing in particular. Texugo (talk) 15:55, 14 August 2014 (UTC)
That should flag "kilometer" (sic) but won't find instances of "meter" used instead of "metre" or "check" used instead of "cheque" as these are valid English words... which just happen to mean something else. There's a joke, something like "My spelling is purr fact in every weigh. My spell chequer told me so," which plays on exactly this. K7L (talk) 17:12, 14 August 2014 (UTC)
Well, of course I know that. But at least it Word spellchecker will catch a common lot of things like those U's mentioned. I wasn't saying that checking is done, only that it's started. Texugo (talk) 17:43, 14 August 2014 (UTC)
To K7L: That is indeed the next step, but I don't know how "huge" it will be. The requirements for Usable status in city guides are actually pretty lenient: a Get In section and at least one listing each in See, Eat and Sleep. I'll very likely go above and beyond for many if not most of them, but at a basic level I could probably do two or three of those in a day. -- AndreCarrotflower (talk) 17:24, 14 August 2014 (UTC)
I have had a look and see no problems. That may not mean a great deal, though, since my English has been influenced by dialects other than my native Canadian. Pashley (talk) 21:33, 16 August 2014 (UTC)
I wrote the star article on fr: I will review this article for content. Amqui (talk) 18:28, 28 August 2014 (UTC)
I added my suggestions on the Talk page of the article, nothing wrong with the content, just some suggestions about couple things to add. Thank you very much for this beautiful article! I will help develop pages for cities and sub-regions in English, I already created most of them in French by now. Amqui (talk) 19:17, 28 August 2014 (UTC)

We would need to find how we translate "Bas-Saint-Laurent" (the region next to Gaspé peninsula). On the Gaspé Peninsula page both "Bas-Saint-Laurent" and "Lower St. Lawrence" are used. The page Bas-Saint-Laurent translate it by "Lower Coast". In my opinion Lower St. Lawrence is a far better translation, I never heard Bas-Saint-Laurent referred as a "Coast" and I grew up there. The official tourist website doesn't translate the name [3] and use "Bas-Saint-Laurent" in English (but this is to be expected I guess from any regions in Quebec), I think using Bas-Saint-Laurent as the name of the page on English Wikivoyage, as it is now, is the good way, but I think the translation offered should be "Lower St. Lawrence" and never "Lower Coast". Termium, the website from the Translation Bureau of Canadian Government also translate by "Lower St. Lawrence" [4]. I wouldn't oppose to use "Lower St. Lawrence" as the name of the page either, this is English Wikivoyage after all, not French. Amqui (talk) 19:45, 28 August 2014 (UTC)

I'm moving this to the talk page of Bas-Saint-Laurent. Amqui (talk) 15:10, 29 August 2014 (UTC)

Images in infoboxes?[edit]

Does Template:Infobox allow editors to insert images inside infoboxes? If so, how? -- AndreCarrotflower (talk) 21:06, 16 August 2014 (UTC)

It can be made to work. I did one at Ouro Preto. I think there are others too, but can't remember where I've seen them. Texugo (talk) 21:16, 16 August 2014 (UTC)
You can even insert many!. :) ϒpsilon (talk) 21:28, 16 August 2014 (UTC)

New maintenance tag proposals[edit]

I have been doing a lot of work correcting mistakes and oversights in the breadcrumb trails/geographical hierarchy, and I have identified a need for two new maintenance templates which I think would help us track and draw attention to problems in this regard. Below:

1: {{vagueregions}} - This tag can be used for regions where the regional breakdown does not have its borders defined well enough for someone unfamiliar with the region to ascertain which region a given destination should be categorized under. Often a region may be divided into Northern/Southern/Eastern/Western/Central or X Valley/Y Lake Area/Z Mountains, with no map and no discussion of where the boundaries between those regions should be drawn. Other times, someone may have started a few subregions for part of the area but there are gaps or overlaps between them. The template could be placed at the top of the Regions section, would add a hidden Category:Regions with vague subregions for maintenance purposes, and might look something like this:

2: {{putinsubregion}} - As a counterpart to the above, sometimes a destination article should be sorted into and linked from one of the existing subregions of the parent region, but it is unclear which one it should go into, either because of one of the problems pointed out above, or simply because it falls on or near the boundary between two regions. This template could go at the top of the article under the banner, would add a hidden Category:Change breadcrumb to subregion, and might read something like this:

For some examples of where these might be used, have a look at the Chicagoland area (it may be easier to see what's going on if you look at Category:Chicagoland) or try to figure out which subregions the towns listed in Category:Queensland go in. I have come across many similar situations of late, and wish I had had some way to tag them to come back to them later but no appropriate tags existed. Does this seem like a reasonable solution to everyone? Texugo (talk) 15:24, 18 August 2014 (UTC)

Agree that there are a good number of regions that need attention and having a maintenance category to identified them would be useful. A large template banner at the top of the page is something I am not too keen on though, maybe should be placed on the talk page or at least at the bottom of the page rather than the first thing people see. Also would like to propose that other templates like the translated from tag be moved to the bottom of articles. --Traveler100 (talk) 15:34, 18 August 2014 (UTC)
The {{translated}} tag already goes on the talk page (though the {{translate}} tag does not). The problem with putting them on the talk page is that you lose the advantage of calling any attention to the problem, since people don't generally go browsing through random talk pages. Plus it populates the maintenance category with talk pages instead of the actual pages, which precludes any CatScan searches, etc. Texugo (talk) 15:48, 18 August 2014 (UTC)
Although I don't think there are any other maintenance tags we've ever put at the bottom, I might be ok with putting number 2 at the bottom rather than the top, since that's where the IsPartOf tag is (invisibly). But I think #1 needs to be in the Regions section itself. Texugo (talk) 15:50, 18 August 2014 (UTC)
Indeed, translated goes to the talk page, because it's something that has already happened. On the other hand when there is a need for some form of work on the article (translation, category maintenance, cleanup etc.) I do think it's necessary to have it on the article itself for everyone to notice. And yes, I think such maintenance tags are useful and would support using them.
On the other hand, a huge text box right at the top of the article is not pretty. As cleaning up categories, listingfying sections etc. in practice is something that's performed by users with some editing experience anyway, we maybe don't need to outline exactly what has to be done in the tags and they could perhaps be smaller and briefer. This is something we could consider doing to all maintenance tags. (How about "Maintenance needed:geographical category"?). ϒpsilon (talk) 16:24, 18 August 2014 (UTC)
Not sure what I think of removing the instructions — maybe we could just shrink the text and make the box smaller, I dunno. But anyway, if you don't mind, I'd like to divorce any proposal to change the overall style of such tags from this discussion. Maybe you could make that a separate discussion. I think it's pretty clear that these proposed tags above match the existing style for maintenance tags, so concerns about the appearance of maintenance tags in general should in no way be a barrier to implementing these. The overall style can always be changed later. Texugo (talk) 17:31, 18 August 2014 (UTC)
Your proposed maintenance tags are useful and address a real issue so we should implement them.
Traveler100's remarks above got me thinking that perhaps we should do something to the overall tag style (which these tags match). Make them a bit smaller or something so that users that know to look after them notice them while "simple readers" don't. E.g. Israel recently had a warning box in addition to the two tags and the thing looked quite massive. But I agree that's better discussed elsewhere. ϒpsilon (talk) 18:09, 18 August 2014 (UTC)
So accepting this template mean that discussion before reordering of major regions is no longer needed? Should we not still use the process of discussing on the talk pages and placing the {{Regions discussion}} on pages before more that simple fixes? --Traveler100 (talk) 05:42, 19 August 2014 (UTC)
I don't think it implies that at all. The guiding practice of ensuring discussion first generally applies to cases where a well-established system is to be changed, where developed region articles have to be totally rewritten to match a new scheme, cases where we want to ensure that the work of previous contributors is not being undone without agreement. Most of the cases which need this tag, however, are cases at the bottom of the hierarchy, in relatively small areas with typically underdeveloped region articles, where the subdivision is poorly or ambiguously or incompletely established — by definition, this tag cannot be applied to "major regions" with an established, functional division scheme. And in these cases where it is applied, often a simple declaration that "North" includes districts A,B and C or that the "Timber Woods Region" extends from river X to river Y would be very helpful, and for that, it's just fine to plunge forward. If anyone disagrees with it later, the discussion can still take place. Texugo (talk) 15:22, 19 August 2014 (UTC)
Tinkering with region boundaries and breadcrumbs is something that can be discussed on the article's talk page. We really don't need a big, ugly template on the article itself for something this small. Save the templates for more serious issues, like "This page has been nominated for deletion, the entire text is plagiarised from a local CVB's promotional blurb and consists of the hôtelier's opinion of their own establishment, and, by the way, this country is an active war zone perched atop an erupting volcano." which affect the usability of the article or the viability of an entire destination. K7L (talk) 13:14, 20 August 2014 (UTC)
That is simply not good enough. This is a problem of no less importance than many many other things we track with similar tags, and being able to track them is enormously advantageous. If I had to start a discussion on the talk page of every article of this type, the text of each would be essentially what is written in one of the tags above, but with the disadvantages that a) I'd have to spend more time typing out the same thing every time, b) I'd have no way to keep track of it and come check on it later, c) it would be far less likely to come to anyone's attention because it would have no category and because people don't generally browse talk pages for the hell of it. The purpose for having this tag — to keep track of identified problems of a given type so that we can reduce them to zero — is the same as the purpose for {{crop}} or {{style}} or {{movetodistrict}} or {{merge}} or any number of tags for other problems we currently track. Would you suggest we reduce ourselves to untraceable talk page discussions for all those problems too? Texugo (talk) 14:49, 20 August 2014 (UTC)
Those tags tend to identify problems that a single dedicated editor could fix without assistance or consultation; your proposed tags are more likely to sit on the article for years while we wait for enough editors to be interested to both have a discussion, and find a consensus. Powers (talk) 17:21, 20 August 2014 (UTC)
That is not at all true. In fact, it is very similar to the {{movetodistrict}} and other tags in that respect: yes, it would be easiest if someone who knows the place well comes along, but that doesn't mean that a single dedicated editor could not fix it without assistance or consultation, given a little research time and/or a map. And as explained above, the type of articles these tags are designed for are not the cases where we need consensus, they only call for cleanup of situations which fail to comply with the basic principles of the geographical hierarchy.
Besides, there are plenty of {{merge}} and {{style}} tags and {{regions discussion}} that have been sitting around for years, among others; that's rather irrelevant and it would certainly be impossible to argue that the problems themselves aren't more likely to get worked on when tagged than when left untracked. We generally do mark these types of unambiguously identifiable problems; it's just that these particular two problems are not covered by any of the existing maintenance tags. Why in the world should that mean that subdivision/breadcrumb problems must be left untracked? Texugo (talk) 17:32, 20 August 2014 (UTC)
I agree. I think it's helpful to tag these things. Ikan Kekek (talk) 23:11, 20 August 2014 (UTC)

So where are we at with this? It does not seem fair to let this be shelved just because a couple of users dislike maintenance tags in general or are not very interested in this particular type of maintenance. Literally every other type of maintenance problem I can think of can be tagged and tracked: problems with banners, problems with article appropriateness/merging, problems with other images, problems with formatting, problems with transcription, problems with style, problems with translation, problems with content placement, plus a whole other scad of problems we track. The only types of common problems we have no way to keep track of are hierarchy problems, and I haven't seen any convincing argument as to why we should insist on keeping it that way.

The two tags above target two specific problems which are clearly and objectively identifiable, common, and easier resolved than some other things we tag such as merges yet not so easy to resolve that one always has time to fix them immediately when they are found. Keeping track of them so they can be fixed later improves the site by cleaning up the hierarchy we organize the site with, ensuring clearly understandable region breakdowns, correcting mistakes in the breadcrumb navigation system, and helping to ensure we don't have orphaned articles. I believe all these things are truly beneficial to the site. Knowing that the whole purpose of tagging problems is so that they can be fixed and untagged rather than floating out there unrecognized as problems for even longer, I do not understand what disadvantages could possibly outweigh those positives.

If you just don't like tags in general or you don't like they way they look, that is a discussion for another forum and I don't think those are very legit reason to hold this up, because we do have a range of tags, and for very similar reasons, so these opinions apply to tags in general. On the other hand, if you oppose for some other reason, please explain: given that every other type of problem has tags appropriate for tracking them with, and given the advantages I've just outlined, what overpowering disadvantage could there possibly be in completing our set of tags so that there are tags appropriate for hierarchy problems too? Texugo (talk) 03:31, 2 September 2014 (UTC)

I see no reason why this is a discussion for another forum. Defacing the articles themselves with more tags makes them look worse, unless there's something so severely wrong (like an article copy-pasted from a local CVB site) that it's already spam, copyvio or just plain unusable. Wikipedia is already a mess of "I don't like this topic, so I shall plaster the article with pointless maintenance tags." We don't need this on our destination pages. K7L (talk) 06:09, 2 September 2014 (UTC)
Put those in talk pages if we want to track them via categories. Works just as well, doesn't clutter visually. PrinceGloria (talk) 06:14, 2 September 2014 (UTC)
K7L, your comments obviously apply to practically all existing tags. All our tags are big and ugly and designed to catch attention so that both tag and problem can be removed, so these are no different in that respect. But while we do have tags for every other common problem but this one, and while that is the way they're all done, I don't think opposing tags in general or opposing it on the basis that it's a big ugly tag gives you the right to hold us back from completing ourg set.
And PrinceGloria, same thing, all other maintenance tags share the same look and they go in the article. If we wanted to start using talk pages instead for maintenance, that would probably apply to most other tags as well. Otherwise what makes hierarchy problems so much less important than the least of style problems or the slightest of banner mis-sizings, to the extent that we'd relegate it to the talk page where the tags would fail to draw the attention they were designed to draw and unprecedentedly categorize the talk pages instead of the actual page?
These are maintenance problems of the same type as all the others which we tag, using the same look and placement as all the other tags. If either of you propose that this case is so extremely different that it needs a new treatment or need not be maintained at all, make your argument and explain why these particular problems should not get the same attention as every other type of problem. Otherwise, back off the obstructivism and take your fight against big ugly tags to a more appropriate forum or, better yet, be sensible and fight big ugly tags the way they were intended, by fixing problems and removing the tags — that's the whole point. Texugo (talk) 11:20, 2 September 2014 (UTC)
All tags should go to talk pages. They're for the experience editors who know how to deal with stuff like breadcrumb trails etc. Otherwise, giving the amount of problems most of our articles have and the dearth of editors we experience, K7L's fear of our articles becoming totem poles for various maintenance tags is justified. We would present a face we would not want to to the casual readers who might become editors. Correcting a small paragraph text or filling in listings is one thing, but being scared away by a big maintenance tag looking like "a big big problem here, don't touch" is another. PrinceGloria (talk) 16:57, 2 September 2014 (UTC)
I can see the advantage of tagging on the article page as it makes running scripts and category compare runs easier, but I really think large tags at top of article pages are ugly and distracting to readers. May I suggest a two stage approach here. First use the new tags proposed here on the article page but make them small in size and placed at the bottom of the page. Second we have a separate discussion on moving all, or maybe just most, of the maintenance tags to the bottom of the article page as smaller boxes or onto the talk page. --Traveler100 (talk) 18:15, 2 September 2014 (UTC)
I don't have any problem with discussing a change in where we put tags or their size or anything. I wouldn't mind making them smaller. I do have a problem with forcing this particular tag to be different from the others unless there is a very substantial clear reason to have two different tagging styles, and I have a very very huge problem with pegging the fate of this proposal to any wider proposal which would affect all tags and which may take a long while for us to get consensus on if we ever do. The only question here is, is there any reason why these should not be tracked while other similar problems should? And no one can provide such a reason. So let's start tracking them. These other issues about tags in general can still be discussed elsewhere, and whatever result that discussion reaches will still be applied to these too, of course, when and if we finally get consensus on that separate issue. This proposal shouldn't be punished for doing what all the other tags already do, and should not be held hostage while we try to satisfy those who want to change all our tagging practices. These are totally in line with existing maintenance practices, they are very useful, and I'm anxious to start using them. Texugo (talk) 18:58, 2 September 2014 (UTC)
My main concern is that these still seem like more long-term tags than most others we use. They both point to problems with the geographic hierarchy, discussions about which are often complex and contentious. It's one thing for a template like {{regions discussion}} which simply alerts interested readers to an existing discussion that they may be able to participate in; these proposed templates are of a somewhat different character, as they prompt new discussions being created. And they're of totally different character from simple cleanup templates like {{districtify}}. Powers (talk) 01:19, 3 September 2014 (UTC)
That is simply a mischaracterization or misunderstanding of what these are for, Powers. {{vagueregions}} is a tag which objectively identifies a region where the region breakdown either has gaps or overlaps or for which the regions have been named but the borders between them are unclear. Occasionally there is even a map already but it is unclear what boudaries (administrative, etc.) the boundaries have been derived from. Most of the existing regions where I've seen this problem are low, sub-state-level regions where the best thing would be for someone to look into it and then plunge forward, because the chances of getting a group of users to respond to Talk:Michoacan or Talk:North Carolina Coastal Plain or Talk:Siena (province) and actually debate knowledgeably until a consensus is reached are practically nil. Plunging forward is how most lower-level region schemes get put together in the first place anyway. And if and when anyone does finally come along and disagree, the discussion can happen, but at least in the meantime the existing scheme will be hierarchy-compliant and clearly organized for the reader. I have fixed a few of these cases, looking into them and correcting the breakdown toward the nearest compliant scheme that seems to make sense, and I certainly find it easier and less time consuming than it would be to complete some of the {{merge}}s or {{movetodistrict}} or {{movetocity}} things we've tagged. And as mentioned before, some of those have been sitting around for years. Plus, as problems go, I think a situation which causes confusion as to where our coverage can be found is at least as deserving of tracking as a banner that's 6:1 instead of 7:1, and is definitely more useful to track than {{regions discussion}}, which can be placed on any article subjectively any time someone proposes any change in the breakdown, and which tends to keep sitting there for ages even if the discussion is not going anywhere and even if the existing scheme is not actually broken or non-compliant in any way.
Similarly, there should be no controversy at all with {{putinsubregion}} either. There is no subjective decision to be made regarding when they should be placed: they are used when there is a proper region breakdown but a destination hasn't been sorted into it yet. In the last 3 months I have fixed quite literally more than 800 breadcrumb problems of this type. Most of the time it doesn't take more than opening a map and comparing it to our region map, or looking up what county/district/department/district/valley/mountain range it belongs to. It's generally a very objective determination which doesn't require any prior discussion to fix, and it's usually not that hard, but like other problems we tag, it does take a little time, and I certainly don't think I or anyone else should be expected to just "fix it immediately or forget it". We need to be able to tag these things. Texugo (talk) 02:26, 3 September 2014 (UTC)
If you put this in the article itself as a huge, ugly template you're addressing this not just to other editors but to the readers. I can see it now, the traveller looks up London; Lonely Planet tells them to see Buckingham Palace, National Geographic tells them to see Big Ben, Wikivoyage tells them that London isn't complete without creating some more subregions. Which is actually useful as travel advice?
There are enough objections made to Wikipedia-like annotations such as <ref>...</ref>, but something that's purely for maintenance and no use to the traveller at all? It doesn't belong in article space, unless the problem is so severe that we're telling the reader not to use the page ({{warningbox|This destination was just obliterated by a nuclear bomb. Forget we listed it.}}). K7L (talk) 04:25, 3 September 2014 (UTC)
I'd summarize the issue this way: Putting tags in an article is kind of ugly, but putting them in the talk page means that no-one is likely to see them. So given those choices, the lesser evil is to put them in the article, if they need attention. And if we can agree to that, then let's try to find a way to make the tags almost as visible to potential editors but less ugly. Ikan Kekek (talk) 04:43, 3 September 2014 (UTC)
The problem is that most people seeing the warning boxes won't do anything about it anyway, will just be thinking the article they're reading is somehow bad. The people who are frequent editors and know about the subject enough usually react to even the slightest mention of a problem in the talk page. And most editors here tend to flock to articles where problems are highlighted, not to mention scouring categories for finding them out. At our level of editor base evolution, I see no benefit from displaying maintenance tags. PrinceGloria (talk) 04:51, 3 September 2014 (UTC)
How about smaller like ths
hHerarchy Talk on vague region
and at bottom of article page?--Traveler100 (talk) 09:15, 3 September 2014 (UTC)
Brilliant, works for me! PrinceGloria (talk) 09:39, 3 September 2014 (UTC)
Guys, how are you missing the point here? We don't need a new consensus to "display maintenance tags"; we already do that, and for every other problems out there. Yes, your concerns are valid, but they have nothing to do with these particular tags. Nobody except Powers has expressed any concerns that directly relate to the issue, and in the absence of that, we'd need go ahead and to let these through to join all the others. Otherwise you are pegging the fate of this proposal to the fate of a new overall proposal that affects many things and will take some time to work out, in effect holding these two tags hostage until you get what you want for the whole set of tags, and that is both unfair and counterproductive. To the extent that these are not the same all as the others tags, are there remaining diadvantages? If not, stop standing in the road here and let's go elsewhere to discuss changes to maintenance tags in general,, Texugo (talk) 10:40, 3 September 2014 (UTC)
Opened up general discussion on tags' size and position below. --Traveler100 (talk) 11:58, 3 September 2014 (UTC)
On these specific tags, no problem with the suggestion as long as it is not used as an alternative to the region discussion tag.--Traveler100 (talk) 11:58, 3 September 2014 (UTC)
I'd be happy to see these exist, and I'd be happiest to see them on the talk page. As a general rule of thumb, if the most likely fix is not some random passerby (which works for typos but not complicated stuff), then the fix will almost always be applied via a dedicated person who found the affected article in a category. Therefore we don't need "visibility" for that kind of tag; we only need its presence somewhere. WhatamIdoing (talk) 15:30, 3 September 2014 (UTC)

Thanks for the support. The comments about starting to hide maintenance tags on the talk page really belong in the other conversation below though, since it's something we haven't done before, something which is proposed for multiple other maintenance tags, and something which more than one user has opposed on the basis of failure to draw any attention and preclusion of cross-referencing due to categorization of the talk page instead of the actual one. Texugo (talk) 15:45, 3 September 2014 (UTC)

Regions[edit]

The adding of these tags brings up another issue. Initially regions were created based on what is relevant for tourists but there is now a tendency to move to administrative structures. For example Middle Rhine Valley has now been tagged an extraregion of Rhineland-Palatinate and some of its articles tagged with {{putinsubregion}}. Anyone familiar with this area of Germany knows that it is dictated by the rivers, not just major towns, roads and rail but where the tourist go. Should the towns be rearranged into the Germans states (the river is not always the border) and new sub-regions for Kreis rather than geography of the area for Rhineland-Palatinate, North Rhine-Westphalia and Hesse articles? --Traveler100 (talk) 05:30, 19 August 2014 (UTC)

Yes, that is exactly what has to happen. Since the Middle Rhine Valley crosses several of the hierarchical regions we've chosen to use (states, and the hierarchical subregions under them), it is by definition an "extra-hierarchical region", and therefore no destination should use it for its breadcrumb trail, because otherwise the breadcrumb would follow an alternative hierarchy that skips over the official hierarchy we've used to subdivide down to that level. This case is slightly complicated by the fact that Rhineland-Palatinate lists it as a subregion, but it is clearly not a hierarchical subregion because it contains destinations from other areas, so it still shouldn't be inserted in the hierarchy via IsPartOf. The only ways for Middle Rhine Valley to be a hierarchical region is if a) we re-carve the whole country into regions other than states, of which this could be one, or b) we limit this article to cover only the Rhineland-Palatinate portion of the valley and put coverage of the rest elsewhere. In the absence of either of those events, we have to let it just be an extraregion and change the breadcrumbs of the destinations to reflect the actual hierarchical state or state subregion. In any case, that's just the way it's done across the site, and none of that actually has anything to do with the tags suggested above. Texugo (talk) 15:10, 19 August 2014 (UTC)
That may make sense to someone who does not visit the area but is really a bad idea for a travel guide. The geography of the region is dictated by mountain regions divided by rivers. You visit the Mosel, the Rhine or the Nahe, or go into the Hünsruck or the Eiffel. The organisation had worked as was in the most useful form for tourists. Someone visiting Rüsselsheim will then travel to Sankt Goar, with a strict administrative regions these would be be in different sub-regions of different German states. --Traveler100 (talk) 18:01, 19 August 2014 (UTC)
Traveler100 - The point is that any discussion of changing the regions of Germany belongs at Talk:Germany (incidentally they were just changed less than a year ago) and has nothing to do with the tags proposed above. As Germany is set up currently, the states are the official top-level hierarchy and anything which crosses more than one of those to carve up the country in an alternative way is necessarily an extra-hierarchical region. We choose one official hierarchy with no gaps and no overlaps, and all breadcrumbs are set under that hierarchy, in which they all have a single place where they belong, and other ways of dividing the space up are covered as extra regions and left out of the breadcrumb hierarchy. Otherwise, we´d start having breadcrumbs arbitrarily subscribing to competing organizational schemes all over the place, which would be a nightmare to maintain and would completely undermine the utility of the parallel category tree. (If, god forbid, you actually are proposing some change to abolish the geographical hierarchy in favor of a patchwork gaps-and-overlaps approach, that would probably belong at Wikivoyage talk:Geographical hierarchy, but expect some fierce opposition.) I set Middle Rhine Valley to extraregion because that's exactly what it is, by virtue of not being its own region on the Germany map. And currently, it is the only extraregion on the whole site which has destination articles categorized directly under it instead of under the conventional hierarchy. (see Category:Extra regions with categories) Texugo (talk) 19:29, 19 August 2014 (UTC)
<edit conflict> If I may interject - can we discuss the regional division of Germany under Talk:Germany?
As regards the general thing - there are many ways to slice the same geographical area. This is why we have the breadcrumb division, extraregions and finally itineraries. I believe they all have their place. For the sake of making Wikivoyage easy to navigate, I believe we do need a single major breadcrumb trail, while we can we add as many extraregions and itineraries as we see fit. We also need a general idea which we should follow while splitting every geographical area, otherwise we might end up in a mess.
I tend to believe that going by e.g. mountain ranges or river valleys we might end up with leftover areas which would have to be put into "stuff that is not along any touristically interesting river, lake or mountain range" and otherwise unreasonable regions we will forcibly need to adopt that nobody would be looking for, will be hard to identify and their borders very subjective, unclear and regional division hard to maintain - e.g. one user may find one location is one arbitrary region, but another may see it more in another arbitrary region, and we will end up with a breadcrumb mix-up, so we will need to constantly patrol for that while maintaining a reasonable knowledge of the idea behind the regional split.
In short - any reasonably identifiable region, like a popular mountain range or river valley, that does not fit in an otherwise reasonable general regional division of the upper-level entity, e.g. country, should become just that - an extraregion. In said case, it may be hard to appropriately describe the area in separate parts, and those parts may singularly be rather uninteresting or provide insufficient content for a reasonable standalone guide unless put in the right context. I find an extraregion, or if applicable, itinerary, a great way to do with such cases. PrinceGloria (talk) 19:44, 19 August 2014 (UTC)
Totally agreed, and yes we should move the rest of this conversation to Talk:Germany, though I will comment that I just realized that Harz and Eifel are two more which need to have their "children"'s breadcrumbs aligned with their respective state subregions instead of that alternate breadcrumb trail. Texugo (talk) 19:51, 19 August 2014 (UTC)
Please discuss on the talk page before you undo any more work that other people have spent time on. Discussing a new structure is worth doing but you are not going to win any friends just simply doing what you think is the correct solution without discussion. --Traveler100 (talk) 20:17, 19 August 2014 (UTC)
I have undone no work here, and changing a list of IPO tags is a breeze anyway. But please realize that the way those breadcrumbs are currently set up is not consistent with WV:Geographical hierarchy#Dividing geographical units, and my efforts only aim to rectify that. There is already broad consensus that we use a single no-gaps-no-overlaps hierarchy for the breadcrumb trails and no other. Nobody is trying to delete those region pages or strip the lists of cities from them or the links to them from elsewhere or anything like that; they are just simply not the regions that get used in the breadcrumb trails, that's all. Texugo (talk) 20:27, 19 August 2014 (UTC)
I guess the point is that instead of asking me to discuss before making completely standard corrections which are already a part of our system, you should drop your objection and either start proposing new Germany regions, get used to the extra regions not figuring into the breadcrumb trail, or propose a drastic abandonment of fundamental WV:Geographical hierarchy policy. In other words, I don't believe I should have to raise any new consensus before setting it up the way written policy dictates, the way everything else is. I'll humor you for the time being, but I'd appreciate it if you'd think it over and let us follow policy on this one until there is consensus to do otherwise. Texugo (talk) 20:52, 19 August 2014 (UTC)
As far as I can tell, "extraregion" is a fairly recent concoction and its existence is not in any way entrenched in policy nor precedent. K7L (talk) 03:41, 20 August 2014 (UTC)

You are correct — the previous practice was to not allow articles exist to outside of the hierarchy at all, to always redirect them to the most suitable higher region or country article. Now we have become looser with what we allow articles for in terms of alternative region structures, tagging them as extra region, because the coverage, when possible, should still be concentrated in our primary hierarchy. But they certainly haven't negated our hierarchy policy; they fall outside of it by definition. Texugo (talk) 03:56, 20 August 2014 (UTC)

For the record - if this becomes a policy discussion, I support allowing extraregions if there is a region that 1. objectively exists 2. does not fall within the regional hierarchy agreed and the hierarchy cannot be reasonably amended to include it. I would add a provision though that first all effort must be done to try to include it in the breadcrumb hierarchy, perhaps altering it if reasonable. PrinceGloria (talk) 04:31, 20 August 2014 (UTC)
We had some debate around the European Union where we concluded that it should not be an extra-region but rather a general travel article.
What would be examples of valid extra-regions ? Andrewssi2 (talk) 04:56, 20 August 2014 (UTC)
Category:Extra regions lists all the currently defined ones, although it seems to require a good deal of clean up. ( e.g. Arcadia_(Greece) ) Andrewssi2 (talk) 05:00, 20 August 2014 (UTC)
That one was incorrectly categorized (now fixed) but by and large, the list is mostly accurate. The overwhelming majority are examples of historical regions/provinces/states/countries or tourist regions based on lakes, seas, mountain ranges, valleys, peninsulas, etc., which happen to overlap with two or more regions of the established hierarchy we've chosen in our regional breakdowns/maps. That's what it's for. Texugo (talk) 13:27, 20 August 2014 (UTC)
And incidentally, "extra-hierarchical" regions are not something someone just cooked up one day and started slapping on there. Discussions go back to at least 2009, and {{extraregion}} is the best response we have so far for a real issue which we have collectively identified, of having regions which are necessarily left out of the no-gaps-no-overlaps hierarchy. Consensus seems to back it pretty solidly at least as for as it goes. It boils down to the simple fact that the breadcrumb for any given article can only go in one hierarchy, and for that purpose, per WV:Geographical hierarchy, we choose the one which covers the geographic area comprehensively with no gaps or overlaps, the one that we organize our regional breakdowns with, the one that can be used to perfectly divide up a map without ambiguity or holes in the coverage. This inevitably means that since there are obviously multiple ways of slicing up most areas, the regions which don't fit into that comprehensive subdivision plan are necessarily left outside the hierarchy, and are thus extra-hierarchical by definition.
Over the 5 years the discussion has been going, no one has suggested that there is no need for such articles outside the hierarchy — we have them and we need to have them, and there is a recognized need for flexibility in such articles, given our guidelines to avoid redundant coverage and recognizing that needs for these articles range from minimal (Cumberland County (Maine), Western New York) to complex (Schwaben cultural region, California Wine Country) — the {{extraregion}} tag simply makes them their own class where that flexibility is possible. Everybody seems to have been in agreement up to that point. The direction of the discussion only suggests we need to go further still in defining guidelines on how such articles should be constructed, given that necessary flexibility, but to suggest we should stop acknowledging that some regions exist outside the hierarchy would be a huge step backwards at this point. Texugo (talk) 14:15, 20 August 2014 (UTC)
They're occasionally useful, but the instances in which they are needed are rare. There's no need for a mess of new policies, added maintenance categories, templates on articles or more rule creep just to accommodate this. I´d also prefer not to see {{extraregion}} tagged onto things which are bottom-level destinations, not regions - Thousand Islands was one example where I'd reverted this sort of edit. K7L (talk) 16:00, 20 August 2014 (UTC)
I agree that it shouldn't be used for destinations (and in fact, I just now suggested that Bolan Pass and Khyber Pass be changed back to the city template).
Please note, though, that this discussion has absolutely nothing to do with the templates proposed in the thread above, so it's better to keep comments about those up there in the previous thread. Also note that neither discussion here is presenting any new policy or rule creep whatsoever. Texugo (talk) 16:07, 20 August 2014 (UTC)

This discussion, as it relates to Germany's subregions, now has a proposed resolution at Germany#Move to restructure regions. Please comment there. Texugo (talk) 01:59, 26 August 2014 (UTC)

Letter petitioning WMF to reverse recent decisions[edit]

The Wikimedia Foundation recently created a new feature, "superprotect" status. The purpose is to prevent pages from being edited by elected administrators -- but permitting WMF staff to edit them. It has been put to use in only one case: to protect the deployment of the Media Viewer software on German Wikipedia, in defiance of a clear decision of that community to disable the feature by default, unless users decide to enable it.

If you oppose these actions, please add your name to this letter. If you know non-Wikimedians who support our vision for the free sharing of knowledge, and would like to add their names to the list, please ask them to sign an identical version of the letter on change.org.

-- JurgenNL (talk) 17:35, 21 August 2014 (UTC)

Signed. What an unconscionable abuse of power by the WMF. Shame on them. -- AndreCarrotflower (talk) 17:44, 21 August 2014 (UTC)
Shame. I hope not to see another IB and yet another fork of Wikivoyage. I wish WMF realise and co-operate with Wikimedia community members. --Saqib (talk) 17:59, 21 August 2014 (UTC)
You guys have only gotten one side of this story. The anti-Media Viewer drive fails to take into account the needs of non-editors and is driven largely by a reflexive resistance to change. Powers (talk) 00:47, 22 August 2014 (UTC)
Powers , do you have any link to the other side of the story? Andrewssi2 (talk) 00:56, 22 August 2014 (UTC)
Not at the moment, I'd have to do some research and get back to you. Try the Signpost? Powers (talk) 00:59, 22 August 2014 (UTC)
A couple of links in English and German. It seems this originates from a disagreement around the implementation of Media Viewer on German WP pages and has resulted in the implementation of 'Super Admin' status for WMF staff in order to override the wishes of the community.
I found the following statement from the WMF that does not directly address this issue, but suggests that stronger leadership and decisions from the WMF staff is important in order to help the WikiMedia platform survive in the developing internet landscape. Andrewssi2 (talk) 01:45, 22 August 2014 (UTC)
[5] may also be helpful to read. (I'm choosing not to state my full opinion at this time, as that would put me in an awkward position - but there's plenty of opinions available at m:Requests for comment/Superprotect rights.) --Rschen7754 01:50, 22 August 2014 (UTC)
Isn't the issue here more one of principle than on the question of whether this software should be used on every Wikimedia site or not? I do realize your first link addresses that, and I appreciate reading that side of the story. Ikan Kekek (talk) 06:47, 22 August 2014 (UTC)

Sigh. Yes unfortunately it is creating excessive drama. The WMF is giving themselves extra authority to push software changes without first getting community consensus. This is tilting the fine balance between the foundation and the community. The flip side is of course that it is a huge effort to develop consensus for anything. Experimentation within Wikipedia is hard. But than maybe it should be. Travel Doc James (talk · contribs · email) 00:47, 24 August 2014 (UTC)

Buffalo/South Buffalo[edit]

Announcing the completion of the second-to-last Buffalo district article. Hope no one minds me patting myself on the back about it here at the Pub. -- AndreCarrotflower (talk) 18:14, 21 August 2014 (UTC)

Congratulations! Ikan Kekek (talk) 18:57, 21 August 2014 (UTC)
Why here in the pub? You should've put it in Wikivoyage:Star nominations right away! ϒpsilon (talk) 19:08, 21 August 2014 (UTC)
Well done and keep up your good work Andre. You've invested a great deal of time and effort into Buffalo articles. --Saqib (talk) 19:12, 21 August 2014 (UTC)
Thanks, folks. Ypsilon: sadly, sticklers will note the article's map is dynamic rather than static. -- AndreCarrotflower (talk) 18:56, 22 August 2014 (UTC)
Hmm...then we need to create a new category for superb articles with "just" a dynamic map? Category:Sun articles?ϒpsilon (talk) 19:05, 22 August 2014 (UTC)

Process ideas for software development[edit]


Hello,

I am notifying you that a brainstorming session has been started on Meta to help the Wikimedia Foundation increase and better affect community participation in software development across all wiki projects. Basically, how can you be more involved in helping to create features on Wikimedia projects? We are inviting all interested users to voice their ideas on how communities can be more involved and informed in the product development process at the Wikimedia Foundation.

I and the rest of my team welcome you to participate. We hope to see you on Meta.

Kind regards, -- Rdicerb (WMF) talk 22:15, 21 August 2014 (UTC)

--This message was sent using MassMessage. Was there an error? Report it!

Badge function in Wikidata[edit]

Dear Wikivoyagers, contributors, readers, travellers...
Wikidata has introduced badges to denote good and featured articles in Wikipedia. These article statuses are displayed with stars in the interlanguage links. Maybe you think, this feature is useful on Wikivoyage and should be implemented on Wikivoyage as well. There is a discussion on meta to develop a common strategy and request the needed functionality from Wikidata. Please joine the discussion, if you are interested in the new feature. (Sent by DerFussi via MassMessage) 06:37, 22 August 2014 (UTC)
I added a comment on meta. I don't see any information about why this would be of benefit. Maybe the benefit is too obvious to everyone else, but I would appreciate knowing exactly what it is. Andrewssi2 (talk) 23:24, 23 August 2014 (UTC)
We already have statuses, so I don't understand what this would add. If an article is a Guide, that's a mark of quality. Ikan Kekek (talk) 23:27, 23 August 2014 (UTC)
Exactly, it would just move the 'Guide' status into WikiData. It wouldn't be useful because this is not a data item that can be shared between different Wikivoyage language sites.
It 'may' be useful to know that Jerusalem is a Guide article in Hebrew if I am looking at the English article which is only 'Usable', although I doubt anyone would be that interested. --Andrewssi2 (talk) 23:37, 23 August 2014 (UTC)
That's the usual argument. On Wikipedia, other-language articles with exalted status are indicated with an icon next to the name of the language on the sidebar. Wikivoyage could do the same. Powers (talk) 01:39, 24 August 2014 (UTC)
That's an excellent idea. Ikan Kekek (talk) 04:51, 24 August 2014 (UTC)
Thinking about it some more, I have to say that I don't check out other language versions of an article because I make the assumption that they will have less content than the English one. This feature would encourage me to at least check out the other ones if there was a quick icon that would tell me there was content worth viewing. Andrewssi2 (talk) 06:48, 24 August 2014 (UTC)

Andrewssi2, Ikan, it will be great if you make a clear statement on Meta, because we have to demonstrate our consensus regarding the usage of badges. So far we have seen a regrettably low interest of the community in this topic. --Alexander (talk) 09:29, 24 August 2014 (UTC)

Done. Andrewssi2 and Powers, I hope you don't mind that I copied your comments as well as mine to the linked discussion in Meta. Ikan Kekek (talk) 05:29, 25 August 2014 (UTC)
Great idea. Useful when one needs help writing articles. Directs one to other languages which may have some really good pictures. Also useful for those who speak more than one language. Travel Doc James (talk · contribs · email) 11:31, 29 August 2014 (UTC)
This feature would have saved me a lot of trouble during my last trip! I went to an African country and was lamenting at the low quality of the English articles. Only after I came back did I discover that the French and Portuguese versions are MUCH BETTER!!! (depending on the destination) As most travellers, I can understand several languages, so this feature would be extremely helpful. We really need that. Also, it makes it safer for external project to link to us (they don't want to link to a page that has just titles, but would like to link to our pages that are good enough). Nicolas1981 (talk) 10:45, 4 September 2014 (UTC)
Update: Star and guide articles already can be shown on the sidebar, see Staraya Russa. For the usables, I filed a bug which I hop will be soon resolved. What is exactly shown on the sidebar (what symbols and what captions) I believe can be changed locally.--Ymblanter (talk) 20:10, 6 September 2014 (UTC)

CC interview[edit]

Hello guys, recently Creative Commons interviewed me regarding Wiki Loves Monuments 2014 in Pakistan. Wikivoyage was mentioned in the interview so thought of sharing it with the community as well. --Saqib (talk) 18:04, 25 August 2014 (UTC)

Congratulations! Ikan Kekek (talk) 05:46, 26 August 2014 (UTC)
Can the interview be seen somewhere? :-) Nicolas1981 (talk) 10:37, 4 September 2014 (UTC)
@Nicolas1981: you can find it here. --Lkcl it (Talk) 10:55, 4 September 2014 (UTC)
How could I missed to mention the URL of interview. IK, you could had notified me about that. Anyways sorry guys and thanks to my Italian friend. Recently, WMF published a blog post on WLM 2014 and they actually used some excerpts from my CC interview. --Saqib (talk) 21:29, 5 September 2014 (UTC)
I still haven't gotten around to listening, just wanted to congratulate you. Ikan Kekek (talk) 22:18, 5 September 2014 (UTC)
I finally got around to reading the interview. Excellent! Ikan Kekek (talk) 05:05, 11 September 2014 (UTC)

Rail trails: where do you stick 'em?[edit]

I'm trying to figure out the best place to stick a rail trail, a non-motorized bike and pedestrian trail converted from an old railway.

Specifically, I'm considering the OC&E Woods Line State Trail in Oregon. I'm thinking it belongs somewhere on the Klamath Falls article. Maybe under "get around" because it's a great way for pedestrians and cyclists to get from one end of town to the other. But maybe "get in" works better because the trail extends well beyond town and meanders quite a ways northeast, passing through a handful of small towns. But then does it go under "by bike" or "by foot"? Or maybe it goes under "do" instead?

Ideas? Athelwulf (talk) 06:42, 26 August 2014 (UTC)

If it is a good size trail and you can write a reasonable article about the route and places along the way then I would suggest creating an itinerary. Something like the Rheinburgenweg listing places of interest along the way as well as an overview of the trail. Then place in the town articles that the trail passes through a link to the page in the do section, like in Koblenz#Do. --Traveler100 (talk) 07:54, 26 August 2014 (UTC)
Athelwulf: I had a similar situation on my hands when I wrote Clarence (though it sounds like the Woods Line State Trail is a good deal longer than the Clarence Pathways). What I ended up doing, and what you might want to use as a sort of template, was giving the trail its own entry under "Do", and also mentioning it in the "By bike" subsection of "Get around". -- AndreCarrotflower (talk) 13:51, 26 August 2014 (UTC)

What is exactly the policy regarding having "regions/districts/boroughs" sections in articles about smaller cities/regions/towns/villages?[edit]

What I mean is... can users on EngVoy add those sections to any article even if the city/region/town isn't too big to justify presenting smaller sub sections of that place? Is that allowed if no extra information is given about each of the sub sections made ?

For example, at the HebVoy article for the Israeli city of Rishon LeZion (as you can see in this version of the article which is produced with Google Translate) the "Regions" area was added with a map, and that small city was seperated into 3 sections, even though no information was added to those section other than what neighborhoods each section consists of. Is this permitted also on EngVoy articles ? or is there some policy that prevents users from making an endless amount of smaller and smaller sub-regions within each existing region article? ויקיג'אנקי (talk) 19:51, 26 August 2014 (UTC)

Hi ויקיג'אנקי. We generally subdivide cities on a case by case basis, usually only for truly huge cities with many districts, and after the article has too much information to keep organized well on one page, and in most cases after a group discussion on the best way to divide up the city into districts. While a static map is of course welcome for any city article, a small city like Rishon LeZion does not even come anywhere near being the type of article we typically subdivide into multiple articles. Texugo (talk) 20:03, 26 August 2014 (UTC)
I myself have understood for a long while that what you just described above is the norm on EngVoy. Nevertheless, it seems that there are no specific rules on this matter which would clearly explain this norm.
Currently I have noticed that the habbit of sub-dividing smaller cities/town/regions/villages has become very prevalent on HebVoy - where some users especially like to subdivide each area into smaller regions. I understand how it would make sense to split many small or remote cities/regions/towns/villages into smaller regions at Wikipedia articles, but on Wikivoyage I think this trend only adds a lot of unnecessary clutter to existing articles/guides. Unfortunately, as this was never fully explained anywhere on EngVoy I find it very difficult to explain to them why subdividing each area into smaller sections is not the best way to go. ויקיג'אנקי (talk) 20:22, 26 August 2014 (UTC)
(edit conflict) At least articles should not get separate sub-district articles of the type City/District until the article is so large that it has to be done. On the other hand I think a District section with a map can be useful for practical navigation in some cases. One example would be Mombasa which practically is a kind of small archipelago where travelers are helped a lot by knowing on what island what is.
On the other hand Rishon LeZion is firstly not as big population-wise or geographically, secondly it's a normal city without any exotic geographical configuration and finally the article itself isn't very long.
I don't think there is an explicit policy against just a Districts section with a map and some descriptions of districts, however in most cases there are probably more important things to work on in the article. And if someone make red links someone else might be tempted to create a bunch of articles with one sight or one restaurant in each - persons who want to use our guides in practice might get pretty annoyed. ϒpsilon (talk) 20:31, 26 August 2014 (UTC)
ויקיג'אנקי, we do actually have guidance on this topic, at Wikivoyage:Geographical_hierarchy#Districts_in_cities. Texugo (talk) 20:32, 26 August 2014 (UTC)
Also relevant is the note further down that page at Wikivoyage:Geographical_hierarchy#Keeping it together. Texugo (talk) 20:55, 26 August 2014 (UTC)
I would note that unlinked districts -- that is, lists of districts, without having articles for each district -- are best put under "Understand" (optionally in an "Orientation" subsection) to avoid confusion. Leave "Districts", "Regions", and "Cities" for site navigation amongst extant (or redlinked) articles. Powers (talk) 00:11, 27 August 2014 (UTC)

Discussion times and warnings to editors[edit]

Is there an acceptable time for discussion? We have a user that appears to think writing on a talk page and then making the edits proposed a few hours later is adequate time for response and discussion. Surly for discussions such as change of region boundaries we should allow at least 24 hours to allow people on all timezones (or because they are not always online) to respond? --Traveler100 (talk) 04:35, 29 August 2014 (UTC)

You can always revert and say "hey, I don't agree, let's discuss first". I guess this is the correct application of plunging forward. The less rules we have that stifle creativity, the better. Thanks to the purposes of the wiki engine, we can always revert changes we find inappropriate, so no harm is done if somebody plungers forward. PrinceGloria (talk) 04:43, 29 August 2014 (UTC)
I think an appropriate amount of time would depend on the subject and how controversial & significant the changes are. I think region boundaries is something that should wait for a couple days before making changes, unless several others support the changes before then. AHeneen (talk) 06:06, 29 August 2014 (UTC)
Seems like a basic question of etiquette, of which I think most Wikivoyagers understand but isn't codified anywhere (to my knowledge)
The person in question should be reminded that it may take interested parties a few days to see their proposal, and that there is no harm to wait before implementing their proposal, if accepted by the community --Andrewssi2 (talk) 06:19, 29 August 2014 (UTC)
Be fair, assume good faith. You might have asked me about it before making a scene in the pub — this was not a case of a user overeagerly pushing a change through. It was just a simple misunderstanding, and if I was overeager, I was only overeager in thinking that you had already agreed by making the proposal in the first place. You proposed ABC, I thought I restated ABC and added DEFG, then the only other dissenting user in the conversation agreed with the ABC part, so I made the change for only that part of the proposal that I thought we were all in agreement. Your immediately previous post had indicated to me that you now understood why we can't allow overlap, so I didn't realize your understanding of ABC had the unspoken implication of unprecedentedly displaying the wrong state for cities 70+ km from the state border. Texugo (talk) 11:29, 29 August 2014 (UTC)
Actualy, now that I look at it again, you yourself wrote "Glad we could agree on the mountain regions" before I made the changes, clearly appearing to endorse my rewording, so I don't really even understand what is meant by your complaint above. I clearly had good reason to think everyone was in agreement. Texugo (talk) 12:55, 29 August 2014 (UTC)
This is the kind of misunderstandings that must be allowed to happen all the time, if we are to keep "plunge forward" as the norm. As to the original question, I often write at the talk page at the same time as I do a change, if it is something easily reverted, where I think I must explain the change. For changes that affect many articles or that might invite further more complicated changes, one should wait some days, and often invite discussion on a more watched page if it seems like nobody noticed the proposal. --LPfi (talk) 08:04, 1 September 2014 (UTC)

Pronunciation Help[edit]

I want to verify that edits like this [6] are counterproductive, correct? I've noticed User:Fabimaru has recently been adding them to various Japan articles, changing place names to add the diacritics for pronunciation purposes. In most cases it seems inappropriate, but I'd like to double check before reverting. ChubbyWimbus (talk) 16:48, 30 August 2014 (UTC)

Note that I did not change the name of any existing page, I only changed the display name. The only drawback I see is that it makes it harder to search a name on the page using the browser (not everyone can easily type such characters). But the reason why I did is that it allows to know the right way to pronounce it. For me it's like not having accents on French names, it leads to ambiguity. It may contribute to be understood when in Japan. From my experience, if you have both the wrong pronunciation and a strong foreigner accent it does not help. Also, Wikipedia (English and French) use the diacritics (excepted for the major cities like Tokyo or Osaka I think), so there would be some consistency between the two projects. But if my view is not shared, no problem, I can stop such modifications and rollback the previous ones. Maybe it should be clarified in the help pages (to be honest I did not check). - Fabimaru (talk) 18:35, 30 August 2014 (UTC)
Interesting question. For example, under North Korean romanisation rules, the capital city is P'yŏngyang (with diacritics) whereas is it typically spelt just as Pyongyang by everyone else, including Wikipedia . --Andrewssi2 (talk) 01:22, 31 August 2014 (UTC)
I agree with Fabimaru that it is important to convey pronunciation for places that don't have a standard common print form in English. That either needs to be with lines over long vowel (more common) or doubling vowels (less common), preferably the first. Tokyo, Osaka, and Kyoto have a standard way, but most other places don't so the diacritic should be used, else ambiguity is introduced. This is how we've done it for other countries like Vietnam, Portugal, etc... Texugo (talk) 01:43, 31 August 2014 (UTC)
Kyotanabe, Kyotango, etc. all have established English names, and I don't see why we would allow diacritics in city links when the cities themselves don't use them. The 'ambiguity' is here is all self-created with our own inconsistencies. I live in Japan, so I can see the names that are used and these cities are never written in diacritics on anything official, travel brochures, (anyplace). Ignorant Wikipedians who are unfamiliar with the area probably created those pages (neither wiki article contains much info), but they don't need them. Incidentally, I've read diacritic arguments on WP and conversations I've read have a strong pro-diacritic brigade that tend to bully those with differing opinions. I tend not to use WP as a reference on this for that reason. When I do an English search, Wikipedia is the ONLY source that uses the diacritics which suggests that a name has been established and Wikipedia is actually the outlier. ChubbyWimbus (talk) 15:50, 31 August 2014 (UTC)
Hmmmm.. I dunno, I lived in Japan for many years as well, and I think the long vowel symbol is pretty common on train stations signs and the like since as you know there is a difference in pronunciation between きょう and きょ or おお and お. I'm not familiar with either of the places you mentioned, which is exactly why I'd like to know if there are long vowels. And regardless of how the local folks there might write it in English, I don't think they are well-known enough or widely written about enough outside the local area to have the same "established spelling" that Tokyo or Hanoi or what have you. Texugo (talk) 16:17, 31 August 2014 (UTC)
In my experience we've used diacritics when the original name is written in Latin characters (e.g. Västerås) and just in 99% of those cases (e.g. Zurich is written without the trema). When it's a romanized name like Pyongyang we haven't used them. ϒpsilon (talk) 16:28, 31 August 2014 (UTC)
That's a valid point, and admittedly, we generally haven't used the diacritic for Japanese locations so far. I just think maybe we should, because unlike the tonal languages like Thai or Mandarin, the full pronunciation info for Japanese can be conveyed if we just allow this one fairly intuitive symbol that most of us know from grammar school. Texugo (talk) 17:14, 31 August 2014 (UTC)
I approve of any kind of standard diacritics and the like, whenever there is no well-known and accepted standard English name for a place. Ikan Kekek (talk) 19:32, 31 August 2014 (UTC)
or for these well-known English name, just once in its main article (just like there is the kanji name) - Fabimaru (talk) 21:06, 31 August 2014 (UTC)
I can see the names that are used and these cities are never written in diacritics on anything official, travel brochures: I just checked (Google image search), the names on the JR platforms use the diacritics at least for Tokyo and Shin-Osaka (edit: so, not never, maybe often). - Fabimaru (talk) 21:06, 31 August 2014 (UTC)
The pronunciation help is good, but it should be separate from the place name, unless the real place name does include the diacritics. Västerås is Västerås, no one in Sweden would write it in any other way and I suppose there is no common English spelling differing from the Swedish one. In cases where diacritics are not part of the name, but a pronunciation aid for non-locals, we should be very clear about what the real name is. I also think it is problematic when links to a destination are written in a way that cannot be cut and pasted and used in the web address (as in the above cited case: Kyōtanabe is a redlink; genitives etc. are a different matter as they are obvious). --LPfi (talk) 09:44, 1 September 2014 (UTC)
Totally agreed, and the crucial point is your first sentence: The diacritics have to be in the official name. Ikan Kekek (talk) 09:47, 1 September 2014 (UTC)
In addition to the above reasons, the diacritic-included pronunciation is actually in the article beside the Japanese-language name. Take a look: Kyotanabe. So there is in fact, already no confusion in pronunciation to anyone who actually wants to know. Why don't we just establish this as a rule? Then we don't have to have diacritic discussions of this nature anymore. The pronunciation will be there while the actual city name can remain normal. Links from other articles don't need the diacritics in this case either, because if someone really cares, they should click the article. ChubbyWimbus (talk) 12:27, 1 September 2014 (UTC)
My opinion is that (1) using the diacritic is the most correct way to represent the name (2) people should care, and if we only put it in the main page then people will read (and then pronounce later) the name incorrectly. Also, I think that the diacritics should be used also for the points of interest (ex: temples…; with the same argument: avoid confusion when talking with locals, either in English or in a few words of the local language). Then in this case there would be a inconsistency between the norm used for the pages and the PoI. - Fabimaru (talk) 17:23, 1 September 2014 (UTC)
I'm not sure that I agree with your claim that "using the diacritic is the most correct way to represent the name". My inclination is to assume that the most correct way to represent the name is however the official publications (like the city's website, if it has an English-language section) do it. WhatamIdoing (talk) 20:53, 1 September 2014 (UTC)
Well, it is true that the macron is not the only way to accurately convey long vowel pronunciation information — there are other systems which convey the same information by doubling letters, etc. The macron is part of the Hepburn system, the most common system and one widely considered to be the best and most intuitive for English speakers, which figures into the JR railway standard and various official government ministry publications, etc. The second and third main systems do basically the same thing but with a circumflex instead of a macron. Some other systems use "oh" for a long O, etc. I think the point is that in terms of "correctness", as measured by the degree of certainty someone can have of pronouncing the place correctly without additional explanation, the current non-standard romanization at use in our Japanese article titles comes way down the list behind all those other systems, making no distinction between short and long vowels at all, meaning that common placename components like big (大, long o) and small (小, short o) get oddly represented as identical, and potentially introducing ambiguity. I personally don't think adopting an occasional single diacritic is such a huge sacrifice to gain the advantage of having names fully pronounceable. I think the very easiest and clearest way would be to follow the Hepburn system, for which we can easily use the WP titles as a model. I don't know or care who the diacritic enthusiasts of WP are, but in the case of Japanese placenames, the result is that they are spelled consistently and clearly, and I don't know why we'd prefer not to have such consistent and clear spelling.
At the very very least, we should be consistent. The only thing I can thank of that would be worse than our current unstandardized quasi-Anglicized system is the notion that we should attempt to follow whatever the local town governments have put on their websites. Those do not necessarily represent some consciously chosen spelling system proclaimed to be the correct one for their little town. A more likely scenario is that an underpaid city employee who speaks little English wrote some copy, sent it to a translation agency or the local gaijin English teacher, and then submitted it to their boss who also speaks little English, and it just gets assumed that whatever transliteration system the translator chose to use "must be correct because it came from a native English speaker after all". Or maybe they are simply written by someone unaware of the rules of existing romanization systems, or they don't know how to type the macron, or they opt not to type it just because the macron can't be used in the URL of their site and they want it to match, or any number of other reasons which don't necessarily imply that some "official" spelling has been declared. Trying to follow whatever they come up with for dozens and dozens of small town websites will just leave us with a completely heterogenous mix of systems, where we have random variation such as using "O" for the 大 in Oita and Ogawa but inexplicably changing to "Oh" for the exact same 大 in Oda and Otawara.
We should at least choose one romanization system and stick to it. I'd still say there isn't any good reason for us not to choose the same system adopted on both Wikipedia and JR railroad signs. Texugo (talk) 22:46, 1 September 2014 (UTC)

(Indent) I think the usefulness of the diacritics here is quite exaggerated. To be frank, the diacritics don't/won't help most foreigners. Most of them elongate the "o" sound naturally, so it's not a problem and they can't even hear the difference when they are told. And saying Kyotanabe vs Kyōtanabe is going to cause confusion is laughable. The foreign accent and non-Japanese appearance of the speaker are going to be what make you "hard to understand", not a lack of vowel extension. I tend to be against diacritics unless there really is no viable option, which is not the case here. Our article titles should not be thought of as pronunciation guides. We should just be giving the names, not "representing" the names. ChubbyWimbus (talk) 13:43, 2 September 2014 (UTC)

For sure if you reduce all the cases to Kyotanabe out of any context, yes it is laughable. What I am talking about is the pronunciation inside a conversation. It happened to me many times that I had to ask my interlocutor to repeat the names of French cities they were talkin about (French is my native language), and we both had decent skill in English. It also happened to me in Italian (even if French and Italian are supposed to be similar; I did not used the long vowels as it's supposed to be done in Italian). Or maybe it's just me who is bad :-) - Fabimaru (talk) 20:09, 2 September 2014 (UTC)
I'm not denying that it happens. Of course it happens a lot. English speakers don't even pronounce Paris correctly by French standards, but we didn't name the article Pah-ree or paʁi. We just call it Paris and leave it at that. If we want the proper pronunciation, I think it should go at the article lead but not replace the city's name. ChubbyWimbus (talk) 11:18, 3 September 2014 (UTC)
I would be glad if we could go forward with a consensus, because I don't want to submit any other name modification if I know that it may be reverted (you know, it takes time). What should we do? Wait for more feedback? Vote? I searched a bit more (it is as funny as reading the terms&conditions of an service :-( ), and in the recommmandation page concerning the Japanese names, it is asked not to use macrons in the page title. It has been added by Jpatokal in this WikiTravel modification in 2006. What puzzles me is that it is not exactly in line with the Wikipedia policy, which recommends using the name commonly used in English (if any exists, and it is not obvious to determine which one) and add redirections when macrons are used. My proposal is to use the same names (for page titles and other names such as those of temples, gardens and people) than in Wikipedia. I cannot see how the two projects could reach different conclusion for a name with the same rules. - Fabimaru (talk) 08:06, 6 September 2014 (UTC)
Different projects, different contributors, different goals. Wikipedia has a lot of editors who value accuracy above all else, including accessibility. Wikivoyage places more emphasis on the latter than Wikipedia does. Powers (talk) 13:38, 6 September 2014 (UTC)
Yes, we can be different if we choose, but that doesn't mean we shouldn't weigh the advantages and disadvantages. And in this case, I strongly agree with Fabimaru. Given that, as we do for other languages, we can use redirects to ensure people don't have to type the macron to reach the very small number of destination articles that the diacritic would affect, I am completely failing to see an accessibility issue or any other consideration that could possibly outweigh the various advantages of:
  • showing placenames the way the traveller is most likely to see them on highway signs and at train stations;
  • having a consistent naming system across all Japan articles, which avoids introducing arbitrary transcription differences like those I mentioned above;
  • removing ambiguity in pronunciation; and
  • never having to discuss case by case what the best spelling would be for a given destination.
Where are the comparable advantages of the current way? How does insisting on an inconsistent, arbitrary non-system we made up serve the traveller better than the most widely-used and recognized form of transcription that we ourselves use on the phrasebook page? Texugo (talk) 14:49, 6 September 2014 (UTC)
  • Actually, the version you are supporting is much more arbitrary and inconsistent than simply NOT using the diacritics, AND your way would in fact welcome discussions on any city that someone feels shouldn't use them, so your only argument is pronunciation aid, which I already addressed above. If we say "no diacritics", then we just write the names as they are (correctly). If we say "Okay" to diacritics, then we open every city to the "fame" discussion just like other places. We have to ask ourselves, "Is the non-diacritic name more famous and widely used?" and if someone says "no", it can always be questioned.
I already addressed the pronunciation argument, but I'll say it again; we don't and should not be using our article names as pronunciation guides. They're city names. If the name is difficult to pronounce for English-speakers or is pronounced in a way that is not obvious to English-speakers, let's put it in the article rather than messing around with the city names. It's a much simpler solution and can be applied to every city across the world. If we start doing it in all of our articles, users will also start to notice and be able to reference it.
I beg to differ that diacritics are "the most widely-used and recognized form of transcription" of the city names. That's not at all true. Kyotanabe doesn't [7]. Osaka doesn't [8] [9]. I never understand why people think Japan is such a "special" case when it's not. I notice the Wikipedia articles don't use pinyin for Chinese names. We don't either, because we don't name our articles to be pronunciation guides; we just write the names. ChubbyWimbus (talk) 16:22, 7 September 2014 (UTC)
That is just purely wrong. Hepburn romanization wouldn't exist as the most popular transcription system if it were arbitrary and inconsistent. It simply isn't. It is beyond ridiculous to insist that Hepburn, the number one way to write anything in Japanese in the western alphabet, is inferior with regard to pronunciation or in any other sense to our idiosyncratic, made-up non-system of maybe-Hepburn-but-disregarding-the-macron-except-sometimes-when-we-feel-like-putting-an-'h'-or-a-'u'-in-there-instead, depending on whether the website creator happened to subscribe to a third-rate non-standard transcription system. And if our decision is to follow WP spelling, as Fabimaru and I have advocated, there would be no reason for us to have any separate argument about spelling anyway, but even if we didn't follow WP — to the extent that it affects travel, with the exceptions of Tokyo, Osaka, Kyoto, and Hokkaido, there are no destinations that both contain the long O sound and are famous enough to have any standardized spelling the layman who hasn't been to Japan would be used to seeing in print. As the spelling system used officially by both the highway system and the rail system, Hepburn is very easily the "most widely-used and recognized for of transcription", and easily the system the traveler will be most likely to encounter on the ground in transit. Anyway, for you to say "we should just be giving the names, not 'representing' the names" makes very little sense. Any time you write a Japanese place name, you are choosing a way to represent it. And while we are choosing a way to represent Japanese placenames, there is absolutely no convincing reason why choosing to vaguely approximate but not actually follow any actual system would be better than choosing the most popular established system used by all the major forms of transport that the traveller is most likely to use. Texugo (talk) 20:46, 7 September 2014 (UTC)
It's also pretty hard to claim Kyotanabe doesn't use it. Texugo (talk) 22:34, 7 September 2014 (UTC)
To be fair, highway signs seems to always dismiss any mention of long vowels. But it was not my argument for using the macron (allows knowing the pronunciation without changing page, and having consistent usage of macrons for all the place names including points of interest) - Fabimaru (talk) 18:42, 8 September 2014 (UTC)

I don't need an irrelevant link to something that was already stated (or even linked?) above. Yours is of the JR station. My link was of the actual city and what the city calls itself (aka: relevent). Nice try though.

Your arguments about the Hepburn system are moot. The Hepburn system was designed for translating WORDS. We're talking about cities that already have English names. We don't have to translate anything. Also, you are using the modified version, not the original Hepburn system, which never used diacritics for elongated vowel sounds. And the Hepburn system is once again no more "special" than pinyin, which once again, we don't use. Of course based on how pro-diacritic people seem to be, it may just be a matter of time before China is targeted...

In response to your comments about Oda vs Ohda, Google produces many more results for Oda than Ohda (with Shimane), so I think it's safe to continue using it without being hypocrites. Whether you like it or not, these cities HAVE English names, so changing them to a phonetic representation is not better. I don't see how using their English names is NOT a convincing argument? I LIVED around Kyotanabe, and nothing in the city about the city in English uses diacritics. That's enough for me to say let's leave it alone. Adding diacritics would be the arbitrary thing to do. The diacritics REALLY aren't important for a traveler. Even those train station names are better known without them because Hyperdia doesn't use diacrtics.

Do you have a response for what's so wrong about just writing the pronunciation beside the name in the article lead? It seems like a win-win to me. The city name doesn't have to be changed and the pronunciation is there for people who are really concerned about being exact. ChubbyWimbus (talk) 13:10, 8 September 2014 (UTC)

The city name doesn't have to be changed: I can take care changing the names. So I (or any other person) do it, what is wrong with my approach? It's a win-win, those who are not concerned by the diacritics are still able to read it, and the other have the pronunciation information anywhere. - Fabimaru (talk) 18:42, 8 September 2014 (UTC)

I would appreciate if we have more opinions from other people, because the discussion is going round in circles. - Fabimaru (talk) 18:42, 8 September 2014 (UTC)

I would too but, I must say that I have just heard two claims that I feel are blatantly untrue and wholly unsupportable: the notion that Hepburn is only "for words and not for names" is completely ridiculous and I have no idea where you pulled that out of. Hepburn was designed to transcribe anything in Japanese, and placenames are constructed out of hiragana and katakana and kanji just like anything else in Japanese. Similarly, any claim that "Japanese towns all have an established name in English" is completely and utterly and laughably unfounded. I've already explained why above. Just because somebody, very likely not even a Japanese person from the given town, translated a website either using or not using a diacritic cannot in any way be interpreted as a statement on the part of the city that "this is our official name we consider to the the correct way to write our city name in English".
You have tried (unsuccessfully I think) to deconstruct the advantages that Fabimaru and I have given for adopting the most popular common transcription system, and you have tried to downplay the disadvantages we've pointed out in the current idiosyncratic approach, of insufficient pronunciation, introduction of ambiguity, inconsistency, and divergent transcriptions of things that are identical in Japanese. But what advantage are you offering?? What are you defending, and why? A system where instead of following a standard, we go case-by-case following whatever arbitrary decision was made by the person who did the translation of the website, regardless of which transcription system they happen to subscribe to, if any at all, and/or the evidence of Google searches made unreliable by the fact that Google searches ignore the macron, all because we want to... what? Where is the comparative advantage of the current bias against the macron? You are denying a system with more consistency, fuller pronunciation, and less ambiguity in favor of what, exactly? Even if I was inclined to concede all the points you just tried to make and pretend the current system has none of the disadvantages already pointed out, I would still see absolutely no convincing reason not to go ahead and use Hepburn. Texugo (talk) 22:13, 8 September 2014 (UTC)
Your claim that Wikivoyage discovered all these Japanese cities and therefore needs to name them is ridiculous. I've already shown that these places do in fact already have names. Kyotanabe has a name, and it doesn't include diacritics. You can whine about it all you want but that doesn't change the facts (nor does stating that what has already been supported is "wholly unsupportable"). This isn't about the Hepburn system; we didn't discover these places and I guess neither did Hepburn. They don't need special Wikinames. I'm not sure how you can even propose that looking at how a place name is written is not a viable way to see how it is written. If the city hall and all references to and promotions of the city that don't copy and paste from Wikipedia write it the same way, you say NONE of it can be trusted, simply because it's not written your way.
Please don't put words in my mouth. Nowhere above did I deny that the diacritics could not be useful for pronunciation. In fact, the suggestion I've made a few times, which you continue to ignore in favor of irrelevant Hepburn rants, is that we should give the cities their names and put the pronunciation in the lead beside the name. I'm not downplaying the advantages of the macron. The advantages are truly minute here. You're talking about adding a symbol to tell people to elongate an "o" that most foreigners already elongate, so who cares? The example above of when the diacritics are useful wasn't even a Japanese case.
The problem is, you are talking about the "advantages" of renaming cities, and while you have ("unsuccessfully I think" to quote you) tried to twist and refute my argument, my argument is that these places have been named. Since they've been named, we need not debate; we can just write the names. You talk about all these "difficult situations" that exist, yet no one has ever refuted any of the Japanese city name spellings. Why? Because they're established, and we all know it.
The anti-diacritic and pro-English stance of naming destinations is a Wikivoyage rule of naming, so the fact that you think it's stupid doesn't matter.
To recap the points that I'm making: We don't need to name named places (As I've said, I know Kyotanabe extremely well and the names we use have never been controversial, because everyone knows them), diacritics are to be avoided whenever there are English names (which there are), AND I'll reiterate my idea to write the names as they've been named but put the pronunciation with the name in the lede, which would be a win-win and could be applied across all non-English city names. ChubbyWimbus (talk) 12:03, 9 September 2014 (UTC)
Youour argument hinges on the claim that there is already a single official way to write every town name in English. Your chosen example was Kyotanabe, and I have already shown that even in that case there are at least two different orthographies the tourist will likely encounter. That means that no, in fact, there is no single English name for it. There are only competing transcription systems, at least three of them, and trying to determine in each case which to follow is silly because it presents no advantage. It would be prudent to choose one and be consistent. Texugo (talk) 13:05, 9 September 2014 (UTC)
My argument doesn't hinge on that at all. If it did, you could have just pointed to Wikipedia's arbitrary names as "proof". Also, your "proof" is a JR Station, which is named by JR West and has no connection to the city itself or how it writes its own name, so you have no proof. Do you want to name every city based on its station name? Above you said that station names were inconsistent and not credible, so have you changed your mind, or are they only credible when they say what you want them to say?
There need not be a "single" way to write a name in order for it to have an established name. We've dealt with many cities where there are slight variances in spite of having one established and common one, and I think you know that. Why do keep saying we will have to "try and figure out which case to follow" when the names are already clear? You keep talking about consistency, but we're already quite consistent; we've named the cities according to... their names. And saying "no diacritics" does in fact create consistency.

In doing a search in Japanese (in hopes of being fair) I could only find non-diacritic namings: Kyotanabe is Kyotanabe [10] [11] [12] [13] [] Soja is Soja [14] [15] [16] [17] [18] I tried to find them written with macrons, and they didn't exist. The only inconsistency that I could find on an official page was that Kyotanabe's Chamber of Commerce website forgot the "e" at the end of the name [19], but we all know it should have the "e" so there is no controversy. Using the diacritics would be just as I said, a special Wikiname that does not reflect reality. That's why I will once again suggest naming the cities without the diacritics and then writing a pronunciation aid beside the city name at the beginning of the article. ChubbyWimbus (talk) 13:46, 10 September 2014 (UTC)

I cannot fathom how it is so easy for you to dismiss the evidence to the contrary. Again, the reality in the ground is the the diacritic is, quite indisputably, used as well. Even if we limit discussion to only your example, the very first thing the very vast majority of visitors will see is a sign using the diacritics. I already posted that pic above and you somehow tried to dismiss it. And that being the case, it's simply not possible to claim that I'm advocating some "made-up wiki name". There are, as I stated, multiple transcriptions in use, on the ground, in reality. It would be far easier to pick one than to go case by case relying on difficult google searches to trying to determine which transcription to use and end up with a collection a Japanese articles which are not titled consistently according to any single established system. If there is any "made-up wiki system" here, it might be the current one that eschews existing standardized spelling systems in favor of a "go with whatever flow you can discern from google but avoid macrons at all costs" approach. Texugo (talk) 16:53, 10 September 2014 (UTC)
The reason you cannot fathom it seems to be that you aren't reading what I wrote, because I've addressed your ONE example above. Do you even remember your own example? It's the JR station to refresh your memory. Please reread my last comment. It has been addressed. I've addressed all of your comments while you continue to state that I am "ignoring" them. It's getting old.
My examples are "on the ground", relevant to travelers, and plentiful, while you are clinging to ONE station name that not only I addressed but YOU yourself called unreliable. Your ONLY source in unreliable by your own admission and , to repeat myself again, a single example does not show that it's an established name. Mine are all reliable sources. That is fact. Your assertion that your way of writing is all over cannot be taken seriously since you have no proof aside from a station name that we've both refuted. How does my proof hold less weight than your word? You don't even know the city. I've both provided evidence AND know that area yet you pretend you know what it's like "on the ground level". Clearly you don't.
And once again, you talk about all these Google searches, "difficulties", and pandemonium without an "established system". Sorry, but there aren't any difficulties and the naming system is well-established and really simple; use the city's name. No one is confused about the naming conventions except you apparently. You are the only one who seems to require Google. The rest of Wikivoyage has been naming these cities without controversy for a long time. Where are the confused masses you pretend exist? At this point, your argument seems to have boiled down to unproven blanket statements, false claims that I've not addressed what you've said, and claims about naming confusions that have never and still don't exist. You've ceased responding to the information I've given you and continue to reiterate things that I've addressed multiple times. I've even proposed a solution that includes the pronunciation guide 5 times. ChubbyWimbus (talk) 18:00, 10 September 2014 (UTC)
I am really sorry. I hope we can reduce the level of emotion we seem to be investing in this. Maybe you didn't mean certain claims the way I took them, and I certainly didn't mean some things the way you seem to have taken them.
We are just looking at this from different perspectives and talking past each other.
What I see is 京田辺. I see 大田. I see 安城. And lots of other placename with various sounds. And for each, regardless of who writes it or where, there is one way to write it in Japanese, and multiple ways to write it using the alphabet which are being used on the ground. You are surely aware that the long O sound can be written with a macron, with an oh, with an ou, or with o with nothing signifying its length. The づ sound can be written as du or dzu or zu. The しゅう sound can be written as shu or shuu or syu or syuu or shū or syū. If you gave any placename containing any of these sounds to 20 Japanese people and told them to write them down in English, you'd definitely get a range of spellings. So, if you are claiming that all Japanese places already "have a name in English" that we should use, what I do not understand is: how do we know which of the possible spellings that supposedly established name is? Where do we find this "established name" you speak of? What is our source? The only possible answers I have seen implied are
a) we look at the town's website - If this is our answer, I wonder what you suggest when a place doesn't have a website, or has no English on its website, or uses machine translation on its website, or contains internal inconsistency on its website. Do we assume the website reflects some "official sanctioned" spelling even if the name is written nowhere except in the url or the copyright notice? Do we take the official town website spelling even if local tourism infrastructure tends to use a different spelling? If a town website does use a diacritic, do we use it too?
or
b) we look at Google results - In this case, it is rather difficult to get a clear answer on the most common placename orthography because place names coincide with business names and personal names, because Google ignores diacritics in searches, etc.
Ok so then, if that question is satisfactorily answered, the next thing I don't understand is: why is that better than following a standard orthography that always writes the same sounds in the same way? Given that we know people will see the placenames spelled different ways in different places no matter which spelling we choose, how is matching city hall websites or whatever case by case more advantageous than spelling things consistently and unambiguously using a recognized common system? Since most Japanese placenames are pretty unknown to westerners, and since there are multiple spellings of many of them to be found out there anyway, when I weigh the existing system against the advantages of following an established orthography system (still very minimal diacritics - just one, improved pronunciation information conveyance, using the same spellings to write the same sounds/kanji, simple check of WP instead of digging up city hall site/google search, etc), then I still wonder: Why are you so vigorously defending the current system versus those advantages? It must have some bigger advantages that outweigh them, right? That is what I do not see. Texugo (talk) 23:14, 10 September 2014 (UTC)
The way I look at is that 99.99% of the cases, we would not need to consult sources. The names simply are. Do we really need sources for Kyoto? Kochi? Oita? I don't think so. Perhaps some of my views of the "obvious" are because I'm talking about places I've been and often visit, so I have seen more than even an internet search will allow. If however, someone DOES questions a name, such as Kyotanabe, then we can of course do a search and provide proof of our assertion. In Kyotanabe's case there are not only official websites from the city and tourism bureau, but also the university, which is known throughout the nation, spelling it with no diacritics, no "oo", and no "oh", so there is plenty to show as proof of its established name. I did the same with Soja above.
Modern naming conventions have almost completely dropped the "oo" and "oh" from usage, so they will generally not be an issue.
The only major case of the "oh" still being used in English that I am aware of is that of Minoh (Minō). Even Wikipedia uses Minoh [20] instead of Minō without anybody questioning it (and we probably should, too. Our way, Mino, with or without the diacritic is less common than Minoh or Minoo, but Minoh is really the dominant name). You pointed out the city hall website of Oda city using Ohda. Most sources in English use Oda, though. If however, you or someone else were to say that Ohda is the name, it could be discussed and considered. If we need sources, we should never use just one to determine the name anyway, regardless of what country the city is in. Google actually corrects the name if you type "Ohda Shimane" which is another indicator that just Oda should be used. But cases that may lead to discussions are very rare.
I would much prefer to review controversial names than to choose a single naming convention for an entire country without regard for how the name has actually been transcribed. It would seem to be against our goals to establish such a system and it would not be to the benefit of the traveler. In the Minoh example, to say that Minoh and Minoo have both been cited and therefore we will use Minō follows no sense of logic and is no help to the traveler. If the discrepancy is between "oh" and "oo", then we should discuss it and the result should be one of those, not something completely different. Pronunciation guides are useful, though, and do have a place, but it should not supersede all other naming rules. That's why I still think it best to write the names as they are written in English (with discussion if "the way it is written" is truly unclear). I think requiring a pronunciation guide in the article lead would be a great improvement to Wikivoyage for all cities with non-English name origins, but I'd keep them out of the article names themselves for the reasons I've stated above. ChubbyWimbus (talk) 09:22, 11 September 2014 (UTC)

Well, I don't have anything else to add really, and maybe you don't either. Summing up, I still see a plurality of orthographies that anyone writing about a given place has to choose between, and the fact that a city hall has had to pick one for their own writings does not to my mind imply that their choice therefore constitutes an "established" name in English. And since I think there is at least reasonable doubt in my mind as to whether there are universally "established" names in English, it is very hard for me to see what advantage an unstandardized selection of dubitably "established" spellings has over a clear and consistent and fully pronounceable orthography system recognized as the most widely-used romanization and adopted by various government agencies including the national rail system that is by far the most common choice of travellers. I have tried my best to explain and support my position above, as have you, and neither of us has managed to convince the other. Now I'm pretty tired of this conversation. Maybe we should hear from some other users who are less familiar with Japan and Japanese. Texugo (talk) 23:41, 11 September 2014 (UTC)

I suppose we have both stated our arguments. I just don't see why we would/should establish a naming convention for one country that supersedes our established naming convention rules makes sense or is necessary, particularly when it is a country where names have been transcribed already in a variety of English materials. To me, it seems we should always at least try to take into consideration how a city's name has already been written in English (as I tried to show with Mino, our current name and the proposed naming conventions completely ignore that the name is most commonly written as "Minoh").
On the note of attracting other user comments, I think we may have confused or scared others away (lol). ChubbyWimbus (talk) 13:57, 13 September 2014 (UTC)

I'm a bit late here, but this discussion really belongs on Wikivoyage talk:Romanization. Nonetheless, I'll summarize my view, which is essentially unchanged since 2006: for non-Latin scripts in general and Japanese in particular, use of diacritics is essential in pronunciation guides, but adds little to negative value in article titles due to the broken link problem. I don't care deeply either way about using macrons in link titles, but it seems a bit pointless.

Also, Hepburn is *the* standard for romanizing Japanese and any alternative spellings should be nuked from orbit. Wikipedia's "use the most common name" policy is a snakepit of endless, pointless festering disputes (I think you'll agree that the discussion above proves this point rather handily); we have the luxury of being able to dictate our own polocy, and "use Hepburn, no macrons" has worked pretty darn well for Japanese place names to date. Jpatokal (talk) 11:58, 28 September 2014 (UTC)

Is it the way to do of all the Administrators of Wikivoyage[edit]

I'm a contributor for several months after my last add on the page of "Les Saintes" I received this post:

[les Saintes]

And this action against me: MediaWiki talk:Spam-blacklist#craigarush dot com, lessaintes-booking dot com

Is "Ikan Kekek" alone when he insultes the "integrity" of a regular contributor or it is the new commun spirit of Wikivoyage ?

Les Saintes (talk)

This looks like you are trying to advertise your own business on Wikivoyage? You may want to look at Wikivoyage:Welcome, business owners and Wikivoyage:Don't tout. There are also restrictions on what we link - we may link to the "official" site for a destination or an individual venue, but do not link to booking agencies or other middlemen. We also avoid links to other travel guides. If you wish to post factual and fair information about a city or destination that primarily benefits the traveller, by all means go ahead... but please avoid promotional hype and blatant advertising. K7L (talk) 00:53, 2 September 2014 (UTC)
URLs aren't put on the spam blacklist except in cases of repeated abuse, which you can see I detailed. You are not an official governmental site and cannot promote your site here. Ikan Kekek (talk) 04:06, 2 September 2014 (UTC)

Please stop the bullshits and ask around U We are in charge to promote the tourim activity in Les Saintes... we are not a real estate!!!! or a travel Agency !!!!?????

The "tourist" "Books" directly with the Owners, there's no fees, no charge or no "Strange threat" behind this site...

Please have a look on the site to understand how its work!

Sorry for your "plot Theory" we hare not the rights guys for you !

Les Saintes

I'd suggest that maybe you shouldn't be in charge of tourism of Les Saintes if you can't help swearing on a public website. Andrewssi2 (talk) 14:55, 2 September 2014 (UTC)
Furthermore, Les Saintes, I would suggest that if you want to continue editing Wikivoyage that you refrain from behaving in an abusive manner toward other editors. Civility is something that is taken very seriously here, and if you can't control yourself we can and will ban you from editing, so consider yourself warned. -- AndreCarrotflower (talk) 15:55, 2 September 2014 (UTC)
Can we slow down a bit here?
Yes, this user seems to be advertising a web site in a way that violates our policy at what we link. He claims it is the official site; I'm willing to assume good faith (the claim is made honestly), but I'd need evidence before actually believing it. Googling "Les Saintes tourist office" turns up several other sites making similar claims and I cannot tell if any are valid. Our Guadeloupe article links to an apparently official site which has a Les Saintes section; until and unless I see evidence otherwise, I'll assume that is the official site for Les Saintes, hence the only one we should link to.
On the other hand, checking the user's contribution record, I do see positive contributions. K7L says above "If you wish to post ... by all means go ahead"; it seems to me this user has already done some of that, so I'd say a ban beyond the three-day cooling off already imposed (Wikivoyage:User_ban_nominations#User:Tourtravelets) should not be considered. The problematic link is blocked and should remain so unless evidence is presented to justify unblocking, so there is no need to block the user. Pashley (talk) 17:01, 2 September 2014 (UTC)
First of all, Pashley, Tourtravelets is a separate case involving a completely different user. Les Saintes is not currently the subject of any ban, of any duration. However, between swearing at K7L and leveling baseless accusations of ethnic prejudice at Ikan Kekek, I think that in the event of a continuation of the behavior pattern displayed above it would be completely reasonable to impose a similar three-day cooling-off ban on Les Saintes. -- AndreCarrotflower (talk) 18:33, 2 September 2014 (UTC)
According the human rights and in a lot of modern country: a person is presumed innocent and after strong evidence she could be judged guilty…

If I understand your rules," lessaintes-booking" is presumed guilty and for some of you already judged guilty….

After a look on The Guadeloupe page and its private and personal links, my honesty can't be offended anymore.

To resolve the problem I propose to ban "Myself" forever …

Les Saintes

Les Saintes: All we ask of our editors, and all we are asking of you, is to follow policy and treat other editors collegially and respectfully. The vast majority of Wikivoyagers, both newbies and old hands, have no problem with those two things, but you have openly refused to do either of them despite numerous instances in which you have been advised. Accordingly, perhaps the resolution you propose is best for everyone. -- AndreCarrotflower (talk) 23:08, 2 September 2014 (UTC)
Les Saintes, Pashley stated above that he found other sites that also claim to be the official site of Les Saintes. You bring up the courts, but in fact, if this were a court case, the burden of proof would indeed be on YOU to prove that your site is the official site. If it is the official site, your time would be better spent inquiring as to HOW you can prove it rather than swearing at people. ChubbyWimbus (talk) 11:25, 3 September 2014 (UTC)

Position and size of maintenance tags[edit]

To separate some discussion above from specific tag proposal. I would like to propose that some maintenance templates be made smaller and/or moved to the bottom of article pages. For example the fact that there is useful text on the German site for Kassel is self-evident and although suggesting someone do some translation work is a reasonable thing to ask I do not think it should be the first thing a visitor to this site reads about the town.

The question is which tags should be moved to the bottom of the page and which should have a smaller footprint on the page? As an example I have created a small option for the translate and districts discussion templates, looks like this:

Translation Latin Alphabet.svg Translate from de
Information Talk on defining districts

Other like delete would probably stay large and at top of page. What about the others? As for moving from top to bottom this would be a relatively easy script to write if other agree this is the thing to do. --Traveler100 (talk) 11:55, 3 September 2014 (UTC)

I agree. I can't think of anything but delete that should remain at the top. Perhaps copyvio if we have a template for it (and not remove copyvios on sight). PrinceGloria (talk) 11:57, 3 September 2014 (UTC)
Anything that does not impair the ability of the traveller to use the article should be moved to the bottom, to the talk page or out of the way. As article space is traveller-facing, the print version matters, the off-line version matters. Someone carrying a copy of WV on a microSD card isn't going to be able to redistrict the article while they're waiting at the baggage carousel. K7L (talk) 14:46, 3 September 2014 (UTC)
As I said above, if it's something that the average reader could fix, I don't mind it being present in the mainspace. If it gets complicated (say, coordinating multiple pages) or requires technical skills, then I'd rather have it on the talk page. I'd probably keep the translation tag, because that has two purposes: (1) please help us by translating, and (2) notice that if you can read German, the German article is probably better than ours, so you should go read that, too. WhatamIdoing (talk) 15:45, 3 September 2014 (UTC)
By categorizing the correct page and not the talk page, we can cross-reference. I can find "guide cities with a style tag" or "merge candidates in Germany" or "outline regions with translation tags" or "countries with two or more maintenance tags". I can run metrics and find where problems are concentrated. If you move tags to the talk page, they categorize the wrong page, the category links to talk pages, and none of the above is possible any longer. I heartily oppose putting any tags on the talk page. I'd be more likely to support completely hidden tags which don't call any attention at all before I'd support moving them to the talk page (for the record, I do not support invisible tags either). The only possible exceptions might be the {{regions discussion}} and {{districts discussion}} tags, since those actually refer the talk page directly, but even those would become pretty pointless if they only went on the discussion itself.
On the other hand, I can support moving certain tags to the bottom, mainly ones which are general or have no obvious place in the article, like {{transcription}}, {{translate}}, {{merge}}, {{merge from}}, etc. Some tags pertain to a given part of the article though, and {{style}} even has a comment field often tailored to the section it's placed in. It'd be weird to put {{crop}} at the bottom too.
I'm also supportive of attempts to make the tags somewhat less conspicuous but I don't want them to appear too cryptic. Perhaps we might use a mouseover to still give some guidance and not lose the comment fields from the style tag, etc.
Texugo (talk) 16:26, 3 September 2014 (UTC)
Thinking further, I'm not sure if I could support small tags of the exact type proposed for anything not moved to the bottom. Any tag in the article may need to remain centered or else people will be tempted to craft article layout/images around them. Another thought is that as K7L mentioned, we don't want any tags in the print version- this can be done regardless of what tags look like or where we put them. We should have "noprint"-ed them long ago. As for offline versions, I suppose it probably depends on the download source, but we may have some back end control over that too. Texugo (talk) 16:38, 3 September 2014 (UTC)
Wikipedia moves article quality (stub, start, A, B, C, good, featured) and article importance to the talk page - they're in the WikiProject boxes. Moving all of this rubbish to talk: would allow the cross-reference you suggest? K7L (talk) 17:50, 3 September 2014 (UTC)
Moving the maintenance tags and the status tags to the talk page would only allow for cross-referencing between them, but it would completely cut both off from cross-referencing with the geo hierarchy categories, which cannot be moved to the talk page. Texugo (talk) 17:56, 3 September 2014 (UTC)
It'd also cut them off from cross referencing with other maintenance categories generated from non-tag templates like pagebanner, routebox, map frame, etc. Texugo (talk) 17:58, 3 September 2014 (UTC)
Not to mention that it would mostly defeat the point of the status templates to put them on the talk page. On WP, different WikiProjects might have different assessments of each article, and the bottom of their articles is already cluttered. Powers (talk) 18:27, 3 September 2014 (UTC)

My own proposal would be to put the somewhat more complicated and contentious issue of placement on the back burner for the moment and start by overhauling the standard dimensions and font sizes and tightening up the wording a little (but still making the same point), so that the boxes are smaller and less conspicuous. Since the {{style}} tag is by far the most common one we have, I'll start there.

When no comment has been entered: we trim the wording a little and reduce the size from this:

to this:


When a comment has been inserted, we cut the standard wording a little more, and go from this:

to this:

We could start by applying this change, using the exact same new style for all existing tags, and all it would take is a few changes to the templates and presto, we'd have smaller, less conspicuous tags. I think it would be great if we could all agree to go at least that far and take that kind of step soon. Then at least we'll have already accomplished something and can continue to discuss the more complicated things like placement issues and complete tag redesigns. It'd be better to take a few steps in a direction we can all agree on first than it would to hold out for more radical overhauls which may never get the necessary consensus. Comments? Texugo (talk) 23:06, 3 September 2014 (UTC)

I agree on decreasing the size while other changes are being discussed. Ikan Kekek (talk) 23:38, 3 September 2014 (UTC)
Let's see what some others look like when tightened up the same way:
{{crop}}:



{{merge}}:


{{movetodistrict}}:


{{translate}}:
I think these are a substantial improvement, at least as a provisional solution. Texugo (talk) 01:30, 4 September 2014 (UTC)
Support the smaller font as first step. Other option I had thought of was a small icon and couple of words with an expand button to get the full text. --Traveler100 (talk) 07:05, 4 September 2014 (UTC)
I agree those look like improvements. The recent Wikimedia-wide font changes had a side effect of making warning boxes bigger (because text was enlarged) and while these new boxes go even smaller than they were before, I don't think they're too small. Powers (talk) 18:20, 4 September 2014 (UTC)
Great, that's four supports so far. K7L, PrinceGloria, WhatamIdoing, anyone else, can we all agree this is a step in the right direction? (fingers crossed!) Texugo (talk) 00:46, 5 September 2014 (UTC)
It's certainly better than the huge original banners, but I lost track in the discussion - what's wrong with the small tags to go to the bottom of the article that Traveller100 proposed? Unlike Wikipedia we have very little "down under", but we have the banner at the top, so I guessed this was a perfect solution for us. PrinceGloria (talk) 04:14, 5 September 2014 (UTC)
There are a few issues that will make getting consensus for the original proposal more difficult: they'll draw almost no attention at the bottom (less than I'd like); putting them at the bottom may give us stacks of three or more; reduced size may not be appropriate for centering if we don't move all to the bottom yet right aligning them would interact with content formatting; not all tags can be simply moved because they contain text tailored for the specific section where they've been placed and the context would be lost (style tag instructions, in particular). Rather than getting bogged down in trying to iron out all that and risk getting the whole thing shelved, I figure my proposal of shrinikng them is an at least an interim step that everyone can probably get behind first, while the more contentious and drastic changes are discussed. Texugo (talk) 10:58, 5 September 2014 (UTC)
I would prefer to keep at the top, especially the Translate tags. This is because we really want to get the attention of someone who can help translate! Merge should also be kept at the top because it indicates straight away that the article may disappear soon.
Movetodistrict is usually placed in each relevant section anyhow. Crop is probably the least important and could go at the bottom. Andrewssi2 (talk) 13:37, 5 September 2014 (UTC)

But Andrewssi2, before we discuss changing the placement (which I also oppose), do you have any objection to making them smaller like all the examples I gave just above? We have five supports and no opposes so far... Texugo (talk) 14:49, 5 September 2014 (UTC)

I have reduced text size on the tags but what method did you use to reduce the size of the table?Or is it just the reduction on amount of text? --Traveler100 (talk) 14:50, 5 September 2014 (UTC)
I support the smaller sizes of the tags. Andrewssi2 (talk) 14:54, 5 September 2014 (UTC)
Done! Maintenance templates are now smaller. If people still want to discuss changing the placement of templates, further redesign, etc., this might be a good place to draw a line and start a new sub-thread. Texugo (talk) 14:26, 6 September 2014 (UTC)

Texugo, you said that you can't cross-reference categories if one is in the mainspace and the other is in the talkspace. That problem has been solved before on other projects. How exactly are you doing this cross-referencing? Perhaps the tools here need an upgrade. WhatamIdoing (talk) 22:26, 7 September 2014 (UTC)

Quick intersection can do nothing if the categories are not on the same page. Catscan can find category-in-main-namespace vs. template-inclusion-on-talk-page or vice versa but cannot cross-reference categories from each, so it could not find, for example cities + needing translation from German, if the {{translate}} tag were on the talk page. None of the [Mediawiki extensions] can handling categories split between main and talk pages. If you know of any tools I don't know about, please do let me know. Texugo (talk) 22:56, 8 September 2014 (UTC)
This is creating a list based on the intersection of a talk page and many main page categories, so I know it can be done. I've never been very good at CatScan. Have you ever talked to the maintainers about it? WhatamIdoing (talk) 19:16, 9 September 2014 (UTC)
That page is just a list maintained by a customized bot written specifically to crawl the categories and compile the list periodically (and also appears to be comparing tag-x-category rather than category-x-category); it's not a dynamic tool that a non-programmer could utilize to cross-reference whatever they want. And no, haven't talked to the maintainers, since I've never had any interest in developing such a workaround - there are still additional non-technical reasons to oppose putting them on the talk page, even if it made no technical difference. Texugo (talk) 22:02, 9 September 2014 (UTC)
Yes, but the fact that a bot has been written to do this proves that it's technically possible to do so, even if the current tool would need to be upgraded to do it. WhatamIdoing (talk) 15:08, 11 September 2014 (UTC)
Not necessarily. Updating that page may very well take a couple or hours or more every time. That is very probably why it's a static page that's updated periodically instead of one that's generated on the fly when you open the page. Just because a bot can be made to spider through and cobble a list together does not necessarily mean that a timely query-and-response tool is right around the corner. Texugo (talk) 15:51, 11 September 2014 (UTC)

Iseo: city guide status?[edit]

Can Iseo page be upgraded to City Guide status? If not, please tell me what I should add or edit. Thanks --Lkcl it (Talk) 12:29, 3 September 2014 (UTC)

Check out Wikivoyage:City guide status. The article looks well formatted, so the question is whether everything most visitors need is there. It's a small town, so I guess everything worth mentioning is already in the article, however you probably know better. A picture or two towards the end maybe? I've seen much larger cities with about equally long articles that have been tagged as Guides, so I think it's safe to upgrade this one too. Ps. It's not a requirement for Guide but I notice there are strikingly many red links in the article - so if you know more about the region... ϒpsilon (talk) 16:40, 3 September 2014 (UTC)
I'll work also on the redlinks, the article will not be guide, but I'll do my best! and ... please forgive me for my mistakes. --Lkcl it (Talk) 17:03, 3 September 2014 (UTC)

Grants to improve your project[edit]

Greetings! The Individual Engagement Grants program is accepting proposals for funding new experiments from September 1st to 30th. Your idea could improve Wikimedia projects with a new tool or gadget, a better process to support community-building on your wiki, research on an important issue, or something else we haven't thought of yet. Whether you need $200 or $30,000 USD, Individual Engagement Grants can cover your own project development time in addition to hiring others to help you.

Such a great opportunity to improve Wikivoyage but its pity that this is going unnoticed. We've plenty of ideas already in place. It would be great if someone can take the charge. Maybe Ryan? --Saqib (talk) 19:52, 23 September 2014 (UTC)
I'm in the final weeks of a long trip with limited internet access, so unfortunately I'm not in a position to help organize anything at the moment. Hopefully someone else has the time and ability required. -- Ryan • (talk) • 15:35, 26 September 2014 (UTC)
User:Tbennert is below planning some kind of series of meetings with tourism professionals with intention to promote Wikivoyage. Perhaps he would be interested. ϒpsilon (talk) 18:24, 26 September 2014 (UTC)
Thanks for thinking of me! I actually did receive one of the grants during the last round. I agree there are a lot of possibilities. Picking a path and keeping a tight focus is probably the hardest part. My understanding is that there are proposal periods each spring and fall, so even if no one is ready this fall perhaps they could prep for the next round. --Tbennert (talk) 03:37, 27 September 2014 (UTC)

"The traveler comes first" vis-à-vis locals[edit]

Can anyone expound on potential ways a local in particular might stray from "the traveler comes first" when building their hometown's travel guide, and offer advice on avoiding that? — Athelwulf [T]/[C] 11:11, 5 September 2014 (UTC)

The problems I see most often coming from locals enthusiastic to make a guide on their hometown usually involve giving too many options, or all options, making it more like a phone book than a travel guide. If you put every single neighborhood park, it's hard for the traveller to pick out the best from the list. If you include loads of info on bus stops in obscure parts of town, it's harder for the traveller to find the info that's more likely to be relevant. If a city has 27 bowling alleys, we don't need to list all of them. To find the things he or she needs, the traveller shouldn't need to sift through lots of furniture repair shops, dermatologists, 13 McDonalds and 7 Subways, office supply stores, counciling centers, quilting clubs, realtors, catering services, day cares, public schools, community college rec rooms, and other stuff that travelers typically do not need. Sometimes locals get so wrapped up in trying to show their town has lots of options, and they forget that a travel guide's job is to help the traveller find the best options. Texugo (talk) 12:29, 5 September 2014 (UTC)
Thanks! There was good advice out there already for business owners and other folks, but I couldn't find anything that addressed locals. This helps. — Athelwulf [T]/[C] 03:02, 6 September 2014 (UTC)
I'm not sure how far the "Understand" section of articles should go. It can contain general info such as history, demographics, culture. It's interesting background for the traveller, but is not travel info per se. Do we have a guideline about how far it should go? Nurg (talk) 04:36, 6 September 2014 (UTC)
I'm pretty sure we do not. If you'd like to start a draft, that would be great, and I will definitely look at it and see whether I can help. Ikan Kekek (talk) 04:39, 6 September 2014 (UTC)
We don't have any firm guidelines on it because it is all very relative, depending much on the destination's size/age/importance/uniqueness in relation to the size/age/importance/uniqueness of other places in the same region and in relation to its wider region/country/continent as a whole. What's notable and relevant background info for travel to one city will not necessarily be the same type or the same volume of information as it would be for another city of the same size in another part of the world. Texugo (talk) 15:13, 6 September 2014 (UTC)
This looks to me like a solution in search of a problem. I think the best course of action is to avoid regulation creep, give contributors (especially well-established ones) as free a hand as possible to develop articles in a way that makes sense to them, and address disputes on what is and is not appropriate content on a case-by-case basis. -- AndreCarrotflower (talk) 15:41, 6 September 2014 (UTC)
Maybe adding favorite new restaurants, and not sticking around long enough to remove the listing when the place goes under. (Restaurant failure rates are pretty significant.)
For people from very small towns, starting a page at all might occasionally be another issue. I added this listing to a nearby town. The restaurant is regionally famous, but it's practically the only thing in that entire town (population < 250). A travel guide for that town would pretty much say, "Eat dinner here, and then leave". WhatamIdoing (talk) 22:33, 7 September 2014 (UTC)
Sometimes tiny villages are created with little or no content - someone drops an empty template just to claim their pop-250 unincorporated village has a listing, but adds no content, adds their own business (as there's nothing else there) or adds something highly generic like "Do: hiking, fishing" with no other detail. Self-promotion is a risk; conversely "municipal property taxes are too high" isn't travel-relevant. Another risk is that locals are often last to notice that a once-respectable hotel has deferred maintenance and let service standards decline, because hotel/motel operators market to travellers, not locals; the first warnings are negative reviews from travellers. There's also a risk of getting too much detail (we don't care who is running for mayor or what day the recyclables are put at the kerb) or listing items which aren't travel-specific (there's this great lumberyard, so if you're staying long enough to build a house...). Certainly, businesses are known to open to great fanfare and close quietly, so even a local might need to drive by and see if everything listed still exists. K7L (talk) 15:10, 8 September 2014 (UTC)

Results from Major Search Providers[edit]

Has any authority (related to Wikivoyage) noticed and attempted to resolve search results that should but don't reflect Wikivoyage content? Moments ago, on Google and Yahoo Advanced Search, queries for "Quebec City" (only) resulted in no "hit" for Wikivoyage, but one or more hits for Wikitravel. Only if "Wikivoyage" is made a required parameter do hits for Wikivoyage appear. This appears the case for many destinations. Does this not reflect an error in search provider algorithms that adversely affects us? Hennejohn (talk) 18:26, 5 September 2014 (UTC)

This is a well known problem for us, although not really an 'error' as such by the search engines. See Wikivoyage:Search_Expedition and the many discussions on Wikivoyage_talk:Search_Expedition. Andrewssi2 (talk) 23:45, 5 September 2014 (UTC)
This really needs to be adressed. WikiVoyage is far too irrelevant to Search Engines, in contrast to clumsy WikiTravel. If we don't overcome these issues, we might just as well go back to editing Wikipedia articles. Cheers, Horst-schlaemma (talk) 09:29, 6 September 2014 (UTC)
Well, Wikipedia articles are for a different audience and have different content. There is no harm working on both.
The links I provided should demonstrate to you that people are proactively addressing this and are seeing some minor victories, it is just a rather difficult thing to fix. You are also welcome to get involved. Andrewssi2 (talk) 09:35, 6 September 2014 (UTC)
Yes, and for the record, there are many in our community who started out at Wikivoyage and only began editing Wikipedia later; still others who've never edited Wikipedia at all. -- AndreCarrotflower (talk) 14:27, 6 September 2014 (UTC)
I don't intend to pit the Wikis against each other. I'm just saying that people are (way) more likely to end up at Wikipedia if they look for information about some place, rather than at Wikivoyage - which may cater to their interests far better. We should make sure Wikipedia links back to Voyage more. I'm also rather good at SEO mechanisms, but not at Wiki scales I fear. And frankly I wouldn't know how to make my way into the code. When I got to know more about how it actually works I could come up with crucial advice to improve the results. Cheers, Horst-schlaemma (talk) 20:59, 7 September 2014 (UTC)

Just a few random thoughts on getting more visitors to WV

  1. We started out with a lot of content from elsewhere - since most of the information we started with was imported. I believe that search engines can detect that and put WV at the bottom of pile.
  2. Have good quality content.. (as few errors as possible) - which we are striving for and doing very well at. Regularly edit and update article pages as well as provide new content - valid links etc. Quality means more much more than quantity - at least in my mind... "Build it and they will come"
  3. Meta tags - Meta tags I understand are not as important as they used to be (meta title, description and keywords)
  4. Links - backlinks from MW
  5. Perhaps some kind of useful tool or tool(s) built into WV to assist the traveller. -- add audio file for various phrase books (do we have that ability), currency conversion tool (could be a bit tricky)
  6. I don't know if an RSS feed would be useful, or share Star articles on social media? Do any of the Wikis have a blog somewhere or is that even a valid suggestion?
  7. Format - in most instances WV has an article format and structure that we follow. What do our visitors think? - pages too long or too short - is the layout great or boring - are we well organised or not? Does the visitor have a way of providing that input -- did visitor find information useful or not or find what they were looking for... perhaps a survey page? Cheers! Matroc (talk) 22:58, 7 September 2014 (UTC)
Matroc, the last item on your list intrigues me. For all the efforts we've made lately to attract new readers and take a bite out of the lead WT has over us on Alexa, one thing we've inexplicably never tried doing is engaging our users - not just the regular contributors and community bigwigs, but the average folks who happen upon our guides after a Google search or stumble in from Wikipedia - and asking them directly, on pages that are easily accessible to newbies who don't know their way around, how we can better do what we do. When it's the same old names doing the deliberating, it's easy for the decision-making process on how to present content to become stale or entrenched. We should reach out to readers who may not ever chime in on a policy discussion and find out what they would like to see on Wikivoyage that's not already here, what we aren't doing well and should be rethought or abandoned, etc. -- AndreCarrotflower (talk) 23:57, 7 September 2014 (UTC)
Regarding social media, Wikivoyage currently has a Facebook page and a Twitter feed which are updated when a new DotM/OtBP/FTT goes into effect, and less frequently when other important events transpire. (Those are the two that I know of; there may be others as well.) See Wikivoyage:Social media. -- AndreCarrotflower (talk) 00:00, 8 September 2014 (UTC)
For all I can see, there's loads and loads of Wikipedia users/editors that primarily want to cater to the interests of tourists. Any idea how to get them here? Perhaps we could have a general message at the top of Wikipedia for a few days to get more attention. Something along the lines of "You want to provide tourist information about a place? Come to Wikivoyage!" with a starter link. There could also be a reminder at the index page that stays a little longer. Just a thought. Cheers, Horst-schlaemma (talk) 17:27, 13 September 2014 (UTC)
Providing links to decent pages here might attract the attention of a few (and it's a long-term way of helping people find us when they are looking for travel information). Banners (sitenotices or centralnotices) would presumably require consent from the target wiki. When we have a project going, we could leave messages at related pages. For example, we could tell w:en:WikiProject India about the proposed India expedition. Is there a newsletter? If so, it could be delivered to off-wiki accounts (if anyone wants to sign up for it). Have any of these been tried in the past? WhatamIdoing (talk) 21:14, 13 September 2014 (UTC)
The India Expedition is up and running and needs more hands on deck. I'll have a look at that WP project page. Ikan Kekek (talk) 21:30, 13 September 2014 (UTC)
WhatamIdoing, that WP link didn't work. Please try again. Ikan Kekek (talk) 21:32, 13 September 2014 (UTC)
Try w:en:Wikipedia:WikiProject India. As a more general point, it is worth noting that there are projects covering many countries and major cities. Try entering Wikipedia:Wikiproject and then a country/huge city name in the WP search box. AlasdairW (talk) 23:06, 13 September 2014 (UTC)
There's also a WP:TRAVEL Wikiproject with subprojects like WP:HOTEL, but it seems to be dead as a doornail. A WP:ROUTE66 project is almost a dead, although there's an active project updating US National Register of Historic Places (NRHP) entries and projects for road/highway articles. The city/region and country projects look to be the best bet, if they're active, as we actually do link to WP for same-topic cities. K7L (talk) 02:31, 14 September 2014 (UTC)
Thanks a lot, AlasdairW. I'll try posting a message on that project's talk page. Ikan Kekek (talk) 02:47, 14 September 2014 (UTC)

Echo and watchlist[edit]

Special:Notifications & Special:Watchlist substantially overlap in functionality, except the former also contains extra (some non-public) events and doesn't provide with passive usage options (means to turn off web-nagging or email-nagging and to just keep visiting the page whenever I'm free), while the latter doesn't provide with options of active web-nagging notifications (but already provides email interface). Partly, in my personal view, the Echo/Notifications project was driven by low usability of watchlist; [21] comes to mind. It's also perhaps worth noting that Echo users aren't exposed to Special:Notifications unless thy have JavaScript disabled — in which case it's their only means of reading the notifications.

I'd like to get this done:

  1. Merge these two pages into one.
  2. To remedy large inflow of information, introduce multiple levels of importance of the web-nagging notifications (red for mentions, orange for thanks, blue for new watchlist items, etc and configurable in your settings).

Thoughts on both, please? --Gryllida (talk) 02:39, 9 September 2014 (UTC)

I do not see them as overlapping. Would not really want the fact that someone leaves a message for me or is referencing my user name mixed up with the many articles I have on watch. --Traveler100 (talk) 04:44, 9 September 2014 (UTC)
Gryllida, how many places did you post this idea to? WhatamIdoing (talk) 19:18, 9 September 2014 (UTC)

Bodies of water or region[edit]

I have read your policy about bodies of water, but I have a question: could I create an article on Lake Iseo considering it as a region (as we have done on it:Lago d'Iseo)? It can contains information about the towns that don't have their own articles and little information about the others. Obviously I'll translate the map. --Lkcl it (Talk) 08:58, 9 September 2014 (UTC)

I'd say an information should go to Brescia (province) and Bergamo (province), respectively - simply start articles for every destinations that merits one (i.e. has at least one accommodation opportunity). I don't think there is much information to share - getting in and around each side of the lake is probably a different story, as much as accommodation, gastronomic and entertainment opportunities, which are located in specific places. You may want to give each province a subregion discussing their side of the lake, and cross-reference each other in the body of the articles. PrinceGloria (talk) 09:16, 9 September 2014 (UTC)
The two sides of the Lake are quite similar: every town is touristic and has got some activities linked to fishing. Get in and get around: to get in, yes there are two different roads, but the nearest airport is the same and to get around the best solution is to take the train (only east side) or to take a ferry boat (same line for both sides). So, in my opinion there are more similarity than dissimilarity. I'd prefer to create a same subregion (the article will contain more information and it will be more complete) and then an article for the towns, yes each town has got at least one accommodation opportunity. Also Lake Garda (divided into 3 provinces), Lake Como and Lake Maggiore have got only an article. --Lkcl it (Talk) 09:47, 9 September 2014 (UTC) And if we decide to follow the division proposed there there will be no problem linked to province boundaries. (I can help translating from Italian) --Lkcl it (Talk) 09:53, 9 September 2014 (UTC)
Well, we have decided for a different regional split in en.voy in that discussion. You can always reference the nearest airport, this is not a problem, all articles do that if they are not the city where the airport is, a short link would suffice. Getting from the airport to the destination is another thing - for every destination it is slightly or vastly different. For ferries, I don't see this a problem - every connection between cities gets mentioned at least twice. I recently did that for Konstanz and Friedrichshafen in the Bodensee Region. Other lakes are anomalies IMHO and are not in accordance with Project:Bodies of water. PrinceGloria (talk) 10:01, 9 September 2014 (UTC)
Ok, now I'll create some article on the towns and then perhaps the two subregions, any way you have decided to not use this division untill the articles will be stub, but if I create some usable articles? --Lkcl it (Talk) 10:33, 9 September 2014 (UTC)
Why don't you create destination articles first. We seem to worry too much about regions, when there is nothing to put in them :) PrinceGloria (talk) 10:53, 9 September 2014 (UTC)
Ok. --Lkcl it (Talk) 11:21, 9 September 2014 (UTC)

Change in renaming process[edit]

Part or all of this message may be in English. Please help translate if possible.

-- User:Keegan (WMF) (talk) 9 September 2014 16.22 (UTC)

Template:User Docent[edit]

If I am a docent of an article, should I categorize my user page in the Category:Docents? If yes could we put it automatically with the template User Docent? Thanks --Lkcl it (Talk) 17:20, 9 September 2014 (UTC)

No. We don't categorize users. Powers (talk) 17:26, 9 September 2014 (UTC)
Thanks. Please note that two user pages are in this category. --Lkcl it (Talk) 17:34, 9 September 2014 (UTC)

Marker types in dynamic maps[edit]

I recently filled out the "Cities" and "Other Destinations" subsections of the bottom-level region Cattaraugus County, adding inline marker templates for each. However, when I tried to use the City marker type for Allegany State Park (in "Other Destinations"), it displayed as #1 on the map - the same as the first entry in the list of Cities. To eliminate the ambiguity, I changed the "type=" parameter to Listing, but it just doesn't look right to me.

My question is this: Do we have an "Other Destinations" marker type that can be used instead? As a matter of fact, can someone give me a definitive list of all the different types of markers that we have for dynamic maps? Besides "city" and the standard See, Do, Buy, Eat, Drink, Sleep, and generic Listing), I know that we also have Go, which we use for bus depots, train stations, subway stations, etc. Are there any others?

-- AndreCarrotflower (talk) 02:51, 10 September 2014 (UTC)

To be honest, I think we are overdue for a discussion about how dynamic maps should be used in region articles in the first place, and in particular, the marker icons of {{marker}} which go beyond those used for the listing-based markers. The "city marker type" is something that was put in there by User:Torty3 when he created the template, and I believe it escaped the attention of most of us and was never in fact discussed how or when or if it should be used. (The same for the go, view, and vicinity types, which I didn't even know existed until I looked at {{TypeToColor}} just now.) There are some concerns I think we should discuss regarding use of markers in region article dynamic maps, including the question of whether we want the typical one-liner lists in the Cities/Other destinations/Go next sections to become numbered lists (which may give the impression of a ranking), the fact that the map is often already showing the cities and the icons actually obscure them (I've definitely seen some region maps somewhere where practically all the cities were already represented but icons were superimposed anyway), and the fact that some region articles also contain listing types, so the map ends up with a mix of icons of different magnitudes, i.e., for single attractions and for whole cities. There is also the question of whether it would be better to use the OD layer which automatically shows pointers for places we have an article for, instead of manually placed POIs. I've seen this in use in some articles too.
We currently have 82 region articles with a dynamic map. I think we should call a moratorium on new ones for the time being, look carefully through the existing ones and see what has been tried, what can be done, what problems and issues there may be, what improvements can be made, etc., and then talk about how we should be implementing these for region articles, so that we can do it in a consistent manner we all agree on. Texugo (talk) 03:08, 10 September 2014 (UTC)
I think that superimposing (the current way it is done) is the correct thing to do for now. OSM often does not show city names, sometimes showing the name of smaller things instead, so we are on the safe side with showing it. And since it is cited in the article, it should be clearly visible as a marker on the map. Nicolas1981 (talk) 03:34, 10 September 2014 (UTC)
I suggest we all analyze Western Finger Lakes in depth, take note of all problems, find ways to fix them, make it optimal, and use it as a base to decide what we want for the other articles. Nicolas1981 (talk) 03:34, 10 September 2014 (UTC)
I looked at Western Finger Lakes for 5 minutes and have not found any problem. The area is highlighted, there is minimal superimposition, points are sufficiently far apart from each other, it gives a good sense of how one could tour the area. Nicolas1981 (talk) 03:42, 10 September 2014 (UTC)

I favour Nicolas' approach so that discussion does not become too abstract and divorced from the current practical reality. --W. Frankemailtalk 11:04, 10 September 2014 (UTC)

I think we should look at more than Western Finger Lakes. It's a fairly rural area without a lot of destinations on the underlying map, so it's less likely to cause problems. Texugo, can you point us to some examples where the map already shows most of the destinations? The maps I've seen to date are more like Western Finger Lakes so the markers were necessary to make the map useable. -Shaundd (talk) 14:55, 10 September 2014 (UTC)
"minimal superimposition" is still a problem. There should be none. Powers (talk) 20:06, 10 September 2014 (UTC)
Slightly off topic -- marker template has an image argument -- would it be worthwhile to incorporate an image argument in the listings (see do etc.) template as well? -- Matroc (talk) 02:49, 11 September 2014 (UTC)
Do you mean that in the Sleep section, instead of small numbered squares you would have small numbered houses? I would say why not, it makes it very visual. Printed guides actually often have this house logo repeated for each hotel, even though the reader could understand that it is a hotel just by looking at the section header. 58.156.2.18 06:02, 11 September 2014 (UTC)
I was thinking more on the line of when you click on a numbered location on a map for a museum or cathedral etc. - a pop up image of that museum would appear... one can put an image in using the marker template but I don't see that option in the listing template... (numbered house icons sounds interesting though...) Matroc (talk) 06:23, 11 September 2014 (UTC)
Simply add the image= field and provide the filename. The picture will be shown in the pop-up window. We have been using this option in other language versions since ages... --Alexander (talk) 09:52, 11 September 2014 (UTC)
The image discussion should probably be separated off from this one, but it probably does need to be discussed be too before we start running with it, not least because having a listing image field in the buy/eat/drink/sleep sections would seem to encourage photos of businesses and we don't have any clear consensus to allow a blanket exception to our image policy against photos of businesses.
Back on topic, to answer your question, Shaundd, some examples of what I consider very problematic are
  • Wasatch Range - fills the map with icons that largely obscure the city dots, labels, and routes of the map
  • Sonora_(Mexico) - most cities on the map are labelled, but obscured by the blue icons
  • Western Nevada - obscures the city dots and labels that would otherwise be visible, groups some cities with a plus so one has to zoom in to see them anyway (and if one is zooming in anyway, why not just consider the more accurate and well-labeled info that's already on the map?)
  • Nine-County Region - of the 20 cities with icons on the map, 13 of them would have a visible label if there weren't an icon blocking it
  • Southeast Arizona - uses the automatically displayed destination pointers, some of which block their own labels, and in combination with regular listing icons, some of which are grouped under little pluses meaning that the user has to zoom in 4 steps anyway, just to resolve them
  • Kathmandu Valley - also mixes regular listings with destination points, the two types overlapping each other as they try to point out everything from bus stops to individual attractions inside the cities, while also trying to show markers for the cities themselves
Like LtPowers, I don't really think we should be overlapping and blocking the stuff that's already on the map, and to be honest, I'm not very convinced of the need for city markers at all. The info is already on the map, even if you do have to zoom in a bit, and as the articles above show, putting city markers doesn't necessarily save you the need to zoom in to see what's going on anyway. Plus, many of our bottom-level region articles have 15-25 cities linked, and putting all those on the map really obscures a lot. I rather consider city markers to be pretty much redundant, given the high chances of the user having to mess around with the map anyway just to determine exactly what points on the map the comparatively large icons correspond to. One more feeling I have is that while I like the way we use icons in our city maps to supplement the information that's on the map with attractions, etc., using the same approach to superimpose icons on top of the cities that are already on the map at some level tends to disproportionately emphasize the cities aspect of the region, de-emphasizing the contours of the transportation systems, the landscape, the shaded park borders, and the other aspects that should make region maps less point-oriented. I'm also not a fan of the way it turns our one-liner city lists into numbered lists; I think it may give the impression of being a ranking. Texugo (talk) 22:52, 11 September 2014 (UTC)

I haven't read through everything new with dynamic maps, but to clarify a point, I did not add any sort of city markers, which was actually added on the 17th of June 2014 by User:Thatotherperson -- see [22]. And I haven't actually even touched the {{TypeToColor}}, so it just goes to show how opaque templates can be when used within other templates. I don't agree with the city markers either, though I probably won't comment any further than this for now. -- torty3 (talk) 03:01, 12 September 2014 (UTC)

Thanks for the clarification. Sorry I didn't get it right the first time! So wow, those got slipped in more recently than I thought. It appears that User:Thatotherperson is also responsible for a good chunk of the instances of it use, especially region articles across the southwest US. This should have been a more limited experiment brought up for discussion. Texugo (talk) 03:12, 12 September 2014 (UTC)
In the interest of full disclosure, I use "Go" markers in the Buffalo district articles for subway stations, the Greyhound station, the Amtrak station, rental car facilities, and one or two other transportation-related listings, and I also use the "City" argument in inline markers (using Template:Marker) for neighborhoods within each district as described in the "Understand" section. If we decide to disallow these types of markers, I would prefer to have a method of pinpointing these items on a dynamic map other than the undifferentiated "Listing" marker. -- AndreCarrotflower (talk) 03:03, 13 September 2014 (UTC)

These type of maps weren't added with no discussion at all; they were brought up on both of our dynamic map talk pages back in June. See here for the exact moment city markers were first implemented, and then here where I proposed updating the dynamic map guidelines to allow region maps. (Not many users commented on that specific proposal, but I figured plenty must have seen it due to the contentious debate going on in the same section, and no one expressed any objections to the region maps.) To those who would rather do without city markers, are you saying it would be fine to have thousands of destinations that don't appear on a map anywhere on the site? A lot of the city labels on the map tiles are only visible at high zoom levels, meaning you would have to already know where the city is to find the label. Powers Texugo claims the built-in labels are sufficient and cites Sonora (Mexico) as an example; I count only 3 out of 13 destinations that would have labels without my added markers, and even Hermosillo, the largest city in the region by far, is invisible at the necessary default zoom level. Imagine you're reading through a list of small towns in a travel guide for a desertous region when you discover the existence of "a bustling city of nearly a million people" — only to look over at the map they gave you and discover that you've been left to locate it yourself. I'm aware that it looks awkward to have overlapping icons and labels, but a map is a terrible place to choose looks over the presence of more information.
Someone mentioned the possibility of replacing markers with the Destinations layer. I would like to point out that the city markers were brought about specifically as a solution to a major problem with the Destinations layer: specifically, that it chooses which destinations get markers strictly based on distance from the map center, without any chance for author customization. In short, the city markers are currently the only way for a user to choose which cities get labels on a map, which I consider to be a functionality more important than appearance.
Thatotherpersontalkcontribs 09:20, 13 September 2014 (UTC)

Well said! --W. Frankemailtalk 09:44, 13 September 2014 (UTC)
I was completely unaware of the first conversation there and think such a change should have had wider exposure and an experimentation period.. The second 'proposak' you linked to was tangential to the discussion and not really addressed or even carried forward to the end of the discussion. We've never had a policy that "every town must be on a map somewhere", and every town is both already on the map at some zoom level and already linked from its own town page.,. I'll stand by every one of my points above... City markers are a very problematic solution to something that is not necessarily a big problem. Texugo (talk) 12:35, 13 September 2014 (UTC)
Where did I say that the built-in labels were sufficient? Also: "a map is a terrible place to choose looks over the presence of more information" could not possibly be more wrong. A bad-looking map is worse than no map at all. Powers (talk) 19:00, 13 September 2014 (UTC)
I think that, perhaps unwittingly, you may have crystallised a fundamental difference between different world outlooks. Some of us feel that the perfect should not necessarily be the enemy of the possible and the practical. This camp vehemently disagrees that a "bad-looking map is worse than no map at all". Now don't get me wrong, a well drawn map is a thing of beauty - but it also should be of practical use. Let's strive to make dynamic maps less ugly - but not at the expense of utility or having them at all. --W. Frankemailtalk 19:12, 13 September 2014 (UTC)
I agree with you that a bad-looking map is better than none, but only as long as it's clearer than no map. A map which is unreadable or more confusing than just reading directions might be worse than none. Ikan Kekek (talk) 19:26, 13 September 2014 (UTC)
I think a map would have to be *very* unclear before it’s worse than no map at all, and IMO, none of the examples cited above are worse than no map. I agree the city markers are problematic — they obscure information in the base map, the yellow pluses mean you have to zoom in, they’re not pretty and I don’t like the number lists — but to not have some kind of marker means our readers have to find destinations on their own. Is Little Town in the upper left, maybe the middle, or perhaps the bottom right? Nope, let’s zoom in another level and repeat. Still nothing, let’s zoom in again. Oh wait, now I’m so zoomed in I’m not sure I’ve covered the whole region. Sigh. Like many of these map discussions there’s an element of personal preference, but having no city markers seems to have a high potential for a poor user experience.
The background details on the OSM maps are nice, but at the end of the day, we write guides to destinations and people come to our site (I hope!) primarily to read those guides. If there is one thing I think our bottom level region maps should do, they should make it easy to locate those destinations we write about. Hopefully the dynamic maps can continue to evolve and improve (or, even better, people develop a sudden infatuation for Inkscape and produce bucket loads of beautiful static maps :-) ), but in the meantime I think superimposing city markers is a lesser evil than obscuring some of the background OSM detail.
I noticed some of the maps had listing markers and city markers on the same map. I thought we weren't supposed to have listings on regions pages? I fully support moving those markers off the region maps. -Shaundd (talk) 23:04, 13 September 2014 (UTC)
LtPowers, I may have confused your comments with Texugo's. I thought it was you who said the map at Sonora already had labels for most cities.
Thatotherpersontalkcontribs 02:53, 17 September 2014 (UTC)
No, my only comment prior to yours was to indicate that a good map should never have overlapping labels. Powers (talk) 17:10, 17 September 2014 (UTC)

We should not use "dynamic" maps for region articles. There is nothing dynamic about them. Cities don't close or change location as listings do, and listings are supposed to be moved to articles lower on the hierarchy, so why have a dynamic one? Besides, most of these maps look really bad and confusing. Static maps show regions, cities and other things relevant to travellers as curated by the maker of the map. Globe-trotter (talk) 09:01, 14 September 2014 (UTC)

Good points.
But an "inferior" dynamic map is still usually better than no map at all.
It's a sad fact that we have a limited number of editors able to draw good static maps. --W. Frankemailtalk 20:27, 14 September 2014 (UTC)
I disagree regarding there not being any use for dynamic maps on region articles – some regions are very sparsely populated, with attractions often many miles from the closest 'city', which may have absolutely nothing of interest and no facilities for travelers, thus not warranting an article. One such example is Dhofar, another is Southeast Arizona. Also after having traveled to some places where no maps are available anywhere, I do think a 'bad' map is better than no map at all. –StellarD (talk) 18:58, 15 September 2014 (UTC)

First of all, as others have pointed out, Globe-trotter's comment misses the point: the static map vs. dynamic map choice is a red herring; realistically speaking, for the vast majority of region articles the choice is between a dynamic map and no map at all. Secondly, in a larger sense, it also serves as a shining example of the hostility toward dynamic maps espoused by some in the static-map camp (here's another example), which in my view needs to end.

Wikivoyage is a website run by volunteers who give of their free time to contribute. Knowledge of Inkscape or other static map programs, or even willingness to learn them, are not prerequisites to membership in good standing among our community of editors. In fact, the primary reason why Wikivoyage added the dynamic map functionality was to democratize the creation of maps on our site, and thanks to that new feature over a thousand articles have maps now that didn't before. And dynamic maps have advantages over static ones - they're customizable, the zoom function allows for the inclusion of more content, and most important of all, for bottom-level destinations, the more user-friendly creation process also allows for easy updates when new businesses open or old ones shut down. I'd be willing to bet, without checking to confirm, that the majority of static maps on this site on bottom-level articles are at least somewhat outdated, and their usefulness to travellers has therefore degraded over time. We simply don't have enough hands on deck to continually update every static map on this site, and frankly, from the static-map diehards I see a whole lot more complaining about dynamic maps than upkeep on static ones.

It frankly boggles my mind that dynamic maps have been featured on this site for so long, and yet the bias against them is still so pervasive that someone has to stand up and defend them from being considered inferior or having the parameters within which it's "acceptable" to use them so tightly circumscribed. If we're worried about things like superimposition and aesthetic matters, perhaps the thing to do is to improve the dynamic map interface (or advocate at MediaWiki for its improvement) rather than writing off the whole feature. We decided to include dynamic maps in Wikivoyage based on community consensus, and whether some of us like it or not, they're here to stay. And people like myself who work very hard - again, on a volunteer basis, for no compensation of any kind - to add dynamic maps to articles should not have their efforts hamstrung by static-map elitists who would prefer that articles contain no content rather than content that isn't of their preferred type.

-- AndreCarrotflower (talk) 19:44, 15 September 2014 (UTC)

That is certainly not what I thought this conversation was about. I am perfectly happy to have dynamic maps in regions articles, especially when they have a mapmask to outline the region in question. But I think treating region maps they way we treat city maps is extraordinarily clumsy at best. Putting up to 40 point-based icons on the map for things that are not actually the same size, type or importance, covering up the more sensibly-scaled and labeled way that a dynamic map handles the same information - it's just a waste and a serious detraction from what a region map is supposed to be: an overview. The dynamic map uses different sized points and fonts to represent cities of different sizes and importances and doesn't try to squeeze every single destination on there with big identical shapes. A region article is supposed to give an overview of the region, leave the gritty details like addresses and phone numbers to the city articles; we don't insist that the city list should give the pronunciation or website or tourist center for every city listed — when a reader needs that info, they click through to the city. Similarly, a region map map should also give an overview — showing a handful of the cities, showing the major transportation routes, etc., not trying to include the geo detail of everything we have an article for. The solution for someone not seeing the destination they are looking for on the map is very simple - go to the article and look at the map there. There is absolutely no reason to crowd our region maps with blocky icons that obscure stuff when the gritty details should be left to the city articles. Texugo (talk) 21:53, 15 September 2014 (UTC)
My intention was not to hijack the discussion and send it into a different direction. Some of the points that have been made touch on a larger issue that has been festering in my mind for some time. As for your concerns regarding dynamic maps in region articles, Texugo, I agree with you, but I see that as more a matter of listings policy than of map policy. Any items other than City markers that clutter up a dynamic map in a region article are reflective of listings in the body of the article that shouldn't be there. That would be a policy violation whether or not the article had a dynamic map. -- AndreCarrotflower (talk) 22:09, 15 September 2014 (UTC)
Three of the regions with dynamic maps are Scottish islands that have no cities (Tiree and Islay) or only one city (North Uist). I don't see any of these having more city listings soon. Islands naturally form a region that can be much smaller than we would normally use, and we have not been consistent about whether to call these cities or regions. AlasdairW (talk) 23:15, 15 September 2014 (UTC)
AndreCarrotflower, but the city markers are themselves clutter, and if we were to start "ensuring that every destination article appears on a region map somewhere" as has been suggested, there will be quite a lot of maps with 25-40 city/other destination icons blocking much of the most important parts of their respective maps.
AlasdairW, all three of those island articles should be using a city template and not a region one, since that is the prevailing manner of dealing with standalone island articles. I have changed to the first two to cities, and marked the third one for merging with its one city — an island 20 miles across with 2000 people and a smattering of attractions can easily be covered in one single island-as-city article. Texugo (talk) 23:36, 15 September 2014 (UTC)
Texugo, I fail to understand how city markers are "clutter" on dynamic maps while dots with place names next to them are fine on static maps. As for bottom-level regions, if they contain 25 to 40 cities that's a pretty good indicator that they need to be subdivided. Also, parenthetically, I think we need to rethink the policy that says all destinations within a bottom level region need to be included on their "cities" subsection. It strikes me as pointless and inherently in conflict with our "Wikivoyage is not the Yellow Pages" non-goal. -- AndreCarrotflower (talk) 00:41, 16 September 2014 (UTC)
They are clutter because they exist in addition to the dots and labels that are already on the map. They are clutter because they jostle with each other unpredictably over the top of roads and contours and labels that would be better shown. They are clutter because they show the tiniest village the same size as the largest city when the underlying dynamic map underneath handles that information in a much more sophisticated manner. On a static map, or even on the dynamic map without icons, the dots and labels are arranged so that they don't interfere with one another, and not so many are shown at a given zoom level that it becomes unnecessarily distracting.
And it's not the right thread to discuss it, but not listing destinations in the bottom level region is not a good idea at all - that would just make it where a person investigating a given region cannot be sure they've found all our coverage unless they scour every article looking for sideways links to articles that have been left out of the hierarchy. Texugo (talk) 02:33, 16 September 2014 (UTC)
Would it be possible to develop a different kind of feature for each city listing which would, without reloading the whole page, re-center/re-zoom the mapframe to the given city? I think it would pretty easy in html, but I don't know about making it work here. Texugo (talk) 02:38, 16 September 2014 (UTC)
Texugo, six months ago you argued against the use of locator maps on this site by saying the following: "...city articles get a map for getting around within the city, region articles show maps for getting around within the region; any maps showing wider placement within the surrounding region belong in the next level up in the hierarchy...". That exact philosophy is the reason it's important to have comprehensive maps with every destination on them in lowest-level region articles. Otherwise we're pushing regional information, like the placement of cities within a region, into the city articles. I don't see how we can say that the lowest-level region articles are overviews when the articles below them intentionally leave large coverage gaps between the populated places with hotel accommodations. If we write the lowest-level region articles as overviews and push all detail into the city articles, then we're essentially trying to divide up the whole globe as a set of cities and their vicinities...at which point the cities become the new lowest-level regions. What is so terrible about the lowest-level region articles resembling city articles and the overviews being written as higher regions?
Thatotherpersontalkcontribs 02:53, 17 September 2014 (UTC)
That is taking me far out of context there. I was talking about static locator maps in that conversation, and I will still argue that we do not need those in every region article or every city article, etc. And dynamic maps even further eliminate any need for that kind of thing, allowing that information to be checked at the roll of a scroll bar. And in any case, I did not and would not insist that we should attempt to try to cram all the destinations for each bottom-level region onto a single map. But seriously, I do not see how anyone could think sticking 25+ icons on a map produces an advantageously usable result. You still can't glean information from that map without interacting with it anyway, and to even get an idea of how the cities are laid out, you have to either click on every icon or or cross-reference every one of them with the city list to tell what's next to what. That does not remotely constitute any advantage worthy of blocking the otherwise clearly legible information that is already on the map. As for the rest of what you've just posted, it sounds like you are proposing a fundamental change to the existing policy of discouraging listings from region articles or something, which would require a whole other discussion for us to address. Texugo (talk) 03:13, 17 September 2014 (UTC)
I don't see how I took your comments out of context. I know you were talking about static locator maps, but that discussion and this one both invoke the same basic question: if a reader wants to use Wikivoyage to learn the location of a destination, where should they look? If it's the region articles, then we need city markers. If it's the destination articles, then we either need a scrollable dynamic map on every one or we need a way to make the geo tag function noticeable to the average reader.
Thatotherpersontalkcontribs 04:40, 19 September 2014 (UTC)
But files on Wiki Commons can indeed be protected from unauthorized edits. This is the case for e.g. many featured pictures. -- Horst-schlaemma (talk) 11:51, 17 September 2014 (UTC)

Wikivoyage:Destination of the month candidates/Banners[edit]

Why should all banner suggestions be uploaded locally?--GZWDer (talk) 10:36, 11 September 2014 (UTC)

As far as I'm aware, it's to prevent them from being overwritten or edited on Commons; we don't want this most public of images to be vandalised. --Nick talk 12:51, 11 September 2014 (UTC)
Also to keep from overwhelming Commons with images not used anywhere, most of which are cropped from existing images only to fit our size requirements. Actually, I think we should be deleting images we don't use once one is selected, and then upload the one we do use to Commons (unless it's non-free). Powers (talk) 18:02, 11 September 2014 (UTC)
Couldn't we implement a simple tool that lets us resize existing images to banner-size right at Wikivoyage? Something like facebook or other community/social sites have. It would save a lot of time and also data storage, as we'd just link to full-size images on Commons. I don't think it would be that complicated, though someone would need to be able to implement an existing solution. No idea who's actually programming here. Cheers, Horst-schlaemma (talk) 09:46, 14 September 2014 (UTC)
Horst-schlaemma, you're missing the point here. Because banner images are so visible, and because such care needs to be taken to optimize the relationship between the text overlay and the image itself, we absolutely need these images to be under local control. If they're on Commons, resizing tool or not, there's nothing preventing the images from being deleted or reuploaded in a different form, and one of the most visible features of our Main Page from being altered without consensus, or even input, from the local community. --AndreCarrotflower (talk) 19:11, 14 September 2014 (UTC)
That being the case, Powers' point about unused banners is a good one, because of the redundancy issue he cited as well as the simple fact that the archive is becoming huge and unwieldy. It already takes forever to load. Additionally, some banner images (for instance, many of the proposed banners for Buffalo as DotM) are not hosted on Commons at all, but were uploaded directly to Wikivoyage by their photographer. I would not object to these images (used as well as unused) being moved to Commons after they're retired from the Main Page. -- AndreCarrotflower (talk) 19:18, 14 September 2014 (UTC)
On second thought, I actually would prefer that we continue to host old banners locally as well, because even after their tenure on the Main Page is over they remain in use at Previous Destinations of the month, Previously Off the beaten path, and Previous Featured travel topics. I suppose it's fine to move old unused banners that aren't derived from images already on Commons, though. -- AndreCarrotflower (talk) 20:17, 14 September 2014 (UTC)
AndreCarrotflower, sorry I should have specified that I'm referring to article/destination banners, the regular ones for cities and regions. Cheers, Horst-schlaemma (talk) 22:42, 14 September 2014 (UTC)

If the banners were on Commons, other language versions could also use them. I think we need someone here with the right buttons on Commons to lock the banners in question while they are showing on the main page. Globe-trotter (talk) 12:09, 16 September 2014 (UTC)

WP has traditionally moved front-page images onto the local wiki and locked them (a) because it was originally possible to override a Commons image by uploading a local image with the same name and (b) because any unexpected, undesired change to the image on Commons could have the effect of vandalising the main page item. That doesn't mean that the Commons versions had to be deleted, as far as I know. K7L (talk) 16:37, 16 September 2014 (UTC)
But that still doesn't address the problem of the continued use of banner images at Previous Destinations of the month, Previously Off the beaten path, and Previous Featured travel topics. Granted, the lesser visibility of those pages makes their integrity less important than that of the Main Page, but it's the same principle at work: those pages are intended as historical records of the banners we've used for previous featured destinations, and as such should not be subject to change by anyone outside our own local community. -- AndreCarrotflower (talk) 16:45, 16 September 2014 (UTC)
Hi, it's possible to protect Commons files from unauthorized changes. As it's done with e.g. some featured images. Cheers, Horst-schlaemma (talk) 08:20, 18 September 2014 (UTC)
That's a promising development, but I imagine the question of whether a particular image is protected is up to the administration at Commons. Are any of us Wikivoyage regulars also Commons admins, and can handle the task of protecting the files? If not, is Commons accustomed to handling protection requests of this nature from other wikis? If every time we want an image protected we have to jump through hoops, I'd be inclined to conclude that it doesn't do any harm or tax our resources too terribly to keep the images local. -- AndreCarrotflower (talk) 17:19, 18 September 2014 (UTC)
There are a few of us who are admins on both projects. Commons' protection policy states: "Upload protection might be used to prevent overwriting of files that are either heavily used across Wikimedia projects (e.g. template icons) or used in a dangerous location (e.g. wiki's main pages) in order to prevent vandalism. These protections might be indefinitely or temporary, for example only as long as a file is on a wiki's main page." Protection can be requested as a routine matter at commons:Commons:Administrators' noticeboard/Blocks and protections. Powers (talk) 01:12, 19 September 2014 (UTC)

Star articles with no custom banner[edit]

Only two lonely star articles have no custom banner:

Anyone game? Texugo (talk) 23:15, 11 September 2014 (UTC)

I'm still mulling over options for the Disney articles; Walt Disney World needs an improved one. Though Downtown Disney is an interesting challenge, especially since it'll be Disney Springs by this time next year. Powers (talk) 23:34, 11 September 2014 (UTC)

India expedition?[edit]

Hi, everyone. Should we have an Expedition to fix the articles about places in India? I don't mean adding content, though that's great if you've got it. The problem is that even when articles about India have content, they're often incorrectly formatted, and the English (spelling, punctuation, spacing, usage, capitalization, even comprehensibility) is often really substandard, and touting is also a problem in some articles.

Lately, a user has been adding a lot of information (arguably too much) to the articles on Southern India and Karnataka, and that's great, but there are way too many destinations listed for a state-level article for a state that has linked region articles. One of the city articles linked from Karnataka, Hubli, has no "Understand" section but encyclopedic information in "Get in." Another linked city article, Belgaum, has all kinds of issues, but one that comes up in many India articles is the random bunch of bulleted entries, such as are in this case in "Eat."

I would propose that we start by making sure the articles linked from India#Regions are in proper format and an acceptable standard of English, and then proceed to look through articles for each state, but somewhere along the line, we should also make a list of the most important local destinations (cities, parks, etc.) and check on their quality, too.

So what do you all think? India is a country where much English is spoken, and it's an important country in terms of history, culture, wildlife, economics, and politics. If we can get together a group of several people who are willing to devote even a few minutes a week to doing some good editing, we have a fighting chance to whip these articles into shape. Ikan Kekek (talk) 01:48, 13 September 2014 (UTC)

Great idea IK. I would had loved to be part of this expedition but until late October, I'll be busy on Wikimedia Commons due to Wiki Loves Monuments Pakistan. Right now patrolling hundreds of uploaded files daily and later I've to start shortlisting and do categorisations thus I'll be on a distant from my home-wiki however I do daily come over here to see how things are moving. --Saqib (talk) 02:36, 13 September 2014 (UTC)
There will still be plenty of work to do after late October, I'm sure! Ikan Kekek (talk) 02:37, 13 September 2014 (UTC)
Right but when I'll be back, I'll focus on Pakistani articles. BTW, we need to look here how the response was in already ongoing geographic expeditions especially Wikivoyage:Brazil Expedition. If I recall properly, I see no one other than User:Texugo actively working on the that expedition and that one is actually is more important as it was started to make articles ready for the 2014 World Cup and 2016 Summer Olympics. --Saqib (talk) 03:01, 13 September 2014 (UTC)
There were at least 2 other users systematically helping on the Brazil Expedition, though it was most me that actually updated the statuses on the expedition page, but anyway, even when it falls inactive for a while, I'm glad we have it, because there's no better place to keep track and organize so we can analyze where coverage is weak, etc. I would totally support an India Expedition as well. I've done some work recently on India articles, especially trying to ensure we don't over-subdivide everything, and I know they are quite a mess. And yes, India articles have always been a frequent target of non-MoS edits, contributions with poor English, superfluous info, etc. It would be great to have a place to organize our efforts to get that mess under control. Texugo (talk) 04:05, 13 September 2014 (UTC)
Greeting IK. I currently reside in Karnataka. I will try and help where I can. (I am also working on a few wikipedia pursuits in parallel). regards Arunram (talk) 02:20, 17 September 2014 (UTC)
Much appreciated! The Karnataka article itself needs a lot of work. Feel free to add your signature on the Wikivoyage:India Expedition page. Ikan Kekek (talk) 02:45, 17 September 2014 (UTC)
Would a more general "subcontinent expedition" be a better alternative, or too broad to make sense? Certainly Pakistan, Sri Lanka and Bangladesh articles could all use work & I think what problems there are with English usage are similar across the region. —The preceding comment was added by Pashley (talkcontribs)
Might be too broad, as India is already a vast country, but we could discuss this further. I'll create the Expedition later today. Ikan Kekek (talk) 14:55, 13 September 2014 (UTC)
Well I think Pashley's suggestion not bad. Though my English is not good but I can cleanup Pakistani article and after that, I can look into Sri Lankan as well Indian articles. --Saqib (talk) 16:28, 13 September 2014 (UTC)
It's definitely a good suggestion. I've created the Wikivoyage:India Expedition. We could discuss enlarging it on its talk page, but I think working on the Indian destinations is already a really daunting task, and perhaps each country should have its own Expedition. Ikan Kekek (talk) 16:48, 13 September 2014 (UTC)
Article status tables are up for the India guide and the multi-state regional guides, with specific remarks about things that can be done to improve them, and I already did some copy editing and editing for structure. Anyone who's interested: Please come and help. Ikan Kekek (talk) 21:15, 13 September 2014 (UTC)
A milestone has been achieved: Status charts for all the Indian states have been filled in. Ikan Kekek (talk) 06:50, 21 September 2014 (UTC)

Numbered icons on article page not matching numbered icons on a map![edit]

Insure that listings of each type have both a latitude and longitude or both arguments are blank.
Everything will appear to be numbered correctly on an an article page (naturally the entry missing the long= argument
will not be numbered). However, here is the kicker: numbered icons after that entry missing the long= will
be increased by 1 on the map... For example: entry 5 on article page will be 6 on a map etc.
Example: - click on the icon numbered 5 for Gokoku-ji.. Hope that helps! Cheers! Matroc (talk) 02:57, 13 September 2014 (UTC)
To verify the coordinates of new listings please click the button 'map center <==> all markers' after saving. POI with incomplete coordinate pairs will be visible and may be corrected. - For further testing, you can use this script [23] . -- Joachim Mey2008 (talk) 07:17, 14 September 2014 (UTC)
Thank you! - hopefully this will assist anyone having this issue and send them in the direction of correcting a listings latitude and longitude information... Matroc (talk) 07:55, 14 September 2014 (UTC)
I think we should remove coordinates of POIs missing either latitude or longitude. Anyone disagree?
To start doing this, just open the latest CSV at http://datahub.io/dataset/listings/resource/15f9e529-22e3-4862-9a0a-ff77692c789d open it in LibreOffice or Excel, sort by latitude with sub-sort on longitude, and you will find them. I actually just did this sorting and saved the erroneous coordinates (and their article/POI name) here: http://datahub.io/dataset/fixes/resource/b8294c35-4829-45b0-aea5-39f2dde958a9 There are 103 to fix. Cheers :-) Nicolas1981 (talk) 07:06, 18 September 2014 (UTC)
Have downloaded the list and will update coordinates if possible, otherwise clean them up at my leisure. Matroc (talk) 23:22, 18 September 2014 (UTC)
Done - These have beeen taken care of! - Matroc (talk) 00:38, 20 September 2014 (UTC)
Does that mean that the lot of the stuff at User:Nicolas1981/Syntax checks can be deleted from the list? Nurg (talk) 04:11, 20 September 2014 (UTC)
I do not believe so as this is a slightly different issue, so No - Best to get Nicolas1981 to answer that question... - Cheers! Matroc (talk) 03:09, 21 September 2014 (UTC)

Should article discussion pages be archived and, if so, when?[edit]

At the discussion page for Karachi there was a brief discussion about if and when the discussion pages of articles should be archived. Although there were only two participants, they seemed to conclude that it was only necessary to archive discussion pages when they became very long and unwieldy.

Usually when I edit an article for the first time, I check its discussion page first to see if there is any guidance regarding language variety, 12 or 24h clock, currency notation or other sensitive issues where I might edit against an established consensus. This is less quick and easy if I have to open each of a series of archives. Because discussion pages usually have a table of contents and the sections are typically arranged in chronological order, I think archiving discussion pages should be a rare event instigated only by necessity.

An opposing viewpoint is that closed discussions from previous years should be archived and is exemplified here. --W. Frankemailtalk 07:13, 16 September 2014 (UTC)

I did some archiving for legacy WT discussions on very long talk pages (basically anything not concluded before 2013). This was because it would be unlikely that a discussion not concluded on WT would continue on WV after the move, and a very long page may be off-putting to a new user. Do remember that some articles have nearly 10 years of discussions built up, and in any case the material is still available on the archive page.
I would still take archiving on a case by case basis, but perhaps it would be good to agree on topics such as Regions and Date/Time that should remain on the talk page indefinately. --Andrewssi2 (talk) 07:43, 16 September 2014 (UTC)
I see no reason why we need the legacy WT discussions because we're not WT. We're Wikivoyage, an entirely separate project. In many cases, opinions expressed are from contributors who are no longer part of either project, having left years ago, and are largely irrelevant today. K7L (talk) 16:33, 16 September 2014 (UTC)
Archives Because the content that we have here is a product of those discussions. —Justin (koavf)TCM 16:35, 16 September 2014 (UTC)
I didn't want to go off-topic with WT archiving. The original question from User:W. Frank was around archiving guidance, and if perhaps we should be careful not to archive topics that are fundamental to defining an article. Andrewssi2 (talk) 00:33, 17 September 2014 (UTC)
Over at Rational Wiki, they use a program on many pages that automatically archives any topic that has had no contributions in a fixed time period. I think some of their time periods are a bit too short — they go as low as 48 hours for busy pages like their pub — but other than that it seems to work very well. Pashley (talk) 22:06, 23 September 2014 (UTC)

Legend on left hand side of maps no longer visible?[edit]

The bar and legend on left hand side of maps appear to no longer show up. Only the zoom level appears on that side. Anyone else notice this or is it just me? - Matroc (talk) 21:43, 16 September 2014 (UTC)

Apparently this was corrected - Thanks! - Matroc (talk) 04:28, 17 September 2014 (UTC)

Javascript changes coming soon ("All your scripts are going to break" edition)[edit]

This information has been sent out for weeks, if not months, but I'm not sure if it's reached the right people at Wikivoyage. This message is for you if you could be described (even a little bit) by one of these categories:

  • Volunteers developing gadgets (such as Twinkle, HotCat, etc.).
  • Users that maintain their wiki's MediaWiki:Common.js scripts.
  • Users that have their own personal scripts.
  • Users who get questions when other people's scripts break.

Several deprecated methods in MediaWiki's JavaScript modules will be removed soon (early October). Please check your code to ensure it won't break with these changes, and update it if needed. Please also check and fix any gadgets or scripts you or your wikis rely upon, to prevent breakage.

What's going to break[edit]

Deprecated methods to be removed in MediaWiki 1.25:

  • Remove mw.user.name() method. 1 Use mw.user.getName() instead.
  • Remove mw.user.anon() method. 1 Use mw.user.isAnon() instead.
  • Remove mediawiki.api methods' "ok" and "err" callback parameters. 2 Use the returned Promise interface instead.
  • Remove mediawiki.api.category "async" parameter. 2 The ability to override $.ajax() to not be asynchronous has been removed. The default (asynchronous) behaviour remains. Use the Promise interface to retreive the fetched data from the API.
  • Remove jquery.json module. 3 Use standardised JSON.stringify and JSON.parse methods. And depend on the "json" module to ensure a polyfill is lazy-loaded for cross-browser support.

If your script contains these functions, then they're going to break. If you use a script, and the author isn't active any more, and you don't know whether it's going to break, then I believe that all you need to do for the first couple is read (or search) the script and see whether the bold-faced words appear in them. If not, then it should be okay. I saw some of the cleanup over at the English Wikipedia a few weeks ago, and it didn't look too difficult.

When it's going to break[edit]

These removals will land in MediaWiki 1.25alpha in early October 2014, being deployed to Wikimedia wikis in October 2014 (probably 1.25wmf2 or 1.25wmf3).

How to stop things from breaking[edit]

If nobody here can figure out what needs to be done, then you can ask for assistance on the the wikitech-ambassadors mailing list.

If you know more, if you've already updated certain scripts, or if you're able to help people, then please feel free to post that information here. Also, if you are active at any other languages of Wikivoyage or any other small projects, please pass this information along to them. Thanks, WhatamIdoing (talk) 05:27, 18 September 2014 (UTC)

Upload files,?[edit]

Wikimedia Commons logo

Hello! Sorry for writing in English. It was noted that on this wiki there is little community activity around uploads: less than 50 "Delete" actions in "File" last year.

I guess this wiki doesn't have the interest or energies to maintain complex templates and metadata, especially for EDP files. I propose to

so that no new work is needed on this wiki and all users can have a functioning, easy upload interface in their own language. All registered users can upload on Commons.

All this will be done around 2014-09-30.

  1. If you disagree with the proposal, just remove this wiki from the list.
  2. To make the UploadWizard even better, please tell your experience and ideas on.
  3. In all cases, existing files will not be affected, but everyone is welcome to join m:File metadata cleanup drive. The goal is to give better credit to the authors who provided us their works.

Nemo 19:12, 18 September 2014 (UTC)

Great push! Just a little sidenote - doesn't it sound funny that "upload activity" is measured in "file deletions" here? ;) Cheers, Horst-schlaemma (talk) 08:32, 19 September 2014 (UTC)

ORCID[edit]

I've created a userbox, {{User ORCID}} for users who have an ORCID identifier. You can see it in use on my user page. ORCID identifiers disambiguate contributors with similar names, and unify the works of people who have published under different names. Anyone may sign up for one, free, and I encourage you to do so, and to display it using this template. More information on the use of ORCID identifiers by Wikimedia project editors may be found at w:en:WP:ORCID. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:08, 18 September 2014 (UTC)

Close old expeditions?[edit]

I thought I would post this in the pub first. I noticed that the expedition page is quite long and has a few expeditions that have not been updated for a while (both article and discussion pages), and even some not touched since before the WT fork in 2012.

Examples of 'stale' expeditions include (but certainly not limited to are) Wikivoyage:Florida_Expedition, Wikivoyage:Maryland_Expedition, Wikivoyage:Education Expedition and Wikivoyage:Fellow_traveller_Expedition.

In order to give more prominence to those currently active expeditions, can we archive those that have not been touched for over a year into the archive section and mark them archived with the {{historical}} template? --Andrewssi2 (talk) 03:05, 22 September 2014 (UTC)

Please do, that would be more informative. If there is a group of users willing to restart a "historical" Expedition, they can always do so. PrinceGloria (talk) 05:38, 22 September 2014 (UTC)
Thanks. Yes, it would be good fto indicate 'Historical' expeditions that could one day be restarted. I will try this out with Florida (a WT era expedition) and see if anyone has feedback before doing this wholesale. --Andrewssi2 (talk) 22:33, 22 September 2014 (UTC)
I think this is a logical step. It's neater if only the active (or at least relatively recently active) expeditions are listed as such; otherwise, we risk diffusing people's attention. Ikan Kekek (talk) 23:28, 22 September 2014 (UTC)
Indeed. I was hoping to draw new people into the active areas such as Wikivoyage:Search Expedition and Wikivoyage:India Expedition that have a good level of activity --Andrewssi2 (talk) 01:12, 23 September 2014 (UTC)
I'm proposing to close LGBT_Expedition because the Expedition has no concrete goals. The corresponding Wikivoyage:Information_for_LGBT_travelers is more appropriate for further discussions. --Andrewssi2 (talk) 00:13, 26 September 2014 (UTC)
We do need to distinguish between expeditions whose purpose is not supported by consensus or no longer makes sense vs. expeditions which would be valid were there interest and activity. WV:Routes Expedition is {{historical}} absent a consensus that WV really *needs* an article about Interstate 4; the same is true of RDF tags or any other expedition whose task is already completed or obsolete. These are {{historical}} as the task is no longer desired. By contrast, Wikipedia uses {{inactive}} or {{semi-active}} for valid topics (like WP:TRAVEL) which are dead only for want of users, and could be useful contributions if interested users in the future were motivated to revive them. They're abandoned, but without prejudice to their resuscitation should new users create a task list and set to work sometime in the distant future. WV:LGBT Expedition (and others that are inactive) still have valid objectives, but should be marked {{inactive}} so anyone stumbling across them will know they're currently dead or dormant. K7L (talk) 04:03, 26 September 2014 (UTC)

Several municipalities in same article[edit]

Hello, just interested in putting together a page about my current city, a Rust Belt community in the USA that (not surprisingly) doesn't seem to appear here at this point. As a political map will show you, it has several tiny satellite municipalities adjacent to it, e.g. w:Eastvale, Pennsylvania; w:West Mayfield, Pennsylvania, and w:White Township, Beaver County, Pennsylvania; they're legally separate, and the locals know which one they're in, but for the out-of-town traveller, they're essentially just different neighborhoods in the same city. At Wikipedia, these get separate articles because they're legally separate municipalities, but the Our regional hierarchy doesn't always follow the "official" breakdown... line at Wikivoyage:Welcome, Wikipedians makes me guess (although of course it's talking about a different level of "official") that here we want to cover the closely interconnected communities in a single article.

Three questions come out of this: (1) Would it be best to cover all of these communities in a single article? (2) The Cincinnati article has a "Notable neighborhoods" section. If we say "yes" to question #1, is it reasonable to cover the legally separate municipalities in a similar section, e.g. entitled "Related communities"? (3) If we say "yes" to question #2, is it reasonable to create the titles of the satellite municipalities (e.g. Eastvale (Pennsylvania) as redirects to the related communities section? Nyttend (talk) 04:51, 23 September 2014 (UTC)

It's perfectly fine to cover several adjacent communities in one article if that's what would best serve the traveler. Whether it makes sense to cover the other communities in a separate section depends on how much content each one would have. In the article for the town of Nyack, New York, which had 6,765 inhabitants in 2010, there is simply the following statement in the intro:
"This article also covers the nearby towns of Upper Nyack and South Nyack, immediately to the north and south of Nyack, respectively."
I don't hold that up as an example of a good article, as it's really lacking in content, but that's kind of the point: If there isn't much content and there are adjacent small towns that don't have a strong separate identity (which I think those probably don't), why create separate articles for them?
But my feeling is, just plunge forward and start writing, structuring the article in a way that you think best, within the basic guidelines of the Wikivoyage:Small city article template, which is flexible ("This template has a much briefer listing format than the big city article template, with fewer sections. If you think that your village or town or whatever needs more sections than are noted here, check the big city article template first for clues. Feel free to copy in some or none of those sections."). Once the content is all there, we can always change the structure if we determine in a discussion on the article's talk page that something else works better. Ikan Kekek (talk) 06:53, 23 September 2014 (UTC)
Sometimes our legally-incorporated municipalities are arbitrarily built that way too, throwing in multiple villages in an otherwise sparesely-populated area to get something of reasonable size instead of creating one separate entity for each one-horse town and hamlet. Prince Edward County is a prime example (grouping Picton, Bloomfield, Wellington); Greater Napanee is another (grouping Napanee and Adolphustown, although the Wikivoyage article also continues into the next municipal township). It makes no sense for the traveller to print off ten individual-village articles with just one attraction in each to cover a large rural area, even if a crowde city like Paris is split into twenty arrondissements. K7L (talk) 14:31, 23 September 2014 (UTC)
Thanks for the input. I've created a basic form (no images yet) at Beaver Falls (Pennsylvania); I thought disambiguation needed because there's also a w:Beaver Falls, New York. Do we disambiguate in hopes that someone will write a NY article, or do we just skip it because the NY article doesn't exist? Meanwhile, I'd appreciate comments on the article itself. I didn't understand the add-listing feature, so I simply skipped it. Nyttend (talk) 21:17, 23 September 2014 (UTC)
Nyttend - Good start. You seem to have the hang of what the content of each section should be. However, I'm afraid that despite your trepidation, it's a necessity per policy to include proper listings in the article. Adding listings is easy enough to do, and you don't have to click on the "Add listing" tab to do so. Wikivoyage:Listings explains the whole process, or else to automatically insert listing templates you can click on any of the seven icons on the top bar of the Edit screen, next to the word "Listings" - from left to right, they're for "See", "Do", "Buy", "Eat", "Drink", "Sleep", and generic "Other" listings. -- AndreCarrotflower (talk) 22:11, 23 September 2014 (UTC)
Also, regarding whether to disambiguate: in cases where one city of the same name is far more well-known than others, we tend to add parenthetical disambiguators to the lesser-known ones but omit them for the most famous one - i.e. Buffalo, New York vs. Buffalo (Wyoming). That being the case, I think it's safe to move Beaver Falls (Pennsylvania) to Beaver Falls as it's eighteen times the size of its New York counterpart, not to mention that it has some degree of fame as the setting of the TV sitcom "Mr. Belvedere" (you might want to include that bit of info in the article, btw). -- AndreCarrotflower (talk) 22:17, 23 September 2014 (UTC)
Man, I was a fan of that show and couldn't have told you that factoid. =) I don't think Beaver Falls, PA, is "so much more famous" than Beaver Falls, NY, as to be able to apply that guideline... but I also don't think Beaver Falls, NY, will ever get its own article. There's nothing there. So for now I think putting the PA article at the base name is fine. Powers (talk) 19:31, 24 September 2014 (UTC)

Update: Promoting Wikivoyage[edit]

Hello! First I want to apologize to the community for the huge gap in my communication. I should have done a better job of providing information and checking in. I plan to rectify my poor behavior with logging on every day and also adding updates regarding the project soon after they happen.

On to the update. Arranging a conference call has been more difficult than I imagined. For now I plan to focus my efforts on creating the presentation, how to videos, and updating the "Welcome travel guides" page. I will then resume contacting chambers. After the chambers (the targeted project group)I will begin finding and contacting location specific travel groups.

The first draft for the presentation is on Google Docs. The link is at User:Tbennert/presentation. I'll be working on User:Tbennert/welcome this week. Anyone is welcome to edit, comment, or question. Thank you!--Tbennert (talk) 19:40, 23 September 2014 (UTC)

Right, as nobody else has bothered commenting I'll try to write down a couple of thoughts. I think it would be good to urge the audience to try out WV themselves to see how practical and easy to use it is and also how easy it is to make it even better. Right away.
Unlike Wikipedia, a travel guide is something that you are directly using as it is - like a recipe in a cookbook. Ask the audience to use the WV article for their home town (if it has an article), a nearby larger town or a destination they visit. Or even to go out on the street right away and look for the nearest POI mentioned in the WV article for the city/town where the meeting is held/wherever they happen to be. Even many small towns have an article with something.
On the other hand, where information you add to WP has to have a source, information you add to Wikivoyage is usually, at least to some extent based on first-hand experiences and impressions, and therefore does not require any prior in-depth knowledge about the destination. Have the audience add something to the WV article of their hometown or some other place or again, the destination where they happen to be at right now. ϒpsilon (talk) 20:16, 25 September 2014 (UTC)
I like this suggestion. People usually have a "thing" that they recommend to visitors ("while you're here, make sure you eat at ____" or "If you go to San Francisco, be sure to walk across the Golden Gate Bridge"), and it's easy to see whether your "thing" is listed. WhatamIdoing (talk) 16:26, 26 September 2014 (UTC)

Official App[edit]

In which section should I add a link to the official app of a town? I am referring to this app. --Lkcl it (Talk) 19:40, 25 September 2014 (UTC)

Unfortunately I don't think that this app is the "official app". It is not linked from the tourist office in the Iseo article. It also does not appear to be developed by (or for) an official body like the city council. We should only link to apps that would be a primary source (city council, railway, bus company etc). If an app is suitable for linking then we should link to the developer's webpage, not a store for a particular platform. AlasdairW (talk) 20:32, 25 September 2014 (UTC)
Also Iseo municipality has collaborate to develop this app. I can't find any article in English to confirm that, but I have found this one in Italian where it is written: "Il Comune di Iseo e la società Itown Lab hanno creato “Iseo”, un’applicazione gratuita scaricabile da Itunes e Android, che promuove il turismo e permetterà di trovare tutte le informazioni necessarie per i turisti e non solo." "Iseo Municipality and the society Itown Lab have created "Iseo", a free app available on Itunes and Google Play, that will improve the tourism and that will allow to find all the information tourists need." --Lkcl it (Talk) 20:41, 25 September 2014 (UTC)
I tend to see Apps mentioned in the 'Get Around' section.
I sometimes download apps to a new city that I am visiting, but generally speaking they are student projects and not great in terms of quality. It is also hard for the WV community to review the quality of an app as well (since they have to go to the trouble of downloading, installing and running).
Finally it is very difficult to establish what is the 'official' app for a given city. The problem is more to do with the fact that App Stores have no quality control. --Andrewssi2 (talk) 23:36, 25 September 2014 (UTC)

Updating Calendar of events and festivals[edit]

I have spent some time cleaning up the month pages of Calendar of events and festivals. Bad links and inappropriate events have been removed and the format of the listing has been made consistent. Where possible I have also added the most recent know exact dates. These pages could now do with being expanded. Would appreciate input from others with events that attract international visitors. Why should we do this (I know list pages are not too popular)? Basically this is a good portal into other location pages on this site. The month pages have a lot of key words and with constant updating will attract good results from search engines, attracting more visitors to WikiVoyage. --Traveler100 (talk) 09:03, 27 September 2014 (UTC)

Stub and Outline Statuses[edit]

There are hardly ever any Stub status articles as it's very easy to find any page that's not using pagebanner and go in and fix it. However, there are a number of articles at outline status, for example Spitak that only just meet the minimum requirements for outline. I'm just wondering what everyone would think about changing the divsion between stub and outline so that articles with just a single line introduction and no listings should be classed as stubs as well, even although they have the template layout? -- WOSlinker (talk) 10:23, 27 September 2014 (UTC)

I think a city article that has the correct titles but no listings at all should be a stub. Regions however, as long as references city articles should be an outline article. I think also if we really want to make use of the status rankings then there is a need to go through the outline article as I think many could be marked as usable. --Traveler100 (talk) 11:14, 27 September 2014 (UTC)
By itself it sounds like a reasonable idea. The problem is that we have a tremendous number of outline articles, the total number of articles being 26,189, I'd estimate there are 15-20,000 outlines. The process should be automated somehow, and as Traveler100 said there are a great number of outlines that qualify for usable status (I nowadays update those whenever I run into them) which also would need to be updated accordingly. Should we have to go through the articles one by one manually I guess that would be a little too much even for someone like yourself and Matroc. ϒpsilon (talk) 11:37, 27 September 2014 (UTC)
The Maintenance panel shows just under 14,000 city outline article, yes a very large task. However could at least tidy up your favourite regions. Using CatScan set depth to 10, category to country of choice and has template to outlinecity gets a list that is doable. --Traveler100 (talk) 12:08, 27 September 2014 (UTC)
In any case, I doubt that changing outline→usable is something that can or should be completely automated. It's too easy to fool an automated process by feeding it text that's pure copypasta from the CVB or venue blurbs, endless marketing fluff like "beautiful sunsets, refreshing breezes, fun for the whole family and ideal for business and leisure travellers" that gets dumped in any random destination but incomplete listings with no contact info and more promotion than fact. I'd hold those at "outline" until fixed even if there were a hundred kilobytes of meaningless text. An automated process could spot particularly long or detailed "outlines" so that someone could look at them manually, but would likely not be clever enough to see the difference between a good article and a heap of copypasta. K7L (talk) 13:26, 27 September 2014 (UTC)
That's the whole point of the 'stub' class; it's supposed to designate articles that can easily be brought up to outline status. Consider 'outline' our version of Wikipedia's stub, if you must. Powers (talk) 20:06, 27 September 2014 (UTC)

Extension:CreditsSource[edit]

Something seems to be wrong with mw:Extension:CreditsSource, it's not displaying MediaWiki:Creditssource-credits properly in the page footer but instead displaying a hard-coded default which contains two clickable links to a rival travel wiki and one redlink labelled as "history". The link should go to the history page here, not red-link or off-site. I don't see anything in Bugzilla and no one has edited any relevant MediaWiki: messages lately, has someone or something broken the underlying extension code? K7L (talk) 13:58, 27 September 2014 (UTC)

The links above the edit box when creating a new page are also missing; there used to be a one-click option to drop {{smallcity skeleton}} or a few of the others onto a blank page. K7L (talk) 16:12, 27 September 2014 (UTC)
Everything looks fine to me at the moment. Powers (talk) 20:06, 27 September 2014 (UTC)

Derivative FX[edit]

Since the tool Derivative FX for uploading the derivative images from Commons doesn't work, I'm not able (in an easy/quick way) to perform that activity. There's an alternative tool that I can use? Any suggestion would be highly appreciated. Thank you. Massimo Telò (talk) 16:57, 30 September 2014 (UTC)