Wikivoyage talk:Banner Expedition/archive 2013-19

Latest comment: 4 years ago by AlasdairW in topic breadcrumb trail

Add a "full TOC" button? edit

As things stand, I see no way to get a full table of contents for a page with a banner, short of editing it to remove the banner. Have I missed something? If not, can we add one?

For many pages, this is not a problem, but for a large complicated page like Shanghai it does seem to be. Lots of sections there have many subheadings — "Get around" currently has 13! — I've already removed some and will do more, but then I've also added some. There should, I think be some simple way to get at those for easier navigation.

Put a "Full contents list" into the banner? Or just "TOC"? Some sort of icon? Whatever we do should be fairly obvious; regular editors could learn control-shift-right-click to get a contents menu, but we shouldn't have to and in any case that would be of zero value to most readers. Pashley (talk) 20:15, 16 May 2013 (UTC)Reply

Or just a perhaps-not-well-thought-out suggestion, but for cases where there are a lot of subsections, we could put a sub-index at the top of each section in the article body, using the same tocbox format:
Texugo (talk) 20:34, 16 May 2013 (UTC)Reply
That does sound like it might be a good idea. --Nick (talk) 21:12, 16 May 2013 (UTC)Reply

Per-section index edit

I think having a sub-index at the top of a subsection might be the best way to go for now. The banner doesn't display the full contents well, and for guides like Shanghai, it would probably make the TOC box so large it would overlap with the title (the TOC box starts at the bottom and moves up). Although, any sub-index would have to be set up manually. The Mediawiki software only allows the __TOC__ command to be used once per page. -Shaundd (talk) 04:46, 22 May 2013 (UTC)Reply
I think ideally we'd like to have a CSS dropdown on each ToC link in the banner, but I don't know how feasible that is. LtPowers (talk) 12:55, 22 May 2013 (UTC)Reply
If that (CSS dropdown) means what I think it does, that would be a good solution. There are travel topics which are now a bit tedious to navigate with the truncated single level TOC. Other than that, the banners really give the articles a fresh new look. • • • Peter (Southwood) (talk): 09:13, 10 June 2013 (UTC)Reply
...or we could revisit the "section heading / banner" thing and see if perhaps there indeed is a workaround there. One like Nicholas proposed (below) would come in handy in case there are many subsections:


...doable using CSS or other Java tricks? PrinceGloria (talk) 13:38, 10 June 2013 (UTC)Reply
Again, I think we come up against the current technical impossibility of automatically populating the subsection list. This is not something that would be feasible to implement and maintain manually. Texugo (talk) 14:14, 10 June 2013 (UTC)Reply
I guess this will be a problem for any solution that would be based on generating a TOC out of headings in a article section, which is what I understand all of the above proposals are. PrinceGloria (talk) 16:13, 10 June 2013 (UTC)Reply
Yep. I think it's pretty much idle daydreaming unless someday a new version of mediawiki comes along that allows multiple TOCs to be generated and manipulated. Texugo (talk) 17:10, 10 June 2013 (UTC)Reply
I may be the only one, or close to it, but I find drop-down menus obnoxious. For example, moving horizontally, point at "Eat" and you get a vertical menu with "budget", "mid-range" "splurge"; the screen is cluttered with stuff you may not want, especially if you are just going past Eat to reach another main heading or you just want to click on Eat. For that matter, I do not like the TOC with little + signs to expand sections; just show me the damn TOC already, don't make me mess about before I can see it. Again, this may well be a minority opinion.
Given those preferences, the options proposed so far come out in this order:
  1. section banners, obviously far the best as a user interface. What do we need to make them practical?
  2. my original suggestion; a "full TOC" button in the banner
  3. drop-down menus
As I see it, any of these might be fine as a quick fix if it is easy to do, but only the first is worth any significant effort. Pashley (talk) 17:43, 10 June 2013 (UTC)Reply
As I was saying, none of those options are possible at this time because Mediawiki software does not permit any method of automatically creating secondary or additional TOCs with javascript, css, or anything else. Texugo (talk) 17:49, 10 June 2013 (UTC)Reply
Well we managed to get the top-level headings displaying at the top; seems like it's at least plausible that we'd be able to finagle the lower-level headings to display as submenus thereof. We wouldn't need "secondary or additional" TOCs in that scenario; we'd simply be using the single primary TOC differently. To Texugo: There are ways of implementing dropdown menus that alleviate your concerns; after all, windowed operating systems have been doing just that with considerable success for decades now. LtPowers (talk) 18:01, 10 June 2013 (UTC)Reply
Pashley, you aren't the only one. Without having seen it, I'm inclined to think no subsection links are better than subsection links as drop down menus, because I have trouble imagining how they would avoid looking ugly and potentially interfere with mouse navigation. But that is of course without having seen it. --Peter Talk 18:17, 10 June 2013 (UTC)Reply
While we are waiting for a better solution I have made an alternative page banner template {{Altpagebanner}} which omits the horizontal ToC which I am using on articles which really need a full ToC to be reasonably user-friendly. It could be implemented in the original page banner template by adding an optional parameter to turn off the ToC, but my template-fu isn't up to it, and just forcing a ToC is ugly. I really like the page banners, but this is something that needs short term and long term solutions. • • • Peter (Southwood) (talk): 14:21, 12 June 2013 (UTC)Reply
Bravo! I have applied it at Shanghai and it does provide reasonable short-term solution. Pashley (talk) 14:53, 12 June 2013 (UTC) reasReply
That's debatable. Using a second template instead of parameterizing the main template is confusing and makes maintenance much harder. Interface-wise, retaining the page banner but not the TOC feature violates the expectations of the user and is confusing both for users and editors not familiar with the change. And all this for an extremely limited benefit -- the ability to jump straight to the "By bicycle" section of "Get around"? It's not like it's hard to find from "Get around" -- how many readers do you think will take the time to expand the TOC just to go straight to a subheading? LtPowers (talk) 15:27, 12 June 2013 (UTC)Reply
I'm with LtPowers. I think the disadvantages far outweigh the advantages here. I'd rather see us keep to a single template (without ability to turn off the horizontal TOC), so things are presented consistently. The ability to jump straight to subsections will be neato when we have it, but I think it's being a bit overrated in terms of how often people actually use it, and I don't think it is essential. Texugo (talk) 15:42, 12 June 2013 (UTC)Reply
I also agree—it's confusing to see the pagebanner missing the usual, expected table of contents. --Peter Talk 15:44, 12 June 2013 (UTC)Reply
      • edit conflict *** I second LtPowers' reservations. To me, even though I had much experience with the MediaWiki engine, it wasn't even quite obvious that subheadings can be accessed by clicking the "+" in the contracted TOC. I believe it adds confusion and limits the benefit. If your sections are vast and some subsections are really important, why not either elevate them to a higher heading level or link from the body in the introduction. If you fear the user may not be able to navigate a section, why not give it a lead with links to further subsections within it? PrinceGloria (talk) 15:44, 12 June 2013 (UTC)Reply
Could you all please take a look at the problem before deciding that a solution is not necessary? Go to Scuba diving, and without using the expanded ToC, find the entries on any 3 randomly chosen countries of your choice. (Make your choices before starting). Then do the same using the expanded ToC. Then come back and tell me if you think there is a need for a temporary measure or not.
I did mention that I don't know how to parameterize the main template, so I didn't mess with it. I quite agree that it would be better that way, which is why I suggested it. • • • Peter (Southwood) (talk): 16:37, 12 June 2013 (UTC)Reply
I was mainly addressing Shanghai. Scuba diving is indeed hard to navigate, which is an indication that it needs to be overhauled. The fact that continents are third-level headings but enlarged to be bigger than the second-level headings is indicative of a serious problem in its organization. The difficulty in finding specific countries within the article is merely a symptom of that larger problem. LtPowers (talk) 17:32, 12 June 2013 (UTC)Reply
Scuba diving could use some good ideas for re-organisation. Constructive comments always welcome. There are other travel topics with similar problems of large numbers of subsections, but fewer formatting issues. Cheers, • • • Peter (Southwood) (talk): 18:25, 12 June 2013 (UTC)Reply
If an article absolutely must have subheaders shown in the ToC (and still, they're hidden behind that plus sign that readers may miss), I think it would be better to remove the pagebanner altogether. Having an "empty" pagebanner at the top is confusing and a little jarring. --Peter Talk 18:33, 12 June 2013 (UTC)Reply
I don't see the lack of horizontal TOC in the banner as confusing or jarring, less so than leaving the pagebanner off a few pages, which would be far more confusing and jarring to me. However, tastes differ, and if there is a consensus to leave the pagebanner off for pages that need a fully functional ToC, I would accept it with some amazement, but no big deal in my life.
I would also like to like to see the stated aims of the expedition realized;
  • create a clean start to the page by having a lead image and horizontal TOC at the top before the article begins
  • make the first impression of our guides more eye-catching
  • give our guides a fresh and more modern look
but not at the cost of making some pages unduly awkward to navigate, as that is not putting the traveler first.
I am suggesting the alternative page banner with ToC layout as a temporary measure, for those articles where it is functionally necessary, only until the technological problems of doing it properly are ironed out. I think the best option suggested so far is the drop down menus, but would accept any of Pashley's suggestions, as either temporary or permanent solutions. • • • Peter (Southwood) (talk): 20:04, 12 June 2013 (UTC)Reply
I definitely agree that some pages are special and it may be necessary to show lower level headings. Scuba diving may be one, but UNESCO is one of the better examples imo; without being able to jump to individual countries, it makes the list very hard to navigate quickly. However, the examples are few. It would only be the odd travel topic. Normal destination pages like Shanghai shouldn't need TOC access to their third level headings; if it does, there may be too many of them and the article should be changed. James Atalk 13:39, 13 June 2013 (UTC)Reply

────────────────────────────────────────────────────────────────────────────────────────────────────

UNESCO is far too long and the title is quite misleading. It would best be broken up into "UNESCO World Heritage sites in Africa" etc., per continent. If the top-level headings are not enough to navigate through the article, it is time to break it up IMHO. PrinceGloria (talk) 13:54, 13 June 2013 (UTC)Reply

Per continent will reduce the article length, but have you counted the number of countries in each continent? Africa: 40, Asia: 38, Europe: 46, others fewer.That would be another challenge for a horizontal ToC, particularly for display on a narrow screen. • • • Peter (Southwood) (talk): 17:55, 13 June 2013 (UTC)Reply
You could use continental sections as the top level headers though. Texugo (talk) 19:28, 13 June 2013 (UTC)Reply
Don't quite understand how "UNESCO World Heritage List" is misleading, as that is precisely what it is. The article is quite long, but it would not serve the traveller if we were to break it up. Wikipedia does that, because they have a mini-description and photo of each, and it makes it confusing. The one, unified list makes it simple to find particular sites and countries, and to print. Instead of proposing splits and renames, the solution is a proper TOC. James Atalk 07:48, 15 June 2013 (UTC)Reply

(od) Another possible arrangement - and again I have no idea how it would be done, but this is how my bank's website does it - is horizontal dropdowns. If you click on a top level ToC item, it highlights the active item and opens up the sub table as a horizontal ToC. This could be done for as many levels as necessary, each level only going down one row vertically. It does mean that only one sublevel of any given level can be open at a time, but that is a lesser problem. Cheers, • • • Peter (Southwood) (talk): 20:19, 12 June 2013 (UTC)Reply

There's lots of good ideas and issues being raised here, but I think the only feasible short-term solutions are:
  1. Leave the banner as-is and accept there won't be subheadings
  2. Use the old-style ToC, with or without the banner, when considered necessary (as proposed by the two Peter's above).
  3. Leave the banner as-is and use a manual horizontal list or navbox to create sectional ToC's for those instances when it is considered necessary.
Of the options above, I'd prefer 1 or 3, but can live with any of them. For #2, I agree with Peter Southwood and would prefer to see a ToC-less banner with the old-style ToC, over no banner at all.
Drop-down menus would be nice to have but I'm really not sure they can be implemented without an extension being built. The information is in the page source code, but the Mediawiki software doesn't structure it in a way that makes it easy to say that's the Get in section subheadings so you can manipulate them. It may be possible, but it's beyond my skill level. -Shaundd (talk) 05:09, 13 June 2013 (UTC)Reply

Dropdown menus edit

Quickest fix would be dropdown menus, since the table of contents is already fully there. I've mocked something up here, using Shanghai and Scuba diving as examples. Can't quite get it to work in WV, probably because of CSS conflicts like an explicit rule to not display second/third level headings. It does seem like it won't be to everyone's taste, but it's quite common because of its relative simplicity. Oh, and I disabled it for narrow screens too, or there'll be overlapping sections otherwise. Section headers would be interesting and could probably work since the data is there, but will need Javascript of sorts and a fair bit of work. -- torty3 (talk) 12:18, 13 June 2013 (UTC)Reply

Of course it could use some tweaking, but I like the mock-up. So you know how to make it automatically extract that info to build the submenus? Texugo (talk) 13:11, 13 June 2013 (UTC)Reply
I'd be interested to hear how you built that TOC with drop-downs. It looks like some form of html and javascript that wouldn't work within a MediaWiki configuration, which is what we're constrained by. Either way, it's a neat idea. James Atalk 13:39, 13 June 2013 (UTC)Reply
I really do like the drop-down menus, though is it something that we could implement on here? --Nick talk 14:14, 13 June 2013 (UTC)Reply
Entirely CSS, based on Shaun's hard work and design, and making greater use of the nested lists. So it should be able to work here, just that the Mediawiki:common.css is given priority somewhere and I can't find the conflict. There's actually quite a bit of extra code there that isn't needed at all. Anyway, check User:Torty3/common.css if you want to look at the code more carefully. Is there some place easier to test it though? -- torty3 (talk) 14:48, 13 June 2013 (UTC)Reply
Looks good to me. • • • Peter (Southwood) (talk): 17:33, 13 June 2013 (UTC)Reply
Do the dropdowns overlay the content text or push it down? The test page doesn't show. Overlay would be preferable I think, or the contents will be bobbing up and down like a yo-yo. • • • Peter (Southwood) (talk): 17:55, 13 June 2013 (UTC)Reply
That's cool, and the test page you linked to above worked on the different browsers that I looked at (Chrome, Firefox and IE8). Re the second/third level headings, there is code in common.css that sets second level headings and below wrapped in an hlist div to display=none. Not sure of the best way to test the dropdowns though since changing the current hlist css will impact all banners. I'm away for the weekend but I can take a look at the code when I'm back to see if there are any conflicts (if it hasn't been fixed already). -Shaundd (talk) 14:45, 14 June 2013 (UTC)Reply
I was leery of dropdown menus, but this mockup looks great. The only hitch I can think of would be when a banner has more than one row of section headers, but then again, does that really happen? --Peter Talk 21:12, 14 June 2013 (UTC)Reply
It does all too often, actually. But it is a good sign the article has too many top-level headings :) PrinceGloria (talk) 21:16, 14 June 2013 (UTC)Reply
It depends a lot on screen resolution. On my home computer, which is 1366 pixels wide, Country TOCs fall onto two lines but everything else is usually one row. My work computer is around 1600 or 1700 pixels wide and I haven't seen any TOC take more than one line. I find it becomes more of an issue around a resolution of 1200 pixels. -Shaundd (talk) 23:01, 14 June 2013 (UTC)Reply
@PrinceGloria, Could you point us to an example of too many top-level headings please. • • • Peter (Southwood) (talk): 06:07, 15 June 2013 (UTC)Reply
Netherlands --PrinceGloria (talk) 20:39, 19 June 2013 (UTC)Reply
You do realize that with the exception of "Drugs and prostitution", every one of those is a standard section as expected in a country article? Nethertlands has somewhat unusual drug and prostitution laws and enforcement policies, so I guess it was considered appropriate to make that a top level section as well.
Are you proposing as an alternative layout to the one which has been pretty much the standard for years, or just moving the one non-standard section into one of the others? • • • Peter (Southwood) (talk): 21:12, 19 June 2013 (UTC)Reply

>> indent reset << I am not proposing anything, was just looking for an example since you asked (and I knew I saw quite a few) and found one today. And, as you noticed, we need only one (longer) heading over the "standard" ones to corrupt the banner on many screens.
As concerns the solution, I believe "drugs and prostitution" could just as well go into "Stay safe" as two headings. Most countries have something unusual. A country known for unusual cuisine or drinks will probably have an unusually large "eat" or "drink" section, perhaps with subsections devoted to particularly peculiar and interesting phenomenons. Perhaps Mongolia should have a large subsection on accommodating oneself in a yurt, but I would still keep it within "Sleep".
As a sidenote, I do not believe that something being a "standard for years" automatically makes it good. Things tend to stick around not only because they work, but also out of inertia. This is not a very lively or successful project as of now. I would be wary of canonizing tradition here and believe we should be open to revisiting every rule, guideline and standard at any time.
Kindest, PrinceGloria (talk) 21:30, 19 June 2013 (UTC)Reply

In this particular case your solution looks reasonable at first glance, and your point about inertia is taken, as I have made that point myself in the past. Technically all rules guidelines and standards are open to revision at any time. All that is required is a proposal, a discussion, and a consensus to change. Since anyone can make a proposal, and getting a few people into a discussion is seldom difficult, the major barrier to change is generally consensus. Getting consensus for a change can be difficult if there are a few people who oppose it, as the bias is solidly in favour of status quo. That is why I oppose uneccesarily rigid rules in the first place, particularly where there may be unforeseen consequences. Cheers, • • • Peter (Southwood) (talk): 06:17, 20 June 2013 (UTC)Reply
To get back to the point of dropdown menus. There appear to be two possible ways forward.
  • Get the dropdowns to work over a folded first layer horizontal ToC (minimal long term repercussions)
  • Force a first level ToC with so few items that it fits in one line of text no matter how narrow the screen or how large the user magnification settings (rather difficult to decide what that would be, and requiring a major rewrite or rearrangement of almost all articles after achieving a consensus on a major change to the MoS)
My inclinations are toward the first option if it is technically possible, but it might be worth looking at the possibilities and implications of the second option as a fallback. • • • Peter (Southwood) (talk): 06:41, 20 June 2013 (UTC)Reply
The first doesn't seem too possible, though the second seems nearly as much. I've actually disabled dropdown menus for screens that are too small since they are the ones most affected by the two layer ToC, though I suppose they might be the ones that need it the most. I've had further thoughts about section headers: while doable within the site itself, the best way worth doing would be through an extension. I've also found the conflict, which is caused by the TocTree javascript. Uninstalling that extension would also increase the speed of loading and remove the issue I noticed in File:Article without Javascript.png. Should we go ahead and request that anyway, now that all articles have pagebanners? -- torty3 (talk) 03:32, 27 June 2013 (UTC)Reply
We talked about uninstalling the extension earlier. It also impacts talk pages, the Pub and any other page that doesn't use the banner. Not sure if anything has changed since that discussion. -Shaundd (talk) 03:54, 27 June 2013 (UTC)Reply
I don't see a big issue. Talk pages rarely have many subheadings anyway. I say remove it! LtPowers (talk) 11:08, 27 June 2013 (UTC)Reply

Renew discussion? edit

Nothing in this section since June, and no change visible in the TOC display. It is November. Is there a way forward? Or is TOC handling permanently broken? Pashley (talk) 01:41, 5 November 2013 (UTC)Reply

It looks like we have a consensus to remove the TocTree extension so long as doing so doesn't break anything else. Unfortunately, the only way to know for sure is to try it. LtPowers (talk) 20:59, 6 November 2013 (UTC)Reply
Bump! It is now February and we still do not have a fully usable TOC. Pashley (talk) 20:06, 14 February 2014 (UTC)Reply
Do we need a Bugzilla entry to remove TocTree? Powers (talk) 21:54, 15 February 2014 (UTC)Reply
I do not know, but we should do something. As I see it, an important piece of site functionality has now been obviously broken for many months. Pashley (talk) 02:04, 28 March 2014 (UTC)Reply
Bump! It has been more than a year and, as I see it an important piece of site functionality has been badly broken all that time, but apparently nobody cares.
If it were actually impossible to keep the banners and have a properly functioning TOC, I'd say scrap the banners. That would be painful, but in my view it is more important that the site be easily navigable than that it be pretty. I'm certain, though, that it is possible to have both; there are several plausible mechanisms suggested above. Pashley (talk) 15:45, 10 September 2014 (UTC)Reply
I agree it is quite annoying when you cannot navigate directly to the subsections. Would it be technically possible to keep the banner but return the old style TOC in its old place? ϒpsilon (talk) 19:28, 10 September 2014 (UTC)Reply
I think that would be fairly easy to do, just remove NOTOC in the banner code. I doubt it is a good idea, though. We would then have redundant TOCs, one in the banner & one below; that strikes me as both ugly and a waste of screen space. Also, the old TOC had problems such as ruining the formatting of bulleted lists, which introducing banners solved (hooray!). We do not want to bring those back.
My original suggestion was a button to bring up the full TOC. Others have suggested a drop-down list attached to each main heading. Either of those might work & would be better than just putting the old TOC back in. There is discussion above.
The suggestion I like best by far is User:Shaundd's idea, adding subheadings in section banners. I think that is much better both visually and as a user interface than the alternatives. It looks harder to do technically, though. Again, see discussion above. Pashley (talk) 19:57, 10 September 2014 (UTC)Reply
I would not want to loose the banners, this is optically a great addition to the site. Bringing back the full TOC permanently on the site would also be a backward step, however can see the advantage of getting to sub-sections easier. If we could have pull-down in the banner that would be great. Other idea, could we have a floating collapse TOC, say bottom left of the browser window? (guess would have to be a javascript). --Traveler100 (talk) 05:51, 11 September 2014 (UTC)Reply
Do not know if this is technically possible (tried but failed to get two TOCs on one page), but what about as well as the pagebanner toc also a collapse one on the right of the page under banner level with first two lines of text. Mock-up here. Also dded some general text that should help with search engine key word results. --Traveler100 (talk) 05:48, 12 September 2014 (UTC)Reply
I'd support happily either pull-down from the banner TOC items or a second collapsible TOC. Any of these would be a great improvement. However I can't contribute with any technical skills in this area. If we agree on usefulness of such solutions, we should discuss the plan in the pub to get general support, and include this plan into the Roadmap or even better WV wishlist at meta to attract attention of those who can help technically. Danapit (talk) 07:37, 12 September 2014 (UTC)Reply

New banners from fr.wikivoyage edit

Hello all. I'don't know this wiki very well so i hope this is the right place to speak about that. I made a lot of new banners (more than 200) for fr.wikivoyage article. I thinks some of them, could also be added to en.wikivoyage. If someone has time to adapt them .Inkey (talk) 21:55, 26 August 2013 (UTC)Reply

You are in the right place! :) Those banners look great - it would be good if we could somehow incorporate them here. --Nick talk 22:09, 26 August 2013 (UTC)Reply
Great! There are some really excellent ones in there. I have gone through a little over half the list (in the order on the contribs page linked above) and put them into articles here which did not have banners yet (some of the French destinations do not have articles yet so I skipped them). If anyone wants to take over starting from Pontivy banner.jpg and continuing down the list, please vouch for it here so we don't duplicate efforts. Otherwise, I may come back and finish it a little later. Thanks again, Inkey! Texugo (talk) 22:57, 26 August 2013 (UTC)Reply
I'll carry on from there; I'll let you know where I get up to! --Nick talk 23:07, 26 August 2013 (UTC)Reply
I'm going to take a break having just finished the first page. :) --Nick talk 00:49, 27 August 2013 (UTC)Reply
I will start at the bottom of the list. • • • Peter (Southwood) (talk): 06:36, 27 August 2013 (UTC)Reply
Got to the top. Most of the banners which are not used on en: are for articles which don't exist on en: though there are also a few where there is already an alternative in use on en: I have categorized in more detail where I could and changed a few names to make it easier to identify where they can be used. A very nice assortment of banners. • • • Peter (Southwood) (talk): 15:48, 27 August 2013 (UTC)Reply
Whoo Nice relay race ! I will continue to made banner later.In fact, i've got already lots of banners in stock (i worked on all the «A…» banner for fr.wikivoyage), but uploading… is so annoying with derivateFx (not made for batch processing).I will come later with a bunch of banners.
File:BXP135677.jpg
Inkey (talk) 17:50, 27 August 2013 (UTC)Reply
I find derivativeFX very slow at times, and it seems it can't deal with some licences, but it is still faster than doing it manually in most cases. As you say, no good for batches. • • • Peter (Southwood) (talk): 19:23, 27 August 2013 (UTC)Reply

Something like 90 news banners(most are for destination beginning with A).

Integrated up to New Brunswick. • • • Peter (Southwood) (talk): 11:57, 29 August 2013 (UTC)Reply
Up to Morzine now. • • • Peter (Southwood) (talk): 11:22, 31 August 2013 (UTC)Reply
Up to Santa Marta. • • • Peter (Southwood) (talk): 20:50, 1 September 2013 (UTC)Reply
Talking about derivateFx: is it only my impression or was is changed recently? Now I have to fill in all the information (source, author, date, license) again by hand, it's not taken over from the original image anymore. Danapit (talk) 11:15, 31 August 2013 (UTC)Reply
I found it cannot deal with some non-standard formatted pages, and possibly some licenses (particularly some PD licenses), while doing others without any difficulty. This was a few days ago, and may have changed more recently. • • • Peter (Southwood) (talk): 11:25, 31 August 2013 (UTC)Reply
Yes, I also noticed the PD license problem. The change with the new form for filling the information happened 1-2 days ago. Danapit (talk) 11:37, 31 August 2013 (UTC)Reply
It seems to be calling a different upload page from commons. It seems now to be virtually useless for its purpose. Most unfortunate. • • • Peter (Southwood) (talk): 20:12, 1 September 2013 (UTC)Reply

Banners inhibit images and flags edit

Is it the case that the banner template inhibits images and flags from the 'quickbar' template? At present, they don't seem to be appearing for me and I'm not quite sure of the cause. --Nick talk 17:10, 14 September 2013 (UTC)Reply

I think it's the result of changes to the quickbar template that have been discussed for a while. I promise I didn't put any secret code in the banner template to hide other images and flags. :-) -Shaundd (talk) 17:27, 14 September 2013 (UTC)Reply
Whoops! Hadn't seen that! Thanks for the info Shaun - I never suspected you of crimes against quickbars! :) --Nick talk 18:50, 14 September 2013 (UTC)Reply

Disambiguation edit

Am I right in thinking that 'disambig=yes' in the banners replaces the {{otheruses}} template? If so, is it worth using a bot to replace the latter with the former across the site? --Nick talk 17:32, 15 September 2013 (UTC)Reply

It would if we had a strong consensus to start using the banners on dab pages. I think they're excessive, personally. LtPowers (talk) 21:01, 15 September 2013 (UTC)Reply
I'm not sure the 'disambig=yes' option is for the pages themselves, but for articles where another destination of the same name exists (like Manchester). Setting that parameter as yes renders the normal 'other uses' text and places a question mark icon on the banner itself. --Nick talk 22:02, 15 September 2013 (UTC)Reply
Er, yes, sorry about that. I didn't read carefully enough. (Though I fear that parameter name is a bit miselading.) LtPowers (talk) 00:20, 16 September 2013 (UTC)Reply
Yeah, I think it should be "otheruses=". Texugo (talk) 02:23, 16 September 2013 (UTC)Reply
  1. We already have a special banner for dab pages
  2. If we do a bot run, maybe we should change the parameter name at the same time. • • • Peter (Southwood) (talk): 06:03, 16 September 2013 (UTC)Reply

Dab banners edit

I would like to propose that we do not include banner images on disambiguation pages. The enormous block of bright blue distracts from the important part of the page: the links to real articles. We want users to get to their correct article ASAP, not have to search for the right link amidst bells and whistles. LtPowers (talk) 21:01, 4 October 2013 (UTC)Reply

Example of a bad banner edit

Can anyone find a good image to replace the "bad banner" example under #How to make a quality banner? Obviously a red link is the worst kind of banner there could possibly be, but I don't think that was the type of example intended... Texugo (talk) 11:50, 19 September 2013 (UTC)Reply

How about File:NewYorkUpstateTrainBanner.JPG? LtPowers (talk) 12:53, 19 September 2013 (UTC)Reply
I'd say that's about right. Shall we change it? Texugo (talk) 13:06, 19 September 2013 (UTC)Reply

A handful of country articles which lack custom banners edit

According to a quick catscan, there are only 11 country articles left which don't have custom banners, if anyone wants a quick and satisfying little project:

Texugo (talk) 23:19, 20 September 2013 (UTC)Reply

All done, • • • Peter (Southwood) (talk): 14:56, 28 September 2013 (UTC)Reply
Woohoo! Thanks guys! Texugo (talk) 15:19, 28 September 2013 (UTC)Reply
Nice! Also because it made me click on Niue, a "country" I'd never heard of with a name that -as I know now- means as much as Look! A Coconut!. Great stuff :-)) JuliasTravels (talk) 15:24, 28 September 2013 (UTC)Reply

A handful of star articles lacking a custom banner edit

A bit of a surprise...

LtPowers might want to do the WDW banners. • • • Peter (Southwood) (talk): 16:55, 28 September 2013 (UTC)Reply

All right, all right. I've been putting it off because I can't decide whether including the Tree of Life on the Animal Kingdom article is kosher or not. (Technically it's a copyrighted sculpture. But then we have Chicago/Loop which also shows a copyrighted sculpture, so...) LtPowers (talk) 23:39, 28 September 2013 (UTC)Reply
Er, well, it used to, at least. Also, Nicholasjf21 did such a good job with File:WDW Page Banner.jpg and File:Epcot Page Banner.jpg I don't know if I can replicate his success. =) LtPowers (talk) 23:41, 28 September 2013 (UTC)Reply
I'm sure you can make banners far better than the ones I've made, but thanks for the compliment! =) If you'd like me to have a go, I'm more than happy to try and do something similar for the other parks? --Nick talk 00:21, 29 September 2013 (UTC)Reply
I'm a bit busy these days so have at it, as far as I'm concerned. =) LtPowers (talk) 15:20, 29 September 2013 (UTC)Reply

Guide articles lacking a custom banner edit

And here's a link to the list of guide articles which don't have a banner yet, 318 at the time of this posting. Texugo (talk) 17:25, 28 September 2013 (UTC)Reply

Down to 303 now. (No thanks to me) Texugo (talk) 18:18, 1 October 2013 (UTC)Reply
I have done a few. Some destinations don't have any suitable images on commons, and trying to find acceptably licensed images with Google is beyond me. • • • Peter (Southwood) (talk): 08:20, 2 October 2013 (UTC)Reply
This is an interesting project for me, as I enjoy searching for images, also outside of commons. However, the progress will be slow, I have urgent matters outside WV these days. Danapit (talk) 08:36, 2 October 2013 (UTC)Reply
Tip on looking for images. Try FIST. Change site to wikivoyage, scan from category to article and enter article name in box, also change List option at bottom to all. --Traveler100 (talk) 08:46, 2 October 2013 (UTC)Reply
Sorry, I don't understand "scan from category to article and enter article name in box," could you clarify? • • • Peter (Southwood) (talk): 12:16, 2 October 2013 (UTC)Reply
I was trying to understand, but I don't get it either. Danapit (talk) 14:16, 2 October 2013 (UTC)Reply
Try this Free Image Search Tool Traveler100 (talk) 14:59, 2 October 2013 (UTC)Reply
Thank you, it works for me now. I don't see much advantage over searching for free images with google or directly at Flickr. Maybe I am wrong though and can't use the whole potential of the program. Danapit (talk) 15:14, 2 October 2013 (UTC)Reply
Down to 239. Texugo (talk) 14:21, 6 November 2013 (UTC)Reply

Interesting use of our banners over on Commons edit

It seems the craze for page banners is spreading rapidly - this looks interesting! --Nick talk 13:52, 14 October 2013 (UTC)Reply

here's the archive link for posterity: Commons:Village_pump/Archive/2013/10#A_tool_to_make_Commons.27_categories_sexier -- also, this is very cool :) -- Phoebe (talk) 03:32, 6 February 2014 (UTC)Reply
There's this too over on WP! :) --Nick talk 03:39, 6 February 2014 (UTC)Reply

UNESCO icon in banners edit

Swept in from the pub

French WV came up with a new UNESCO icon incorporated in page banners. IMO it is a great idea worth considering at English WV, as well. An example is here. --Danapit (talk) 20:37, 10 September 2013 (UTC)Reply

Nice idea indeed. Nicolas1981 (talk) 05:20, 11 September 2013 (UTC)Reply
I like that too. It's definitely worth considering. Nick1372 (talk) 10:56, 12 September 2013 (UTC)Reply
Just out of curiosity, how many in-banner icons do we currently have, and what is the maximum number of them that can appear on one article? I like the idea somewhat, but I worry that the bigger the pile of icons in up in the corner, the uglier it will be... Texugo (talk) 16:56, 12 September 2013 (UTC)Reply
If I understand correctly (see Template:Pagebanner), a destination can have now up to two icons: 1) star and 2) one of DotM/OtBP/FTT. Then we have the geo icon above the banner. --Danapit (talk) 12:37, 14 September 2013 (UTC)Reply
There's a third as well - if you set 'disambig=yes', the banner replaces the usual disambiguation template and features a question mark icon. See it in action here. --Nick talk 13:36, 14 September 2013 (UTC)Reply
How is the disambig icon used? Could have all 3 icons for example at Santa_Fe_(New_Mexico) or Washington,_D.C.? Danapit (talk) 14:02, 14 September 2013 (UTC)Reply
I think it's possible that you could have them all in use at once, yes, but such occasions would be very rare. As far as I'm aware, it's just used as a replacement for the old template, though it doesn't seem to have been done en masse by a bot for some reason. --Nick talk 14:15, 14 September 2013 (UTC)Reply

This discussion kind of died off, but it is a great idea. Any objections to me implementing it? It's a fairly minor change that won't have any immediate ramifications. If we add a category, it might also help us keep track of articles that describe worth heritage destinations as part of the expedition. James Atalk 09:35, 4 November 2013 (UTC)Reply

Since there hasn't been any objection raised, and there appears to be support, I'd say go for it. -- Ryan • (talk) • 15:44, 4 November 2013 (UTC)Reply
Thanks for arranging this. For the actual implementation in banners we might use some kind of table at Talk:UNESCO_World_Heritage_List to see which countries have been done already. Danapit (talk) 09:28, 6 November 2013 (UTC)Reply

Just a detail to adding the icons: in case we don't have an article for the actual UNESCO destination, should the icon be added to the region article, when it mentions the UNESCO destination? Example, UNESCO sites Monasteries of Haghpat and Sanahin in Armenia don't have an article, but are mentioned in Northern Armenia. I would say NO. Danapit (talk) 10:21, 6 November 2013 (UTC)Reply

It's a difficult one. Are the monasteries in towns, or just the middle of nowhere? I had a similar issue with the first UNESCO site on the list: Al Qal'a of Beni Hammad in Algeria. It is basically in the middle of nowhere. So, do we:
I'm starting to think the third option is the best in some cases. What do others think? James Atalk 11:56, 6 November 2013 (UTC)Reply
If you were to visit it, is there anywhere you might logically stay the night besides M'Sila? Texugo (talk) 12:13, 6 November 2013 (UTC)Reply
Danapit, the Monasteries of Haghpat and Sanahin are covered in Alaverdi, about 6 km away, along with several similar sites. I'm not sure they would sustain their own article. Texugo (talk) 12:19, 6 November 2013 (UTC)Reply
I don't even think you'd stay in M'Sila, as it seems there's nothing there for tourists at all, although I'm no expert on the area. Another example is Jam. That's just a ruined minaret in the absolute middle of nowhere, and there's no hope of filling out any of the other sections apart from Get in. So that's a violation of the 'Can you sleep there' thumb rule, but is there an alternative? At the end of the day, we're trying to do what's best for the traveller, and sending them on wild goose hunts looking for where certain monuments are described might not be of great help. James Atalk 12:28, 6 November 2013 (UTC)Reply
Well, redirects can take care of that part pretty easily. I'd say that sites not complex enough to make much of an article and with no place to stay should be covered in the article for the place a tourist is most likely to be visiting from, i.e., where the tourist will likely stay the night before/after the visit. Then we create appropriate redirects so that the information can be found more easily. Texugo (talk) 12:46, 6 November 2013 (UTC)Reply
I can see that working in some cases, but what about, say, Jam. The article mentions it's a common stopover on the way from Kabul to Herat by road, so you could assume the few tourists that visit would've slept in Kabul. Are we really going to write about the Minaret of Jam in the Kabul article, which is 595km/9 hours away? James Atalk 12:55, 6 November 2013 (UTC)Reply
I would imagine that with pop. 15,000, Chaghcharan should probably get an article though and it could be covered there. Of course, all of this has to be on a case-by-case basis, but we've always tried to cover rural attractions in the nearest articles whenever possible, and with redirects, it nearly always works out somehow. Texugo (talk) 13:12, 6 November 2013 (UTC)Reply
Fair enough. I could see that setup working. Would it go in the See or Go next section? I think it would work better as its own header under Go next with logistical and relevant info, while keeping See just for attractions actually within the town limits. Although I don't believe that is the current process. James Atalk 13:22, 6 November 2013 (UTC)Reply
Texugo, thanks for pointing to Alaverdi! Otherwise I would like to avoid adding icons to region articles. Instead, either we should create own articles if there is a chance of staying over night or describe the sites in the nearest town or the usual place where the tourists would stay. Off course, often tourists stay in capitals and make day trips to UNESCO sites. But linking Jam to Kabul doesn't seem right. Generally, doesn't every UNESCO site deserve own article? There must be at least a B&B nearby ;)Danapit (talk) 13:21, 6 November 2013 (UTC)Reply
Well, I'm not sure every UNESCO site deserves a separate article. After all, many of them are within sizeable cities. And how much could there be to say about a single isolated minaret? Texugo (talk) 13:32, 6 November 2013 (UTC)Reply
James, if i remember correctly, we used to put things like that in Go next (Get out, at the time), but it seems like we have shifted toward putting stuff like that in See now. I'm not sure where that discussion is, but I do tend to agree with you. Texugo (talk) 13:33, 6 November 2013 (UTC)Reply
(edit conflict x2) Well I'm flabbergasted. I just read an old 2007 Lonely Planet PDF guide I had on Afghanistan and it appears there is/was a guesthouse right next to the Minaret!! There is also a village, Garmao, 15km away which has a guesthouse or two. So I guess things aren't always what they seem :P And LP managed to somehow squeeze 3/4 of a page out of the Minaret. If anyone's curious/wants to expand our article, I'm happy to forward the relevant pages by email. James Atalk 13:41, 6 November 2013 (UTC)Reply
The progress of icon implementation (and other useful parameters) can be followed now at Wikivoyage:World_Heritage_Expedition/Progress_tables. Danapit (talk) 17:30, 8 November 2013 (UTC)Reply

