Template talk:Pagebanner Voyage Tips and guide

Contents

Considering this template is still experimental, why has it been placed on over 100 articles? LtPowers (talk) 14:46, 14 April 2013 (UTC)Reply

See Wikivoyage_talk:TOC/Banner#Comments. As it is a proposal that would be rolled out on the entire mainspace, a test space of one country has been selected, so that we have a variety of page types and sizes to analyze. Texugo (talk) 14:51, 14 April 2013 (UTC)Reply

I really really love this feature on desktop but you should hide it for mobile.

Side note: we are doing some improvements on the mobile site so that the skin works on tablets. I would love this to be more of a core feature... Come chat with me on #wikimedia-mobile on irc :) Jdlrobson (talk) 04:10, 3 June 2013 (UTC)Reply

Hi, thanks for your message! It would look great on mobile if it worked, but alas, it does not. We aren't currently aware of a way to specifically hide certain elements/templates from the mobile skin. If you know how to do it, please enlighten us as it'd be of great assistance! As Wikivoyage is all about travelling, the mobile site will be of increasing importance, so we look forward to its future development. All the best, James A ▪ talk 06:03, 3 June 2013 (UTC)Reply

You can use the nomobile class on any element to hide it on mobile (although there is a bug - https://bugzilla.wikimedia.org/show_bug.cgi?id=48637). The better way if you can is to get the styling in a stylesheet and use media queries :) Come hang out in #wikimedia-mobile if you need any other help with mobile optimisation!! Jdlrobson (talk) 19:19, 3 June 2013 (UTC)Reply

Thanks for that! I'll let the others know about that advice and we'll pop past if we need any more :) James A ▪ talk 10:13, 4 June 2013 (UTC)Reply

Yeah, thanks, that was very helpful (and simple!). nomobile is added now so the banner is hidden for mobile. Is there a class that can be used to display images or text on mobile only? -Shaundd (talk) 05:17, 7 June 2013 (UTC)Reply

Update: See https://en.wikivoyage.org/wiki/MediaWiki_talk:Mobile.css#Template:Pagebanner_on_mobile Jdlrobson (talk) 19:39, 17 November 2013 (UTC)Reply

Poke is there any reason we can't apply this? Jdlrobson (talk) 23:53, 27 November 2013 (UTC)Reply

Plunge forward and see how it goes! LtPowers (talk) 02:04, 30 November 2013 (UTC)Reply

Greetings from Greece. First of all congratulations for this nice template. I 'm trying to use Template:Pagebanner in Greek Wikivoyage articles. Could you please tell me which other templates are needed so that it can work? Any further advice will be appreciated. Thanks in advance!-- Alien ^? 21:06, 4 June 2013 (UTC)Reply

I don't think there are any other templates needed, but you'll need to copy a number of things from Mediawiki:Common.css to the corresponding page on el:, specifically the sections titled:

• /* Suppress numbering of items in TOC */
• /* Styles for Pagebanner template */
• /* Style for hlist class */ and its associated subsections:

• /* Display list items inline and make them nowrap */
• /* Allow wrapping for list items (in tight spaces) */
• /* Display nested lists inline and allow them to wrap */
• /* Generate interpuncts */
• /* For IE8 */
• /* Add parentheses around nested lists */
• /* For IE8 */
• /* allow ToC to stretch across screen when it is part of a horizontal list, change background and font colours */
• /* links in the horizontal ToC should be black... */
• /* ... except when the ToC box is black ... */
• /* ... or except when being hovered over */
• /* don't display ToC title when in horizontal ToC */

• /* Prevent display of subheadings in horizontal ToC */

I think if you copy all those code section to your common.js there, it should work. Texugo (talk) 21:32, 4 June 2013 (UTC)Reply

I updated the template to add some code to display icons in the top right corner of the banner and the disambiguation hatnote after the banner. You'll need to add the following new section to your Mediawiki:common.css file:

• /* style info for icon box in the top right corner of the banner */

Cheers -Shaundd (talk) 05:22, 7 June 2013 (UTC)Reply

Hi, I'm testing this template in it:voy and I've started a discussion in the lounge. It's my intention to be as much as adherent to your version in order to avoid following rework after each one of your update, so I want to share with you one doubt that has arisen from one user. He stated that the title in the banner is redundant with the title in the top of the page, so we were wondering if it would be a good idea to hide one of the two.

It's clear that the esiest technical approach is to hide the one in the banner, but maybe it could ruin the look of it.

On the other hande, hidden the title of the page (only when a banner exist) it's a little bit complex because it maybe involve other changes (geodata, stars, etc...) but it would provoke a discrepancy between the pages with and without banner.

What do you think? --Andyrom75 (talk) 09:02, 6 June 2013 (UTC)Reply

Well, here we had it where the title of the page was hidden and only the banner title displayed. That functionality recently broke (discussion here and Bugzilla: 49015), so we are working on hiding the page title again. Here on en: the other issues have been resolved - we will be using a bot to put a pagebanner on every page in the main namespace, using default banners for every page that doesn't have a unique banner yet, so that all the pages look the same. The title icons have also been incorporated into the template (see Vancouver) with discussion here. We'll probably have to use a bot to move the geo information from the {{geo}} tag to the pagebanner tag.

Anyway, the central place for discussing this stuff is not here, but at Wikivoyage talk:Banner Expedition, so you might want to read through the discussions there and the expedition page itself for more information. Hope this helps! Texugo (talk) 11:11, 6 June 2013 (UTC)Reply

Thanks a lot for the explanation. I'll go to the other link get more information and to follow/participate on the development. --Andyrom75 (talk) 11:30, 6 June 2013 (UTC)Reply

The template was recently changed to categorize disambiguation pages with "Disambiguation banner.png" as "Has default banner" in place of "Has custom banner". While strictly correct it is not helpful, in that it suggests for maintenance purposes that the disambiguation pages need custom banners, whereas we decided to use a standard banner for all disambiguation pages, as it would be pointless to try to produce meaningful custom banners for them. This complicates the process of filtering the default banner listing when checking for pages which need a custom banner, as now the dab pages also appear. Either the Dab banner can be classed as a custom banner or we need another category for the dab banner to keep things clear. • • • Peter (Southwood) ^(talk): 06:01, 19 September 2013 (UTC)Reply

I have added a switch to categorize dab pages with dab banner as "Has standard banner". This will make the counts easier and clearer. • • • Peter (Southwood) ^(talk): 06:15, 19 September 2013 (UTC)Reply

See Wikivoyage talk:Search Expedition#Questions for an explanation of some recent changes to this template. -- Ryan • (talk) • 21:22, 19 September 2013 (UTC)Reply

What is property P948 and how does checking it impact this template? LtPowers (talk) 15:00, 11 October 2013 (UTC)Reply

It's the Wikidata property for Wikivoyage banner, but I assume you already figured that out from the pub discussion? Texugo (talk) 15:43, 11 October 2013 (UTC)Reply

Yes, apologies for not checking the pub first. But I'm curious how I would identify this fact in the future; a Wikidata search for P948 didn't return any results. LtPowers (talk) 17:18, 11 October 2013 (UTC)Reply

Weird. I think Wikidata is still working out some bugs with their search engine. If you search "Property:P948", it comes up though. Texugo (talk) 17:24, 11 October 2013 (UTC)Reply

Yes, you have to use d:Property:P948. --Rschen7754 18:24, 11 October 2013 (UTC)Reply

The pagebanner on Moscow is currently off; the name and the little quarter-circle in the upper-right are pushed down a space from the top, while the TOC is pushed up a space from the bottom. LtPowers (talk) 02:18, 12 October 2013 (UTC)Reply

This edit is the one causing the problem, but I'm not immediately seeing why it is doing so. -- Ryan • (talk) • 02:56, 12 October 2013 (UTC)Reply

I moved that chunk of code to the category switch instead of the image switch, and fixed a couple of missing pipes in the code and it seems to be working now. Texugo (talk) 19:42, 12 October 2013 (UTC)Reply

I just realized it is possible for a Wikidata item to contain two or more banner files (see wikidata:Q3992 for an example), which I think is a perfect solution instead of different language versions competing and having cross-language discussion about which one to put there. However, it means that the current #property method of automatically displaying a banner (when WD has one and we don't) fails to work properly because it puts both file names in there (example). We need a lua module that will return only the first filename (or second, or third, etc.) listed under that property. I am sure that it is possible but I'm not a lua guy. Anyone know how to do that? Texugo (talk) 22:42, 12 October 2013 (UTC)Reply

It is probably better to use a qualifier to make the distinction, actually. But I personally would prefer having the cross-language discussion, personally. --Rschen7754 00:24, 13 October 2013 (UTC)Reply

What do you mean by "a qualifier"? Texugo (talk) 14:08, 13 October 2013 (UTC)Reply

d:Help:Qualifiers. --Rschen7754 17:13, 13 October 2013 (UTC)Reply

So we need to have a cross-language discussion every time two different languages have different page banners? Why not just let each language use whichever pagebanner they want? LtPowers (talk) 18:12, 14 October 2013 (UTC)Reply

I think the ideal is if one language gets a banner for a destination it is automatically applied to any other language for that destination if they use banners. If a language wants to use a different banner this can be done without need for discussion, and this provides a choice for everyone else.• • • Peter (Southwood) ^(talk): 19:03, 14 October 2013 (UTC)Reply

Swept in from the pub

Why do OtBP and disambiguation have the same icon in this template? --Xiaomingyan (talk) 10:17, 1 September 2013 (UTC)Reply

I've just changed back the edit to Template:Pagebanner that made the icons the same. OtBP and FTT articles now share the same icon - is that right? --Nick ^talk 11:32, 1 September 2013 (UTC)Reply

Well, this page uses the question mark. I'm a little bit confused now. --Xiaomingyan (talk) 13:04, 1 September 2013 (UTC)Reply

I changed the icon at the top of the Previously off the beaten path page to the "tick" icon. That is used for both OtBP and DotM. FTT has a little pen as an icon. Is that correct? --Danapit (talk) 08:22, 1 November 2013 (UTC)Reply

Swept in from the pub

Wikidata now has a Wikivoyage banner property! Now when you create a banner, it will be used in all languages :-)

1) Could someone modify the pagebanner code to take advantage of that? See Andorra for an example of an article that retrieves a lot of its information from Wikidata.

2) Anyone willing to write a one-time script that would add all existing banners to Wikidata? (example)

Cheers! Nicolas1981 (talk) 02:00, 11 October 2013 (UTC)Reply

Oooh! What a pleasant surprise! That will come in very handy! Unfortunately I have no idea how to make this kind of script. Texugo (talk) 02:17, 11 October 2013 (UTC)Reply

I quickly learned how to write bots (surprisingly easy!), and created BannerBot. For now it just sets the property for one object, so what's needed is the list of destinations-banner couples. Nicolas1981 (talk) 08:30, 11 October 2013 (UTC)Reply

I've fixed the pagebanner code; I believe it works, but check to make sure I didn't bork anything up :) --Rschen7754 09:15, 11 October 2013 (UTC)Reply

Two things to consider: 1) I coded it so that whatever is on Wikidata overrides what is on here. Not sure if that is what the community wants, though doing it the other way can be done too. 2) Hopefully different Wikivoyages didn't choose different pictures for the same page. --Rschen7754 09:17, 11 October 2013 (UTC)Reply

Also, the file name in the pagebanner transclusion will be redundant, and you may want to consider running a local script to remove them (but it is optional - just to reduce confusion). --Rschen7754 09:19, 11 October 2013 (UTC)Reply

Thanks a lot Rschen7754! Personally I think the ability to override locally would be appreciated, see this summit discussion with Alexander. Cheers! Nicolas1981 (talk) 09:45, 11 October 2013 (UTC)Reply

Done, though now the parameter will have to be removed to allow the wikidata stuff to show. --Rschen7754 09:56, 11 October 2013 (UTC)Reply

