Wikivoyage:Travellers' pub

From Wikivoyage
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


WT links in Wikipedia[edit]

I just noticed a link to WT in Wikipedia (here) and I guess there are many others. I unfortunately have no time to fix them right now, but any volunteer for the task? That's one of the only easy ways we have to increase WV traffic, so not doing it would be a shame.

  • Go to and for EACH language's wikipedia (there are many):
  • Find the search box, type "wikitravel" in it and type Enter
  • Ignore any article which is actually about Wikitravel itself
  • Open each article that contains a link to WT
  • Find and click the Edit button or press Alt+Shift+e
  • Press CTRL-f and find the WT link
  • Find the equivalent article on WV
  • Replace the WT URL with the WV URL

Please let us know as an answer here what languages' Wikipedias you have processed, so that work is not duplicated, thanks a lot! Syced (talk) 06:18, 23 June 2015 (UTC)

I suggest to use this link for the second step (using the equivalent link for each language). --Andyrom75 (talk) 06:41, 23 June 2015 (UTC)
Sorry to ask the question, but does our status as a sister project allow us to do this?
I would guess that under normal circumstances Wikipedia wouldn't appreciate a website changing the links of a competitor to their own. I hope that I'm wrong in this instance. Andrewssi2 (talk) 06:49, 23 June 2015 (UTC)
Such changes have been already performed in the past in thousands of occurrences in several languages, and if I'm recalling it correctly, it has been discussed here on en:voy as well.
Briefly, (just for example) if an article of a city mention the WT external link as a source of information, it can be easily substitute it with the equivalent in the same language adding maybe the one related to the official language of that city (e.g. in fr:w Moscow article, the WT link could be replaced with the fr:voy and maybe ru:voy ones). Clearly, be sure that the page exists and use internal wikilink instead of external links that between sister projects doesn't make a lot of sense.--Andyrom75 (talk) 07:47, 23 June 2015 (UTC)
This was likely done once, a couple of years ago. See Wikivoyage talk:Search Expedition. Many of the WT links which were left behind are on talk or project pages, where changing other people's comments was likely deliberately avoided. Certainly, WP doesn't want links in articles to point to an external, commercial site where that site merely mirrors content already in one of WMF's own projects, as that sort of external link is spammy. They also wouldn't want a wiki or other user-editable content cited as a reliable source for anything, so the only place these should occur in actual articles (other than the pages about WV and WT) is in "external links". K7L (talk) 16:12, 23 June 2015 (UTC)
I would still be quite upset if somebody did such semi-automatic link changes in my home wiki (at least if I were not active here). Changing external links to sister project links providing the same information should not controversial (in articles), but if the WT article is more complete or contains some key information absent from our article, then it surely is. --LPfi (talk) 12:16, 26 June 2015 (UTC)
There were a rare few languages which were problematic because they didn't fork during the main WT to WV transition; Japanese was one, so links to WT in that language were often left alone. User boxes claiming "user so-and-so edits on Japan WT" were the usual issue, although some other rarely-edited languages were affected. K7L (talk) 12:51, 26 June 2015 (UTC)
I looked through en.wp's list. There were very few in articles, and even fewer that should be converted. Either it was pointless spam (usually claiming to be a reliable source) or a link to WT was actually required (e.g., for copyright/license attribution). WhatamIdoing (talk) 19:24, 27 June 2015 (UTC)
It seems sv-wp has quite a lot of links (in the External links section). Was that one of the problematic ones? The normal sister project links should go to the Swedish versions of the projects (where most pages are stubs), so the voy:en links probably have to be treated (although not formatted) as normal external links. For destinations where our version is at least as good as WT changing the links should be no problem, as long as the edit summary is adequate, but I suppose WT can be better in some cases. Does anybody have a bot that could see whether any substantial edits have been done on WT after the fork? --LPfi (talk) 20:51, 27 June 2015 (UTC)
I see no need to have a bot look at WT, as any links to sv: which were left unchanged were likely missed by mistake. Swedish was one of the first half-dozen or so languages for m:Wikivoyage#Creation, so there's no reason to keep a link to basically the same content on a competing external project. Finnish is one of the problem ones (like Japanese, there is no WV) and maybe Swedish was presumed (inadvertently and incorrectly) to be part of that same issue? Certainly, any of the languages which were created on WV late (such as Chinese) are worth verifying to make sure the external links were changed to point here. K7L (talk) 21:25, 27 June 2015 (UTC)
"On a competing external project" with an antipathetic attitude toward the WMF and a history of real-world legal antagonism, no less. That's a salient point that, IMO, overrides any comparatively minor concerns about tampering with WP article content (a line of thinking that smacks of article ownership issues anyway). -- AndreCarrotflower (talk) 21:55, 27 June 2015 (UTC)
I changed thousands of WT links to WV links more than a year back. I cannot figure out how to write in the other direction and therefore did not do Persian and Arabic. Travel Doc James (talk · contribs · email) 06:27, 11 July 2015 (UTC)
Anyone with RTL experience and willing to do this? user:Saqib maybe? :-) Syced (talk) 06:54, 16 July 2015 (UTC)
What is RTL? I'm travelling by the way. --Saqib (talk) 11:41, 16 July 2015 (UTC)
"Right To Left". The interaction between words with Latin characters (such as most URL:s) and neighbouring text in Arabic & al is quite confusing for those not used to it. --LPfi (talk) 13:55, 16 July 2015 (UTC)
Sure, will do. Please let me know what to do. --Saqib (talk) 04:40, 17 July 2015 (UTC)
Basically go to Wikipedias that have RTL languages and search for Wikitravel. Arabic only has a couple left [1]. Likewise Farsi [2] and Hebrew [3]. Replace these links with WV ones if possible. Travel Doc James (talk · contribs · email) 15:58, 21 July 2015 (UTC)
Doc: Sorry for late response as I'm travelling these days. So please check if this is that you want me to do? --Saqib (talk) 13:49, 25 July 2015 (UTC)
Hum yes appears to be resistance. Likely we need someone in good standing in that community to help us. Travel Doc James (talk · contribs · email) 19:18, 14 August 2015 (UTC)

Dynamic maps[edit]

Hey All. We appear to have an issue with the dynamic maps. They call tile from mapquest which means that the user's IP is exposed to a third party which is not allowed per our privacy policy. Thus I have been informed that some layers of the dynamic maps need to be turned off.

Now the good news. WMF is putting together its own tiles which should be available soon. If you are interested in helping they are looking for front end java script developers. [4] Travel Doc James (talk · contribs · email) 04:44, 20 July 2015 (UTC)

This is extremely annoying. At the moment, we do not include any tiles from mapquest automatically. We only call them if the user decides to do so by switching the tiles manually, which is perfectly in line with the privacy policy because the tiles section contains clear information on which tiles are from the WMF-controlled servers, and which are not.
However, the tile server on is extremely unreliable, and most problems with the dynamic maps are caused by overloads and down-times of this server that is, unfortunately, beyond our control. WMF should establish a reliable and complete tile server before making any complaints or forcing us to switch off certain tiles that we do need for making our travel guides useful. --Alexander (talk) 13:46, 20 July 2015 (UTC)
Previously (ie yesterday) when I went to Cranbrook it automatically pulled tiles from mapquest without me selecting it. Now I need to select mapquest before it will load from their. That seems a reasonable compromise to me User:Atsirlin and hopefully enough for those involved with maintaining privacy. Travel Doc James (talk · contribs · email) 15:48, 21 July 2015 (UTC)
Hi Alexander, could you show me the usual process for enabling tiles from mapquest? Is this an option in {{Mapframe}}? Thanks! Stephen LaPorte (WMF) (talk) 16:56, 22 July 2015 (UTC)
Go to a page with a map, for instance Amsterdam/Binnenstad#Get in. At the upper-right corner of the map, there's an icon with a stack of layers, which brings up a menu. From that menu, various tiles can be manually chosen by the user. K7L (talk) 17:05, 22 July 2015 (UTC)
Thanks! Stephen LaPorte (WMF) (talk) 17:53, 22 July 2015 (UTC)
@Atsirlin:, I agree 100% - this is very annoying indeed, and I hope the new OSM-based tile server, hosted in WMF production cluster, will be available within a few weeks - Max and I are working on it every day. --Yurik (talk) 23:17, 22 July 2015 (UTC)
On a side note, apparently this issue has been discussed on meta before. --Yurik (talk) 23:17, 22 July 2015 (UTC)
Yes, we have discussed it, and I thought that our current solution (tiles from external server not loading automatically) is fine with everyone. Nice to know that someone is working on the new tile server. Thanks for the effort that you put into it, and I look forward to seeing it operational! --Alexander (talk) 11:24, 23 July 2015 (UTC)

Is there a source repository for PoiMap2 somewhere? I found, but it looks like an outdated fork. I wanted to make a pull request. MaxSem (talk) 19:57, 11 August 2015 (UTC)

Hello MaxSem! PoiMap2 is maintained by Joachim, who is not a Git fan it seems, but I have access a copy on an FTP server and can mirror the script to my Github whenever requested. I have left a message on his talk page saying you want to collaborate, the best is probably to explain to him what you intend to develop, or send him the source code if written already :-) Thanks a lot for your interest in dynamic maps! Hopefully they can be reused on other projects Syced (talk) 07:28, 14 August 2015 (UTC)

New service, is coming to Wikivoyage. Maps provide two features - tiles and static images, but at this point only has the basic one-language labeling. We hope it can replace the frequently breaking labs instances as a default base layer. This is a trial service - once it is clear that the service is needed, we will have to throw more hardware at it (relatively easy from the technical perspective, but requires some work and budget allocations). See also Maps home. --Yurik (talk) 16:46, 27 August 2015 (UTC)

Yurik, that's great news, but I think that I did not get the point. Do you want us to use instead of labs from now on? I believe we can do it (of course, with Joachim's consent), provided that you are available for resolving bugs and problems. --Alexander (talk) 17:21, 27 August 2015 (UTC)
@Atsirlin:, yes, that's the idea, but there is one "but": - user:MaxSem and I have been working on the new service for about 4 months now, and we think it is ready for real trials. Wikivoyage is a perfect place to be its first user, but I will not be online for the next week (taking my first vacation in a year and disconnecting from the grid), so I will not be able to assist with resolving bugs until I come back September 8th. It would be awesome if the community could evaluate the new service and report any issues found to Maps discussion page or in the phabricator, but I think we should wait one week until I come back to actually switch all of the map templates to it. What do you think? --Yurik (talk) 04:36, 28 August 2015 (UTC)
I agree. Moreover, it takes a few days before map scripts (which are also sitting on tools.wmflabs) are updated. Joachim, what is your opinion? --Alexander (talk) 07:20, 28 August 2015 (UTC)
First of all, the access from * to must be made possible. Otherwise, I can not test anything. -- Joachim Mey2008 (talk) 17:30, 28 August 2015 (UTC)

Request for feedback & testing: listing editor v2[edit]

How to enable the new listing editor
Listing editor in two-column mode
Listing editor in single-column mode

I've been spending some time in recent weeks on a rewrite of the listing editor, and it's now at the point where wider feedback and testing would be very helpful.

Update 8-Aug: changes are now live for all users, no configuration is required

Any logged-in user who is interested can test out the new listing editor by doing the following:

  1. Click on the "Preferences" link at the top right of any page.
  2. Click on the "Gadgets" tab on the preferences page.
  3. Uncheck the "ListingEditor" box under the "General" heading (do not skip this step - the old & new listing editor cannot be run at the same time).
  4. Check the "ListingEditor2 (beta)" box under the "Experimental" heading.
  5. Click the "Save" button at the bottom of the page to save your gadget settings.
  6. Go to any article and add or edit a listing using the new listing editor.

Changes in the new version:

UI Changes:

  • The listing editor dialog box and its fields will now expand to fill up more of the available screen space, allowing listing fields to be edited without the need for scrolling.
  • The listing editor dialog box will now more cleanly collapse from two columns to a single column on very narrow screens.
  • Standard fields that have pre-existing values will now always be displayed. As an example, when editing a "sleep" listing that has existing "hours" data, "hours" will appear as an editable field in addition to the standard "checkin" and "checkout" fields.
  • The current listing editor suppresses the "fax" field in the listing editor dialog since it is seldom used; the new version additionally suppresses "alt" in order to make better use of screen space. Note that if either field has a pre-existing value then it will not be suppressed.

Functional Changes

  • When editing a listing, users can now enter an edit summary and mark an edit as minor.
  • The listing editor will no longer automatically delete unrecognized attributes like "phoneextra" or "wikipedia". See MediaWiki talk:Gadget-ListingEditor.js#Extra fields.


  • Multi-paragraph listings are now editable, and newlines will be automatically converted to <p> tags so that the listing displays properly per mw:Help:Lists#Paragraphs in lists.
  • If there is a failure that prevents saving the listing, the listing editor dialog will re-display with all of the user's changes intact so that no work is lost. Additionally, submissions should no longer fail if the user's session expires (due to the use of mw.Api#postWithToken). See Wikivoyage talk:Listing editor#Error adding listing.
  • Other minor fixes.

Feedback and bug reports would be much appreciated - if you don't like something, want to see additional changes, etc please comment. If you are reporting a bug, please be sure to state what browser and OS you're using and how to reproduce the problem (article & listing you tried to edit, what action you took, etc) since if I can't reproduce the issue it will be much harder to fix. There is some work remaining to make the code easier to customize for other language versions, and a few bugs that exist with the current listing editor still exist with the new listing editor (example: User:Wrh2/Sandbox#Content field & equal sign), but I think that this version is close to being ready for widespread use. Thanks in advance to anyone willing to provide feedback. -- Ryan • (talk) • 05:09, 21 July 2015 (UTC)

Just wondering if price could also have the $ symbol listed as well? I know that it's easy to find on a keyboard but just thinking it would be nice to have it included along with the others. -- WOSlinker (talk) 10:31, 21 July 2015 (UTC)
Is it technologically possible to have some things that are the same for huge geographical areas or just one city automatically appear in a listing? E.g. the national currency (e.g. any listing whose breadcrumbs is within the US automatically gives USD for the price) the local area code (I have to only enter the local number without the local area code) or the country code (e.g. all listings in Nicaragua automatically give +505 at the beginning of their phone number whereas all those in Germany automatically give +49). Furthermore something that may (or may not) be an issue is that in Germany for example some cities have more than one ZIP code. The ZIP code is needed as part of the address, but currently addresses only include street name and number. Wouldn't it be a good idea to have a field to enter (non default) ZIP-codes? After all, some GPS devices work better with them and the postal service requires them. Hobbitschuster (talk) 12:33, 21 July 2015 (UTC)
There is no such thing as a "German ZIP code", short of resuming a US military occupation there. Zone Improvement Program™, ZIP™ and ZIP+4™ are (or were) trademarks of the US Postal Service.™ K7L (talk) 13:21, 22 July 2015 (UTC)
I know, but most non-Germans don't know what the hell a "Postleitzahl" is. And it is functionally the same thing as a ZIP-code. I was (trying to) use it as a generic term, just like not everybody requesting a "Kleenex" will be outraged when getting the generic knock-off... Hobbitschuster (talk) 14:31, 23 July 2015 (UTC)
"Post(al) code" will be an uncontroversial generic term, I think. :-) Ikan Kekek (talk) 18:08, 23 July 2015 (UTC)
I shall keep that in mind for future reference... Hobbitschuster (talk) 18:55, 23 July 2015 (UTC)
Wondering if it would be useful to also store this type of data on Wikidata? Or store it entirely their and then all languages of Wikivoyage could pull from a single source? We could have a bot initially move it over. Travel Doc James (talk · contribs · email) 15:52, 21 July 2015 (UTC)
That might run into compatibility issues. While de-WV is currently wondering about a similar issues, over there they don't use listings but rather "vcards" which work differently (and confuse my humble self to no end). While I do think that having listings (or most of the information contained in them) stored in Wikidata is a good idea and should be the end goal, some cross-language compatibility seem to be more pressing. But as I am not a technical expert of any kind, I may well be much mistaken... Hobbitschuster (talk) 16:00, 21 July 2015 (UTC)
I would imagine that each place would be stored as an item. These items would then have multiple properties. These properties would than be individually pulled from Wikidata and presented by each language how they wish. Thus if en likes a certain 8 properties in a certain format and de likes 10 properties in a certain format both languages could get what they wish while still using wikidata. At least that is my understanding. Travel Doc James (talk · contribs · email) 16:13, 21 July 2015 (UTC)
@Jmh649: Regarding wikidata, see meta:Wikivoyage/Lounge#Wikidata for listings! for current status on efforts to move listing information to wikidata. There are a lot of issues to resolve, both from a technical and a process standpoint, so sharing listing information remains something that is unlikely to happen in the near future.
@WOSlinker: Regarding adding the "$" symbol, that should be easy enough if it is something people would like to see. Ideally we should have more currency symbols available, but there is limited space in the dialog UI, so suggestions/mockups for implementing a drop-down or similar UI element might be useful.
@Hobbitschuster: Regarding automatically loading country-specific data like country codes, that would be a great feature but isn't straightforward to implement - determining the country requires traversing the category hierarchy, which would make the listing editor much slower, and would also require a lot of additional logic. It's an excellent idea, but in the interest of getting the current updates live without having to do significantly more development work it is probably something that is better handled as a future feature request instead of in the current update.
Regarding adding zip code as a listing editor field, that would require a consensus to add that field to the listing template - if the template is changed then it would be easy to add support in the listing editor, but if it's OK I would ask that changes to the template be moved to a separate discussion so that this discussion can stay focused on the current updates to the listing editor. -- Ryan • (talk) • 16:20, 21 July 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Sure. I wanted to just raise those points as "nice to have" for the next upgrade/update... And as I sadi, my technical understanding of these matters is limited at best. If any of them can be done without too much work or wasting resources, I am all for them. Otherwise, there are bigger marine vertebrates that harken the pan ;-) Hobbitschuster (talk) 17:43, 21 July 2015 (UTC)