Printing pages with banners edit

I have tried several different browsers, and different printers and have not been able to get the banner to print when I print a page with a banner - either on paper or as a pdf. Is this an intentional feature? AlasdairW (talk) 22:17, 5 November 2013 (UTC)Reply

The same with me. I don't know if it's a feature or a bug though. Danapit (talk) 10:28, 6 November 2013 (UTC)Reply
It seems that Template:Pagebanner is enclosed in <div class="noprint">. But does it print a page title at all? Because if it doesn't that may be something to be fixed. Texugo (talk) 12:09, 6 November 2013 (UTC)Reply
If I print using the browser print, or the "Printable Version" link at the left, there is no title - but the breadcrumbs are printed so the title can be seen, but not at a glance. The "Download as PDF" link on the left does give a PDF with a properly formatted title, but no banner. I think that banners should print, and I have wanted to print articles specifically to show the banner to people. AlasdairW (talk) 23:05, 6 November 2013 (UTC)Reply
It would be good if users had the option to print our guides with or without photos, as sometimes people want to save ink and only need the content. Is that possible? James Atalk 00:22, 7 November 2013 (UTC)Reply

Oops... edit

Swept in from the pub

The pagebanner for Syracuse (New York) defaults to the image for the city of the same name in Sicily. How does one go about changing that? -- AndreCarrotflower (talk) 20:01, 29 October 2013 (UTC)Reply

Fixed. Someone added the Italian banner to the wrong wikidata item. Now that I removed it, it has no default. Texugo (talk) 20:05, 29 October 2013 (UTC)Reply
That banner was added because it's on fr:Syracuse, which was incorrectly associated with the English and Dutch articles on the New York city, presumably even before the interwiki links were migrated to Wikidata. The correct solution is to move the banner image definition, and the French Wikivoyage link, to the correct Wikidata item. (As it turns out, that banner is already on the Syracuse, Sicily Wikidata item, but keep it mind for future reference. And the French article link still needed to be moved, which I've done.) LtPowers (talk) 21:55, 30 October 2013 (UTC)Reply

Mobile banners edit

Dropping a note here about the updated mobile situation from User:Jdlrobson. See MediaWiki_talk:Mobile.css#Template:Pagebanner_on_mobile. Looks really nice, except for the increased kilobytes of course. What do others think? -- torty3 (talk) 01:42, 19 November 2013 (UTC)Reply

I don't really use this site on a mobile device, but providing someone can confirm that everything works as expected then I don't see any reason not to enable banners for mobile. -- Ryan • (talk) • 02:50, 19 November 2013 (UTC)Reply
I think it would be a nice idea as well - I'm all for it! :) --Nick talk 02:51, 19 November 2013 (UTC)Reply

odd behaviour on page edit

When I display Montérégie I get a wrong proportion image Lac Davignon Panorama.jpg however when I go to edit the page the pagebanner template is the default one. Can anyone explain this? --Traveler100 (talk) 06:59, 26 November 2013 (UTC)Reply

This is a relatively new feature, when you have default banner and at the same time wikidata contains Wikivoyage banner record, it shows it automatically. Most of the time it works fine and it allows sharing banners between language versions, but it can cause this kind of problem. I was trying to address it before, because I have found several cases like this by coincidence. We have to crop the banner and correct the wikidata record. I also prefer to set the banner name locally. Danapit (talk) 07:10, 26 November 2013 (UTC)Reply

Could someone explain to me how this wikidata works? Very confusing method. Is this why we have a problem at Addis Ababa. --Traveler100 (talk) 19:31, 10 December 2013 (UTC)Reply
No, Addis Ababa banner was removed from Commons due to copyright violation. I replaced it with different one now. Jjtkk (talk) 21:44, 10 December 2013 (UTC)Reply
So how do we get article to refer to the default banner if the one on wikidata is no longer there? And how do I see the file name that has been delete? For example with Beijing/Haidian. --Traveler100 (talk) 18:54, 12 December 2013 (UTC)Reply
Can we remove the use of wikidata? No one will explain how this works to me and I cannot fix broken pages (e.g. Saint-Louis). --Traveler100 (talk) 06:20, 19 April 2014 (UTC)Reply
Saint-Louis is fixed now. What you do is click on "Data item" in the Tools menu (left sidebar) to view the wikidata page for that topic. Scroll down until you find a box called "Wikivoyage banner", click "edit", then click "remove".
Thatotherpersontalkcontribs 07:12, 19 April 2014 (UTC)Reply
Thanks for the explanation of how it works. --Traveler100 (talk) 08:13, 19 April 2014 (UTC)Reply

Crop tool edit

So next time when somebody wants to make a page banner, consider using commons:Commons:CropTool. --Saqib (talk) 12:25, 15 December 2013 (UTC)Reply

Saqib, this looks useful, indeed. I looked briefly, and didn't find two particular functions that would be quite important: 1) Does the tool allow to crop into a given aspect ratio? 2) Can I rotate by a few degrees (often the pictures don't have horizontal horizons, etc.)? Anyway, this might be something we could ask the developers. Danapit (talk) 08:56, 19 December 2013 (UTC)Reply
Sorry for late reply Dana. Unfortunately, this crop tool is not useful for us since the cropping into a given aspect ratio is not possible. Sorry! --Saqib (talk) 20:03, 12 January 2014 (UTC)Reply
It is possible to preset a aratio for cropping now! Seems like CropTool became an alternative now for quick and dirty cropping. We should mention it as an option at the Expedition page, what do you think? Danapit (talk) 07:55, 12 October 2015 (UTC)Reply
I have added the information about CropTool (and removed information about discontinued derivativeFX) to the expedition page. Please feel free to rephrase anything that soounds weird or is unclear. Danapit (talk) 17:48, 21 October 2015 (UTC)Reply

State of derivateFx? edit

I very rarely do banners, but for the last few months derivateFx does not seems to be usable, I have to fill all info again.

I don't know much about the matter, but could someone contact the developer about this problem? Otherwise it will hold back banner development. Thanks! Nicolas1981 (talk) 10:27, 1 January 2014 (UTC)Reply

Hi Nick, there was some brief discussion about the matter in another thread. Others already contacted the developer. As far as I understand from his reply, the tool can not be fixed easily, have a look here. I used to like using the tool a lot, as well. Now I upload from scratch and use derived from template. The other info must be entered manually though. Sadly, I don't know any other easy approach. --Danapit (talk) 13:29, 1 January 2014 (UTC)Reply

Convention for country level banners edit

There has been a discussion on Talk:United_States_of_America#Page_banner about whether iconography (as in a notable landmark pictured as a silhouette) should be the preferred way of representing countries. I browsed some other countries such as Mexico, Brazil, Finland and France. The general WV convention appears to be some form of landscape and actually the United States is the only place I see the silhouette employed.

I am not an expert in aesthetics, therefore I won't try and describe the issue in greater depth. Andrewssi2 (talk) 02:56, 6 January 2014 (UTC)Reply

I thought I had made clear that due to the size and importance of different countries, that each county needs an individualized approach. I don't see any reason to assume that because we did something one way on Mexico that we have to do it the same way on the USA article. Powers (talk) 19:41, 6 January 2014 (UTC)Reply
Many country banners are landscape, but others are not. For smaller countries landscape can work well, as it can be typical of what you might see in most parts of the country (e.g. Wales). But for larger countries other images may be more appropriate like India and China. The landscape of Alaska and Florida have little in common. I am not that taken with the silhouette though, and note that most artistic images of the statue has some texture (see Commons:Category:Statue of Liberty in art), and the statue maybe is too "vertical" for a banner. AlasdairW (talk) 23:33, 6 January 2014 (UTC)Reply
I am with User:LtPowers here - we really don't need any convention here. For every country, something different would be the most appropriate, let's use common sense and talk pages and don't waste time establishing unnecessary rules. PrinceGloria (talk) 06:27, 7 January 2014 (UTC)Reply
Just asking the question :) Andrewssi2 (talk) 08:44, 7 January 2014 (UTC)Reply
I don't think we need hard and fast rules here either, but it is worth pointing out that the silhouette thing is being presented as a possible solution for at least one instance of a situation which is shared by many larger countries, but like Andrewssi2 and AlasdairW above and others elsewhere, I don't buy it. It just strikes me as a photo that is not lit well enough to be a good; it's too concrete to suggest that it's meant as an abstract representation. Texugo (talk) 13:20, 7 January 2014 (UTC)Reply
Abstraction comes in different degrees. Aiming for a slight amount of abstraction seems better than eschewing it entirely. Powers (talk) 18:54, 7 January 2014 (UTC)Reply

Tip: Find all big images in a Commons category edit

Here is an URL that finds all big images in a Commons category:

http://tools.wmflabs.org/catscan2/catscan2.php?language=commons&project=wikimedia&categories=Quality_images_of_Berlin&ns%5B6%5D=1&sortby=filesize&sortorder=descending&ext_image_data=1&doit=1

Replace "Berlin" by any other destination. No thumbnails unfortunately. Nicolas1981 (talk) 03:39, 20 January 2014 (UTC)Reply

Mobile edit

Just to let you know, I've now enabled pagebanners on the WV mobile site, following (and slightly tweaking) the suggestions of Jdlrobson and Mark. To see the full saga, you can take a look at my stream of consciousness here. :) --Nick talk 13:47, 5 February 2014 (UTC)Reply

Yeyyy! All my pages suddenly came alive! I still think it may need tweaking a little more. The contrast between page actions and background is sometimes a little off. But looks so much better! Exciting stuff! Nice consciousness! ;) Jdlrobson (talk) 15:55, 5 February 2014 (UTC)Reply

Jdlrobson, Nicholasjf21: congratulations and thanks, it looks great! -- Phoebe (talk) 03:25, 6 February 2014 (UTC)Reply
That's rather brilliant, even if users on limited-band connections and roaming may not appreciate that as much. I am also forseeing a slight issue - while most banners are made with the assumption that the bottom part will be covered by the TOC-box in the web browser and the top will shine, in the mobile version it is the upper part that gets covered and the bottom exposed. Some banners (e.g. for Munich) look rather weird in this setup. Did you consider (sorry if this IS in the stream of consciousness I have so conveniently decided not to have time to follow) moving the title banner and icons to the bottom of the banner, and/or placing them side-by-side whenever possible? PrinceGloria (talk) 04:43, 6 February 2014 (UTC)Reply
From what I understand, mobile users were downloading the banner anyway; they just couldn't see it. Powers (talk) 18:15, 6 February 2014 (UTC)Reply
In response to PrinceGloria's question, I didn't move the title and icons to the bottom as I didn't want to make it look too different from the default without further consultation and, also, we will never find a single position that works for all banners unfortunately. I think we'd struggle to place the article title and action icons next to each other as, on pages with longer titles, the two will run over each other. We could perhaps hide the image icon however as I think we lock that on all pages. --Nick talk 23:25, 6 February 2014 (UTC)Reply

Cleaner banners edit

 
London banner with straight lined boxes.

Hi! How would everyone feel about removing the curved elements on our banners (i.e. the place name and icon box). At present, I think it makes the top of the page look a little cluttered and it would be nice to see a more streamlined version that fits in with the other straight lines that populate the site. --Nick talk 03:57, 25 February 2014 (UTC)Reply

I wouldn't mind doing it to the notifications icon either... --Nick talk 03:59, 25 February 2014 (UTC)Reply
My personal preference would be to keep the name (London in this example) and remove the icon completely. It is confusing to add the visual element that can mean 'previous destination of the month' or 'UNESCO site'. Andrewssi2 (talk) 05:09, 25 February 2014 (UTC)Reply
Curved box is infinitely better than sharp-edged box, there is no contest. I firmly object to changing the round edged box. I wholeheartedly support removing the "previous destination of the month", who cares - certainly not the casual reader. We can keep that info in the talk page for reference. PrinceGloria (talk) 05:56, 25 February 2014 (UTC)Reply
I think I agree with PrinceGloria on excising the "previous x-type of feature" boxes from articles and putting the notice on the talk page, instead. It's a convenience to editors looking for new DotM, etc., to see the notice right there at the top of the page, but this is not a meta site mainly for the benefit of its own editors but a site for the benefit of travelers. But what about the UNESCO symbols? Can they be put as a bolded notice below the banner instead of a symbol within the banner? Ikan Kekek (talk) 06:06, 25 February 2014 (UTC)Reply
I like the icons as a way of indicating that the article is special in some way - higher quality, world heritage site, etc - but it doesn't necessarily need to be on the banner if someone else has a better place for it. I think it should be near the top of the article though, and not on the talk page. -- Ryan • (talk) • 06:57, 25 February 2014 (UTC)Reply
My suggestion, then, would be to put it as a bolded announcement directly below the banner, for any kind of distinction, including UNESCO. I think it's probably best to keep the name in the pagebanner, but the banner would look nicer without the name, so to those of you who want to make the banner just a photo with nothing else in it (only Nick so far?), where do you propose to put the place name? Just in the little breadcrumb trail? Ikan Kekek (talk) 07:07, 25 February 2014 (UTC)Reply
Hi! Sorry, my first post might have been a bit confusing. I'm not advocating removing the place name by any means - just to changing the box it's in to one with corners rather than rounded edges as I believe it looks cleaner and fresher (per the screenshot), whilst in-keeping with the other straight lines that are in use across the rest of the site (like in our loo and the MW interface). I'm sorry if I caused any confusion! --Nick talk 10:37, 25 February 2014 (UTC)Reply
OK, I understand. However, unless I'm missing something, the differences in the shape of the nameplates are so small that they almost seem like optical illusions. If I look very carefully, I can see that the edges of the nameplate currently have tiny diagonals or perhaps curves instead of right angles, whereas your mockup has only 4 sides with right angles between each pair of sides. What's much more noticeable is that your nameplate doesn't overlap with the building to the left, whereas the banner in the London article does (which makes yours better). I also see that your table of contents doesn't go all the way from left to right along the bottom of the pagebanner, whereas the TOC in the article does, and for visibility's sake, I'd give the nod to the existing format in this respect. Ikan Kekek (talk) 10:56, 25 February 2014 (UTC)Reply
I think that's probably a result of different screen resolutions rather than pagebanner itself. As the banners resize dynamically, I imagine almost everyone's display will look slightly different. --Nick talk 11:15, 25 February 2014 (UTC)Reply
We could just bump those icons above the banner onto the same line as the breadcrumbs. The map icon has been sitting up there for a while without bothering anyone.
Thatotherpersontalkcontribs 11:19, 25 February 2014 (UTC)Reply
(2x edit conflict) Ikan, the apparent differences in overlapping the bridge and the TOC going all the way across are simply because the screenshot above was taken on a larger screen size than the one you see the page with. Like Ryan, I don't see a particular need for a change here. And I don't like the idea of a bolded announcement just under the banner because there will be plenty of cases where it would start to look like a stack of things at the lead, in combination with the banner plus the various hatnotes and style/merge tags or region/district discussion tags that sometimes occupy that space. Texugo (talk) 11:21, 25 February 2014 (UTC)Reply
My preference would be to keep the curved boxes and icons because they looks pretty to me. Btw, I just realised that boxes are curved in IE7, article and icon boxes background is black and TOC links not working as well. --Saqib (talk) 11:47, 25 February 2014 (UTC)Reply
I think the sharp-edged version of the name box Nicholas suggests looks a bit too harsh and prefer the current one. When it comes to the icons I have no strong opinion whether to keep or discard them. It would be good to hear the opinion of people who've come up with the icon idea and implemented it before removing the icons, though. ϒpsilon (talk) 14:58, 25 February 2014 (UTC)Reply
I'd like to keep both rounded edges and icons the way they are. Danapit (talk) 09:08, 26 February 2014 (UTC)Reply

edit

Who runs the bot to transfer banners to wikidata, please? There are some 200 items on en wv by now... Danapit (talk) 09:12, 26 February 2014 (UTC)Reply

I believe it was User:Nicolas1981 who was doing it before. Texugo (talk) 11:13, 26 February 2014 (UTC)Reply
I just did what I always do when this happens: I asked Kizar :-) I also documented that "procedure" at the end of the present article, so that anyone can do it directly. Nicolas1981 (talk) 01:43, 28 February 2014 (UTC)Reply
Banners transferred! :-) Nicolas1981 (talk) 03:14, 2 March 2014 (UTC)Reply
Hello, I tried to contact user Kizar on Wikidata to run xyr bot for transferring the banners to wikidata, but got no reply. He doesn't seem to be very active lately. Is there any plan B? Nicolas, Texugo, any idea? --Danapit (talk) 13:22, 24 January 2015 (UTC)Reply
Unfortunately, I haven't a clue when it comes to this type of bot. Texugo (talk) 13:32, 24 January 2015 (UTC)Reply
Me neither... I don't know if it can only be run by one person (the owner) or somebody else, as well. --Danapit (talk) 13:34, 24 January 2015 (UTC)Reply
I contacted Kizar at his/her home wiki. Is the source of the bot available somewhere? If not we might have to re-implement it (I am busy with other scripts so no time unfortunately) Nicolas1981 (talk) 08:35, 25 January 2015 (UTC)Reply
So did I a while ago... We could try and ask around about the bot in the wikidata pub if we don't get any reply. --Danapit (talk) 10:58, 25 January 2015 (UTC)Reply
Seems like the user might not be active anymore. Perhaps we need to find someone to develop another bot doing the same job. How can we do it? Danapit (talk) 14:01, 17 February 2015 (UTC)Reply

Banners and the Typography Refresh edit

One of the Beta Features WMF is testing is called "Typography Refresh". You can enable it at Special:Preferences#mw-prefsection-betafeatures, but if you do so, it screws up the display of our horizontal ToC on the banners. Powers (talk) 13:47, 3 March 2014 (UTC)Reply

Or maybe it's just me? Anyone else seeing this? You can always switch the Typography Refresh setting back. Powers (talk) 13:56, 6 March 2014 (UTC)Reply
I can confirm, Powers. It does screw up the TOC. At the bottom left part of the banner a small gray rectangle appears and the TOC doesn't have the shaded background.--Danapit (talk) 19:01, 6 March 2014 (UTC)Reply
After taking a quick look through the wikitech news, seems like the WMF is going to un-beta the Typography Refresh on the 3rd of April, which makes any fixing of this to be essential. Anybody to dig through the CSS? -- torty3 (talk) 04:20, 30 March 2014 (UTC)Reply
This change should partially resolve the issue. To get rid of the extra gray box below the TOC, once the typography refresh goes live we'll need to modify MediaWiki:Common.css to change the following style:
.topbanner-toc {
	position: absolute;
	bottom: 6px;
	left: 0;
	z-index: 3;
	width:100%;
}
...to:
.topbanner-toc {
	position: absolute;
	bottom: 0.8em;
	left: 0;
	z-index: 3;
	width:100%;
}
-- Ryan • (talk) • 16:05, 30 March 2014 (UTC)Reply

Changing shadow box opacity edit

See Talk:Main Page#Shadow box opacity test page: User:Wrh2/Sandbox for a relevant discussion about potentially changing page banner shadow box opacity. -- Ryan • (talk) • 23:44, 27 March 2014 (UTC)Reply

Renew TOC discussion edit

The first section above, #Add_a_.22full_TOC.22_button.3F, raises what I think is an important problem; the banners improve some things, but they break others. The horizontal table of contents is a large improvement visually and it works very well for smaller articles with a simple heading structure, but it fails miserably for more complex articles since it denies access to lower-level headings.

This was originally raised in May last year, but has not been fixed yet. Am I alone in thinking it is important?

My preferred solution would be the one described at #Per-section_index above, because it does not complicate the banners and is visually consistent with them, maintaining the horizontal theme. Pashley (talk) 13:06, 2 April 2014 (UTC)Reply

Personally, I have never found this issue to be of the utmost importance. Yes, technically it "denies access" to lowest-level headers, but I would venture that it is far less than 1% of our sections where regular section headers won't show you all the subsections on the screen at the same time anyway, and in the cases when they don't, a half-scroll of the mouse will usually suffice to get you to the rest without any significant hunting. Plus, since almost all of our subsections are standardized (By car/By bus/etc.) there is very rarely an enormous disadvantage in not being able to "explore the TOC" once you realize that pretty much all our pages are structured the same way, so I don't see it as a highly popular and oft-used feature. That said, I would fully support it if someone could create automatic drop-down menus from the banner at the top, like Torty3's mock-up, but the #Per-section_index idea has some problems, not least of which is the technical impossibility at this time of creating and manipulating multiple TOC instances in an automated manner, but almost as serious to me would be the bizarre visual stripe effect that turning headers into horizontal bars would have on the 95+% of our articles which have sections with little or no content, and its consequence of emphasizing those empty sections by highlighting them with multiple bars in a row. Texugo (talk) 13:26, 2 April 2014 (UTC)Reply
If we did find a way to do per-section TOC bars it would certainly be necessary to automate them since doing it manually would be a maintenance disaster. Given that, it should not be hard to prevent them appearing unless there are (two or more?) subheadings. On the other hand, that would make the section headings look quite different in the two situations, which might be fairly ugly.
There is likely a way around this — perhaps just eliminating the black bar? — but I am not certain what it might be. Pashley (talk) 16:11, 2 April 2014 (UTC)Reply
Don't think I could support any solution where some headers look different from others. Anyway, aren't we a lot closer to being able to do dropdown menus than we are for per-section TOCs? Texugo (talk) 17:21, 2 April 2014 (UTC)Reply
Without knowing more about the way TOCs are generated, yes. Regarding the changing headers, I think the better solution would be to utilize a simple navigation strip below the header, including it only where necessary (not just any section with subsections but only where it's deemed essential for navigation); that means that headers will all look the same (as they should) as well as remaining harmonized with other WMF wikis. If we take that route, the number of instances may be small enough to be worth doing manually. Powers (talk) 14:27, 3 April 2014 (UTC)Reply

Rotating banners for articles? edit

Over at Talk:Lille and some other pages we have examples of equally good banners that we could use for some articles. I guess it would be good to discuss if we can use the rotating banner feature for articles as well. I cannot find a reason why we shouldn't, but perhaps somebody can. Do excuse me if this was discussed and I missed it. PrinceGloria (talk) 22:02, 6 April 2014 (UTC)Reply

I guess my reaction is that it could be a good thing to do, though it's more important for good pagebanners to be created for articles that don't have any. One possible down side is if the images within the article are chosen with the image in the pagebanner in mind, but that hardly seems like a crippling blow. Ikan Kekek (talk) 22:19, 6 April 2014 (UTC)Reply
If we're referring to the current mechanism used on the Main Page, I'd probably be against such a move. Whilst it's undoubtedly attractive to have a rotating feature, the JavaScript we use is somewhat demanding and implementing it might make mobile compatibility an issue. Unless there is another way to rotate the banners other than an 'action=purge' command which only does so when the page is edited, I'd advise against this. As Ikan says, for the moment, we should focus on filling the large gaps we currently have in pagebanner imagery. --Nick talk 22:34, 6 April 2014 (UTC)Reply
Would captions keep in sync with the rotating banner? It also might be a little off putting to the casual reader to have a page look different from yesterday if the content has not changed. AlasdairW (talk) 22:39, 6 April 2014 (UTC)Reply
I agree that a rotating banner would be off putting. It is completely appropriate for the main page with multiple destinations but not for a specific destination. Andrewssi2 (talk) 23:09, 6 April 2014 (UTC)Reply
Part of the purpose of the banners is visual identification. That goes out the window if we're continually changing them. Powers (talk) 00:41, 7 April 2014 (UTC)Reply
Oh, I missed the part about the banner being so important for identification. Many sites that use stuff akin to our banners do use features similar to our rotating banner feature. Besides, we do change banners on the fly, when we decide on the talk page there is a new, better banner idea. If the user visits the article only once, they'd have no chance of noticing. If they happen to visit twice, they'd be just as confused. If they visit multiple times, which is likely, they will surely find out how the feature works quickly - I saw it used elsewhere, as I said, and never did it confuse me.
I do see that there may be technical issues though. Nick, could you expand in more detail? PrinceGloria (talk) 04:13, 7 April 2014 (UTC)Reply
The JavaScript used for the carousel feature is more work-intensive for users' systems than the JS for the banners at present. By making such a change, we make all of our pages slower to load. At present, the mobile version of the Main Page does not feature any images, whilst our articles have their banners intact (compare https://en.m.wikivoyage.org/wiki/Main_Page and https://en.m.wikivoyage.org/wiki/England). There is also the issue of what to do with the associated Wikidata class and how many is too many. I think we probably need to just decide on a banner and go with it - we can always change it later on anyway. --Nick talk 15:35, 7 April 2014 (UTC)Reply
Just a clarification - I do not mean a carousel like in the main page, but rather displaying randomly one of the few given banners, like we do atop the main page of this Expedition. Is this just as resource-intensive and impossible to implement as the carousel? I also believe it is not impossible to let more than one image be designated as a Wikivoyage banner in Wikidata. The only question is how and where that data is used. Finally, I think there are destinations where we will have more than one brilliant banner idea because they are quite popular and picturesque, but I don't believe we will have too many of them, or more than two-three equally brilliant banners for each. Just as well we will continue to have destinations for which it will be hard to find any banner-suitable imagery at all. It would simply be a shame to lose any of the brilliant banners just because only one can be THE one. PrinceGloria (talk) 16:03, 7 April 2014 (UTC)Reply
If you use the random image method (as at the top of this page), then there shouldn't be any issue with resource-intensive JS. That said, as far as I'm aware, a new image is only selected when the page is purged, which happens most commonly at the same time as editing. As such, onp ages that aren't edited very regularly, it could be many days between changes. --Nick talk 16:29, 7 April 2014 (UTC)Reply
I don't think this would be a problem - if anything, the voices above were concerned if the banner changed too often. I also believe most of the destinations which stand a chance of getting more than one brilliant banner are those which will see most frequent edits, so the feature won't be left unused. PrinceGloria (talk) 17:16, 7 April 2014 (UTC)Reply
Yes, some of our articles change banners occasionally as new, better ones are found; presumably the situation will stabilize as they're rolled out. But given the relative prominence of the images over the title of the article, I think maintaining relatively consistent imagery is important to visually signify to readers the identity of the article they're reading. Powers (talk) 19:58, 7 April 2014 (UTC)Reply
It's also worth pointing out that sometimes an important site is depicted in the banner image and nowhere else on the page (to avoid redundancy); this is difficult to maintain if the banner image is unpredictable. Powers (talk) 20:00, 7 April 2014 (UTC)Reply
I find the latter situation to be wrong. Very few landmarks/POIs lend themselves well to presentation in the 7:1 banner form. I find those being impressions, not depictions. In the articles I edit, I make a point of including a different, more "matter of fact" picture of same landmark/place in the appropriate section, if a particular one is indeed in the banner. I just avoid repeating the same or similar view in both banner and one of the pictures in the article.
Again, I don't think users will have issues identifying where they are given that the pages still have prominent titles, and there are many travel sites using "rotating" imagery. I never felt lost using them. And, on the contrary, I believe that the number of new banner proposals will RISE as our user base will grow, and anticipating that, I would hate to lose good proposals (or good "old banners"). PrinceGloria (talk) 05:03, 8 April 2014 (UTC)Reply
I said "sometimes". Obviously it's not always true. Powers (talk) 14:05, 8 April 2014 (UTC)Reply

Wikivoyage banners edit

Swept in from the pub

Hello there Wikivoyage community. AndreCarrotflower notified me on my talkpage last week while I was transferring a few of Wikivoyage's freely licensed banners to Wikimedia Commons that I ought to leave local versions of the banners on the English Wikivoyage without deleting them, per the notice at the top of Wikivoyage:Destination of the month candidates/Banners. Of course, I respect the English Wikivoyage's independence from Wikimedia Commons, a practice sometimes exercised also on the English Wikipedia, but I am curious as to the original reason this not-so-well-documented line of policy was introduced. I was pointed to Talk:Main Page#PNG but the reasoning introduced there did not clarify exactly why hosting the files locally is better than hosting them on Wikimedia Commons. Perhaps it was an issue regarding bandwith issues, but could someone also elucidate the technical details of that to me? If it was something else altogether, I noted the existence of commons:Category:Wikivoyage banners already created on Commons for the purpose of hosting banners across language editions of Wikivoyage, which would be an argument for transferring to Commons rather than against, wouldn't it? TeleComNasSprVen (talk) 08:45, 17 March 2014 (UTC)Reply

It's worthy of note that User:Peterfitzgerald, the one who originally proposed that banners be hosted locally rather than at Commons, is no longer active on Wikivoyage and is very unlikely to be reachable through his talk page. -- AndreCarrotflower (talk) 10:58, 17 March 2014 (UTC)Reply
One point is if hosted locally they could be easily protected by local admins, but I don't think we do it anyway. Danapit (talk) 13:46, 17 March 2014 (UTC)Reply
Another reason: might these banners be more likely than other illustrations contain non-free content according to our Exemption Doctrine Policy? Danapit (talk) 13:54, 17 March 2014 (UTC)Reply
Talk:Main Page#Proposed Main Page Specifications indicates that local banner upload is done to allow admins to protect them while they are being featured, thus preventing a main page image from being changed to something that would be extremely embarrassing for the site. -- Ryan • (talk) • 15:21, 17 March 2014 (UTC)Reply
Keeping mind we're only talking about main page banners here (our 7:1 article banners should be on Commons where possible)... I would suggest that we keep the local uploads temporary for protection purposes. Once the feature is over, the banner can be uploaded to Commons (so that we can use it on our Previous DotM (etc) page(s)), while alternative banner suggestions can be deleted. Powers (talk) 18:11, 17 March 2014 (UTC)Reply
I believe that it may be possible to have them protected on Commons (but it's done by bot); en.wikipedia does it, and you must be an admin to upload over the fullprotected file here. But, they may not be willing to do this as we're not en.wikipedia, and thus 1) not such a huge target of vandalism and 2) only a medium-sized wiki. --Rschen7754 21:00, 17 March 2014 (UTC)Reply
That would require protecting the name on both wikis, as otherwise a locally-uploaded file overrides a shared repository. K7L (talk) 01:12, 18 March 2014 (UTC)Reply
IMO, this is rapidly approaching "more trouble than it's worth" territory. The current system of uploading banners locally has not been an issue thus far, and frankly I'm not exactly sure what problem we're trying to solve here. -- AndreCarrotflower (talk) 02:18, 18 March 2014 (UTC)Reply
That is not correct; only admins can upload a file using the same name as what is on Commons. --Rschen7754 17:55, 18 March 2014 (UTC)Reply

Pros:

  • Keeps our list of Special:ListFiles low and manageable, helps to keep track of local Fair Use files and whatnot.
  • Possible reuse on other language Wikivoyages, and even third-party reusers (InstantCommons) which is what we want per our licensing right?

Cons:

  • Local upload/create-protection still necessary to prevent overriding the shared repository version.
  • May require jumping through commons:Commons:Upload hoops, though it might not be that much different than going through local Special:Upload.

Is this a correct reading of what I'm seeing here? As to the bot, I think I can ask Krinkle to modify his script accordingly to auto-protect Main Page banners. Or perhaps better yet ask a bot owner to reupload a banner to Commons after the main page feature is done and then delete the local version. TeleComNasSprVen (talk) 07:20, 18 March 2014 (UTC)Reply

39 suggested new alternative banners - please participate in the following discussions and vote edit

Swept in from the pub

Over the last month or so I have created 39 new alternative banners to existing ones used in various prominent city articles on Eng Voy. I created these banners from exisitng photos on Wikicommons first and foremost for use in the parallel articles on the Hebrew Wikivoyage. In most instances these new alternative banners feature panoramic photographs of cityscapes (and yes, I know not everyone here want cityscape banners to be used in the city articles), as we in the Hebrew Wikivoyage tend to prefer cityscape panoramic banners to panoramic banners of flowers, bushes, fishes, or other individual objects which are not necessarily unique to a certain place and do not necessarily help the travelers get an idea of how the destinations they plan on traveling to actually look like (we usually add the photos of important individual objects to the relevant segments in the articles instead).

Please participate in the following 39 discussions and indicate in each of the discussions whether you prefer the existing banners or the new suggested banners.

ויקיג'אנקי (talk) 04:40, 5 April 2014 (UTC)Reply

I looked at all banners of destinations I know, but none of the suggestions were an improvement. --FredTC (talk) 19:54, 6 April 2014 (UTC)Reply
Excuse me but I find this kind of shopping around quite disgusting and counter-productive. If you don't like a banner, make a better one, start a discussion in the talk page, see where it goes. It is not a "vote", it is a discussion. If you want voting, try Eurovision.
Secondly, if you believe you have superb banner-making skills and want to put them to good use, look around for articles to go without a banner, of which we still have shiploads.
If you just want to be appreciated, do note that this is a collaborative project and not a talent contest. Appreciation comes in the form of having created a better, more complete, more useful, more frequently visited and used, and also nicer to look at, site. Mediawiki sites, even those with well-developed badge/barnstar and whatnot systems, are some of the worst places to go to if you want to shine and receive massive expressions of awe and appreciation. This is the uttermost opposite of X-Factor.
If you want the kind of appreciation Wikivoyage can provide you with, start with articles that need help the most, as this is where making a meaningful and visible impact is the easiest. The appreciation you can provide yourself with looking at an article that started out as neglected, outdated stub and is now a full-blown guide is the best thing ever. Or at least the best thing on Wikivoyage. PrinceGloria (talk) 20:36, 6 April 2014 (UTC)Reply
I actually thought that this was a healthy way to promote collaboration between language versions. Even if none of the new banners are used here, it's interesting to see what other languages prefer, and it's at least worth discussing the possibility of changing to a potentially better banner. -- Ryan • (talk) • 20:48, 6 April 2014 (UTC)Reply
Yeah, I don't understand what the down side is. And some of the new banners are a major improvement (while others are not). Let 100 flowers bloom. Ikan Kekek (talk) 20:54, 6 April 2014 (UTC)Reply
We've had those banners suggested in the talk pages for some time now and they have generated instantenous reactions, though some not favourable for the user who posted. I fail to see why this needs to be brought to the attention at the pub, I am seeing this kind of discussions quite often (i.e. suggestion of a new banner, also from other language versions). The fact that the user refers to their preference regarding panoramas and refers to a "vote" made me think they perhaps want to shop for "votes" for their proposals, which I find counterproductive.
I also believe that while diversity and multiple choices are always better, we may want to direct our attention to more creative issues. There was a fair share of discussions in the talk pages, why do we need to encourage more participation in bulk? If somebody is particularly keen on or knowledgeable about Leeds, they will probably have had the article on their watchlist and have or will see the discussion about its banner. If somebody isn't, why bother them. It is a local issue, not a global one, and not a pressing one requiring more attention from the community. The French and Italians are also using different banners oftentimes. PrinceGloria (talk) 21:40, 6 April 2014 (UTC)Reply
Yes, and we had a bunch of beautiful banners from French Wikivoyage proposed some time ago. I found your tone unnecessarily hostile. I don't see it as harmful that this notice was posted here, and I also don't see it as harmful that ויקיג'אנקי has pride in their banners or that they posted about their philosophy of what makes a good banner to them. Ikan Kekek (talk) 21:46, 6 April 2014 (UTC)Reply
I see nothing wrong with ויקיג'אנקי's actions here. Even if in most of these cases I preferred the existing banner to what was proposed, it's nice to see other options presented and have these pleasant little discussions about what we look for in a good banner. No harm done, and I think we're a stronger community for it. PerryPlanet (talk) 22:47, 6 April 2014 (UTC)Reply
I agree that it is a worthwhile exercise to see alternative banners. ויקיג'אנקי made some suggestions and if it helps improve one English destination article then that is great.
It does actually raise another question. Since the Hebrew site apparently doesn't use Wikidata as the reference to banners it means all changes have to be suggested in this manner. If it was the French site then basically our banners would change with no discussion (or even change notification), and this is true vice versa. Has anyone considered how we work with other language sites that use Wikidata for banner references? Andrewssi2 (talk) 23:43, 6 April 2014 (UTC)Reply


First of all I want to apologize if anyone was offended becuase I did not choose the right words (I chose to use the word "vote" instead of "discussion" or "consensus based discussion"). English is not my primary language and therefore occasionally I may end up formulating sentences which do not take into account different nuances and sensitivities.

I must also clarify that contrary to what someone suggested above, in addition to these 39 alternate banners I created, over time I have also created many banners for articles ​​which have no banners at all (both in Heb Voy and Eng Voy). In the future I definitely plan to also help create even more banners for articles that don't have any banners. Either way, I have made many banners in the past and I'll continue to make many more in the future (first and foremost for usage in Heb Voy), and in my opinion no harm is done by having the Eng Voy community (and maybe also other Wikivoyage communities) discuss using some of these alternative banners here as well. On the contrary - I believe that permitting discussions of this kind help us improve the quality of our articles over time.

I will also note that I have noticed that many of the users in Eng Voy whom have created banners in the past tend to be very proud of to their creations, and some of them I believe might even assume that their banners would continue to be used in the Eng Voy articles forever. In practice, Wikivoyage banners​​, as well as any of the other elements appearing in the articles, are open to discussion at any time now and in the future, and of course in the future instances in which specific new alternative banners would actually end up being favored by a majority of community members in a discussion, existing banners might very well end up being changed based on the new consensus reached. Based on my experience with Wiki culture, most likely, in 5 years, or 10 years or 20 years from now, most of the banners currently used in Eng Voy would probably end up being replaced by more much more successful and spectacular panoramic photos, whether you like it or not (this would most likely happen when the En Voy community would become much larger and diverse).