This appears to have broken the banner - the TOC now appears below the banner, rather than overlaid on top. Any ideas why? --Nick ^talk 10:46, 11 October 2013 (UTC)Reply

An extra line break had been inserted in there. Should be fixed now. Incidentally, I agree that we need local override capability. I was also thinking, after running the bot to catch wikidata up to speed, we can put a switch in the pagebanner template which checks for pages with local banners but no banner in Wikidata, and adds them to a Category:Banner missing from Wikidata, so that we can keep it in sync as people add more and more banners. (Note that this would not include future cases where we locally override a banner on wikidata, only cases where wikidata has nothing.) Texugo (talk) 11:54, 11 October 2013 (UTC)Reply

There does appear to be another problem with the way you've changed the template though. Right now the logic says:

a) is there something in {{{1}}}?

if yes, use that

if no,

b) is there a wikidata item?

if yes, use that

if no, use the default banner

The problem is that this only works for pages which have nothing in {{{1}}}, whereas articles outside of europe/n. america all have various other default banners written in {{{1}}}— other default banners are still taking precendence over wikidata but they should not be. The logic needs to be changed so that a) asks "is there something in {{{1}}} other than one of the various default banners?" This will apparently require yet a third long list switch. Or perhaps the overall logic of the whole template needs to be moved around a little. Texugo (talk) 12:27, 11 October 2013 (UTC)Reply

Now done. I was able to trim some redundant code before I made the change, so it wasn't as bad as I had feared. I have an idea for improving the code - let me see if I can get to it within the next hour. --Rschen7754 18:50, 11 October 2013 (UTC)Reply

Eh, I think it's more readable the way it is set up; WOSlinker made another edit to fix things too. --Rschen7754 19:10, 11 October 2013 (UTC)Reply

Looks great. I added a little switch for Category:Banner missing from Wikidata as well, as discussed below. Texugo (talk) 19:44, 11 October 2013 (UTC)Reply

Okay, maybe I'm being obtuse, but...

1. Why do we want every Wikivoyage to use the same banners?
2. What happens if a banner is hosted locally due to copyright issues?

-- LtPowers (talk) 15:05, 11 October 2013 (UTC)Reply

To add, what if a banner has a caption (as do many of the ones I've uploaded)? Will there be a way to provide different captions for each language version? Rastapopulous (talk) 15:31, 11 October 2013 (UTC)Reply

• It's not that we necessarily want every Wikivoyage to use the same banners, but we do want as many pages to have banners as possible — a good, already made and properly sized banner in use on another version is always better than no banner at all, and this is an automatic way to ensure that. With much lower numbers of editors, it would take the other language versions years to create as many banner as en: has in a few months, so there is much interest using the already made good images. And there aren't currently very many pages for which multiple good banner options have been created. If it comes to that, we and other versions always have the choice to override locally.
• If a banner is hosted locally due to copyright issues, it shouldn't be listed on Wikidata.
• Captions do not appear to be stored on Wikidata anyway, so any captions will remain local.

Texugo (talk) 15:40, 11 October 2013 (UTC)Reply

Let me also write it here, explicitly. We need a list of exceptions including generic banners used by each language version (en: has generic banners for different continents, ru: is using generic banners for those destinations where a good custom banner can not be drawn, other projects may have their own quirks). These generic banners should not be copied to Wikidata. Then we need a really smart bot that will remove filenames from the {{pagebanner}} template, but only those filenames that match their counterparts in Wikidata. Nick, are you able to do this? --Alexander (talk) 16:43, 11 October 2013 (UTC)Reply

LtPowers: Creating banners is a severe pain. Finding good images, manipulating them, uploading as a derivative, categorizing... Each banner takes a rather long time, English Wikivoyage is slowing after painfully reaching 20%, and other Wikivoyages have no hope of ever reaching 100% if no collaboration happens.

Texugo: Good points. Any idea how a script could check whether a file is hosted locally due to copyright issues?

Alexander: That would be a different bot, right? I guess I could do it, but I will be travelling soon, back in December, so hopefully other people will step in and start coding :-) Nicolas1981 (talk) 16:53, 11 October 2013 (UTC)Reply

I imagine it could check whether the file is in Category:Files to be kept locally. We don't appear to have any banners in this situation yet. Texugo (talk) 16:58, 11 October 2013 (UTC)Reply

Thanks! I updated the bot request. By the way: Rather than create a bot that would maintain Category:Banner missing from Wikidata, how about just run the initial bot again, every week or so? Nicolas1981 (talk) 17:21, 11 October 2013 (UTC)Reply

Category:Non-free Wikivoyage banners exists; is it used anywhere? And it should probably be a subcat of Category:Files to be kept locally. LtPowers (talk) 17:33, 11 October 2013 (UTC)Reply

Hmmm... I couldn't find any templates that insert that category, but it's not a bad idea, and yes, should be a subcategory of the other..

As for running the bot every week or so, well, if somebody is going to keep track of that and do it regularly without fail, that's fine with me. I'm just afraid those things tend to be forgotten after a while. At any rate, I don't think the category would hurt even if the bot were run every week. At least you could see at a glance whether it needs to be run. Texugo (talk) 18:07, 11 October 2013 (UTC)Reply

If an image is nonfree, should it really be used in a banner? --Rschen7754 18:25, 11 October 2013 (UTC)Reply

Why not? Our policies allow it, as long as the reason it's non-free is limited to depicting an important but copyrighted work of art or architecture. LtPowers (talk) 19:17, 11 October 2013 (UTC)Reply

The problem with that is that it comes very close to violating fair use laws. Since we don't have individual articles on sites, the chances that we would need a non-free image as a banner are fairly small. --Rschen7754 23:57, 11 October 2013 (UTC)Reply

Um, no, not even remotely. It would come very close to violating Wikipedia's non-free-use policy, but we are not Wikipedia. Fair use laws are considerably broader than that, and we're well within our rights to editorially use a photograph of a famous attraction in the area about which we are writing. Travel publications do it literally all the time. LtPowers (talk) 02:12, 12 October 2013 (UTC)Reply

At such a high resolution that is needed for the banner, and for decorative use? This really does not seem like a good idea. --Rschen7754 19:17, 12 October 2013 (UTC)Reply

Resolution is irrelevant. The reason Wikipedia requires non-free images to be low-resolution is because Wikipedia deals frequently in book covers and CD covers and screenshots -- images where someone might be able to use the image to recreate the copyrighted work, or for other fraudulent purposes. For travel photographs of buildings and sculptures, which is the extent of what our non-free-image policy covers, resolution is not an issue, with, perhaps, certain image-specific exceptions. "Decorative use" also fails to adequately describe the use to which we put these images. We choose to present them in a decorative fashion, but that hardly makes them any less educational than the more boringly-presented lead images we have long used. I hate to repeat myself, but we really are not Wikipedia. Wikipedia has their rules, and has good reasons for them; we have different rules, and good reasons for them as well. But since our purposes are different, so must the rules be. LtPowers (talk) 18:36, 14 October 2013 (UTC)Reply

That's great and all, but I don't care about local policy, if it doesn't comply with copyright law in the United States and/or puts the Foundation at the risk of being sued. --Rschen7754 07:24, 15 October 2013 (UTC)Reply

If you think that current policy cannot be justified by the doctrine of fair use for educational or informational purposes, please make your argument at Wikivoyage talk:Non-free content. My belief is that fair use is a principle that's important enough that the Wikimedia Foundation would be and should be willing to fight for it, if necessary, but if you think that banners are somehow different from non-banner thumbnails in terms of fair use, that would be worth discussing. Ikan Kekek (talk) 08:00, 15 October 2013 (UTC)Reply

And continue the discussion on some random page that nobody will notice. Eh, I don't think it would be worth it, since people around here don't seem to want to change any policy, or change anything from the Wikitravel days. In the last few weeks I've considered resigning the admin bit quite a few times for that very reason. --Rschen7754 08:10, 15 October 2013 (UTC)Reply