Always bigger fish to fry! ;) - Matroc (talk) 03:46, 23 July 2015 (UTC)
Just wondering if the country could be determined with code as below (with some added error checking and a little more code to work when on the actual country page as the code below only works on subpages of the country)? Anyway, it would be better as a feature for v3 rather than delaying v2.-- WOSlinker (talk) 22:07, 21 July 2015 (UTC)
var level1 = $("#contentSub a:nth-child(1)").html();
var level2 = $("#contentSub a:nth-child(2)").html();
var level3 = $("#contentSub a:nth-child(3)").html();
var country;
if (level1 == 'Asia') country=level3;
if (level1 == 'Africa') country=level3;
if (level1 == 'Europe') country=level3;
if (level1 == 'Oceania') country=level2;
if (level1 == 'North America') country=level2;
if (level1 == 'North America' && level2 == 'Central America') country=level3;
if (level1 == 'South America') country=level2;
Possible future reference if data is in Wikidata then one should be able to retrieve Calling Code from there or go to actual Wikidata country record and retrieve it as well (may be a long way off yet) - as usual there may be an issue with timing/parsing that might present a problem - Matroc (talk) 03:46, 23 July 2015 (UTC)
I use the 'alt' field very frequently; is there any way we can retain it? Powers (talk) 00:07, 22 July 2015 (UTC)
This edit restores the alt tag - the only downsides are that the listing editor will take up slightly more vertical space, and it may be more daunting for new users who see more fields to fill out. I don't feel strongly either way as there are good arguments both for displaying or suppressing the lesser-used fields. -- Ryan • (talk) • 01:00, 22 July 2015 (UTC)
I, too, am strongly in favor of retaining "alt". -- AndreCarrotflower (talk) 03:13, 22 July 2015 (UTC)
The "alt" field is probably more often misused to repeat the name of a hotel or insert some promotional text about it than it is used correctly, such as by giving the Chinese, Japanese, Korean, Russian, or Arabic name (for example) for a hotel or restaurant or its former name, but it is a useful field sometimes and is probably better to retain. Ikan Kekek (talk) 20:53, 22 July 2015 (UTC)
Keep the alt field - Matroc (talk) 03:46, 23 July 2015 (UTC)
Since there is a lot of work and discussion about Wikidata - For future version? - I believe that a Wikidata ID field could be added - Matroc (talk) 03:46, 23 July 2015 (UTC)
I think alt is useful for displaying the names of POIs in both English and the local language; the first so the reader understands what it is, and the second for sign and conversation reference. James Atalk 13:11, 23 July 2015 (UTC)

Some extra requests:

  1. Can we make Name a mandatory field?
  2. Can we apply a Regular Expression checker on the Email field?
  3. Can we reduce the width of the Latitude and Longitude fields?
  4. Can we have a regular expression to recommend keeping the length of the values of Latitude and Longitude fields to 4 decimals?
  5. Can Type be the first field on the form?

Andrewssi2 (talk) 03:57, 23 July 2015 (UTC)

Thanks for the feedback. Name isn't actually a required field in all cases (see Template talk:Listing#Name is mandatory or not?), but the current listing editor does require that at least one of name, alt or address be non-null. Similarly, for very small places lat/long coordinates of up to 6-7 significant digits (within a foot) might be appropriate, and many GPS databases and mapping services (including return data at higher precisions, so I think we should be cautious about being too prescriptive (see also w:Wikipedia:WikiProject Geographical coordinates#Precision guidelines). A checker on email makes sense and I'll add that to the TODO list. As to moving the "type" field, if others want to see it moved it's an easy change, although personally I would think we might want to de-emphasize it since it is something that is set automatically based on section type and unlikely to change. -- Ryan • (talk) • 04:40, 23 July 2015 (UTC)
Simple email address validation has now been added - invalid emails can still get through, but it will catch common errors, which I think is better than trying to get too fancy and accidentally blocking a valid email. The current validator just looks for "something@something.something", with the only stipulation being that "something" must not be an "@" or whitespace - this means that an email address like ".@..." would get through, but again, I think letting a bad email through is preferable to accidentally blocking good emails. Feedback and testing appreciated as always. -- Ryan • (talk) • 05:09, 23 July 2015 (UTC)
I tried the new editor yesterday and today, it is Wonderful! Especially great to see that it fixes the session issue, no more losing carefully written text in an old browser tab :-) What else to ask... link to Wikidata item and pre-filling of lat/long/name/alt/website/image from this Wikidata item? :-) (National Art Center sample) Syced (talk) 02:44, 24 July 2015 (UTC)

Feedback Round 2[edit]

First, thanks to everyone who took time to provide testing & feedback. I think most of the above comments have been addressed, with a few items moved to WV:Listing editor#Feature requests to be considered in the future, but there are (I think) two remaining suggestions from the thread above that would benefit from additional comment:

  1. Should the list of currency symbols also include "$"?
  2. Should the "type" drop-down be the first field on the form?

Regarding #1, there is limited space for currency symbols, so while adding just one more is probably fine, it would be good to get an idea of whether people want to use the limited space for the "$" symbol or if we should just leave things as they are. If anyone has an idea for a UI that would allow more symbols to be included as options, via a drop-down or other UI, and is willing to create a mock-up then I can look into making a bigger change. Longer term, Hobbitschuster's suggestion about figuring out how to display the currency symbol appropriate for the country being edited is a good one.

Regarding #2, making the listing "type" field the first item in the editor is an easy change to make, but since listing tag type should almost always match the section type it seems like an equally valid argument could be made for leaving the listing type drop-down where it is, or even suppressing it altogether. Comments would be appreciated.

If I've missed something, or there are additional bug fixes or changes to make, please add them below. Thanks in advance! -- Ryan • (talk) • 17:45, 25 July 2015 (UTC)

I have to add, that in some countries there is a "parallel currency" (usually the dollar, but in some cases the Euro) that is used for the price of many high value goods, such as hotels geared towards international visitors, whereas other things (say food) are (at least officially) priced in the national currency. As those countries tend to have high inflation and prices in the parallel currency are more stable, it might make sense to treat them as if their inofficial currency was in fact the official one. Hobbitschuster (talk) 23:54, 25 July 2015 (UTC)
It does make sense, and we do :-) See Wikivoyage:Currency for the relevant policy. JuliasTravels (talk) 09:53, 29 July 2015 (UTC)
@Ryan; thanks for all this work, it works perfectly well for me. As for your questions: 1) I don't mind the "$" sign to be included. The real issue remains of course that our selection of currencies there is almost random, and the listing editor has no link to all the other symbols one would need. Not that I know how to improve that :-) Hobbitschusters long term idea to display per destination is a good one indeed. 2) I would leave the type-dropdown exactly where it is. It's handy to have to fix wrong listings, but it's not something you want people to directly mess with if they open a listing in the right section. I imagine that >95% of the time, it should not be used. JuliasTravels (talk) 10:03, 29 July 2015 (UTC)
Thanks for the feedback. Given that there is at least lukewarm support and no objection I've added the dollar sign to the list of currency symbols. I've got a bit more work to do to support some features used in other language versions, after which the new listing editor should hopefully be ready to go live. Further feedback and bug reports are of course still much appreciated. -- Ryan • (talk) • 03:28, 30 July 2015 (UTC)
I agree with the addition of the dollar sign, simply because not everyone uses an American-style keyboard that has the dollar symbol at easy access. While I'm happy to leave it at that, you could say we're missing a few other important ones, such as the Indian rupee (₹), but let's await another solution first. Furthermore, I think the type field sits nice where it currently is, for the reasons mentioned above. James Atalk 11:00, 30 July 2015 (UTC)

Changes are now live[edit]

The new version of the listing editor is now live for all users, and I've made additional changes so that captcha validation should be more reliable for anonymous users. Bug reports and feedback appreciated. -- Ryan • (talk) • 16:24, 8 August 2015 (UTC)

Discussion that may be of interest[edit]

On Jimbo's talk page Travel Doc James (talk · contribs · email) 16:33, 21 July 2015 (UTC)

Suggestions for banners on small screens[edit]

I'm putting forth a list of suggestions given at T105033 to solicit views on the experience of banners on very narrow mobile screens (typically 320px wide). Since banners are optimised for desktop screens, it might be good to look at these alternate solutions which could be incorporated in the developing extension and act as an improvement feature(Note that this is a parallel discussion which would not stall the ongoing work on the extension): The few options available for banners on very small screens are:

  • do nothing
  • a mobile specific parameter that loads a different file on a mobile screen (and an associated Wikidata property)
  • not loading banners at all (this will require care to ensure the img is not unnecessarily downloaded) in portrait mode (but show them in landscape)
  • adjusting the styling in some way. e.g. banners only
  • splash screen upon entering.
  • a coordinate parameter which specifies a focus area allowing you to clip a larger area and limit

Let me know if a new enhacement is worth introducing to improve the experience of banners on screen dimensions mentioned above.Thank You!--Sumit.iitp (talk) 10:13, 24 July 2015 (UTC)

I am not sure that one needs banners on such small screens. In my opinion, the old mobile view (each section collapsed in the mobile view and expanded by clicking on it) was close to ideal. Then banners are simply not needed. --Alexander (talk) 10:55, 24 July 2015 (UTC)
I'm completely for banners on the mobile view. Mobile usage will exceed desktop usage in the future (It probably already has) and we need to move with the times.
I'd also say that mobile screens are not typically 320 pixels wide. My iPhone 6 is far beyond that with its retina screen. Ideally a scaling solution should be employed. --Andrewssi2 (talk) 12:38, 24 July 2015 (UTC)
My suggestion would be not to disable banners based on whether a user agent is a mobile device or not, but to consider disabling based on screen size. If someone is connecting from a 320px screen then a banner is probably a waste of space and bandwidth, but as Andrewssi2 notes, someone connecting from a mobile device like an iPhone 6 has a screen resolution higher than some desktops. Insofar as the new banner extension can send different images based on screen resolution, if possible I'd suggest sending no image at all for resolutions below a certain minimum. -- Ryan • (talk) • 14:40, 24 July 2015 (UTC)
If you speak German; a similar discussion is currently taking place on German WV (which currently has no banners whatsoever) and the current consensus seems to be "no banners for mobile". There also seems to be a consensus against default banners over at de-WV.Hobbitschuster (talk) 15:09, 24 July 2015 (UTC)
I agree with Ryan; simply saying "no banners on mobile" is ridiculous, but saying "no banners if the window resolution is less than X pixels" is perfectly appropriate. On a 320-pixel-wide display, a 7:1 banner image would be about 40 pixels high. Too small to make out anything useful in most cases. Better not to waste that valuable screen real-estate. Powers (talk) 21:27, 26 July 2015 (UTC)
No banner below a certain minimum resolution seems the best solution indeed. While there's always an image and thus some information, banners mostly serve an aesthetic purpose. If you can't do it right, it has the opposite effect anyway, plus the waste of space. JuliasTravels (talk) 09:29, 29 July 2015 (UTC)
Large banners with images are essential to travelers learning more about their destinations. Many travelers won't carry big laptops with them, and will want to learn more about destinations on their phone. Also agree that mobile usage will exceed desktop, and in many countries it already has. I think "a coordinate parameter which specifies a focus area allowing you to clip a larger area and limit" is the most scalable solution. KHammerstein (WMF) (talk) 20:13, 28 July 2015 (UTC)
How exactly is the banner "essential" to learning about a destination? Powers (talk) 23:33, 29 July 2015 (UTC)
Maybe not the definition of 'essential', but banners have equal value with the other images for presenting an article. Andrewssi2 (talk) 06:38, 30 July 2015 (UTC)
No-one is disputing the added value of a good banner, and everyone agrees that when screen quality allows, it's great to have them on mobile too. When having to scale it down to a tiny one like on a 320 px screen, however, that value is pretty much gone and the image will become something undistinguishable. That's at least the concern people here have. You seem to feel that's not an issue, KHammerstein (WMF). Perhaps you can create an example to show how a coordinate parameter with a specified focus area would still have good value for the reader. Realistically, this focus area would have to be random. Setting the best focus area for all banners by hand, only for those tiny screens, which will become ever less relevant, seems like a bad way to spend our man power. Do we have any statistics about how many users visit the site on small screens? JuliasTravels (talk) 09:10, 30 July 2015 (UTC)
Wikimedia has some overall stats (I used June 2015), and if we assume that Wikivoyage has a similar traffic profile to the other Wikimedia sites (and that assumption can be challenged, although I can't think of a reason why they would be different) then we can see that 30% of visits were on an iPhone/iPad and another 15% were from Android devices. 47% of visits were from Windows and Mac machines, therefore mobile is in fact very close to overtaking desktop.
I can't see stats on the version of the device being used (i.e. iPhone 3G v iPhone 5) but these stats show the Android versions being used, and it seems almost nobody browses Wikimedia with a version older than 'Ice Cream Sandwich' (Version 4) that was first used in devices from 2012. Based on that I would say extremely few devices are used that have 320px or 480px width screens.
However to be balanced, we are excluding potential 'feature phones' that are popular in China, India and elsewhere. For example the Nokia Asha feature phone only has 240 pixels width. Andrewssi2 (talk) 12:34, 30 July 2015 (UTC)


Sumit.iitp has implemented a origin parameter. It allows you to define an important part of the image as a focal area. I've gone ahead and switched the London article to use the extension to show how this works. You'll notice on mobile that 1) you can see the banner and 2) the banner repositions and focuses on tower bridge when you shrink your screen.