Regarding the original note I added above, in which I invited the Eng Voy community to take part in the current 39 discussions being held over these alternative banners... I chose to post this invite here mainly because this practice is widely acceptable in many wikis as it promotes fairness and it help us make sure that the final decision actually corresponds to the prevailing opinion amongst the Eng Voy community.

Anyway, I am glad that so far at least some of the alternative banners I created have gained support/consensus of the community and would probably end up being used in Eng Voy as well.

Finally, regarding Andrewssi2 last question about the instances in which foreign wikis would use Wikidata to display banners - I can confirm here that we in Heb Voy community do display banners according to what is defined in Wikidata by default, NEVERTHELESS, in the instances in which we rather display other alternative banners than what is defined in Wikidata - all we need to do is edit the banner code of a specific article in Heb Voy and specify that a different banner would be used there, and as a result, that article only doesn't use the banner which is associated with that article in Wikidata. ויקיג'אנקי (talk) 05:17, 7 April 2014 (UTC)Reply

Hi ויקיג'אנקי, you took the initiative to help improve WV and I personally don't think you need to explain yourself at all. Many thanks again for the alternative banner suggestions. Andrewssi2 (talk) 07:44, 7 April 2014 (UTC)Reply
This is at least the second time you offered a lot of alternative banners. Last time, you presented some great ones, too, and this time, you waited for more people to pass judgment on them, so I think that's great, and I know that most of us will welcome you whenever you come again with more banners for us to look at. And we'll look forward even more to pagebanners for articles that have none. Ikan Kekek (talk) 09:12, 7 April 2014 (UTC)Reply
I think the pub is a nice place to get opinions, because some destinations may not generate conversation if it is left to the talk page. Plus, since users who make banners are all proud of their work, discussion is probably better than plunging forward to replace everyone else's banners with one's own. That way no toes are stepped on. ChubbyWimbus (talk) 14:22, 7 April 2014 (UTC)Reply

Method which may allow you to find many additional spectacular panoramic photos to be used as Wikivoyage banners edit

Swept in from the pub

I wanted to share with the community an interesting method which may allow you in many cases to use certain spectacular panoramic photos of specific destinations around the globe as banners in certain travel destination articles on Wikivoyage.

As far as I have gathered, nowadays when most Wikivoyage banner creators want to create a banner for a specific travel destination they would most likely begin their search for a good panoramic photo (which they would later crop to the resolution 2100 x 300 and then re-upload) on WikiCommons. Although there are a lot of free photos of travel destinations available to use on Wikimedia Commons, in many cases you would not be able to find there even just one good panoramic photo of specific destinations (or a good photo you could turn into a good 2100x300 banner). From my experience, as a result of this lack of variety in available free spectacular panoramic photos to certain destinations, in many cases Wikivoyage banner creators whom are unaware of additional sources of free panoramic photos may often, as a compromise, create banners from existing photos on Wikicommons which don't produce the best quality Wikivoyage banner.

The alternative method (which apparently some Wikipedians also prefer) for finding many additional spectacular panoramic photos for use as Wikivoyage banners, is as follows:

1. First perform a global search on Flickr's vast photo database (make sure that the search would be done on all their photos, including the ones which do not have a free license) for panoramic photos of specific travel destinations. On this search page, you would be able for example to search for "Panorama Disneyland Paris" or "Panoramic Disneyland Paris' (check it out here for yourself and you will notice that there are far more spectacular panoramic photos available on Flickr for this specific destination than those available for this specific destination on Wikicommons).
2. After you find one or multiple non-free panoramic photos you think would look well as a Wikivoyage banner (the free ones you can of course import easily using this Wikimedia foundation tool), go ahead and send the creator of that photo on Flickr the following message:

Subject: May we use one of your photos in Wikivoyage?

Content: Hi (Write the Name or Username of the Flickr Photographer you are addressing). I am a volunteer writer for the free travel guide website Wikivoyage (the latest creation from the creators of Wikipedia). I am working on the article (Write Name of Travel Destination Article) (en.wikivoyage.org/wiki/NameOfTravelDestination) which currently has no panoramic picture in the banner. I am emailing you to request that you license one of your photos Write the URL of their specific Flickr photo you liked under the Creative Commons Attribution-ShareAlike 3.0 license (CC-BY-SA), a license which permits others to reuse your image as long as they provide proper attribution to you. Your credit would be attached to the image, along with a link back to either your Flickr profile or other website of your choice. The contents of the CC-BY-SA license can be found at creativecommons.org/licenses/by-sa/3.0/

If you are willing to contribute your image under the terms of the CC-BY-SA license, you can change the license by going to the image's Flickr page and under Owner settings clicking edit License and choosing "Attribution-ShareAlike Creative Commons".

3. Usually, when you send the above message to between 3 to 5 different photographers on flickr, whose photographs you found by making a global search on Flickr, in most cases, after a day or two at least one photographer would respond and tell you they approve of your suggestion and that they changed the license.
4. After the Flickr photographer changes the license of their photo, you would now be free to (A) import the photo to Wikivoyage using this Wikimedia Foundation tool (B) create the banner image using an Image editing program such as Photoshop or Paint.net and be able to upload the new version as a separate derivative work (the free license terms of the photo would of course allow you to do so).
5. Write back Flickr photographer and thank them.

Using this method, and thanks of course to the generosity of Flickr photographer CetusCetus, I have created not so long ago the banner which now appears at the top of the article Disneyland Paris (surprisingly I did not find any existing spectacular panoramic photos for this popular destination on Wikivoyage, but Flickr on the other hand had many different good panoramic photos of this specific destination). After I sent the above message to the Flickr photographer CetusCetus she changed the license of this brilliant picture and as a result I was able to create a banner from it. ויקיג'אנקי (talk) 23:06, 26 May 2014 (UTC)Reply

You could tell the same thing in a brief message. --Saqib (talk) 23:29, 26 May 2014 (UTC)Reply
It's also worth noting that you can search for photos on Flickr that are compatible with our licence here: https://www.flickr.com/search/?sort=relevance&license=4%2C5 --Nick talk 00:49, 27 May 2014 (UTC)Reply

Guide articles edit

Hi, everyone. With your permission, I'd like to prioritize the Guide articles that are still lacking in custom pagebanners. The list is here. Once all these articles (well, possibly excluding Isha Yoga Centre, which many of us thought should have been merged and redirected) have pagebanners, I intend to add a requirement for a custom pagebanner to the criteria for advancing an article to Guide status. Ikan Kekek (talk) 13:18, 5 August 2014 (UTC)Reply

I think this is a fine idea - go for it! --Nick talk 21:39, 12 September 2014 (UTC)Reply
Thanks. I had forgotten all about this! But this should still be a priority, as nothing much has changed. I've added this as a priority under Wikivoyage:Banner Expedition#Goals. Ikan Kekek (talk) 21:55, 12 September 2014 (UTC)Reply
I wouldn't say nothing much has changed. The list was at 97 items the first time I checked right after you posted it here, and is now down to 54 items. That's 44% completion in six weeks, compared to the banner project as a whole where it took a year and a half to reach 27% completion.
Thatotherpersontalkcontribs 09:48, 13 September 2014 (UTC)Reply

TOC background color edit

Anyone knows how to make the black TOC background less transparent (darker)? I'm asking this for the Dutch WV where they find the white text difficult to read on some banners. Globe-trotter (talk) 12:05, 8 September 2014 (UTC)Reply

The only option I know about is TOC box option. (Enter box=black for the TOC to appear in a translucent black box with white type. Enter box=white for the TOC to appear in a translucent white box with black type. Enter nothing for the default solid grey box with black type.) Might that help? --Danapit (talk) 13:23, 10 September 2014 (UTC)Reply

Guide articles lacking pagebanners edit

Swept in from the pub

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

attribution in image edit

Do not like it myself but should we allow attribution text in banner images? See Skomer, I asked the contributor to remove copyright text from the image, which was done, only to be replaced by copyleft text. Do we want to have what appear to be advertising a business in images? --Traveler100 (talk) 15:35, 28 October 2014 (UTC)Reply

Preferably not. We have the summary sections on the file's page on Commons for that purpose. --ϒpsilon (talk) 15:39, 28 October 2014 (UTC)Reply

edit

I noticed this edit (since reverted) by User:ויקיג'אנקי, who provides the rationale in the change of banner as to it being larger than the 'standard size' of 2100x300.

Looking at the guidance seems a bit ambiguous. It does seem to suggest that 2100 x 300 is recommended, but if a banner is (say) 7000 x 1000 in size, is this truly a problem?

The benefit of larger banners is that they scale better to higher resolution screens (such as Apple Retina laptops), and logically screens will increase in resolution more in future.

The disadvantage is that the full size image gets downloaded, thereby increasing rendering and download time.

Which is right? And can we provide clearer guidance on the subject? --Andrewssi2 (talk) 05:07, 19 December 2014 (UTC)Reply

I think the 2100 x 300 was a recommendation. The important part was maintaining the 7:1 ratio. If the image quality permits, I've started to make banners at 2800 x 400 to take into account higher screen resolutions. -Shaundd (talk) 06:08, 19 December 2014 (UTC)Reply
Right, but I think User:ויקיג'אנקי (and perhaps others) are taking 2100 x 300 to be the recommended size, no smaller and no greater.
Can we change the guidance to reflect the bold text below?

Image size (Proposed)

  • Banners have a 7:1 width to height ratio.
  • Banners need to be at least 1800 pixels wide to accommodate wide screens (images do not scale up to fit the size of the screen). The recommended dimensions are a minimum of 2100 x 300 pixels.
--Andrewssi2 (talk) 06:31, 19 December 2014 (UTC)Reply

I didn't write the right description in the summary and as a result I was misunderstood - you see, I fixed this new banner, instead of that which شاملو created, mainly because his banner wasn't a 7:1 (and that's what i should had written in the description) - it was a 6.3897 x 1 (and the resolution was 2,000 x 313). ויקיג'אנקי (talk) 06:56, 19 December 2014 (UTC)Reply


I will add though that at the Hebvoy community we have discussed in the past what the banner resolution should normally be, and only after I made a couple of banners in high resolution PNG files and got many complaints from Hebrew Wikivoyagers whom told me that these banners took too long to load, we at Hebvoy decided to only create compressed JPEGs which are around 180 KB in size, and usually have a resolution of 2100 x 300 (or smaller if I can't find a good source photo). ויקיג'אנקי (talk) 07:01, 19 December 2014 (UTC)Reply
Ah, I see. I think we need to have the same conversation here since most of us were not party to that discussion on Hebvoy :)
I hold the position that banner image sizes should be as high in resolution as they can in order to look good on Wikivoyage in 5 years or 10 years time when people are using much higher resolution screens. I understand that image size could be an issue from a bandwidth perspective, therefore what should be a maximum size? I would suggest four time the size of the recommended minimum, i.e. 8,400 x 1,500 --Andrewssi2 (talk) 07:27, 19 December 2014 (UTC)Reply
My understanding of the banner code is that it only loads the 1800px thumbnail and then sizes it dynamically based on the width of the browser window. If that's the case, sizes over 1800px should have no deleterious effect on performance. Powers (talk) 13:26, 19 December 2014 (UTC)Reply

Large PNG files take long to load. Too many of our users would load these pages + banners at locations around the globe with slow Internet connections. For this reason I do not favor having high resolution 5 mega byte PNG files used instead of compressed 180 KB JPEGs. LtPowers - a 5 MB PNG file takes longer to load. I would recommend that you go aborad and test loading such banners in Wikivoyage from India or something to really realize how much more slower those load than the JPEG banner I created for New York City for example. ויקיג'אנקי (talk) 14:38, 19 December 2014 (UTC)Reply

That is a ridiculously impractical suggestion. The fact that the banner you created is a JPEG should be completely irrelevant when it comes to load times because the Mediawiki software creates all thumbnails as PNGs. If our banner code is loading a pre-generated 1800px thumbnail, there should be very little difference between banners. Powers (talk) 16:00, 19 December 2014 (UTC)Reply
Apologies, after checking, it appears Mediawiki only converts SVGs to PNG for thumbnailing. JPEGs remain JPEGs as thumbnails. Nonetheless, the thumbnails are indeed generated and cached at 1800px; you can confirm this by right-clicking a banner and opening the image in a new tab (or saving the image to your hard drive). You will see that the image actually displayed to the user is the 1800px thumbnail, not the full-size original. Powers (talk) 16:09, 19 December 2014 (UTC)Reply
Right now we recommend a banner of 2100x300, but Template:Pagebanner resizes that to a width of 1800. The trade-off we're facing is that a lower-res banner looks bad on big screens, but a higher-res banner uses up bandwidth unnecessarily on smaller screens. Wikivoyage:Travellers' pub#Would you be interested in a PageBanner extension?* is an attempt to resolve that issue by downloading banners that are sized appropriately for the user's screen, but it might also be possible to implement a Javascript solution to this issue that uses a smaller banner by default and then replaces it with a larger banner for users with large screens. Since that replacement could be done on DOM load the process would likely be transparent to the user. Time permitting I'd be interested in working on a proof-of-concept for such a solution unless anyone sees any holes in that design, and I think it would then allow us to have recommendations to create banners that were as big as people could find (i.e. a minimum width of 2100px for the original), would improve download times for users with small screens since smaller images would be used for them, and would look better for users with huge screens since larger images would be used for them. The experience will be sub-optimal for users with Javascript disabled (we could default to the existing behavior those users encounter today), but I think that holds true for most of the web these days. Thoughts or comments? -- Ryan • (talk) • 17:06, 19 December 2014 (UTC)Reply
* does anyone know if the proposal to create a module for page banners is moving forward? [1] seems to have gone silent.
It's pretty much waiting for a developer to raise his or her hand and agree to work on it. There's nothing else to move forward on, really. I'm also not clear on whether the proposed module is intended to be coded so that only an appropriately-sized thumbnail is downloaded.
Re: your proposal, I'd like to see some concrete numbers on how big a problem this is. Our banners are currently less than half a megapixel (1800x257); for anyone browsing on a connection slow enough where that's a problem, I would argue they should probably be browsing the web with images off anyway.
-- Powers (talk) 19:32, 19 December 2014 (UTC)Reply

Since this is a subject that would affect all the other Wikivoyage communities as well (and on the long run, the EngVoy community should want to have all Wikivoyage communities working together on making and using page banners because there are a lot left to create), I suggest that this discussion would first and foremost be held with users from other Wikivoyage communities as well - maybe in this discussion page? ויקיג'אנקי (talk) 05:57, 20 December 2014 (UTC)Reply

Isn't this just a very simple thing to solve? If I understand the discussion above it doesn't matter what size the banner is as long as it is scaled 7:1 and is in JPEG format. Wikimedia will apply the appropriate scaling for WV. We shouldn't use PNG format for photos because that is just not good practice.
In future, when somebody rewrites the banner extension then we can take advantage of the higher resolution images that we have. And seriously, in 5 years most people will be using very high resolution screens and we will have to run through ALL the articles and uploading new banners! We want to avoid this. Andrewssi2 (talk) 09:10, 20 December 2014 (UTC)Reply
The traveller comes first - for this reason, loading huge banner image files while in India for example might be much excruciating for the actual travlers in that region using slow Internet connections to read the India guides (yet you rather support the interest of the Western countries readers that would be loading huge banners at their homes on their wall projectors in 2025). ויקיג'אנקי (talk) 19:52, 20 December 2014 (UTC)Reply
You earlier mentioned "5MB PNG files" -- can you give an example of an article that has a 5MB PNG banner atop it? Powers (talk) 20:09, 20 December 2014 (UTC)Reply
The traveller comes first is not a valid response. We have established that using a JPEG banner will result in a scaled image.
Also we should not be using PNG for photos anyway! The format is suited for diagrams and should not be used for banner pictures. Andrewssi2 (talk) 21:33, 20 December 2014 (UTC)Reply
Just a little real world investigation with Google Chrome developer tools. The banner for Germany is a whopping 6MB in size and following the belief of ויקיג'אנקי this will mean every single visitor will have to download this 6MB file to view the Germany article.
Looking at the actual resources downloaded (Chrome->Tools->Developer Tools->Resources), the Germany article downloads a scaled image of 2560 × 370 with a file size 394 KB on my laptop as well as a second file of 3600 × 520 with a size of 743 KB
This does suggest that the code that renders banners needs to be looked at (why two files?), but it is just wrong to suggest that the original banner image is currently downloaded in full.
The answer is that banners should be JPEGs and can be any large size you want. Why is this so complicated? --Andrewssi2 (talk) 22:06, 20 December 2014 (UTC)Reply
Are you positive it's getting two banners in your test above, and that they are sized as stated? Looking at the network traffic for Germany, I see only one banner file being downloaded - http://upload.wikimedia.org/wikipedia/commons/thumb/9/91/%C3%96tlingen_-_Panoramaansicht_klein_banner.jpg/1800px-%C3%96tlingen_-_Panoramaansicht_klein_banner.jpg (195kb). A single banner file sized at 1800px is what I would expect based on the code present in Template:Pagebanner. Are you perhaps using a particularly huge screen resolution? In my test, even setting my browser at fullscreen only renders the banner image at 1674px. -- Ryan • (talk) • 22:16, 20 December 2014 (UTC)Reply
I tried again and only got one! I didn't clear my cache (sorry). The new (single) image is 3600 × 520 with a file size of 743 KB. This might be explained by the fact I have a MacBook Pro with a Retina display.
Since Chrome has an emulation function I tried a 'generic notebook' with a display of 1280x800 and the new banner dimensions were 1800 × 260 with a file size of 195 KB, so it probably is based on the browser info.
In any case, I think the suggestion above that banner images should be small because they do not scale is a myth. We should use large images as we can because they will be scaled. --Andrewssi2 (talk) 01:51, 21 December 2014 (UTC)Reply
I believe your Retina display may be upscaling the 1800px banner, because the template code should only be retrieving an 1800px thumbnail. I suggest checking an article where the original file size is much smaller, like Arillas. If that banner also shows up as 3600, then we know it's upscaling (because the original is only 2100px). Powers (talk) 02:00, 21 December 2014 (UTC)Reply
Powers , perhaps not. The dimensions for the Arillas banner are 2100 × 300 with a file size of 115 KB (I refreshed the page to make sure this was the case). These are also the dimensions of the source of that banner on Wikimedia. --Andrewssi2 (talk) 02:12, 21 December 2014 (UTC)Reply
Andrewssi2: Can you list the exact steps you're using to get your numbers? The file File:Arillas Wikivoyage banner.jpg has dimensions of 2100x300, but unless there is some code somewhere that I'm not aware of, that file is rendered on Arillas after being resized to 1800px - all of the "File:" calls in Template:Pagebanner include an argument of "1800px". For that file to show up at any other size than 1800px in the Arillas article means that we've got some other call somewhere that is fetching a larger-sized banner image, but so far I haven't found anything that I can see would be doing that. -- Ryan • (talk) • 02:31, 21 December 2014 (UTC)Reply
I think we are moving into the realm of screenshots :) I will do this later today.
That said, even if WM does provide (slightly) larger images for my MacBook Pro, I think it has little impact on the core of the discussion above in that we can certainly afford to use high resolution Banner images just as long as they use the recommended JPEG format. Andrewssi2 (talk) 03:09, 21 December 2014 (UTC)Reply

edit

It is understood that Wikimedia will scale down banner images to 1800 pixel width, no matter what the size of the source image is.

I reported seeing a higher resolution banner of 3600 x 520 pixels for the Germany article banner when viewed with Chrome for MacOS Mavericks on a MacBook Pro Retina (13"). I went into 'incognito mode' to be sure nothing was confusing the results. Here is a screenshot:

 

The link text was was https://upload.wikimedia.org/wikipedia/commons/thumb/9/91/%C3%96tlingen_-_P…t_klein_banner.jpg/3600px-%C3%96tlingen_-_Panoramaansicht_klein_banner.jpg (note this doesn't render directly in a browser window)

I also saw a larger image (2100x300) than anticipated for Arillas.

 

The link text was was https://upload.wikimedia.org/wikipedia/commons/e/e5/Arillas_Wikivoyage_banner.jpg

Is this sufficient for analysis? Andrewssi2 (talk) 08:28, 21 December 2014 (UTC)Reply

Interesting. For comparison, I tried to right-click and download the banner pic for Germany and the downloaded photo was 1800 x 260 pix. I am using a Samsung laptop with Win7 and Firefox. Danapit (talk) 10:38, 21 December 2014 (UTC)Reply
Andrew, your link text isn't working because your browser abbreviated the link (thus the ellipsis in the middle of the URL). The full URL is https://upload.wikimedia.org/wikipedia/commons/thumb/9/91/%C3%96tlingen_-_Panoramaansicht_klein_banner.jpg/3600px-%C3%96tlingen_-_Panoramaansicht_klein_banner.jpg
That's exactly what we'd expect to see if we used the image syntax [[File:Ötlingen - Panoramaansicht klein banner.jpg|3600px]], but we're not. We're using 1800px, so that should be the only thumbnail image being transmitted from WMF servers. Powers (talk) 16:03, 21 December 2014 (UTC)Reply
Thanks Andrewssi2. Based on those screenshots I would assume that there must be some Javascript somewhere pulling in the larger file sizes, but I can't find anything in Template:Pagebanner or in MediaWiki:Common.js that would do so. There is some Javascript on the image that looks like it's for the image viewer, but that's all I've found so far. It would be nice to know what's going on, as this functionality would likely be easy to re-use to provide different file sizes based on screen resolution. -- Ryan • (talk) • 16:46, 21 December 2014 (UTC)Reply
A bit more investigation. I tried with a standard Windows 7 laptop and I got 1800 x 260 pixels (as you expected)
I then tried the Chrome emulation for Galaxy S4 smartphone, both desktop view and mobile view, and guess what? I got the larger banner size:
I am guessing that the Template:Pagebanner is instructing all images to scale to 1800x260 when it detects a Windows browser agent. Otherwise (Mac OS, mobile device, etc) it instructs a different scaling.
I would say this is a big issue for anyone using a mobile device, since they are likely downloading a much bigger banner than they need. Andrewssi2 (talk) 23:00, 21 December 2014 (UTC)Reply
Reproducing your test I'm seeing other images being downloaded as 440px images, where on fullsite they are downloaded as 220px images. This problem is apparently general to all images on mobile devices, and not specific to the page banner. Perhaps @Jdlrobson: can provide some insights. -- Ryan • (talk) • 00:01, 22 December 2014 (UTC)Reply
Nice detective work. Perhaps Mediawiki doubles all thumbnail sizes on mobile? Powers (talk) 02:25, 22 December 2014 (UTC)Reply

This is not mobile specific. MediaWiki implements larger images for retina devices. If you look closely at the output HTML, any image tag will have a srcset attribute set. This will scale the image up to 2 times the requested resolution. The only way to get round this in a template is to use background-images instead of image tags.

There are various problems with banners implemented in current form and the more issues I see the more I think we should implement this as an extension. See https://phabricator.wikimedia.org/T77925 (note you can login and comment and help move this along using your Wikivoyage username and password!). Hope this is helpful. Jdlrobson (talk) 21:29, 22 December 2014 (UTC)Reply

Thanks, I suspected this was not mobile specific although it must impact all high end mobile devices these days. I will try and join the discussion that you linked to. Andrewssi2 (talk) 04:17, 24 December 2014 (UTC)Reply

Distorted banners edit

A common error when making page banners is distorting the aspect ratio during cropping process. As avoiding the distortion doesn't seem to be obvious and I didn't find anything on this matter in the project page, I suggest we add it, for example in this section (the suggested new sentence is bolded here):

  • Make a good composition. Most images, ... have to be corrected when found. Resize image without distortion (keeping aspect ratio).

Any objections? Can anybody help me to re-phrase the sentence, if it is not understandable? Thanks! Danapit (talk) 09:15, 17 February 2015 (UTC)Reply

Good addition! I might rewrite "When resizing images you should ensure that you keep the correct aspect ratio in order to avoid distortion" Andrewssi2 (talk) 10:09, 17 February 2015 (UTC)Reply
Thanks, it sounds better. Danapit (talk) 10:11, 17 February 2015 (UTC)Reply
Hi Danapit, I inlcuded this on the new experimental Wikivoyage:Banners policy page. --Andrewssi2 (talk) 23:00, 26 March 2015 (UTC)Reply

Feedback for pagebanner extension for wikivoyage edit

Hi all, there's a discussion on a project for developing the functionality provided by the pagebanner template into an extension here, with a purpose to make the banners render well on mobile in addition to desktop. It would be great to get feedback as well as if someone could help along, in providing valuable suggestions as to the look and feel of the banners in the new extension as the project progresses. Thank you!-Sumit (talk)

edit

Earlier this year we had an interesting discussion around page banner guidelines. It appeared that Hebrew Wikivoyage were making two major mistakes which were (1) using PNG format for photos, which is generally a bad idea and (2) limiting the sizes to 2100x300 because Wikimedia can't resize PNG. We also discovered that high definition screens had larger banners renders automatically by Wikimedia, even if it was a small device like a phone.

Anyway, I think now that the facts are known, we should clarify the advise to:

  • Banners must use JPEG format
  • Banners must have a 7:1 width to height ratio
  • Banners should be as wide as possible and need to be at least 1800 pixels wide to accommodate wide screens. The recommended minimum dimensions are of 2100 x 300 pixels

Any thoughts on this? --Andrewssi2 (talk) 05:26, 23 March 2015 (UTC)Reply

That sounds fine to me, but it if the guidance is updated it would be helpful to include an explanation about why JPEGs are being recommended in case people wonder. -- Ryan • (talk) • 05:35, 23 March 2015 (UTC)Reply
Looks OK, Agree with Ryan. • • • Peter (Southwood) (talk): 06:45, 23 March 2015 (UTC)Reply
I thought those were already our preferred guidelines. Powers (talk) 19:14, 23 March 2015 (UTC)Reply
Are the guidelines called out somewhere other than on the expedition page? Banners have moved far beyond the expedition phase at this point, but Template:Pagebanner just points to the expedition and Wikivoyage:Banners doesn't exist. If we don't already have a policy page for banners then one should be created. -- Ryan • (talk) • 19:23, 23 March 2015 (UTC)Reply
I was thinking that. We only seem to have the expedition page and the Template page itself. Can we start working on Wikivoyage:Banners  ? Andrewssi2 (talk) 00:00, 24 March 2015 (UTC)Reply
Another option is to just extend Wikivoyage:Image_policy Andrewssi2 (talk) 04:54, 24 March 2015 (UTC)Reply
I'm not sure I understand what "scaling for different page sizes" has to do with PNG vs. JPEG in the text proposed below. After reading #Banner Size Guidance, it seems like the argument for JPEGs is based on trying to use banners with smaller file sizes and thus faster page load times? As to a Wikivoyage:Banners page, I would very much be in favor of seeing someone start that - it could be easily done by just copying the text from the expedition page that is relevant to banner implementation (as opposed to the bits about expedition members, banner rollout on the site, etc). I think a separate page for that information makes sense, rather that putting it on the image policy page, although the two pages should definitely reference each other. -- Ryan • (talk) • 05:22, 24 March 2015 (UTC)Reply
I understood from the discussion that a PNG file wouldn't scale, and the full size image would be downloaded regardless. A corresponding JPEG image would be scaled in the same scenario, thereby resulting in smaller file sizes and quicker rendering.
That said, our Wikivoyage:Image_policy page already makes clear that JPEG should be used for photos, which most banners are. Andrewssi2 (talk) 05:30, 24 March 2015 (UTC)Reply
 
Scaled to 50px
 
Scaled to 200px
See the example at right - PNGs seem to be scaled properly by Mediawiki. That aside, a pointer to Wikivoyage:Image policy#Image formats, with additional text explaining the file size advantages of JPEGs vs PNGs, would be helpful for whatever banner guidance is created. -- Ryan • (talk) • 05:43, 24 March 2015 (UTC)Reply
Yes, it seems standard PNG images have no issue to scale. I wonder what the Wikivoyage Hebrew issue was then... Andrewssi2 (talk) 23:41, 24 March 2015 (UTC)Reply
Occasionally I have added banners which were existing images on commons that just happened to be almost 7:1. To cater for these cases, I would suggest that such existing images must be between 6.8:1 and 7.2:1, and be cropped if they are outside this range. I am also wondering if we should give a maximum size - 21000 x 3000 maybe for performance reasons.
As an example Spiš has a banner which is 12,854 × 1,824 (7.05:1). AlasdairW (talk) 23:22, 24 March 2015 (UTC)Reply
I'd be in favor of some flexibility on the point of the ratio. At this point we probably want to encourage as many new banners as possible even if the ratio is not completely precise. At the same time we should allow for someone else to later update that image with the 7:1 ratio without major consultation.
Maximum size is interesting... we just don't know what we will be dealing with in 10 year's time. I'd say we should not have a maximum but leave the scaling to Wikimedia, unless that is otherwise a problem? Andrewssi2 (talk) 23:41, 24 March 2015 (UTC)Reply
A quick look at Spiš on a Windows laptop suggests the downloaded banner image is only 1800 pixels across. The download speed was instant over a 4G network. --Andrewssi2 (talk) 23:45, 24 March 2015 (UTC)Reply
7:1 only, as far as I'm concerned. The whole point is to keep that banner element as a consistent interface element. Powers (talk) 02:03, 27 March 2015 (UTC)Reply
With the range of 6.8:1 to 7.2:1, I am suggesting a tolerance of about +/-3%. I have used existing images in the banners for Spiš, Perth and Kinross, Dunedin and Dunbar. Dunbar is the most "out of spec" at 7.12:1. Looking at this on a large screen, I do see a grey line at the bottom of the picture, but this is not a big issue. Dunbar gives a picture of 1800x253, against a standard one of 1800x257, Spiš is 1800x255, and the other two are 1800x256. AlasdairW (talk) 00:16, 28 March 2015 (UTC)Reply
I think that it should remain firmly at 7:1, however we can make it clear that banners of a slightly different dimension are preferable to having no banner at all. --Andrewssi2 (talk) 21:27, 28 March 2015 (UTC)Reply
Banners which are not exactly 7:1 should be tagged with a maintenance category. Preferably immediately. I forget the template details. • • • Peter (Southwood) (talk): 03:58, 29 March 2015 (UTC)Reply
I forgot about that template. {{crop}}
--Andrewssi2 (talk) 10:22, 29 March 2015 (UTC)Reply

Updated revised text based on comments edit

Some revision based on comments above:

  • Banners must use JPEG format in order to allow scaling for different page sizes, as well as general web design best practice
  • Banners must have a 7:1 width to height ratio
  • Banners should be as wide as possible and need to be at least 1800 pixels wide in order to accommodate wide screens. The recommended minimum dimensions are of 2100 x 300 pixels

Andrewssi2 (talk) 00:04, 24 March 2015 (UTC)Reply

Another update:

  • Banners must use JPEG format in order to follow WikiVoyage image policy
  • Banners must have a 7:1 width to height ratio
  • Banners should be as wide as possible and need to be at least 1800 pixels wide in order to accommodate wide screens. The recommended minimum dimensions are of 2100 x 300 pixels

--Andrewssi2 (talk) 05:32, 24 March 2015 (UTC)Reply

Policy Page edit

Should we call the policy page Wikivoyage:Banners or Wikivoyage:Banner Policy ? --Andrewssi2 (talk) 21:25, 25 March 2015 (UTC)Reply

I'd vote for the first option. If people do end up preferring the second, though, it should at least have a lowercase P in policy. Texugo (talk) 23:14, 25 March 2015 (UTC)Reply
I Created Wikivoyage:Banners. If really need it can be renamed before it becomes official. --Andrewssi2 (talk) 22:21, 26 March 2015 (UTC)Reply

Table of contents edit

Swept in from the pub

Having just landed at Penang International, I thought I'd look at your George Town article. Huge and informative but lacking a table of contents like Wikipedia or Wikitravel. Since you seem to use the same software is there a good reason for this omission - or is it just an oversight? 218.208.95.130 00:58, 4 May 2015 (UTC)Reply

Georgetown (Malaysia) does in fact have a table of contents embedded in the banner. Are you not able to see it?
Also what device / browser combination are you using? Thanks, --Andrewssi2 (talk) 01:08, 4 May 2015 (UTC)Reply
It's rather counterproductive to embed it there since it spoils the hero image and means that many folks will miss it. Your minimalist (but still intrusive) ToC also seems sadly lacking in functionality since, unlike the usual Wikipedia style contents list, I can find no way to expand it to H3 and H4 level headings. If I'm interested in a Splurge level hotel, I don't wish to wade through all the Budget listings to get there. And, of course, it's totally lacking in the mobile view...
I originally used the Chrome browser on an Android LG phone and then, when I eventually got to my hotel, a laptop running Firefox under Windows 8.1 (Ugh!).
Incidentally, this article is named wrongly. Officially (central and local government and UNESCO) it's always been two words George (and) Town since the very first maps were created in the English language. Just because many folks have struggled to use English when their native language was Hokkien, Arabic, Malay or Tamil doesn't mean we should perpetuate the heterodox. 118.101.139.200 01:04, 5 May 2015 (UTC)Reply
Well, moving it is easy. I used to live in Malaysia in the 70s and remember seeing it as one word most often. I did a Google search and found that the two-word version is used a bit more often than the single-word version, so I'll go ahead and move the article. Ikan Kekek (talk) 01:06, 5 May 2015 (UTC)Reply
Thanks, (fish soup?). Google often gets things wrong. It's particularly bad on the correct physical location of Spanish cathedrals, for example... 118.101.139.200 01:26, 5 May 2015 (UTC)Reply
Fish soup is sup ikan. Ikan kekek is a particular type of fish. Ikan Kekek (talk) 06:34, 5 May 2015 (UTC)Reply
Yes, WV's table of contents implementation has been badly broken for quite some time. There has been a lot of discussion; see Wikivoyage talk:Banner Expedition#Renew TOC discussion and elsewhere on that page, but no solution implemented. I'm not sure what it would take to get this fixed. Pashley (talk) 11:33, 5 May 2015 (UTC)Reply
The Wikimedia Foundation's technical staff has expanded greatly in numbers and competence in recent months. You might try asking for technical assistance to implement a horizontal, hierarchical and expandable table of contents at https://phabricator.wikimedia.org/tag/phabricator/
For people in locations with slow and/or expensive metered connections a good ToC may be thought important. On that topic, you might also ask them to ensure that text is loaded very first and before any resource hungry resources such as images and maps. 175.138.97.134 11:42, 8 May 2015 (UTC)Reply

Hello Wikivoyagers. I have been experiencing the same problems as the original IP user for a couple of weeks now on all articles. The banners are there but there are no tables of contents on any of the articles I view or edit. Since this doesn't appear to be an issue for many / any other users (I haven't come across any other discussions on the matter) it is presumably an issue with my browser, which is just bog-standard Chrome. Any ideas or suggestions? Warmest regards, --ThunderingTyphoons! (talk) 14:41, 18 May 2015 (UTC)Reply

Apparently they don't work without Javascript? K7L (talk) 15:15, 18 May 2015 (UTC)Reply
Thanks for the suggestion, though I do have Javascript enabled. :-) --ThunderingTyphoons! (talk) 22:35, 18 May 2015 (UTC)Reply

Dubious guideline - can we not show people in banners? edit

The following guideline was just added:

"To respect privacy, avoid pictures of identifiable people"

Some of my banners have clear pictures of people. What is meant by 'identifiable' in this respect?

I think travel would be be dry if we only looked at monuments, with no life around them --Andrewssi2 (talk) 11:10, 4 June 2015 (UTC)Reply

The person should not be the main focus of the image (unless you have had permission), faces at a distance as part of the overall scene should be OK. --Traveler100 (talk) 11:50, 4 June 2015 (UTC)Reply
I would avoid images where the person's face is taller than the article title that appears on the banner. It might come as an unpleasant surprise to some readers if they saw a photo of themselves as they looked five years ago. In some countries permission is required to publish a photo of an identifiable person see: Commons:Commons:Personality rights. In a couple of cases I have edited a banner image to remove a conspicuous face, but that now appears not to be allowed according to Wikivoyage:Banners, which has different guidelines to those here. AlasdairW (talk) 22:26, 4 June 2015 (UTC)Reply
The paragraphs has been clarified. Of course, banners can feature professionals, performers and other people who are part of an attraction; see Religion and spirituality and Manhattan/Theater District. I made a Respect banner where faces were blurred to be safe better than sorry; there are probably better solutions. /Yvwv (talk) 22:53, 4 June 2015 (UTC)Reply
Thanks, a strict interpretation of the previous wording would have made it near impossible to use any people at all!
In terms of the new wording, we have the phenomenon that digital photographs are getting higher resolution all the time. A crowd of 100 people may probably have many (if not all) their faces visible in high resolution.
I agree that a banner should not focus on one person or small group of people (exceptions for public performers as mentioned above), but do we really need to go for blurring in terms of a large crowd of people? --Andrewssi2 (talk) 23:32, 4 June 2015 (UTC)Reply
Shouldn't the banner policy align with our image policy? I agree the banner shouldn't focus on one identifiable person or small group, but I think blurring faces in a crowd in a public place or only permitting public performers is more strict than it needs to be. -Shaundd (talk) 03:52, 5 June 2015 (UTC)Reply
That is a sensible suggestion User:Shaundd , agreed Andrewssi2 (talk) 22:42, 5 June 2015 (UTC)Reply
Our image policy for people in photos is not particularly useful. The Commons:Photographs_of_identifiable_people is detailed and comprehensive. The banner should focus on the place, not random or arbitrary people. Any photo that requires pixellation or similar to prevent identification is inherently unsuitable for a banner. • • • Peter (Southwood) (talk): 08:26, 6 June 2015 (UTC)Reply
Generally I agree that banners for destinations should focus on the place. Unfortunately sometimes the best photos on commons do have people in them. Travel topic banners are more likely to need people in them to be relevant to the topic, and blurring may be appropriate in this case, as was done for Respect, as readers might infer that an identifiable person supported the advice in the travel topic. AlasdairW (talk) 14:17, 6 June 2015 (UTC)Reply
Inferring that an identified person in a banner would support the advice given in the article is rather far fetched. Andrewssi2 (talk) 23:30, 6 June 2015 (UTC)Reply