And continue the discussion on a page where there was already some discussion of the policy. I'm not sure who you're thinking of in your broad-brush remark, but I certainly have no great attachment to existing policies, and I'll observe that it would be quite ironic if you follow up resignations over frustration with Frank (and my apologies to Frank for bringing him into this discussion in order to make a point) by resigning because you seem to agree with Frank's viewpoint about admins (other than you). If you want to change a policy, as I've said to Frank, Tony1, and others, you need to make a clear argument and try to persuade others of its truth. I say that not because I disagree with most of Frank's arguments (rather, I agree with some of them, don't care enough to have a pro or con position on others, and disagree on one or two) or with yours (I'm not a lawyer and haven't seen your argument on this policy in detail), but because you know very well that by giving up and just applying a negative stereotype to (other) admins, you won't be able to achieve anything. So if you really would rather make the argument here, with reference to the existing arguments at the talk page I linked to, rather than at the talk page in question, please go ahead. But I would implore you not to repeat the kind of corrosive statement you just made. I can resign, too, and if I do so in the near future, it would be for another reason: Spending unpaid time here will have stopped being fun, in large part because of just the kind of remark you just made. Ikan Kekek (talk) 08:36, 15 October 2013 (UTC)Reply

I don't think you realize how deflating it is to spend time helping the community here, and have your suggestions that might help this site get along better with editors from other Wikimedia sites spurned repeatedly. Perhaps I was a bit too broad in my remark: my comments certainly don't apply to everyone on this site, and I apologize for that. But what I've seen is a bit too much of circling the wagons whenever new proposals are made, and it seems that moving such discussions off to side pages where only regulars will notice is another thing that seems to happen a lot. Plus plenty of other things that other Wikimedians have complained about to me, and which I've largely overlooked. --Rschen7754 08:47, 15 October 2013 (UTC)Reply

Well, I can't speak for others, but I'd like to read your ideas — and in particular, for the purposes of this discussion, your concerns about the use of images that include copyrighted sculptures, etc. Also, for my part, the reason I suggest having discussions on relevant pages is to maintain order and continuity. I do a lot of patrolling, so I don't have trouble finding discussions wherever they happen. Ikan Kekek (talk) 08:57, 15 October 2013 (UTC)Reply

Yeah, the thing is that I don't do a lot of patrolling using RecentChanges - I keep an eye on things on #cvn-wikivoyage, but it doesn't show edits from trusted users. I've been wanting to write up my thoughts on Wikivoyage, but am still trying to find the time to do so. Oh, and in regards to your comment on Wikimedia defending fair use: that does not seem to be the case (also see Meta). --Rschen7754 09:02, 15 October 2013 (UTC)Reply

(unindent to avoid my interruption being a thin worm one word wide)Sorry to bother you, but what is " #cvn-wikivoyage ", please? --W. Frank^email_talk 12:16, 15 October 2013 (UTC)Reply

Fair use is not mentioned, but I don't think that proves conclusively that the WMF wouldn't want to fight for it, if they felt it was necessary. That said, if Wikivoyage's non-free content policy could expose the WMF to a lawsuit, I think the policy needs to go beyond the policy-discussion level and be referred to WMF Legal for them to rule on. Ikan Kekek (talk) 09:30, 15 October 2013 (UTC)Reply

We should probably have some idea of what the law says before trying to second guess the legal professionals about interpretation.

Does WMF have any existing policy on this? If so, we should take a look at it first, as it may solve the problem. (wishful thinking, I know, but we should at least check).• • • Peter (Southwood) ^(talk): 11:36, 15 October 2013 (UTC)Reply

Okay, another concern: If we offload banners to Wikidata, it becomes nearly impossible to tell when a page on your watchlist has a new banner, or has its banner changed. LtPowers (talk) 02:12, 12 October 2013 (UTC)Reply

Not true. Check "Show Wikidata edits in your watchlist" in preferences. --Rschen7754 19:17, 12 October 2013 (UTC)Reply

Sigh... I have that checkbox checked. The problem is that seeing that an edit has been made to an article's associated Wikidata item doesn't tell me anything about what was changed. It might have been the name of, say, the Esperanto Wikipedia article associated with that item, or the creation of a Wikidata Category associated with that item, or the addition of a translated property to the item, or any number of other things I don't really give a fig about in a Wikivoyage context. And given the scores of Wikidata edits on my watchlist every day, as well as the painfully slow speed of large Wikidata pages, I cannot possibly check the history of each one to see if it's a Wikivoyage-related change or not. LtPowers (talk) 18:36, 14 October 2013 (UTC)Reply

If we can agree that the template should default to the first banner listed, and that any additional banner should be added to the wikidata item rather than replacing the one already there, that would mean that banner changes would have to physically happen here by means of override, and would thus show up on the watchlist as always. Texugo (talk) 20:54, 14 October 2013 (UTC)Reply

The automatic edit summary should explain what was changed. --Rschen7754 00:10, 15 October 2013 (UTC)Reply

The only edit summaries I see on my local watchlist for Wikidata changes all say "Wikidata item changed" and nothing more. Is there something else I should be seeing? LtPowers (talk) 01:15, 15 October 2013 (UTC)Reply

That's odd. User:Lydia Pintscher (WMDE) is that the expected behavior? --Rschen7754 01:42, 15 October 2013 (UTC)Reply

Bot has been approved! Anyone has time to prepare a CSV file containing couples ARTICLE NAME; BANNER FILENAME ? I would use it and start with a hundred of them. By the way, on the English Wikivoyage what are the filename patterns that distinguish generic banners that should not be uploaded? Will I filter them all out with "*default*.*"? Any other pattern? Nicolas1981 (talk) 11:06, 13 October 2013 (UTC)Reply

All the default banners filenames are listed in the code of the template. There are not very many so will list them here too:

Pagebanner default.jpg

Mena-asia_default_banner.jpg

S-amer africa default banner.jpg

Caribbean default banner.jpg

Australia-oceania default banner.jpg

TT Banner.jpg

Generic flying banner.jpg

Default Scuba diving banner.JPG

Itinerary banner.jpg

Welcome banner.jpg

I think that's the lot. • • • Peter (Southwood) ^(talk): 12:02, 13 October 2013 (UTC)Reply

How does this banner property affect the way new custom banners should be added? • • • Peter (Southwood) ^(talk): 12:08, 13 October 2013 (UTC)Reply

Banners should be added to the Wikidata item. --Rschen7754 17:13, 13 October 2013 (UTC)Reply

This is something new, we need a suitably detailed explanation on the project page, which is now presumably inapplicable. • • • Peter (Southwood) ^(talk): 19:17, 13 October 2013 (UTC)Reply

This is overly complicated. It's bad enough we force people to go to another site to upload images, but we also want to force them to go to a third site to put the images into articles? LtPowers (talk) 18:36, 14 October 2013 (UTC)Reply

I think the idea of promoting sharing of data via Wikidata is a good one, and that interfaces for interacting with Wikidata will improve over time and make this easier. For now I would agree that it is burdensome to have to go to Wikidata to add a banner, so at least for the moment it may make sense to have this be a bot task - if a bot finds an English Wikivoyage banner that isn't yet in Wikidata it can add it and update our site accordingly. There are a number of talented bot writers working with Wikidata, so hopefully this would be a proposal we could endorse and one of their bot people could then implement. Would that address the complexity concerns? -- Ryan • (talk) • 18:46, 14 October 2013 (UTC)Reply

Certainly, though there's the still the issue of identifying changes to watchlisted banners, which is being discussed above. LtPowers (talk) 19:19, 14 October 2013 (UTC)Reply

I think that we need to take this slowly. It is a serous issue if banners can be changed without showing up on everybody's watchlist. A spammer could probably change a load of pages to show his advert before it was noticed, because the edits would not show up here or in most watchlists. The complexity will also put people off - banners are complicated enough as it is, and there is no link from our pages to the Wikidata page. I would also suggest that banners are only transferred after they have been in use here for a month, so that it is easy to change a banner shortly after it has been added. AlasdairW (talk) 21:59, 14 October 2013 (UTC)Reply

Well, such a spammer would certainly be noticed on Wikidata, as we have our own patrollers and admins. --Rschen7754 01:41, 15 October 2013 (UTC)Reply

And such a spammer would have to upload their ads to Commons, where they would not last more than a few minutes. I don't think spam will come this way anytime soon. Sincerely, the worst I can see happening is two editors arguing on which banner is the best... by the way, does this kind of banner dispute happen often on the English Wikivoyage? Nicolas1981 (talk) 01:58, 15 October 2013 (UTC)Reply

If the spammer uploaded an explict advert, it would be noticed on commons. But a lot of marketing photos would be accepted on commons - photos of hotels or restaurants for instance. Our policies restrict the use of hotel photos, so the use of a photo of an uninteresting hotel would normally be noticed and reverted. AlasdairW (talk) 21:54, 15 October 2013 (UTC)Reply

One mild three comment discussion on a replacement that was uncontroversial and a deletion of a touty non-compliant banner with strong agreement are the only cases I know of. It certainly is possible for this to be a problem, but there is a procedure for dealing with it at Wikivoyage:Banner_Expedition#Changing a banner. • • • Peter (Southwood) ^(talk): 07:08, 15 October 2013 (UTC)Reply

Is it possible to have a script of some kind similar to the listings editor which would update wikidata when the pagebanner template parameters are edited? This should be something that could later be called from VE if/when it comes to WV. I think VE already has facilities for editing some classes of template, and maybe we could borrow from their coding. • • • Peter (Southwood) ^(talk): 07:26, 15 October 2013 (UTC)Reply

Before answering this question, we need to decide whether we are going to limit wikidata items to having only one banner (in which case it should be hardcoded not to allow more) or whether we will put multiples there (as it currently allows). My proposal is to allow multiples there, so anyone can check there to see what options there are, but have our template here use the first one by default, so that if the banner shown on en: is changed afterward, it has to be changed locally in the override parameter, thus always showing up in recent changes. Texugo (talk) 11:13, 15 October 2013 (UTC)Reply

I see no reason not to allow multiple banners on a Wikidata item. It allows choice to the various languages, and they can all choose which they prefer from the available selection, which will in most cases be one.

It seems like a reasonable idea to have the first banner loaded as the default custom banner, and to require anyone who feels strongly enough to provide a replacement custom banner to make the necessary changes. It is probably not going to happen that often anyway. I am not sure I understand exactly what you are proposing, but it sounds OK. • • • Peter (Southwood) ^(talk): 11:30, 15 October 2013 (UTC)Reply

It will happen now and then. Some banners have been replaced. Ikan Kekek (talk) 11:42, 15 October 2013 (UTC)Reply

Sure, they have, but the point is that if we follow the above, replacement would continue to happen by changing the attribute here in the template itself (where it can show up in our watchlists), rather than by simply replacing what is listed in the property field on wikidata. Texugo (talk) 11:46, 15 October 2013 (UTC)Reply

I got that and liked that proposal. Ikan Kekek (talk) 11:47, 15 October 2013 (UTC)Reply

All non-generic banners from all Wikivoyages are now in Wikidata :-) Nicolas1981 (talk) 04:17, 16 October 2013 (UTC)Reply

Hm. What about all these? Texugo (talk) 11:47, 16 October 2013 (UTC)Reply

These 472 banners have been missed indeed... Thanks for the feedback! Nicolas1981 (talk) 04:23, 17 October 2013 (UTC)Reply

Done :-) Remaining images should be moved to Commons first. Nicolas1981 (talk) 13:31, 17 October 2013 (UTC)Reply

Some are already on commons (Whale Rock, Train travel in NZ, Travel photography, Tracyton), some were deleted as copvios (Stanley and Port Augusta) and some have to stay on WV for FOP reasons (Loop art tour, SF Mission/Bernal Heights) etc. • • • Peter (Southwood) ^(talk): 17:39, 17 October 2013 (UTC)Reply

I took care of most of them. Buffalo/Allentown and the Delaware District still needs to be moved to Commons, and the other three are copyrighted works we'll have to keep here. I'll see about putting a switch so we can keep the category clean. Texugo (talk) 17:56, 17 October 2013 (UTC)Reply

Done. Adding fop=yes to the pagebanner template will take them out of the maintenance category. Now all that is left is that Buffalo article. Texugo (talk) 18:02, 17 October 2013 (UTC)Reply

I was away for some time and missed all this discussion about banners move to wikidata. The idea sounds great, but at the same time I am worried about yet another relatively difficult step within the banner creation. I mean how many editors will be motivated enough going through the whole procedure of finding a picture, editing it, uploading to commons, and finally putting it to wikidata? I also find it is important that we keep the option of having different banners for each project.

Because adding banners has been one of my main activities at WV, I still have some open questions, for which I might have missed the answers above.

• My main concern is how exactly will I find out from the watchlist that a banner was changed and why it happened?
• If an existing custom banner is changed, there should be a discussion or at least reason behind it other than just personal preference. There is no space for such discussion at wikidata, is there?
• How would I lead this discussion with anyone from a different language version?
• Also we have some set of rules (or guidelines) saying what is a good banner and what is not. This might very from one WV to another.
• Is it allowed or not to upload more than 1 banner to wikidata? If so and there are more than 1 banners, how can I implement a second/third/... one? --Danapit (talk) 07:39, 23 October 2013 (UTC)Reply

Hi, Danapit. The proposal, not yet set up, is:

• the first banner is added to wikidata
• the pagebanner template automatically grabs the first banner listed on wikidata unless something is written manually here (override)
• additional banners can be added to wikidata, but beyond the initial banner, subsequent changes to the banner here will be managed by manually writing in the title (override), so that they show up in recent changes.

Texugo (talk) 10:35, 23 October 2013 (UTC)Reply

Texugo, thank you for the explanation. Still it is not clear to me how we can follow a change in the wikidata banner. This will not appear clearly in the watchlist. Danapit (talk) 18:44, 23 October 2013 (UTC)Reply

Well in the proposed scenario, the only way to change from one banner to a different one would be by manually changing it here, as we always have, so of course it would show up in the watchlist. Texugo (talk) 18:49, 23 October 2013 (UTC)Reply

How could we prevent anyone changing the banner at wikidata? We would have no control over that... It is not enough we agree only to add banners in case they are missing, but not changing them. We can agree here for this scenario, but how are the other wikidata users (non-wikivoyagers) to know? Danapit (talk) 18:57, 23 October 2013 (UTC)Reply

Well, Wikidata has patrollers too, who should prevent people from removing banners there. Wikidata does support adding multiple banner entries, and they do remain there in the order they are added. Texugo (talk) 19:38, 23 October 2013 (UTC)Reply

The other option would be to keep doing everything locally, and have the template not display anything by default but only flag articles (put them in a maintenance category) when wikidata has a banner for an article without one here. I might could be convinced to support that too. The problem I see is that doing it that way would eliminate any incentive for ensuring that banners are written to the data items and would require more manual maintenance to keep up with banners added there by other language versions. Texugo (talk) 19:41, 23 October 2013 (UTC)Reply

Wikidata surely has patrollers, but I am not sure if checking if a banner file is exchanged is high on their priority list. I did this edit some days ago replacing an existing banner file by another one (the old one had wrong size) and nobody complained. I would be inclined to support the other option including the maintenance category. Users working on banner expedition could regularly check that one like they do with crop maintenance category. Danapit (talk) 14:24, 24 October 2013 (UTC)Reply

If we can get someone running a bot to periodically check Category:Banner missing from Wikidata and add the banners to WD to collaborate with other language versions, I would be OK with that solution.Texugo (talk) 14:47, 24 October 2013 (UTC)Reply

I would really prefer to set the banners locally and additionally add to wikidata. Would that be a good solution? Danapit (talk) 08:41, 6 November 2013 (UTC)Reply

Ok, is this really better than a default banner: Shimoga? I repeat: we have no control over this! --Danapit (talk) 10:58, 14 November 2013 (UTC)Reply