{{PAGEBANNER:London Thames Sunset panorama - Feb 2008 banner.jpg|icon-dotm=Previous_Destinations_of_the_month|caption=London's burningː Tower Bridge at sunset.|disambig=yes|toc=yes|origin=-0.5,0}}

The origin parameter works by defining a vector from the center of the image. It uses this when needed based on the resolution.

Another great side effect of this is that if you want you do not need to use 7:1 images any more necessarily - see Caye Caulker as an example and note that the max-height can be tweaked on desktop browsers if necessary so it's less tall - those of you are tech savvy will notice what happens when you add the following css rule :)

        @media all and (max-width: 768px) {
                .wpb-topbanner {
                        max-height: 200px;

(This means you could avoid having to manually crop images... ) Jdlrobson (talk) 20:54, 19 August 2015 (UTC)

Caye Caulker looks good on an iPhone 6, but it takes up 30% of the top of my screen on my MacBook!
How do you propose this should look? --Andrewssi2 (talk) 22:35, 19 August 2015 (UTC)

Yup it still needs further work. With a smaller max-height it should stretch further and it wasn't the best example to showcase this - I was just keen to point out the potential here in case anyone wants to explore it some more. Out of interest what screen resolution is your macbook? Jdlrobson (talk) 05:40, 20 August 2015 (UTC)

2560 x 1600 Retina display (13 inch) Andrewssi2 (talk) 08:24, 20 August 2015 (UTC)
Yeh.. unfortunately the image chosen has a maximum resolution of 1024px so it can grow no bigger than that without stretching. What width do we advise for these banners? There was must be a minimum size we allow? I'll try to find a better example for demoing this point, in the mean time is it better to have no banner or a banner for Caye Caulker (it looks much better on my considerably smaller laptop screen :-)? ( Jdlrobson (talk) 16:01, 20 August 2015 (UTC)
This is a prescient point for me right now. The Retina display actually means images should be downloaded at an even higher resolution to look good
Our minimum width guideline is 1800px, with at least 2100px recommended. There are no guidelines on height, except the ratio must be 7:1 (width:height) which has worked fine for me on all devices. Andrewssi2 (talk) 23:01, 20 August 2015 (UTC)
Interesting. Would it make sense to enforce this? For example - if I try and save a page banner below 1800px should it renders with an error? It's worth noting on a retina display with a monitor size of 2000px a 2100px and a suitable high res image would result in a 4200px banner which could potentially be huge. We should probably define what is acceptable. As Wikivoyage gets more popular this could become an issue :-S Jdlrobson (talk) 01:07, 21 August 2015 (UTC)

Wikivoyage talk:Listings thread[edit]

Please give your opinion at Wikivoyage talk:Listings#Listings without addresses, concerning whether it's OK for people to post listings of language teachers or instruction without any location beyond one or two names of towns in the listing, or whether such listings should be deleted as touting. I feel that it's important to resolve this question, on which our policies seem ambiguous at best. Thanks a lot, everyone. Ikan Kekek (talk) 02:31, 26 July 2015 (UTC)

poimap2.php is 404?[edit]

Go to any random page, click the map icon at the upper-right corner and get sent to somewhere like ... which gives a fat HTTP 404 error. I'm seeing this on every page. K7L (talk) 23:03, 26 July 2015 (UTC)

Might have something to do with a new tile server in process? server address is different (not = Matroc (talk) 04:00, 27 July 2015 (UTC)
Looks like it is being corrected as my markers are now working correctly. - Matroc (talk) 04:10, 27 July 2015 (UTC)
The server address '' has failed due to problems in the files system. I have changed the address back to '//'. -- Joachim Mey2008 (talk) 04:11, 27 July 2015 (UTC)

What does a Healthy Community look like to you?[edit]

Community Health Cover art News portal.png

The Community Engagement department at the Wikimedia Foundation has launched a new learning campaign. The WMF wants to record community impressions about what makes a healthy online community. Share your views and/or create a drawing and take a chance to win a Wikimania 2016 scholarship! Join the WMF as we begin a conversation about Community Health. Contribute a drawing or answer the questions on the campaign's page.

Why get involved?[edit]

The world is changing. The way we relate to knowledge is transforming. As the next billion people come online, the Wikimedia movement is working to bring more users on the wiki projects. The way we interact and collaborate online are key to building sustainable projects. How accessible are Wikimedia projects to newcomers today? Are we helping each other learn?
Share your views on this matter that affects us all!
We invite everyone to take part in this learning campaign. Wikimedia Foundation will distribute one Wikimania Scholarship 2016 among those participants who are eligible.

More information[edit]

Happy editing!

MediaWiki message delivery (talk) 23:42, 31 July 2015 (UTC)

Creating an inter-language link seems not to work properly[edit]

Hi there, while preparing an article on the greek Mount Olympus in the german language WV, I wanted to check, whether the English branch has more information then me - it only had a stub article. So I thought it might be helpful to link to the german language article manually, as the mountain is simply called "Olymp", and an english speaking person might not know about this. So I tried to link from "Languages", everything looked fine until there was an automatic check for other languages (Wikidata repository) which I should conform, then I encountered an error message ("Error: $1. Details Attempted modification of the item failed", maybe you check this - so I cannot be helpful, kind regards from Switzerland Martin - Mboesch (talk) 20:12, 1 August 2015 (UTC)

@Mboesch: It looks like you want to link voy:Olympos_National_Park with voy:de:Olymp_(Nordflanke) by making the interwiki link at d:Q12876760, which I just did. —Justin (koavf)TCM 20:33, 1 August 2015 (UTC)
thank you, exactly how I hoped it would be, kind regards from Switzerland Martin - Mboesch (talk) 20:20, 12 August 2015 (UTC)

Idea: City status expedition[edit]

As may by now be known among some here, I recently upgraded the status of a whole bunch of district articles who were erroneously classified as outline. While probably some of those currently classified as usable are (or should be) in fact guides, the most pressing issue appears to have been resolved there. However, what about the tons of city articles? Some I assume might even end up on the vfd trash heap, while others should maybe be deleted simply for being verbatim copies of that other site. Regardless, there is currently a large number of city articles at outline and unlike country articles, it is rather easy to asses whether they merit a promotion to usable. However, this is a daunting task for the thousands of outline city articles currently in existence. I would be willing to do part of the work, but not all of it. Who would be willing to help?

To clarify: Initially there will be no (major) effort to work on the content of the articles per se just to more accurately assess them in order to make those articles that are truly problematic more evident and hence subsequent work easier.

Best wishes Hobbitschuster (talk) 17:37, 3 August 2015 (UTC)

Support. We sure do have a lot of outline city article that has the four things required for usable status. I run into them all the time (and correct them), for each article it takes perhaps three seconds. The problem is, as you said, that there are thousands and thousands of articles. ϒpsilon (talk) 18:10, 3 August 2015 (UTC)
Precisely. How many people do you think would be necessary for this to be worthwhile? Hobbitschuster (talk) 18:22, 3 August 2015 (UTC)
5-10? The more, the better of course. ϒpsilon (talk) 18:32, 3 August 2015 (UTC)
If an expedition is formed to methodically go through and update article statuses then I have no objection. However, I'm concerned about the statement that "Some I assume might even end up on the vfd trash heap, while others should maybe be deleted simply for being verbatim copies of that other site". See WV:Deletion policy for guidelines on when a deletion is appropriate - if a goal of this expedition is to delete articles, particularly if the articles wouldn't normally merit deletion under existing guidelines, that would be less straightforward and I think some specific proposals about what is going to happen would be useful before any expedition started making changes. -- Ryan • (talk) • 19:13, 3 August 2015 (UTC)
Any way to have a script find everything with (1) "See" or "Do" non-blank and (2) "Eat" non-blank and (3) "Sleep" non-blank and (4) article status "outlinecity" or "outlinepark"? It would cut down the number of articles which need to be checked manually by excluding ones which actually are empty, useless skeletons. It's possible that a page which has been a victim of a CVB attack could have plenty of text, but still not be useful as it's promotional copypasta and not formatted to Wikivoyage style. K7L (talk) 19:16, 3 August 2015 (UTC)

Finding empty or skeleton articles[edit]

My previous contribution seems to have been "swallowed" by a crashing browser / OS... any way... Here goes: Deletion or vfds are not the stated goal, but rather an undeniable and inevitable side-effect of looking through a large number of articles. Just like my looking through "districts" at outline status turned up some that were in fact not districts at all. If for example we find an article on a two house hamlet in the middle of nowhere with only one tout ever adding context to it and that back at the old place, I guess a deletion might have merit... Best wishes Hobbitschuster (talk) 19:22, 3 August 2015 (UTC)
As for a skeleton detecting bot... This might on the one hand be helpful in finding more pages that actually don't deserve their outline status. On the other hand some of the empty skeletons are doing no good for this page anyway. In some cases they might even be worse than a redlink. In other cases there may be better ways in which those places could be (or already are) handled. But his is a question for another time, maybe... Hobbitschuster (talk) 19:30, 3 August 2015 (UTC)
It's already settled consensus that we don't delete articles that fall within the parameters of policy just because they happen to be skeletons.
There was a single instance, a year or two ago when we were far deeper in the SEO hole than we are now, when we had a mass deletion of skeleton articles because at that time we were under the impression that we were legally required, per details of our legal settlement with IB, to include a hyperlink to WT in the attribution footer of each article. However: 1) we've since removed these footers from all our articles, thus neutralizing much of the SEO benefit of further deletions; 2) a significant portion of our community (self included) was opposed to the deletion, and, most importantly, 3) all deleted articles were (or were supposed to have been) recreated after deletion, which in my estimation is the final answer to the question of whether simply being a skeleton is a VfD-able offense for an article.
I'm not opposed to this expedition in principle (though I might note that in Wikivoyage these days, creating an Expedition around an idea seems to be one of the surest ways to make people lose interest in it). However, the thing to do with skeleton articles is for chrissakes just add a listing or two to "Buy", "See", "Eat", "Drink" or "Sleep". Aside from the obvious fact that adding more content is always beneficial to the end user of our site, it takes a minimal amount of time, and the shorter an article is the less effort is required to diverge it from its WT counterpart for SEO purposes.
-- AndreCarrotflower (talk) 19:45, 3 August 2015 (UTC)
The problem is that while being an empty skeleton is not a deletable offense per se, it might indicate that the article covers a place with little in the way to make it worth an article. Hence it is neither a sufficient nor a necessary condition for deletion but a good first hint. If you catch my drift... Hobbitschuster (talk) 19:52, 3 August 2015 (UTC)
An article that is about a place that isn't article-worthy should be redirected, not deleted - see Wikivoyage:Deletion policy#Deleting vs. redirecting. If a goal of this expedition is to identify articles that should be merged or redirected elsewhere that's fine, but if the goal is to generate VFD nominations for articles that wouldn't normally get deleted then I think there will be a lot of pushback. -- Ryan • (talk) • 20:09, 3 August 2015 (UTC)
So basically any article can be redirected without any sort of process beforehand? After all merge (even if there is nothing to merge) and redirect is a common outcome of the vfd process... Hobbitschuster (talk) 20:12, 3 August 2015 (UTC)
Except in obvious cases it's usually polite to start a talk page discussion prior to redirecting (see Wikivoyage:How to merge two pages#Discuss for a related topic). Most "merge and redirect" VFD results occur when the nominator failed to read WV:Deletion policy#Deleting vs. redirecting ("if it is a real place, redirect rather than delete"). -- Ryan • (talk) • 22:03, 3 August 2015 (UTC)

Finding promotable outline articles[edit]

It looks like there are two different questions here, (1) how to find articles marked "outlinecity" which meet the basic criteria (something to see or do, somewhere to eat, somewhere to sleep) for possible promotion to "usable" status vs. (2) how to find skeletons of an "'''X''' is in [[Y]] {{subst:smallcity}}" level of uselessness for merging to valid destinations or nomination for deletion. These are two entirely separate questions. The suggestion that a script could find and list (but not automatically promote) pages where the sections are filled out but the status is still "outline" was intended to address (1). K7L (talk) 20:23, 3 August 2015 (UTC)

It may be a good solution for issue (1), but I don't know whether a bot does in fact justify the effort needed for its creation... Hobbitschuster (talk) 20:31, 3 August 2015 (UTC)
You do realise that we currently have 13714 outlinecities? K7L (talk) 21:06, 3 August 2015 (UTC)
Well I have not the slightest idea how much effort such a bot would take to write. Did I mention on occasion that I am not that good with computers? Hobbitschuster (talk) 21:09, 3 August 2015 (UTC)
There are actually less than 2000 articles that have the correct listing that could be moved from outline to usable, but enough for a little project click here then press Do It at the bottom of the page. --Traveler100 (talk) 03:25, 4 August 2015 (UTC)
Interesting. If the criteria are "something to see or do, somewhere to eat and somewhere to sleep" that would be this (2250 towns and cities) and this (26 parks). It might be possible to narrow this a bit by excluding pages with {{cleanup}}, {{vfd}} or other issues from the list of promotion candidates. It looks like some of what this finds is promotable, some is badly formatted (listings in wrong sections, touting, other issues which need fixing first) and some pages were demoted or held back due to issues which had since been fixed. K7L (talk) 04:10, 4 August 2015 (UTC)
Note that the article also needs to have some information on getting in to be usable. ϒpsilon (talk) 04:38, 4 August 2015 (UTC)
True, and if you want to do a proper job I suggest doing this: User:Traveler100/outlinetousable#What this involves. --Traveler100 (talk) 04:46, 4 August 2015 (UTC)
While efforts to improve our many outline articles are great, I think we should not start focussing on articles that just meet the technical criteria and promoting them to usable. While we might call an article usable with 3 or 4 listings and a mention of the main road, almost all readers will find it completely lacking and will go to another site with more information. In the end, it's all about content and cleanup, because the status change itself has no real effect on readers. I'd suggest determining a workable sub-group, say the 500 best developed outlines. When singling out the best and easiest outline articles to improve (so not half-empty), including a minimum article size in the search might be helpful. Having a banner also helps a lot for the "look" of the article. Perhaps this effort can join forces with some of our banner creators? Lastly, expeditions are rarely successful for this kind of thing, especially when the task is so huge. This might perhaps be a better candidate for a collaboration of the month, if we can narrow the number far down? JuliasTravels (talk) 09:31, 4 August 2015 (UTC)
While those are good ideas User:JuliasTravels, I would like to explicitly focus on the more mundane task of getting stuff into the right category. The bar for "usable" is low by design so that it does not take all that much effort to get an article up to said status. We are not trying to promote anything to guide here. This might be the next step, but I think this is rather done on a country by country or region by region basis as it requires some actual real knowledge of the places rather than technical knowledge of how listings should look like and what information is needed for getting in eating and sleeping. As I have seen with our district articles, approximately half of our current outlines need not be outlines if we apply our own criteria. This is both frustrating for our editing purposes and hindering for people wishing to do upkeep and maintenance tasks. If there is an article tagged as a stub, I know immediately that it has big problems. Outlines may range in quality widely. The end goal should be a list of outline articles that are unusable by any definition of the term and on which further efforts of any kind can more efficiently be focused. Maybe through an "adopt a outline" program or simply through upgrading the "Random Article" tool to filter by status, so that you can find a random outline. If you want, you can of course first look through our usable cities and see whether some of those deserve demotion. Right now this would be a task doable by one or two people with time on their hand. Once we sifted through all outline cities, this will be much harder. Hobbitschuster (talk) 10:56, 4 August 2015 (UTC)
There are obviously no objections to systematically reviewing and updating the status of outlines within policy. While your suggestion would put articles in the "right" status-category, I'm just not entirely sure how it helps maintenance, or why outline articles with usable content are a hindrance. Anyway, it's perfectly fine to sift through them. If you're looking to get people involved in a time-consuming project however, it helps if there's a clear vision of the actual benefit for the site, for readers or SEO. I'm just worried that AndreCarrotflower is right in his somewhat pessimistic view of expeditions, hence my suggestion to come up with clear and feasible boundaries. It was just a suggestion though :) JuliasTravels (talk) 13:52, 4 August 2015 (UTC)
If before upgrading from outline to usable the listings were checked and enhanced I believe that would be beneficial. Removing old listings, fixing bad links and adding addresses and coordinates would not just benefit the reader but also improve the search engine ranking of the page. --Traveler100 (talk) 15:16, 4 August 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I think the janitorial work that promoting the articles mostly boils down to is extremely important as it allows to more accurately assess the quality (and quantity) of our coverage and where we are lacking. Right now the status designation "outline" means "nobody bothered to upgrade yet" more often than not. And checking the listings (besides things that a bot could do) would be rather hard to do in cases of listings without websites. Of course touting may be discovered as a (positive) side effect as well.... Hobbitschuster (talk) 14:15, 5 August 2015 (UTC)

When I upgrade from outline to usable I will click on all the links to check they are still active and correct where necessary. For the other listings a quick check on google maps generally shows the attraction/hotel/restaurant and will be labelled as "closed" (as apposed to "closed today") if no longer exists. Then maybe quick search on Yahoo if not found by Google. As a final check if that is inconclusive I go to Yelp and TripAdvisor and if I find the reviews are older than 3 or 4 years with nothing newer I assume closed and remove the listing. --Traveler100 (talk) 15:34, 5 August 2015 (UTC)
The usual signs of a "closed" business: main website dead or cybersquatted, a once-active timeline on Facebook/Twitter and the like has no new updates for years, a web search for "(company name) closed" finds local news of a bankruptcy or the business marked closed on some other site (like Yelp), a telephone call gets a recorded intercept error or somebody's private residence (a one-minute test call on VoIP is a penny or two to most developed nations). Usually a venue won't go out of its way to announce its closure (unlike the hype when it opened) but anything that has to be renewed monthly or annually (such as phones, web domains or paid directory adverts) quietly stops getting renewed. Some other company might pop up at the same physical address, but that's hard to spot as one doesn't always know who had that place first. K7L (talk) 15:23, 11 August 2015 (UTC)

So where are we?[edit]

Will there be any type of collaboration and what will it look like? Maybe we can make it the cooperation of the month September as I gather more people will have time by than... Hobbitschuster (talk) 15:11, 11 August 2015 (UTC)

The main goal is to do this for appropriate articles, right? Looking at the lists above, and considering how many (tens of thousands) of pages I've rated at the English Wikipedia over the years, I have these suggestions:
  • "Just do it" for the list of 46 parks. It's a short list, and one person could easily do it. Even if you spent a significant amount of time checking every link, etc., it's probably less than one full day's work for an experienced contributor.
  • The list of 2250 cities should probably be processed twice:
    • The first step is little more than a cursory glance, for the purpose changing the "obviously wrong" labels. That will probably require about 40 hours of work. In terms of collaboration, if we could get four people to work on it, then we can have one start at "A" and work down, one start at "M" and work up, the third start at "M" and work down, and the last start at "Z" and work up. Stop when you seem to have encountered pages that the next person checked.
      This is a pretty quick, high-reward process. It should take about one minute per page: Open page, check four sections, see if it obviously meets or exceeds the bare minimum, and change the tag. Move on to the next one. It's a bit repetitive but it's not hard. However, that quick, easy look is the most important step in terms of getting things rated correctly overall. You'll get more value out of fixing ratings on the obvious cases than in waffling (or arguing) over how to classify the borderline cases.
    • Weeding out the "obviously wrong" classifications will reduce the workload for people who are willing to be more thorough. They'll benefit from having a list that is more focused on the ones that require attention. This should be done after the first, quick pass has completed.
Also, in response to a comment above: correct ratings encourage contributors. I've done a lot of article assessment work, and when things are assessed lower than the author expected, then they often feel discouraged. For some contributors, a "good" rating is taken as a sign of appreciation and approval. It's worth spending a little bit of time on this, even if it weren't seen by non-editing readers. WhatamIdoing (talk) 19:46, 17 August 2015 (UTC)
I like your idea, and as a matter of fact at first my intention was nothing but the "first round". Which as you rightly point out, should be a cooperative effort for the city category at least Hobbitschuster (talk) 19:50, 17 August 2015 (UTC)
I'm doing the handful of cities that are outside of the "A to Z" list. Široki Brijeg looks borderline to me (lots of places, but almost no addresses or other contact information), but the others look like they can all be promoted to usable. WhatamIdoing (talk) 19:52, 17 August 2015 (UTC)

Proposal for a new Go listing type at Wikivoyage talk:Listings[edit]

I've proposed the approval of Template:Go over at Wikivoyage talk:Listings for use in the Get in and Get around sections of our guides. This change could potentially affect thousands of articles, so am seeking wider opinion. Would appreciate your thoughts and comments there. Regards, James Atalk 12:12, 4 August 2015 (UTC)

Travel Stack Exchange[edit]

Any Stack Exchange users here?

When I write Wikivoyage articles, I often get difficult-to-answer questions such as Is there a train from Antananarivo to Antsirabe? or Where is the night market in Ayutthaya? for which Google has no obvious answer.

Whenever I have such a question, I post it at and I am always surprised at the quality of the answers.

When I post a question or answer, I link place names to the relevant articles on Wikivoyage, I believe this is good for SEO, so I invite you to do the same.

Also, I created "community ads" that get displayed on that website's front page. While the Wikivoyage ad has been highly upvoted already, the new Wikivoyage Offline ad needs your upvotes before it gets shown on the front page, thanks! (only users with some Stack Exchange reputation can vote) Syced (talk) 07:44, 5 August 2015 (UTC)

52 suggested new alternative banners - please participate in the following discussions and help decide whether some existing banners would be replaced or not[edit]

Over the last years I have created 52 new alternative Wikivoyage banners (mostly based on existing photos in Wikicommons) to be used, first and foremost, in the articles of the Hebrew Wikivoyage.

I am hoping that the English Wikivoyage community would consider using some of these alternative banners here as well.

Please participate in the following 52 discussions and indicate in each of the discussions which banner you prefer seeing at the top of this article.

ויקיג'אנקי (talk) 13:50, 11 August 2015 (UTC)

Thanks for your work! Hobbitschuster (talk) 15:12, 11 August 2015 (UTC)
I just cast my vote on all of them. Nice work ויקיג'אנקי! :-) Syced (talk) 08:16, 13 August 2015 (UTC)

Wikivoyage offline: Now possible on iOS too![edit]

You want to bring Wikivoyage with you everywhere, but you are stuck with an iPhone?

An iOS version of Kiwix has just been released! Install it, select the Wikivoyage file for download, and you will be able to enjoy Wikivoyage anywhere, even when swimming through the Waitomo glowworm caves or exploring the underground Imperial Palace in Nagano!

(The Android app is of course still available:

Cheers! Syced (talk) 06:02, 12 August 2015 (UTC)

Great! (Although I won't take my iPhone swimming)
Is there also an iPad specific version? That would be of even greater use. --Andrewssi2 (talk) 09:34, 12 August 2015 (UTC)
I've got a Windows Phone, but won't hold my breath for it anytime soon! James Atalk 09:41, 12 August 2015 (UTC)
I used to have a Windows Phone. The Kiwix web site claims it isn't hard to compile the source for any OS, so maybe someone could give it a go... --Andrewssi2 (talk) 09:45, 12 August 2015 (UTC)
Would this be worth adding to packing list, alongside the (brief) mention of the various OpenStreetMap apps? Admittedly I'm a wee bit partial to Android as their devices usually provide a microSD slot for a memory card to hold this stuff, but... K7L (talk) 14:14, 12 August 2015 (UTC)
I would be all for mentioning, I seriously think it has greatly improved my travelling experience, as well as reduced my costs and backpack weight. The article says "Printing off pages from Wikivoyage makes for a lightweight reference" and then talks about what can be loaded on electronic devices, so I think a sentence about Wikivoyage Offline (and links for Android/iOS) would be appropriate. Any opposition? Syced (talk) 08:40, 13 August 2015 (UTC)

A crazy idea/suggestion which might actually help us substantially increase the amount of banners created on a regular basis - by having Wikivoyage Chat Room Banner Creation Parties![edit]

Each time I end up suggesting that the English Wikivoyage community would consider using some of the alternative banners I have created for the Hebrew Wikivoyage (this usually happens only once a year) I am also approached by some users whom tell me they think I should put a higher priority on creating banners for the 15,000 + articles without banners, instead of creating alternative banners to prominent articles with banners which I did not like visually.

For a long while I have been the sole active editor in the Hebrew edition of the Hebrew Wikivoyage, and therefore I tend to focus on many various important tasks, and not just on producing banners. Although there is a big demand for new banners I have also learned to accept that my abilities are limited - it takes me usually around 20 to 30 minutes minimum to create each new banner, and most of the time is usually spent on searching for good panoramic source images with commercial use + mods allowed license (necessary to create derivative works I can upload to Wikicommons) which I then edit in Photoshop, and upload to wikicommons (I actually prefer looking for source images first on Flickr as they have a wider selection than Commons, and because their search engine helps me find good pictures faster). I estimate that every year I end up making maximum only around 100-200 banners, and those are usually only banners which I thought would look well visually (I never produce banners which I do not like visually, just for the purpose of having one less article without a banner but with an ugly banner).

I feel that we have a significant problem - there are still A LOT of banners left to create, and there simply aren't enough people focusing their time on the creation of the 15,000 plus remaining banners. The few "experts" whom do create banners for Wikivoyage articles, can only create so many by themselves, and usually end up not devoting most of their time here to creation of banners as the banner creation process tends to be a long and somewhat exhausting process (just to illustrate the substantial amount of work that is left - if it takes around 30 minutes on average to create a decent banner from a good source image on flickr/commons * 15,000 banners = 7,500 hours of continuous work in total = 312.5 days of continuous work in total). In my opinion it is definitely doable, but we'll still need a lot more people involved in this process (even if you are not Photoshop experts) for us to be able to create most of the missing banners within the next few years.

Yesterday, after the user Andrewssi2 approached me about the need to focus on creating banners for the 15,000 plus articles with no banners at all, I had a crazy idea on how we might be more efficient in creating a more substantial amount of banners over time... by scheduling weekly or monthly Wikivoyage Chat Room Banner Creation Parties.

for this to work, we'll need to have a least 10-20 people taking part in this collaborative effort, coordinated through a chat room, at a specific day + time which works out for everybody involved. From all the participants, around 20-30 percent would have to be Photoshop experts.

Before each collaborative effort takes place, the group would compile a list of 100-200 prominent articles without banners and that list would be the main focus of the group during the actual scheduled collaborative effort. During each scheduled collaborative effort, all the participants whom ARE NOT Photoshop experts, would mainly be focused on searching flickr and commons for good panoramic source photos to create decent banners from - when someone finds a good panoramic source photo, they would send the link to one of the Photoshop experts, whom would be fully devoted to using those photos to create the banners + uploading their work to commons (and making sure to fill in all the necessary text of each banner file license). I believe that if we'll have enough people whom are willing to work together in this way, we'll be able to substantially increase the amount of banners created on a regular basis, and get closer much sooner to creating all of the missing 15,000 plus banners.

What do you think? ויקיג'אנקי (talk) 14:02, 12 August 2015 (UTC)


I like the idea, but I fear that this will soon fizzle out like most attempts at organized collaborations have in the past...Hobbitschuster (talk) 17:02, 12 August 2015 (UTC)
It will not "fizzle out" if enough people would sign up for it and make an effort to take part in it. ויקיג'אנקי (talk) 17:19, 12 August 2015 (UTC)
Various Wikivoyage users I recently noticed that expressed a somewhat interest in banner creation, and/or are are experts in Photoshop, include - user:Hobbitschuster, user:Ikan Kekek, user:Traveler100, user:PrinceGloria, user:Andrewssi2, user:JamesA, user:ThunderingTyphoons!, user:Danapit, user:Nicholasjf21, user:AndreCarrotflower, user:Othello95, user:AlasdairW - Please specify in this discussion section what you think about the general idea/suggestion (maybe you have ideas or how to improve this idea of mine?), and/or consider adding your name in this list below.

Would be cool, I hope enough people can participate :-) How can we attract people to join this effort, for instance people who don't hang out here? Syced (talk) 17:21, 12 August 2015 (UTC)

I am no Photoshop expert and have never made a banner, just FYI. Of course that doesn't prevent me from discussing the merits of banners as compositions, but that's another matter. Ikan Kekek (talk) 23:00, 12 August 2015 (UTC)
I'm a bit concerned about all this talk of 'photoshop experts'. I wouldn't describe myself as one, but I know enough to produce banners that are at least to the required specification.
The reality is all you need is Microsoft Paint to create a perfectly good banner. I personally use Gimp because it is free and more powerful. We should stop talking about expert technical skills to perform what is a straightforward task. --Andrewssi2 (talk) 23:43, 12 August 2015 (UTC)
I admit to sometimes going on banner binges, but they come at whims, especially when I feel like Wikivoyaging but cannot get myself down to contribute actual content. And I am OK with working on my own, though input is obviously always appreciated. That said, I think we're pretty well covered when it comes to banners. I'd rather the community effort went towards e.g. upcoming featured articles which often could do with a brush-up, as well as popular destinations who have been slightly neglected for some time. Another great effort would be to help brush up neglected regions of countries like Germany, which was actually underway until the initial enthusiasm gave way to vacations :D PrinceGloria (talk) 19:42, 12 August 2015 (UTC)
Maybe we should call a general moratorium for new community initiatives during the Northern Hemisphere summer? :-P Hobbitschuster (talk) 19:47, 12 August 2015 (UTC)
While making banners is my passion here at WV and I possess skills necessary for their editing, plus I enjoy collaborating with others, I cannot promis I will be available for any kind of scheduled event. I don't know if it is at all possible to organize such a party accross time zones. Anyway, I often escape for contributing on WV just for a couple of minutes when I should be doing other things anyway, so scheduling won't work for me. Danapit (talk) 20:19, 12 August 2015 (UTC)
I also see time zone difficulties, and although I have made a few banners for "random" places, most have been for places that I know a little about (I have been to the same country etc.), and I find it is most fun to create a banner using my own photos (but I do mainly use ones from commons). AlasdairW (talk) 22:06, 12 August 2015 (UTC)
  • ויקיג'אנקי - I admire your enthusiasm, but honestly I think you're overthinking this whole banner thing.
The culture of this community has evolved in such a way that the development of English Wikivoyage tends to be slow, gradual, and somewhat piecemeal. I've spoken before about how, with a few exceptions, Expeditions almost invariably die as soon as they're hatched, and the same is going to be true of things like "Chat Room Banner Creation Parties", the banner suggestion lists from a little while ago, etc. For whatever reason, big, splashy initiatives turn us off. Maybe because we're a wiki that's small but has an extraordinarily dedicated group of regular editors, and we'd rather feel satisfied watching the progress we each make individually on whatever we happen to be working on, than feel pessimistic about the future of our site by watching yet another big complicated effort go belly-up due to lack of interest.
You're one of our most prolific banner creators, ויקיג'אנקי, which is a good thing. But here's a few words of friendly advice. Whoever told you it's more important to create new banners for destinations that don't have any yet is absolutely right, but more to the point, it doesn't have to be as long and tedious a process as you seem to think it does. If you want to make a new banner for a destination that doesn't already have one, just put it on the article. 99.9% of the time, the community will be more inclined to be grateful for your contribution than to nitpick over whether there might be a nicer banner image out there somewhere. Meanwhile, if you want to make a new banner for a destination that does already have its own banner, just post a message on the article's talk page saying so and linking to the new image. Most of the time no one will care either way, so if you don't get a response within a few days go ahead and put up the new banner; if you do get a response, then you can start worrying about building consensus and feeling out community opinion and all that jazz. And if you make a whole slew of new banners all in a row and you want to hear what the community thinks about them, go ahead and write about in in the Pub and you're likely to get a short burst of feedback, but please disabuse yourself of the idea that it's going to spark a long-lasting interest in banner-making among the community. In general, whether it's by you or someone else, the banners will get made when they get made.
-- AndreCarrotflower (talk) 21:42, 12 August 2015 (UTC)
I'm pretty much where Danapit is here :) I can't schedule anything.
I would also say that the absence of 15,000 banners (or better stated, 66% of English Wikivoyage articles) isn't a major issue as such. My own approach to South Korea is to list all the pages without banners (URL currently down) and pick them off by order of page size. I'm not in a hurry and will hopefully finish off the country this year, but it is more important to choose a banner with care than just crank out as many as I possibly can.
In terms of the banner creation party.. well I would say if you want to try it then more power to you! Even just two people working in tandem would be quite productive. AndreCarrotflower is however right to caution the level of enthusiasm for initiatives such as this. Andrewssi2 (talk) 23:09, 12 August 2015 (UTC)
Also in terms of the delimitation of responsibilities, you may find many pictures are chosen which don't work. For example I sometimes find a great picture that I think should make a good banner, but after the 7:1 magic treatment doesn't look very good at all. --Andrewssi2 (talk) 04:44, 13 August 2015 (UTC)

Without a joint effort to create a big portion of the missing 15,000 banners, we have no chance of getting those created before the 2010s are over (in this pace, it they might not be created before the 2020s are over either). I need more volunteers to make this happen. Even if you don't know anything about Photoshop, please join this effort! ויקיג'אנקי (talk) 23:20, 12 August 2015 (UTC)

Users interested in participating in a such an effort[edit]

Are there any users whom would be willing to take part in such an effort? if so, please indicate that in the list below:

Photoshop experts
People whom would focus only on finding good source photos on Flicker and/or Wikicommons

Banners extension deployment[edit]

Dear all,

Sumit's banners extension is being deployed right now to the English Wikivoyage :-)

Please let us know immediately if you notice any problem.

Cheers! Syced (talk) 16:09, 12 August 2015 (UTC)

Great, thanks a lot. What else needs to be done here?
  • Rewrite the expedition accordingly (I can contribute here)
  • Write and run a bot to redo pagebanner --> PAGEBANNER (volunteers?)
  • Correct some automatic categories and counters (precise specification and volunteers?)
  • Prepare a specification for a bot request for pagebanners to wikidata transfer (I will try to start with that)
  • ...

Danapit (talk) 17:22, 12 August 2015 (UTC)

There was an unrelated urgent security patch that took all of the admins' time, so our timeslot has passed :-/ Deployment is being re-scheduled to probably tomorrow or Monday. Syced (talk) 17:25, 12 August 2015 (UTC)
PLEASE don't run a bot to replace the template when this goes live. As I understood things we should be able to just update Template:Pagebanner directly, but I haven't looked closely at the extension in a while. -- Ryan • (talk) • 21:57, 12 August 2015 (UTC)
What is the plan when this goes live? Just to try on a few select articles? Andrewssi2 (talk) 22:54, 12 August 2015 (UTC)
The plan is to first do nothing, then test with just a few test articles. So nothing should change. Deployment has beeen rescheduled to today (9.30am pst) Cheers! Syced (talk) 08:44, 13 August 2015 (UTC)
Hi, as Ryan pointed out, no bots are needed for migration to new extension. Simply modifying Template:Pagebanner on this wiki to call the extension with required parameters will do the job. I've created a helper template here which allows use of new extension without modifying individual pages of the wiki. An example page using that template is this - You will notice that the syntax of the Canada page has not changed and yet it uses the extension to show banner.
ThankYou! --Sumit.iitp (talk) 13:19, 13 August 2015 (UTC)

Second attempt today! As WMF's Jon says, this is the "first extension to launch on Wikivoyage first" which is quite historic and shows that Wikivoyage can bring useful innovation to all of Wikimedia and Mediawiki :-) The deployment is slowly taking place right now as I type! 16:54, 13 August 2015 (UTC)

After a first seconds of "[8c7c9fc4] 2015-08-13 16:52:30: Fatal exception of type MWException" and "Error: invalid magic word PAGEBANNER" fixed by a scap, it is taking a bit more time... Syced (talk) 17:02, 13 August 2015 (UTC)
The extension is deployed, and Wikivoyage does not seem to have any problem with it :-) If you notice anything strange, please let us know! Also, better keep our tests to a few well-defined test pages at first, thanks! :-) We use this article for tests: Red Wharf Bay, see it in all of its mobile glory here: Notice how the banner is a lighter file and the menu shows differently from the main site. Thanks Sumit for the code and everyone for your support! Syced (talk) 17:56, 13 August 2015 (UTC)
That's cool :) The drop down menu actually works like magic when you add subsections! Amazing stuff, thanks. Danapit (talk) 18:41, 13 August 2015 (UTC)
Look forward to experimenting with this later, thanks! Andrewssi2 (talk) 23:41, 13 August 2015 (UTC)
Looks good, thanks for putting this together. I tested it out in a couple of places. A couple of things I noticed are:
  1. It doesn't seem to pull banners from Wikidata. So for Halifax Region, I get the default banner[5] instead of the banner in Wikidata.
  2. It doesn't pick up on the badges or caption in the template. See Vancouver (current) and with extension [6].
For using badges please see this the documentation at You will have to use icons=star,unesco,otbp. You will also have to copy the lines here to Mediawiki:Common.css. I have put an example Red_Wharf_Bay. Once Common.css is updated, the icons will show up. Note that this syntax will change slightly in near future and I'll notify of the change.
Caption parameter is tooltip.--Sumit.iitp (talk) 15:49, 14 August 2015 (UTC)
  1. The extension seems to require "toc=yes" to activate the TOC in the banner, which is new compared to the existing template. Is it possible to add this to the template without requiring an update of every page with a banner? (I'm assuming so, but wanted to ask)
Yes, on using {{PAGEBANNER...}} separately on a page would require toc=yes. However, above in this same thread I've explained how to integrate the extension in the existing {{pagebanner}} template which would not require an explicit use of toc=yes. They would automatically be enabled on all pages using the modified template. Same applied for parameter tooltip which would take the value from caption parameter.--Sumit.iitp (talk) 15:49, 14 August 2015 (UTC)
I didn't follow development closely, so I'm not sure if this is what the launch version is supposed to look like or not. It looks good though, it loads faster on my machine and it's nice to be able to see multiple layers of subheadings! -Shaundd (talk) 04:41, 14 August 2015 (UTC)
Hi Shaundd, thanks for the feedback! Wikidata is not enabled yet, we will do it next week. Not sure about point 2 and 3, let's ask Sumit. Cheers! Syced (talk) 05:49, 14 August 2015 (UTC)

Great extension. Will love to use it on Commons. Pyb (talk) 21:58, 17 August 2015 (UTC)

it would be great to see this extension on other projects. If you are serious about it we could explore seeing if the community is interested in enabling it in some form - either on user pages / certain namespace pages if not article / file pages. Let me know if I can help in any way. Jdlrobson (talk) 20:35, 19 August 2015 (UTC).

Some updates to the WikidataPageBanner extension went out today. What's the status of switching the {{pagebanner}} template to use it? Kaldari (talk) 22:19, 19 August 2015 (UTC) Tracked in Jdlrobson (talk) 23:32, 19 August 2015 (UTC)

Alternative Satellite photo banners for continents + large regions instead of panoramic photos of specific cities/sites ?[edit]

For a while it has been bugging me that the Hebrew Wikivoyage articles have panoramic photo of specific cities/sites in the banners of continents or large regions (for example, there was a banner of Jerusalem in the top of the Middle East article). Because of this, yesterday I replaced all the continents banners (+ the banner of the Middle East article) of the Hebrew Wikivoyage with the following banners:

I am currently considering creating more banners like these for other large regions.

Would the English Wikivoyage community consider using these alternative banners here as well ? ויקיג'אנקי (talk) 19:53, 12 August 2015 (UTC)

I agree that a panorama of a specific city is not ideal, but unfortunately the new banners look too similar to our regional default banners. I like the banners that we have for Europe and Oceania, which show more of a typical detail for the continent. AlasdairW (talk) 20:46, 12 August 2015 (UTC)
Banners are supposed to be beautiful and interesting. A satellite image will never be anything but dull. Sorry, I think this is a nonstarter. -- AndreCarrotflower (talk) 21:48, 12 August 2015 (UTC)
Interesting idea, but can't say the result of the satellite images looks compelling. Andrewssi2 (talk) 22:55, 12 August 2015 (UTC)
Any ideas on how to make it look more compelling yet not have a photo of a specific site ? maybe making each of those banners have a collage of various photos that are highly representative of each region ? Any other ideas ? ויקיג'אנקי (talk) 23:24, 12 August 2015 (UTC)
The community has been very against collages/montages in the past. That said I do see the disconnect of the Asia banner showing the India wilderness, with the implication that represents everywhere from Jerusalem to Tokyo. --Andrewssi2 (talk) 04:41, 13 August 2015 (UTC)

Geo URI's on Web version[edit]

The offline Kiwix is great. The geo URI's work well with offline maps.

Could we also have geo URI's on the webpage? Maybe not by default since not all user agents can handle it, but there could be a link to an offline version of the page with geo URI's.

My motivation is that before I travel somewhere, I update Wikivoyage and Openstreetmap with things I might find useful when I get there. But usually I am too late for my updates to be in the Kiwix and Osmand updates. So I save the destination page from the browser. Which works, except it is difficult to use the POI locations -- I could copy paste them into Osmand or maybe find the street address in Osmand. But if I could save a WV webpage with geo URI's I would be happy.

Maybe my use case is not that common, but I think it is important because it encourage contributions to WV instead of e.g. just creating personal favorites in Osmand --Elgaard (talk) 00:21, 13 August 2015 (UTC)

Alternatively, you can download all POIs as GPX file (maximum of 25 articles grouped together) [7]. You can import this file into OsmAnd. All search and routing functions are possible with this GPX data. - Joachim Mey2008 (talk) 05:16, 13 August 2015 (UTC)
I have exactly the same use case. I also use the trick mentioned by Joachim, but indeed I support showing geo URIs if the browser is a mobile browser. Do templates have the ability to know whether it is a mobile browser or not? Syced (talk) 08:47, 13 August 2015 (UTC)

Adding a "Do" topic without specific information[edit]

I would want to add a "Do" topic to Pörtschach saying "Go swimming in the Wörthersee", because that's what I did when I last was there, and found it to be very pleasant. However, Wikivoyage presents me with a template asking me to fill in contact information including official websites and e-mail addresses, as well as opening times and prices. Lakes don't have these. Here in Finland, lakes are open for everyone to enjoy without charge, but I found out that in Pörtschach, the Wörthersee is so crowded that you can only go there if you have a reservation at a hotel. Provided this, the lake is open for your pleasure, as long as you don't venture to some other private property. How would I add this to the article? JIP (talk) 20:27, 13 August 2015 (UTC)

JIP, you don't need to use the listing template, if this is what you mean. I'd simply add a bullet point saying: * Go swimming in the Wörthersee and describe what you just described above with the hotel reservation. Alternatively, if you can provide coordinates of some good beach or bay, use template marker: Go swimming in the {{marker |type=do|name=Wörthersee|lat=xx |long=yy }}. Does this solve your problem? Danapit (talk) 20:37, 13 August 2015 (UTC)
A quick Google yields at least a URL link to an official tourist page for the lake. That could be used in a 'Do' listing. Also I'd want to know how to get to the lake, which the template also provides for. --Andrewssi2 (talk) 23:38, 13 August 2015 (UTC)
You don't have to fill all parameters. The template also gives you an "image=" field which can be useful to show what the beach/surroundings look like. Some people will probably find your swimming suggestion from the dynamic map (or a mashup of the same information) when they happen to be near the lake. A non-template bullet description would not appear in such mashups. Cheers! Syced (talk) 05:52, 14 August 2015 (UTC)
Following on from what Syced said, feel free to not fill in all the fields. You might like to just make 'Lake Wörthersee' the name, add the location, official tourism website and then a description, including info about swimming and other activities. Although it's up to you what you think's best :) James Atalk 07:31, 14 August 2015 (UTC)

VisualEditor News #4—2015[edit]

Elitre (WMF), 22:28, 14 August 2015 (UTC)

No references?[edit]

Could anyone tell me why there is no "References" section in Wikivoyage articles? Without that, there's no way to verify the correctness of articles here. Na Tra (talk) 04:46, 15 August 2015 (UTC)

Because much of the content is based on original research - the experiences of travelers and residents of places around the world. Why would you want references for that? Ikan Kekek (talk) 05:11, 15 August 2015 (UTC)
Wikivoyage is a travel guide not an encyclopedia like Wikipedia. Unlike Wikipedia original work is allowed and thus does not require a referenceable source. Yes there is a risk that something is not correct, but it is encouraged that contributors and editors add URLs to primary sites to a listing were possible. The thing is that some points of interest may not have another source of information. Any dubious information will be discussed on the article or user talk page and edited appropriately. --Traveler100 (talk) 05:18, 15 August 2015 (UTC)
OK I see. Original research, so references are impossible. But it's still so dangerous. It's just so easy to make up something and no one's gonna be able to find it. Do you have any ideas to prevent this from happening instead of using references? 14:02, 17 August 2015 (UTC)
Although it would be very unfortunate if a traveller would be searching for something that doesn't exist, he/she will hopefully fix such an error afterwards. Fortunately, however, this is more an issue in theory than it is in practice, so far. While original research is permitted, most listings for hotels, restaurants etc come with phone numbers and weblinks to their official sites. Lots of other information is verifiable online. And let's be fair: if someone would really want to be malicious by providing false information, it's easy enough to create an accompanying reference; so it wouldn't be any guarantee anyway :-)
As Traveler100 said: if there's doubt about the correctness of information, it will be discussed and mentioned in the article. Did you have any specific doubts? JuliasTravels (talk) 14:20, 17 August 2015 (UTC)
Well there may well be factual inaccuracies in some "understand" section or other, but as our focus is travel, they are not all that important in the great scheme of things. It gets worse if their are factual inaccuracies in travel topics (though as they are usually written by more than one person with knowledge on the subject these things get corrected quite quickly) and it would be even worse if there were factual errors in hotel or restaurant listings.... Which is why we provide ample contact detail, including the official website of said establishment to check. You see, our focus and our linking to primary information combat what you perceive as an oversight in our lack of citations. Thus far this has served us (and I daresay our readers) well, as probably nobody who reads a travel guide has nerve to comb through dozens of footnotes... And we do in some cases provide links to back up claims on the talk page or in <!--comment tags--> best wishes Hobbitschuster (talk) 14:21, 17 August 2015 (UTC)
And sometimes we send voyagers on a lengthy journey to South Detroit on the midnight train to anywhere. Don't stop believing... That said, the usual issues are listings for something that once did exist (Merrickville lost its hotel to the Great Recession, Cartwright (Labrador)'s hotel burned to the ground) or the owner of an establishment posts a deliberately one-sided laudatory listing for some rubbish dump. Citing references won't prevent listings for defunct venues; a list of sources might be useful for "Understand" or similar descriptive background text, but they're usually buried on the talk page, in edit summaries or document comments as the idea is for the voyager to print off (or carry on a microSD card) a copy of a destination guide for use off-line, on the road, from points where they don't have the ability to access additional information from cited external sources. As a Wikipedian, yes, it is counter-intuitive; we link {{listing}}s to the venue's own official site (which is usually highly promotional) but not to neutral, objective external sources. K7L (talk) 15:38, 17 August 2015 (UTC)
I don't know whether it still appears on any of our official policy pages, but at some point we had the easy to remember sentence "If you find yourself wishing to provide a source for your statement, it probably doesn't belong here anyhow", or something to that extent. Our be fair policy for example skirts most issues that would commonly result in tons of refs being necessary over at WP. Hobbitschuster (talk) 15:57, 17 August 2015 (UTC)

Thanks all of you guys for your comprehensive explanations! Beside no references, I have too the same worries like K7L about listings for something that no longer exists. Should we build a bot to mark listings that were last updated since a specified time with a small warning, like warning: last updated more than xxx months ago and add them to a category like "Outdated listings"? That would help the readers as well as the writers. Na Tra (talk) 17:10, 17 August 2015 (UTC)

Oh. Template:Listing has already a parameter for that purpose: lastedit. Unfortunately I rarely see it used in articles here. It would be nice to have the job done by a bot, highlight the old ones with red, then add all of them to a category. Na Tra (talk) 17:27, 17 August 2015 (UTC)
If you look at an article with recently updated listings (let's say Hof for a random example) you will notice a small "last updated" behind the word "edit" (or was it before it?). If you edit said listing, you can check the box "verified information up to date" and it gets automatically reset to the date you edit if you do so Hobbitschuster (talk) 17:24, 17 August 2015 (UTC)
I've just tried to edit a listing in Hof and the date automaticall updates. Impressive :) Na Tra (talk) 17:38, 17 August 2015 (UTC)
I must say I consider it one of our best recent innovations, though of course I'd wish for it to have been around for longer already... But that will surely come with time ;-) Hobbitschuster (talk) 17:40, 17 August 2015 (UTC)
(Response to Na Tra) As Hobbitschuster notes, many listings now include a "last edited" date indicating when the listing was last verified as being up-to-date, but that field was only added to the listing template five months ago, so at this point the vast majority of listings do not yet have that field filled out. It wouldn't hurt to create a category to track articles with out-of-date listings now, but until the "last edited" field is used more widely that category will most likely contain every article with listings. -- Ryan • (talk) • 17:28, 17 August 2015 (UTC)
Uhm. I see the problems now. So that means there's still a lot of work ahead with the checking of old listings... =.= Na Tra (talk) 17:40, 17 August 2015 (UTC)

The "last edited" field is removed whenever I use the editor. I use the common combination of Windoze 8 (ugh!) and Firefox. Is this a bug or an undocumented feature? 20:00, 17 August 2015 (UTC)

Optional fields are automatically removed by the listing editor when they have no value, which is what appears to have happened. If you see a non-empty "lastedit" date being removed please let me know. -- Ryan • (talk) • 20:30, 17 August 2015 (UTC)
Thanks for your useful work improving the listing editor - but naturally I assumed that every time the new listing editor was now used (going forwards) it would add the last time an edit was made. It seems strangely counter-intuitive to arrange things so that this potentially very useful field is not only not completed automatically (when using the new listing editor) but actually removed entirely! What's the point of that? 20:46, 17 August 2015 (UTC)
Adding a new listing with the listing editor automatically populates the lastedit field. Editing an existing listing with the listing editor only updates the field when the user explicitly chooses to do so since they might only be correcting a typo or performing some other action that doesn't necessarily indicate that the listing information is up-to-date. See Wikivoyage talk:Listings#Next steps for the original discussion on the subject. -- Ryan • (talk) • 21:31, 17 August 2015 (UTC)
But, Ryan, why have it removed when empty? Not everyone uses the editor all the time, and when you're working in the wiki-syntax, it would be handy if the field is there, or not? JuliasTravels (talk) 21:37, 17 August 2015 (UTC)
The listing editor can be modified to always add an empty "lastedit" field, or to treat "lastedit" as a field to be removed if empty (the current behavior). Changing the behavior is a matter of updating a single flag, and I'm happy to update it if there is a consensus that it should be changed. -- Ryan • (talk) • 21:53, 17 August 2015 (UTC)

Ebola warningboxes[edit]

Is this thing over yet? I'm wondering if it's time to start removing the big red {{warningbox}}es about Ebola: suggests that Sierra Leone is down to its last two cases and the last quarantines are being removed; we've already removed the big red boxes from Liberia. What's the situation in Guinea or in any of the individual cities which've been plastered with warnings over the last year? K7L (talk) 04:10, 16 August 2015 (UTC)

CDC says Guinea still has new cases and is not advised to visit along with Sierra Leone [8] ChubbyWimbus (talk) 11:53, 16 August 2015 (UTC)

Could an admin please edit Common.css?[edit]

Any admin, could you please copy the 4 lines at into MediaWiki:Common.css so that {{PAGEBANNERS}} works with icons? Thanks a lot!

By the way, today is the last day of Sumit's Google Summer of Code! Congratulations to him for the hard work developing the banners extension :-) Syced (talk) 06:36, 18 August 2015 (UTC)

Although the change looks very simple and safe, I still wouldn't be comfortable asking any admin to do this. The skills of an Admin are not actually for technical work.
I have background in HTML, but as far as I can tell, only Ryan has been actively editing CSS files on Wikivoyage. It would probably be best to ask him. --Andrewssi2 (talk) 07:30, 18 August 2015 (UTC)
I've messed with this stuff before, so I went ahead and did it. Let me know if you find any problem... Texugo (talk) 11:26, 18 August 2015 (UTC)

Tabs out of alignment[edit]

The tabs at the top of the pages have gone out of alignment for me when I am viewing pages. The bottom line of the tabs drops down lower. They are fine when I am editing. It happens in 3 different browsers. Not a big deal - it seems just cosmetic. Is the same happening for other people? Nurg (talk) 07:21, 18 August 2015 (UTC)

Yes. I've noticed exactly the same already yesterday afternoon (about 20 hours ago) on both Safari and Firefox. ϒpsilon (talk) 07:25, 18 August 2015 (UTC)
I was having the same issues. I found it coincidental that the changes to MediaWiki:Common.css mentioned just above this thread were made in a similar timeframe. Upon reverting the changes, the tab alignment issue appears to have been fixed. Our coders will need to work to solve this bug before reimplementing the code into Common.css. I've also made the header of this thread a subset of the one before considering they're directly related. James Atalk 13:20, 18 August 2015 (UTC)
Edit: Although the problem seemed to be have been fixed temporarily, as soon as I posted this message it returned, even after refreshing the cache. Not too sure in that case; if people don't think the changes are related, I'm happy for the changes to Common.css be readded. James Atalk 13:25, 18 August 2015 (UTC)
The problem seems to be in the core Mediawiki stylesheets - it looks like a software update has a bug. Specifically, the height on this style rule seems to be problematic: div.vectorTabs li a. If the problem isn't resolved with the next update we can try to find a workaround. -- Ryan • (talk) • 15:07, 18 August 2015 (UTC)
I'd assumed it was an issue with the new Pagebanner extension, but apparently not? I do note that the tabs are rendered correctly when the page is first loaded; the lines shift after a half second or so. Powers (talk) 00:55, 19 August 2015 (UTC)
I've had a bit more time to compare Wikivoyage code to Wikipedia, and while that CSS is what's causing the tabs to enlarge, it's actually code from the listing editor that is the root cause of the problem. I'm not sure if something in Mediawiki changed recently that triggered this bug or if it's been there since the listing editor changes launched, but I'll try to figure out a fix as soon as possible. -- Ryan • (talk) • 01:30, 19 August 2015 (UTC)
I think that this change will resolve the issue, but please revert it if it creates any problems with the listing editor. -- Ryan • (talk) • 01:38, 19 August 2015 (UTC)
thanks. Nurg (talk) 06:37, 19 August 2015 (UTC)

How can we improve Wikimedia grants to support you better?[edit]


The Wikimedia Foundation would like your feedback about how we can reimagine Wikimedia Foundation grants, to better support people and ideas in your Wikimedia project. Ways to participate:

Feedback is welcome in any language.

With thanks,

I JethroBT (WMF), Community Resources, Wikimedia Foundation. 05:22, 19 August 2015 (UTC)

Do you think we should have banners like this one in our articles?[edit]

Through the last two years, in many instances I have had a difference of opinion about whether certain banners should used in Wikivoyage or not (this has lead me in many times to create quite a few new alternative banners, mainly for the articles of prominent sites/cities/regions, and first and foremost for usage in the corresponding articles in the Hebrew Wikivoyage, although I eventually end up suggesting using some of these alternative banners on Engvoy as well).

Either way, I just noticed that the user Andrewssi2 created this banner today. I decided bring this case up for discussion here in the Travellers' Pub, instead of the discussion page of the Inje article, mainly because I think banners of this type of banners (that show soldiers/war instead of prominent present day tourist highlights/attractions of a region) completely miss the main purpose of Wikivoyage and our articles, and therefore I am hoping we'll all discuss the usage of these type of banners, and re-reconsider using such banners in our articles.

In my opinion, the main purpose of Wikivoyage and our travel articles/guides is to first and foremost present our readers with the most prominent present day tourist highlights/attractions of of each region/city/country/site. Therefore, for example, in the Wikivoyage articles we have that are about regions in the Middle East or Africa that are in a continues state of war, we would definitely refrain from including banners or photos that have to do with the horrors of war / soldiers / guerrilla fighters / showing weapons, and most likely usually we would try instead to create a banner and/or add pictures of prominent archaeological sites, camels, and other prominent present day tourist highlights/attractions of that region that would make people actually want to go visit that area one day.

Do you think banners of this type should be allowed ? or do you prefer that only photos that show prominent present day tourist highlights/attractions of each region be used as banners? ויקיג'אנקי (talk) 12:44, 19 August 2015 (UTC)

I'd agree with your assessment of the Inje banner. If it was about a location such as the DMZ, I could understand the reasoning (but would still be hesitant). However, in this case, the Inje article mentions nothing about soldiers, and it doesn't portray the destination nicely. I think our banners should try to portray destinations in a positive light. James Atalk 12:58, 19 August 2015 (UTC)
The banner is well balanced and artistically interesting, but I agree that a banner without soldiers would be better, except if tourists go there to see the soldiers. Cheers! Syced (talk) 16:06, 19 August 2015 (UTC)
I don't think the banner is that objectionable. Northernmost Inje is actually in the DMZ, so I don't think it's improbable that you are going to see a whole lot of soldiers, military equipment and installations there. At least, when going from Seoul northwards, the last 20 km definitely reminds one of a military training area.
Also, I do think our banners should be varied rather than just panorama after panorama which has become the norm as of lately. That said, there are for sure other themes in Inje county that can be picked for the banner if people think it's inappropriate. ϒpsilon (talk) 17:31, 19 August 2015 (UTC)
I don't think military scenes should be inadmissible per se. Considering the introduction for Inje (I don't know this place), this particular banner would need more introduction though, as the text paints a completely different picture. That said, I do agree with Ypsilon that some creativity should always be applauded; the banners don't need to be /fair/ representations. They need to be inviting images. JuliasTravels (talk) 19:26, 19 August 2015 (UTC)
Soldier in London/Westminster
The article doesn't do a good job of explaining it, but the area is very close to the Korean DMZ and the military have a large presence there. You will likely see the military training in the mountains if you visit, and as such the banner is representative.
Banners do not have to just be about tourist attractions, and I reject that we should only feature the "most prominent present day tourist highlights/attractions". We would be a really bland travel guide if we did that. --Andrewssi2 (talk) 22:23, 19 August 2015 (UTC)
I think such a banner is perfectly allowable. Every banner should relate to the destination it's about, but I agree with Andrewssi2's point completely: The banner can be of a well-known attraction, a panorama, a bridge, a nice building, nearby hills, etc., etc. Why limit it? Ikan Kekek (talk) 02:04, 20 August 2015 (UTC)
The photo of the Buckingham guard on the right is an unfair comparison; he is a largely ceremonial soldier, while those pictured in the banner in question I wouldn't call at all ceremonial. This may be a better comparison; would that be an appropriate photo for an article? I don't question the banners quality. It's very good, it's just it's appropriateness. If Inje is in the DMZ (I didn't check, only read the article), then it may be more appropriate. James Atalk 08:29, 20 August 2015 (UTC)
Yeah, but your comparison is between a photo of a line of soldiers in pretty natural surroundings and a picture that focuses purely on soldiers, as the surroundings in the second photo are completely uninteresting. Ikan Kekek (talk) 08:35, 20 August 2015 (UTC)
Sorry James A, but you are actually very mistaken about the role of the Buckingham palace soldier, please check : w:Queen's_Guard . "Contrary to popular belief, they are not purely ceremonial and are fully operational soldiers armed with functional firearms fed from live ammunition". It is definitely a fair comparison.
Inje is a very much militarised area. It isn't a pure coincidence that a line of soldiers were having an exercise in the mountains. Andrewssi2 (talk) 09:12, 20 August 2015 (UTC)
'Ceremonial' was probably the wrong word. The duty of the Queen's Guard is to guard Buckingham Palace and other major royal sites. They are a significant tourist icon. The reason the other photo is comparable has nothing to do with the landscape; that's a non-issue in this case. It's because they are comparable soldiers: infantry whom fight on the front line and may engage in combat. James Atalk 11:24, 20 August 2015 (UTC)
I don't get the counterpoint from your statement? Your original comment was that the Buckingham Palace soldiers were "a largely ceremonial soldier" and not real soldiers and therefore "an unfair comparison" . Obviously this is not true at all and they are absolutely comparable. --Andrewssi2 (talk) 12:08, 20 August 2015 (UTC)
I don't think they're comparable. Many thousands of people put "see famous soldiers in bearskin hats walk down the street or stand near a door" on the list of things to do in London. I doubt that very many people put "see soldiers walk around the mountain" on their list of things to anywhere in the world. WhatamIdoing (talk) 21:32, 21 August 2015 (UTC)
The original question from ויקיג'אנקי was "Do you think we should have banners like this one in our articles?" The answer is YES ABSOLUTELY.
Seriously, please, no more bland landscapes of mountains or boring city shots of grey buildings that could be just about anywhere. Let us be as creative and interesting with our subject matter, not just use images that would be so tepid and uninteresting that they wouldn't make the grade for a cheap 25c postcard from a tourist trap.
I see our current issue as a lack of creativity, and fighting that should be our focus. --Andrewssi2 (talk) 12:08, 20 August 2015 (UTC)
I agree we could use some creativity in banners, but showing soldiers either in training or actively patrolling -- outside of the context of a tourist attraction -- goes against our mandate to make the places we write about seem appealing and inviting. Powers (talk) 14:17, 20 August 2015 (UTC)
I wholeheartedly agree with Andrewssi2. As yet we don't have the quality of content to compete head to head with the Lonely Planets and Frommer'ses of the world on their own terms. To be relevant we have to offer something different than they do, and I see creativity in banner images as a small part of that. Any publication can show their readers pictures of the most obvious and clichéd tourist attractions. Less often do you have a travel guide endeavor to provide a more immersive, "slice-of-life" picture of a destination, and if we want to make that our niche, I say by all means let's do that. Even if in Inje that means a picture of marching soldiers as a banner. Scenes like that are part of the landscape there, and there's something to be said for plainspoken honesty. -- AndreCarrotflower (talk) 17:10, 20 August 2015 (UTC)
It probably wasn’t the real intention of the public denunciation of my banner as the subject of this topic, but it has actually got people discussing what sort of guide we actually want to be and that can only be a good thing. My own motivation to creating the banner was to positively contribute to the community, and I feel this is something that should be encouraged as long as the pictures are within policy. Some people prefer generic touristy photos (which I find completely uninspiring), and I am also certainly on the side of "slice-of-life".
Also please note that although South Korea is a heavily militarized country, there are only two banners that feature soldiers out of 93 article banners for the country. Context is everything.
Thanks for all your comments, for or against! I hope that when you make your own banners in the future you will consider all the points raised above for the benefit of the site Andrewssi2 (talk) 22:36, 20 August 2015 (UTC)
I much prefer your banner in the article than none at all, and appreciate the effort you've gone to create it! Honestly, I don't have a strong feeling on the subject anyway and think any banner should be welcomed. James Atalk 08:36, 21 August 2015 (UTC)
Just an aside: I have had reason to buy both the second and third edition of LPs guide to Nicaragua and while the second edition (i.e. the first edition covering Nicaragua alone and not together with some other country) had the "money shot" of Volcan Concepción (on Ometepe) on it, the third edition has a small lavishly painted boat in front of a tropical landscape on it. So LP also seems to be heading into the "less conventional image" territory in their equivalent of banners... Hobbitschuster (talk) 10:30, 21 August 2015 (UTC)
Actually, to be fair, they've been doing that for a long time. I have quite a collection of LP guides, and their covers vary widely, with plenty of "slice of life" or destination detail images. Rather than us being in any way ahead of them when it comes to images (well, except that we have them for every town), we should at least not be more conservative. JuliasTravels (talk) 14:25, 21 August 2015 (UTC)

Banners extension: Now live on these articles[edit]

Dear all,

Since a few days, the new banner extension has been active on these two pages:

No problem encountered with those? If no, how about going to the next step? Which is:

We need to set $wgWPBBannerProperty on English Wikivoyage to "P948" to fetch banners from wikidata, as described at I am not an admin so someone will have to do it, but first is it OK to do that now?

By the way, Sumit's GSoC is over, so from now on we are on our own! Cheers! Syced (talk) 04:35, 20 August 2015 (UTC)

Not quite true :) I'm at hand to keep an eye on things and keep things ticking (I'm also keen to take it further and help review code if anyone wants to submit patches) and Sumit has expressed an interest in keeping an eye on it post GSoc Jdlrobson (talk) 05:36, 20 August 2015 (UTC)
Even admins don't have access to $wgWPBBannerProperty, only tech can do that.
On a more general note, I don't see the drop-down menu with subsections. Was it skipped in the final release for some reason? --Alexander (talk) 05:49, 20 August 2015 (UTC)
Sorry if I haven't been following this closely enough, but have we actually agreed on fetching banners from wikidata instead of setting them locally? Fetching from wikidata assumes all languages versions will want the same banner, which is not true, and would result in WD privileging WV:EN's banner choice over the others, which is not fair. Texugo (talk) 11:24, 20 August 2015 (UTC)
Could be done in the template to check wikidata for a banner only if one is not specified by the article. -- WOSlinker (talk) 11:29, 20 August 2015 (UTC)
That might be better, but it doesn't ensure that people will add the code locally rather than pop over to WD and change what's there. Texugo (talk) 11:35, 20 August 2015 (UTC)
I'm against automatically setting EN VOY banners against WikiData. If I want to change the banner for Paris then do I really want to go through due process and convince every language community? Or have I missed the point to this? --Andrewssi2 (talk) 12:14, 20 August 2015 (UTC)
If memory serves me correctly, we agreed that we would fetch banners from Wikidata as a default but to allow for each individual community to override them locally if there's consensus to do so. If there's the ability to do that with the current banner extension, fine. If not, then mark me down as strongly against deploying the extension at this time. -- AndreCarrotflower (talk) 12:47, 20 August 2015 (UTC)
Correct. The banners will come from Wikivoyage if a banner is available there but your community will always have the final say and can override it with a local version. Jdlrobson (talk)