Avoid using Nazi monuments for cities in Germany edit

There is another guideline which I agree with, but the example used is bad:

"Prefer motives that would make the locals proud, without too much controversy. For instance, avoid using Nazi monuments for cities in Germany."

I lived in Germany for a few years and never once saw a Nazi monument. They were mostly destroyed or covered up after the war, and anyway it is actually illegal to display Nazi symbols in Germany.

Examples of Nazi architecture still do exist (Templehof airport and the Olympic Stadium in Berlin) but I don't see anything wrong in using them.

Can we use a better example? --Andrewssi2 (talk) 00:15, 5 June 2015 (UTC)Reply

I don't know how far we should go with this. There's a huge skyscraper in Warsaw that was a gift from Stalin. It's therefore controversial, but it's still an important sight. Should it be per se excluded from a pagebanner? Ikan Kekek (talk) 00:27, 5 June 2015 (UTC)Reply
Also any skyline of Pyongyang will include the Ryugyong hotel (the massive pyramid structure). It is a constant source of embarrassment to the local population (well, perhaps more the leadership) since it is a showcase building that never got completed. It is nevertheless a defining part of the city.
After reading Ikan's comment, I'm actually now inclined to agree to remove this guideline altogether. --Andrewssi2 (talk) 22:38, 5 June 2015 (UTC)Reply
How about: Avoid using images that would be offensive to the inhabitants. Examples are not really needed. If an inhabitant finds the banner offensive, they can let us know.• • • Peter (Southwood) (talk): 08:12, 6 June 2015 (UTC)Reply
I agree with Peter. Ikan Kekek (talk) 08:14, 6 June 2015 (UTC)Reply
The only "Nazi monument" (apart from former concentration camps) that I could think of in Germany is the Reichsparteitagsgelände (Nazi party rallying grounds) in Nuremberg. And while its Swastika was famously blown up by the Americans, it is still recognizable as Nazi architecture. That being said, it is unlikely to be featured in a banner, unless Nuremberg gets districtified, because most non-German visitors will care more about the old town than the Nazi era. That being said, there is some merit in this policy, as it might help discourage edit wars. While North Korean propaganda trolls are probably not our main concern, imagine if for some reason we put up a pagebanner that is perceived as insulting king Bhumibol of Thailand. Even John Oliver got into trouble for being perceived as having insulted the Thai royal family. Hobbitschuster (talk) 11:21, 6 June 2015 (UTC)Reply
We have at least one example of Nazi architecture banner, for Prora article. I don't find anything offending about it though. Danapit (talk) 14:32, 6 June 2015 (UTC)Reply
Nor do I. It is just a building they built. • • • Peter (Southwood) (talk): 19:47, 6 June 2015 (UTC)Reply
But I do think that Prora is "Nazi architecture" in the sense that no other type of regime would have built something like this... Hobbitschuster (talk) 20:17, 6 June 2015 (UTC)Reply
The text has now excised all reference to the Nazis (a good idea generally on the Internet) Andrewssi2 (talk) 23:32, 6 June 2015 (UTC)Reply

Incomplete table of contents edit

Adding the banners was a fine idea in several ways, but it wrecked the tables of contents. Banners show only top-level headings and there is no way to get lower-level ones. Discusssion on this started over two years ago at #Add a "full TOC" button? and was extensive; several solutions were suggested but none implemented. The conversation petered out late last year.

Can we restart the conversation? Or better yet, fix the problem? Pashley (talk) 20:21, 26 June 2015 (UTC)Reply

Wikivoyage:Travellers' pub#Please test the new banners should address this issue. -- Ryan • (talk) • 21:05, 26 June 2015 (UTC)Reply
Great! Thanks for the pointer. Pashley (talk) 22:04, 26 June 2015 (UTC)Reply

A list I made edit

I made a list (here) of city entries that I thought need banners. Of course some of them are in more desperate need than others (like Constanța, before Lexington). --AmaryllisGardener talk 19:00, 7 August 2015 (UTC)Reply

Just out of interest, why do these destinations require banners in particular? --Andrewssi2 (talk) 23:27, 7 August 2015 (UTC)Reply
@Andrewssi2: These are cities I thought were next in line to get a banner, based on the city's size (i.e. Weihai's population of 2.5 million), and tourist attractions (i.e. Lexington, North Carolina's famous Barbecue Festival that attracts as many as 160,000 people). --AmaryllisGardener talk 18:29, 10 August 2015 (UTC)Reply
It may interest you to know there is a way to automatically generate a report of articles without banners. Here is one I use for Chinese cities without banners based on article size that you can modify for other countries/criteria. --Andrewssi2 (talk) 00:59, 11 August 2015 (UTC)Reply

Consensus for deploying the new banners extension edit

Swept in from the pub

Hi all,

We are about to deploy Sumit's new banners implementation to Wikivoyage English. As the Wikimedia rules stipulate, we need this discussion to show that the community approves the deployment. So, please voice your approval or disapproval below, thanks a lot! Notes:

  • At first the extension will only target a handful of test pages. So nothing will break overnight because of the deployment.
  • A demo is available, there are still a few minor bugs that should be fixed in the next few days, but we should not wait until everything is 100% perfect, as the deployment paperwork process will take some time. We will iron out the last details on test pages here.

Thank you! :-) Syced (talk) 10:03, 8 July 2015 (UTC)Reply

I am obviously in favour of deploying this extension. Syced (talk) 10:05, 8 July 2015 (UTC)Reply
The new menu drop downs look really good! I'm concerned about the following however:
1) There is still no menu in the mobile view (tested on Safari on an iPhone 6). Is there plan to introduce?
2) The banner on your test page is very blurry on a Macbook Pro Retina with the Safari browser. The same banner used on Asia looks fine. Therefore this looks like a significant bug. (The Chrome browser is fine for both your test page and Asia.
Personally I'd prefer all significant bugs get fixed before installing, because... well I work in software and I just know it is easier to fix before than after :) --Andrewssi2 (talk) 10:39, 8 July 2015 (UTC)Reply
Are there any changes beyond the drop down menu? (which I am heavily in favor of, btw). Hobbitschuster (talk) 10:56, 8 July 2015 (UTC)Reply
From the project page, it seems that Wikidata integration is more flexible (you can specify which Wikidata item to bind to) and a wider range of sizes is supported (not quite sure how it works, but I'm happy to get higher resolution banners) Andrewssi2 (talk) 11:09, 8 July 2015 (UTC)Reply
What about the categories created with the current template for tracking usage of custom and default banners? --Traveler100 (talk) 11:18, 8 July 2015 (UTC)Reply

I get an image with low resolution and without any menus (Opera on Debian desktop). Does the functionality rely on specific settings (javascript etc.), perhaps on a site other than the visited one? --LPfi (talk) 14:34, 8 July 2015 (UTC)Reply

When returning to the page the menus had appeared. Really slow? Still 320x46 image. --LPfi (talk) 14:37, 8 July 2015 (UTC)Reply
Like User:Andrewssi2, when using the Safari browser the banner looks like something taken with a decade-old cell phone camera. The dropdown menu works fine. On Firefox the banner looks normal. ϒpsilon (talk) 17:58, 8 July 2015 (UTC)Reply
Well spot LPfi, thanks! Reproduced and reported at https://phabricator.wikimedia.org/T105274 Syced (talk) 07:28, 9 July 2015 (UTC)Reply

A few points from my side:

  • The review before deployment will still take time, till when I'll keep resolving issues. With respect to workboard, I'm left with this major task on TOC. However, an important part is capturing issues that I might have missed, so feel free to add more of them if you find, the earlier, the better. I've already created a task here to explore the blurry banners issue raised above. I'll add more if needed.
  • Categories for banners is tracked here.
  • Banner without menus as stated above will be resolved by the above mentioned task(T103569).
  • On a final note, I'd like to bring your attention to the task T105033 which talks about banners on narrow mobile screens and explores some options. That task is just an initial discussion on the issue and currently not part of the plan. So views on that task will help improve and take forward the issue of small banners on screens as small as 320px width.

Thanks for the feedback!--Sumit.iitp (talk) 21:23, 8 July 2015 (UTC)Reply

So is this command intended to be placed in the existing pagebanner template and then we build round it the category logic and additional icons? If so any issue with the name of this function being the same as the the template? Also documentation use two different spelling for banner. --Traveler100 (talk) 20:11, 9 July 2015 (UTC)Reply

Thanks for pointing out the typo, it is now fixed! Syced (talk) 08:39, 10 July 2015 (UTC)Reply
This looks good. Just a couple of comments from me:
  • The text in the drop down menus can be hard to see (it clashes a bit with the underlying text) -- maybe we should have less transparency in the menu bar once this is implemented (I'm not sure if it's still relying on the local CSS or if it's part of the banner extension)
  • I'm confused as to how it gets banners. Looking at how the extension is used on the demo page, it seems a user just provides the name of a Commons image; but the project page makes it sound like it's coming from a Wikidata property. Can the extension handle both? -Shaundd (talk) 13:49, 10 July 2015 (UTC)Reply
Hello! Regarding categories and clash with existing pagebanner:
Thank You!--Sumit.iitp (talk) 19:43, 10 July 2015 (UTC)Reply

A few quick questions edit

OK, I decided to give cropping banners a go, even if it's not usually my cup of tea. I have a few questions though, for which I haven't found the right answers on the expedition page (although that might just be me). Hopefully one of you can answer? :)

  1. If I use an image from Flickr, do I need to upload the original file to Commons first, or can I upload only the cropped version/banner?
  2. If I use an image that's on Commons, is it enough to just link the original file as source, or do I somehow need to file it as a derivative work? The expedition page suggests using DerivativeFX, but that tool seems to be offline?
  3. I'm a bit confused about the allowed sizes. It needs to be at least 1800 wide. 2100:300 is recommended, but in the end it's about the 7:1 aspect ratio. So, if I have or create a 7:1 image that's somewhat larger, is that still okay? Or is 2100:300 also a maximum?

Thanks, JuliasTravels (talk) 21:29, 15 August 2015 (UTC)Reply

To answer your last point, banners can be much larger than 2100:300. I have used 3500:500 for several banners. I think that we did discuss having a suggested upper limit somewhere, but it was not thought to be needed. I would consider down sampling if the image was going to be over 6300:900, but that is partly to reduce the upload time. Also see draft guidelines in: Wikivoyage:Banners. AlasdairW (talk) 23:19, 15 August 2015 (UTC)Reply
Re #2, I've seen it done both ways. I usually link back to the original image and note the original author, while describing the changes I made. None of the banners I have handled that way has questioned so far. An example is Commons:File:Similkameen banner valley view.jpg. -Shaundd (talk) 04:49, 16 August 2015 (UTC)Reply


JuliasTravels, I think it is in princliple ok just to upload the cropped version to Commons from Flickr, but it is pity not to have the full picture in Commons once someone uploads anyway. Instead of DerivativeFX I use flickr2commons tool nowadays. It took me a while to make it work, it needed a permission when I used it for the fisrt time and then it only worked when I restarted the browser. But otherwise it works very well. Once the picture is in commons, you should still refer to the original file on Flickr, because when you select the Flickr licese, the picture goes through a review and the commons admins find it easirer to check it if they have the original source. Plus I use template ´´derived from´´. YOu can have a look at this pic I uploaded recetly and the banner I derived from it. Like this it is well documented how the file is further used. The banner can be any size larger than 1800 pix in the correct ratio. This is one way to do it, others might works in a slightly different way. Danapit (talk) 05:06, 16 August 2015 (UTC)Reply
One pitfall that I encountered was that even if the Flickr source image on which the Banner was based is moved to MediaWiki, you still need to reference the original Flickr location.
Another fun one I saw last week was a slight variation of the CC license of an image used on Flickr (that didn't allow derivative works) resulting in my banner being rejected. Andrewssi2 (talk) 10:41, 16 August 2015 (UTC)Reply
Thanks for all your comments; it's a lot clearer to me now :-) JuliasTravels (talk) 11:18, 16 August 2015 (UTC)Reply

Banners extension: all reported bugs have been fixed. Asking again for consensus edit

Swept in from the pub

Thank you for all the feedback about the new banners extension! Sumit worked hard for 10 days, and now all bugs you have reported have been fixed! You can try it here: http://pagebanner.wmflabs.org/wiki/Roppongi

This extension is essential to having Wikivoyage display correctly on mobile. It is important that we deploy it well before Sumit's GSoC is over, so that it can be tested in real situation and fine-tuned correctly. For this, we need everyone's consensus below. Deployment will start with a few test pages. Due to paperwork it takes time before consensus and actual deployment, so we would greatly appreciate your cooperation to move forward. Thanks! :-) Syced (talk) 04:09, 17 July 2015 (UTC)Reply

<img src="https://upload.wikimedia.org/wikipedia/commons/6/61/Sony_Pictures_Entertainment_banner.jpg" srcset="http://pagebanner.wmflabs.org/images/thumb/6/61/Sony_Pictures_Entertainment_banner.jpg/320px-Sony_Pictures_Entertainment_banner.jpg 320w,http://pagebanner.wmflabs.org/images/thumb/6/61/Sony_Pictures_Entertainment_banner.jpg/640px-Sony_Pictures_Entertainment_banner.jpg 640w,http://pagebanner.wmflabs.org/images/thumb/6/61/Sony_Pictures_Entertainment_banner.jpg/1280px-Sony_Pictures_Entertainment_banner.jpg 1280w,https://upload.wikimedia.org/wikipedia/commons/6/61/Sony_Pictures_Entertainment_banner.jpg 2560w" class="wpb-banner-image">.
Otherwise what I saw in my limited testing looks good. -- Ryan • (talk) • 05:38, 18 July 2015 (UTC)Reply
Thanks for reporting this! What browser version do you use? In particular, we will have to check whether it supports srcset. For browsers without srcset we just send the default (big) image, a choice which is actually up for discussion. Syced (talk) 10:22, 20 July 2015 (UTC)Reply
I saw the issue using the most current version of Chrome after using the developer tools to change my user agent to iPhone 6. I use this method for testing different mobile browsers frequently at work. -- Ryan • (talk) • 14:27, 20 July 2015 (UTC)Reply
You can track progress here and chime in with thoughts - https://phabricator.wikimedia.org/T106523. It's worth noting this is no worse or no better than the status quo (currently banners served via the template are hidden in mobile but still get downloaded). At least with the extension we have more options to work this out. Jdlrobson (talk) 18:29, 20 August 2015 (UTC)Reply
Well spot! I see that Sumit fixed that bug this morning, thanks for reporting! :-) Syced (talk) 10:24, 20 July 2015 (UTC)Reply
Is "srcset" supported on mobile devices? A low resolution banner on good desktop screens will make a bad impression, but a large banner on mobile devices will be a huge usability issue when bandwidth is low or costly. --LPfi (talk) 11:21, 20 July 2015 (UTC)Reply

Thank you everyone! The "paperwork" has now started, with the Mediawiki Admin team performing a security review which will probably take around two weeks. That will leave us around a week before Sumit's GSoC ends, which is quite short, so everyone is still encouraged to play with http://pagebanner.wmflabs.org/wiki/ and report any bug. Cheers! Syced (talk) 05:28, 22 July 2015 (UTC)Reply

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

Swept in from the pub

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

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

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

Swept in from the pub

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

Discussion edit

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

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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
  • ויקיג'אנקי - 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)Reply
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)Reply
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)Reply

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

I'm happy to be involved in the creation of banner, but sadly, like many of the above, can't really commit to a particular time. Please do continue with your own great work on this - we will get there! --Nick talk 22:17, 13 September 2015 (UTC)Reply

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

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

Swept in from the pub

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

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)Reply
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)Reply
Interesting idea, but can't say the result of the satellite images looks compelling. Andrewssi2 (talk) 22:55, 12 August 2015 (UTC)Reply
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)Reply
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)Reply

Suggestions for banners on small screens edit

Swept in from the pub

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

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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
How exactly is the banner "essential" to learning about a destination? Powers (talk) 23:33, 29 July 2015 (UTC)Reply
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)Reply
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)Reply
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)Reply

Update edit

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


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

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

2560 x 1600 Retina display (13 inch) Andrewssi2 (talk) 08:24, 20 August 2015 (UTC)Reply
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)Reply
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)Reply
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)Reply

Banners extension deployment edit

Swept in from the pub

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

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

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)Reply
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)Reply
What is the plan when this goes live? Just to try on a few select articles? Andrewssi2 (talk) 22:54, 12 August 2015 (UTC)Reply
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)Reply
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 - http://pagebanner.wmflabs.org/wiki/Canada. 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)Reply

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)Reply
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: https://en.m.wikivoyage.org/wiki/Red_Wharf_Bay 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)Reply
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)Reply
Look forward to experimenting with this later, thanks! Andrewssi2 (talk) 23:41, 13 August 2015 (UTC)Reply
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[2] 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 [3].
For using badges please see this the documentation at http://mediawiki.org/wiki/Extension:WikidataPageBanner. 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)Reply
  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)Reply
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)Reply
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)Reply


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

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).Reply

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 https://phabricator.wikimedia.org/T102537 Jdlrobson (talk) 23:32, 19 August 2015 (UTC)Reply

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

Swept in from the pub

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

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)Reply
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)Reply
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)Reply
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)Reply
 
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
'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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply

Effective strategy for completing banners on a country/state leve edit

Swept in from the pub

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

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)Reply
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)Reply
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)Reply
Re that banner category, there is a long-unaddressed issue at Category talk:Has custom banner. Nurg (talk) 06:09, 23 August 2015 (UTC)Reply

Banners extension: Now live on these articles edit

Swept in from the pub

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 https://phabricator.wikimedia.org/T108839 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)Reply

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

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 http://pagebanner.wmflabs.org/wiki/Roppongi, so the problem may lie in the currently-deployed extension code. -- Ryan • (talk) • 14:25, 20 August 2015 (UTC)Reply
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 https://www.mediawiki.org/wiki/Extension:WikidataPageBanner#Examples

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

Update - Drop down toc's should now be visible--Sumit.iitp (talk) 18:47, 20 August 2015 (UTC)Reply
Yes, I see them. Awesome! --Alexander (talk) 19:56, 20 August 2015 (UTC)Reply
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)Reply
Tried to fix it here: https://gerrit.wikimedia.org/r/#/c/232844. Kaldari (talk) 21:03, 20 August 2015 (UTC)Reply
Update: Red Wharf Bay is now using Wikidata to power its banner. Please test like crazy :) !!! Jdlrobson (talk) 23:13, 20 August 2015 (UTC)Reply
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)Reply

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

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)Reply
@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)Reply
@Ryan, Toc in banners is currently broken for me; is that related? JuliasTravels (talk) 08:01, 24 August 2015 (UTC)Reply
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)Reply
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)Reply


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

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

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

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)Reply
Looks like a Windows Phone issue... see the same view on my iPhone 6 Andrewssi2 (talk) 10:55, 24 August 2015 (UTC)Reply
Tracked in https://phabricator.wikimedia.org/T110100. They should be the same although I'm not sure which one is displaying correctly. :) Jdlrobson (talk) 19:00, 24 August 2015 (UTC)Reply
Thanks for following it up. Yes, no surprises it's a Windows Phone issue :P James Atalk 11:30, 25 August 2015 (UTC)Reply

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

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)Reply
Arguably, banners shouldn't print, though the title and a TOC of some sort should. Powers (talk) 00:16, 25 August 2015 (UTC)Reply
With regards to noprint - please discuss here so we can work out what to do - https://phabricator.wikimedia.org/T110201 - 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)Reply
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)Reply
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)Reply

────────────────────────────────────────────────────────────────────────────────────────────────────

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

  1. The banner is appearing above diffs: [4] vs [5].
  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)Reply

I will get them installed on user pages at 5pm PST https://gerrit.wikimedia.org/r/234072 I wasn't aware of the revision problem - have created https://phabricator.wikimedia.org/T110384 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)Reply
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 https://phabricator.wikimedia.org/T110436 Jdlrobson (talk) 00:03, 27 August 2015 (UTC)Reply

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

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)Reply
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)Reply
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)Reply
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)Reply
I've updated Template:Pagebanner, so the new extension should now be live on all pages. -- Ryan • (talk) • 19:08, 28 August 2015 (UTC)Reply

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

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

edit

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

I have the same issue periodically. Sometimes it will cut off some of the banner so it looks like a 10:1 ratio and sometimes the banner doesn't stretch to fit the screen. Refreshing once or twice usually fixes it. -Shaundd (talk) 04:49, 30 August 2015 (UTC)Reply

NZ default banner edit

New Zealand articles that use the NZ default banner (File:NZ default banner.jpg) aren't showing a banner at all right now (see Central North Island and Raglan, for example). There's also no ToC. -Shaundd (talk) 04:49, 30 August 2015 (UTC)Reply

That was my fault - typo in the update to Template:Pagebanner. Special:Diff/2846280/2847203 should fix it. -- Ryan • (talk) • 05:39, 30 August 2015 (UTC)Reply
That seems to work, the default banner is back on all the pages I tested. Thanks! -Shaundd (talk) 06:07, 30 August 2015 (UTC)Reply

Categories edit

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

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

Enhancements edit

Now that the new banners are live on the site there are at least three issues that have come up:

  1. The old page banner allowed HTML in the page title, mainly for the purpose of allowing page names to wrap in cases like Devils Tower National Monument where we didn't want the page title to cover up an item of interest in the banner image. Including HTML in the page title is usually not a good idea, but we could easily wrap titles with CSS - see User:Wrh2/Sandbox for an example.
  2. The old page banner provided the option to specify "box=white", which would use a white TOC instead of a black one, for cases where the image was very dark.
  3. The old page banner allowed users to specify a page title of &nbsp; in cases like Chicago where the banner image already displayed the city name. I'm not sure that was actually a good idea, as suppressing the page title text is really bad for SEO and accessibility purposes.

I'm curious what people think the best way to resolve #1 and #2 are. We could potentially add new parameters to the banner extension for "pgnamewidth" and "toccolor", but I was thinking it might actually make more sense to just create a generic "extraClass" parameter that could be used to add one or more CSS class names to the banner wrapper. Doing so would provide a lot more future flexibility if people want new banner functionality since we could just modify Template:Pagebanner to accept parameters like "pgnamewidth", "box", etc, and then modify MediaWiki:Common.css locally without the need to change the underlying pagebanner extension. Thoughts? Any other enhancements that are needed? -- Ryan • (talk) • 15:42, 29 August 2015 (UTC)Reply

Create a generic "extraClass" parameter to add one or more CSS class names to the banner wrapper. As you so perceptively state, doing so would provide a lot more future flexibility. The "ToC losing legibility when overlaid on dark image" problem would be solved by having it appear immediately below the banner image rather than spoil the aesthetics of what is often a stunning image by obscuring the lower part. 80.234.185.120 15:50, 29 August 2015 (UTC)Reply
yeh I think this is a good idea and would be good to do in the extension itself. FYI if you do discover bugs once you have worked out the way forward please do be sure to raise a phabricator ticket] so the extension gets more powerful and generic. There are so many village pumps to keep an eye on that I'm worried I'll miss important things such as this. With respect to the banners you can pass pgname=|tooltip=Chicago which will have the desired effect. With a tweak the banner could be made to not output an empty h1. The tooltip should be enough to serve screen readers but you'd have to run some tests to see how the absence of an h1 impacts seo. Wrapping can and should be done at the extension level with CSS. You'll want to treat different resolutions differently... Jdlrobson (talk) 02:10, 30 August 2015 (UTC)Reply
Thanks Jon. I'll definitely get requests pushed to phabricator so please don't feel that you need to track everything here. The goal in raising issues in the pub is to coordinate what needs to be fixed and what solutions people prefer, and to then create a phabricator request once it is clearer what needs to be done. -- Ryan • (talk) • 15:59, 30 August 2015 (UTC)Reply

Show Preview and TOC edit

If you edit an article, and do a Show Preview, it will show a table of contents within the article. It would be better if this wasn't shown. -- WOSlinker (talk) 08:37, 30 August 2015 (UTC)Reply


Bot to find banners? edit

Swept in from the pub

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

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)Reply
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)Reply
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)Reply
Disclaimer: This technique will only work if the French and English destination names are the same --Andrewssi2 (talk) 06:35, 28 August 2015 (UTC)Reply
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)Reply
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)Reply
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)Reply
@Jdlrobson: Do you mean the new pagebanner extension? It writes to Wikidata?? Syced (talk) 13:23, 30 August 2015 (UTC)Reply
No but it could Syced :) It does retrieve from Wikidata though. will obviously read from wikidata, not too much to go the other way. Jdlrobson (talk) 16:12, 30 August 2015 (UTC)Reply
@JuliasTravels: Unfortunately Kizar has disappeared and the number of banners waiting to be uploaded to Wikidata is now over 1000. Syced (talk) 13:23, 30 August 2015 (UTC)Reply
I tried recontacting him/her and now all banners are on Wikidata :-D Except 9 "problematic" banners. I have checked one of these 9 and copyright seems to be OK, not sure what's wrong. Could anyone look at them and find what's wrong? Thanks! Syced (talk) 02:48, 31 August 2015 (UTC)Reply
I'm seeing no banner at all on West Bohemia, but the others look normal. K7L (talk) 03:08, 31 August 2015 (UTC)Reply
The image specified for the banner on that article does not exist: File:Westböhmen Banner.jpg. -- Ryan • (talk) • 04:12, 31 August 2015 (UTC)Reply
Fixed by adding banner Plzen banner.jpg to Wikidata. Syced (talk) 13:56, 31 August 2015 (UTC)Reply


Guidance on montages edit

 
Recent montage attempted on the site

I just noticed the following guidance:

"Collages, photomontages etc, are a lot of work to do well, and unless you are particularly skilled at this kind of work and don't mind having your efforts rejected due to differences in taste, probably not worth the effort. Use them at your own risk - each proposed application must be accepted by consensus."

This appears to contradict the image policy on the subject, which says montages are simply not allowed : Wikivoyage:Image_policy#Montages_and_gallaries

Can we modify this text accordingly? --Andrewssi2 (talk) 23:47, 29 September 2015 (UTC)Reply

100% agreeed. The Kazakhstan banner is awful - although it might perhaps inadvertently properly signify where the country's elites might be stuck taste-wise. I hope most of our readers do not think of Dynasty as pinnacle of good taste anymore. PrinceGloria (talk) 06:28, 30 September 2015 (UTC)Reply
I agree too. Nix on montages and collages. Ikan Kekek (talk) 07:00, 30 September 2015 (UTC)Reply
I also believe we should avoid montages. Danapit (talk) 08:35, 30 September 2015 (UTC)Reply
While the creator has put some work into that Kazakhstan banner, it just doesn't work in our guides and I'd support bringing this page in line with our image policy. James Atalk 13:19, 30 September 2015 (UTC)Reply
For mostly selfish reasons, I oppose completely shutting off the possibility of montages in banners. Powers (talk) 18:40, 30 September 2015 (UTC)Reply
If montages are allowed for banners it should be made clear in Wikivoyage:Image_policy#Montages_and_gallaries. Now the image policy (which I assume, is valid for banners as well) says "Wikivoyage does not use montages...".
And BTW, are banners considered "simple photography"? Otherwise, banners themselves would actually be disallowed per current Image policy. ϒpsilon (talk) 18:57, 30 September 2015 (UTC)Reply
I would be supportive of language that makes it clear that montages are usually discouraged but not disallowed. Assuming it's not a copyvio, the Kazakhstan banner above is quite striking and would be a good replacement for the existing banner if it was trimmed to the proper proportions. -- Ryan • (talk) • 19:26, 30 September 2015 (UTC)Reply
I don't think I agree that that kind of banner should be used. It's creative but weird and kind of Alice in Wonderland-like. Ikan Kekek (talk) 20:26, 30 September 2015 (UTC)Reply

────────────────────────────────────────────────────────────────────────────────────────────────────The banner in question looks - no offense intended - like one of those cheesy "visit x" commercials and also has the vague aura of "Ex-Soviet dictatorship trying to polish their image in the west". Maybe that's just me, though Hobbitschuster (talk) 20:29, 30 September 2015 (UTC)Reply

Let's not go down that road. Whatever the intentions, there is no accounting for taste and there's nothing to gain from pursuing deeper discussions about it. While not my personal taste, I agree with Ryan that the Kazakhstan example is a striking one, and nicely done. It's at least more interesting than the current banner, so kudos for the effort :-) That said however, the guideline simply calls for a consensus and even warns that it will be hard to get it. Clearly, there is no consensus at this point. I see no reason to change the wording. It's not as if montages are a constant issue, and there's no reason to suddenly shut the door completely on montages in banners. Perhaps one day someone surprises and persuades us all. At the very least, it will leave a base for the tiny handful of montages we have now (usually simplifying an image rather than adding to it). JuliasTravels (talk) 21:06, 30 September 2015 (UTC)Reply
To be clear, I only used the Kazakhstan banner above as an example of what a montage looks like and not an evaluation of its photographic merit.
The original point is that image policy and banner guidance are contradictory at the moment. If we feel that potentially montages n banners could be permitted then the image policy would need changing. --Andrewssi2 (talk) 22:27, 30 September 2015 (UTC)Reply
And we don't have a consensus to change it, so does that mean we are left with this contradiction of policies? Ikan Kekek (talk) 22:32, 30 September 2015 (UTC)Reply
Well, the banner expedition is only guidance. As far as I know an expedition isn't policy and therefore the Image policy should prevail (or be changed). Andrewssi2 (talk) 22:48, 30 September 2015 (UTC)Reply
Frankly, I'm tempted to say that the wording of policy should be changed to reflect the actual situation ;-) The reality is that there has always been a strong dislike of montages that combine images (and I personally agree). However, stating that we only want simple photography ignores all the Disney banners we have, which are technically montages too. Ideally, the wording should somehow reflect that. The thing with policies that explicitly disallow is that creative discussions are often nipped in the bud because policy says it's just not allowed. Getting a policy changed is much more of a bureaucratic thing, and mostly the domain of established users. Changing it is very hard, while an individual banner might just be brilliant enough for consensus to want to make an exception to common practice. That's why I like the kind of wording the guideline uses, and like to have it as some sort of precedent, even when the net effect is the same in 99% of the cases. JuliasTravels (talk) 14:16, 1 October 2015 (UTC)Reply
I don't believe any of the Disney banners are montages. Yet. Powers (talk) 23:50, 1 October 2015 (UTC)Reply
With regards to the 'actual situation', can we link to some montages that are in use? (I am personally not aware of any) Andrewssi2 (talk) 00:00, 2 October 2015 (UTC)Reply
Okay, maybe this is a problem of semantics on my side :) On this site, I've always considered montages to be anything that is not simple photography or maps, so including simplified or stretched images like the USA or Walt Disney World/Animal Kingdom banners. We have no other policy on that, do we? Either way, I'd still prefer to not shut off creative initiatives before they've had a chance to hatch. Just thinking or "combined" montages that might just be acceptable, when someone brilliant enough can produce them, I imagine situations where we really don't have suitable free-licensed panoramic source material, but we have, e.g. two images from the same place that could work together. Don't get me wrong; I much prefer simple photography and I'm no fan of travel brochure-like montages of landmarks. Obviously it wouldn't be acceptable to create situations that are not realistic. But if it's not unrealistic? And if it's the best we have? I wouldn't mind seeing a proposal, and judging it on its merits rather than just disallowing it completely in policy. JuliasTravels (talk) 11:26, 2 October 2015 (UTC)Reply
By definition, a montage is a single image assembled from multiple source images. I believe we've always had an implicit aversion to digital manipulation that misleads, but unspoken acceptance of subtle changes made to improve the image. Powers (talk) 18:35, 2 October 2015 (UTC)Reply
Yes, I wasn't thinking USA was a montage as such, but I get what you are saying. I'm also agreeing that we shouldn't place a constraint on creativity for the sake of policy, but I do think that the policy would need this exception called out. Andrewssi2 (talk) 10:27, 3 October 2015 (UTC)Reply
In practice, almost any policy can have exceptions by consensus. For example, there are instances in which a consensus has called for one or more "other-subject" links to Wikipedia. If we're going to disallow montages 99.99% of the time, I think we should have a policy that states that you can't use montages, and then if a particularly exception montage comes along, we can vote on whether to make an exception for it. That's my point of view, anyway. Ikan Kekek (talk) 11:07, 3 October 2015 (UTC)Reply

Unknown parameters? edit

I suspect some recent change has broken something. I see many pages with a message at the bottom referencing an "unknown parameters" page.

That is a red link, but the category has 263 members. I have no idea what is going on there, so I won't try to fix it. Probably someone should. Pashley (talk) 15:24, 1 October 2015 (UTC)Reply

Pub#Banner error category. -- Ryan • (talk) • 15:25, 1 October 2015 (UTC)Reply

Suggestion: adding small flags + coat of arms next to the title in the banners of all the country and city articles edit

Swept in from the pub
 
Screen captures of the current banners in the Italy and Norway French Wikivoyage articles + the current banners in the Jerusalem and Warsaw Hebrew Wikivoyage articles

To my understanding, this feature was initially created and added to the French Wikivoyage articles (although as of now their banners only display flags). The feature was later on also added to the banners of the Hebrew Wikivoyage. Recently the Hebvoy community decided to start having the Coat of Arms of cities be displayed in the city banners instead of displaying the city flags (as done on the French Wikivoyage).

I am hoping that the English Wikivoyage community would choose to have this feature added to the English Wikivoyage banners as well. What do you think? ויקיג'אנקי (talk) 15:35, 31 August 2015 (UTC)Reply

I forgot to mention that this feature automatically retrieves the images of the flags and the coat of arms from Wikidata. ויקיג'אנקי (talk) 15:49, 31 August 2015 (UTC)Reply
I like the idea of adding country flags, but am less excited about coats of arms. Note that if there is support for this change, it will be a bit tricky to implement with the new banner extension since the banner is no longer part of the main page content. It would be doable, either via Javascript, custom CSS for each country article, or a modification to the banner extension. It would be best not to rely on Javascript, and custom CSS for every country is kind of a hack, so if there is support for a change then the best option probably means updating the banner extension again. -- Ryan • (talk) • 15:52, 31 August 2015 (UTC)Reply
I agree with Ryan - I'm in favour of country flags, but less keen on the idea of using coats of arms: that feels like it might be an unending and thankless task. That said however, if it's incredibly difficult to implement, I would not be desperate to display the flags. --Nick talk 16:00, 31 August 2015 (UTC)Reply
I agree, but would go a bit further; I think coats of arms are downright silly in such a prominent place since travellers generally will not care about them.
As for flags, I think they are a fine idea for countries and probably also for states or provinces, but I'd object tto them for cities. The breadcrumb links at top of page already mention the country, and in most cases the text will as well. Why clutter the banner wiith an extra image, and add overhead to fetch it?
Also, in some cases the status of a city is controversial, e.g. see w:Positions on Jerusalem. Having the breadcrumbs for Jerusalem point to Israel seems fine to me, the only sensible course since they are in de facto control. However, I'd object to putting an Israeli flag in the banner. Pashley (talk) 16:16, 31 August 2015 (UTC)Reply
Coats of arms are often less striking and also less well known than national flags. (Counter-examples like Hamburg or Berlin notwithstanding). However, what shall we do about regional flags? Say the official flag of Alabama? What if they contain controversial symbols (e.g. the Confederate naval jack)? What if there is an "unofficial" flag that is more widely known and used? What about Islands and other destinations that havce semi-official flags? I like the idea, but as we say in Germany: The devil lies in the details Hobbitschuster (talk) 16:19, 31 August 2015 (UTC)Reply
For that matter, would   or   appear on the Toronto (+1 416) articles? The latter is a bit obviously   Toronto City Hall to anyone who knows the city, but might not be immediately obvious to someone outside the region. K7L (talk) 16:51, 31 August 2015 (UTC)Reply
Didn't we have flags on the banners of country articles at one point? ϒpsilon (talk) 16:57, 31 August 2015 (UTC)Reply
In case my comment was unclear, I'd be in favor of country flags on country articles as I think that's a nice UI clue for users that country articles are different from city or region articles. I don't think there is much value in having the flags elsewhere, although if someone wants to propose a different UI element that would help users to distinguish different article types (city, region, topic, etc) then that might be useful. -- Ryan • (talk) • 16:59, 31 August 2015 (UTC)Reply
This is a perfect example of a solution looking for a problem. I would be against adding coats of arms to the banners. They add almost no value to the article and even the people who live in those cities are probably unaware of what they are. It would be adding extra clutter for no benefit to the traveler at all.
National flags on country level articles may be more acceptable, but frankly I don't see why we need them. --Andrewssi2 (talk) 22:50, 31 August 2015 (UTC)Reply
Agreed with Andrewssi2. Just because one language version of Wikivoyage does something doesn't mean we need to. -- AndreCarrotflower (talk) 23:04, 31 August 2015 (UTC)Reply
I am all for country flags. And also for the emblem of the destination if easily retrieved from Wikidata. In France you can often find the coat of arms of the city on old buildings, that's interesting. Most tourism brochures feature them. Syced (talk) 04:44, 1 September 2015 (UTC)Reply
Why not add an image of the coat of arms to the article if it is useful? That would be more effective than an ugly micro-logo in the banner itself as this proposal is suggesting. Andrewssi2 (talk) 05:21, 1 September 2015 (UTC)Reply

This is a huge can of worms that involved months of discussion back in mid-2013 when there were major changes to Template:Quickbar and the introduction of Template:Pagebanner. While flags used to be included in the quickbar, there was consensus to remove them from the bar but consensus was never formed to add them to the pagebanner. Some relevant discussions can be found here, here and here. My position remains the same as 2 years ago; that is, in favour of adding only national flags to country guide pagebanners. However, I think the matter's trivial enough that we should not dwell on it too much. We seem to have been putting a lot of time and effort into pagebanner discussions lately, when really they are of fairly minor importance to travellers themselves. James Atalk 05:47, 1 September 2015 (UTC)Reply