That is not true. You can go to Wikidata and remove the banner, which I just did. We do have control over this. --Rschen7754 11:01, 14 November 2013 (UTC)Reply

Well, off course you can change it on Wikidata, in case you know something changed. Danapit (talk) 11:05, 14 November 2013 (UTC)Reply

Also it is a little mystery to me where did the file come from. It was added by a bot, but en WV had a default banner, de: doesn't use banners and there are no other language versions, are there? Danapit (talk) 11:10, 14 November 2013 (UTC)Reply

Oh, sorry, it was taken from en WV by the bot. I corrected it back to default banner and being upset that it kept showing the oversized banner from wikidata, I went grumpy. I can however imagine a situation, when wrong sized banner is added to wikidata or banner file exchanged and it remains unnoticed for a long time. Oh well, seems like I have to learn to live with it... Danapit (talk) 11:19, 14 November 2013 (UTC)Reply

I would request to remove the disambiguation icon option from page banner. Template:Otheruses exists for the purpose and this template alone seems more than enough. The icon is looks pretty but its not very useful. --Saqib (talk) 16:29, 18 January 2014 (UTC)Reply

I think the icon was meant to replace that template, but it hasn't been rolled out universally yet. --Nick ^talk 16:39, 18 January 2014 (UTC)Reply

Hi Nick, I would suggest to illustrate the page banner with icons (DotM, Ftt, OtBP and UNESCO) which shows the value and significance of an article. Hope you'll understand what I'm trying to convey in my HINGLISH. --Saqib (talk) 16:53, 18 January 2014 (UTC)Reply

I would agree. All the other icons signify something directly related to the article. The disambig icon doesn't go along with this theme, so could probably go, especially since there is also the same link in the line below the banner anyway. -- WOSlinker (talk) 12:34, 22 January 2014 (UTC)Reply

Any opposition ? --Saqib (talk) 13:09, 31 January 2014 (UTC)Reply

Swept in from the pub

Every time here gives me a so bad experience that my will to participate became negative, now I'm have to say to my friends, "do not edit there, it's a waste of time".

Simple editions that could highly improve the community are not allow, if you don't spend tons of hours, that I don't have, discussing the "egg hair"... 2 years in the Wikimedia Movement and do not adopted the "be bold, don't be idiot".

Why that? Why that much of bureaucracy instead encourage volunteers to contribute? Rodrigo Tetsuo Argenton ^m 20:52, 2 January 2015 (UTC)Reply

A cursory inspection of your reverted edits today seems to indicate that you are just upset because you don't get to do what you want, regardless of standards that were developed through many discussions over the years. Since you know how Wikis work, you're surely aware that if you're unwilling to see your edits subjected to all kinds of revisions and sometimes reverted, and especially if you want to do things like create pagebanners that are much larger than the standard size, you need to start your own blog instead of complaining that this entire site is not your sandbox. Happy trails, and have a great 2015! Ikan Kekek (talk) 21:05, 2 January 2015 (UTC)Reply

Rodrigo Tetsuo Argenton, I guess you are referrring to your edits to the pagebanner template, which User:PerryPlanet reverted. I admit I do not understand very well how templates work. Nevertheless, the pagebanner is something visible on pretty much each and every article. Edits to a central page like that will have consequences for practically the whole Wikivoyage instantly, therefore anyone should realize such edits should be discussed before they are implemented. Besides, edit warring is definitely not making matters any better. ϒpsilon (talk) 21:16, 2 January 2015 (UTC)Reply

w:WP:DIVA, folks. -- AndreCarrotflower (talk) 21:33, 2 January 2015 (UTC)Reply

Let's be nice and assume good faith, barring any evidence to the contrary. In this case, the page banner edit was well-intentioned, but I very much agree with Perry's concern about an undiscussed change to a template that appears on basically every page on the site, and I suspect that a similar edit on Wikipedia would probably be reverted as well. While a max height makes sense for the specific article and image that Rodrigo Tetsuo Argenton was attempting to add, we've had all sorts of troubles with large page banners creating problems for mobile and elsewhere, so I'm inclined to support the current policy of forcing properly-sized banners, rather than using a CSS hack to be more permissive with banner dimensions. -- Ryan • (talk) • 21:41, 2 January 2015 (UTC)Reply

Ad hominem and disrespect that I will not enter on that...

And a q.e.d.... yep the whole Wikivoyage instantly will be affected... but, this don't change any present edition, this affects future editions, and this allow new things so, q.e.d., you created barriers and do not allow small changes that could improve the community... ant that's the point here, not the edition. Ryan, the banner have a "no mobile", they don't appear in mobiles.

I'm not talking about the small picture, I'm talking about the whole thing... as you entered in the example, the pt community is haunted by a en volunteer that don't allow beaches articles, but, as the majority of occasional volunteers are Brazilians, and beaches are important for us, I saw a lot of this type of articles being deleted with no discussion, and the argument is "the community [this one here], do not allow that type of article", I tried to solve, showing alternatives and nothing. And he won, I don't have time to enter on more hours of this.

And this happens every time and time, "this article is to print", "we do not allow galleries" "we do not allow videos" "we do not allow montages" "we do not allow...", we already have tons of tech solutions for all this, "noprint", i.e., and yet, you tried to stop in time and be the 2005 WikiTravel...

You are free and have a real support, and we are in 2015, we have tablets, internet, people can select what they want to print and we can create books for than with to buttons....

Dogmas will not improve the community "Let it go!", be bold, spread your wings, if something do not worked after use, revert, but try, let happen... Rodrigo Tetsuo Argenton ^m 21:45, 2 January 2015 (UTC)Reply

It would help if you could explain the purpose of your bold changes. For instance, doesn't setting the maximum height of the banner to 250px reduce the height of all of the banners on the site? And how does that provision interact with an image such as you posted on Manhattan/Midtown East? What's the practical effect of these changes? Powers ^(talk) 21:59, 2 January 2015 (UTC)Reply

(edit conflict) Your comment about banners not appearing on mobile devices is inaccurate and also conflicts with work going on elsewhere (see [1] for one example), and thus supports the point that when there is concern about a change to an important template it should be discussed to avoid unintended consequences. With that said, I'm sympathetic to many of your points and agree that the culture here is too restrictive, but also feel that your comments indicate an unwillingness to go along with existing consensus when you disagree with it. Existing Wikivoyage editors should very much work harder to be more accepting of new ideas, but you also need to respect the fact that many of the guidelines currently in place are the result of difficult compromises made by a large editing community. -- Ryan • (talk) • 22:03, 2 January 2015 (UTC)Reply

Edit conflict (four times already) Ryan look this File:Wikivoyage banner versions.jpg on mobile versions, now I saw that your version is present in mobiles, in the pt version no. But, you can compare the difference between the 7:1 and the CSS "cheating".

For me is to tough to see in the actual version...Rodrigo Tetsuo Argenton ^m 22:17, 2 January 2015 (UTC)Reply

Powers a lot of image you can put there will work without editing, and create a new image 7:1, I can simply choose one that looks good with the cut, and that's it. See: pt:Nova York. The ones that are in 7:1 are not affected. Rodrigo Tetsuo Argenton ^m 22:17, 2 January 2015 (UTC)Reply

Yeah Ryan, I get the respect part, but I rise up the pt version alone, helped to raise this one and the es, made a lot of importations, adjusts, recovered files... and after ready you started to be very aggressive with me, never if respect, and just because I was questioning some things... respect need to be mutual ;)

I didn't get how this affect the discussion about mobile, but this is not the point that I'm raising, the bureaucracy is what's bothering me, if some one have a real argument as "we could not change that, because of that", I respect, but reversion for free... Rodrigo Tetsuo Argenton ^m 22:17, 2 January 2015 (UTC)Reply

I looked at pt:Nova York, and the image's aspect ratio changes dynamically based on the window width. It would only be 7:1 at one specific window width, I think. It seems like our other banners would be affected similarly, with the bottom getting progressively cropped out once the image width exceeded 1750 (your coded maximum height of 250 times the 7:1 ratio our banners follow).

Anyway, one thing you should understand is that on Wikipedia, the template you edited would likely be protected from editing because of the high potential for damage and vandalism. They even have a template for that: w:Template:High-use. We don't protect high-use templates like that; instead we revert if the changes are wide-ranging and undiscussed beforehand. Is that really a less welcoming move than simply using page protection?

-- Powers ^(talk) 23:40, 2 January 2015 (UTC)Reply

I think we should all drop our personal prejudice and abstain from off-tangential discussions, focusing instead on answering the poignant original question: "How free do you are?" PrinceGloria (talk) 23:48, 2 January 2015 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Thank you PrinceGloria, this is not about the template, if you want move your concerns to the template page that I can respond there.
You are not Wikipedia, the volume of editions and access is not comparable, wp wy, you don't need this level of bureaucracy, you can track every step, and not many people will be affected if something goes wrong.
And even WP are more free than here when we are talking about edition, if I want I can put more images, write in a different flow, {{eat}} {{do}} {{learn}}, and learn could not be "visit this neighbourhood, to see this type of architecture", because this is not learn this is see(?), but I could not put in see, because we already have too much "see". For big cities I can't create a gastronomic guide, even having people that just travel for that, for beach cities I can't create a guide with all beaches, I need to squeeze all beaches in see, and I can't put photos, and not much information, because don't fit... I can't create a article Musée du Louvre to give tips to travellers more valued than just the price, hours... Today I can't put info how to get there, a map, photos of arts there... and you can say to me, in this case "they have a website", first, I need to stop my reading here to go there, and second the have 3 languages, France, English, and Japanese... and for some reason, pt e other smaller wy, suffer a huge influence of here, informations about some monuments is totally ridiculous to find in some languages...
I need to restrict my share potential, because you don't allow more information, I truly understand that in a trip you need to see the top 5 monuments, top 10 restaurants... and we need to be concise, but a lot of people want to see alternatives, some people live there and want to discover new places. I live in a huge city, I don't know 1/10 of the places available, even I taking my camera and visit new places at least one time in the month. We can simply create a "appendix" in the "Eat" section with a food guide, with a lot types of food, restaurants, same with beaches, museums, galleries... and the main article will be with more 5 lines indicating this appendixes, and will not affect the tourist, but can put a gigantic smile in some travellers...
Look how many monuments the Wiki Loves Monument bring every year, and how many people are involved on that, picture a married if that, if will could list this here, saying how to hit that spot, giving tips of the surround, and maybe linking a QR Code in the monument to a appendix here, that bring more of the same... And now you have a server for that, and have a community with a new breath to make this happen, but you need to be more flexible, all this things at the end that I described we can make happen this year.
So you don't need to block, you need to be more open, what's the difference between ratios, the other to right, quantity of lines... spread your wings. Rodrigo Tetsuo Argenton ^m 01:09, 3 January 2015 (UTC)Reply

As on any wiki, it's perfectly possible to change Wikivoyage's policies, but only if users go through the proper procedure to do so. That procedure consists of initiating a discussion on the matter on the relevant project talk page and/or rfc and/or in the pub, gathering consensus, and - if consensus is agreeable - initiating the desired changes. A problem that this project has been seeing more and more often is users trying to bypass the official channels and either proposing huge, sweeping changes to policy in totally inappropriate venues or, as Rodrigo Tetsuo Argenton has been doing, making such changes unilaterally and then getting angry when they're reverted.

I totally get that changing policy in the prescribed way is a pain in the neck and the process oftentimes moves at a glacial pace. And I am totally sympathetic to folks who are frustrated with what a tedious undertaking it is to hammer out consensus. If what PrinceGloria is suggesting is that we make some sort of effort to streamline the process of gathering consensus and implementing policy, or to encourage input from a wider slice of the community when policy issues come up, or to establish some guidelines for the scope of policy discussions so that they don't get derailed by folks going off on a thousand different tangents - then you can mark me down as an enthusiastic supporter. But even if nothing changes, I still prefer the status quo a thousand times over rather than some sort of Wild West scenario where anyone can make any major sitewide change he wants at anytime, without consultation. And regardless of any other factor, the petulant attitude displayed by Mr. Argenton on this thread and elsewhere (e.g.) are never called for in any circumstance. Wikivoyage is a wiki that provides itself on maintaining a civil atmosphere and we have actually userbanned editors for consistent patterns of uncivil behavior, which I mention not as a veiled threat but to underscore the importance we place on this.