The reason that the drop-down menu with subsections is not working is due to the following in Mediawiki:common.css

/* Prevent display of subheadings in horizontal ToC */
.hlist #toc .toclevel-2,
.hlist #toc .toclevel-3,
.hlist #toc .toclevel-4,
.hlist #toc .toclevel-5,
.hlist #toc .toclevel-6 {
    display: none;

It can't really be removed though until all pages are using the new banner as it would probably mess up some of the existing banners. -- WOSlinker (talk) 13:59, 20 August 2015 (UTC)

I just looked at this very quickly so I may be wrong, but in the Vancouver banner I'm not seeing the ".hlist #toc" pattern matching, so I'm not sure that the above CSS is the problem. The drop-down also appears to be broken on, so the problem may lie in the currently-deployed extension code. -- Ryan • (talk) • 14:25, 20 August 2015 (UTC)
A few points:
  • I've added a fix for TOC dropdowns not appearing and they would soon return to normal. Thanks for reporting!
  • Though my GSoC period is over, I'll still continue to make this extension better and be here for as long as it takes!
  • Enabling $wgWPBBannerProperty to fetch wikidata banners does not in any way take from editors the power to use native banners. Even after enabling that property, a wikidata banner would show-up only when banner name parameter to{{PAGEBANNER:}} is left blank. Specifying a custom image would show that image as banner just like the current template does. See the last example on