I am absoluteluy against adding flags, coats of arms or any other images to the banner. Adds unnecessary visual clutter. There are many other ways we can still benefit the traveller much better and we should focus on them. PrinceGloria (talk) 05:57, 1 September 2015 (UTC)Reply
I am rather against cluttering the banners of countries with national flags and completely oposed to adding coats of arms to cities - this doesn't bring any benefit to the traveler in my opinion, and it can result in visual conflict with the banner image. Danapit (talk) 07:30, 1 September 2015 (UTC)Reply

We seem to have a partial consensus that no such addition to the banners is a good idea, except perhaps national flags in country-level articles. (If we agree on those flags, then we might talk about also showing state or provincial flags in banners for those articles; I'd oppose that.) If a coat of arms is important then put a good-sized image in the body of the article; in the banner it would be illegible clutter. The national flag in city & region article banners would be redundant clutter.

As for national flags, I feel strongly that they should be shown somewhere; either put them back in the quickbar or add them to country article banners. I'd prefer putting them in the banners, agreeing with Ryan: "I'd be in favor of country flags on country articles as I think that's a nice UI clue for users that country articles are different from city or region articles." Pashley (talk) 13:19, 1 September 2015 (UTC)Reply

I've thought about this, and I don't think I want to make it obligatory to put countries' flags in pagebanners. I'm not sure it's actually important to put flags anywhere in articles (if it is, a quickbar is a fine place to put it, and I can be put down as mildly supportive of that), as it's easy enough for people to find the flag of any country they like and not crucial information for visitors in most places, but I think that adding them to pagebanners risks distracting the viewer from the image and creating aesthetic problems at times. Ikan Kekek (talk) 19:42, 1 September 2015 (UTC)Reply
I don't think there's much informational value in putting flags next to the article titles. At that size, while some flags would look fine (like France), others would be barely legible (like Brazil). If we want to increase the visibility and importance of national flags, they should be displayed in the article proper at at least 150 px. Powers (talk) 20:01, 1 September 2015 (UTC)Reply
I realize that mine is a minority view, but I would be happy to see the national flag in the banner on all articles within that country (omitting disputed places, of course). Not everyone thinks to look at the breadcrumbs trail, so this gives Special:Random visitors another important piece of context. WhatamIdoing (talk) 21:48, 6 September 2015 (UTC)Reply
I disagree with the idea of putting a flag in every article, but "except disputed places" is in any case a no-go. We don't take sides in disputes on this site, and deciding what constitutes a disputed place (the entire state of Himachal Pradesh, all of which is sometimes called "South Tibet" by China?) would set a dangerous precedent for this site. Ikan Kekek (talk) 22:22, 6 September 2015 (UTC)Reply
In some places, which flag is displayed could be regarded as a political statement. I could see an edit war over whether Edinburgh has the flag of Scotland or the United Kingdom. Also would many people recognise the difference between the flags of Australia   and New Zealand   when displayed at that size? AlasdairW (talk) 23:19, 6 September 2015 (UTC)Reply
Yes, it is a whole can of worms that isn't relevant to our project.
I'm also wondering why all these banner related suggestions are being thrown somewhat dramatically on the travellers pub rather than the talk page of the banner expedition. Andrewssi2 (talk) 23:25, 6 September 2015 (UTC)Reply
Indeed, I for one have grown tired of hearing out attempts to fix a feature of our site that's not broken. -- AndreCarrotflower (talk) 23:43, 6 September 2015 (UTC)Reply
This is going off-topic, but I will just answer the last two comments: 1) Most banners discussions take place on Phabricator, I only post here the ones that require community approval. 2) Flags are indeed not a bug fix, but just in case the comment was not only about flags I might add that the recent extension was definitely a bug fix as banners were not displaying correctly on mobile. Cheers! Syced (talk) 02:49, 7 September 2015 (UTC)Reply

edit

Swept in from the pub
 

Does anyone know why banners don't always display fully? See the screenshot. Reloading shows the banner, but that's not really a solution. I'm getting this quite regularly (maybe 2 in every 10 articles). I'm using Firefox on Mac OSX. JuliasTravels (talk) 16:33, 6 September 2015 (UTC)Reply

Seems to be Firefox specific. On Safari I don't have this problem at all, but now when trying Firefox (on Mac), there is indeed not only the issue of banners not showing up but also banners that are scaled in weird ways; sometimes they look like narrow slices and sometimes like huge things that you'd like to put a crop tag under. And occasionally the banner looks entirely normal. The funniest thing is that you can stay at an article and reload the page and get different results each time... ϒpsilon (talk) 16:59, 6 September 2015 (UTC)Reply
I have seen this with Firefox on Windows, on several different PCs. I have also seen this with IE10. The most common one that I see is the banner only displaying the top half of the image - down to the bottom of the title, with the menu below. I am seeing it slightly less often 1 in 10 or so. AlasdairW (talk) 18:06, 6 September 2015 (UTC)Reply
See it most of the time on Firefox. Mentioned it above when the banner method was changed. Appears to display minimum height of graphics to show text of name and menu, then scales oddly, or display almost nothing. --Traveler100 (talk) 19:26, 6 September 2015 (UTC)Reply
I'm using the latest Firefox on Mac (I think). 64 bit version 40.0.3 .Bertha Benz Memorial Route looks fine. Also works fine under Chrome and Safari. --Andrewssi2 (talk) 23:22, 6 September 2015 (UTC)Reply
Just looking at one will not show the problem, particularly if you have already loaded that image on the machine. Wondering if we should revert the bannerpage back to the old method. People have invested a lot of effort in uploading images and now visitors to the site are seeing no or poor representations of them. --Traveler100 (talk) 05:59, 7 September 2015 (UTC)Reply
Actually first time loading that page for all browsers. Proper way to do this is reproducible test cases. What are they? --Andrewssi2 (talk) 06:08, 7 September 2015 (UTC)Reply
Can anyone seeing this problem add the following to their userpage css (User:SomeUser/common.css) and report whether it solves the problem:
.wpb-topbanner {
	overflow: auto;
}
-- Ryan • (talk) • 06:56, 7 September 2015 (UTC)Reply
On an initial test that does appear to have improved things. --Traveler100 (talk) 07:32, 7 September 2015 (UTC)Reply
For me it didn't fix the problem, although, where I was previously only encountering the issue of banners not displaying at all, I'm now also getting the narrow stripes / top half banners as Ypsilon described above. JuliasTravels (talk) 16:24, 7 September 2015 (UTC)Reply

────────────────────────────────────────────────────────────────────────────────────────────────────

I've created phabricator:T111710. Hopefully the suggested fix will resolve the issue, although I haven't tested it. -- Ryan • (talk) • 17:40, 7 September 2015 (UTC)Reply

@JuliasTravels, Traveler100: User:Sumit.iitp has indicated that this bug should now be fixed, and I wasn't able to reproduce it after hitting about a dozen random pages with banners. Can anyone else who was seeing the issue confirm that it is now fixed? -- Ryan • (talk) • 04:55, 10 September 2015 (UTC)Reply
Still no ToC displayed for me under Win8/Firefox when logged in or logged out. They do now load under Chrome when logged out. Banners also very slow to load -but at least they are loading last now and not delaying the rest of the page. Sorry, no banana yet. 148.122.187.2 06:45, 10 September 2015 (UTC)Reply
For me it does seem to be fixed. I've hit at least 30 random pages and haven't seen a single issue. Thanks for all your efforts, Ryan and Sumit! JuliasTravels (talk) 08:31, 10 September 2015 (UTC)Reply
Thanks JuliasTravels - I've indicated in the ticket that the issue is fixed and the ticket can be closed. -- Ryan • (talk) • 15:21, 10 September 2015 (UTC)Reply
Why on earth would you do that when you've been told quite clearly that it's NOT fixed when using the latest version of Firefox under Windows 8 ?
While the ToC appears for me if I switch to Chrome it certainly does not appear at all, EVER, under the Firefox I usually use and it's really quite annoying. BushelCandle (talk) 15:33, 10 September 2015 (UTC)Reply
It looks like it is fixed for me on Windows 8.1 Firefox 40, but now banners are not displaying at all on difference listings. This may be an acceptable consequence, as I am not bothered about seeing the banner when checking recent changes (except when the banner itself is changed).AlasdairW (talk) 22:22, 10 September 2015 (UTC)Reply
Appears to be fixed for me using Firefox 40, have not seen the problem since the change made. --Traveler100 (talk) 18:29, 11 September 2015 (UTC)Reply
I'm using Firefox 40.0.3 in a Windows 8.1 environment. Banners don't display when I'm in a window like this, but they do when I'm in a regular window like this. Ikan Kekek (talk) 09:57, 12 September 2015 (UTC)Reply

TOC placement edit

I've now completely lost any table of contents (ToC) whatsoever! (Latest Firefox on Windows 8).

Since the previous placement of the ToC obscures part of the banner image and makes it ugly AND means that the ToC text is smaller than optimal, wouldn't it be better to have the ToC block underneath (but immediately abutting) the banner image? BushelCandle (talk) 19:11, 7 September 2015 (UTC)Reply

This suggestion was made previously on this page by 80.234.185.120 - Special:Diff/2846870/2846871.
If anyone wishes to try out moving the TOC below the banner, adding the following to your userspace CSS (User:SomeUser/common.css) should make it happen:
.wpb-topbanner-toc {
	position: inherit;
}
-- Ryan • (talk) • 20:19, 7 September 2015 (UTC)Reply
Thanks for the suggestion, Ryan, but after creating User:BushelCandle/common.css I'm afraid I still don't have any ToC at all, never mind one that is not obscuring the lower part of the banner. BushelCandle (talk) 20:40, 7 September 2015 (UTC)Reply

Page banner file source edit

Swept in from the pub

I need some help understanding things: I wanted to crop banner of Kłodzko, because it is in Category:Banner_needs_cropping. The file name for the banner is not given locally ({{pagebanner|Pagebanner default.jpg}}), but at Wikidata, as an item wikivoyage banner. Because the file has very low resolution and cropping was not possible, I decided to delete the banner from wikidata, which as I expected would lead to use of default banner. But to my surprize, the custom banner keeps showing up. Where is it uploaded from? Thanks for explanation. Danapit (talk) 18:31, 13 September 2015 (UTC)Reply

The "barbarian" solution would be to just insert the file name of the cropped banner in the pagebanner tag and call it a day. Wikidata doesn't seem to override it for this article. ϒpsilon (talk) 18:53, 13 September 2015 (UTC)Reply
+1 Barbarian solution :) Setting the name locally and Wikidata as a courtesy works well. --Andrewssi2 (talk) 23:18, 13 September 2015 (UTC)Reply
Thanks for your comments. Now the default banner is displayed also without "barbarian" solution. I don't know why it took a while. Danapit (talk) 07:44, 14 September 2015 (UTC)Reply

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

Swept in from the pub

Since early August I have created 27 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 27 discussions and indicate in each of the discussions which banner you prefer seeing at the top of this article.

ויקיג'אנקי (talk) 05:33, 23 September 2015 (UTC)Reply

Should Wikivoyage not crop banners? edit

Swept in from the pub

I pushed a few changes to the WikidataPageBanner extension specifically aimed at mobile this weekend. before and after

(You can see for yourself here!) Note no change on desktop! yay!)

However I noticed, if for the Agra example I used the original banner rather than the cropped banner, and applied the origin parameter to do manual cropping, it looked even better on mobile and arguably even better on desktop. (See this example) and this after screenshot.

I thought I'd bring this to your attention. It's obviously a big mindset change... but would it make sense to start using automatic cropping rather than manually cropping? What is needed to enable that? Jdlrobson (talk) 21:08, 18 September 2015 (UTC)Reply

I lack the knowledge to fully understand what this would mean or what would be required technically, but automatic cropping of any kind seems to have one major problem. It does not allow for aesthetic choices in terms of eliminating less desirable parts of images - which we do a lot. The Agra banner is an example of a beautiful source image that can be used in its entirety, but unfortunately that's not the case for all original images. Just a first thought. JuliasTravels (talk) 10:57, 19 September 2015 (UTC)Reply
Hi Jdlrobson , you haven't actually described at all what your change actually was :)
Looking through your links, I get the impression that the change can crop source images for banners automatically. However on Wikivoyage we require all banners to have a ration of 7:1 and therefore automatic cropping is not needed, and in fact not actually desirable at all (for reasons that JuliasTravels stated ) --Andrewssi2 (talk) 11:25, 19 September 2015 (UTC)Reply
Also, what struck me immediately is that the banner size I understand you would like to implement to would make our articles look more like our competitor's.
And as others have asked, would someone have control over what part of the photo (upper/middle/lower/some corner) would be used as banner? Otherwise the result would more often than not look entirely ridiculous (e.g. some asphalt with some feet and legs or just the blue sky). ϒpsilon (talk) 11:36, 19 September 2015 (UTC)Reply


Maybe summarising as follows will help: a 7:1 ratio and the current height restrictions should be revisited for mobile devices. The extension provides support for cropping by ensuring the width and heights of the banners meet your specs on desktop and allowing editors to use an origin parameter to specify a focal point (so yes editors can still control where to focus in an image). I'd encourage people to play with the banner code on our test instance with different image sizes and soon Wikivoyage (Wednesday) to explore whether using a different image banner ratio/taller banners provides a better banner experience for mobile users whilst retaining the same experience for desktop users. Potentially you may find cropping is less important than before and that the software can enforce photo requirements.

To be clear I'm not suggesting any changes to desktop banners aesthetic appearance im just suggesting you revisit banner requirements with mobile in mind now you have a more powerful option in your hands that cannot be achieved via templates!

Please let me know if more clarification is needed. Jdlrobson (talk) 14:45, 19 September 2015 (UTC)Reply

The problem is that you are using a non 7:1 image size for Agra, therefore everyone here will likely be confused as to your intention. I suggest that you use the banner we use here on Agra --Andrewssi2 (talk) 23:09, 19 September 2015 (UTC)Reply
I think what Jdlrobson is proposing is we use uncropped images (i.e., non 7:1 images) and then use the "origin" parameter of the extension to focus the banner on the part of the image we want displayed.
I'm still confused about what is being proposed though:
I'm suggesting the origin parameter can do a lot more for you then manually cropping images to be 7:1 and that using 7:1 is doing harm to your mobile experience..IThe banner here (zoom aside) has the same dimensions as the banner on Agra in Wikivoyage no? However if you view its mobile equivalent it looks much better than before. If you inspect the banner you'll see it uses the original image rather than the uncropped image. The image used for desktop and mobile must be exactly the same resolution on both, using a different image for both mediums is currently not possible. A 7:3 image can look like a 7:1 image on desktop but look taller on mobile where vertically you have more space. Jdlrobson (talk) 06:38, 20 September 2015 (UTC)Reply
If we go back to the original post, we have before and after examples. In terms of mobile I could understand this approach for older smart phones / feature phones with low resolution screens (e.g. 320 pixels), but for the latest Android or iPhones I don't see the Desktop banner as being a problem at all.
I would suggest that technology will make the experience some of us have today on the iPhone 6 / Galaxy S6 fairly widespread in a couple of years. Won't this make things more complex when the problem will go away by itself by virtue of the adoption of newer technology? --Andrewssi2 (talk) 10:48, 20 September 2015 (UTC)Reply
It's not a question of resolution, it's a question of aspect ratio. The display on a mobile telephone is taller than it is wide, which is backward compared to a desktop PC. If anything, desktop screens have been getting wider (8:5 instead of 4:3) since the mid-2000s (decade). K7L (talk) 12:16, 20 September 2015 (UTC)Reply
Yup exactly. The extension banners should pick the right image for the right device (we still need to fine tweak this) but we have more options now we are not using a template. I must confess I don't know exactly what the right aspect ratio is but if banners have a focal area of 320px by say 200px it will look great on mobile. You may find using banners with double the height of the current ones is all that is necessary (we can clip the bottom half easily on desktop) Jdlrobson (talk) 19:11, 20 September 2015 (UTC)Reply
Unless your audience is "well-off people in the developed world only", then it's going to be a long time before "the problem will go away by itself". Newer technology means newer technology for people who can afford it. The "old" technology of low-resolution screens will be in the hands of teenagers, blue-collar workers, and the rest of the world for a very long time. (This might make more sense: You know all those people who still have flip phones? When you started thinking about buying an iPhone 6, they started wondering whether they could afford a cell phone with a low-resolution screen.) WhatamIdoing (talk) 12:54, 20 September 2015 (UTC)Reply
I'm not sure why you put this statement in WhatamIdoing when it was clarified that the rationale was around screen dimensions and not resolution, but you are wrong. The original iPhone was released in 2007 and had a resolution of 320×480, and adoption and corresponding resolutions have been increasing rapidly and that includes the important lower end of the smartphone market.
Wikimedia statistics show clearly that the number of visitors to Wikimedia sites on mobile devices (about 50% of the total audience now) are overwhelmingly with mobile devices with recent (past 3 years) specifications. --Andrewssi2 (talk) 20:41, 20 September 2015 (UTC)Reply
Because I don't believe that "the problem" will go away on its own, because I don't believe that it's a good idea to design a site to assume that it will just go away, and because I don't think that designs should be based primarily on capabilities of people who can already use the site (versus those who want to use the site, but can't because the design makes it painful to use on the devices that they can afford). If you want more readers, and if you want more global readers, then the mobile design needs to work (and work well) on a low-budget phone sold in India a couple of years ago, and not just for the latest iPhone. WhatamIdoing (talk) 21:33, 22 September 2015 (UTC)Reply
The site as it is works perfectly fine with a low-budget phone sold in India today. Your outrage at the iPhone owning 1% of capitalists is somewhat misplaced. --Andrewssi2 (talk) 22:53, 22 September 2015 (UTC)Reply
I've got no problem with Apple or iPhones. My only problem with Android devices is their lousy security model. I'm not outraged about anything—not even the fact that Android's failings has led to some individual users getting hacked. However, I am aware of my privilege, and the fact remains that 99% of the world can't afford a new smartphone every year (or even at all). If you design for "today's" (brand-new) smartphones, then you exclude everyone who can only acquire hand-me-downs and castoffs.
The WMF had the opportunity to do some developing-world simulation testing at one of the big internet companies a while ago. I don't know if a formal report was ever written up about it (presumably it's on mw: if someone did). Essentially, you take your website into a room with an elaborate copy of the internet systems for various developing countries, and you see how much you can use. The results were not pretty. "Works perfectly fine" was not a statement that any of the staff present used to describe the results. WhatamIdoing (talk) 12:47, 23 September 2015 (UTC)Reply
Hi Jdlrobson, I agree the banners would look better on mobile (in portrait mode, anyway) with a different aspect ratio than 7:1. Looking at the test pages you link to, the banner extension seems to auto-crop (for lack of a better word) the source image differently depending on whether it's mobile or desktop. If that's the case, it's an interesting solution that provides more flexibility on how banners are displayed. Before going down that road though, I think we'd need to feel comfortable that the job the banner extension does cropping images is nearly as good as what we do manually now. Otherwise, it seems to open a can of worms for something that I'm not sure is a big problem. Also, how would the 8000+ legacy 7:1 banner images be handled? -Shaundd (talk) 04:35, 21 September 2015 (UTC)Reply
Hi Shaundd the great thing about this change is its backwards compatible, so you can update those 7:1 images over time, if they are never updated they'll still work, just won't look as good. The goal would be to increase the height but leave the top half the same as it currently is on desktop. I guess the first step would be to try 7:2/7:3/7:4 banner sizes on a sample of 10 articles to see whether this is plausible and see whether this improves mobile rendering. If we find a better ratio I'd suggest a vote on this page to switch the default to the new proposed one using the 10 examples. The change will go live on Wednesday so you'll be able to experiment with ten pages on that date. Does that sound like a good idea?Jdlrobson (talk) 17:40, 21 September 2015 (UTC)Reply
Hi Jdlrobson , this change on Wednesday will have no impact on the existing Banner template right? (changes will be limited to the experimental pages) --Andrewssi2 (talk) 22:23, 21 September 2015 (UTC)Reply
Correct. You should notice no difference anywhere (there are no experimental pages on wikivoyage that I know of). However on Wednesday you will be able to experiment on any test pages you choose to with larger banners and I encourage you to do so. Ultimately this is your decision as editors but I highly recommend you revisit the ratio and make this site even more kick ass then its competitors which currently struggle much more with their own mobile experiences! Jdlrobson (talk) 22:27, 21 September 2015 (UTC)Reply
I'll certainly give it a test. It might not be until the weekend though -- the job that pays the bills is quite demanding right now. -Shaundd (talk) 05:29, 22 September 2015 (UTC)Reply
I look forward to seeing how it works! I'm certainly open to a better way of implementing banners, although such a change should require a decent period of evaluation and discussion before formal implementation. Andrewssi2 (talk) 22:59, 22 September 2015 (UTC)Reply

Update edit

Has anyone explored this to see if they might work better? Jdlrobson (talk) 19:11, 7 October 2015 (UTC)Reply

Hi Jdlrobson, I played with the Origin parameter on a couple of banners. It seems to try to fix the height of a banner to 300px and then scales the width accordingly. The y-coordinate moves the focus up or down in the original image but the x-coordinate has no impact (presumably because the full width of the underlying image is being used). Is it supposed to work that way? -Shaundd (talk) 05:43, 8 October 2015 (UTC)Reply
Thanks for the reply and exploration Shaundd!! For desktop it enforces a certain maximum height (as you say this is 300px) but allows you to use images that are taller than 300px and as you say move the focus up and down with the y-coordinate. The x-coordinate will kick in at a lower resolution on a mobile view, you can test this by shrinking your screen on the mobile site/Vector to less than 400px. This is the killer feature - you will be able to get better banners displayed on mobile than currently, which is primarily what this parameter was added for. Does that make sense? So to summarise, there should be little different on desktop but a big difference on mobile. Jdlrobson (talk) 19:27, 9 October 2015 (UTC)Reply
Hi Jdlrobson -- I haven't been able to replicate what you described above in mobile view when I use the origin parameter. When I specify origin=x,y, it fixes the height to 300px and uses the full image width as I described above. It doesn't seem to matter what size I shrink the screen to, it always displays the full width of the image. On the other hand, if I view an existing banner (with no origin parameter) and shrink the screen as you described in mobile view, at a certain point it switches to focus in on what seems to be the middle of the banner. I do like what it does in mobile view, it makes the banners more attractive on my cell phone. It doesn't carry over to my 7" tablet though (a 2nd gen Nexus 7), it just displays the traditional banner in mobile view.
The pages I tested the origin parameter on are:
  1. Piran . 1565x1200 . 1412x300 (desktop) . 1000x300 (mobile)
  2. Amboise . 7000x2743 . 1412x300 (desktop) . 1000x300 (mobile)
  3. Vancouver/City Centre . 4200x2794 . 1412x300 (desktop) . 1000x300 (mobile)
The first column after the page name is the original image size, the second column is the size of the banner in desktop view, and the third column is the size of the banner in mobile view. Based on my experience, the width of the banner will vary depending on the resolution of the display. By comparison, banners currently display as 1412x202 on my desktop, so the origin parameter does alter the aspect ratio from the current 7:1. -Shaundd (talk) 22:03, 12 October 2015 (UTC)Reply
Shaundd all those banners look ammmazzinnggg on my mobile phone with the use of the origin parameter. Not so good without: http://m.imgur.com/vNsOyFg,dbaoAUZ,euKY712,hagQgZi
Are you sure you are testing at the right resolution? I'll have to test the desktop equivalents when I'm not mobile...
Jdlrobson (talk) 00:47, 13 October 2015 (UTC)Reply
Perhaps I was misunderstanding the first time I tested. Based on your link, I'm guessing what you want to see on mobile is the banners from the first two images, correct? -Shaundd (talk) 04:47, 13 October 2015 (UTC)Reply
the issue I'm keen to solve is that on many articles due to the nature of mobile being width constrainted (lets say at 320px) banners render in such a way that it's difficult to make out what they are actually pictures of. The examples in ttp://m.imgur.com/vNsOyFg,dbaoAUZ,euKY712,hagQgZi show that mobile banners when taller carry much more wow factor (in all cases I can actually make out what they are pictures of). In desktop they should look the same as they currently do (if they don't than that is a bug that needs fixing). London I'd an example of a banner that might benefit from this.

Jdlrobson (talk) 15:05, 13 October 2015 (UTC)Reply

On Jupiter, the banner is too tall. Its minimum height seems to be set at 300px but that's too tall for any width less than 2100px. Powers (talk) 22:05, 3 November 2015 (UTC)Reply

Banners no longer showing edit

Swept in from the pub

I'm using the monobook skin and the banners are no longer showing at all. :( -- WOSlinker (talk) 21:26, 24 September 2015 (UTC)Reply

I'm not 100% positive, but I don't see the banner HTML in the page when using Monobook. I thought it might be due to the recent Javascript fix, but after disabling Javascript in my browser I think it may be an extension issue. I'd suggest creating a phabricator: ticket. -- Ryan • (talk) • 22:08, 24 September 2015 (UTC)Reply
Is Monobook even supported anymore? Powers (talk) 01:45, 25 September 2015 (UTC)Reply
It should be! I have the impression that lots of editors, who used Wikipedia before Vector came, still use Monobook. Some liked the new skin, others did not, and there has been no great reason (nor any push) for the latter to migrate. --LPfi (talk) 09:54, 25 September 2015 (UTC)Reply
There was a bug in the code. Fix on the way - https://phabricator.wikimedia.org/T113746 Jdlrobson (talk) 15:25, 25 September 2015 (UTC)Reply
If memory serves, I believe that Monobook is semi-officially in the "bug fix" level of support: the devs keep it working, but they don't plan any major improvements to it. This implies that someday, if it becomes too complicated to maintain it, then it may be removed, but there are no plans to do this, and I'd be surprised if that end-of-life moment happened this decade.
I believe someone said that (very) approximately 40K active users at en.wp are using Monobook. It would be reasonable to assume that the percentage is similar at other larger/older wikis, and lower at smaller/newer ones. It's not as popular as it used to be. WhatamIdoing (talk) 00:56, 27 September 2015 (UTC)Reply

Breadcrumb menu and map icon dropping below the banner edit

Swept in from the pub

As the headline says, when I open an article I see the banner on the top of it and the breadcrumb menu and icon below it (before the text). I'm using Safari 8.0.8 (on a Mac) and yesterday the articles looked completely normal. In Firefox the articles look normal. Is it again someone playing around with the banner template? ϒpsilon (talk) 04:24, 24 September 2015 (UTC)Reply

This looks like a change that was made to the banner extension - Do not add banner inside #bodyContent. User:Jdlrobson can probably confirm. For what it's worth, the change seems fine to me - as far as I'm aware, on most web sites breadcrumbs are placed under the top banner. -- Ryan • (talk) • 04:34, 24 September 2015 (UTC)Reply
Since when has the page banner image been above the location breadcrumbs? --Traveler100 (talk) 05:42, 24 September 2015 (UTC)Reply
Not sure which is better, being different from what you are used to is always firstly a negative reaction. I guess we should keep it a week or so and see how we feel then. --Traveler100 (talk) 06:42, 24 September 2015 (UTC)Reply
I think I prefer the new arrangement. It makes the banner/title more visible. I also think that we should try having breadcrumb aligned to the right. Syced (talk) 11:21, 24 September 2015 (UTC)Reply
Hey! those breadcrumbs appear in contentSub which appears under the first headings on all wikis for example mediawiki so this is a side effect of making the banner override the heading rather than hack itself to look like a heading.
In code it's called subTitle so code wise it makes sense for the subtitle to appear below the title. Design wise for this use case maybe not.. I'm not sure.
I sadly didn't pick this up before to discuss as none of the examples on http://en.wikipedia.beta.wmflabs.org/wiki/WikidataPageBanner_example_3 have breadcrumbs. I'll rectify that for you for future.
What's generating the tagline? Am I right in guessing it's Extension:GeoCrumbs? If so and you decide on a different placement we will have to add support to that extension. Jdlrobson (talk)
This change is awful. From a navigational standpoint, it made total sense before, zooming in from the global level at the top and going down to the destination in question and then navigation within that destination's article
External navigation down to this destination > This destination > Internal navigation within this destination > Content within this destination
Now it's all out of order:
This destination > Internal navigation within this destination > External navigation down to this destination > Content within this destination
We could still discuss changing it later if there is really a reason for it that everyone can get behind, but this should be reverted immediately pending discussion of and consensus for the change, because this is simply not the way things are supposed to work around here. Especially for sitewide changes such as this, it's supposed to be proposal, then discussion, then consensus, then implementation of the change. Not change implemented out of the blue, adjustment period to see if we like it, possible discussion, and then "oops there's not unanimous consensus to change it back, guess we'll keep it". Whoever did this, please change it back immediately, the sooner the better. Texugo (talk) 17:32, 24 September 2015 (UTC)Reply
As Jdlrobson notes, the change was a result of the fact that we were previously mis-using banners to move the article title within the article body content, so there is a strong argument to be made that it's unreasonable to demand an immediate revert of a global fix that exposed a bug in our implementation. That said, if there is a strong desire to move the breadcrumbs back above the banner, as Jdlrobson suggests the geocrumbs extension can be modified to allow positioning of the breadcrumbs outside of the article content, which would match your suggestion of moving global navigation outside of article content. My preference would be to leave things as they are now, however, for reasons stated above. -- Ryan • (talk) • 17:59, 24 September 2015 (UTC)Reply
If you want I can make some minor js/css changes which will correct it for 99% of users. Just let me know and I'll do it - this is better than a revert (but will still show them under the heading for non-js users). I've setup a bug to make sure we get this fixed so you at least have the option to revert back to the old bug. Jdlrobson (talk) 18:19, 24 September 2015 (UTC)Reply
I don't care if it's not technically reverted back, but if it's possible to revert the appearance back, as Jdlrobson suggests, that would keep us much more in line with our standard procedure for approving sitewide visual changes, so I don't think there is any question that that is what should be done at this point. Texugo (talk) 18:28, 24 September 2015 (UTC)Reply
My only concern with a JS/CSS solution (as opposed to the suggested fix in the phabricator ticket) is that we ensure that it isn't done in a way that will penalize us with search engines. Mucking about with the <h1> tag can be dicey where SEO is concerned, and we've already been whacked a few times recently by Google due to page banner changes. -- Ryan • (talk) • 18:35, 24 September 2015 (UTC)Reply

You should be able to put the following in MediaWiki:Common.js:

$( '#contentSub' ).insertBefore( '.ext-wpb-pagebanner' ).addClass( 'visible' );

and in MediaWiki:Common.css

#contentSub { display: none; }
#contentSub.visible { display: block; }

I've never heard of such a change impacting SEO. Given the amount of SEO concerns I'm hearing on this page, it might be worth asking the Foundation's discovery team to investigate that and identify ways to improve Wikivoyage's page rankings. It's my belief that by better features and slicker designs more people will link to Wikivoyage and you will drive up your search results more than any tiny penalties due to things such as positioning. Jdlrobson (talk) 19:01, 24 September 2015 (UTC)Reply

The above change should be fine since we're not touching the <h1> tag - past banner changes involving the page title and top heading have caused articles to drop significantly in Google rankings. The larger discussion about SEO would be valuable, but should take place at Wikivoyage talk:Search Expedition to avoid confusing this thread. -- Ryan • (talk) • 19:12, 24 September 2015 (UTC)Reply
I've made the tweaks and it should be back to the way it was. Let me know what the preferred layout should be. Please subscribe and poke the ticket for a more long term solution. Jdlrobson (talk) 21:18, 24 September 2015 (UTC)Reply
Now it is worse. The map icon has not moved with the breadcrumbs as is squashed between the banner and the text. Please experiment with site wide changes outside of main-space in future. --Traveler100 (talk) 06:54, 25 September 2015 (UTC)Reply
And in addition, the map icon's upper rim is covered by the banner and while the breadcrumb has moved back up, its text (and unless something's suddenly wrong with my eyes, the article name, UNESCO icon and featured article) has become remarkably larger... ϒpsilon (talk) 13:43, 25 September 2015 (UTC)Reply
So the map icon is no longer overlapping the banner but if there is an image at the top of the article they will overlap. --Traveler100 (talk) 13:40, 26 September 2015 (UTC)Reply

First impressions edit

Positive: I like the banner image at the top of the page, looks professional and clean; the map icon below the banner image is somehow more obvious, being discoverable to new users is important.

Negative: As stated above, page content listed before breadcrumb hierarchy does not feel right; and the big negative - when you want to go to the country page from a city article and move you mouse too slowly down from the top of the page the drop down sub-section titles come down over the breadcrumb line making it difficult to see and select.

--Traveler100 (talk) 19:19, 24 September 2015 (UTC)Reply

On this subject if we made it possible to add external links to banners is there any reason the map can't be a banner icon? e.g. http://en.wikipedia.beta.wmflabs.org/wiki/WikidataPageBanner_example_3 If this is desired does someone want to open a phabricator ticket? Jdlrobson (talk) 21:23, 24 September 2015 (UTC)Reply

IIRC, we did test adding the map parameter to the banner icons at one point, but only on a few articles and it was eventually killed off, I think due to the need to move all geo coords into the banner template. Wouldn't be opposed to revisiting moving the icon. James Atalk 10:30, 28 September 2015 (UTC)Reply
I use Firefox and I'm getting the map icon on top of the article text at the right hand end of the first line. Also, when editing and doing a preview, an old-style table of contents appears (in addition to the usual menu bar on the banner), meaning it is far from a true preview of layout. Is there a fix for these two issues? Nurg (talk) 08:29, 30 September 2015 (UTC)Reply
Moving the geo coords into the banner could maybe done with a bot. Or maybe we need to add an additional space after the geo icon so that it does not overlap text or images at the top of articles. --Traveler100 (talk) 05:32, 2 October 2015 (UTC)Reply

Regarding consensus policy in Engvoy edit

Swept in from the pub

If for example, four or five users support a specific change in a specific discussion page, while one or two users object that change be made... would the change be made or not per Engvoy policy?

My impression is, from comments made by several users, that the Engvoy's Wikivoyage:Consensus actually means that in any cases of difference of opinions, one or two users get to veto decisions made by 4-5 users. Am I right ?

I will try to explain the main reason to why I think it is better to avoid a situation in which a small minority (1-2 users) is given the power to veto decisions made by a majority of 4-5 users ... when I recently suggested we use some of the alternative banners I created for Hebvoy on Engvoy, there were one or two users here on Engvoy whom noted that they would oppose the usage of ANY new alternative banners, even in the instances when the new alternative banners are a real improvement, just because they oppose having people suggest new alternative banners be used. If the Wikivoyage:Consensus policy actually means that a minority of 1 or 2 users can veto the preference of 4-5 users, because "it is not a clear consensus", I am afraid that in the future it would be impossible for me to continue suggesting that the Envoy community considers using new alternative banners. ויקיג'אנקי (talk) 01:21, 2 October 2015 (UTC)Reply

Well, take Brooklyn/Coney Island and Brighton Beach‎‎ as an example. I thought your substitution was premature, so I asked the two people who were on record in opposition to the change whether they were willing to reconsider, in light of Powers' proposal. One of those previously in opposition has changed his mind. I will wait a day or two to see what Danapit has to say, as there's no reason to rush, but with only one person now opposed to the change and 5 in favor, I consider that a clear consensus. It really depends how many people have expressed an opinion. 2-1 is probably not a clear consensus, but 5-1 is, and 6-2 would be a pretty good consensus, I suppose. Part of the point I'd make, though, is that within reason, more discussion is better, not worse, and helps to create and sustain a collegial atmosphere, where people don't feel like there are actions taken quickly and forcefully. Ikan Kekek (talk) 01:39, 2 October 2015 (UTC)Reply
But what about a 4 - 1, or 5 - 2, in which the one or two people opposing are doing so constantly without a real justifiable reason? (in this case, they stated they are doing so just because they oppose having new alternative banners in general...) would their opinion be taken into consideration in the tally or canceled/striked out ? I am trying to point out the major flaw of the vetoing system (please explain how to overcome this specific flaw). ויקיג'אנקי (talk) 01:49, 2 October 2015 (UTC)Reply
My impression is that even those who would prefer for you to stop suggesting changes to existing banners (especially good existing banners) would not stand in the way of a substitution they considered clearly superior. However, in my opinion, just based on numbers, 4-1 looks like a pretty good consensus. I think that it's not just a question of numbers, though; the strength of support and opposition and whether there are substantive arguments in either or both directions should be part of the discussion, too. Ikan Kekek (talk) 02:02, 2 October 2015 (UTC)Reply
Taking another example Dallas/Downtown 1 support change, 1 moderate support change , 1 keep original and 2 change on Dallas page instead. Not sure how that is describe as majority consensus for change. I have also commented in the past on changing banners on pages that already have banners as not the most productive activity (just by seeing how much time it takes with others making comments) but not against it totally and have supported changes were this difference is notable such as with Food. --Traveler100 (talk) 05:19, 2 October 2015 (UTC)Reply

Related to the above questions (but not specific to banners), there was a lengthy discussion about making it easier to determine consensus at Wikivoyage talk:Consensus#Wikivoyage:Consensus/Draft, but it did not get enough participation and agreement to allow policy to be changed. I don't think I currently have the mental stamina to try to drive that thread to any sort of resolution, but if others are interested in doing so please plunge forward. -- Ryan • (talk) • 01:47, 2 October 2015 (UTC)Reply