-- AndreCarrotflower (talk) 01:43, 3 January 2015 (UTC)Reply

"status quo a thousand times" = dogma...

" the petulant attitude displayed by Mr. Argenton" ≠ maintaining a civil atmosphere

"userbanned editors for consistent patterns of uncivil behavior..." = open threat (not a veiled one) ≠ maintaining a civil atmosphere

A interesting thing in this "ban", the name of the same person that do not allow any kind of change in pt.wy pops up... And the people that are being "rude" (I'm not gonna use what I'm thinking) here, are the people who hunted the person banned and creating a not civilized environment in this discussion, maybe the problem is in another side...

"or to establish some guidelines for the scope of policy discussions so that they don't get derailed by folks going off on a thousand different tangents" = The issue

I can hear you screaming "this is not WikiTravel, ops, Wikivoyage!" when you was reading my thoughts, and possibilities to here. You don't need more guidelines, or rub in the face of a volunteer the "scope" that were created in 2003, we all get.

But why not improve things, why you cannot rethink as you have more power to use, more technology to burn, to provide more options, more information, to receive more knowledge, to bring more volunteers...

Why do not thing out of the your giant iron box...

This is not working for the pt community, and I bet my kidney that it is slowing down the en...

I'm not gonna get deeper, because you keep trying to punch me, not the issue. So I can't see a point to keep discussing with you. Rodrigo Tetsuo Argenton ^m 03:18, 3 January 2015 (UTC)Reply

Regardless of any merits the argument in the second half of your post may have regarding the scope of policy discussions, the first half makes it abundantly clear that you're not interested in contributing to Wikivoyage in a constructive and collegial manner. Again, if you can't handle cooperating with the community, you're more than welcome to leave as you promised to do. Happy trails! -- AndreCarrotflower (talk) 03:29, 3 January 2015 (UTC)Reply

Again, q.e.d., "you keep trying to punch me, not the issue.", nothing more to say to you. And any one can read the thing that you wrote to me ;)... Rodrigo Tetsuo Argenton ^m 03:35, 3 January 2015 (UTC)Reply

PS:Ad hominem and creating a hostile environment to stop the conversation, don't make you write...

Happy New Year all. Not the best conversation in which to start a new year, but I'll go ahead and put it out there that I am the "en member who haunts pt". I have been round and round and round with this user many times on various topics, which in pretty much every case has involved him ignoring or denying the legitimacy of existing policy/practice and insisting on making unilateral changes, on everything from montages to banners to attraction/beach articles to the use of hot pink text. Pt is pretty much in maintenance mode and does not have any regular users besides myself with which to build any consensus behind his desired changes, but obviously that doesn't mean that he therefore gets to have the site as his personal "sandbox", which is what he has always appeared to feel entitled to. When I reverted his changes, it inevitably led to interminable conversations in which he often resorted to very nasty personal attacks, including lodging inappropriate formal allegations against me at meta (which failed of course). After some point maybe a year ago he stopped editing, and so all of that was buried long ago. I hope not to have to dig it all up again, but I will if I have to.

Anyway, I cannot say I am pleased to see this user back again with the same diva behavior, and I will go ahead and announce here that on pt:, his unilateral changes will be patrolled and reverted exactly as they would be here on en:. He will be referred here to en: for any new proposals to gain consensus, because I do not intend to allow the absence of discussion participants there to be used as an excuse for him to redesign the whole site to his liking, and because I do not appreciate the stress I felt from trying to hold him back one-on-one the last time around. Already wasted much time on this guy. Texugo (talk) 04:10, 3 January 2015 (UTC)Reply

Ad hominem again! That's awesome!!!

As it's me subject again: this what I was doing the whole day, even with years in WT/WY as he proud says, never fixed one of the most accessed pages, and I spend the whole day fixing problems, improving the page, in 3 min he f up all the work, just because he doesn't like.

[2], [3] the last one is incredible, he wrote "restore map wikivoyage style - which would justify taking one WV map and put other non-WV?", and that's so absurd that I can even say anything. I change one map that no one could read for one that even me, can see... and this is not a WY map, dogmatic to the roots...

Again I don't need to prove my point, it's pop up during discussion. The same crew hunting another guy that change one thing, and they create a non-healthy environment and change the angle to the lonely guy...

You know what's gonna happen? The NY page will be stay the s that is now, and the Paris, Tokyo, and London (cities planned to be fix, in my holiday). As pt:Oslo, pt:Florianópolis, instead of helping, the volunteers withdraw my contributions, no matter if it was better than before just to maintain the things the way that they like... in most cases in pt, empty...

And the possibility to this happens is your fault...

Old guys can implement anything without any kind of discussion (as the banner, buttons...), write rules that was not present before [4], [5], [6], [7], [8],..., and the "new" ones need to pass through the whole bureaucracy, this is not a free space, we have a name for that. Rodrigo Tetsuo Argenton ^m 04:52, 3 January 2015 (UTC)Reply

I think it's best that we not continue to give this user the attention he clearly craves. Let's move on. -- AndreCarrotflower (talk) 04:57, 3 January 2015 (UTC)Reply

You might like to know that with Firefox 37.0.2 under Mac OS X 10.9.5 no menus are shown in the pagebanner template. It only works in Safari.--Aschmidt (talk) 22:24, 27 April 2015 (UTC)Reply

Works for me in Firefox 41, Mac OS X 10.10.3. Kaldari (talk) 00:33, 30 September 2015 (UTC)Reply

Hi, I heard about mw:Extension:WikidataPageBanner which adds a PAGEBANNER parser tag. I came to en.wikivoyage.org to learn about it and wound up on this template.

I think it's worth explaining the difference, {{pagebanner|imagename.jpg|...}} versus {{pagebanner:imagename.jpg|...}} is pretty subtle. -- SPage (WMF) (talk) 08:50, 31 August 2015 (UTC)Reply

Special:Diff/2846324/2848009 has been added to note that the preferred usage is to invoke the template rather than directly invoking the extension. Feel free to make any additional edits if you think further clarification is needed. -- Ryan • (talk) • 14:38, 31 August 2015 (UTC)Reply

Currently, when you hover over a menu item in the pagebanner, it underlines the menu item, but also underlines the bullet that separates the menu items. This looks sloppy as the bullet is not part of the menu item (or shouldn't be). Is there a way we can keep it from being underlined as well? Kaldari (talk) 00:37, 30 September 2015 (UTC)Reply

The bullet was originally added to the list element, rather than the link, and behaved as desired. However, a change to the banner extension broke things badly and the CSS was moved to the link as a quick fix. I've had it on my TODO list to revisit, but it seemed like a minor issue so it wasn't a priority. If you or anyone else wants to attempt a fix please do so. -- Ryan • (talk) • 04:21, 30 September 2015 (UTC)Reply

Swept in from the pub

So do we give up on the new Pagebanner syntax. Would be a shame to lose the drop-down of sub-sections but maybe it is the price to pay for not having the contents section keep randomly appearing on pages. --Traveler100 (talk) 06:58, 13 March 2016 (UTC)Reply

Anyone working with the Pagebanner reading this? (I've already got so used to the problem being there that I seldom notice it any longer) ϒpsilon (talk) 19:24, 15 March 2016 (UTC)Reply

On it:voy I haven't implemented the extension but I've add some code in the templates. Basically the benefit of the extension are two:

1. fixed mobile visualization: already implemented
2. drop down menu: on this topic I'm half way.

Unfortunately my real job has reduced dramatically my available time for voy, but if someone would like to support me on the finalization of this coding, we could rid off this extension with all the relevant bugs that time by time occurs here on en:voy. I'll be more than glad to explain where I've arrived and what is still missing. PS In case ping me on it:voy. --Andyrom75 (talk) 18:45, 5 April 2016 (UTC)Reply

Andyrom75, that sounds promising. I don't think that my coding skills will be sufficient to contribute (and I don't have much time either), but on a longer run this may be a good solution.

In the meantime, I can only ping @Jdlrobson: The Pagebanner extension does not work properly, and we need a developer who can fix it. --Alexander (talk) 20:57, 5 April 2016 (UTC)Reply

Hi. First I've heard of this. What issue are you seeing? Is there a phabricator task open? The best way to reach developers is to write a task or poke us on existing tasks there (watching every single projects Village pump sadly doesn't scale) - we're pretty respondent there I promise! What does "price to pay for not having the contents section keep randomly appearing on pages." mean? The only table of contents related bug I've seen was big caching issue that hit the entire cluster (and was unrelated to WikidataPageBanner) and got fixed Tue, Mar 8. In practice, many less frequently edited pages would have still been impacted by that bug up to April 8th due to the 30 day cache window in place. If you're still seeing issues that sound familiar to that, there may be something else going on that I'll happily personally look into for you. Jdlrobson (talk) 22:55, 5 April 2016 (UTC)Reply

Unless I'm mistaken the issue is phabricator:T121135 (TOC appears in the article instead of the banner) which has been ongoing for several months. -- Ryan • (talk) • 23:00, 5 April 2016 (UTC)Reply

I see the problem moderately often. Lapu-Lapu is a current example. Pashley (talk) 04:42, 6 April 2016 (UTC)Reply

I will be deploying a fix within the next hour that will hopefully resolve this. I may need to touch the pagebanner template to verify. Will update you soon! Jdlrobson (talk) 15:10, 13 April 2016 (UTC)Reply

It seems simply editing the template with a null edit or purging doesn't propagate to the pages that use it. Could someone edit the template to include a comment e.g.

<!-- cacheversion 1-->

and let me know when that's been done? Ping Ryan. Make sure this is in the output HTML - this will also help us with future debugging if people update it :) Jdlrobson (talk)

I've made the requested edit, but I'm not sure you will see it in source - doesn't MediaWiki strip HTML comments from the generated HTML output? -- Ryan • (talk) • 16:07, 13 April 2016 (UTC)Reply

Yes you are right. HTML comments are stripped so that's no good. That said if you view the source of a page impacts by the table of contents bug e.g. Monmouth_(Oregon) you'll see "Cached time: 20160328210714" - a time before this fix went live - it seems editing a template is not enough to force a re-render of pages that use that template. We may need to manually purge any troublesome articles and wait 30 days for this problem to fully go away. We could ask the Wikimedia operations to do a cache flush but I'm not sure this is advisable or allowed given the non-unbreak now nature of this problem. :/ Jdlrobson (talk) 16:14, 13 April 2016 (UTC)Reply

Editing the template will force pages using that template to update in the cache, but unless things have changed it's done via a work queue so it takes a while for all pages to be updated, depending on server load and current queue size. -- Ryan • (talk) • 16:22, 13 April 2016 (UTC)Reply

Seems like you are right. Yay I learnt something! Looks like the issue has disappeared from Wikivoyage. After hitting random several times I have not hit a single page with the issue. Can you confirm you see the same? Jdlrobson (talk) 16:40, 13 April 2016 (UTC)Reply

First, thanks for your efforts in trying to solve this issue. Note, however, that forcing a cache purge by editing Template:Pagebanner has been our workaround for the issue over the past several months - doing so always "fixes" the articles for a few days, but then in-article TOCs start building up again. I think we'll need to wait a couple of weeks to see if the issue occurs again before it will be safe to declare that the latest code change fully resolves the issue. -- Ryan • (talk) • 16:49, 13 April 2016 (UTC)Reply

It seems like the changes User:Jdlrobson made may have fixed this issue - I haven't seen the problem re-occur in the two weeks since his change went live. If anyone else comes across an in-article TOC please add a comment with a link to the article on phabricator:T121135. Many, many thanks to Jdlrobson for tracking down a difficult problem. -- Ryan • (talk) • 17:42, 28 April 2016 (UTC)Reply