-Thanks!--Sumit.iitp (talk) 17:13, 20 August 2015 (UTC)

Update - Drop down toc's should now be visible--Sumit.iitp (talk) 18:47, 20 August 2015 (UTC)
Yes, I see them. Awesome! --Alexander (talk) 19:56, 20 August 2015 (UTC)
It looks like the icon-cruft is not lining up quite right with the top corner of the banner due to .wpb-iconbox { margin-top: -2px }. Kaldari (talk) 20:55, 20 August 2015 (UTC)
Tried to fix it here: Kaldari (talk) 21:03, 20 August 2015 (UTC)
Update: Red Wharf Bay is now using Wikidata to power its banner. Please test like crazy :) !!! Jdlrobson (talk) 23:13, 20 August 2015 (UTC)
I've created Template:PagebannerNew, which should behave exactly like the old page banner template, except that it invokes Sumit's extension. Just replace "pagebanner" with "pagebannerNew" at the top of the article; nothing else should need to change. Once the bugs are worked out we should theoretically be able to copy the new template code into the old template, and every page on the site would then update to use the new extension. -- Ryan • (talk) • 01:30, 21 August 2015 (UTC)

Is there any way we could get the bullets inserted between the TOC headings on the new banners? I hadn't noticed their absence before, but having some sort of separator is nice. Powers (talk) 01:10, 21 August 2015 (UTC)