I'm not sure where the flaw is here. Clear consensus does not mean unanimous agreement.
"in this case, they stated they are doing so just because they oppose having new alternative banners in general" this statement is concerning if it refers to some of my votes. I am opposed to the replacement of good banners with new suggestions with no benefit or are less interesting, however my voting record should be clear that I have supported many of your suggestions that are clearly superior and it is very disingenuous to suggest otherwise. There isn't anyone voting 'no' by default. Andrewssi2 (talk) 06:13, 2 October 2015 (UTC)Reply
re: ויקיג'אנקי: "in this case, they stated they are doing so just because they oppose having new alternative banners in general", you say. In the first place, you did not bother to explain when initiating the discussions why your new suggetions are superior to the existing banners. Why do you expect others to spend their time explaining their preferences? Otherwise I understand, that for achieving consensus, simply stating keep / change is not helpful. I'll try my best to add a couple of words of explanation on the next occasion I will make a statement like that. Danapit (talk) 10:12, 2 October 2015 (UTC)Reply
I was one of the users who posted a message regarding consensus. Of course consensus is not unanimity, and if there's a 5 to 1 division in simple preference, a change is fine. However, as our policy page states, and as we usually work, outstanding suggestions and concerns should at least be addressed. In the case of Dallas/Downtown for example, there was no clear consensus to just replace the banner. Several users suggested to use the proposed banner for Dallas instead. Just ignoring those suggestions and proceeding to change the Downtown banner is not in line with our common consensus. JuliasTravels (talk) 10:59, 2 October 2015 (UTC)Reply
Also, I too want to underline that not one single user has simply spoken against all of your banners. Even the ones who would prefer not to have these discussions have supported changes where they consider your proposals to be superior. Suggesting otherwise is non-constructive and impolite. While usually simple keep or change "votes" are discouraged, I'd also say that for users who have made it clear that they prefer to only change a banner when it is obviously better than the existing one, it should be perfectly acceptable to be brief in this matter, considering the cookie cutter approach you've chosen for your suggestions. JuliasTravels (talk) 11:08, 2 October 2015 (UTC)Reply

Consensus is not determined by counting votes, so it's disingenuous to complain that certain combinations of vote counts could result in decisions going against the majority. Powers (talk) 18:32, 2 October 2015 (UTC)Reply

re: Danapit's comment "In the first place, you did not bother to explain when initiating the discussions why your new suggetions are superior to the existing banners" - I think this cuts to the heart of the problem some people have with ויקיג'אנקי's campaign of making banners for articles that already have them.
It would be fine if he concentrated on making banners for articles whose existing banners are ugly, uncharacteristic of the destination, etc., but instead it appears that ויקיג'אנקי simply targets articles at random. This is problematic because he is also open about the fact that he has no familiarity with the destinations for which he makes banners. It could be that any given banner he's trying to replace was crafted in a well-thought-out way by an editor who is familiar with the destination (I'll admit I blanch at the thought of Buffalo coming onto his radar screen next, and the prospect of the carefully deliberated banner I created being replaced wth some clichéd cookie-cutter skyline shot of the type he seems to prefer). When that point has been brought up by others, ויקיג'אנקי has responded by saying that in most cases there's no way of knowing what degree of familiarity a banner's creator had with the destination or what was behind the decision of which image to use - but the fact is that even in the best-case scenario it's a wash; we simply go from one randomly chosen image to another.
The question, in my mind, then becomes: if not to improve the respective articles, then why is ויקיג'אנקי making all these new banners in the first place? (Even if they're for hebvoy, why propose them over here too?) And - speaking at least for myself and also, I suspect, for many others - what I am left with is the impression that one-upmanship plays a considerable role; that it's simply about replacing others' content with his own as an end in itself, without so much as a cursory consideration as to which version is of better quality. (That may or may not be true, but that's the overall feeling I'm left with, and I suspect I'm not the only one). But in reality, there's no one watching in the background and "keeping score" as to how many banners or how much of our content belongs to any particular user; no prizes to be won for the editor with the most thumbprints on the most articles. In other words, Wikivoyage is a collaboration, not a competition.
It bears mentioning that ויקיג'אנקי is technically correct when he says that in a wiki setting no one has the right to be upset when their own content is altered by some other editor, but given all we know about his banner-making process - articles chosen at random, creator has no familiarity with the destination in most cases, he spends by his own admission no more than 30 minutes on each one - I still say the whole effort flies in the face of the friendly, collaborative ethos of this site.
-- AndreCarrotflower (talk) 02:09, 3 October 2015 (UTC)Reply
We may be talking about a woman, you know. I'm not sure whether I'm reading the name right, but it looks like "Vicky g'Yankee" to me. I just don't know what the gimel there means. Ikan Kekek (talk) 02:21, 3 October 2015 (UTC)Reply
With a little coaxing, Google Translate gives "Wikijunkie". Anyway, given the gender breakdown of the overall WMF contributor community, I was playing the odds, but your point is well taken. -- AndreCarrotflower (talk) 03:43, 3 October 2015 (UTC)Reply
I have to completely agree with you AndreCarrotflower, ויקיג'אנקי self stated mission is to replace the banners of prominent articles throughout English Wikivoyage site with his own, probably because he is under the interesting notion that he is a 'photoshop expert'. One-upmanship does appear to drive this. I'm also concerned by the angry comments at Talk:Kaliningrad#Alternative_banner_for_this_article.3F
From our Banner expedition:
"Poor quality banners may be replaced by better quality banners. Banners may be replaced by more appropriate banners. Correctly sized banners are by default more appropriate than incorrectly sized banners. Leave an edit summary explaining why the new banner is more appropriate. If anyone disagrees with a substitution for reasons other than correct sizing or image quality, temporarily replace the banner with the appropriate default banner and get consensus on the article talk page."
I propose enforcing this going forward. If ויקיג'אנקי want to propose alternative banners then he just needs to explain why he is proposing the change. Just using it on Hebrew Wikivoyage is an irrelevant reason. Andrewssi2 (talk) 09:33, 3 October 2015 (UTC)Reply

What I never quite got is why there are hardly ever any new proposed banners for articles that don't already have them. Many destinations in Nicaragua could use one, for instance... Hobbitschuster (talk) 10:50, 3 October 2015 (UTC)Reply

Replying to some comments above, I'm concerned that the discussion is becoming borderline abusive towards an individual. I don't think there is harm in suggesting new banners for aesthetic reasons, and I was under the impression that these banners were already in use on Hebrew Wikivoyage, so we should be encouraging cross-wiki collaboration even if we don't change banners. -- Ryan • (talk) • 15:08, 3 October 2015 (UTC)Reply
Sure there is nothing to say against this. Just the fact that the user in question has in one case even replaced their own banner (this is the article I am talking about). And the fact that there is a huge number of articles - some even rather high profile ones - without a banner. So of course everybody may decide for themselves what to invest time on, but I would think creating banners where there are none is better then creating banners where there are already some... Hobbitschuster (talk) 16:36, 3 October 2015 (UTC)Reply
Equally if not more important than encouraging crosslinguistic collaboration is encouraging civil and collegial cooperation among our own editors here at en: - something this user has very explicitly refused to do in choosing to press forward full steam ahead with his banner creation without even attempting to find a compromise or middle-ground solution or otherwise address the valid concerns of other members of the community. It's this user's completely unwikilike, obstinate-bordering-on-confrontational conduct that "does harm". As for "abusive", in the remarks I personally have made, I have been very careful to walk a fine line between doing justice to my concerns and feelings on the one hand, while giving the benefit of the doubt or assuming good faith where possible. It's a contentious issue, but in the final analysis this kind of conduct absolutely should be called out. -- AndreCarrotflower (talk) 17:01, 3 October 2015 (UTC)Reply
I'm sure that you didn't mean this, but when I finished reading all of the comments about this contributor, I had developed the impression that the complainants would be satisfied if the contributor just left en.voy entirely. I know that nobody actually wrote "you are not welcome, so please go away", but the repeated and sustained complaints seemed to have the same effect overall. WhatamIdoing (talk) 20:22, 3 October 2015 (UTC)Reply
All due respect, I don't see how inflammatory comments like the above contribute to the resolution of this conflict. Obviously no one's goal is to drive the contributor away from en.voy entirely, and in fact his or her positive contributions to the project in other domains have been duly noted. But the concerns raised by those who have an issue with the banner creation are real and valid, and they're amplified by ויקיג'אנקי's reluctance (see link in above comment timestamped 17:01) to work with the rest of the community in coming to a compromise solution. -- AndreCarrotflower (talk) 21:02, 3 October 2015 (UTC)Reply
The individual concerned started this topic because they were upset that consensus on Wikivoyage wasn't working for them, which prompted a release of steam from many on this site who have not been happy with the individual's approach, nor their obstinate refusal to listen to constructive advice on the subject for quite some time.
We are not saying "you are not welcome, so please go away". We are saying "please engage with us constructively so that our mutual goals can be achieved". If they are not willing to be collaborative then at the very least they should refrain from replacing good banners with their own personal vision which is demonstrably not shared by the majority of users here. Andrewssi2 (talk) 21:50, 3 October 2015 (UTC)Reply

──────────────────────────────────────────────────────────────────────────────────────────────────── Let's not make this too personal and let's not blow frustrations out of proportion. While several of us have made it clear that they would consider other contributions more constructive, I don't think the above accusations are fair. No-one is just replacing banners - this user has been systematically seeking discussion. I also don't read the linked comments as being uncivil. When I mentioned on their talk page that (s)he might not be applying our consensus guidelines in the usual way, they started this discussion here themselves. I think that's pretty well in line with wiki-ways. To me, most of these proposals are much like copy-editing good text. Like copy-editors, "banner-editors" should be allowed to dedicate their time to whatever they prefer - as long as they work within policy and preferably with some consideration for other users' frustrations. Taste is a major factor in all of this, and of course, when you're the only editor on a wiki, personal preferences become that wiki's way (which is fair enough). Clearly, ויקיג'אנקי is creating these banners because they seem better in some way to his or her eye. The fact that the community here sometimes agrees and sometimes doesn't, is just proof that tastes differ. Let's not forget that apart from this users many contributions on heb.voy, we've also gained a bunch of banners that we as a community do find superior. Perhaps the biggest frustration is the large number of banner discussions started at once, which makes it feel a bit pushy to some (even when that's not the intent). Perhaps ויקיג'אנקי can suggest them as they are produced? JuliasTravels (talk) 23:08, 3 October 2015 (UTC)Reply

If יקיג'אנקי could be persuaded not to keep carpet bombing a bunch of replacement banners and then explain the actual rationale behind each individual replacement then I would personally be happy to move on from this. --Andrewssi2 (talk) 03:15, 4 October 2015 (UTC)Reply
Agreed. -- AndreCarrotflower (talk) 21:44, 4 October 2015 (UTC)Reply
Are you willing to follow the same standard yourself? If you replace something, will you explain your "actual rationale behind each individual replacement" for everything that you replace? I don't support rules in which some contributors are more equal than others; that leads to dysfunction. WhatamIdoing (talk) 17:30, 5 October 2015 (UTC)Reply
Andrew can speak very well for himself, but first of all, this is specifically about replacing existing pagebanners, and yes, of course everyone should give a reason why they think their proposed replacement banner is better. Secondly, I don't know where on Earth you've gotten this notion that anyone thinks some people here are "more equal than others". I would suggest that you assume good faith and not cast wild aspersions without giving very firm evidence. Ikan Kekek (talk) 20:43, 5 October 2015 (UTC)Reply
WhatamIdoing : Did you actually read the really short proposal or even think a few seconds about it before jumping to some silly missives about equality? I was asking ויקיג'אנקי to follow our existing guidance to perform banner changes, not 'explain themselves' -Andrewssi2 (talk) 21:55, 5 October 2015 (UTC)Reply
I've just looked at 100% of ויקיג'אנקי's mainspace contributions so far this month, and they comply perfectly with the existing guidance at "Changing custom banners", which puts only one requirement on the editor: "Leave an edit summary explaining why the new banner is more appropriate." Every edit made this month either replaced the default banner with a custom one, or had an edit summary that explained the decision (usually "per talk page", which is ideal when a discussion has taken place, because the choice supported in discussion is the "more appropriate" choice). Therefore s/he's already complying with your proposal. What more do you need? WhatamIdoing (talk) 16:22, 6 October 2015 (UTC)Reply
First off, I take great umbrage at the idea that some have expressed that my remarks and others' are targeted at ויקיג'אנקי personally. I have nothing against ויקיג'אנקי personally, nor do I have anything against a new replacement pagebanner or two being suggested every once in a while. What bothers me is the pattern of behavior here:
  • First of all, as has been repeated many times, the articles for which ויקיג'אנקי suggests new banners have perfectly good ones of their own.
  • ויקיג'אנקי openly admits that he has no familiarity with the destinations for which he creates these banners, and also that in choosing which articles to target for possible new banners, he has no intention of trying to distinguish between similarly randomly chosen banners and those created by editors familiar with the destination. Instead, given his previous remarks on the subject combined with the lack of any other explanation of what makes his banners better than the ones they seek to replace, it's to be assumed that he presumes his own banners superior solely because of his self-proclaimed expertise in photo editing, which even if true, is akin to someone saying "I type 70 words per minute, therefore I'm a great writer."
  • ויקיג'אנקי openly claims to spend very little time on the creation of each banner, further suggesting a mechanized, assembly-line approach that is directly at odds with Wikivoyage's goal of providing information that is creative and distinctive.
  • On several occasions, ויקיג'אנקי has been known to put his suggested banner changes into effect prematurely, disregarding consensus.
  • ויקיג'אנקי has stonewalled many, many previous attempts by community members to get through to him in a calmer and friendlier way with their concerns that his efforts to systematically replace others' content with his own for no good reason come off as extremely pushy, and that if he enjoys creating pagebanners he'd be better off addressing the many articles that lack any.
  • Lastly - and this is the most important part, and the part that his defenders always inexplicably fail to address - when it became necessary to escalate the situation and ויקיג'אנקי was finally confronted about his uncooperative conduct, he made it known in no uncertain terms that he intended to continue disregarding the community's opinion and making unnecessary new pagebanner suggestions. (Incidentally, how anyone could fail to read incivility in a comment like "I will be [continuing to do this] whether you like it or not" boggles my mind). Let it be emphasized, as well, that that statement was never retracted.
ויקיג'אנקי has made, and continues to make, valuable contributions to Wikivoyage. I think I can safely speak for all of us in saying that I'd like to see that continue. But his "my way or the highway" attitude about pagebanners has no place on a collaborative project like ours, and that particular part of his conduct needs to change. I would have thought we'd learned our lesson from the Alice/Frank/118 debacle that issue-forcing and failure to "let it go" constitute incivility, which is something that's not to be excused from anyone in our community, regardless of how productive a contributor they are. In my mind, that's the greater issue here: the blatant disregard for the opinions of others, not being too hung up on pagebanners.
Lastly, I'd like to address the question WhatamIdoing posed, "If you replace something, will you explain your "actual rationale behind each individual replacement" for everything that you replace?", which presupposes that all content on Wikivoyage is created equal. Not so. Things like pagebanners, which serve as a visual introduction to the article for the reader, absolutely should come under more scrutiny than, say, a copyedit to correct a typo - for the same reason that a wiki might restrict editing privileges to their Main Page or some other high-traffic page. Again, ויקיג'אנקי is not being singled out here - I would absolutely hold anyone else in the community to the same standard, and I'd expect to be held to that standard by others as well.
-- AndreCarrotflower (talk) 23:30, 5 October 2015 (UTC)Reply
Sorry, from what I've seen I'm going to defend WhatamIdoing and ויקיג'אנקי from what seems to me to be unwarranted incivility. The "I will be [continuing to do this] whether you like it or not" quote, which I think was inaccurately paraphrased, was in response to being harshly told that suggesting new banners was a "waste of time". Statements like "it's to be assumed that he presumes his own banners superior solely because of his self-proclaimed expertise in photo editing" or suggesting that the only motivation for suggesting new banners is because "he is under the interesting notion that he is a 'photoshop expert'" strike me as being unnecessarily insulting. Similarly, describing someone's comments as "silly missives about equality" is an assumption of bad faith towards another user.
EVERYONE involved in this discussion has the project's best interests in mind, and having dealt with all participants in other threads I can say that all are decent folks, but that's not how things are coming across in this discussion. Let's have a civil discussion about ways to more productively suggest collaboration between Hebrew Wikivoyage and English Wikivoyage, and about better ways to choose page banners, but let's please try very hard to ensure that the tone of that discussion is respectful and civil, otherwise it's very, very tough to come to any productive agreement. -- Ryan • (talk) • 00:16, 6 October 2015 (UTC)Reply
I do apologise for using the word 'silly' in describing WhatamIdoing's comment. My own complete mistake in etiquette there.
As with all things on WV, I believe we can work collaboratively. Banners are difficult because we can only have one per article, and obviously there are concerns that previous good work can be replaced with something less compelling over a mere difference of vision, and therefore our practice of justification is worthwhile. An unrelated discussion recently on Montages shows that in terms of photographic taste regular WV users have a widely differing palette, and there is no reason not to accommodate them, whether they be vast landscapes or pictures of boots.
Also we should bear in mind that 65% of English Wikivoyage articles have no banner (around 16,000 articles) so there isn't exactly a shortage of articles to work on all together. --Andrewssi2 (talk) 03:33, 6 October 2015 (UTC)Reply


Wow such a long discussion! I am really sorry that my efforts, or maybe in some instances it's the way I chose to phrase myself in the discussions - aren't always perceived well amongst some core Engvoy users.

By the way, my username indeed means "WikiJunkie".

Regarding the banners... I always try my best to get them right, even if I haven't been to a certain location before (I am not the only prolific banner creator whom hasn't been to all the destinations of the banners they end up creating over time). Before making banners I always check the article on Wikivoyage+Wikipedia+check the photos available on flickr for that destination to determine what are the most prominent locations AND the most interesting locations in a specific destination (according to flickr) and the most photographed locations in a specific destination. The website Sightsmap.com also helps me a lot in finding good photos for banners. Sometimes this process + together with importing the photo from flickr to Wikicommons + and processing the photo in Photoshop, and uploading the derivative work to Commons, and adding the correct license text, can take about 30-40 minutes for each banner! (some times it might take even more time).

Nevertheless, although I invest a lot of time in finding good photos for banners of prominent locations, I still believe that the wisdom of crowds + wisdom of the locals might be a great help over time in making the best choices regarding each banner we'll choose (whether on Hebvoy, Engvoy or other Wikivoyage editions) as having a good discussion amongst as many people as possible help us choose the best banners more wisely (this is actually the reason that in my opinion, occasionally inviting the Engvoy community on the Travellers' pub to participate in discussions about a bunch of banners helps us eventually get a consensus which is based on many more opinions than what those discussions would otherwise get). I also believe that everyone's opinions are important in each discussion, even the opinions of the users whom have never been to a certain destination but believe that certain banners aren't working well for some very prominent destinations (for example banners with blurry unclear images used in the articles of major countries or cities, banners that zoom in on items that aren't unique to specific major countries or cities, or banners that show how awful a certain place is instead of trying to show the beautiful and unique spots that really appeal to the tourists whom are considering going to certain countries or a major cities, etc). These considerations, seem obvious to me and to the user Dekel E (whom is the current sole admin on Hebvoy), but I understand that in many times some users (here, on Hebvoy, or on other Wikivoyage editions) might have different opinions. In fact, it seems to me that the majority of users in the discussion pages on Engvoy usually tend to prefer banners that are colorful and artistic, although not necessarily of locations that have a major significance or are prominent tourist attractions (for example, a colorful picture of a flower, a boat, a sign, or a fish as the main banner of a major city/region/country seemingly might in many cases work better here because of this common taste among the majority of core users in your community (as of 2015), although those pictures might not always make sense to the actual Israeli tourists reading the Hebrew Wikivoyage articles, or the actual Russian tourists reading the Russian Wikivoyage articles, or the actual French tourists reading the French Wikivoyage articles, etc. And for this reason each Wikivoyage edition community eventually needs to take into account such considerations as well as the opinions of the locals, or the common taste of the Engvoy community, and decides for itself what banners they prefer be used for their own articles. Please try to understand that and respect that, although you might prefer that certain banners, which you have created or just banners which you really like, be used in all the other Wikivoyage editions as well.

Since early 2013 (almost three years!) I been mostly active on Hebvoy, where I have invested major efforts in creating a good foundation for Hebvoy to flourish over time. Since I am the user mostly active there, Hebvoy is still in early development stages (I'm doing the work of 20 users, in a period of time which takes x20 longer than what it would have take if Hebvoy actually had a community of 20 active users). Either way, at these early stages of Hebvoy, I have decided to focus a lot of my efforts in making sure that the majority of the Hebvoy articles have good banners (I believe that good banners help motivate and inspire many potential editors to participate in content development, in many times even more than mere text segments). I am not replacing all banners used on Hebvoy! only a small portion of the banners - usually banners of countries or major cities that in my opinion deserve better photos. We only have around 200-300 banners left to create on Hebvoy. Once I get all these banners created I will definitely move on to focus on the development of other specific things on Hebvoy. ויקיג'אנקי (talk) 03:40, 6 October 2015 (UTC)Reply

Thank you for participating in the discussion, ויקיג'אנקי. Let's try and move forward. Above I suggested that perhaps you could post the alternative banners more as you create them, so one or two at a time, rather than a list you accumulate over a longer time. I'm not talking of rules; it's just a suggestion, as it seems that this would take away some of the main frustrations. With fewer page banner discussions going on at once, it's probably easier for you to give a brief explanation why you think the new banner is more appropriate (because yes, we would actually expect that from all users, for banners that are not obviously bad), and for others to explain why they agree or not. Can we persuade you to do that? :-) JuliasTravels (talk) 10:46, 6 October 2015 (UTC)Reply
As I just tried to explain above, the main reason for which I much rather prefer to invite the Engvoy community from the Travellers' pub to participate in several discussions held about a bunch of banners, is that this is the only way in which such discussions are held with many more users' opinions taken into account and that as a result the common perception among the broad Engvoy community is expressed in each such discussions (the so called "community consensus") instead of just the opinions of 1-2 users whom are very good with monitoring the recent changes. Although in the past, in order to not "overload" the Engvoy community with such discussions, I used to start such discussions only once a year, as I am currently making many more banners than before (as I am hoping to finish the creation of the last 200-300 new+alternative banners needed on Hebvoy sooner than later), I will make sure from now on that I start such discussions only once in every 3 to 12 months in order to not "overload" the Engvoy community with such discussions. In the certain cases, in which it isn't clear why a new banner works better, I will definitely try to briefly explain why in my opinion the suggested banner works better than the current one used. ויקיג'אנקי (talk) 12:03, 6 October 2015 (UTC)Reply
Julias, technically, we don't require anyone to post alternative banners in advance. We only require that when the editor boldly replaces the banner, sans discussion, that the editor give some rationale (e.g., in an edit summary, but of course one could have longer discussions on the talk page). Also, there is no requirement that the rationale be something that other editors believe is important or even true. "Looks prettier to me" is an acceptable rationale under the existing guidance, and it completely fulfills the sole requirement we place on editors of page banners. WhatamIdoing (talk) 16:22, 6 October 2015 (UTC)Reply
Yes, I'm aware of what the banner expedition states and I had no qualifications in mind for an explanation. I was just trying to be pragmatic in finding some common ground, allowing ויקיג'אנקי to just do what they do, but with less frustration for other users. To me personally, the letter of policy is mostly something we have to rely upon when we can't get there with common sense and collaboration. Just for the record though (if we're getting into detail), you're referring to the banner expedition, which is not an actual policy page. For major changes (and I suppose banners on high visibility pages would count as that), we usually have discussions on the talk page. However, I don't think this is even relevant here, since ויקיג'אנקי has always shown the courtesy of seeking discussion beforehand. Let's just move on, and see how it goes when fewer banners are proposed at once. JuliasTravels (talk) 20:31, 6 October 2015 (UTC)Reply

The ToC looks weird on some articles edit

Swept in from the pub

Earlier today I noticed there was something wrong with the table of contents in an article, instead of the headings, the ToC read just "1". It was very confusing, firstly there was nothing odd with the pagebanner tag in that article, secondly I couldn't find any other "funny" things in the page's wikicode, and thirdly: as I saw the problem on just this one article I was sure it was something local.

However now I've run into two other articles with the same issue; Aracati and Mossoró. But, on the other hand, I've looked at many other articles today, which have entirely normally looking and working ToCs. What is wrong?

Ps. are there any plans to return the map icon back above the banner? ϒpsilon (talk) 17:34, 9 October 2015 (UTC)Reply

Save the page without an edit appears to fix the problem. Question is how do we find such pages? --Traveler100 (talk) 17:58, 9 October 2015 (UTC)Reply
Yup, that seems to return the ToC to normal. ϒpsilon (talk) 18:22, 9 October 2015 (UTC)Reply
Still I've no idea what causes this in the first place. I just, for example, fixed Washington (North Carolina). The only thing these articles have in common is that they are of comparatively small places and therefore probably not edited very frequently. Would be great if someone with technical knowledge would notice this thread. ϒpsilon (talk) 08:54, 11 October 2015 (UTC)Reply
@Jdlrobson, @Sumit? --Alexander (talk) 20:01, 11 October 2015 (UTC)Reply

And now another ToC problem edit

On some articles, even though have banner they are showing the table of content in the article. Example Middle Rhine Valley. --Traveler100 (talk) 19:41, 11 October 2015 (UTC)Reply

I removed the 'unesco=yes' property from Middle_Rhine_Valley and the TOC works again in preview mode. --Andrewssi2 (talk) 20:06, 11 October 2015 (UTC)Reply
Again a save without edit fixed the problem. Should we maybe do a minor edit to the pagebanner template to force a re-save or all pages? --Traveler100 (talk) 06:02, 12 October 2015 (UTC)Reply
Not sure.. it may be possible that these banners are using code before the banner extension went live (e.g. the original templates) but I'm not 100% sure. Next time someone encounters this could they copy and paste the HTML of the banner and share it? Note appending `action=purge` to the query string should also have the same result... Jdlrobson (talk) 23:25, 12 October 2015 (UTC)Reply
Just saw the issue on Florissant Fossil Beds National Monument while editing - when I saved the article everything cleared up. Here's the banner HTML prior to saving (note the "1" for the TOC content):
<div class="ext-wpb-pagebanner noprint pre-content">
	<div class="wpb-topbanner">
		<h1 class="wpb-name">Florissant Fossil Beds National Monument</h1>
		<a class="image" title="Florissant Fossil Beds National Monument" href="/wiki/File:Florissant_Fossil_Beds_banner.jpg"><img src="https://upload.wikimedia.org/wikipedia/commons/thumb/f/fa/Florissant_Fossil_Beds_banner.jpg/2560px-Florissant_Fossil_Beds_banner.jpg" srcset="https://upload.wikimedia.org/wikipedia/commons/thumb/f/fa/Florissant_Fossil_Beds_banner.jpg/640px-Florissant_Fossil_Beds_banner.jpg 640w,https://upload.wikimedia.org/wikipedia/commons/thumb/f/fa/Florissant_Fossil_Beds_banner.jpg/1280px-Florissant_Fossil_Beds_banner.jpg 1280w,https://upload.wikimedia.org/wikipedia/commons/thumb/f/fa/Florissant_Fossil_Beds_banner.jpg/2560px-Florissant_Fossil_Beds_banner.jpg 2560w" class="wpb-banner-image " data-pos-x="0" data-pos-y="0" style="max-width:8118px"></a>
		
	</div>
	<div class="wpb-topbanner-toc "><div class="wpb-banner-toc">1</div></div>
</div>
-- Ryan • (talk) • 20:56, 13 October 2015 (UTC)Reply
Tracked in phabricator:T115719. I'm still not sure what's happening here but given this is in the HTML itself the only way to fix this is to purge offending pages. We may need to write a script to search for pages with this problem. I'm trying to work out what's causing this. Jdlrobson (talk) 16:06, 16 October 2015 (UTC)Reply
For anyone following this thread, per the phabricator ticket, a potential fix is scheduled for release on Wednesday. -- Ryan • (talk) • 16:57, 25 October 2015 (UTC)Reply
I've stumbled upon this "1" problem in almost ten articles since yesterday. Any ideas? ϒpsilon (talk) 13:37, 24 October 2015 (UTC)Reply
Practically every article I go to today has this problem. Nurg (talk) 09:41, 29 October 2015 (UTC)Reply
Per phabricator:T115719 any banners showing the problem are theorized to be cached banners that updated improperly when the fixed extension was deployed yesterday. I've made a minor edit to Template:Pagebanner that should force the cache to reload for all articles, but if anyone has edited a page since midnight last night and sees a "1" for the TOC in the future for that article that would disprove the caching theory. -- Ryan • (talk) • 15:30, 29 October 2015 (UTC)Reply
I believe that's not quite absolute proof. As I understand it, some large corporate networks and ISPs keep their own caches, which are not always updated in a timely fashion. But that's not likely to be seen by a logged-in user. WhatamIdoing (talk) 23:41, 3 November 2015 (UTC)Reply

edit

Swept in from the pub

So what us generating Category:WikidataPageBanner with unknown parameters category on some pages? (looks like any recently edited page). --Traveler100 (talk) 05:15, 1 October 2015 (UTC)Reply

It's a recent change in the banner extension. It looks like it doesn't like the "toc" parameter, even though that parameter is valid according to the documentation at mw:Extension:WikidataPageBanner. I'll open a phabricator ticket. -- Ryan • (talk) • 05:26, 1 October 2015 (UTC)Reply
Ticket opened: phabricator:T114342. -- Ryan • (talk) • 05:39, 1 October 2015 (UTC)Reply
Thank you! - Matroc (talk) 05:51, 1 October 2015 (UTC)Reply
Thanks for the report. Patch submitted. Jdlrobson (talk) 16:53, 1 October 2015 (UTC)Reply
I merged the change mentioned by @Jdlrobson:. It will land on wikivoyage next Wednesday the 7th October :) --Florianschmidtwelzow (talk) 19:08, 2 October 2015 (UTC)Reply
So the fix is there but the 1,791 articles that were edited during the problem still need to be re-saved.--Traveler100 (talk) 07:40, 9 October 2015 (UTC)Reply

edit

Swept in from the pub

On some pages like Retiring abroad and Xiamen I am currently seeing the old-type TOC (left side of 2nd text section) while the bottom of the banner has only a white 1 where TOC should start. Other pages are fine. I'm using Firefox on Lubuntu Linux, both recent versions, if that matters. Pashley (talk) 22:49, 15 October 2015 (UTC)Reply

See #And now another ToC problem. -- Ryan • (talk) • 23:03, 15 October 2015 (UTC)Reply
Thanks. That confused me more :-)
Both those banners had |caption= labels at is the end, which is silly since captions don't display on banners. Removing those solved my problem, but I suspect there is still a bug that developers might hunt for. Probably low priority, though. Pashley (talk) 23:13, 15 October 2015 (UTC)Reply
Grand Trunk Road shows the problem and its banner tag contains only the image name, nothing removable. Pashley (talk) 00:38, 16 October 2015 (UTC)Reply
The captions for banners display on mouse-over, so they are not necessarily silly. Not all banners need them, but for banners that show something interesting that the reader might want to know a little about, they are valuable. Those two both had other additional parameters for the banners, so I wonder whether it was something about the order of the parameters, rather than the existence of a caption parameter per se. Nurg (talk) 06:32, 16 October 2015 (UTC)Reply
Grand Trunk Road is now OK, but Jar has the problem. I looked at about a dozen random pages & all the others were OK. Pashley (talk) 20:20, 21 October 2015 (UTC)Reply
Yes I am seeing this on a number of pages. --Traveler100 (talk) 20:52, 21 October 2015 (UTC)Reply
Tried > 20 random pages, found only Restonica Valley with the problem Pashley (talk) 21:08, 21 October 2015 (UTC)Reply
I have stumbled upon a couple of those. They can be simply fixed by starting the editor and saving without changes. But this is not a systematic solution, is it? --Danapit (talk) 21:24, 21 October 2015 (UTC)Reply
For Grand Trunk Road; the problem went away after User:Danapit did some edits, but has now reappeared. Coincidence? Or is there some logical reason I cannot see? Pashley (talk) 12:54, 24 October 2015 (UTC)Reply
Labuhan Lombok and Amazônia National Park show the problem; it seems to turn up in about 1 of every 12 or so random pages. Pashley (talk) 13:01, 24 October 2015 (UTC)Reply
This is an odd error and I think occurring too often. Although I really like the new drop-down menu in the banner should we consider returning to the old method until the problem is identified and fixed? --Traveler100 (talk) 12:08, 26 October 2015 (UTC)Reply
Did notice that happened to one of the pages I was going to work on - wasn't sure if it was widespread or not - thanks for the heads up! - "?action=purge" took care of that page for me - should probably be looked into -- Matroc (talk) 15:45, 26 October 2015 (UTC)Reply
There are currently two threads referencing this same issue. The other thread (link is in the second comment in this thread) has a pointer to the phabricator ticket where status can be tracked. -- Ryan • (talk) • 16:02, 26 October 2015 (UTC)Reply

Switching banner does not work edit

A banner in Wikivoyage:Banner Expedition does not show. It must be something to do with the switching function... Any chance of fixing it? Thanks. Danapit (talk) 17:21, 21 October 2015 (UTC)Reply

Pick one banner and stick with it. =) Powers (talk) 18:53, 21 October 2015 (UTC)Reply
re: Danapit - the switching function is fine, it appears that the new banner extension suppresses banners in the project namespace. Perhaps someone else could confirm and request an update to the extension? -- Ryan • (talk) • 19:16, 21 October 2015 (UTC)Reply
Right... Might Jdlrobson be able to help? Danapit (talk) 21:00, 21 October 2015 (UTC)Reply
I did a minor modification of the pagebanner template, which theoretically should have forced a re-save of all pages, Did however not solve the problem. --Traveler100 (talk) 21:39, 21 October 2015 (UTC)Reply
The pagebanner extension is activated in the main namespace only. One has to request its usage in other namespaces. We had the same problem in ru. --Alexander (talk) 21:47, 21 October 2015 (UTC)Reply
I can get it enabled in project namespaces or all namespaces. Which would you prefer? Maybe the latter is a better default?

Tracked in https://phabricator.wikimedia.org/T116262?workflow=create Jdlrobson (talk) 07:13, 22 October 2015 (UTC)Reply

All right, is there a reason for NOT allowing outside of main namespace? Until the change of the template it was possible to use page banners at Wikivoyage:Banner Expedition. Can we keep that? Danapit (talk) 14:52, 29 October 2015 (UTC)Reply

Autocropping not working properly? edit

A pagebanner was added to Jupiter, but while the pagebanner extension is cropping it somewhat, it's not cropping it enough. The original image is 7089x1744, and the pagebanner is autocropped to 1678x300 (on my screen). With a width of 1678, the height should be about 240, not 300. What needs to change to make this crop correctly? Powers (talk) 20:56, 2 November 2015 (UTC)Reply

This autocrop idea is somewhat frustrating, because it is close to impossible to find wrongly sized banners anymore. Or is there a way I don't know of? Danapit (talk) 21:45, 2 November 2015 (UTC)Reply
I think the autocropper does that by design. By fixing the height at 300 px and then scaling the width to the resolution of the screen, the banners don't look so tiny on tablets and phones in portrait mode. The downside is it doesn't follow the 7:1 aspect ratio we've been guided by. I'm guessing we'd need to contact the mobile team (User:Jdlrobson) if we wanted it changed. That said, I think the mobile team wants Wikivoyage to consider whether losing the 7:1 ratio is an acceptable trade-off to get a better mobile experience -- if I'm understanding this Pub conversation properly. -Shaundd (talk) 23:24, 2 November 2015 (UTC)Reply
Wouldn't it be possible to have 7:1 aspect ratio on desktops and laptops, and then a more boxy aspect ratio on mobile devices? James Atalk 23:48, 2 November 2015 (UTC)Reply
I don't know, it's a good question. Jdlrobson, is it possible for the cropping mechanism in the banner extension to crop to a 7:1 aspect ratio for desktops/laptops and a different aspect ratio for mobile devices? -Shaundd (talk) 21:19, 5 November 2015 (UTC)Reply
Firstly the autocrop idea is intended to both make your lives easier and improve mobile rendering. It's a work in progress as we learn, so please do feedback ideas and problems you are running into via myself or our community liason User:Melamrawy (WMF). We can enforce any sort of ratio you want but as I outlined in Pub conversation I'm still not sure what is most optimal. The only constraint is the image on desktop but must be the same as the one on mobile. To clarify the cropping is down by css - .wpb-topbanner currently has a max-height of 300px (not a fixed height). I think you can safely add .wpb-topbanner { max-height: 240px; } in MediaWiki:Common.css for desktop if the appropriate height should be 240px without damaging the mobile experience. We can fine tune this in the extension itself if you find this is working better for the majority of articles. Jdlrobson (talk) 21:29, 5 November 2015 (UTC)Reply
To be honest, I think that's the wrong solution. Setting a max of 240px would result in a banner that was too short if the full recommended width of 1800px is shown. I think the consensus of editors, though, is to maintain strictly 7:1 banners, at least for typical desktop-size resolutions. Perhaps what we could do is set a minimum height, so that if the page width shrinks below, say, 700px, the height stays fixed at 100px. Powers (talk) 01:17, 6 November 2015 (UTC)Reply

edit

Swept in from the pub

Anyone knows why or how to fix that ? ויקיג'אנקי (talk) 04:11, 9 November 2015 (UTC)Reply

I purged the article and it seemed to fix it for me. Try navigating to this link. James Atalk 04:21, 9 November 2015 (UTC)Reply
I see. Why did that happen? was the banner template changed recently, and the changes did not take effect yet in all non-purged articles ...? ויקיג'אנקי (talk) 04:24, 9 November 2015 (UTC)Reply

Black & White banners? edit

I just created a Black and White banner for the new article of Jebudo.

I chose this because there are not a great deal of CC images available that show this out of the way destination.

Looking through the expedition I don't see anything against this although BW tend to be rare on WV, any thoughts? --Andrewssi2 (talk) 22:14, 15 November 2015 (UTC)Reply

If that's the best suited image at this moment, I think it should be perfectly fine. While I love black&white images I don't think they typically make for the best banner material - but a little diversity never hurts. JuliasTravels (talk) 22:22, 15 November 2015 (UTC)Reply
I would certainly agree with that. If someone did come up with a better banner (better mean holistically better than the existing BW image, not just any image in color) then replacing it would be fine. --Andrewssi2 (talk) 22:59, 15 November 2015 (UTC)Reply
I agree with what's been said. I had the same issue a few years ago with Dukhan, so there is some precedent. James Atalk 00:16, 16 November 2015 (UTC)Reply
It is a nice banner - reminds me of an Ansel Adams' photograph -- Matroc (talk) 01:04, 16 November 2015 (UTC)Reply
Yeah, it's beautiful! Ikan Kekek (talk) 02:26, 16 November 2015 (UTC)Reply
I am also perfectly ok with a pretty B&W custom banner, unless someone suggests a better alternative. Danapit (talk) 11:06, 16 November 2015 (UTC)Reply
Great usage for what is available JarrahTree (talk) 00:49, 17 November 2015 (UTC)Reply
It looks great! --Zerabat (talk) 02:23, 15 February 2017 (UTC)Reply