Hello. I want use this template on Azerbaijani Wikivoyage project. How I can do that? --Aabdullayev851 (talk) 11:05, 6 August 2016 (UTC)Reply

The template makes use of mw:Extension:WikidataPageBanner, which will need to be installed in order to make the banners work as expected. -- Ryan • (talk) • 15:18, 6 August 2016 (UTC)Reply

Over the last week several banners have been added that have the wrong proportions. Is it somehow possible to change the pagebanner template so that it checks if the pagebanner image has the right size and proportions, and if it hasn't, automatically adds the crop tag under the banner (just like when you add a banner to a user page, the blue "This is a Wikivoyage user page." box turns up). In this way the person who has added the banner immediately gets to know that something is not right. ϒpsilon (talk) 18:53, 28 August 2016 (UTC)Reply

Swept in from the pub

So there have been a bunch of edits to some articles in Germany of this pattern? What is that for, what does that do? Hobbitschuster (talk) 11:20, 9 July 2017 (UTC)Reply

Hi Hobbitschuster, on small screens (i.e. smartphone displays) you cannot show the whole banner picture. So those 2 values define the center of the picture in case the website is opened from smartphones. Better described here (Focal area of the image). I sometimes needed many trials since I did those edits from my phone. Not sure whether the smaller display can be simulated on a desktop somehow. --Renek78 (talk) 11:37, 9 July 2017 (UTC)Reply

Okay, that makes sense. Thanks. Everything that makes our site look better on mobile is good. Hobbitschuster (talk) 11:38, 9 July 2017 (UTC)Reply

Doesn't the script use window size? That is the relevant quantity anyhow, and then simulating the smaller display size can be done by merely resizing the window (unless desktop is treated in an other way regardless of the display). --LPfi (talk) 16:58, 10 July 2017 (UTC)Reply

Per accessibility conventions, we should add alternative text to these images. —Justin (koavf)❤T☮C☺M☯ 05:50, 8 September 2017 (UTC)Reply

does the caption parameter address this? Also is there an easy way to test how the alt looks without images on the page? --Traveler100 (talk) 12:14, 8 September 2017 (UTC)Reply

@Traveler100: Captions and alt text should serve two different purposes: a caption should augment a photo (so you see it, and the words give context) whereas alt text should substitute for an image (e.g. you are blind and this says what you would have been seeing). There can be a lot of overlap but they should be distinct. —Justin (koavf)❤T☮C☺M☯ 16:41, 15 September 2017 (UTC)Reply

That explanation makes sense, I would support adding the alt parameter to the template. Although I was involved in the initial definition of this it has developed past my coding knowledge. Before we can update the template on Wikivoyage I think the MediaWiki Extension has to be updated. --Traveler100 (talk) 18:13, 15 September 2017 (UTC)Reply

The images are only used on the maps though. How useful are the maps when you are blind? -- WOSlinker (talk) 18:36, 16 September 2017 (UTC)Reply

@WOSlinker: Altho the primary purpose of alt text is for the blind, it's not the only one. —Justin (koavf)❤T☮C☺M☯ 05:08, 20 September 2017 (UTC)Reply

This template is for page banners. What do you mean about maps? Powers ^(talk) 02:25, 17 September 2017 (UTC)Reply

Sorry, I was thinking of the listings. -- WOSlinker (talk) 15:09, 18 September 2017 (UTC)Reply

The pagebanner on enVoy doesn't make proper use of larger screens. My 15.6" screen is displaying the banner perfectly fine, with the banner using up all available width, while on my 27" screen, the banner doesn't (screenshot). Both screens have the same resolution. I've noticed that other Wikivoyages do not have this problem (nlVoy, esVoy, ptVoy, ruVoy, itVoy, etc.), and I myself can't find the problem in the source wikitext for the pagebanner. Can someone perhaps look into this, or is this issue already known to begin with?
-- Wauteurz (talk) 18:20, 20 December 2017 (UTC)Reply

zoom the scale on the one on the left. Reading a web page of text when line length that is more than 20 words is not a good idea. Eye tracking back to start of the next line is more difficult.--Traveler100 (talk) 21:03, 20 December 2017 (UTC)Reply

@Traveler100: My left monitor is scaled to have text at roughly the same size for webpages, which I find to be easier on my eyes. Apparently I've grown custom to the scaling to where I didn't think of that being the issue. I guess page scaling is more down to personal preference any way. Thanks for pointing it out though :)

Either way; I didn't realise that Chrome was scaled down by 10%, so I guess that solves that issue. I, however, noticed that as the page scales down, the banner dimension gets warped (flattened). If possible, I'd like to see the 7:1 dimension be fixed into the pagebanner, but (except for larger screens, I guess) that isn't an urgent issue per se.
-- Wauteurz (talk) 20:19, 21 December 2017 (UTC)Reply

Maybe it is a chrome thing. I switch between different screens, using Firefox, not seeing that. Sometimes Windows 10 HD screen scaling does odd things across multiple screens but within one no issues. Also do not have my browser on full screen when using more than 1680 pixel screens. --Traveler100 (talk) 20:34, 21 December 2017 (UTC)Reply

Swept in from the pub

I've been trying to do this for the poor-quality banner images for speedway and Ohlone Trail, which I added myself a while ago, but now I can't change them back to the default. How is this done? Selfie City (talk) 21:20, 6 August 2018 (UTC)Reply

You'd have to remove the "wikivoyage banner" on the associated Wikidata item, in addition to putting the default image in the template here. K7L (talk) 22:27, 6 August 2018 (UTC)Reply

I think the assumption is that any banner is better than the default... However, I'm not sure I agree... Hobbitschuster (talk) 22:36, 6 August 2018 (UTC)Reply

Interestingly, the speedway one is working now. And generally yes, I would say any banner, but these images were very poor quality. Selfie City (talk) 00:07, 7 August 2018 (UTC)Reply

Thanks to K7L's explanation, I've got the other one working now as well. Thanks, both of you, for your assistance on this issue; it's really been a help. Selfie City (talk) 00:11, 7 August 2018 (UTC)Reply

Swept in from the pub

Why are we farming out more and more of our banners to Wikidata? Some reasons in support of keeping the information locally are:

1. It would make changing banners easier and quicker; edits made on Wikidata can take anything from a few minutes to several hours to become visible on Wikivoyage, leaving you uncertain as to whether the edit was successful.
2. In the time lapse described above, a Wikidata user could have reverted your change, with good reason: it's not their job to understand or cater to the needs of our wiki.
3. The longer editing process and delay described above are unnecessarily confusing, especially to newer users. This goes against our general tendency to keep things simple: minimal use of templates and images, no photo montages, a relatively restrained bureaucracy, etc. Furthermore, you shouldn't have to know how to use a completely different wiki in order to effectively edit Wikivoyage.
4. As far as I know, no other wiki uses pagebanners (the other Wikivoyages excepted, but not even all of them do). So hosting banners centrally does not benefit other projects
5. Keeping banners in Wikivoyage also means that the different language versions can more easily use different banners for their version of an article, as decided by that wiki's community (the Hebrew Wikivoyage seem to like to do their own thing in this regard).
6. If Wikidata policies towards the banners they host were to change, we might lose control of them completely.

Any thoughts? --ThunderingTyphoons! (talk) 13:15, 17 August 2018 (UTC)Reply

I see no reason not to put the banner image name on Wikidata but I always enter it explicitly on English Wikivoyage. Are you saying that the file name is being removed from Wikivoyage pages or is it just the case that there is one on Wikidata due to a different language user entering it there? --Traveler100 (talk) 13:34, 17 August 2018 (UTC)Reply

As far as I know, no file names have been removed from WV. Nonetheless, putting the name on Wikidata (whoever does it) results in all of the problems described above. Having the name on Wikivoyage doesn't override what's on Wikidata; in fact it's the opposite. --ThunderingTyphoons! (talk) 13:36, 17 August 2018 (UTC)Reply

That sounds not preferable. How would a user on wikidata know the style requirements (7:1 and at least 2100 x 300 pixels) here on wikivoyage unless they specifically went looking for them? DethDestroyerOfWords (talk) 13:45, 17 August 2018 (UTC)Reply

Exactly, in fact that is why I decided to post this here, after removing a badly-proportioned banner from Shillong which had been posted to Wikidata. --ThunderingTyphoons! (talk) 13:49, 17 August 2018 (UTC)Reply

As far as I know entering a banner image name on the Wikivoyage page overwrites the Wikidata setting. And this should definitely stay. --Traveler100 (talk) 14:04, 17 August 2018 (UTC)Reply

Yeah, actually, it's not quite as bad as I thought. We can, in fact, change between custom banners locally without changing what's on Wikidata. However, if you try to use the Default Pagebanner, as I have done at London, the banner listed on Wikidata remains visible. --ThunderingTyphoons! (talk) 14:07, 17 August 2018 (UTC)Reply

I'm sorry for wasting people's time on an issue which is far smaller than I first realised; most of the problems listed above are not actually an issue, except in the case of wrongly-formatted banners being added to Wikidata, and there is no alternative available so we want to use the default. --ThunderingTyphoons! (talk) 14:18, 17 August 2018 (UTC)Reply

Don't be sorry. These issues crop up any time we allow a Wikivoyage article to be dependent on anything hosted on some other wiki - whether it be Commons or Wikidata. We might find a great image, use it in an article somewhere, then have it randomly disappear - with the only notification to us that it was nominated for deletion on Commons being a User:CommonsDelinker bot removing the image: link from the article after it's too late and the image is already gone. WV.de tried a version of the {{listing}} template which could populate the fields from a Wikidata listing; they found that the {{vCard}} was breaking when Wikidata admins mistook the records as "not in use" and deleted a few. We're also open to the same issues if we allow {{mapshape}}s to be hosted on Commons; there was an incident a while back where Commons users were accusing us of being liars and worse because some of our content "shared" there contained (lat,long) co-ordinates which looked to be derived from OpenStreetMap, an open source which needs to be reusable. And then there's the whole question of whether content spread across two or three wikis is more difficult for new users to maintain, as the structure is less understandable than one where everything's held locally on the one wiki. All of this is nothing new and it's all been discussed before. K7L (talk) 14:52, 17 August 2018 (UTC)Reply

Just a few notes....

1. "edits made on Wikidata can take anything from a few minutes to several hours to become visible on Wikivoyage". Untrue - the data are used right after you regenerate the wikipage.
2. "it was nominated for deletion on Commons" ... what's the usual reason? I'd say copyright issues or similar? In such case, you cannot just copy it to WV and pronounce it OK. Copyright applies also here.
3. "We're also open to the same issues if we allow {{mapshape}}s to be hosted on Commons". Again, rather than copying suspicious stuff to WV, you should rather explain the source and license of the data at W-commons?

Andree.sk (talk) 20:12, 17 August 2018 (UTC)Reply

1. The purge function is hardly general knowledge, especially not if we speak about new editors. I suppose new editors need not change banners, but it is awkward anyway.
2. I suppose the problem is mostly with some admins at Commons, who are quite trigger happy. They might delete a file because the permissions were stated (or evidence provided) in a way they are not used to, or other formalia. Or they think a file is not in scope (although files used over here are per definition in scope). You can usually get the file restored through an undeletion request, but you have to note the deletion and know the processes.
3. The case hinted at had no copyright problems, but the deleting admin did not trust the uploader about the copyright status. It is quite frustrating that a file that has been on Commons for weeks (or years) can be deleted after five days with only a message at the file and the user talk page when an admin thinks there is not enough evidence. If you do not check the pages (or your e-mail, if you have it notify you) every few days, you'll likely just find the file gone.

I think Commons does a splendid job most of the time (Swedish Wikipedia does not have local files, because we trust Commons to do it better than we could). Still, loosing a file or having to fight for its restoration is unpleasant to say the least, even if one has to deal with it only a few times a year.