Do you have an example of overriding WikiData? I take it from the developer page that it would be {{PAGEBANNER:RedWharfBay-banner-01.jpg}} ? Andrewssi2 (talk) 01:17, 21 August 2015 (UTC)
@LtPowers: This change should add the dividing bullets into the new TOC. Please revert if there are any unforeseen consequences. -- Ryan • (talk) • 02:33, 21 August 2015 (UTC)
@Ryan, Toc in banners is currently broken for me; is that related? JuliasTravels (talk) 08:01, 24 August 2015 (UTC)
Can you clarify what you mean by "broken"? Do you not see the drop-downs at all, do they appear but look strange, or is something else going on? Are you connecting on a laptop or on a phone? What browser are you using? Is it broken on both Vancouver and Red Wharf Bay, or are you seeing the issue on a different article that you're using for testing? -- Ryan • (talk) • 14:10, 24 August 2015 (UTC)
Sorry, that was far too vague indeed, and I had no time the rest of the day ;-) It's okay now. I was seeing white space for the toc on all pages, on a laptop in both FF and Chrome. Same machine now, but it's fine. Thanks, JuliasTravels (talk) 16:11, 24 August 2015 (UTC)

Bug reports[edit]

First, thanks for all of the hard work and the quick follow-up to issues raised so far. I ran into the following issues while testing the extension:

  1. Adding a page banner to a user page using the extension doesn't seem to do anything. Is that by design? Currently we allow banners on user pages such as on User:AndreCarrotflower.
  2. The "caption" attribute (mw:Extension:WikidataPageBanner) doesn't seem to do anything - what is its expected effect? The "tooltip" attribute currently generates the same behavior as "caption" did in Template:Pagebanner.