Broken pages (Table of contents and Edit links) edit

Swept in from the pub

Hi all - I noticed that the display of some pages is broken - for example this one: Yell. The table of contents is not shown in the banner, but at the beginning of the page (as it used to be before the banners were introduced). Furthermore, the "edit" links next to each section are displayed without square brackets, nor space after the section title & they do not work, when clicking on them. If I make an edit to such a "broken" page (via the page edit link), the problems disappear. (I didn't edit the Yell page, so that you can see the problem). Could someone please have a look at that? Thanks. 13:21, 31 January 2016 (UTC)

The table of contents problem has been here for a couple of months already, I remember it being discussed somewhere but apparently nobody has been able to fix it yet. The bloated Edit links in the Yell article is something new. Not sure who knows how to fix these things, maybe Ryan or Torty3? ϒpsilon (talk) 13:59, 31 January 2016 (UTC)Reply
To fix an individual article with the TOC problem, you must purge its cache: https://en.wikivoyage.org/w/index.php?title=Yell&action=purge
If you see a lot of articles with that problem, the recent workaround has been to make a null edit to Template:Pagebanner. I suspect purging the cache for the template would work too, but I'm not certain.
-- Powers (talk) 15:39, 31 January 2016 (UTC)Reply
-- Maybe could consider something like this on main article pages - create from a template or module :   -- have used this type of thing before on other personal sites -- Matroc (talk) 19:51, 31 January 2016 (UTC) -- (think I also did a new tab that just did that function about 12+ years ago) - just a thought... caioReply
The in-article TOC is discussed in the #Page banner and TOC - again above, with a link to the current phabricator ticket. As LtPowers suggests, the current workaround to that bug is to make a minor edit to Template:Pagebanner which will force all pages with banners to refresh their cache (it takes up to a few hours, be patient). I'm not seeing any problem with edit links in the Yell article, so please provide more information - browser, operating system, whether it occurs on other articles, etc. -- Ryan • (talk) • 02:27, 1 February 2016 (UTC)Reply
Thanks everyone for your feedback. The problem with the edit links can no longer be seen in the Yell article, since edits were made in the meantime. I'll let you know if I encounter another article with the same problem. 13:11, 7 February 2016 (UTC)

Port_Campbell edit

I'm trying to get rid of the page banner image on Port_Campbell, but it won't seem to go. I've pointed it to the default image, etc. Can someone quickly tell me what I'm doing wrong, and why the page banner image still appears? --Inas (talk) 01:52, 29 April 2016 (UTC)Reply

I think it's because the banner is a Wikidata item. Once a custom banner is identified in Wikidata, it becomes the default banner for a guide. We can override the Wikidata banner locally if we specify a different banner (i.e., {{pagebanner|image_name.jpg}}), but it only seems to work if it's another custom banner. I guess the banner could be deleted on Wikidata, but other language versions may be using it and I don't know if Wikidata likes it if we delete a property like that (I've never edited Wikidata, so hopefully others with more experience know better). -Shaundd (talk) 04:26, 29 April 2016 (UTC)Reply
The wikidata banner is not referenced anywhere else so could use the edit option there to delete it. However would be better to replace if you think there is a better alternative. Why do you want delete it, is not a this one better that the default? --Traveler100 (talk) 06:17, 29 April 2016 (UTC)Reply
Happy to replace, but I can't find anything. This image is actually of a completely different Port Campbell in the UK, so it's entirely inappropriate. At least the issue is now well defined. --Inas (talk) 06:40, 29 April 2016 (UTC)Reply
This is a picture of Port Campbell in Australia, the Port Campbell Surf Lifesaving Club and Cairns Street can be seen. --Traveler100 (talk) 07:59, 29 April 2016 (UTC)Reply
Confirmed. I first tried to see which side of the road they were driving on, but the main road in the picture is one-way. But then I easily found this beach on Google Maps: https://goo.gl/maps/dhr3Q1nmPBH2 ... Pretty crazy crosswalks they've got there. Powers (talk) 18:24, 29 April 2016 (UTC)Reply
Would you believe I was standing on that beach at the time? Just wow.. Anyway.. thanks for help, all.. --Inas (talk) 03:57, 30 April 2016 (UTC)Reply

Another cropping tool edit

I did not notice there was already a CropTool integrated to Commons, so I wrote mine (a simple web page).

  • Pros:
    • I prefer not to see the rest of the image while doing the selection (CropTool and Gimp show it), it prevents me from having a good idea of the result.
    • When creating banners, most of the time, I used a selection from side to side (because of the ratio is 7:1, making the width shorter make the image even thinner).
    • It saves directly in 2100x300.
    • You can drag&drop an image from your machine.
    • You can save and modify the image locally (ex: colours curves with Gimp).
  • Cons:
    • Can only use the full width on the source image.
    • No rotation.
    • Not integrated with Commons:
      • Requires to paste the URL of the image (I did not find any API that provides the URL of the image in full resolution).
      • Cannot upload to Commons directly.
    • It may not work with some browsers (IE?).

Fabimaru (talk) 11:17, 7 August 2016 (UTC)Reply

Hi Fabimaru, great job making the cropping tool and thanks for sharing it as an alternative! Personally I like using the CropTool. I appreciate most its possibility to directly upload the new file to Commons. Sometimes I edit the picture on my computer, if more than simple cropping is needed, for example rotating, contrast adjustments, etc. But the file with all the information is already there @ commons, which saves some effort & time.
If I just can have a little comment to the features of your croptool: I believe that the maximum resolution should be preserved in 7:1 ratio, not downgrading it to 2100 pix, if greater original image is available. You might consider this as an option. Cheers, --Danapit (talk) 06:56, 8 August 2016 (UTC)Reply
Thanks a lot Danapit for your comments. Having the informations directly in Commons is definitively great (that's a fastidious part). The '2100x300' policy was specified in the French Wikivoyage, so I just initiated a discussion to change it to the minimum resolution like in this Wiki. And I will add an option for saving in JPEG.
When you need to edit on your computer, how do you manage to keep the informations in Commons? Do you create with CropTool an intermediate version of the file and then upload the edited version?
At last, the best way would be to enhance the current CropTool. I may have a look. — Fabimaru (talk) 19:01, 8 August 2016 (UTC)Reply
Fabimaru, I do it exactly as you say: I create an intermediate version with CropTool and then upload the edited version. Danapit (talk) 11:25, 9 August 2016 (UTC)Reply

PNG image: convert to JPEG and upload? edit

I noticed that a few banners are in PNG format, for example Berlin/City_West (1.6Mo). Would you agree that these files should be converted to JPEG and re-upload to Commons (with a reference to the original files) and the reference in the page should be changed to the JPEG one? That was not explicitly mentioned, but it seems logical for me. Otherwise, the Wikivoyage code for handling the banner could be enhanced to convert the PNG to JPEG (in additional to the scaling). — Fabimaru (talk) 19:31, 8 August 2016 (UTC)Reply

I don't have any firm opinion about the format. Are there any technical advantages / disadvantages of either jpeg or png format in this context? Danapit (talk) 11:27, 9 August 2016 (UTC)Reply
I do replace these when I see them (one example was Saarland). The advantage of JPEG is that the image size scales down in banners regardless of the size of the original, whereas PNG does not scales at all (at least for Wikivoyage banners). Generally speaking, JPEG is better for photos and PNG is better for diagrams. --Andrewssi2 (talk) 13:05, 9 August 2016 (UTC)Reply

Recommend CropTool instead of GIMP edit

The main Creating a banner instructions use GIMP. Then a few paragraphs below, CropTool is suggested as an alternative.

How about doing the opposite? CropTool as the default, and then suggest GIMP as an alternative.

The default instructions should be for beginners. Advantages of CropTool are numerous for beginners:

- No need to install any software - Author/descriptions/metadata are automatically copied perfectly - Compression is made correctly - Aspect ratio is enforced without requiring any calculation

Cheers! Syced (talk) 03:56, 24 August 2016 (UTC)Reply

I agree. It completely makes sense. Danapit (talk) 08:43, 24 August 2016 (UTC)Reply
I think that the intent around this is probably better than the wording. Effectively you are saying that CropTool is fine for defining banners from images, but there is no restriction on using an image editor (which could be Gimp) to define 7:1 ratio banner images? --Andrewssi2 (talk) 08:09, 25 August 2016 (UTC)Reply
The crop tool is probably the best method for files which are already on Commons and don't need any other adjustments. I like the way that it automatically handles the attribution and licensing. However more detailed instructions are required as my first attempt came out in the wrong aspect ratio. Gimp or another editor is best for editing your own photos, or those in commons that need other edits (colour adjustments etc) - the alternative would be upload the image and then crop it using the tool, but that sounds like more work. AlasdairW (talk) 20:44, 25 August 2016 (UTC)Reply
It is more work, but Commons prefers having the originals available for future use. If the original is truly inferior, it can be uploaded to the same filename before the superior version, because all previous revisions are kept. Powers (talk) 01:50, 26 August 2016 (UTC)Reply

How to import the TOC Bread-Crumbs on the banners to hewikivoyage? edit

Swept in from the pub
 
TOC bread crumbs

Hi, I want to import the TOC Bread-Crumbs on the banners to hewikivoyage. What do I have to do to import it? Thanks, Dekel E (talk) 07:17, 19 July 2016 (UTC)Reply

The banners utilize mw:Extension:WikidataPageBanner. You should be able to open a request on phabricator: to get it installed. -- Ryan • (talk) • 07:31, 19 July 2016 (UTC)Reply

Create banners easily with CropTool edit

Swept in from the pub

100% online, no third-party website, no copy/pasting of metadata. All the boring stuff gets done the right way, automatically.

 
CropTool 7:1 aspect ratio
  1. Go to https://tools.wmflabs.org/croptool/
  2. Log in
  3. Paste the name of a Commons image, for instance: Sainte-Enimie-Gorges du Tarn-Frankreich.jpg
  4. Specify 7:1 as a custom aspect ratio
  5. Drag, resize, move the selection box
  6. Preview
  7. Save as a new image with a simple click.

So much easier than anything I have used before!

Syced (talk) 10:12, 23 August 2016 (UTC)Reply

Could be worth adding that info to Wikivoyage:Banners. -- WOSlinker (talk) 18:18, 23 August 2016 (UTC)Reply
Someone has now added it apparently :-) Syced (talk) 06:08, 24 August 2016 (UTC)Reply

Have there been any known bugs with the new banner extension? edit

Swept in from the pub

These days the Hebrew Wikivoyage community is also looking into adding the new banner extension. We are currently in the testing phase of the new banners, trying to see if we can catch any important bugs that need to be fixed before we add the new banners to all our 2,067 articles.

I do recall seeing a discussion in the English Wikivoyage sometime in the last year about specific bugs related to the new banner extension which everyone must just accept and "live with" (if I am not mistaking, the discussion was about how the good old Table of Contents would sometimes appear in various random articles as a result, or some similar annoying bug which is caused by the new banner extension).

Do the new banners work well in all platforms (mobile+ desktop) and browsers, even though it relies on Javascript?

Please let me know which specific bugs you have discovered that occurred as a result of installing the banner extension having the new banners replace all the old ones. ויקיג'אנקי (talk) 10:41, 30 August 2016 (UTC)Reply

The bug with the content table appearing has been addresses. Have not seen any issues for a couple of months now. --Traveler100 (talk) 10:46, 30 August 2016 (UTC)Reply
So the new banners are flawless ? they work well in all platforms and browsers ? ויקיג'אנקי (talk) 21:00, 30 August 2016 (UTC)Reply
I use a variety of browsers and haven't seen any bug in a while. Syced (talk) 03:33, 31 August 2016 (UTC)Reply

Alt pagebanner layout? edit

Swept in from the pub
 
Isfahan example
 
Costa de la Luz example
 
Boston example

Hello! I was just thinking about a minor cosmetic update to the pagebanner templates. With a few lines of CSS supported by all modern browsers, banners could look like this?

The main idea is to make the image aspect ratio a little taller without having to re-crop all the banners, so move the content bar below the image. Also switching the title background color with a drop shadow, and left aligning the title and content bar text will give a slightly more modern feel.

IMHO extending the page by 28px is a pretty reasonable trade-off for a little more image space up front. Text alignment is a no-brainer to me, but let's see what everyone else has to say!

If we actually want to go forward with this, I would also recommend moving the · from the A tag to the LI tag within the content bar.

Thanks! --ButteBag (talk) 23:40, 23 May 2017 (UTC)Reply

I'm pretty sure both of these were raised when banners were first discussed but I can't find the conversations. If I remember correctly, I think the main page banners used the drop shadow and we were finding that it didn't work well in some backgrounds and people felt it would be good if the main page banners and the pagebanners had a consistent look. Regarding the content bar, the height of the banners was a bit contentious and 7:1 (including the content bar) was as tall as some were willing to go. Opinions may have changed, so it's good to revisit. I'm not fussed about where the content bar is placed. I do prefer the translucent box over the drop shadow because I find it produces a readable result more consistently (drop shadow can work really well, and other times the text will not stand out much at all). -Shaundd (talk) 06:24, 24 May 2017 (UTC)Reply
Thank you for the feedback! From a design perspective I think this is an improvement, (people in general like to look at pretty pictures) but I respect that there are many other use cases for WV. I do think the drop shadow looks nicer than a transparent rectangle in almost all cases. Maybe for a few odd banners there could be a "reversed=true" option, where the text is black and the drop shadow is white? Thanks again! --ButteBag (talk) 14:48, 24 May 2017 (UTC)Reply
I like the idea of moving the text off the image. WhatamIdoing (talk) 16:09, 24 May 2017 (UTC)Reply
I'm a bit slow/confused when you talk about adjusting the image aspect ratio. Does that man stretching the image to the new aspect ratio ? (bad bad bad idea) or does it mean keeping the banner image aspect ration and moving the title menus to a new box below the existing banner ? Stretching the image would be very bad. Moving the heading menus from being over the image to being below the image has good and bad points and personally I prefer it as it currently is (less screen space used and does look quite neat and tidy). But my main concern is about any changing/stretching of the banner image. PsamatheM (talk) 18:27, 24 May 2017 (UTC)Reply
Would be supportive of moving the title menus below the pictures rather than within the pictures if that is what is suggested. Travel Doc James (talk · contribs · email) 22:45, 24 May 2017 (UTC)Reply
Hard for me to see any downside to this, but would still urge that you get a large consensus on WV before making such a fundamental change. Andrewssi2 (talk) 05:48, 25 May 2017 (UTC)Reply
Thanks! How does one get a large consensus? Leave this conversation here and maybe do something in a month or so if people are feeling generally positive? Propose: 1) Move table of contents from on top of the banner image to below the image. 2) Change page title to have a strong drop shadow instead of a transparent black box. 3) Proper left alignment of text. 4) Move the separating dot to the LI from the A, so it doesn't underline when you hover it. (very minor, but it irritates me). Arguments: These changes would strengthen the design and visual impact of WV pages. The agreed upon 7:1 crop is aggressive and should not be changed, so by moving the table of contents below the banner; the image is given more room to breathe and visually delight visitors. That's the idea anyway. Thanks! --ButteBag (talk) 14:41, 25 May 2017 (UTC)Reply
I'm not sure that your list of arguments is going to persuade me. IMO the reasons I support moving the TOC off the image are (1) since people don't always crop to leave a 28px border at the bottom of the image, it might cover up something that I want to see, and (2) you said that it's just 28px, out of the ~700 pixels (usable height) in my browser window, which is a trivial amount of screen real estate to "lose" to the TOC (especially since it scrolls off the screen quickly, as I'm almost never interested in the introduction). WhatamIdoing (talk) 16:16, 25 May 2017 (UTC)Reply
Ha, cool! Your reason #1 is my #1. (strengthen the design and visual impact of WV pages) Thanks for that! --ButteBag (talk) 01:08, 26 May 2017 (UTC)Reply
For what it's worth at this late date, I wouldn't mind moving the menu bar below the banners. I don't think the drop shadow provides enough contrast on some images, though it does look spiffy for others. Powers (talk) 18:39, 22 July 2017 (UTC)Reply

Page banner content edit

Swept in from the pub

Did I miss a conversation and decision somewhere. Do not like the new contents title. What was wrong with the old one? --Traveler100 (talk) 07:12, 15 June 2017 (UTC)Reply

I'm unaware of any conversation. What change have you noticed? --Andrewssi2 (talk) 07:25, 15 June 2017 (UTC)Reply
Ah, I see now! (the page needs to change before the new rendering appears). There lower translucent menu bar is now much higher with the word 'Contents' above it. Looks bad. Can we please revert back?
I can't see any recent changes at Template:Pagebanner to cause this, so maybe at MediaWiki ? --Andrewssi2 (talk) 07:29, 15 June 2017 (UTC)Reply
In the Dutch WV the extra space has the word "[verbergen]" (hide) in it. However it is not showed in every page: nl:Hongarije has it, nl:Praag does not have it. --FredTC (talk) 08:00, 15 June 2017 (UTC)Reply
New layout looks dreadful compared to previous one - "damages" the banner image badly. Also makes WV look very inconsistent as some (edited) pages have new layout whilst old (unedited) pages have old layout. Definitely agree to revert to old layout. This one os also "greying over" virtually the bottom half of the banner - I don't get the "Contents" on a page I tested (but if you highlight the greyed area the word is there in black and in my test Woodbridge (Suffolk) the banner colour makes the menu items be white (so it's not been properly implemented anyway!). I did think these sorts of changes would have been discussed before being implemented. All my votes to revert to old layout. Edit note: Does not even work properly with the default page banner!! PsamatheM (talk) 08:52, 15 June 2017 (UTC)Reply
I agree that it looks bad and should be reverted. To do that we have to figure out what caused it, I guess. Maybe User:Thiemo Mättig (WMDE), who recently edited the MediaWiki extension, can help. —Granger (talk · contribs) 09:30, 15 June 2017 (UTC)Reply
I've made a change to MediaWiki:Common.css which seems to fix the issue. The real cause of the problem should still be investigated though. -- WOSlinker (talk) 11:28, 15 June 2017 (UTC)Reply
The interesting thing is that whatever caused the change required the page be edited before the new banner style appeared. But whatever @WOSlinker did has immediate effect and does not require the page to be edited for the banner to revert back. So I do suspect that the solution (which works) is not undooing the cause, just overriding it (great that it's back how it was, thanks) PsamatheM (talk) 12:36, 15 June 2017 (UTC)Reply
My change is just an override to hide the problem. It's not a fix of the original cause, whatever that is. -- WOSlinker (talk) 13:17, 15 June 2017 (UTC)Reply
Out of interest for my understanding as to how WV (and other Wiki's) work, how is the problem identified now. Is there some report mechanism to MediaWiki or do they just spot comments here on this thread, or does an Admin here take the reporting the issue to whoever, etc. i.e. who has to do what ? PsamatheM (talk) 14:52, 15 June 2017 (UTC)Reply
The place to report mediawiki bugs is at https://phabricator.wikimedia.org/ and anyone can do it. -- WOSlinker (talk) 15:51, 15 June 2017 (UTC)Reply

FredTC, WOSlinker, PsamatheM, Andrewssi2 - Unfortunately, The bug isn't gone. Apparently it only affected the Hebrew Wikivoyage and Dutch Wikivoyage which are the only Wikivoyage editions that did not replace all their old banners code with the new banner code (the new banner code had several issues and therefore we chose to implement it in the Hebrew Wikivoyage). In order to see if the bug was fixed... take any page on either the Hebrew or Dutch Wikivoyage, press on Edit Source, and change the "&action=edit" at the end of the URL to "&action=purge" (which would refresh the page and show that the new hide feature is added or eventually will be added to all articles once they are refreshed. ויקיג'אנקי (talk) 16:58, 15 June 2017 (UTC)Reply

For example - see the Granada article in the Dutch Wikivoyage and the Hebrew Wikivoyage. ויקיג'אנקי (talk) 17:00, 15 June 2017 (UTC)Reply
What seems to show on those WV's is completely different to what we saw on en WV earlier. They have a Show/Hide option to show of hide the heading jump menus. On en WV there was a "Contents" heading in black and the greyed area was covering almost half the vertical height of the banner. the nl WV looks different in that I cant see a greyed area. So I can't see how the issues relate PsamatheM (talk) 17:05, 15 June 2017 (UTC)Reply
Either way, someone changed the code of the old banner 2 days ago. Since it is only used by Hebvoy and NLvoy, and since we are not interested in this change, how do we revert this "hiding" feature? ויקיג'אנקי (talk) 20:53, 15 June 2017 (UTC)Reply

How to find unused banners? edit

At times, page banners get made without getting used. At other times, page banners get removed. Is there a method to check which banners are used and unused? /Yvwv (talk) 22:40, 8 September 2017 (UTC)Reply

Other than checking through the commons categories I can't think of any. What for? Almost all banners are associated very strongly with one place and are not suited to use elsewhere. • • • Peter (Southwood) (talk): 15:42, 9 September 2017 (UTC)Reply
An unused banner for a city might be useful for a region containing that city, and an unused travel topic banner could be useful for a destination article. —Granger (talk · contribs) 16:29, 9 September 2017 (UTC)Reply
It is possible that some banners have fallen through the cracks and gotten lost or have never been categorised, but they should all be in one of the categories that matches the places they could reasonably be used. If you have a suitable image available it may well be quicker and less work to make a banner than to try to find one. It is not difficult and does not take long. I made hundreds when we first started using them. • • • Peter (Southwood) (talk): 18:03, 9 September 2017 (UTC)Reply

Our banners reused elsewhere :-) edit

Swept in from the pub

The Wikivoyage banners are being used by a webapp produced by the French Wikipedia, see for instance https://macommune.wikipedia.fr/Q279681/Thouars This means our efforts also benefit other projects. Syced (talk) 12:12, 25 July 2017 (UTC)Reply

Downtown Shanghai edit

 
Suzhou Creek, crop out hazy top
 
The Bund, crop out foreground

New page, talk page shows why it was created. Needs a banner. Pashley (talk) 21:43, 12 September 2017 (UTC)Reply

Are you able to suggest any images, or categories on commons of suitable images. It is hard to create a banner for a city district if you are not familiar with the area. For instance commons:Category:Views from the Oriental Pearl Tower might have some suitable images, but without quite a bit of research I wouldn't know which were looking in the right direction. AlasdairW (talk) 22:32, 12 September 2017 (UTC)Reply
Anything looking across the river from there would be OK, not things looking around Pudong. I like the ones to right:
There are similar images that might be better. Anything in categories 1.2 through 1.5 on this page is in the area in question. Pashley (talk) 23:35, 12 September 2017 (UTC)Reply
Third one might be easiest; it is the right shape, large enough & a suitable subject: Pashley (talk) 23:49, 12 September 2017 (UTC)Reply
 
Bund panorama

It now has a banner that looks fine to me. Pashley (talk) 00:10, 13 September 2017 (UTC)Reply

Thanks, that was a good selection of images, but it is great that it now has a banner. AlasdairW (talk) 20:39, 13 September 2017 (UTC)Reply

Pagebanner syncing to Wikidata edit

Swept in from the pub

Having uploaded several hundred pagebanners over the past month, I've come to wonder why none of my banners are getting automatically synced to the Wikidata listings for the pages. I think this is a missed opportunity, not for enWikivoyage per se, but for all other-language Wikivoyages using pagebanners. I know that the template fetches the banner from Wikidata if no image has been specified in the template (i.e.: {{pagebanner}} instead of {{pagebanner|Pagebanner default.jpg}}), but I am not sure if there is a bot or whatever dedicated to syncing the banners to Wikidata. This leaves me with the following questions:

  • Is there any means of having the pagebanners automatically synced to Wikidata? The only thing I can see this depending on is my naming of banners (-Wikivoyage Banner while -banner is advertised as the correct way to name them), but I doubt that that's the case.
  • If the answer to the question above is no, then shouldn't there be? Many other-language Wikivoyages do not use a preset banner image in the template (File:Pagebanner default.jpg is what we automatically insert into the template when using the quick copy/paste templates). They instead choose to fetch them from Wikidata if one is available. We are significantly ahead of many other-language Wikivoyages, and they can benefit from our banners. Only problem is that we don't let them yet and have their editors go through the manual task of checking the English version for a banner instead. Wouldn't it be better for all if we would sync the banners we've made and implemented to Wikidata?

-- Wauteurz (talk) 19:40, 29 September 2017 (UTC)Reply

Not sure, but I found Wikidata rather problematic for banners. We go through enough drama sometimes discussing a banner change, and having 'stealth' changes through Wikidata would not go down well. I don't support forcing us to move our banners to Wikidata. --Andrewssi2 (talk) 00:27, 30 September 2017 (UTC)Reply
I think that was not what Wauteurz suggested, rather that banners would be added to Wikidata automatically (when inserted in an article or when uploaded to Commons). That would make the banner appear automatically in those projects fetching their banners from Wikidata by default. It would not affect us. A bot could easily do that (I do not know whether there is such a bot now), perhaps checking the banner has been at least a week on en-wv to guard against vandalism. Fetching the link from Commons is more difficult, as the coupling between banner and article is not always obvious, at least not for a bot, and I think fewer people monitor the categories on Common for inappropriate images (those monitoring last changes there worry about copyvios and out-of-scope files, not about the appropriateness for a certain use). --LPfi (talk) 09:43, 30 September 2017 (UTC)Reply
@Andrewssi2: I do not want our banners to be fetched from Wikidata. Instead I'd like for our banners to be synced to Wikidata, meaning that syncing only goes one way: If we have a banner image set, then the Wikidata listing will get that same image in the Wikivoyage banner parameter. We, meaning enWikivoyage, will not be affected. LPfi brings up an aspect of this that I hadn't taken into consideration yet, namely vandalism. I would agree with them that several days after the change of the banner image, it can get synced to Wikidata, as a week or so is plenty of time for the banner image to be verified as non-vandalism (I honestly think that 24 or 48 hours is plenty already, as the change will be well out of sight on Special:RecentChanges).
I see two ways of achieving syncing of banners via bots, namely one where we check edits to Template:pagebanner here, set that change aside, and check back some time later to see if it has been changed again, if not, then the image can get linked in Wikidata. The other option involves reading the file usage paragraph on Commons some time after the file's creation or checking all banners in Commons' Wikivoyage banners of~-categories for changed file usage, then checking when the banner was last edited on enWikivoyage, and if that's been longer ago than x days, then the bot can link the image to Wikidata. The latter option however, involves three Wikimedia projects (enWV, Data and Commons) instead of two (enWV and Data), making the first way of tackling this seem the more obvious way.
Again, I doubt a bot for this purpose exists at this point in time, as I have yet to have come across a banner linked in Wikidata that hasn't been added manually. Also, if anything, I want this to not have an effect on our pagebanners. Template:pagebanner might check Wikidata listings, but by adding File:Pagebanner default.jpg as the default specified image as we are doing already and blacklisting the default banners for the bot to sync, I think we can overcome any problems here from occurring.
-- Wauteurz (talk) 10:54, 30 September 2017 (UTC)Reply
I agree that a day is probably enough. The prime problem that I see is how the bot will find the edits to {{pagebanner}} without checking all edits. If there is no good method, then it would perhaps be better to use database dumps instead of querying the servers. That would mean quite some delay. How often are new dumps published? Another method is for the template to have a hidden category, which the bot can check. There may be still other methods. --LPfi (talk) 17:23, 30 September 2017 (UTC)Reply
I can't answer anything about database dumps, but I can point at Category:Has default banner and Category:Has custom banner. Using them we can make a list of pages having a default banner at one point in time, and having a custom banner the next time they're checked (say, for instance weekly or bi-weekly) is only a partial solution as you're not capturing changes such as Custom_banner_01.jpg to Custom_banner_02.jpg. Instead, we might be fine with just checking the edit notes. Checking edits alone can filter edits to paragraphs (as pagebanners are only ever used outside of page paragraphs at the top line of the article) and edits to other namespaces that are not of interest. The edit notes, furthermore, can be filtered for words such as "banner" and "pagebanner" to create an overview of "Banner-related changes". This does require all edits to banners to have an edit note attached. We can't guarantee that, but we can still resort to database dumps every time they roll around, even if that happens every three months or every year.
Either way, my knowledge of bots is quite limited, so I'll tag the only person I know on here that does - Ryan, if you'd be so kind as to give some technical insight as well as your view on this, then please be my guest :)
-- Wauteurz (talk) 18:39, 30 September 2017 (UTC)Reply
We have Category:Banner missing from Wikidata, but for some reason I can't post an internal link to it - see [6]. This has 1,184 members, which shows that it is a while since the bot was run. AlasdairW (talk) 19:30, 30 September 2017 (UTC)Reply
@AlasdairW: If I understand correctly, you're saying that the bot I am looking for does exist, but hasn't been run for some time? If so, who would I need to get in touch with to have it put back into action?
-- Wauteurz (talk) 19:50, 30 September 2017 (UTC)Reply
I don't know the details of the bot, but have a look at the very bottom of Wikivoyage:Banner Expedition. AlasdairW (talk) 20:08, 30 September 2017 (UTC)Reply
As far as I remember, User:Syced operated the bot. --Alexander (talk) 20:10, 30 September 2017 (UTC)Reply
Thank you, Alexander and AlasdairW. I've found one reference to the banner bot on Syced's talk page, but he never replied to it. I'll get in touch with d:User:Kizar, who has ran the bot linked at the Banner Expedition before. I'll check with him whether the bot can be ran somewhat more regularly.
-- Wauteurz (talk) 20:25, 30 September 2017 (UTC)Reply
One obvious disadvantage of the one-side synchronization is that English Wikivoyage does not receive any updates on page banners and often uses mediocre banners when much better options are available. This is the case for many of the Russian and Eastern European regions, where lots of high-quality banners have been uploaded in the last 3 years. Compare, for example, Ulyanovsk Oblast with ru:Ульяновская область, and Krasnoyarsk Krai with ru:Красноярский край, not to mention Crimea and ru:Крым. --Alexander (talk) 20:32, 30 September 2017 (UTC)Reply
If the bot is used just to add banners on wikidata where none is referenced from before, it will not have any such drawbacks that I can think of. Updating the entry with better banners is much more convoluted, and probably requires manual action, at least (there are other problematic cases) if the existing entry was not that which was replaced on en-wv.
For updates, that is a separate question. People with interest in some specific article might want to look at banners, illustrations and content in articles in other languages, especially the one in the native language of the region. It would be helpful with some mechanism notifying (on the articles talk page?) about banner changes on Wikivoyage and Wikidata, new articles on the subject (destination) appearing in other languages or such articles being significantly expanded. May be a general mechanism could be introduced, but a bot could handle much of this.
--LPfi (talk) 10:46, 1 October 2017 (UTC)Reply
Since Template:Pagebanner already fetches a banner from Wikidata, it wouldn't be much of a hassle to get it (the template) to add the banner to a category such as Category:Banner not equal to Wikidata. If we get that going in all other-language instances of that template, then we can compare the outcome of those categories to see which pages have other banners than specified in Wikidata, as well as see which other-language instances of the article have different banners. Ideally we'd get a recurring bot to compare these categories and produce a list of Different pagebanner articles in one of it's userpages. At that point, people could browse through that list and compare the banners, pick their favorite and edit them manually (or in someway notify the bot of their preference and have it change it universally, but that seems somewhat too tedious). I haven't got a clue as to how realistic this solution is, but it's a solution.
-- Wauteurz (talk) 08:40, 2 October 2017 (UTC)Reply
We already have category:banner missing from Wikidata. Do we need another category for basically the same task? K7L (talk) 02:27, 3 October 2017 (UTC)Reply

@K7L: I am well aware of that category's existence. The category I posed above however, collects the pages that have a different banner than is listed in the Wikidata listing, whereas missing from Wikidata reports the pages that have no banner image specified in the Wikidata entry. I'll most likely make a list of what I would want from a bot should a new one be created.
-- Wauteurz (talk) 09:10, 3 October 2017 (UTC)Reply

Requesting a new bot? edit

After some digging around I found that d:User:Kizar, who controls the bot, is rather inactive [7] [8]. Seen as how the bot responsible for the banners does not seem to be open source, isn't this a good time to gather what we would want out of a bot for this purpose should we want a new one, and possibly request a new one that is open source and can be activated by multiple users to ensure that the bot stays accessible?
-- Wauteurz (talk) 16:49, 2 October 2017 (UTC)Reply

I contacted Kizar but indeed s/he is even more inactive than in 2015 it seems. I also tried to do it myself using HarvestTemplates but my query does not make the difference between generic banners and custom ones so it is not usable. Requesting a bot is a good idea. Syced (talk) 04:27, 3 October 2017 (UTC)Reply
Hello both, sorry for the late response. I run the script yesterday. The remaining articles in the category must be fixed by hand. There are 2 issues: articles without page in Wikidata (create it manually) and articles with the banner hosted in Wikivoyage (move it to Commons). The code is awful and commented in Spanish but here it's. I can run the script again in the future if you need. Regards --Kizar (talk) 12:07, 7 December 2017 (UTC)Reply

New bot proposal edit

As announced, I have made a rough list of what I look for should a new bot be requested. I don't mind being the person that ends up stepping forward and actually request the bot to be created, but I do wish to have some feedback on whether or not my view on this is shared by all of us.

The bot requires several core functions, sorted below by importance:

  1. Synchronise en-Wikivoyage banners of articles to the associated Wikidata listings in the page banner-parameter (P948) where that isn't the case yet (i.e., sync the pages in Category:Banner missing from Wikidata to Wikidata).
    • We only want the banner to be synced if the addition or change of the banner has been done more than 48 hours before the check. If not, add the article to Category:Articles with recently changed banners and have the bot come back to these first as soon as it gets restarted for another go.
  2. Check the pagebanners on en-Wikivoyage articles with what is specified in the associated Wikidata's parameter (P948). Should the two differ, then update the Wikidata listing, should the banner have been changed >48 hours before the check.
    • Again, we'd like to have the opportunity to verify. Therefore, if the time between change and check is less than 48 hours, add the article to Category:Articles with different banners than Wikidata. Once again, should the bot be done and be set back to work, it will first check that category, verify that all is good, do what it must and go on as usual.
  3. Find articles that have different banners on other-language Wikivoyage articles, and add these to Category:Articles with different pagebanners elsewhere. After this, manual review can be done to determine which of the banners is better for the article on ENWikivoyage.

The points listed above should only be done when initiated by a user that has been whitelisted to do so. Note that multiple people must be able to operate the bot, though not at the same time per se. Features 1 and 2 I recon can best be done simultaneously as it is calling the same pages in both tasks. I recon the bot can have an internal whitelist of who can initiate it and I plan to use that so that the bot doesn't fall into a limbo of non-usage, leaving the categories it is responsible for unattended without anyone being able to do something about it without doing the manual tasks themselves, as is the case now (October 2017). My general line of thought here is that the bot should always be able to be controlled by at least one active user.

Debatable points:

  • Should pagebanners get added immediately if the user is an Autopatroller or above? I think the best means of measure here is to check if the edit to the banner has been marked as patrolled. I'd like to make this a feature as to not crowd the categories (they probably will see very few members either way) should traffic and participation on Wikivoyage rise in the future. See this feature as a means of future-proofing. Autopatroller and above seems a good rule of thumb as they "are less likely to need help with formatting and following policies", as stated on the description page for the user group.
  • Is adding categories for the articles that turn out to have be created less than 48 hours before the bot checks the article a good measure to take? Should we rather have the bot leave the page alone if the article qualifies as recently edited?

Once more, please verify this view on how a new bot should work according to me. I would like for all involved to support the addition of it once the bot's creation gets requested. -- Wauteurz (talk) 19:20, 5 October 2017 (UTC)Reply

Disagree - I do not think wikidata should override code on Wikivoyage. If there is no banner on the Wikivoyage page and is one on Wikidata then yes good idea, but if there is a different one on Wikivoyager than that named on Wikidata there could be a good reason for it. Such changes should be manual and maybe after discussion in the talk page. If there is a banner on WIkivoyage and non mentioned on Wikidata then that would also be OK to automate. --Traveler100 (talk) 19:30, 5 October 2017 (UTC)Reply
@Traveler100: I might be mistaken, but I can't find any point in which I mentioned that a Wikivoyage article banner will be overwritten based on Wikidata parameters, and neither do I intend to make that a feature. Can you tell me what let you to believe that that is a goal I wish to achieve with a new bot? What I did say, however, is that if Wikidata and Wikivoyage should have different banner images specified, then the bot should overwrite the image specified in Wikidata.
-- Wauteurz (talk) 19:45, 5 October 2017 (UTC)Reply
I programmer reading $1 will synchronize the data. It does not state "only when default is current recent Wikivoyage value. Computers do what you say not what you mean. The sentence need to be much clearer if you think I am misunderstanding what it is asking for. --Traveler100 (talk) 19:53, 5 October 2017 (UTC)Reply
I am strongly against #2, because it means that English Wikivoyage community has some super-authority over other language versions, who typically call banners from Wikidata and do not try to store everything locally. #3 is largely irrelevant for the same reason. --Alexander (talk) 19:35, 5 October 2017 (UTC)Reply
@Atsirlin: It isn't my intent to give ENWikivoyage authority over other-language edition, and I believe my wording is somewhat lacking in that aspect. I've reworded #3 somewhat to better reflect that. I see how #2 can be a bad change. What might be the better option then, is to give the Wikidata parameter multiple statuses, one referring to ENWikivoyage, the other to the other-language version and making sure that Template:Pagebanner can deal with this, preferring one language edition over the other, should multiple entries exist for the parameter.
-- Wauteurz (talk) 19:45, 5 October 2017 (UTC)Reply
Well, Wikidata is designed to store information used by several projects. It does not make sense to duplicate on Wikidata something that is used in English Wikivoyage only. I don't think it will be approved by Wikidata either.
In fact, I have to say that I do not understand this peculiarity of English Wikivoyage about page banners. Is the concept of page banners here different from other language versions? Obviously, not. Are there many discussions about page banners? Not at all. We have 5 times more such discussions in Russian Wikivoyage, which is especially striking given the smaller size of the community. Does the English community participate in page banner contests and harvest new high-quality banners? No. So why not to use page banners from Wikidata like everyone else does? --Alexander (talk) 20:43, 5 October 2017 (UTC)Reply