--LPfi (talk) 20:36, 17 August 2018 (UTC)Reply

For the pagename text, there is a darkened section of each banner in the top left corner. I think the darkened section should be just a little darker so it can easily be read on all pages. --Comment by Selfie City (talk | contributions) 03:45, 1 March 2019 (UTC)Reply

Swept in from the pub

I've been experimenting with implementing a similar use of the Pagebanner extension to yours and ran into the problem that the Heading and ToC simply disappear on Anisa and Timeless skins. As someone pointed out in a request for help here viewing Wikivoyage with the Timeless skin currently does the same thing. I've found what appears to be a simple solution:

On server; mywiki/extensions/WikidataPageBanner/includes/WikidataPageBanner.functions.php has;
* @var string[] name of skins that do not implement 'prebodyhtml'
* banners for these skin will be prepended to body content*/
protected static $blacklistSkins = [ 'monobook', 'modern', 'cologneblue' ];

changing the blacklist to
protected static $blacklistSkins = [ 'monobook', 'modern', 'cologneblue', 'anisa', 'timeless' ]; fixes the problem on mywiki - so I'm wondering if there's some horrible side-effect to doing that which I've so far not noticed... and if not, erm, why you haven't done a similar fix! Hunting dog (talk) 09:22, 6 May 2019 (UTC)Reply

If this doesn't even work in Anisa (a very recent fork of the Example best practices skin), I don't think the problem is with the skins - whatever the extension is doing can't be standard, and it sounds like it's going to need to blacklist every skin. It's possible someone just added something skin-specific to Vector and then got their logic backwards and instead of just checking for Vector, checked for everything but for the fallback? (So yes, you should be safe, but this should probably be fixed to be the other way around in the thing itself...) Isarra (talk) 03:33, 7 May 2019 (UTC)Reply

@Hunting dog: All right, bawolff filed phab:T222681 against WikidataPageBanner to get it fixed here, and that should be a good reference for your own extension as well (if it works, maybe you could submit a patch to that too?).

Whatever the case, thanks for properly looking into this and reporting back - this sort of info is always appreciated, even if it does sometimes take us awhile to find it when it's not directly on the tasks themselves. Isarra (talk) 14:25, 7 May 2019 (UTC)Reply

Excellent thanks! As I'm sure you've gathered I had no idea where to post about this!! Hopefully, that gets things fixed for all of us. Hunting dog (talk) 15:03, 7 May 2019 (UTC)Reply

Definitely a step in the right direction. Also probably useful to have this here anyway since any wikimedia-side folks who'd be affected are, well, here. See, everyone? We're making progress! Isarra (talk) 15:44, 8 May 2019 (UTC)Reply

I just did my first bit of tinkering with an article's Pagebanner template, and I believe I encountered some contradictory documentation, though which portion is in error I'm not entirely certain. If you examine this template's formal doc page you'll see in the description for the origin field the text:

The value of the parameter should consist of an x and a y coordinate separated by a comma. Each coordinate represents the distance from the center of the image as a value from -1 to 1. For example, origin=1,1 is the top left corner and origin=-1,1 is the bottom left corner. There is a graphic here that shows this information visually.

Yet, when you visit the link cited therein, you find the following placed quite prominently...

The origin corresponds to a vector from the center of the image where top left corner is -1,-1 and bottom right corner 1,1. This defines a banner focal point.

Personally I find both systems to be poorly conceived, so I can't even offer an opinion as to which should be preferred. (If my assessment of the situation is, in fact, correct.) Mathematical history isn't my bailiwick, but I have a fairly clear recollection of a lecture in college about a 17th century French polymath who lent his name to the very concept of two-dimensional coordinate systems, and that his system of writing the location on the horizontal axis first (with values ascending left to right) and the vertical axis second (values ascending from bottom to top) was at some point agreed to be the standard. Here we have the doc page describing a system with the vertical axis written first (bottom to top) then the horizontal (right to left). The Phabricator page meanwhile states the method to be horizontal first (left to right) then vertical (top to bottom), which I do see at least some small justification for, since that's how coordinates on computer monitors are given. Ugh, where's that emoji with the spinning eyes when you need him...?

I'm exceedingly new here so I'm hoping someone with greater experience and authority will review this and hopefully set about fixing it so both pages agree, and failing that at least tell me who's right and who's wrong. If asked, I'd submit that both be changed and the underlying code corrected to calculate the vector in accordance with tradition and Mr. Descartes as I think that's what most of us are taught in school, but hopefully I'm too green to find myself a part of such decisions. ;) In conclusion, I'm quite enjoying my time here so far and it's nice to be contributing alongside all of you. Good night and good luck, 🐈⚞ℛogueScholar⚟^{🗨₨UserTalk} 04:38, 23 June 2019 (UTC)Reply

I tested this and indeed the documentation was wrong—the coordinates go horizontal,vertical , and negative is left and positive is right, as a mathematician would expect. I've corrected the documentation to fix these problems. I don't know if up and down are positive or negative because I couldn't think of a way to test it. —Granger (talk · contribs) 14:15, 20 July 2019 (UTC)Reply

The <code><templatedata></code> section has a typo. I don't have sufficient permission to fix it myself. The otbp parameter has been accidentally labeled Destination of the month and should be labeled Off the beaten path. This needs to be fixed in the JSON markup of the template data. Thanks!

Swept in from the pub

I'm new here, so sorry if this is the wrong place. The {{pagebanner}} is giving me some trouble. Could someone look at Eastport (Maine) and help me get the banner looking less bad? Wugapodes (talk) 20:27, 3 April 2020 (UTC)Reply

See Wikivoyage:Banner Expedition#How do I help?. Per the standards described on that page, banners need to be at least 1800 pixels wide, and a 7:1 ratio (2100 x 300 pixels or larger is preferred). The image you're trying to use isn't wide enough, but even if it were, it needs to be manually cropped to the part you want and then uploaded as a separate file. --Bigpeteb (talk) 21:19, 3 April 2020 (UTC)Reply

The current pagebanner looks okay. The problem I see is that it is somewhat blurry on the left side. This may require a new image; there is a tool called Croptool which you can use to get a 7:1 banner ratio from photos on Commons, which can then be used as Wikivoyage banners. If you want more information about that, see Category:Banner missing from Wikidata. --Comment by Selfie City (talk | contributions) 23:33, 3 April 2020 (UTC)Reply

Thank you both! Those were helpful links. There aren't a ton of pictures of Eastport, and I'm too far away to take any myself. I'll look through my albums and ask some friends if they have any they'd be willing to upload to commons. Wugapodes (talk) 01:36, 4 April 2020 (UTC)Reply

User:Wugapodes, I found the banner process to be more complicated than I wanted to bother with, so I list my suggestions at Wikivoyage:Banner expedition/Banner suggestions, and other editors very kindly finish the process. This is a friendly place with lots of helpful people. WhatamIdoing (talk) 20:27, 5 April 2020 (UTC)Reply

Swept in from the pub

I noticed at Washington, D.C. that the tooltip for the green checkmark in the upper right says "Previous Destinations of the month". Could someone with the necessary rights change Template:Pagebanner so that it'll read "Previous destination of the month". The plurality fix makes it a lot clearer, and the capitalization fix is needed, too. Sdkb (talk) 22:20, 19 May 2020 (UTC)Reply

Sdkb, because of the current Extension:WikidataPageBanner design, there is no easy way to change that label because is supposed to be identical to the target, hence at the first glance these are the options:

• Cleanest: open a ticket to ask to implement the possibility to specify a label for each target
• Quickest: create a new page whose name is equal to the label that redirect to target
• Dirtiest: add a JS that changes dinamically the label after the creation of the page

I don't see other alternatives. --Andyrom75 (talk) 06:33, 20 May 2020 (UTC)Reply

@Andyrom75: A lot of that is over my head technically. I'm happy with whatever approach you/others feel is best and want to pursue. Sdkb (talk) 08:09, 20 May 2020 (UTC)Reply

Is it clearer? I have got confused when I click on it, because it doesn't tell about this page as destination of the month, but indeed previous Dotms (I just read carelessly). Of course, the symbol tells this was a previous Dotm, so the question is: should the tooltip tell teh meaning of the symbol or the target of the link? If we want the former, creating the redirect should be no problem, we could create it right away regardless. --LPfi (talk) 08:16, 20 May 2020 (UTC)Reply

I think almost anyone can create a redirect and change the icon name in the template, but if support is needed please ping me. --Andyrom75 (talk) 17:14, 20 May 2020 (UTC)Reply

Today I found the page banner disappeared on mobile view while I view Galapagos wildlife on screen (you can also reproduce here). Is there any way to fix? -- Great Brightstar (talk) 17:07, 31 August 2020 (UTC)Reply

Reproduced with Kiwi Browser "Quadea". -- Great Brightstar (talk) 17:12, 31 August 2020 (UTC)Reply

Unable to reproduce the error on Firefox 79, the banner shows just fine on the mobile version of that page. 87.74.196.200 17:32, 31 August 2020 (UTC)Reply

Today I noticed that {{pagebanner}} by itself now produces no pagebanner instead of the default pagebanner, for example at Somali Sea. @Andyrom75: Could this be due to the recent changes to the template? —Granger (talk · contribs) 15:24, 14 January 2021 (UTC)Reply

Granger thanks for spotting it. Just fixed. --Andyrom75 (talk) 16:49, 14 January 2021 (UTC)Reply

Swept in from the pub

I've noticed that on HebVoy the template fails to every time on Safari browsers on Ipads and Iphones while it works perfectly Safari broswers on Ipads and Iphones for the English Wikivoyage. Can someone maybe suggest a quick fix for this issue? ויקיג'אנקי (talk) 23:32, 8 January 2021 (UTC)Reply

ויקיג'אנקי, most likely is a CSS/JS issue, but since I can't modify mediawiki page on he:voy I'm not able to perform any kind of test. However I've seen that he:voy use the page banner extension, hence all the "topbanner" occurrences on common.js and common.css are useless and can be deleted. No behaviour effect but at least you could focus better on the rest.

For the same reason I would suggest you to reorganize better the styles as done in it:Template:Banner/styles.css for it:Template:Banner simplifing Common.css. --Andyrom75 (talk) 14:42, 9 January 2021 (UTC)Reply

@Andyrom75, if you were willing to clean up the mess, I suspect that they would give you interface-admin rights for a few days. Most small wikis are grateful for any kind of technical help. WhatamIdoing (talk) 18:22, 9 January 2021 (UTC)Reply

WhatamIdoing, I'm a bit busy in this period, hence for the cleaning it would be great if they would be able to be autonomous :-) after that for the test, if the problem persist, I can try to help but unfortunately I don't have a Safari test environment (i.e. the equivalent of the Chrome JS console). Any suggestion would be welcome :-) --Andyrom75 (talk) 21:00, 9 January 2021 (UTC)Reply

You might be able to use a website like https://crossbrowsertesting.com (the mw:Editing team has used that one, and it offers a free trial). I didn't look to see whether it uses mobile devices, and this problem only appears in iOS. WhatamIdoing (talk) 23:33, 9 January 2021 (UTC)Reply

It's a pity that they need a mobile number (I don't like to disclose it), but thanks for suggesting that site. Once he:voy will be cleaned up, I could evaluate its use. Starting earlier could result in the expiration of the trial period before the actual begin. --Andyrom75 (talk) 12:31, 11 January 2021 (UTC)Reply

Is there a way to keep the page name from displaying over the image? Or to move it to the right hand side? I thought ⇨ this banner would be cute, but the page title ruins it by covering up the sign. I cropped some kids faces out of the banner immediately to the left of the sign, in case you were wondering why the sign is all the way to the left. Travelwriter1000 (talk) 22:12, 22 July 2021 (UTC)Reply

Swept in from the pub