Let me know if any further information is needed. -- Ryan • (talk) • 01:52, 21 August 2015 (UTC)

currently disabled on user pages but a 10 minute config change I can do on Monday if needed. Jdlrobson (talk) 02:26, 21 August 2015 (UTC)
pgname, tooltip, bottomtoc, icon-<name>=Link, toc are all the parameters supported. There is no caption parameter. Jdlrobson (talk) 03:26, 21 August 2015 (UTC)
Thanks for clarifying, I've updated the docs at mw:Extension:WikidataPageBanner and will update Template:PagebannerNew to use "tooltip" instead of "caption". -- Ryan • (talk) • 03:55, 21 August 2015 (UTC)
One additional note, with the new pagebanner extension we lose the <h1> with the page title (the old page banner hides it using Javascript, but it is still something search engines likely would have spidered). Not having the page title in a top-level heading tag may be a killer from an SEO perspective. Would it be possible to change the "wpb-name" element from a div to an h1? It should be easy enough to style it so that it looks the same, and would avoid SEO issues. -- Ryan • (talk) • 04:18, 21 August 2015 (UTC)
Doh that was an oversight. Yes that should be an h1 'inside the banner I'm not sure what happened there.. task created. That said SEO is a bit of a mystery and I wouldn't worry about it unless you are seeing evidence of concrete lower page rankings. Given that h1s were previously hidden with the old banners and not visible at all, this may even be an improvement. Vancouver is currently not on the first 10 pages of Google search results for me for the term "vancouver wiki travel" with the old HTML so it will be interesting to see if that improves with the change... Jdlrobson (talk) 06:31, 21 August 2015 (UTC)
I guess if you are already prompting google to search for that other place it is unlikely to find the superior guide... Hobbitschuster (talk) 10:34, 21 August 2015 (UTC)
it's a wiki and the content is about travel and voyage is far superior content wise so it should he up there for that page and search term. I notice London does make it to page 1 so you guys are doing something right. As i said SEO is a mystery. I think the more important thing is content and incoming links. :/ 14:24, 21 August 2015 (UTC)
"tooltip" is a poor choice of parameter name compared with "caption", as it implies a specific browser implementation of the data which may not apply (e.g., in the case of screen readers). Powers (talk) 13:47, 21 August 2015 (UTC)
but doesnt caption give the impression the text will be appended and be visible and thus is not quite right too? I agree tooltip doesn't quite make sense in the case of screen readers. Maybe annotation?
In the interest of not diluting this discussion, it would be good if further non-banner SEO discussions could take place at Wikivoyage talk:Search Expedition. Regarding "caption" vs "tooltip", Template:Pagebanner uses "caption", but the functionality created by that parameter is to display the message in a tooltip when the mouse hovers over the image; perhaps "rollover" might be a better name, but "tooltip" actually seems more logical to me than "caption" for the behavior it invokes. Template:PagebannerNew still uses "caption" for backwards compatibility, although it is now internally translating the provided "caption" parameter and passing it to the extension as a "tooltip" parameter. -- Ryan • (talk) • 14:38, 21 August 2015 (UTC)
The behavior it invokes is only a tooltip if the browser you're using implemented it that way; that's my whole point. "Caption" simply implies that it's text describing the image. Powers (talk) 22:45, 21 August 2015 (UTC)
Just to confirm that the lack of an <h1> is a big deal, the Yosemite article unfortunately was spidered by Google on Aug 21, 2015 03:54:21 GMT, which fell into the three hour window when the new banner was live for that article. A search for "Yosemite travel guide" previously had the Wikivoyage article in position #12, but the article is now filtered out of search results completely and only appears as result #26 when doing an unfiltered search. -- Ryan • (talk) • 18:36, 25 August 2015 (UTC)
I may be the only one obsessing over how tweaks to articles affect SEO, but just to confirm, after Google re-spidered the Yosemite article Tuesday night (with the old page banner) we moved back into the rankings at position #14. With luck the fact that the new page banner does not require Javascript manipulation of the <h1> tag might provide an additional SEO boost. -- Ryan • (talk) • 00:51, 28 August 2015 (UTC)

It's worth noting that we can rename any of these parameters and still maintain backwards compatibility with the old ones temporarily. Jdlrobson (talk) 14:24, 21 August 2015 (UTC)

Is the image on the right how the banner extension is meant to work on mobile? The banner, the breadcrumbs and all the header items take up the entire screen, so it's not a great outcome. Just not sure if this is a bug, or the intended view for mobile users. I'm using Internet Explorer on Windows Phone 8.1 on a Nokia Lumia 930. James Atalk 10:20, 24 August 2015 (UTC)
Looks like a Windows Phone issue... see the same view on my iPhone 6 Andrewssi2 (talk) 10:55, 24 August 2015 (UTC)
Tracked in They should be the same although I'm not sure which one is displaying correctly. :) Jdlrobson (talk) 19:00, 24 August 2015 (UTC)
Thanks for following it up. Yes, no surprises it's a Windows Phone issue :P James Atalk 11:30, 25 August 2015 (UTC)

With the new banner on London differences in article revisions appear below the banner rather than above as they used to. I don't think that this is a massive problem, but is it intended? Also please could something be done about printing banners (an issue reported ages ago with the old banner - but still nothing is printed). AlasdairW (talk) 23:03, 24 August 2015 (UTC)