Let's start with #1 only. I believe we should not ask for #2 or #3 as it would lower our chances of getting the bot implemented quickly. After #1 is done, we can start asking for additional things, but in my opinion #1 is a hundred time more important. Syced (talk) 06:00, 11 October 2017 (UTC)Reply

Pagebanner sync to Wikidata the second edit

As of writing this, the category for banners missing from Wikidata items is filled with some 500 articles. I'd like to use this moment to raise attention to the fact that d:User:Kizar, who operates the pagebanner bot, is still fairly inactive. They have, upon request, released the code behind the bot though, which in my opinion is a good time to reconsider the bot. Where do we go from here with the bot? Do we keep Kizar's bot as-is? Do we re-host the bot on an account of our own? Do we request a fully-new bot (with possibly some new functions if desired)?

From what I can gather, Kizar's bot is somewhat undesirable seen their inactivity. The issue with re-hosting their script on another bot is that the script is in Spanish and would require Spanish people to maintain the bot. I've translated the script where possible, but my knowledge of Python is lacking to where I do not know whether the bot would still be functioning with said script. Another downside to re-hosting the bot is that it would have to be re-evaluated before being allowed to be put into service. The advantage of starting with a new bot made from scratch would be that things like a trigger could be added (for example: {{#ifexpr:500 - {{PAGESINCATEGORY:Banner missing from Wikidata|R}} > 0 | yes | no}}, which would output yes when Category:Banner missing from Wikidata has 500 or more members, and output no when that number is less than 500. This could be placed on a page in the bot's userspace. The output can then be read and the bot therefore activated automatically).

To clarify: I'm not saying that either of these options is the right way to go, I'd just like to know how other Wikivoyagers stand on the matter only to then discuss a possible change.
-- Wauteurz (talk) 18:29, 11 February 2018 (UTC)Reply

A little help edit

I've just put a new banner here. It may needs resizing, which is beyond my ken. Thanks for your help. Ground Zero (talk) 13:37, 30 March 2018 (UTC)Reply

  Done -- Wauteurz (talk) 15:28, 30 March 2018 (UTC)Reply

And the banner at Merritt. I can't access the CropTool on my tablet, so I have to ask for help. Thanks. Ground Zero (talk) 12:20, 20 May 2018 (UTC)Reply

I am having problems with the CropTool on a PC at the moment. I last used it on 14 May. AlasdairW (talk) 21:04, 20 May 2018 (UTC)Reply
The tool is now working again, and I have just cropped the banner. AlasdairW (talk) 22:54, 22 May 2018 (UTC)Reply

edit

An interesting area & quite popular as a tourist destination, mainly for diving. Article needs quite a bit of help, including a banner. Pashley (talk) 00:12, 30 July 2018 (UTC)Reply

Someone inserted a nice one. Thanks! Pashley (talk) 20:49, 30 July 2018 (UTC)Reply

Wikivoyage banners in Wiki Loves Monuments 2018 edit

Swept in from the pub

We are glad to announce the annual Wikivoyage banner competition as part of Wiki Loves Monuments 2018! Take photos of cultural heritage monuments, crop them to the Wikivoyage format (7:1, as all of you should know...), and upload the banners to Wikimedia Commons. Best contributions will find their place in the travel guides and receive small awards from our ru-WV community.

I would be grateful if people with access to social networks of Wikivoyage will share this information.
@Andyrom75, Lkcl it, Adehertogh, Yuriy_kosygin, DerFussi
Others: just talk to your neighbors, and participate yourself!

Have fun with cultural heritage! --Alexander (talk) 14:37, 31 August 2018 (UTC)Reply

Ok, we'll take care soon about it. --Andyrom75 (talk) 08:48, 1 September 2018 (UTC)Reply
@Atsirlin:@Andyrom75: I've just scheduled the post on fb and twitter. I've also tried to translate the page in Italian, with no result ... Is this edit correct? (if not please revert it). Btw you can find my translation here, can you add it? --Lkcl it (Talk) 19:40, 1 September 2018 (UTC)Reply
Lkcl_it, thank you! I have no idea how this bloody translation system works. It looks like we can't do anything without translation administrators. I have asked some of them. Let's see what happens. --Alexander (talk) 20:46, 1 September 2018 (UTC)Reply
Lkcl_it, I managed it somehow. Please, take a look.
Two small requests from my side:
1. The upload wizard has the field 'Source image (Commons file that your banner was cropped from)'. Could you suggest me the Italian translation for it?
2. Could you reach the guys organizing WLM in Italy and ask them that they add information about the banner competition to their website. Unfortunately, I don't have time to contact every country (there are nearly 50 countries in WLM this year!), and I am sure they will be happier if you ask them in Italian.
Thanks! --Alexander (talk) 21:37, 1 September 2018 (UTC)Reply
Great! Thanks.
1. A translation could be "Immagine originale (File Commons da cui il banner è stato ricavato)".
2. I'll write the email shortly and I'll let you know. --Lkcl it (Talk) 09:29, 2 September 2018 (UTC)Reply

Adding maintenance category for duplicate banners edit

{{swept

Would anyone be opposed to adding a category like this one? I saw a couple of articles with locally-defined banners that were exactly the same as the ones in Wikidata, meaning double the work is needed to change them. The category can have a standard disclaimer at the top like the Russian WV has, which I can translate if necessary, but basically says, "If the local banner is worse than the Wikidata one, simply delete the parameter, but if it's better, either begin the process for changing the Wikidata banner or leave it alone." Either way, there are potentially many pages with this kind of banner problem.

I'm not 100% sure how to do this, but if it's just adding the appropriate if statement to the template code and creating the page, I can do it if need be. ARR8 (talk) 14:55, 6 September 2018 (UTC)Reply

I suppose that is our default. That way others can use the same banner automagically, while a change at Wikidata won't affect us. On the other hand, if the banners differ – or is different to one used on any WV version – then checking and possibly changing it in some place might be worthwhile. --LPfi (talk) 15:04, 6 September 2018 (UTC)Reply
I don't think that duplicate banners is a problem. Different languages divide countries up into different sized chunks. We may have a huge city with 10 banners for the the city and its districts. If another language has not split the city into districts, I see no problem if they pick a different one for the city (possibly one which we use on a district). Different languages also appear to have different preferences for panorama v detailed views for banners. There is only a real need to change an existing Wikidata banner if the image is deleted or has been incorrectly applied to the wrong location. AlasdairW (talk) 20:44, 6 September 2018 (UTC)Reply
Makes sense to me. ARR8 (talk) 03:11, 7 September 2018 (UTC)Reply
@LPfi, AlasdairW:, do either of you have any thoughts on creating the category? It doesn't necessitate any action taken, but it would be easier to see the scope of the problem. ARR8 (talk) 03:11, 7 September 2018 (UTC)Reply
There are instances of banners being different on different voyage wikis as well. India being but one example. I don't believe banners should be restricted to that found only in Wikidata. Replacing one in Wikidata affects all those that "autorestrictomagically" refer to them. Use of a locally defined banner can eliminate the prospect of unwanted replacement in a particular wiki be they duplicate or not. Having a banner in Wikidata is naught but a convenience unless it is now a prerequisite that all wikis use the one banner. If wikivoyage banner in Wikidata is an array; perhaps, adding an alternative or two might be useful. Adding a banner to Wikidata if one does not exist makes sense as well as replacing a banner if it doesn't belong. There is no single authority. -- Matroc (talk) 03:47, 7 September 2018 (UTC)Reply
I was thinking the opposite, that we could delete the local definition of a banner if it is the same as the one in Wikidata, anyway. I wouldn't want to change them in Wikidata if multiple languages have the same article, or remove any local definitions if a specific WV has found an image that better illustrates their article. In fact, I would be opposed to any unilateral changes to the Wikidata banner for a location. What I do think is that the majority of the articles here which manually specify a banner will probably never differ from Wikidata, and probably aren't too attached to a specific image, rather only using the best available, in which case removing the local definition can save some maintenance. I wouldn't want to batch remove all local banners, either, because I'm sure there are some articles which override the Wikidata banner for a reason. ARR8 (talk) 04:11, 7 September 2018 (UTC)Reply
There is a tradeoff, and I think the consensus here is that the chances of a better banner found and making its way to Wikidata without us noticing is less than the frustration of a good banner at WD being exchanged for a less suitable (according to the taste of whoever cares). If we have a banner, it can be assumed to be good enough, while there is no guarantee that the new banner at WD isn't problematic in some way. The new WD banner can still be evaluated by anybody working with the article. The consensus could change, of course, but probably not without some time passing or very good arguments being made. --LPfi (talk) 16:26, 7 September 2018 (UTC)Reply
Unfortunately data can be changed on Wikidata without anybody noticing. There is an option to "Show Wikidata edits in your watchlist" but I have found this to be no help, as it notifies me if anything changes in the related Wikidata item, when I only want to know if something which impacts the article changes. After a few days of trying this option, I turned it off. However I do want to know if somebody changes the banner of a watched page. In particular, I want to know if the banner has been changed to a picture of a hotel or other business.
A recent bot edit on Wikidata changed the UK emergency phone number (999) by incorrectly adding a digit. It took 3 months for anybody to notice, despite this being used on several country pages.
It would be useful if a bot could put a message on the article's talk page when a new banner is added to Wikidata, but I would not want any automatic changes. AlasdairW (talk) 20:55, 7 September 2018 (UTC)Reply
Calling User:Lydia Pintscher (WMDE): Could your project to limit 'noise' in the watchlist be adapted to Wikivoyage's needs? We'd want banners and whatever is used in the article (e.g., latitude/longitude). WhatamIdoing (talk) 18:46, 9 September 2018 (UTC)Reply
User:WhatamIdoing: Thanks for the ping! The system should already work from our side. There might be two remaining potentially bigger issues: 1) Local templates sometimes load the whole item instead of specific parts of it. These need to be changed in order to get fewer edits from Wikidata to show up in the watchlist here. 2) If you get the page banner via an extension and not Lua then it might not be tracked correctly by us. If this is the case and people here would like this changed then it'd be great if someone could open a ticket for it. --Lydia Pintscher (WMDE) (talk) 20:37, 15 September 2018 (UTC)Reply
@LPfi: I understand. There is a tradeoff, and the status quo works fine. I'm happy to leave the issue be. However, I'd still like to create the category, if only for completeness' sake. Would you be opposed? @AlasdairW: ARR8 (talk) 01:35, 8 September 2018 (UTC)Reply
I suppose it'd do no harm. I am not going to figure out how to create it though; I haven't created that kind of categories before. --LPfi (talk) 07:17, 8 September 2018 (UTC)Reply
I don't object to creating the category, but I haven't a clue how to do it. AlasdairW (talk) 10:37, 8 September 2018 (UTC)Reply
Thanks all for the discussion. ARR8 (talk) 14:45, 8 September 2018 (UTC)Reply
I've added this change to the {{pagebanner/sandbox}}, and it seems to work fine. Would an administrator consider adding it in? I'm not sure if this is the right place to ping admins; if it's not, I'd appreciate it if someone would point the way. ARR8 (talk) 16:08, 8 September 2018 (UTC)Reply
This will create too many false warnings. It only checks of a banner page name is present, will show as different from Wikidata even if same as Wikidata pagebanner. The check needs to be more precise. --Traveler100 (talk) 16:35, 8 September 2018 (UTC)Reply
I have updated the sandbox version to only place articles in this category if they are different. Need to test a little more but appears to work. --Traveler100 (talk) 16:50, 8 September 2018 (UTC)Reply
I cannot support the idea of removing the banner name from an article when it is the same as on Wikidata. Wikidata is not very discoverable for many users, not just new ones. Having on the article page makes it clearing what is happening and easier for contributors to edit. If changes the article will be added to the category and others can comment on if it is an improvement on the Wikidata version. --Traveler100 (talk) 16:54, 8 September 2018 (UTC)Reply
@Traveler100: Yes, this resembles the other concerns mentioned above. At this point, I'm forced to agree. Perhaps in the future, when Wikidata becomes a little more accessible and integrated with wiki projects, this can be reconsidered. Either way, I think there's no harm in adding the category. ARR8 (talk) 16:59, 8 September 2018 (UTC)Reply
@Traveler100: Yes, that was intentional. The name of the category is a little misleading, but I wrote about it in the description, and it matches the way the category is used on the Russian and Ukrainian WVs. Of course, if the category is more useful showing only banners that differ, then it makes sense to keep it this way, but I'd originally intended it to show pages that had banners defined in both places, even if they were identical. Perhaps there's room for both categories? ARR8 (talk) 16:57, 8 September 2018 (UTC)Reply
The ones needing attention are those that have the banner defined only in one of the places. If on Wikidata, it means there is a banner, which could probably be used and should be added explicitly. If on Wikivoyage, it should probably be helpful to add it to Wikidata. I think the one you requested is more for curiosity, it mostly means the banner is defined according to our practice. --LPfi (talk) 17:31, 9 September 2018 (UTC)Reply
You're probably right. ARR8 (talk) 21:23, 9 September 2018 (UTC)Reply

Are banners with other dimensions than 7:1 allowed nowadays? edit

Almost every day I randomly check out articles that come up in Recent changes, and when looking for new discoveries (once/twice a week), I click on "Random page" in the left sidebar and open up 10-20 articles in tabs to look for some interesting facts in different articles.

Now over the last few months I've quite often stumbled upon articles with custom banners that are too tall, recent examples being Bakkhali and Rail travel in the Czech Republic. Formerly, say, a year ago, one could probably spend a day systematically browsing through articles without running into even one with a banner with wrong dimensions. Has there been some recent changes in policy allowing banners of other dimensions than 7:1? ϒpsilon (talk) 18:16, 20 September 2018 (UTC)Reply

I don't think there's been a change in policy. Maybe a change in enforcement? Hobbitschuster (talk) 18:34, 20 September 2018 (UTC)Reply
Of course there hasn't been a change in policy. Why would that question even be asked? If the policy had changed, there would be a thread on this page discussing the proposed changes and different language on the project page. Ikan Kekek (talk) 19:20, 20 September 2018 (UTC)Reply
(edit conflict) There's been no change in policy. I think there are just more new users adding custom banners than there used to be.
When you come across these oversized banners, you can help us out either by putting in the{{crop}} template, or by reverting to the appropriate default banner, or by making a new custom banner yourself. The first of these should be done for banners which have potential (or you can set the right dimensions), while the second and last are best for the poor-quality large banners that won't look any better when cropped.--ThunderingTyphoons! (talk) 19:32, 20 September 2018 (UTC)Reply
Well, for some reason I've just seen a lot of them recently, in fact I've stumbled upon two more of them in the last hour (Mawlamyine, https://en.wikivoyage.org/w/index.php?title=Tirupati&oldid=3614722). ϒpsilon (talk) 19:34, 20 September 2018 (UTC)Reply
Looking at the second link, it appears that the pagebanner template has automatically cropped a 1.4:1 image to about 4:1. This ratio is about the same as the banners on WT. I think both of these things could confuse new users. AlasdairW (talk) 20:06, 20 September 2018 (UTC)Reply

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

Swept in from the pub

Over the last years I have created many 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 17 discussions and indicate in each of the discussions which banner you prefer seeing at the top of this article.

ויקיג'אנקי (talk) 09:10, 13 September 2018 (UTC)Reply

Thank you for sharing these and L'Shana Tova. Ikan Kekek (talk) 09:42, 13 September 2018 (UTC)Reply
Thanks ויקיג'אנקי (talk) 13:37, 15 September 2018 (UTC)Reply

Pagebanner default vs. continent pagebanner default edit

Swept in from the pub

There is a default pagebanner for destinations but there are also versions for continents, etc., like this banner. Should we use the regional defaults or the world default for our articles? --Comment by Selfie City (talk | contributions) 19:14, 12 November 2018 (UTC)Reply

Pagebanner default.jpg is (sadly) automagically entered when creating a new stub. I've considered bringing this up before because automatically inserting this makes it to where we cannot accept banners defined on Wikidata linked by other language editions, which is a shame. The code is there in {{Pagebanner}} to work perfectly fine with the regional banners, and it needs just a little bit of code to work out which one to show if no custom one is entered (which can be achieved through {{IsIn}}, for example). I personally like the idea of regional differences (they may not be noticeable if you don't look at it, but it adds a nice touch nonetheless), it's just that the tools we have created over time make it an unused feature. I'd be supportive of wiping Pagebanner default.jpg from every instance of pagebanner and automatically make the pagebanner template work out which banner to show. I don't think I possess the knowledge or tools to switch this myself. If I could, I would have mentioned this a long time ago.
-- Wauteurz (talk) 19:25, 12 November 2018 (UTC)Reply
Well, if you add {{pagebanner}}, it shows up in red like it was a mistake, right? But it still works. --Comment by Selfie City (talk | contributions) 19:27, 12 November 2018 (UTC)Reply
IMO the "global default banner" is better than no banner at all, and if you can't remember the file name for the "local default banner", I think it's useful that the global version is automatically added. Just my opinion. ϒψιλον (talk) 19:32, 12 November 2018 (UTC)Reply
Strongly agree with User:Wauteurz. Although I have been told that we do like to have custom banners defined locally here, there's no reason for that to be the case with generic banners, which the template handles on its own. @Ypsilon: You don't have to remember anything. The template does the appropriate regional variation for you. ARR8 (talk) 19:56, 12 November 2018 (UTC)Reply
Also, @SelfieCity: I've adjusted the templatedata, setting the image parameter to suggested, not required. Shouldn't throw an error anymore. ARR8 (talk) 20:03, 12 November 2018 (UTC)Reply
No, in the source code it's still showing up red, unfortunately. --Comment by Selfie City (talk | contributions) 20:05, 12 November 2018 (UTC)Reply
@SelfieCity: I can't say I've heard this before. What are you doing to get that result? Just adding the template without parameters?
@Ypsilon: {{Pagebanner}} should work to display the standard banner for Mena-asia if you enter {{Pagebanner|Asia}}. From my brief testing using page previews, this does work. You can type in the continent or region rather than having to remember the filename. Some of the options include Asia, Europe, North-Africa, TT, Itinerary, Diving, Phrasebook, New Zealand, Australia, Caribbean and North America.
@ARR8: There is a preference to locally define banners, I know that from experience, but there are some good banners out there on other language projects. It's a waste of time if we'd not accept those in where they are already available. If they suck, then we can always replace them, but I'd argue that the Pagebanner is essential to Wikivoyage's identity, and that having a colourful custom one is infinitely better than having the default banner. Besides, there aren't that many destinations that had a custom banner. I've seen at most 20 custom ones when creating the 750 banners I have made, and 20 is a high estimate, I'm sure. If that number is representative, then we're talking about 302 existing banners that would be imported. Besides, there surely is a way to group that into a category for "Pagebanner fetched from Wikidata" if that doesn't happen yet, just so these banners can be easily reviewed at one point or another.
-- Wauteurz (talk) 20:06, 12 November 2018 (UTC)Reply
Yes, all I was adding was {{pagebanner}}. --Comment by Selfie City (talk | contributions) 20:08, 12 November 2018 (UTC)Reply
I didn't know that — thanks for the heads up! ϒψιλον (talk) 20:09, 12 November 2018 (UTC)Reply
@Wauteurz: Yes. I'm pretty sure we're in complete agreement; I was told about the practice for custom banners here in my first post to the Pub. I still think we should switch to Wikidata-only definitions at some point in the future, maybe when concerns about reliability of Wikidata are addressed. Either way, I think it would be great to passively benefit from the work of other WV languages and vice-versa. ARR8 (talk) 20:25, 12 November 2018 (UTC)Reply
Actually, seems there's nothing to worry about. Dunkirk, right now, has "Pagebanner default.jpg" defined, but is displaying a banner from Wikidata. I was going to propose changing the article skeleton templates to remove the pagebanner definition, but don't see a good reason now. ARR8 (talk) 20:27, 17 November 2018 (UTC)Reply
@ARR8: I'm a bit confused by Dunkirk right now. If locally defining banners has a priority, then why doesn't specifying a default banner have priority over Wikidata? A custom locally defined banner has priority over Wikidata at the least, so I'm guessing that a "Any banner is better than a default banner"-mindset is at play here?
As for changing the skeleton: The only reason I can think of to remove Pagebanner default.jpg would be to allow the template to automatically insert the appropriate regional pagebanner. I'm not sure the template is capable of figuring out which one should be displayed at this time though, but I don't think that's impossible to implement. If we don't, then we might as well toss the regional default banners, since no-one will bother using them if they aren't able to be inserted through skeletons, and I don't think many people are aware of these regional default banners existing in the first place. If anything, a little drop-down menu next to the skeleton buttons could help, which lets you select the continent and change the pagebanner default on that basis.
-- Wauteurz (talk) 21:18, 17 November 2018 (UTC)Reply
Taking a look at the code now, seems that's exactly the case. If any of a few predefined "default banners" are set, it will overwrite them with the WD property if it exists. This is also true for shortcuts like Asia, Africa, Caribbean, etc. Given the choices you mentioned, it seems to me it would be best to implement the location logic, as trying to teach everyone, including new editors, about these shortcuts might be an uphill battle, and selection tools for skeletons might not even be used if people are just copy-pasting them. ARR8 (talk) 21:31, 17 November 2018 (UTC)Reply

────────────────────────────────────────────────────────────────────────────────────────────────────

I had the same issue before with banners. The edit history of Motorcycle speedway shows the problems I had with this, and I eventually brought it up in the Pub and learned that sometimes you had to edit Wikidata to solve the problem. --Comment by Selfie City (talk | contributions) 21:57, 17 November 2018 (UTC)Reply

@ARR8, SelfieCity: I've previously edited {{Pagebanner/sandbox}} to make the first switch function allow for a bit more of an overview, but I've gone ahead and pushed two more changes to it now. First of all, the first switch function now auto-converts the first parameter (i.e., the image you enter as banner or the short-cut for a default banner) to lowercase, so that {{Pagebanner|Asia}} works as it did, but {{Pagebanner|asia}}, {{Pagebanner|AsIa}}, {{Pagebanner|ASIA}} (with any capitalisation) now gives the same result: the meno-asia default banner. Idem dito was done for the other default banners. Secondly, I removed the default banners from the first switch function so that they don't force a fetch from Wikidata. This should resolve everything. A page preview of Dunkirk with {{Pagebanner/sandbox|Pagebanner default.jpg|unesco=true}} now returns the desired default banner. I'd suggest we wait for some of the more frequent/notable editors to {{Pagebanner}} to add their ten cents on whether or not Wikidata should be preferred over a default banner or not (@Wrh2, Shaundd, WOSlinker:) before we get an admin to push the changes to the template proper.
-- Wauteurz (talk) 22:31, 17 November 2018 (UTC)Reply

Reducing the number of pages using the Pagebanner default image.jpg edit

Swept in from the pub

Under Standard Templates, on the at the right hand side of the Maintenance panel homepage, are the categories of Has custom banner and Has standard banner. These currently total 15784 pages and 1937 pages respectively. The names of the 11,163 pages that have the Pagebanner default.jpg image at the top is missing. This is needed so that a list of pages that need a custom banner made can be easily found.

Since we can show the number of pages that Has custom banner, shouldn't we be able to show the number of pages that Has default banner or Missing custom banner? Alternatively, could we add under Maintenance Categories a list of these pages.

Since it is hard to find to find the pages with the Pagebanner default image, except by randomly displaying pages, the number of pages using this image is likely to continue to remain high. Perhaps there is some other way to find these pages on Wikivoyage without looking up individual page names on Wikimedia Commons? Zcarstvnz (talk) 11:14, 21 January 2019 (UTC)Reply

@Zcarstvnz: is Category:Has default banner what you are looking for? I have added to Maintenance panel. --Traveler100 (talk) 11:57, 21 January 2019 (UTC)Reply
@Traveler100: Yes, that is exactly what I was look to see. Thanks! Zcarstvnz (talk) 12:52, 21 January 2019 (UTC)Reply

DOTM banners/Commons edit

Swept in from the pub

Ypsilon and AndreCarrotflower, when you create a DOTM banner image, how do you do it? My main problems are creating a duplicate image so I can crop it. I know this is mostly a Commons-related question, but hopefully you can explain how you crop images in Commons. Thanks.

If anyone else knows how to do it, or has a link to a tutorial, feel free to explain. --Comment by Selfie City (talk | contributions) 22:37, 9 February 2019 (UTC)Reply

So far, I've figured out how to get GIMP and I'm working on doing a new DOTM banner choice for Chapel Hill. --Comment by Selfie City (talk | contributions) 23:08, 9 February 2019 (UTC)Reply
I've got it worked out now. Maybe, though, just check the file pages to make sure I've got the basics right. However, hopefully the recent effort will give some people a break on having to find banner pictures! --Comment by Selfie City (talk | contributions) 00:21, 10 February 2019 (UTC)Reply

Banners needed everywhere? edit

While we are at it - I really appreciate the effort and everything, but what should be the purpose of the banners? I would say probably to convince visitors to visit the area by highlighting the best part of the area? While e.g.

 

is probably a good representative of the common settlements in the Abov area, I would not say this is the reason why anyone would visit there... Do the banners need to be really unique? It will increase the size of the stuff to be downloaded (e.g. for offline version) with quite little gain - unless the banner is a really nice picture. -- andree.sk(talk) 08:51, 12 February 2019 (UTC)Reply

I think the solution for bad banners is to replace them with good ones. :-) Ikan Kekek (talk) 09:12, 12 February 2019 (UTC)Reply
Agreed. --Comment by Selfie City (talk | contributions) 15:10, 12 February 2019 (UTC)Reply

This month's cotm: custom banners! edit

Swept in from the pub

This month, the collaboration of the month is custom banners. Please go the list of non-city articles with default banners and try to find as many custom pagebanners as you can for each of the options on the list. Use images from Commons, preferably, or Flickr, and if you decide to edit the images using a tool other than CropTool, when you upload the new version of the image, be careful to make sure that you get the attribution correct. --Comment by Selfie City (talk | contributions) 03:07, 1 March 2019 (UTC)Reply

Proposed minor adjustment to duplicate pagebanners rule edit

Swept in from the pub

I propose that, in certain limited situations, pagebanners for a region may also be used for a phrasebook. For example, according to the text in Bashkir phrasebook, people speak that language in a specific region called Bashkortostan. Therefore, the banner used in Bashkortostan should be, IMO, used in the Bashkir phrasebook article as well.

Doing this would make it much easier to have custom pagebanners for phrasebooks.

--Comment by Selfie City (talk | contributions) 01:25, 2 March 2019 (UTC)Reply

I'm kind of not convinced. Basically, you're saying that languages with relatively small numbers of speakers shouldn't have unique pagebanners? Ikan Kekek (talk) 08:20, 2 March 2019 (UTC)Reply
In the case of phrasebooks, I think that the default banner is good and is coloured unlike the main default banners. So there is little benefit to the reader in changing for the sake of it. It is more likely that a reader will have the region and phrasebook pages open at the same time that two phrasebooks. AlasdairW (talk) 09:22, 2 March 2019 (UTC)Reply
I'm not particularly for or against this idea, but just to point out that the Welsh phrasebook already uses the same banner as Wales, and there may well be other duplicates like this already. I don't think that really impacts negatively on reader perceptions of Wikivoyage, even though I personally would prefer a banner depicting the written Welsh language.--ThunderingTyphoons! (talk) 10:33, 2 March 2019 (UTC)Reply
Yes, a banner that represents the language involved would be my preference too. Specially when another alphabet is used in the language. --FredTC (talk) 10:52, 2 March 2019 (UTC)Reply
I think a banner that represents the language or a banner that represents the destination is good – maybe it depends on the language in question. I don't think there's a need to duplicate the banner for Bashkortostan – it has many beautiful images on Commons, so we can easily make two good banners. In some cases it might make sense for the phrasebook banner to emphasize a different aspect of the destination than the region/country banner. For instance, since most travelers to Bashkortostan wouldn't need the phrasebook (they can just use Russian), maybe the phrasebook banner can focus on some cultural attraction that might be harder to access without speaking the language, rather than scenery like the region banner. (That's similar to what I tried to do with the Dhivehi phrasebook banner.) —Granger (talk · contribs) 01:10, 3 March 2019 (UTC)Reply
I think we should strive for each page to have a unique banner, but failing that, I think a pagebanner that's also used elsewhere is still better than the default banner. And I think that also holds true for articles other than phrasebooks. -- AndreCarrotflower (talk) 01:27, 3 March 2019 (UTC)Reply

Page banners look different, have errors edit

Swept in from the pub

Something has happened to the pagebanners, and I see it both in Safari and Firefox and both on laptop and phone. First I noticed the names of articles are written in a different font (though this is not much of a problem). But then I noticed markers in the upper right corner are all blacked out (the Star article marker has turned into a barely visible black star). Check out for instance Bali that has all three types of markers (UNESCO World Heritage Site, Star article, Previous DotM). ϒψιλον (talk) 11:43, 2 March 2019 (UTC)Reply

Seeing this too. --Traveler100 (talk) 12:02, 2 March 2019 (UTC)Reply
I'm also seeing this on Chrome for mobile.--ThunderingTyphoons! (talk) 12:37, 2 March 2019 (UTC)Reply
This is my fault; I was moving rules out of the global styles into the individual styles for the pagebanner template. It worked fine in testing, but it seems there are some issues I haven't accounted for. I've requested both interface admins to undo the change. ARR8 (talk | contribs) 14:04, 2 March 2019 (UTC)Reply
Hey ARR8! If you have the access and interest to do this, I got consensus awhile back to try out a new banner style. I never implemented it because I don't have the permissions to do so. Check out the styles here: User:ButteBag/common.css. If it's not your thing no big deal, figured I'd ask while you're poking around in there already. Thanks! --ButteBag (talk) 14:19, 2 March 2019 (UTC)Reply
Ha, I thought I had the access, but today's incident shows that I don't. Thanks for the information, though; I'm compiling all of this sort of thing to the wv:UX Expedition, and I'll put it on the list. ARR8 (talk | contribs) 14:25, 2 March 2019 (UTC)Reply

Excessively Large Banners edit

On the article page it states under How to make a quality banner that, "If done right, your banner will have a size of around 600KB to 1MB," but it states nothing about larger banners. Looking at the previous article topics on this Discussion page there is some indication that the page banner is automatically scaled. So if this is true, then is it true that creating or using banners of sizes greater than 1MB or even 20MB should never be a problem?

Temporarily ignoring the fact that page banner for Mammoth Lakes,using the file File:Lake George Mammoth September 2016 panorama 2.jpg, is incorrectly sized for Wikivoyage, the page banner is 20MB. I have already created the correct sized banner and it is 17MB. Are these oversized banners really acceptable and they won't cause any problems? I usually limit the banners I post to about 2 MB, but neither the Banner Expedition page nor the Discussion page state anything about using such massive files. Zcarstvnz (talk) 10:08, 23 April 2019 (UTC)Reply

Progress with custom page banners (COTM update) edit

Swept in from the pub

This month we've been focusing on adding page banners to articles, and this has been going very well. The stats are included on that page and as of 19 March (UTC), we've seen an 18% decrease in standard page banners for non-city articles; the best categories are region articles (standard banners down 35%), travel topics (standard banners down 28%), and phrasebooks (standard banners down 27%).

If you do add a pagebanner to an article, make sure to add the category "Wikivoyage banners of [country/region name]" to the page banner image, and make sure to follow the steps at the Category:Banner missing from Wikidata page. Even if you normally aren't a big cotm person, please feel free to join in and participate in the fun! For those who've contributed to the cotm, thanks so much for your work.

In November 2019 another COTM is scheduled of this nature, custom banners for usable articles. --Comment by Selfie City (talk | contributions) 03:23, 20 March 2019 (UTC)Reply

Is there a way to suggest banners? For example, Cycling in the United States is in the list, and any of these images might be feasible: File:Golden Gardens cyclists silhouette 02.jpg, File:Missisquoi Valley Rail Trail St. Albans Vermont.JPG, File:Tour of Utah - Stage Two (28449152780).jpg, or File:Rental bicycles and rack, downtown Nashville.JPG. I don't really want to crop and upload the images myself, but I wouldn't mind looking for source images, if someone else wanted to do the other part. WhatamIdoing (talk) 23:52, 20 March 2019 (UTC)Reply
Good idea. I've created User:SelfieCity/Banner suggestions where they can be suggested, for now. There's an older page for Wikivoyage:Banner expedition/Banner suggestions that is currently in the vfd process. --Comment by Selfie City (talk | contributions) 00:00, 21 March 2019 (UTC)Reply
If it is a good idea, then why not just use the old page and vote "keep" at vfd? I see no reason to have the page in user space instead of project space. Moreover, the lack of visibility was cited as a reason for failure of the page now in vfd. --LPfi (talk) 06:37, 21 March 2019 (UTC)Reply
AlasdairW, I believe, has adjusted the page as you wish. I currently plan to delete the page I created if WV:Banner expedition/Banner suggestions is kept, after the vfd discussion is closed. --Comment by Selfie City (talk | contributions) 01:38, 22 March 2019 (UTC)Reply
Mx. Granger modified the page. I just acted on the first suggestion and created a banner for Travelling on a low-carbohydrate diet. This was a useful suggestion as I had looked unsuccessfully for banners for this article a few weeks earlier. I hadn't thought of using a picture of nuts - the pictures of broccoli and kale that I looked at were unappealing. AlasdairW (talk) 14:52, 22 March 2019 (UTC)Reply
Thanks anyway, though! I'd just say that we now have only about a week left to do the banners, so let's really do it on the final push! Perhaps, try to get region article banners down 50% — that number is currently around 38%. I think we can definitely do it — maybe we can even reach 55% or 60% if we really do it at the end. --Comment by Selfie City (talk | contributions) 00:33, 23 March 2019 (UTC)Reply

Changing page banners edit

Swept in from the pub

Just wondering...

Is it ever allowed (per policy, consensus, etc.) to change page banners (for unimportant articles) without having a discussion first? --Comment by Selfie City (talk | contributions) 16:49, 21 April 2019 (UTC)Reply

I think that it is ok if the change is unlikely to be controversial. I have occasionally done it, most recently I replaced a banner on Wareham (England) that I had created, as the banner was nominated for deletion on Commons, although in this case the image was finally kept after 6 months discussion. I think that it also fine if the banner doesn't meet the technical requirements, or is of the wrong place. Replacing a banner which you created is also unlikely to be controversial. It is good to explain the banner change in the edit summary. AlasdairW (talk) 22:11, 21 April 2019 (UTC)Reply
Although it's noticeable that the three discussions you started recently produced better banners through discussion than the ones you proposed at first. Thanks again for getting the ball rolling on these discussions. Ground Zero (talk) 22:32, 21 April 2019 (UTC)Reply
I would also say that it's okay for someone with local knowledge of a particular destination to unilaterally replace a pro forma banner that was uploaded by an editor lacking such local knowledge solely for the sake of the article not having the default banner. -- AndreCarrotflower (talk) 23:07, 21 April 2019 (UTC)Reply
Thanks for your explanations! --Comment by Selfie City (talk | contributions) 00:05, 22 April 2019 (UTC)Reply

Twillingate edit

There is a panorama photo in this article that would be suited to being made a banner if someone with the necessary technical skills were inclined to do so. Thanks. Ground Zero (talk) 20:06, 15 June 2019 (UTC)Reply

The image is 1700 pixels wide, which is just below the 1800 minimum. Would File:Twillingate Hr, Newfoundland, canada.jpg be suitable? AlasdairW (talk) 21:12, 15 June 2019 (UTC)Reply
Its not a great picture, but it is better than having a default banner, so I'd say "yea". Thanks. Ground Zero (talk) 21:17, 15 June 2019 (UTC)Reply
  Done AlasdairW (talk) 23:10, 15 June 2019 (UTC)Reply

Gibsons edit

I have added a picture to this article that I think would be suited to bannerification if someone would be so kind. Ground Zero (talk) 20:42, 16 July 2019 (UTC)Reply

Lindsay edit

I have split the "Lindsay and Fenelon Falls" article into its component parts, which has left Lindsay without a banner. The commons doesn't have great pictures of Lindsay, but maybe someone will see something in the pictures in the article that could be used for a banner. Thank-you. Ground Zero (talk) 11:57, 8 September 2019 (UTC)Reply

I have added a different image. Not brilliant so if someone can find a better one, please go ahead and change. --Traveler100 (talk) 13:01, 8 September 2019 (UTC)Reply

@Traveler100: Thank you. It's not a bad picture. Recreational boating is important in the region, although not specifically in Lindsay. If we find a better image, I'm sure this one can be repurposed somewhere. Ground Zero (talk) 18:29, 10 September 2019 (UTC)Reply

breadcrumb trail edit

Where or what is "breadcrumb trail" in the Goals?--Dthomsen8 (talk) 03:46, 13 December 2019 (UTC)Reply

Spruce up breadcrumb trail & geo icon display is unreadable jargon to the newbie. Perhaps it could be a clear goal to the newbie and still be readable to the Wikivoyage experienced editor.
Yes could do with a little more explanation. Have added a link in the sentence to Wikivoyage:Breadcrumb navigation. --Traveler100 (talk) 05:41, 13 December 2019 (UTC)Reply
I think the "Spruce up breadcrumb trail & geo icon display" should be removed.It is not related to adding a banner to a page. There may have been an intention to make other improvements to an article at the same time, but as breadcrumbs rarely need to be changed these days (and are best done by those who know the area), and most articles have geo co-ordinates, these specific ideas are no longer relevant. AlasdairW (talk) 10:47, 13 December 2019 (UTC)Reply
Return to the project page "Banner Expedition/archive 2013-19".