Both Pacific War and World War II in China currently show (at least for me, Firefox on Linux) the old-style TOC as well as the one below the banner. The old one is down by the Understand section. I think it should be removed.

I looked at the wiki text & could not see a reason. Can someone fix this? Pashley (talk) 05:12, 4 November 2021 (UTC)Reply

I see them on every article I checked, I also feel they should be removed. Tai123.123 (talk) 05:50, 4 November 2021 (UTC)Reply

@Pashley, Tai123.123: It used to be able to be fixed by adding __NOTOC__ onto {{pagebanner}} but I've just tried it with no success. Maybe @Andyrom75: or @Omondi: might know how to fix it and this issue seems to be on all language Wikivoyages, so we're not alone. Maybe filing a phabricator task might work. SHB2000 (talk | contribs | meta.wikimedia) 06:51, 4 November 2021 (UTC)Reply

I have filed a phabricator task. See phab:T295003. Feel free to subscribe to that thread to get email notifications about this issue. SHB2000 (talk | contribs | meta.wikimedia) 06:57, 4 November 2021 (UTC)Reply

@SHB2000 @Pashley they seem to be gone now, theyre there for a couple of seconds but then they disappear. Tai123.123 (talk) 14:49, 4 November 2021 (UTC)Reply

As the javascript Andyrom75 inserted hides them. But they shouldn't be there in the first place. –LPfi (talk) 14:58, 4 November 2021 (UTC)Reply

Until today, the new-style TOC (in the bar at the bottom of the banner) was the default. Put in a banner & the software would automagically both generate the new-style TOC and suppress the old-style one. It still does the new one just fine (I've tested & that still works) but now it fails to suppress the other. Pashley (talk) 09:20, 4 November 2021 (UTC)Reply

Pashley, @Omondi:, SHB2000, I've temporary patched it:voy and en:voy. See phabricator for details. --Andyrom75 (talk) 10:41, 4 November 2021 (UTC)Reply

I also have patched "MediaWiki:Common.js" on French Wikivoyage and it's also working. Tanks to Andyrom75 --Omondi (talk) 12:45, 4 November 2021 (UTC)Reply

@Omondi, Atsirlin:, the bug has been corrected, so now you can remove the patch in your common.js. --Andyrom75 (talk) 22:10, 9 November 2021 (UTC)Reply

@Andyrom75: Done thanks a lot for your concern. --Omondi (talk) 05:37, 10 November 2021 (UTC)Reply

@Andyrom75, @LPfi, @Omondi When you are logged out of wikivoyage you still see the table of contents. Tai123.123 (talk) 05:49, 12 November 2021 (UTC)Reply

Ok never mind it’s not on most articles when logged out but when I was looking at the Kurayoshi article while logged out I saw the Table of contents. WHEN I logged back in it disappeared ( this was on Ipad) Tai123.123 (talk) 05:52, 12 November 2021 (UTC)Reply

Cache is likely the explanation for that. SHB2000 (talk | contribs | meta.wikimedia) 06:04, 12 November 2021 (UTC)Reply

@Tai123.123: logged out I have tried several articles on the main space, on the Wikivoyage space and on the Aide space ("Help" space what you don't have on Wikivoyage in English) and no table of contents was displayed. But thanks for the warning and I would be attentive to this phenomenon in the future. --Omondi (talk) 06:48, 12 November 2021 (UTC)Reply

@Omondi I first had a look at Greater Blue Mountains Area, and it didn't seem to have a table of contents only to realise that there's no headings in the first place, but a TOC isn't appearing for me in Kanak culture in New Caledonia, The Flashman Papers and UNESCO World Heritage List while logged out. SHB2000 (talk | contribs | meta.wikimedia) 06:59, 12 November 2021 (UTC)Reply

SHB2000, it's normal that Greater Blue Mountains Area & The Flashman Papers do not have the pagebanner TOC (shortly PBTOC), because, the PBTOC is the equivalent of the standard TOC (shortly STOC), and the STOC appears only when there are at least 4 headings (see w:Help:Section incipit).

I see Kanak culture in New Caledonia in a regular way (with PBTOC & without STOC).

Finally the UNESCO World Heritage List's PBTOC wasn't shown because of JamesA's choice (see Special:Diff/2460880). Most likely at that time the PBTOC showed only inline H2 titles and don't the H3 titles in the pop-ups. See now the page. --Andyrom75 (talk) 08:37, 12 November 2021 (UTC)Reply

It seems to work now for Kanak culture now, that issue happens when a page loads for me and my connection is very slow. But thanks for the clarification on the other two though. Makes sense. SHB2000 (talk | contribs | meta.wikimedia) 08:41, 12 November 2021 (UTC)Reply

SHB2000, although I'm not sure, I tend to suppose that you saw the STOC only because of cache issue. To eliminate this doubt, purge the page before your evaluation (with the dedicated link if it's something that you normally use, or adding "?action=purge" at the end of the URL).

However, all that said, articles in view mode are fine, but I've noticed that in preview mode the bug still persist. I've highlighted it in the ticket to the maintainer, hoping that it can be quickly solved as well. Note: a similar patch to the old one can be reintroduced, but since it's not a critical bug I would suggest to avoid it. --Andyrom75 (talk) 08:45, 12 November 2021 (UTC)Reply

That issue of no TOC appearing with a very slow connection has been happening since June 25 this year, but half the time when that happens, the font all appears in Times New Roman. But if I refresh my page, that issue seems to vanish. But it's been a while since I've had that issue, so it was somewhat unusual. SHB2000 (talk | contribs | meta.wikimedia) 08:51, 12 November 2021 (UTC)Reply

Just opened another ticket relevant to the preview mode bug, that for some reason occurs in all language versions except that on it:voy. --Andyrom75 (talk) 07:44, 13 November 2021 (UTC)Reply

The issue has been resolved and soon also the ticket will be closed. --Andyrom75 (talk) 21:35, 10 December 2021 (UTC)Reply

Swept in from the pub

pgname does not appear to accept italic formatting. Can this be fixed? Some types of dive site title such as the names of wrecked ships customarily use italics for the actual ship name, such as SS Clan Stuart. This template is a little complex foe my skills. Cheers, • • • Peter (Southwood) ^(talk): 10:33, 24 November 2022 (UTC)Reply

Since yesterday, pagebanners on most articles (but not all, curiously enough) seem to have shrunk or been cropped when viewing them in the Safari browser, as in the screenshot to the right. In my other browser, Firefox, I don't have this problem at all. Anyone else seeing this? Ypsilon (talk) 16:56, 13 April 2023 (UTC)Reply

I can reproduce this in Safari but not Firefox or Chrome (on a Mac).

If it happened yesterday, it may be related to the weekly deployment train. Jdlrobson might have an educated guess at what changes could have affected something like this. WhatamIdoing (talk) 23:28, 13 April 2023 (UTC)Reply

Thanks for the ping. What version of Safari is this? I can't replicate this on Safari 16.3. The only thing that comes to mind that might be related is the recent reduction in browser support in phab:T178356 which may have impacted this in some way. There's been no change to the extension itself. Jdlrobson (talk) 02:49, 14 April 2023 (UTC)Reply

I tried reproducing this error on Safari, but the banner wasn't as shrunk as shown in the screenshot. I have no idea what version of Safari I'm using, though, and I usually use Chrome anyway. SHB2000 (talk | contribs | meta) 06:28, 14 April 2023 (UTC)Reply

Reproduced with Epiphany on Debian (epiphany-browser 3.32.1.2-3~deb10u2). –LPfi (talk) 08:15, 14 April 2023 (UTC)Reply

When the page (France, as in the screenshot) was first opened the banner was not shown at all (I think). When maximising the window I got the shrunk banner. Playing around with the window size the banner started to behave as expected, also after closing and restarting the browser (I installed epiphany for the test). –LPfi (talk) 08:21, 14 April 2023 (UTC)Reply

Safari Version 16.4 (18615.1.26.11.23), I updated the OS (yes, Mac) a couple of days ago and almost certainly the browser was updated too. Ypsilon (talk) 08:47, 14 April 2023 (UTC)Reply

@Jdlrobson, I can reproduce this in Safari 16.4.1 (17615.1.26.101.10, 17615) on macOS Monterey 12.6.4 (21G526). WhatamIdoing (talk) 16:44, 14 April 2023 (UTC)Reply

@ WhatamIdoing can this be replicated in safe mode? Jdlrobson (talk) 15:33, 18 April 2023 (UTC)Reply

Also what browser width (window.innerWidth) are you seeing the issue at - perhaps there's some specific styles kicking in somewhere they shouldn't? Jdlrobson (talk) 15:37, 18 April 2023 (UTC)Reply

@Jdlrobson, I don't see it in safemode, and I do see it in a private/incognito window (so, something in sitewide css or a default gadget?).

I don't know how to find window.innerWidth. In slowly changing the window width, though, I see it get truncated, then back to normal, then truncate again, back to normal, repeatedly. WhatamIdoing (talk) 20:59, 19 April 2023 (UTC)Reply

Weird. Looks like there were no changes to sitewide CSS or gadgets https://en.wikivoyage.org/wiki/Special:RecentChanges?hidenewpages=1&hidecategorization=1&hideWikibase=1&hidelog=1&hidenewuserlog=1&namespace=8%3B2300&limit=50&days=14&urlversion=2

My guess is this might relate to a recent change in the parser relating to indicators since they are in the vicinity of the banners and they look stacked (I feel they used to be alongside one another). I've pinged someone in that team.

I suspect his could be fixed by adding the following CSS to MediaWiki:Common.css. Can someone test in their local CSS and let me know?

.mw-indicators .mw-parser-output { display: inline; }

Jdlrobson (talk) 00:24, 20 April 2023 (UTC)Reply

@Jdlrobson, assuming that User:Whatamidoing (WMF)/common.css is what you meant, then it made no difference. WhatamIdoing (talk) 16:37, 20 April 2023 (UTC)Reply

What is happening is that the indicators are reserving space in vector 2022, and then once the page banner loads, the page banner logic, tries to calculate the distance to the first heading (or something), and sets a margin-top: -somethingpx on the banner image, which cuts off the dimensions of the banner. The solution is to set .vector-body-before-content { display:inline; } on the vector 2022 code.

However.. the entire page banner code probably needs some rework, it looks a bit dated. TheDJ (talk) 11:36, 9 May 2023 (UTC)Reply

Ah.. the wikipagebanner code has a condition that detects 'portrait' mode images. On macOS, due to responsive auto height sizing, the height is .2px larger than the container's height. This tricks the code into thinking this is a portrait image and applying an margin offset. It seems this is a bug in the subpixel sizing code of Safari, but also a bug that in turn is TRIGGERED by the font-size of 84% that is being set by vector-2022 in the block:

::.vector-feature-zebra-design-disabled #contentSub:not( :empty ),
::.vector-feature-zebra-design-disabled #contentSub2 {
::  font-size: 84%;
::  line-height: 1.2em;
::  color: #54595d;
::}
::

Disabling that seems to fix all the issues with the wikidata page banner. ping @Jdlrobson and @Whatamidoing (WMF). TheDJ (talk) 13:21, 9 May 2023 (UTC)Reply

thanks for investigating TheDJ. Jdlrobson (talk) 14:32, 9 May 2023 (UTC)Reply

All issues noted here, for Safari and Vector 2022 should now be fixed TheDJ (talk) 10:55, 26 May 2023 (UTC)Reply

Thanks for fixing it! :) --Ypsilon (talk) 19:28, 26 May 2023 (UTC)Reply

@TheDJ, Jdlrobson: I don't know if this is related to this issue, but since today, the breadcrumbs of an article plus the text on the banner have appeared much smaller than they used to be. SHB2000 (talk | contribs | meta) 10:40, 16 June 2023 (UTC)Reply

Fixed by https://en.wikivoyage.org/w/index.php?title=MediaWiki%3AVector.css&diff=4681411&oldid=3755283 Jdlrobson (talk) 00:52, 17 June 2023 (UTC)Reply