Banners are currently in a "noprint" section of HTML - that code is in the first line of Template:Pagebanner. I don't know the reason for setting things up that way, but assume it's probably due to the fact that the banner is resized via Javascript and thus might not print in the proper proportions. It's probably something that could be fixed with a little effort if there isn't objection to changing things. -- Ryan • (talk) • 23:17, 24 August 2015 (UTC)
Arguably, banners shouldn't print, though the title and a TOC of some sort should. Powers (talk) 00:16, 25 August 2015 (UTC)
With regards to noprint - please discuss here so we can work out what to do - - you can login with your wikivoyage account! :) Also with regards to the differences in revisions I'm not 100% clear what you mean. Are you talking about diffs? Jdlrobson (talk) 16:51, 25 August 2015 (UTC)
See, for example, here; previously, since the banner was part of the page content, it appeared below the diff as part of the preview of the article. Now, as an interface element, it appears above the diff. Powers (talk) 17:57, 25 August 2015 (UTC)
Banner heading inside div instead of an h1 is resolved, and the extension would soon upgrade itself to use the newmakrup. The pages will then have h1 inside banners. :)--Sumit.iitp (talk) 12:34, 26 August 2015 (UTC)


With the <h1> issue now resolved I think there are only two open banner issues:

  1. The banner is appearing above diffs: [9] vs [10].
  2. The new banners cannot be used on userpages.

There is also a noprint issue, but that's an existing issue with the banners and not something that should hold up deployment of the new banners. Have I missed anything? Jdlrobson indicated the fix for #2 was a simple configuration change, and I suspect that the benefits offered by the new code might be great enough that people would be OK with launching the new banner sitewide without #1 being fixed (I actually like the new behavior better since it separates heading from content). Is there anything else that would prevent us from using the new extension on all articles? -- Ryan • (talk) • 19:22, 26 August 2015 (UTC)

I will get them installed on user pages at 5pm PST I wasn't aware of the revision problem - have created to get this fixed as soon as we can. At latest a fix should be live next week but probably sooner. Jdlrobson (talk) 19:50, 26 August 2015 (UTC)
Now working. See in action on User:jdlrobson. Unfortunately however the changes we made to the h1 have broken section collapsing in mobile view - at least now I know why we were not using a h1 :) Tracked in Jdlrobson (talk) 00:03, 27 August 2015 (UTC)

Wild [edit|edit source] Right adjustment problem Syced (talk) 03:56, 27 August 2015 (UTC)

We are now enabled on user pages and the toggling on mobile issue is fixed. Can we safely switch over to the extension now and iterate on it or are there any other blockers you see? Jdlrobson (talk) 00:10, 28 August 2015 (UTC)
Given the fixes that have been made I no longer have any objection to copying Template:PagebannerNew to Template:Pagebanner and thus making it live across the site. From the descriptions it doesn't sound like the two issues raised by Syced are blockers, but as a courtesy to site users why don't we delay for another 12-24 hours just to give one last chance for people to do some final testing or raise any last objections? Barring any significant issues the new extension would then go live on all articles within the next day. Does that sound reasonable? -- Ryan • (talk) • 00:45, 28 August 2015 (UTC)
Out of my two issues above, one is solved, only one is probably linked to something in my environment, so I am all for deploying across the site :-) Syced (talk) 05:05, 28 August 2015 (UTC)
Let's set noon Pacific time (three hours from now) as the launch time for the new banner extension. That gives a last chance for anyone to comment, but also provides enough time during business hours that Wikimedia folks will be online to address concerns, and a few regular editors will still be around to revert if necessary. -- Ryan • (talk) • 16:21, 28 August 2015 (UTC)
I've updated Template:Pagebanner, so the new extension should now be live on all pages. -- Ryan • (talk) • 19:08, 28 August 2015 (UTC)

Say, I've noticed that pages where we don't want a pgname displaying (e.g. Chicago, Hollywood) are now displaying the &nbsp code instead of the empty space. Anyone know how to fix that? PerryPlanet (talk) 20:53, 28 August 2015 (UTC)

Oh, wait, hang on, it looks like all wiki code isn't being supported in the pgname function (see Santa Cruz (California) and Devils Tower National Monument). PerryPlanet (talk) 20:57, 28 August 2015 (UTC)
We shouldn't be using HTML in page titles. If there is a desire to have boxes wrap we can do so with CSS, but we shouldn't be trying to format the headings with HTML. -- Ryan • (talk) • 21:19, 28 August 2015 (UTC)
Similarly, for pages like Chicago, suppressing the page title is an absolute SEO killer and something we really shouldn't be doing. -- Ryan • (talk) • 21:21, 28 August 2015 (UTC)
There's got to be some way to hide them while retaining the SEO and accessibility benefits, doesn't there? Powers (talk) 23:33, 28 August 2015 (UTC)


Using Firefox banners are loading the wrong proportions. Need to resize the window a few times before it looks correct. --Traveler100 (talk) 02:50, 29 August 2015 (UTC)


Forgive if this has been addressed somewhere. I was wondering, will the new pagebanner functionality maintain the categorization we have been using (Category:Has banner, Category:Has default banner, Category:Has custom banner)? Texugo (talk) 15:29, 28 August 2015 (UTC)

Have a look at Vancouver, Culver City or Yosemite National Park which are all using Template:PagebannerNew. If there is any difference in categorization then it's a bug. -- Ryan • (talk) • 15:49, 28 August 2015 (UTC)
Those three look fine, and the categorization with default banners looks fine too. I suppose if we are going to have it pull banners from WD when not specified locally, we need to test the categorization for that case too. Texugo (talk) 15:56, 28 August 2015 (UTC)

Effective strategy for completing banners on a country/state level[edit]

My public denunciation and successful refutal above gives me an opportunity to highlight my approach to South Korea that I am making good progress with (given that my time is sporadic at best):

  • There are 114 South Korean Articles
  • As of today there are only 21 South Korean articles without a banner (much better than the 33% coverage in English Wikivoyage)
  • It is a bit of a struggle finding CC images for this country that are distinctive to a particular town or area – for the first time visitor you could travel the breadth of this nation and frankly see the same types of buildings and mountains everywhere
  • Buddhist temples make for nice banners, but every article could actually have a similar looking local Buddhist temple - I try and avoid for this reason
  • To my knowledge, there are exactly 2 articles out of the 114 that use banner pictures of the military. Given the militarized state of the country, that is actually below representative. I do not regard the Army as either positive or negative but as part of everyday Korean society and that is valuable for the traveler to understand
  • Every banner has to be relevant to the area it is depicting
  • All banners conform with Wikivoyage Image policy

The approach has been:

  1. Run a report on all articles in South Korea without banners
  2. Order the results by article size (largest first)
  3. Attempt to find a compelling image from Flickr and/or Wikimedia and adapt it (sometimes a compelling image is not possible, and then it goes to the ‘most acceptable option’)
  4. Upload and… one more banner down

Rather than people wasting time creating banners for articles that already have more than acceptable banners, I would seriously ask people consider choosing a country (or state) and taking the a similar approach. The rules I apply to image selection in South Korea will be different elsewhere, and you know your countries best! Good luck :) --Andrewssi2 (talk) 22:51, 20 August 2015 (UTC)

I started doing this, and adding image URLs to Wikivoyage:Banner_expedition/Banner_suggestions_-_List_1 :-) Even though Nara has a banner it is listed by the catscan request, strangely. Syced (talk) 03:20, 21 August 2015 (UTC)
Curious, it seems that Nara has a category issue. I'm not sure how to debug that. The banner markup looks fine.
That said, Japan has 686 articles and 445 articles without (reported) banners! That seems rather too high for such a destination. I'm doing a China banner side project as well that is comparable in scale. Andrewssi2 (talk) 05:31, 21 August 2015 (UTC)
The banner syntax was non standard - "PAGEBANNER:Nara banner Daibutsuden.jpg|" instead of "pagebanner|Nara banner Daibutsuden.jpg" which meant that it didn't appear in Category:Has custom banner. This is some quirk that lets the banner appear but not be added to the category. AlasdairW (talk) 13:58, 21 August 2015 (UTC)
Re that banner category, there is a long-unaddressed issue at Category talk:Has custom banner. Nurg (talk) 06:09, 23 August 2015 (UTC)

Table of contents (ToC) working at last![edit]

I just discovered that the ToC is finally being displayed with tertiary headings dropping down at Vancouver.

This is a major achievement since the eye-candy banners weakened the functionality of our site many months ago and I'd like to thank whoever is responsible. Who was it? 11:58, 26 August 2015 (UTC)

Ooooooh! It gets better! Clickable quaternary headings are displayed if you hover your mouse over the relevant tertiary heading that drops down! Does this neat restoration require Java or anything fancy? 12:00, 26 August 2015 (UTC)
No Java, only JavaScript. Indeed, it is cool that we are now able to deep-link to for instance Vancouver>Get around>By car>Parking, very convenient when friends on social networks ask for travel tips. Syced (talk) 03:34, 27 August 2015 (UTC)
Is it actually using Javascript? The TOC looks like it's primarily done with CSS, and if I disable Javascript in my browser it still seems to work. -- Ryan • (talk) • 03:48, 27 August 2015 (UTC)
It's all CSS :-) You can thank User:Sumit.iitp a student in India for making that happen :-) Jdlrobson (talk) 18:10, 27 August 2015 (UTC)

Routebox editing issues[edit]

Example of error on the routebox

As of today, when editing a routebox, &#13; is being added to the right-hand destinations, as shown on the image to the right. The routebox template hasn't been edited recently, so that's not the issue. Eco84 (talk) 21:58, 26 August 2015 (UTC)

I'm not 100% confident in this fix, but I think the edits I just made to Template:Routebox and Template:Routebox/row will resolve the issue. The former appears to have had some mis-matched braces that for some reason weren't breaking anything. The latter is where the &#13; was coming from, so I assume that perhaps the underlying Mediawiki parser might have changed in a way that caused it to display instead of generating a carriage return? -- Ryan • (talk) • 22:57, 26 August 2015 (UTC)
The &#13; is gone, but the excessive gap between the place name and the actual routebox (which I previously forgot to mention) is still there. Eco84 (talk) 23:23, 26 August 2015 (UTC)
I think Special:Diff/2844941/2845001 should fix spacing issues. -- Ryan • (talk) • 00:06, 27 August 2015 (UTC)

Wikivoyage broken on Chrome?[edit]

Since this morning I can not use Wikivoyage on Google Chrome in both normal and incognito modes. It appears to hang and then eventually timeout and crash.

I am using Version 44.0.2403.157 (64-bit) for Mac OSX. (Yay autoupdating of browsers that break things)

Firefox on the same machine is fine.

Where do I raise this issue? --Andrewssi2 (talk) 00:17, 27 August 2015 (UTC)

I'm on Chrome 44.0.2403.157 m for Windows, and while I saw one hang on the recent changes page that caused Chrome to crash, that was an isolated incident and the site has otherwise been fine. If the breakage is specific to the browser then the fault likely lies with Chrome - they allow bug reports via [11]. -- Ryan • (talk) • 00:28, 27 August 2015 (UTC)
I just tried again a couple hours later and it is working fine. Possibly a caching issue that fixed itself. --Andrewssi2 (talk) 01:36, 27 August 2015 (UTC)
hmm, issues started again. I have logged it with the Chrome team. --Andrewssi2 (talk) 06:51, 27 August 2015 (UTC)
I have another weird issue with a specific detail, that I only had since a couple of hours. Namely, (500 last recent changes) won't load at all on Safari. Regular Recent changes (with 50 edits) shows up normally on Safari as do all articles. On Firefox I have no problems.
Also another interesting thing (which has gone on for more than a week) is that the "Welcome to Wikivoyage! Help us to improve our travel guides by contributing to an article today!
Welcome, Wikipedians | Policies and guidelines | Follow us on Facebook and Twitter" message occasionally sits at the bottom of the page, and when this occurs the message's font size is remarkably larger than otherwise. ϒpsilon (talk) 08:07, 27 August 2015 (UTC)
Might be same issue, since it is typically that page (with the 500 results) that typically crashes Andrewssi2 (talk) 08:18, 27 August 2015 (UTC) (500 last recent changes) works for me in Safari 8 on Mac OS 10.10 (right now). WhatamIdoing (talk) 16:29, 28 August 2015 (UTC)
I've also noticed it's working again. ϒpsilon (talk) 16:35, 28 August 2015 (UTC)

TOC strangeness[edit]

Is someone changing Wikivoyage settings? The table of contents styling broke for all page banners using the old Template:Pagebanner due to the underlying HTML changing - the CSS class "tocFloat" stopped appearing on the div with id "toc", causing the TOC to render as a white block. In trying to fix the issue by modifying MediaWiki:Common.css I've seen the old HTML return and then disappear once or twice. Does anyone know what's going on? -- Ryan • (talk) • 02:01, 27 August 2015 (UTC)

Bot to find banners?[edit]

Are there many cases where some language versions lack a banner but other versions have one for the corresponding article? Could a bot find those so we could add them?

While we're about it, are there cases where two languages have different banners? Pashley (talk) 02:30, 28 August 2015 (UTC)

We know that there are quite a few instances of banners at heb.voy being different from banners at en.voy. Ikan Kekek (talk) 02:37, 28 August 2015 (UTC)
If we uploaded banners to Wikidata (rather than locally), the issue would not even arise. A Wikidata user used to upload banners to Wikidata regularly, but unfortunately he/she disappeared. Syced (talk) 05:02, 28 August 2015 (UTC)
Well, we upload banners to WikiMedia right? We then create a property in WikiData to register that. As long as (for example) French Wikivoyage users register their banners in the correct WikiData item then we would be able to use them with no effort.
But... people need to use WikiData for that to happen :)
An easy way to get the result Pashley is looking for is to run some queries such as all EN WV Europe articles with no banners and all FR WV Europe Articles with custom banners . Export them as CSV and do some basic Microsoft Excel mashing. --Andrewssi2 (talk) 06:33, 28 August 2015 (UTC)
Disclaimer: This technique will only work if the French and English destination names are the same --Andrewssi2 (talk) 06:35, 28 August 2015 (UTC)
A note: (A list of WikiData Qnnn (IDs) as found in en.wikivoyage might be useful to start with! I would like to see a CSV file of them...) - Look up Q668 - title is India - banner property is P948. Check sitelinks for fr.wikivoyage and you should be able to get name found in fr.wikivoyage: ie. fr -- Inde for Q668. That might give something more to work with:
Q668 -- India -- India banner Elephants.jpg -- Inde -- (then look up P948 for fr language WikiData entity)
(Should provide some useful data - missing articles, missing banners etc.) - Just a thought. - Matroc (talk) 07:06, 29 August 2015 (UTC)
I was under the impression that our banners get imported to Wikidata by bot... The banner expedition mentions: "When there are more than 100 banners at Category:Banner missing from Wikidata. Please ask user Kizar on Wikidata to run xyr bot (example)." (That category is well over 100 now). Can we get the same thing working for other wikis? JuliasTravels (talk) 11:47, 28 August 2015 (UTC)
With the new extension when live, I suspect we can automatically save the banner to Wikidata and override any existing value. If the extension gets installed on other wikis you'd all naturally benefit from banner contributions in other projects. Jdlrobson (talk) 17:24, 28 August 2015 (UTC)