Wikivoyage talk:Image policy/archive 2014-2019

Images under the Exemption Policy

Swept in from the pub

Hello,

I uploaded an image which should fit under the exemption policy: File:Map of Agra Fort.jpg. What template(s) should I add in the description? This image was deleted on Commons as 2D art is not covered by Freedom of Panorama in India. If it is OK, I will upload more. Regards, Yann (talk) 15:36, 14 November 2012 (UTC)

PS: There is an issue with thumbnails. Yann (talk) 15:43, 14 November 2012 (UTC)

The thumbnails give " Error 401: Authorisation required, it's my way or the highway...". This is a server-side bug so you might want to report that to bugzilla: using the "report a bug" link in the sitenotice? No one here has access to configure the servers. K7L (talk) 15:52, 14 November 2012 (UTC)

Looks like the problem of local files has not been fixed yet. It would be great if you could post another bug report. We don't have any template for non-free content yet. Could you try to copy one from Wikipedia and adjust it to our purposes? --Atsirlin (talk) 15:57, 14 November 2012 (UTC)

{{KeepLocal|reason}} is used on the shared projects to indicate that an image is useful for Wikivoyage but can't be uploaded to Commons for whatever reason, but it seems that the KeepLocal template doesn't exist here. One example here and more examples here. It seems that it is also necessary to create "Information" and "Self" templates. --Stefan2 (talk) 16:00, 14 November 2012 (UTC)

Could an admin import these templates from Commons and/or Wikipedia? Thanks, Yann (talk) 16:04, 14 November 2012 (UTC)

Is there already an exemption policy agreed? Before allowing such files, such policy should exist. Also such policy isn't a blank check to upload everything which isn't allowed on Commons. With such policy there are specific guidelines that determine which files are allowed and which not. Uploading locally is not a dustbin for everything which isn't allowed on Commons. Romaine (talk) 17:15, 14 November 2012 (UTC)

See here. This policy has not matured yet, but it should be enough for the start. However, we cannot start as long as the file upload does not work-( --Atsirlin (talk) 17:19, 14 November 2012 (UTC)

Yann, I'm not sure this image would meet our non-free use policy anyway. If we're going to have a map in an article, it would be better to have a Wikivoyage-style map that's entirely free than to use a picture of a non-free map. LtPowers (talk) 18:48, 14 November 2012 (UTC)

So what quite of images would be allowed? To me, this seems acceptable: a map of the Fort is essential to illustrate properly this article, and this is the original map shown on the site. Yann (talk) 06:09, 15 November 2012 (UTC)

But the map has to be presumed to be copyrighted; you would not be allowed to upload it at Commons. Wherever possible, we prefer files that can be uploaded to Commons, which in this case would be our own map, formatted in Wikivoyage style, and translatable to other languages. LtPowers (talk) 13:38, 15 November 2012 (UTC)

The EDP doesn't have any statement about replaceable images (cf. w:WP:NFCC#1). Should there be one? In this case, the image wouldn't survive deletion on English Wikipedia because it would be possible to replace the image by drawing your own map, or by improving Openstreetmap's map. User:LtPowers's post above sounds a bit like the Wikipedia policy: use Commons images (i.e. free images) whenever possible. Also, the foundation's resolution says that replaceable images shouldn't be permitted, although one could maybe debate what "replaceable" means. --Stefan2 (talk) 13:47, 15 November 2012 (UTC)

I did not include replaceable images when I drafted the policy because I was only considering artwork and architecture presented as artwork and architecture, which are inherently non-replaceable uses. I failed to consider the subset of "artwork" that presents useful information -- e.g., maps -- which are indeed replaceable. That was my oversight, and I apologize. You're right that the Resolution says "An EDP may not allow material where we can reasonably expect someone to upload a freely licensed file for the same purpose," and our EDP should be modified to explain that. I will make a proposal on the talk page. LtPowers (talk) 14:11, 15 November 2012 (UTC)

Of course, this map is under a copyright. That's why I uploaded it here instead of Commons. I don't see how you could make a map which would not be a derivative of this one, unless we make a survey of the whole building ourselves, which is hardly possible. And yes, it meets the criteria of art work in the draft policy. Yann (talk) 16:47, 15 November 2012 (UTC)

Here's a start: http://osm.org/go/zj5un3vvI- LtPowers (talk) 18:32, 15 November 2012 (UTC)

The thumbnailing issue should be fixed now.--Eloquence (talk) 03:11, 15 November 2012 (UTC)

Non-free images

Hi folks; I've taken a stab at creating Template:Non-free image. You can see it in action on File:Sign Mammoth Hot Springs YNP Wyoming USA.JPG. It categorizes images into either Category:Photos of copyrighted works or Category:Orphaned photos of copyrighted works. The latter category is applied if no articles are listed in the template call, so it may not be the best title (it could have false positives if an image is actually used but the article isn't listed on the template... or false negatives if an image is orphaned but an article is listed in the template); I'm not aware of any programmatic way to determine if a file is orphaned or not.

Feel free to tweak as necessary.

-- LtPowers (talk) 01:04, 19 November 2012 (UTC)

File on Commons message

Swept in from the pub

According to point 5 at Wikivoyage:Cleanup: "We need a template like Wikipedia with "This is a file from the Wikimedia Commons. Information from its description page there is shown below."" For that the page MediaWiki:Sharedupload needs to be updated with:

{| align="center" class="plainlinks" width="512px" border="0" cellpadding="2" cellspacing="2" 
style="border:solid #AAAAAA 1px; background-color:#F9F9F9; font-size:95%; margin:.2em auto .2em auto;"
|- 
| [[File:Commons-logo.svg|30px|Wikimedia Commons Logo]]
|align="center" | This is a file from [[:Commons:Main_Page|Wikimedia 
Commons]].<br />Information from its 
'''[{{fullurl:Commons:File:{{PAGENAME}}}} description page there]'''
is shown below.
|}

Can someone edit that page? Greetings - Romaine (talk) 17:06, 17 November 2012 (UTC)

Similar text is already displayed: "This file is from Wikimedia Commons and may be used by other projects. The description on its file description page there is shown below." Is there something more that is needed? LtPowers (talk) 19:47, 17 November 2012 (UTC)

I find that notice isn't noticeable enough. It's just one line of text. We should be immediately able to recognise an image is from Commons without having to read the notice. And there's no harm done from changing it. JamesA ^>talk 01:29, 18 November 2012 (UTC)

I tried updating MediaWiki:Sharedupload but the change doesn't seem to be reflected on image pages - see File:Denali-from-reflection-pond.jpg which still uses the old formatting. Is there another message that should be changed? -- Ryan • (talk) • 01:58, 18 November 2012 (UTC)

Try MediaWiki:Sharedupload-desc-here. JamesA ^>talk 02:42, 18 November 2012 (UTC)

That worked. -- Ryan • (talk) • 02:47, 18 November 2012 (UTC)

Privacy rights shed

In updating this imported page, I basically deleted everything about privacy rights. I did so reading an evolving consensus that we are leaving this sort of thing up to Commons. I left in a note about not adding your "me-in-front-of-touristy-stuff" photos. Does this seem right? --Peter ^Talk 04:34, 11 January 2013 (UTC)

Thumb alignment

We've always discouraged left aligned thumbs. Does anyone mind if I make this official? Again, the reasoning is that our articles are supposed to be fairly uniform in structure—to allow users to quickly scan for their information. Left aligned thumbs break up the listings being scanned. --Peter ^Talk 06:31, 16 January 2013 (UTC)

Traditionally, we have given a wide latitude to editors to deviate from the norm provided they can produce a cogent rationale.

Traditionally, we have been very careless and negligent regarding physically handicapped readers and those whose native language is not a variety of English, and this should change now that we are members of the WMF family.

Our policy should first give clear and unequivocal guidance to newbies, and then more detailed advice for long term editors.

Our Image policy article should clearly state:

"

Please use thumbnails unless you have a good reason not to: "[[File:Name|thumb|alt=Alt|Caption]]" This way, the display size of images can be enlarged if the reader clicks on the lower right corner of the thumbnail. The other details are optional, if you have a good reason to change the default, and can be placed in any order: Type "thumb" (or "thumbnail"; either can be followed by "=filename"), "frame" (or "framed"), or "frameless". Display the image with specific formatting. frameless is a bit like "thumb", but means both the visible caption and the box around the image are left out. Another way to put it, is that this is like specifying no type at all, except that the default size is that of a thumbnail and the "upright" option also works (see Wikipedia article for details). Border "border". Put a small border around the image. Location "right", "left", "center" or "none". Determine the horizontal placement of the image on the page. This defaults to "right" for thumbnails. Alignment "baseline", "middle", "sub", "super", "text-top", "text-bottom", "top", or "bottom". Vertically align the image with respect to adjacent text. This defaults to "middle". Size "Widthpx" or "xHeightpx" or "WidthxHeightpx" or "upright" or "upright=Factor". Scale the image to be no greater than the given width and/or height, keeping its aspect ratio. With "upright", scale a thumbnail from its default size by the given factor (default 0.75), rounding the result to the nearest multiple of 10 pixels. Size is disabled when the image is 'framed'. A factor of 1.3 is often about right for a landscape orientated lead image and 1.7 is often a good choice for maps. Link Link the image to a different resource, or to nothing. Must not be set for non-public domain images unless attribution is provided in some other fashion. Alt Specify the alt text for the image. This is intended for visually impaired readers. See WP:ALT for how this should typically differ from the caption. Caption Specify the image's caption. This is visible only if "frame" or "thumb" attribute is used, but may be displayed on mouseover in other cases. It does not matter whether the file is from Wikimedia Commons or hosted locally; the same syntax is used.

" -- Alice^✉ 02:38, 2 March 2013 (UTC)

I am very much in favor of making it official and clear that we discourage left-aligned images, for the reasons Peter stated. I am not aware of any case where consensus has been reached to keep something aligned to the left, and I can't imagine why we would need to. It is every bit as much a part of the look and feel of our articles as the article templates themselves. Texugo (talk) 03:21, 2 March 2013 (UTC)

In my articles, I have always tried to alternate left- and right-aligned thumbs. I feel that it provides balance to the page layout, especially when two or more photos need to be placed relatively close to each other in order to correspond with the text of the article: stacking one directly on top of the other gives the page a lopsided look, especially when there aren't any other photos for some distance above or below. -- AndreCarrotflower (talk) 03:25, 2 March 2013 (UTC)

As you might expect, I feel that the policy wording I have proposed above, in the pink box, makes it clear enough that editors should not deviate from the defaults without good reasons, while simultaneously giving the flexibility to thoughtful editors such as André who may be able to advance a cogent rationale for deviating from the defaults. These defaults are there for good and sensible reasons, but there will be articles and circumstances where the default of a right-located thumbnail with no size specified and aligned to the middle of surrounding text might need to be changed. Another good reason might be to specify the location of a thumbnail as none to facilitate use in a table. This is not dissimilar from our policy with regard to article templates: do not deviate without good cause.

As an aside, the current revision of the Google relevancy ranking algorithm places a great deal of emphasis on the "alt" text of images since it is an attribute traditionally ignored by people trying to use manipulative Search Engine Optimisation (SEO). If editors start using this correctly, they will not only help our visually handicapped readers, they will also boost Wikivoyage search engine rankings in general! -- Alice^✉ 04:30, 2 March 2013 (UTC)

Again

I am going to insist that we do add to the policy that left-aligned images are discouraged. It doesn't matter one bit that some people want to introduce them - we can always continue discussion about whether they should be allowed. But realistically, that's what it is -- introducing something we have always specifically avoided -- and that is not something that should be done by default just because we never got around to codifying our very long-existent practice. Our body of content has been pretty meticulously curated to always right-align images - of our 30,000+ articles, I would venture that less than 40-50 currently have left-aligned images, and the ones we do have have practically all been added since Peter's original proposal above. Not putting the prohibition in the policy amounts to introducing left-aligned images by default, without consensus, in spite of our long-established practice. I think it is an absolute no-brainer that the policy needs to reflect the established practice which is already in evidence in 99.9% of our articles. It needs to be in there and it needs to be in there now. Those who are in favor of introducing left-aligned images have the onus of building consensus for changing our existing practice, and should not be allowed to impede us describing the time-honored status quo on the policy page. We don't need to build a new consensus to simply describe the status quo, regardless of who disagrees with it. If consensus is ever reached in the future to change the practice and introduce left-alignment, the policy page can always be changed again at that time. Texugo (talk) 00:01, 26 May 2013 (UTC)

I'm inclined to agree—I didn't think there would be any debate about it, given that we've always discouraged the practice... in practice. The only argument I've seen for using left-aligned images is to accommodate more images than the article length allows for, which kind of runs afoul of the minimal use bit. --Peter ^Talk 00:16, 26 May 2013 (UTC)

Moreover, for the purposes of your original proposal above, it doesn't even matter what their pro-left-alignment arguments are, and there is absolutely no need for those arguments to be dealt with before simply describing the status quo in the policy. If we allow supporters to block that, we are effectively introducing what they want by default and reversing the burden for gaining consensus, automatically throwing out our long-established practice and then fighting for consensus to get it back. That is not right. Texugo (talk) 00:22, 26 May 2013 (UTC)

This seems astoundingly, and unusually, combative. I'm surprised to see such vehemence. LtPowers (talk) 02:38, 26 May 2013 (UTC)

I suppose so, and I'm sorry if my language is strong. I have just finally gotten through similar but much more heated discussions about a bunch of similar practices/policies on pt:, and I thought I sensed in the above the same tactic at work: a simple clarification of long-established practice has been stymied since January just because somebody wants to change that established practice first, with the result that the discussion is deadlocked and their desired change is implemented by default until some future consensus is re-reached, which in this case may be never. Maybe I have overdone it, but I did want to leave it clear that I consider this tactic to be unfair and unquestionably un-wiki-like. Sorry if I have offended. Texugo (talk) 03:08, 26 May 2013 (UTC)

I oppose on the principle that once put into policy it becomes, in practice, virtually impossible to change in the future. Our policies are becoming increasingly prescriptive. By all means produce a guidance, a recommendation, but not a prohibition. Cheers, • • • Peter (Southwood) ^(talk): 06:42, 26 May 2013 (UTC)

I'm very sorry, but I do not really recognize "oppose" as a valid position in this case. We aren't proposing to make anything "more prescriptive" - there has already never ever been a single case among 30,000+ articles in all these years where we decided left-alignment was ok. The practice has always been 100% consistent across all articles. Call that prescriptive if you will, but that is the status quo, and describing that in policy would represent no change, while omitting it or putting anything less into policy would represent a passive change to become more permissive without any consensus for such change. To oppose simply describing the way things have always be done is simply a vote to bypass the the process of consensus for change. Any discussion to change how we do things and make it more permissive should be a completely separate discussion. I cannot fathom any legitimate reason for opposing the simple explanation of the status quo. Texugo (talk) 13:29, 26 May 2013 (UTC)

That's an interesting way of putting it. What do you regard as valid positions?

By the way, I do not agree with much of your summation above. • • • Peter (Southwood) ^(talk): 14:58, 26 May 2013 (UTC)

Walt Disney World/Animal Kingdom was promoted to Star with a left-aligned image. LtPowers (talk) 15:30, 26 May 2013 (UTC)

Wow, you're right, although I would consider that it simply slipped under the radar, and I don't think I am the only one who would have objected had I seen the nomination process. Look, I regret reopening this conversation with such a combative tone, but no one can deny that, as Peter stated, left-alignment has always been discouraged and has been corrected to the right in 99.99% of our content. The fact that it wasn't written down was never really an issue, but now that we have moved to WV, it is starting to proliferate and it has become an issue which is starting to change the consistent look of our content. Since the way WV works is "status quo until consensus to change", we need to stop now and evaluate what the status quo is (our starting point) to know what default will prevail in the event that no consensus is reached. I think it is more than obvious that status quo is against rather than for, regardless of any extraordinarily rare exceptions you may dig up, and if we do not clarify that that left-alignment is discouraged and always has been, the new practice will continue to grow and proliferate as if that were the status quo when it is clearly not. Again, I am sorry if I have offended, but I feel very strongly that left-alignment should not be able to win on a technicality that gives it the status quo advantage simply because we never bothered to write it down back in the day. Texugo (talk) 17:10, 26 May 2013 (UTC)

To Peter, I don't understand your point about policy articles becoming too prescriptive. Isn't that what they're there for? I'm all for looking the other way while productive contributors get their feet wet, but at the point of a star nomination, we look to the style policies to make sure a nominated article in line with our practices. --Peter ^Talk 18:35, 26 May 2013 (UTC)

Also to Pbsouthwood, you wrote above that "once put into policy it becomes, in practice, virtually impossible to change". I would say that it is just the opposite: if not put into policy now, it will become, in practice, virtually impossible to preserve things the way we have intentionally kept them for years. And I do not think that is remotely fair. Texugo (talk) 18:40, 26 May 2013 (UTC)

We have a few guiding principles, and a few core content policies. Together these define WV. The rest of the policy is there to support those critical items. The more rigid the detail becomes the more difficult it is to do new and interesting things which may be improvements. If the manual of style is tightened up so that it only allows one way of presenting an article, there can be no growth into areas which are within the guiding principles and core content, but have been prohibited by rigid and possibly even unintended restraints. When that happens, generally either people ignore the rules, including the good ones, or leave. My personal opinion is that our rules are already excessively restrictive in some regards. Some may think I am trying to force my wishes on the rest, but equally it may be claimed that others are trying to force their somewhat more specific and restrictive wishes on the rest. I would prefer the project not to become a tyranny of the majority.

Texugo, consider the possibility that some of the ways we have intentionally kept things for years may not be the best ways for them to be, either now or in the future. Some of the ways things were done in the past have already been changed, and some of us think these have been improvements. Would it be fair to stifle improvements? Bear in mind that the community changes over time, and technology changes over time, and if the policies do not allow change to take advantage of new technology, or are unacceptable to new contributors, or old contributors who want to try something new, the project will stagnate and die.

All policies should have a clearly defined reason, and the reasons should be stated in the policies, so that if the reason for a policy one day is no longer valid, it will be possible to change the policy. Could we have a nice clear summary of the reasons for not allowing left aligned images, so we can see why they are currently such a bad thing? • • • Peter (Southwood) ^(talk): 07:51, 27 May 2013 (UTC)

I don't really think your fears are especially well-grounded with regard to the rigidity of our policies inhibiting change or growth. If changes are truly worth making, we discuss, we reach consensus, and we change them. As you have pointed out, we have already changed some of the ways things were done in the past - we've introduced categories, changed section headers, changed tags to templates, changed our listing format, introduced page banners, introduced new article types, working on dynamic maps, etc. - we have been pretty good with adapting to new technology and new ideas, and every one of those changes was well discussed until consensus was reached before implementing them. In this case however (and the case of galleries below), we are allowing the way we do things to be changed without such discussion and consensus. We have always been, for years, very strict with regards to left-alignment, which is why our body of content is very consistently right-aligned. Now however, there are new contributors, great ones even, who disregard our established practice, and those of us who do not wish to introduce the new practice are now left without any fair way to keep correcting them, so it is slowly starting to change our formatting, and without the discussion and consensus that should happen first. To go from strictly weeding out all left-aligned images to allowing them whenever somebody wants is unquestionably a big change for our content, and I insist that, like all other big changes, we be given a way to preserve things the way they are until such time as consensus has been reached. The only way to do that is to make policy reflect the practice that has brought us to this point, and then proceed with the discussion for change afterward. If we try to do it the other way around, the new practice will continue to take hold in the meantime, despite the fact that consensus may never be reached, and those who want to keep the traditional way things have been done will have lost completely by default. Texugo (talk) 11:32, 27 May 2013 (UTC)

Oops, forgot to answer your last paragraph. Rationale for not using left-alignment includes, at least:

• it creates a meandering text flow, the appearance of which varies greatly depending on the user's font size, monitor size, window size, and browser type
• it introduces random flow and formatting problems (same reason we are happy to eliminate the left-aligned TOC), and these are not always evident to the person adding, due to the same variables as the previous point.
• it reduces quick scannability of listings by splitting parts of lists away from the left margin
• it presents yet one more aesthetic variable for editors to disagree and fuss over.

There may be other arguments introduced over the years as well. Texugo (talk) 11:41, 27 May 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

While I would agree that right-alignment of images is the preferred format in almost all cases, I also agree with Peter that many of our policy pages are turning into long lists of things that aren't allowed, which is a concern. In this case would it be acceptable to update the image policy with something like the following:

Images should be right-aligned, as this keeps a consistent look and feel across articles and avoids layout and flow issues that can be encountered when different alignments are used. If there is a compelling reason to use an alignment other than right-alignment, be sure that the reason is obvious to others and ideally explain that reason in an edit comment or on the article's talk page. Please do not use different alignments solely as a way to fit more images into an article - see minimal use of images.

Would that encapsulate the preferred formatting, without closing the door entirely on experimentation? -- Ryan • (talk) • 18:24, 27 May 2013 (UTC)

I appreciate your diplomatic attempt at resolution, and that would certainly be better than nothing. I might be amenable to that wording, particularly if you strike the words "in an edit comment or", but in almost a decade of working with this material, have we ever come across any situation where we agreed there was a compelling reason to use another alignment which was obvious to others (besides perhaps centering panorama pictures)? Texugo (talk) 21:02, 27 May 2013 (UTC)

I'd be pretty happy with that wording, although I might add at least one strict line: "don't use them when they would alter the formatting of a bulleted list." That's the single biggest problem they present. --Peter ^Talk 23:12, 27 May 2013 (UTC)

I would like to see that caveat as well. And since it has always been possible to avoid left-alignment in one way or another, I'd much prefer that an edit comment alone not be sufficient. I think an argument should be presented as to why an exception has to be made, because I have never seen such a case. Texugo (talk) 00:04, 28 May 2013 (UTC)

Looks OK to me. It discourages without shutting off the possibility of using it if there is a situation where it works better than the other available option. I do prefer the reasons to be listed, both in the policy article explaining why the use is discouraged, and in any article where it might be used.

Re the reasons listed above:

• Appearance differences may be sorted out by browser development. Not holding my breath, but possible as this is a current technology issue. Currently valid, may fall away some day.
• Also a current technology issue, which may change. Currently valid, may fall away some day.
• Quite agree on this point. Messing with list appearance is not good for legibility.
• A bit over the top in my opinion. I don't see this as a valid reason myself. There will always be differing opinions on aesthetics to argue about.
• If there are other reasons introduced over the years they should be listed too, otherwise if the others are not relevant, they may be missed in the argument for using a left aligned image. if and when this occurs. All reasons for not using should be listed, and it should be specified that they are technical or aesthetic reasons. The more clarity there is, the less likely that there will be disagreement. They don't have to be added immediately, and can be removed as and when they are no longer valid. • • • Peter (Southwood) ^(talk): 07:20, 28 May 2013 (UTC)

Proposed wording

Ryan's wording above garnered some support. Altering it a bit to accommodate concerns expressed by Peterfitzgerald and myself, we have:

Images should be right-aligned, as this keeps a consistent look and feel across articles and avoids layout and flow issues that can be encountered when different alignments are used. If there is a compelling reason to use an alignment other than right-alignment, be sure that the reason is obvious to others and ideally explain that reason on the article's talk page. Please do not use different alignments solely as a way to fit more images into an article - see minimal use of images. Don't use them when they would alter the formatting of a bulleted list.

Can we please put this into the policy now? Texugo (talk) 19:39, 24 September 2013 (UTC)

Looks fine to me, and that wording matches existing practice. -- Ryan • (talk) • 19:46, 24 September 2013 (UTC)

I question whether we ever had a strong consensus for so heavily favoring right-alignment. Certainly it's preferred, but having to individually justify every single use seems extreme, especially since we have star articles that were promoted with left-aligned images. LtPowers (talk) 20:21, 24 September 2013 (UTC)

LtPowers makes a good point about star articles with left aligned images. That precedent suggests a prior consensus for a greater tolerance of left aligned than the proposed wording. It should not be necessary to require that the reason is obvious to others or explain it on the talk page. It can be explained if anyone chooses to move it, and the person who chooses to move it can then explain why it would be better in a different place. I agree they should not mess with list formatting.

Alternative: Images should generally be right-aligned, as this keeps a consistent look and feel across articles and avoids layout and flow issues that can be encountered when different alignments are used. Please do not use different alignments solely as a way to fit more images into an article - see minimal use of images. Don't use them when they would alter the formatting of a bulleted list. • • • Peter (Southwood) ^(talk): 06:46, 25 September 2013 (UTC)

That one star article just slipped through the cracks and does not really constitute any binding precedent here, especially considering there were very few commenters who participated in its nomination process, plus the fact that both instances in that article do interfere with the formatting of bulleted lists, which we agree is unacceptable. I am not the only one who would have opposed it on these grounds, had I noticed it. Other than that, I just used a bot to do a count: there are 194 articles which currently have a left aligned image, or around 0.7% of our mainspace articles. I would venture that a majority of these have been added in the months since this discussion was first started, and especially given that it requires a bot to find them, I'd say it means that this hitherto unwritten policy has been more consistently enforced than even many of our written policies. If there were a way to simply find them with the search box or a maintenance category, you can be pretty sure that number would be practically zero by now. Looking through the list I found, I haven't found any where there is any particularly good or obvious reason for the left alignment, nor any case where the reason has been explained and agreed upon. It boils down to this:

• undeniably, left-alignment has overwhelmingly always been corrected to the right
• there has been no case where we have discussed and had consensus to keep something on the left
• to say that images "should generally be right-aligned" but not require any justification for putting on the left means either:

• "should generally be right-aligned" is meaningless and you can still put images on the left whenever you feel like it, with the expectation that nobody will come along and correct them without discussion (which is contrary to established practice); or
• I would still be implicitly justified in correcting the 194 existing and any future instances to the right, without need for explanation (in which case putting left-aligned images without justification is futile)

I'm sorry, but we have always had a high degree of consistency on this, and I think exceptions need a justification/consensus. Otherwise you can expect that, as has always been done, left-alignment will eventually be corrected to the right. Texugo (talk) 13:31, 25 September 2013 (UTC)

I really don't understand why you feel so strongly about this issue, Texugo. Can you point to any instances (prior to the recent one) where a well-formatted, mostly-complete article largely written by a reliable contributor had left-aligned images actively moved to the right? LtPowers (talk) 14:47, 25 September 2013 (UTC)

There is no way to search for that, and I'm not sure what the point would be. Besides you and Andrecarrotflower, reliable contributors have generally collaborated with the practice of right-alignment. Do you somehow, in spite of the overwhelming numbers, still doubt that images have routinely and consistently been moved to the right thousands of times over the years? I feel strongly about it because unless someone feels strongly about it, the status quo falls by the wayside without any consensus for the effective change in standard article appearance. Texugo (talk) 14:58, 25 September 2013 (UTC)

Yes, but why does the possibility of the status quo changing without explicit consensus bother you so much? LtPowers (talk) 15:10, 25 September 2013 (UTC)

Because that is not how long-established practices should be changed on a wiki. Just because an established practice didn't get written down didn't mean that we started allow montages to be introduced by default - we finally added the wording in 2009. We didn't let a similar omission start allowing galleries by default - we finally added the wording a few months ago. This case is not any different. Texugo (talk) 15:30, 25 September 2013 (UTC)

I don't accept your premise. The wiki way is collaborative, and very frequently standards emerge organically merely by observing what others are doing. Likewise, standard practice can change organically, as it seems to be doing here. In such cases, I believe one needs to have a good reason to stand in its way. A requirement to garner consensus before changing anything is harmful to a wiki, not helpful. LtPowers (talk) 17:56, 25 September 2013 (UTC)

LtPowers - it is very clear that the standard here has always been "right aligned unless there is a good reason to use some other alignment", and that in cases where people have added left-aligned or center-aligned images without any reason for doing so we have moved them back to the right in order to avoid layout problems. Is there some wording you could propose that would reflect that reality that would be more acceptable? -- Ryan • (talk) • 15:14, 25 September 2013 (UTC)

If wording is necessary, Peter's suggestion above is a good start. Your phrasing is also good; perhaps we just disagree on what a "good reason" is, and I vehemently disagree with Texugo's desire to have every exception pre-cleared. LtPowers (talk) 17:56, 25 September 2013 (UTC)

So let me try this again, then: If no justification/explanation is required to make such exceptions, then can they be corrected on-sight to the right with the automatic greater justification that we discourage left-alignment? If the answer is yes, wouldn't it be in the interest of the person left-aligning to provide a justification anyway, so that left-aligning isn't just an exercise in futility? On the other hand, if the answer is no, wouldn't it just absurdly revert the onus of justification onto the person who is simply trying to align things in the recommended fashion, the way we always do? Texugo (talk) 18:04, 25 September 2013 (UTC)

LtPowers: "Can you point to any instances (prior to the recent one) where a well-formatted, mostly-complete article largely written by a reliable contributor had left-aligned images actively moved to the right?" Answer: Clarence, but is that the "recent one"? Ikan Kekek (talk) 18:13, 25 September 2013 (UTC)

(edit conflict) If I'm understanding, the sticking point seems to be justifying use of another alignment. In cases where I've seen other alignments it's usually done to avoid an infobox or because the image is oddly shaped (panoramas, for example) so what about just making the standard "clear to a casual editor why another alignment is being used":

Images should generally be right-aligned, as this keeps a consistent look and feel across articles and avoids layout and flow issues that can be encountered when different alignments are used. If another alignment is being used please ensure that it is obvious why a non-standard alignment is needed - for example, left-aligning to avoid an infobox or centering a very wide image - but please do not use different alignments solely as a way to fit more images into an article (see minimal use of images). Never use any alignment other than right-aligned when the image might alter the formatting of a bulleted list.

If a casual editor can't quickly determine why the image isn't right-aligned then there probably isn't a good reason for that alignment, but in cases like Walt Disney World/Magic Kingdom#Sleep it is clear that the alignment was changed to avoid interfering with the infobox. -- Ryan • (talk) • 18:24, 25 September 2013 (UTC)

(outdent) Okay, I stand corrected; Walt Disney World/Epcot was indeed changed waaaay back to right-align an image I'd put on the left for layout reasons. I contested it on the talk page, and discussion (since other pages were involved) moved to Wikivoyage_talk:How to add an image#Alignment; that discussion ended without a response to my comment regarding the aesthetics of exclusive right-alignment. But that's not germane here, as we're talking about what current policy is. The only thing that's clear to me in that regard is that Texugo and Peter (F) regard right-alignment as the only acceptable standard and do indeed change it whenever they see it. What I contest is that this preference on their part constitutes a long-standing sitewide consensus. In previous discussions, mention was made of earlier discussions that would represent such a consensus, but I haven't seen them yet.

I have no problem codifying a preference for right-alignment, but I do not feel we should give carte blanche to enforce compliance with that preference without discussion.

-- LtPowers (talk) 18:47, 25 September 2013 (UTC)

The only options I see are to

• give carte blanche to correct unjustified deviations, or
• give carte blanche to ignore and defy the preference at will without discussion, and make anyone correcting such deviations explain themselves every time

Only the first makes any sense at all. Texugo (talk) 19:02, 25 September 2013 (UTC)

Also, you have just reminded me that we did actually have "Images should always be placed to the right of the article" in writing for five years at Wikivoyage:Images_in_articles before that was summarily redirected to Wikivoyage:How to add an image in October of last year without first merging that wording. Texugo (talk) 20:24, 25 September 2013 (UTC)

Of course it also says "These guidelines are just that — guidelines. Remember that they are still being developed by editors like you based on their experiences. Break these guidelines sooner than do anything barbarous, but try to update the guidelines to take care of the situation." You're taking an extremely hard-line stance here. It's very disappointing. LtPowers (talk) 23:40, 25 September 2013 (UTC)

I am simply backing the community's historically hard-line stance as evidenced by the remaining 99.3% effectiveness of the practice, in spite of the lack of a non-script way to track them, and in spite of several months now of no longer being allowed to uncontroversially continue patrolling them due largely to the resistance in this thread to simply writing down the way things have always been done. The current rate of 99.3% enforcement is probably the lowest it has ever been, but it is still evidence of a very hard-core consistent community stance. The wording should reflect the way it has always been done because that is the status quo. The wording should not be looser than we have traditionally been such that people can just start using left-alignment whenever they feel like it and we have to repeat the whole conversation every time we want to correct it. That would represent a change in practice, and that kind of change needs consensus. If loosening the community stance is what people want, the policy can be discussed and changed later, but a wish to change the established practice should not be allowed to stymie a simple effort right now to describe the way things have always been done. Texugo (talk) 23:58, 25 September 2013 (UTC)

Existing policy does not prohibit "thumb|left" images. Even if you were proposing to change "should right-justify" to "must right-justify" that is a substantial policy change and, unless you can obtain consensus for this change, it doesn't get done. K7L (talk) 03:55, 26 September 2013 (UTC)

That argument is unacceptable and completely wrong because it ignores the intentional and highly consistent long-standing community practice of avoiding left-aligned images. Simply recording that practice in writing does not in fact represent any change in the way things are done, whereas opening it up to start allowing them whenever you feel like it would indeed be a change that needs consensus. You don't get to say "haha you forgot to write it down so I get what I want". Written policy should be adapted to fit practice, not practice changed because we failed to write it down clearly. Texugo (talk) 11:18, 26 September 2013 (UTC)

"Adapting" policy as you describe it is just another word for "creating" policy. Get consensus first. K7L (talk) 14:51, 26 September 2013 (UTC)

(edit conflict) Dead wrong. If you willing to thus summarily dismiss the undeniable fact that left-alignment has always heavily frowned upon and intentionally rooted out and corrected for almost 9 years, you are simply trying to cheat the established system to introduce what you personally want. Texugo (talk) 15:26, 26 September 2013 (UTC)

Texugo, so far, all you've proved (in regards to "intentional and highly consistent long-standing community practice of avoiding left-aligned images") is that you and Peter chose to move left-aligned images to the right when you see them. Any exceptions to this -- cases where the community did not change left-aligned images -- have been dismissed by you as "well, I didn't notice them". You've invented a tautology, apparently based solely on the personal preference of two editors, and now you want to encode it in policy so that it is harder to change in the future. You're going to have to start providing some evidence that your preference really was widely accepted by consensus before I acquiesce to your demand to have that preference encoded in policy. LtPowers (talk) 15:15, 26 September 2013 (UTC)

You are also dead wrong, Lt. Powers. Surely you can't believe that it was just me and Peter who "cleaned" 25,610 of our 25,804 articles. I didn't even know how to search for them until 2 days ago. The consistency in our body of articles is so overwhelming that it's almost a defining feature of our look when compared to other wikis. That is the evidence, and is all that is needed. I haven't "invented a tautology" based on personal preference - you are using personal preference to impede preservation of the status quo. Texugo (talk) 15:26, 26 September 2013 (UTC)

I don't think there is any question that right-aligned has always been the preferred standard - Texugo's 99.7% number, text on the old "how to" page, the memory of numerous editors (myself included) about past discussions, and a handful of talk page discussions that have been mentioned all support that assertion. That said, I don't agree that left-aligned has been prohibited in the past, nor should it be in the future. We have always encouraged right-aligned unless there is a clear reason to use something else. Let's just note in policy that unless there is an obvious reason for using another alignment that images should be right-aligned and be done with it. -- Ryan • (talk) • 15:30, 26 September 2013 (UTC)

I will concede to use your last wording, Ryan. Texugo (talk) 15:37, 26 September 2013 (UTC)

Obvious to whom? • • • Peter (Southwood) ^(talk): 18:48, 26 September 2013 (UTC)

I would think "obvious" as in "a means to avoid an otherwise obvious layout problem" (i.e. infoboxes piling up, etc.). Texugo (talk) 18:57, 26 September 2013 (UTC)

You keep claiming we're "dead wrong" but refuse to provide evidence. Anyway, I do not support any sort of wording that requires "reasons" to be "obvious", as that's highly subjective and leaves certain people with strong preferences on this issue free to change the considered layout choices of established editors by simply claiming that there was no "obvious" reason. LtPowers (talk) 19:13, 26 September 2013 (UTC)

I have no idea what kind of "evidence" you think you need. Are you asking me to build a bot to scrape 9 years of history to show you a list of all the many many times left has been corrected to right? You know they are there - we didn't get to 99.3% consistency by accident, nor by the sole efforts of Peter and myself. And you still haven't answered my question, posed two different ways above, so I'll try a third: How in the world could "carte blanche to use unjustified left-alignments with an expectation they will stay that way" ever be consistent with our preference for right-alignment? The only result of that would be that it would now be ok for anyone to use left-alignment whenever they want, which would simply make stating the preference meaningless. The result would be that we would be powerless to keep doing things the way they have always been done, and preserving that is the reason this whole thread was started in the first place. Texugo (talk) 19:47, 26 September 2013 (UTC)

How about a discussion, Texugo, where we achieved consensus to do things a certain way -- you know, exactly the sort of evidence we provide routinely when someone asks why something is the way it is. We point them to a discussion we had where we came to an agreement. I am not contesting that right-alignment is a standard; what I contest is the idea that its enforcement by fiat was ever routinely undertaken by anyone except you and maybe Peter when it comes to positioning decisions made by experienced, trusted contributors. We routinely give trusted editors a fair amount of leeway on issues related to formatting, layout, and style, and I believe the history of image alignments (e.g., Star articles promoted with alternative image alignments) bears that out. I have no doubt that we routinely shift images to the right when left-aligned by new contributors, or on short poorly formatted articles. But the idea of taking a considered decision by a trusted editor to left-align an image and negating that by fiat... I do not believe that was ever widely accepted policy, nor do I believe it should be. LtPowers (talk) 00:44, 27 September 2013 (UTC)

I'm not sure whether this should count for much, but since I found out a while ago that it's customary to align all images right, I have made a number of edits that moved images from left or center to right, giving the customary status of right-alignment as a reason. Ikan Kekek (talk) 01:35, 27 September 2013 (UTC)

Most edits moving an image from one place in an article to another would probably go unremarked, whether they followed a specific policy or not, for a variety of reasons:

• Many people would not feel particularly strongly one way or another whether the image is aligned left or right.
• Possibly the majority of editors are not entirely familiar with all the details of all the policies, and would simply accept a claim that a relatively harmless edit was done following a stated policy assuming good faith on the part of the editor making the change.
• When we see a trusted editor has made a change to an article on our watchlists, we generally assume good faith and don't bother to look more closely unless genuinely interested to see what improvement they have made.
• This is a wiki, people edit. Mostly small changes like image placement are not worth arguing about, so we leave them. This will probably remain the case with right/left alignment. I really don't get upset by left alignment if it doesn't harm formatting. I also don't get upset if someone chooses to change it to right alignment if it makes no observable difference to the quality of the article. I don't even care if someone makes a habit of systematically rearranging image alignment as long as it does not go against a policy, and as long as nobody else objects. When someone else objects, I feel obliged to check if the objection is justified. When there is no functional reason for a change, I may take a side depending on what looks right to me.
• I don't like unnecessary or unnecessarily inflexible rules. They stifle creativity and reduce the range of possibilities for development, and if they turn out to be a problem they are almost impossible to remove and cause endless strife.
• As things stand, we all have carte blanche to make any change that we think improves an article as long as it does not go against a policy. This is implicit in the guiding principle "Plunge forward". The principle of consensus is only invoked if someone disagrees with that change.
• There are maybe half a dozen of us debating this point. This is hardly representative of the community of editors, not even of admins. We couldn't claim a genuine consensus of the community even if we all agreed. Consensus by failure to object due to ignorance is not a logically or ethically defensible concept, even if it is implicitly used by governments. • • • Peter (Southwood) ^(talk): 07:40, 27 September 2013 (UTC)

I don't care greatly about this debate, either. The only thing that would cause me to care is if an alignment of an image creates some kind of problem, which I recall it's been stated that left-alignment does. That said, just as when people don't vote in an election, their preferences don't have an effect on it, whoever doesn't take part in policy debates doesn't get to shape the policy. As you said, most editors probably don't care much about image alignment, but if you consider it really important to get more people's opinions, we could try to publicize this debate more. Ikan Kekek (talk) 07:47, 27 September 2013 (UTC)

I don't think many people will care one way or the other, my point is that most probably don't even know that the matter is under discussion, so their absence from it is not a matter of choice. There is no general notice that I am aware of to let everyone know when a policy decision is being discussed. As a result, much policy may be made, and consensus assumed, by a small minority - those who knew that the discussion was happening. I don't claim that this is done in bad faith, only that it happens. Anyone can put the policy pages on their watchlist, if they know to do so, but discussions for new policies may get in under the radar. • • • Peter (Southwood) ^(talk): 09:19, 27 September 2013 (UTC)

The closest to a general notice would be postings in the Pub and Requests for Comment. Ikan Kekek (talk) 09:42, 27 September 2013 (UTC)

Hrm, this discussion seems to have come a bit off the wheels. My thoughts basically boil down to these: right alignment is our de facto standard, with overwhelming conformity, and a tradition of "correcting" images back to the right; there are valid reasons for this preference beyond aesthetic concerns; and asking editors to justify the occasional deviation is not onerous.

Can we agree on Ryan's last proposal? It seems to satisfy the concerns raised by all parties? --Peter ^Talk 16:30, 28 September 2013 (UTC)

I still object to the requirement that alternative justifications have "obvious" justifications (er...). Shouldn't it be enough that an experienced, trusted editor thinks it's better to have a particular image on the left? If someone wants to know why it was done, one can ask, rather than blindly (and without edit comments!) change it. LtPowers (talk) 00:08, 29 September 2013 (UTC)

Edit comments: "Justified thumbnail right, per Wikivoyage custom." Ikan Kekek (talk) 00:28, 29 September 2013 (UTC)

Galleries

We have long discouraged galleries, mainly to stick to our Minimal use of images policy. Would anyone mind if I stick this in the policy page. This would follow Wikivoyage:How to add an image#Thumbnails. --Peter ^Talk 19:17, 18 January 2013 (UTC)

We have a few star articles that include galleries - Singapore has several, and a bunch of the Diving the Cape Peninsula and False Bay articles also use galleries. This is horribly worded, but our implicit policy thus seems to be something along the lines of:

"Image galleries are generally discouraged and should only be considered for lengthy articles for purposes of providing examples of items described by a specific section of text (for example, when describing animal species or food items). Image galleries should not be used solely as a way to include a large number of different pictures in a destination article."

-- Ryan • (talk) • 19:31, 18 January 2013 (UTC)

How about:

Image galleries are discouraged, and should only be considered for showing multiple examples of a specific topic (for example, in describing flora and fauna or cuisine—but not attractions). Keep in mind that we aim for a #minimal use of images.

--Peter ^Talk 20:05, 18 January 2013 (UTC)

That's far better stated than my wording. Would it be OK to also note that this only applies to lengthy articles? I don't think we want people to start using image galleries as a replacement for text, so how about "...should only be considered in lengthy articles for showing" ? -- Ryan • (talk) • 20:10, 18 January 2013 (UTC)

Maybe—see below. The worry would be that long articles are already tougher and have more images than a molasses internet connection can handle. The main point, I think, is just that they should be rare, and have a specific reason for inclusion, beyond liking galleries. --Peter ^Talk 21:11, 18 January 2013 (UTC)

IMHO, the main issue with the articles Singapore and Diving the Cape Peninsula and False Bay is that they are too lengthy, and would be impractical to print on paper, or display on a mobile device. They should have appendix articles, such as Singaporean cuisine or list of dive sites in Cape Peninsula and False Bay, so that they are not much longer than 100k. /Yvwv (talk) 17:37, 25 January 2013 (UTC)

A workaround for bandwidth problems might be to put galleries into a sub-article for any given article, so you only look at them if you want to.

Another thought in this line: Is it possible to have a gallery that does not load with the article initially, but loads and opens in the article if you click on it? • • • Peter (Southwood) ^(talk): 15:00, 10 February 2013 (UTC)

@Yvwv, Do you have any practical suggestions for a logical split for Diving the Cape Peninsula and False Bay which would not harm its utility?

I like the suggestion of a click to expand gallery. I don't know how possible it is, though. --Peter ^Talk 21:55, 11 February 2013 (UTC)

Like this?--Traveler100 (talk) 06:36, 12 February 2013 (UTC)

Gallery text title not collapsed

• 
  Rhenstein southern start/end at Schloss Biebrich
• 
  Goethestein, Wiesbaden-Frauenstein
• 
  Erlenbachtal near Wiesbaden-Frauenstein.
• 
  Honigberg near Kiedrich
• 
  Eberbach Abbey

That gallery is loaded together with the rest of the page, and revealed when you click on "Show". I think Peter S. wanted something that would not load up front with the rest of the page, reducing the bandwidth required, and would only load (and display) after being clicked. --Avenue (talk) 11:50, 12 February 2013 (UTC)

Yes, there is not much point in collapsing the gallery unless the bandwidth is saved. • • • Peter (Southwood) ^(talk): 12:08, 14 February 2013 (UTC)

I have a problem with galleries: Often, the photos are thereby too small for easy viewing of the salient features. I think galleries are very problematic. Ikan Kekek (talk) 05:12, 20 February 2013 (UTC)

I like our policy against galleries. Exceptions must be proven to enhance the guide somehow rather than just show off a bunch of pretty pictures. If people just want to look at images, they can go to Wikimedia Commons, Flickr, Google, etc. ChubbyWimbus (talk) 05:37, 20 February 2013 (UTC)

This does not appear to have been added to the image policy yet. Please see my comments in the "Again" subsection of the "Thumb alignment" discussion above, as they apply here too. Not expressing our long-standing practice of discouraging galleries amounts to encouraging them, effectively reversing our practice without discussion. I suggest that Peter's last wording be added to the article immediately. If we reach discussion later to change our already-established practice, we can always change the policy page again. Texugo (talk) 00:12, 26 May 2013 (UTC)

I do not see that pretty pictures are an undesirable feature of a travel guide. The only realistic objection I have seen against them is the bandwidth and display problem, which can be dealt with by putting high bandwidth media on a sub-page, so the user can choose to look at it or not. Allowing gallery subpages deals with this problem, and they could be formatted to display at a useful size. • • • Peter (Southwood) ^(talk): 06:51, 26 May 2013 (UTC)

The established practice is not against "pretty pictures". As I see it, it is:

• against an unbalanced excess of pretty pictures
• against turning the site into a picture book or image repository (that's what commons is for)
• against jumbling the pretty pictures together in such numbers that they lose their character and effectiveness
• against breaking up the text with giant blocks of images to scroll past
• against presenting images too small to view well without an extra click (see Ikan Kekek`s comment)

Allowing sub-pages would only address the last two points above.

And again, regardless of the arguments for or against, why would we need to wait possibly forever to reach a new consensus for a proposed change before simply describing the status quo of how things are currently and have always been done? Opposing that amounts to simply insisting we change our practices to what you want until we reach consensus to return to our traditional practice. Texugo (talk) 14:36, 26 May 2013 (UTC)

Commons is an image repository, as you say, it is not structured to make it a particularly useful place to look at images related to a specific topic. Also there is a difference between a status quo and a policy. A status quo can be as flexible as it needs to be, whereas a policy on this site is an extremely difficult thing to change. I am not convinced that making this particular practice compulsory will further any of our guiding principles or core content policies. • • • Peter (Southwood) ^(talk): 15:22, 26 May 2013 (UTC)

Peter's last wording above is just about as flexible as our practice has ever been on the topic. If the policy page continues to say nothing on the topic, then we have to repeat this conversation every time someone uses a gallery for any reason, and I'm afraid they will start proliferating, ceding the status quo advantage to the pro-gallery side simply because we, despite years of intentionally avoiding galleries, never wrote it down. Like the left-alignment discussion above, I don't think it is fair to disregard our long-standing practice and give the implicit advantage to the proponents of change based on the simple technicality that we never got around to writing our established practice down on the policy page. Texugo (talk) 18:17, 26 May 2013 (UTC)

I don't like galleries very much myself, mainly for bandwidth reasons. They are a poor option, for most of the resans Texugo states above, but until we have a better way of dealing with the occasional requirement for a group of images I don't think they should be banned. I do favour the use of an auxiliary gallery subpage where it would improve the article, and I favour having such subpages on WV rather than on commons when they are specific to a WV article. On commons we have less control over the contents than on WV, and we also don't have the complicating issue of in-line links to a sister project to contend with. This is largely because that is the best option I can think of at present, If technology allows a better solution, I would like to know about it.

As I see it, we need a way to provide useful information which is more conveniently presented as images in such a way that it does not adversely impact on low bandwith or mobile phone users, or unduly interrupt and break up the article text. Having a choice of image size so that they are big enough to be useful would also help.

It would be really nice to be able to click on a link at the appropriate place in the article, that indicates that you will be opening a high bandwidth section, and roughly what the contents will be, which opens as a pop-up or new tab, so you can go straight back to where you were in the article after looking at it. I don't know if or how this can be done, but would not be surprised if a template could be written for the purpose. • • • Peter (Southwood) ^(talk): 08:22, 27 May 2013 (UTC)

I am not entirely in disagreement with you, but I think proposals and discussion of any possible changes to practice should remain separate from what should have been a simpler issue of making the policy reflect the established practice. Does Peter's wording exclude any existing uses of galleries which you think are valid under current practice? Texugo (talk) 11:59, 27 May 2013 (UTC)

I can live with his version of 18th January. • • • Peter (Southwood) ^(talk): 07:31, 28 May 2013 (UTC)

Guidelines for "minimal use" of photos

Now that I've read it, I understand the argument for minimal use - that there are situations in which a lot of big files will slow download speeds for articles to a standstill. But including some good photos is a really nice thing. So do any of you have rough criteria you go by on ratios between lines or screens of text and photos? What about on size of thumbnails? I've been acting generally on the basis of how big a thumb needs to be to be sufficiently visible, but if anything, I may tend to err on the side of more good photos, rather than fewer. I think it would be great if every destination article of a place of beauty had at least one photo in it. Ikan Kekek (talk) 20:19, 18 January 2013 (UTC)

For me, the guideline just means don't use huge images (if you can avoid it—see Oceania#Regions), don't use galleries, and don't use thousands of little thumbs. In terms of spacing, I tend to think, more or less, anyone reading a shorter article (Washington, D.C./Anacostia) on a wide screen should be able to see an image at any given time while scrolling. With a longer article, that may make less sense (United States of America). Washington, D.C./Shaw is a good example for a medium-sized article. Really short articles can get a little crammed with images, but that's OK since they're small, and you need to use what space you have to illustrate. --Peter ^Talk 21:11, 18 January 2013 (UTC)

Sizing of images

Wondering about greater consistency in image sizing.

• Within the MediaWiki software we can set the usually default image size to 300px and people who do not like the size can alter under preferences.
• All we need to do is set most images sizes to default. One can also set image sizes to a factor of default.

This is nice for people with slow connections as they can set the size to small and thus view them easier. Travel Doc James (talk · contribs · email) 02:29, 19 January 2013 (UTC)

I'm finding 300px to usually be too small for decent visibility, but it really depends on what's being depicted and how. Setting a default might be nice, providing it is easy to override the default. Ikan Kekek (talk) 02:39, 19 January 2013 (UTC)

The width setting doesn't take into account the size of the image. A tall image at 300px could be way to big; a wide image way to small. --Peter ^Talk 04:40, 19 January 2013 (UTC)

Would it be possible to have, say, 3 default thumbnail sizes, called landscape, portrait and panorama? • • • Peter (Southwood) ^(talk): 14:35, 10 February 2013 (UTC)

What sizes do you have in mind for defaults, and how easy would it be to custom edit them for individual photos? Ikan Kekek (talk) 14:57, 10 February 2013 (UTC)

We could, but within each category there is still going to be plenty of variation in dimensions. Then there is also the question of the destination. If there's a pressing need to add a bunch of images, it would be better to shrink them. If there are only two high quality photos of a place, then it would be better to enlarge them. If the images are simply fantastic, better to enlarge them to show them off in the article. We already have some basic guidelines, so why try to restrict our own editorial decisions? Are we having a problem with this that I'm unaware of? --Peter ^Talk 15:59, 10 February 2013 (UTC)

So that users can have the option to choose what size to display the images at (especially if they are paying high mobile roaming charges or if they are limited to very poor 56k speeds in third world countries, etc) rather than have those "editorial decisions" foisted on them by ignorant editors.

I know that, if one has registered an account, one can set one's Preferences to show thumbnails (under the "Appearance" tab) to this range of sizes: 120px, 150px, 180px, 200px, 220px, 250px, 280px or 300px. That is just one reason why - unless they have a truly exceptional reason - editors should use thumbnails without pre-determined pixel width settings. (Anyone that wishes to see larger sizes, can just click on the bottom right corner to enlarge them right up to the maximum available native size.) -- Alice^✉ 23:06, 11 February 2013 (UTC)

Another reason is that readers use devices with various resolutions. Our current default thumbnail width (220px) seems too small on my laptop, but about right on my iPad (held horizontally). What I'd really like is an option in the preferences for making thumbnails default to a certain fraction of the window or screen width. Failing that, I think we should stop forcing images to appear a fixed size (except when really necessary, e.g. for most maps, or in galleries), and increase the default thumbnail width to 300px. --Avenue (talk) 00:07, 12 February 2013 (UTC)

I approve of setting a larger default thumb size than MediaWiki out of the box dose, say 300px, as travel images should be presented large enough to enjoy. If we set the default thumbnail size to 300px, we should also change the _user preference options_ to a range above and below that, so that the new default, say 300px, remains in the _middle_ of the range and users could choose smaller or larger. The relevant variable in LocalSettings.php on the server in which to set this range of thumnail size options is, I think, $wgThumbLimits. (And see also mw:Manual:FAQ#How_do_I_change_default_user_preferences.3F and mw:Manual:$wgDefaultUserOptions.) We could for example change this:

$wgThumbLimits = array(
        120,
        150,
        180,
        200,
        250,
        300
);

to this:

$wgThumbLimits = array(
        200,
        300,
        350,
        400,
        450,
        500
);

--Rogerhc (talk) 06:41, 19 February 2013 (UTC)

That limited range of defaults, biassed towards the large end, would negate one of the main reason for having the registered user facility for setting a default thumb size! Folks using third world connection speeds absolutely need the ability to set a much lower default size than you propose, Rogerhc.

If there is only a range of seven available (as at present) I would, therefore, propose:

$wgThumbLimits = array(
        120,
        150,
        200,
        250,
        300,
        400,
        500
);

If a larger range is available, then this:

$wgThumbLimits = array(
        120,
        150,
        180,
        200,
        220,
        250,
        300,
        350,
        400,
        450,
        500
);

-- Alice^✉ 20:25, 19 February 2013 (UTC)

Good point. Something like that would do it. The default could be set larger than it is on Wikipedia, with user preferences offering larger and smaller choices. --Rogerhc (talk) 04:55, 20 February 2013 (UTC)

Image sized as factor of default

I know that, if one has registered an account, one can set one's Preferences to show thumbnails (under the "Appearance" tab) to this range of sizes: 120px, 150px, 180px, 200px, 220px, 250px, 280px or 300px. That is just one reason why - unless they have a truly exceptional reason - editors should use thumbnails without pre-determined pixel width settings. (Anyone that wishes to see larger sizes, can just click on the bottom right corner to enlarge them right up to the maximum available native size.) What is the syntax, please, for setting thumbnail image sizes to be a factor of the default selected by the registered user? -- Alice^✉ 23:06, 11 February 2013 (UTC)

Specify the size component as "upright=factor". (This only works if "thumb" is also specified - see the English Wikipedia documentation for details.) By the way, just specifying "upright" without the factor argument uses a default value of 0.75, which is a sensible default for images in portrait orientation. --Avenue (talk) 23:53, 11 February 2013 (UTC)

Thanks for your rapid and educational response, Avenue! What a pity there would be squeals if we added this as an inline link to the relevant Wikipedia article in our image "how-to" pages. -- Alice^✉ 00:19, 12 February 2013 (UTC)

Inline links should be OK on project and talk pages, just not in mainspace articles. • • • Peter (Southwood) ^(talk): 08:59, 19 February 2013 (UTC)

That's very interesting and useful to know, Peter. Is that clearly stated on a policy page anywhere? It's not that I do not believe you - just that I wish to have my ammunition all arranged before I gird up my loins and try and edit the policy page again... -- Alice^✉ 09:05, 19 February 2013 (UTC)

The rules for links refer to articles. Non-article pages have much less constraint. Generally if an edit complies with the Guiding principles, and does not contravene the other policies, it is OK. There is no rule that one may not use inline links on non-mainspace pages, therefore, providing they don't go against the guiding principles (and a few other policies like spamming, edit warring, threats etc which refer to the whole project, and would refer to the content of a link rather than the presence of a link in that context), there is no reason why a useful inline link should not be used in project space or on a talk page. If anyone knows of a policy or consensus that contradicts this interpretation, please let me know, as it should then be included in the policy directory. • • • Peter (Southwood) ^(talk): 11:42, 19 February 2013 (UTC)

There is precedent for using inline links to technical pages on Wikipedia, Meta and Bugzilla. The proposed links look like they would be similar in intention. There is no point in going to great lengths to functionally duplicate a technical page on WV if a link will do the job, and WP, Meta etc tend to be kept up to date on those things, whereas we are a technical backwater. • • • Peter (Southwood) ^(talk): 11:42, 19 February 2013 (UTC)

As an example: If you need to know how to use images, Wikmarkup, templates or HTML, you go to Wikipedia or Meta, where there is a large amount of information, written, on the whole, by experts. If you want to explain these things to someone else, it is useful to link to the relevant article or section. This is not appropriate in a travel guide article, but if it is in a discussion of how to do something on a talk page, or a description of how it should be done on a project page, it would be perfectly appropriate to provide the link where it is most useful. • • • Peter (Southwood) ^(talk): 11:58, 19 February 2013 (UTC)

You're a Star, Peter! you've explained that utilitarian stance in such a lucid, comprehensive and rational way that nobody could fail to be persuaded - even my usual antagonists (I hope...)! -- Alice^✉ 20:00, 19 February 2013 (UTC)

As I feared, an admin (intent on "defending his patch") has now carelessly abused his special revert tools to (accidentally?) remove the relevant advice on how to size images by a factor of the default thumbnail size set by a registered user. -- Alice^✉ 01:37, 21 February 2013 (UTC)

I support Peter's reversion, as what you added amounts to a policy change for which there is no consensus. Nowhere has policy ever said that the reason thumbnails are suggested is so that the user can choose their own size in preferences.The reason thumbnails are suggested is so that all images have the same kind of frame and caption. We have, in policy and in practice, always been free to specify different sizes, with reasonable limits suggested on this page. This whole "must be a thumb so people can change the default size" thing is purely your own invention, hence should not be added to the policy page unless there is clear consensus.Texugo (talk) 02:00, 21 February 2013 (UTC)

An unexplained reversion, with an automatic edit summary and marked as a minor edit, could be seen as objectionable. I see Peter F. explained his reversion to Alice elsewhere, though.

On the substantive issue, while we should be able to specify different image sizes when necessary, I do think our policy and help pages should discourage editors from forcing readers to view images at a particular size without good reason. Why wouldn't we want to give travellers the opportunity to choose the image size that is most useful to them, e.g. for their current device or internet connection? It's accepted as good practice on other projects, and I don't see why Wikivoyage's readers should be given any less consideration. If our policies and help pages have been obtuse about this until now, that's all the more reason to change them. Also, where larger sized images are needed, I think we should generally encourage the use of "upright=factor" over exact sizes in pixels (as here), to allow travellers' preferences to affect those images too. --Avenue (talk) 14:21, 21 February 2013 (UTC)

Having a thumbnail type size definition has advantages for people with slow connection, as they can choose a smaller image as standard, which does not work for specified pixel sizes. A single available size is not really enough, and a larger set of standard options allows the editors to exercise some control over the appearance of the page, while giving the users control over bandwidth usage. My previous suggestion of 3 standard sizes - landscape, portrait and panorama would give this facility, though some coding may be neccessary to implement it. A fourth standard image size for maps would probably be worth having too.

To go along with this there would have to be a facility to select display size from a list as currently available for thumb. This could either be mix and match ot selection of preset combinations. The existing thumb default size could be used for landscape or be an extra. I don't know how complicated this would be to implement, so if someone knows it would be too complex, please mention this. • • • Peter (Southwood) ^(talk): 16:54, 21 February 2013 (UTC)

If going this route, we would need to change the defaults, and have defaults for different orientations (as discussed above). If I wasn't aware of this little bit in the preferences, it's fair to assume that our readers will not be too. It's a tricky issue to keep the pages looking nice for people with different resolutions, and that's something I've been pretty careful to curate in the articles I've put the most work into. It would also be very difficult to go through and remove all the sizing specifications, since virtually every single one of our thumbs uses them. --Peter ^Talk 18:42, 21 February 2013 (UTC)

Yes, and almost all the articles I work on also have size specified thumbnails, so I would also have a lot of work to sort them out, but there would be no rush. In the long term I think it would be a good solution though, if it is not too difficult to implement. I still don't know how feasible it would be...

The preferences options could be made better known by advertising them. They could probably be preset for viewing on mobile phones, or by selecting a low bandwidth access option, though I dont know how this would be done. • • • Peter (Southwood) ^(talk): 19:45, 21 February 2013 (UTC)

I'm supportive of the idea of requesting larger defaults for thumbnails, and then encouraging use of the default size or scalable factors (via the "upright" parameter) as desired by authors. This would allow greater flexibility for different devices or user preferences. However, since odds are that 95+ percent of users do not have a thumbnail size preference specified, no such changes should be implemented until there is agreement to change the default thumbnail preference sizes and we get that change implemented. -- Ryan • (talk) • 04:57, 2 March 2013 (UTC)

It's a noble goal, but I'm not sure it will work well. Maps, for instance, usually must be precisely sized to ensure readability of the thumbnails. And once we have the maps sized with absolute pixel widths, then having photos scaled relative to a user's preferences can produce unattractive discrepancies between the sizes of photos and maps. We choose the photo image widths to harmonize well with infoboxes and maps, and using relative sizes may disrupt that. LtPowers (talk) 22:01, 2 March 2013 (UTC)

I'm with Peterfitzgerald and LtPowers. I think it would have deleterious effects on the aesthetic and legibility of many of our pages, and I think the payoff in terms of users who would actually go in and mess with that setting would be absolutely negligible.Texugo (talk) 22:38, 2 March 2013 (UTC)

Isn't the point that the pages could be made to look exactly the same as they do now, but users who wanted to would have the ability to modify display to meet their personal preferences without impacting everyone else? For example, if the default thumbnail size is 300px and you want a map to display at 600px, where today you would specify "600px", with the new approach you would said "upright=2", and nothing would change aesthetically. Then if a user is browsing the site on an iPad and prefers smaller images they could change their default thumbnail size to (for example) 200px and see images take up less screen real-estate, or if someone is visually impaired they could choose a 400px default to see larger images. It would obviously take some time to slowly begin using scalablity factors instead of hard-coded pixel sizes, but the added flexibility that this approach would allow seems like a change worth seriously considering. -- Ryan • (talk) • 23:08, 2 March 2013 (UTC)

But then the map only displays at a legible resolution for users who have their thumbnail size set to 300px or higher. We also predicate certain decisions (like where to place images vertically and horizontally) on the presence or absence of other nearby images; not knowing the resolution makes that impossible. LtPowers (talk) 00:58, 3 March 2013 (UTC)

There are two things I'm not understanding:

1. What do you feel this proposal changes for the default user (I don't think anything, but maybe I'm missing something)?
2. Why this proposal wouldn't be a huge improvement for those users who have a reason for using images sized diffrently from the default.

To be clear: the vast majority of users will use the default, and we will continue to optimize pages for that default exactly as we do today, only instead of saying "450px" we would recommend using "upright=1.5x". As to the "legible resolution" argument, legibility is very, very dependent on the resolution of the user's screen and the user's eyesight. Using a 800x600 screen resolution will mean that a 400px image is enormous, whereas on a 1800x1440 screen it is teeny, so users of the lower resolution might want smaller images, while users of higher resolution may want larger images, and having an option to change image sizes will improve legibility in both cases. To your other point, no matter how careful we are with layout, vastly different screen resolutions cause all sorts of layout issues no matter how carefully an article is laid out. My argument for making this change is that if we implement this proposal, nothing changes for most users: we would still be optimizing image sizes to look good for the default thumbnail size that will be used by the vast majority of users (exactly as we do today, only using scaling factors), and all that this proposal would change is that we would provide an option for those users who have a reason for using something other than the default to do so. Finally, in the rare cases where we really, really do want an image to display at exactly 600px we could still do so, but that would be the exception, and in most cases we would just specify that image to scale at 2x normal (upright=2). -- Ryan • (talk) • 05:00, 3 March 2013 (UTC)

I don't think it's you that's missing anything, Ryan, and my proposed wording at Wikivoyage_talk:Image_policy#Thumb_alignment above makes it clear that if editors have a good reason to change the default details then they can still exercise their editorial judgement.

As to the print argument (which is a valid, if relatively minor, concern), it should not be beyond the wit of man to devise "print only templates" that would force the exact details (including pixel width, location and alignment of images and suppression of in-line links to sister projects in print versions) that an editor desires. -- Alice^✉ 05:54, 3 March 2013 (UTC)

My only issue here would be that I think the default image pixel size is overall too small. So, I think we should try and change the default in the MediaWiki configuration. Travel photos should be bigger than encylopedic photos in my view. If we use relative sizing, we limit our ability to make this change. If we're determined never to increase our default image size, I see no other harm in this proposal. --Inas (talk) 22:01, 3 March 2013 (UTC)

I agree the default size of 220px is too small, and that it should be increased. I don't understand why this would be limited by a decision to use relative sizing. Our current practice of forcing specific image sizes, on the other hand, makes it difficult for us to increase image sizes globally if desired. --Avenue (talk) 22:25, 3 March 2013 (UTC)

Firstly, I think that 90% issue in the image sizing is that 220px is to small in most usecases. So, mostly people increase this to 300px, etc, where it is more usable. If we change the default image size (which we should) to 300px, then no harm done. However, if we use relative image sizing, and then we make this change, out 1.5x relative size is going to grow disproportionately large. So, I think we should firstly try and get a consensus to lift the default image size. I think most of this issue will go away. Following that, we discourage image resizing of normal photos. We use px sizing for maps, where resolution make sense, and use relative sizing (sparingly for everything else). Certainly we should consider the issue of default image size before we even consider relative sizing. --Inas (talk) 22:09, 4 March 2013 (UTC)

I think it would indeed be helpful to resolve to increase the default image size to 300px and also to publicise that registered users can make a selection in their preferences; we should also resolve to implement this increased range of defaults for registered users to select in their preferences:

$wgThumbLimits = array(
        120,
        150,
        180,
        200,
        220,
        250,
        300,
        350,
        400,
        450,
        500
);

since there seems to have been no opposition whatever to this in the main section above, is there a bureaucrat reading this discussion that can now make the request to the WMF's technical team? -- Alice^✉ 22:53, 4 March 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

Bureaucrat status has nothing to do with this. In any rate, I don't think we're ready for a tech request, since we haven't defined defaults as they would relate to differently composed images (wider, taller, etc.). --Peter ^Talk 23:19, 4 March 2013 (UTC)

I'm afraid you're rather confused, User:Peterfitzgerald. There is only one default thumbnail size that can be set globally for non-logged on users and only one default thumbnail size that the user can change in their preferences (together with an "Image size limit"). Our proposal is to increase both that one default size and the range that the user can select from in their preferences, if they choose to do so. The net effect in most cases would probably be to accede to your personal preferences to display larger images. -- Alice^✉ 23:29, 4 March 2013 (UTC)

I agree with Alice. Let's do this now. --Rogerhc (talk) 22:06, 14 April 2013 (UTC)

Panorama pictures

Swept in from the pub

Hi guys! I've seen this nice panorama feature in German wikivoyage: Is there a way how I can do the same with some simple template in English wikivoyage? Ml31415^✉ (talk) 21:25, 8 February 2013 (UTC)

{{de:vorlage:panorama}} appears to be a version of Wikipedia's wide image {{w:template:panorama}}. I'm not sure if there are mediawiki:common.css changes that must be made before creating {{panorama}}. K7L (talk) 01:16, 9 February 2013 (UTC)

Thanks for your hint! I translated the template and adjusted the magnify icon. First proud use case: Nha Trang Ml31415^✉ (talk) 03:55, 9 February 2013 (UTC)

It should be possible to print out Wikivoyage on paper. If an image is too wide, then it might be impossible to include the whole image on the same paper. --Stefan2 (talk) 21:32, 16 February 2013 (UTC)

Should we put Template:Panorama into Category:Exclude in print? LtPowers (talk) 03:57, 17 February 2013 (UTC)

I don't like how huge, center-aligned panoramas look in Wikivoyage articles (see the end of the "See" section here and here), but of course when they're thumbnails at default size, they're tiny. Should we officially discourage the use of panoramas outside of pagebanners and remove or alter this language, which is in Wikivoyage:Image policy#Image alignment?

For example, images that are much wider than they are tall (e.g., panorama photos, or the occasional map) should usually be centered. Ikan Kekek (talk) 08:36, 25 November 2019 (UTC)

Discourage, but not prohibit. I don't like the panoramas in the two examples above. On the other hand, the captioned panoramas in Chicago skyline guide are good, but are 800px wide, which might be a good width limit. AlasdairW (talk) 22:29, 25 November 2019 (UTC)

I agree with you. In a skyline guide, the use of a panorama like that is useful and appropriate. So how about this?

Panorama pictures and maps may be centered, if appropriate, but do not use panorama photos unless they are clearly important for the reader, such as in guides to a city's skyline. Ikan Kekek (talk) 00:10, 26 November 2019 (UTC)

Proposal to change default thumbnail size

Today: The discussion above is getting convoluted so I'm breaking this proposal into a separate thread. Currently the default thumbnail size appears to be 220px, and the available user preference options for default thumbnail size are 120px, 150px, 180px, 200px, 220px, 250px and 300px.

Proposal: Based on threads above:

1. Our default thumbnail size should be 300px
2. The seven available user preference options for thumbnails should be 120px, 150px, 200px, 250px, 300px, 400px, and 500px.

See mw:$wgThumbLimits, mw:Manual:FAQ#How_do_I_change_default_user_preferences.3F and mw:Manual:$wgDefaultUserOptions. for more information. Comments? Support? Opposition? -- Ryan • (talk) • 23:55, 4 March 2013 (UTC)

• Support for the reasons I outlined earlier to give more consideration to our readers and more flexibility for editors. -- Alice^✉ 00:00, 5 March 2013 (UTC)
• Agree. This will reduce the incentive to change the sizing on every single image. --Inas (talk) 00:32, 5 March 2013 (UTC)
• I don't know that we need both 120 and 150. 350 is commonly used and seems like it would be a good option. LtPowers (talk) 01:13, 5 March 2013 (UTC)
• Support #1 at least. 300px is a reasonable default thumbnail size for the desktop site. I don't have a strong opinion about the user options, as long as they range from at least 150px to 500px. --Avenue (talk) 01:14, 6 March 2013 (UTC)

• Question Why are you restricting the pick list to only seven? Do you think it is not technically possible to have a choice of ten thumbnail widths of 150px, 180px, 200px, 220px, 250px, 300px, 350px, 400px, 450px and 500px in that pick list? (For most users, they would only set their preference once, but some readers might want to change their preferences as often as they changed from using a big desktop monitor to a tiny tablet and back again.) -- Alice^✉ 02:49, 5 March 2013 (UTC)

Let's not let this discussion drift too wide. Can we split into three parts. Firstly, can we agree the default pixel size. Then can we agree to use relative sizes except for maps and other images where exact pixels are required. Then can we discuss expanding the available list of preferences.

I see this as being the correct order to deal with the issues. The first needs to be dealt with before the second, by its nature. The last one if of lesser significance, since if only affects the relatively small number of people who change their default preference. --Inas (talk) 02:17, 6 March 2013 (UTC)

I thought it would be easier to combine the default thumbnail size and the proposed change to thumbnail size options into a single bugzilla request since it affects the same configuration, but am happy to split those into separate efforts if desired. -- Ryan • (talk) • 03:06, 6 March 2013 (UTC)

I agree. I just trying to order the discussion, rather than the submit multiple bugzilla requests. There really is no urgency here at all, we're change a long-standing policy, and we may even get some pushback from tech. --Inas (talk) 03:55, 6 March 2013 (UTC)

• Comment: This subsection has a bipartite specific proposal. It is not (and should not, in my view) be concerned with whether editors are either obliged to implement (or forbidden from implementing) specific switches in the Wikimedia image syntax when making edits.

I am perfectly happy to let the first part stand stet: Our default thumbnail size should be 300px

In this situation where I have had no answer to my question of "Do you think it is not technically possible to have a choice of ten thumbnail widths of 150px, 180px, 200px, 220px, 250px, 300px, 350px, 400px, 450px and 500px in that pick list?" I would like an immediate change to the second part so that instead of reading "The seven available user preference options for thumbnails should be 120px, 150px, 200px, 250px, 300px, 400px, and 500px." it instead reads: "We request WMF technicians to allow a pick list of ten thumbnail widths of 120px, 150px, 180px, 220px, 260px, 300px, 350px, 400px, 450px and 500px in user preferences and, if that is disallowed, change instead to 120px, 150px, 200px, 250px, 300px, 400px, and 500px".

This change would, I hope, allow LtPowers and others to give their support to these two narrow and precise proposals. I hope that there is nobody out there opposed to allowing a wider range of default thumbnail sizes for registered readers to pick from in their preferences. -- Alice^✉ 06:47, 6 March 2013 (UTC)

I'm certainly happy with that. --Inas (talk) 07:38, 6 March 2013 (UTC)

Just to understand completely: These would be defaults and could be manually deviated from in exceptional cases, correct? Because I've noticed some panorama pics set at 600px which didn't take up the entire page and looked good. Ikan Kekek (talk) 08:25, 6 March 2013 (UTC)

May I reiterate that, personally, I would never seek to dictate to either readers or editors what size images in our articles should display at. Hence my very careful wording here. This subsection has two very specific (and restricted) proposals. It is not (and should not, in my view) be concerned with whether editors are either obliged to implement (or forbidden from implementing) specific switches in the Wikimedia image syntax when making edits but merely about the default display size of thumbnails that have no specific size set and the reader is not logged on and (secondly) the range (or choice) of preferences that a registered reader can pick from to change that "default" default thumbnail size. Whatever is decided here has no direct bearing whatever on the question of whether it is a good, bad or indifferent idea whether to set specific image sizes either in terms of absolute pixels (px) or as a factor of those defaults!

PS: Panoramas can be problematic for narrow screens; that's partly why I have been recently experimenting with a template Template:wide image to display them with a caption, a restricted image width (and, consequently, height) but with a horizontal scrollbar and a "click-to-enlarge-icon in the lower right corner here: http://en.wikivoyage.org/wiki/User:Alice/Kitchen/SI -- Alice^✉ 08:43, 6 March 2013 (UTC)

• Support. Add larger size choices, eg 400px, 500px and 600px, to let our travel photos blossom on new and larger high resolution screens. We could simply add these three choices to the current seven choices that currently top out at 300px, and set a larger default of, say, 300px. I see no reason why 10 choices would cause any trouble at all. :-) Rogerhc (talk) 23:15, 15 March 2013 (UTC)
• Support. Seems like we'll all be happy with a larger image size. Has there been any request submitted though? -- Torty3 (talk) 03:25, 21 March 2013 (UTC)

Are we dead set on 300px as default? I would recommend a slightly smaller default, otherwise the formatting for a lot of short articles that are well illustrated will get messed up. Using 270px would prevent that problem from occurring for display resolutions under 1400. If I sound overly specific, chalk it up to the fact that I've patrolled thousands of articles here over the years ;) --Peter ^Talk 21:51, 21 March 2013 (UTC)

The difference between 270 and 300 is small. If it helps prevent a big problem, by all means make it 270 default. • • • Peter (Southwood) ^(talk): 06:21, 22 March 2013 (UTC)

• Support - (270 is fine, if that makes such a difference.) I'm really wondering how many of our visitors actually log on from such very slow connections. I'm not thát worried about that group, because larger images have limited effect on usability of the site. Most images are illustrative, if they load slowly it doesn't mean you can't use the rest of the article. (Text is loaded first on Wikimedia projects, right?). I also wonder how many people actually change their settings for images (I never have, guess I should as I always find the images too small.) Including large selection seizes for new high resolution screens seems smart though. JuliasTravels (talk) 15:42, 5 April 2013 (UTC)

• My concern re:270 v 300 is that images will get squeezed together if they are all displayed at 300, when currently the average px setting is 260-270. --Peter ^Talk 23:46, 6 April 2013 (UTC)

Per above, let's submit a bug request to have:

1. default en.WV image size set to 270px, and
2. range of user preference options set to 120px, 150px, 180px, 220px, 270px, 300px, 350px, 400px, 450px and 500px.

Please add your support (or provide reasons if you object) below. --Rogerhc (talk) 00:27, 15 April 2013 (UTC)

• Support. Default at 270, per Peter's last two comments above, and expanded user preference range per above. --Rogerhc (talk) 00:46, 15 April 2013 (UTC)

• Support for the reasons I outlined earlier to give more consideration to our readers and more flexibility for editors and also reduce server and editor work. -- Alice^✉ 04:54, 16 April 2013 (UTC)

• Support as per the above proposal. This should greatly improve our user experience. --Nick (talk) 18:07, 16 April 2013 (UTC)

Bug request #47332 filed April 17, 2013. --Rogerhc (talk) 19:41, 17 April 2013 (UTC)

Bug rejected April 17 for server load and storage reasons:

(Tomasz W. Kozlowski quoting Antoine "hashar" Musso)--

[we don't configure] different thumbnail sizes per wiki for the following reasons:

• we keep thumbnails forever currently, the more we have the more disk

space it takes

• different sizes lower the cache hit rate which in turns cause...
• ... a CPU cost on the cluster to generate a thumbnail, varying the sizes cause more and more thumbnails generations
• whenever a file is updated, we have to purge each thumbnails ever generated.

--Rogerhc (talk) 02:45, 18 April 2013 (UTC)

As I read the above, both change requests have been rejected and there is no point in further discussion of either.

Taking that and other discussion above into account, I have gone ahead and made changes at Wikivoyage:How_to_add_an_image#Sizing. Comment solicited, probably on that article's talk page. Pashley (talk) 15:13, 23 June 2013 (UTC)

Agree with Pashley. The bug request the WMF team referenced when turning down our request makes it pretty clear they won't change the default thumbnail size for a wiki. It's too bad. -Shaundd (talk) 15:50, 23 June 2013 (UTC)

You may well both be right, but the way I read and understand the reasons for the rejection, I believe they did not consider at all whether to fulfill the first request to change the default thumbnail size (rather than vary and expand the range of user-selected preferences - they're two entirely different and separate things).For clarity, that's why I would still like to submit my proposed bug report as outlined below. -- Alice^✉ 16:02, 23 June 2013 (UTC)

I agree the bit posted above isn't clear, but the Bugzilla report (47332) for our request references a request by Hebrew WP to change their default thumbnail size (41712). The request by he:wp was turned down for performance reasons. I'm pretty sure they considered both aspects of our request and rejected both. -Shaundd (talk) 17:32, 23 June 2013 (UTC)

Pashley - until the default thumbnail size is changed I don't think it is a good idea to encourage use of multiple formats for image sizing (both "300px" and "upgright=1.3") as it is essentially the worst of both worlds - default thumbnail sizing will look too small for the majority of users who haven't specified a preference, and we'll also have a mix of hard-coded and relative image sizing. We should standardize on one format (with rare exceptions if warranted), and then use that throughout the site, rather than promoting two different formats. -- Ryan • (talk) • 17:49, 23 June 2013 (UTC)

I may not have been clear enough either here or at Wikivoyage:How_to_add_an_image#Sizing.

What I was trying to say here is that I consider further discussion of changes to thumbnail size utterly pointless. My reading is that tech staff (rightly, in my view) rejected that. End of story.

What I was trying to say on the image page is that we already "standardize on one format (with rare exceptions if warranted)", using what I have been doing in for some time. The one format is "thumb" alone, with neither relative nor absolute size specified. Any further discussion of that should go on that talk page, though. Pashley (talk) 18:05, 23 June 2013 (UTC)

Actually, since the changes to the "How to add an image" page are essentially policy changes I think this is still the right place for the discussion. Most of the star articles I looked at specify sizes for all images, and discussion above seems to indicate a preference for 270-300px (the agreement seems to be that the default of 220px is too small), so I don't think the statement that we already standardize on the "thumb" (alone) format is correct. Similarly, adding statements about fixed image sizing like "These should be used sparingly since they override any preference the user has set" is counter to what is actually done in most articles. Again, until we can either get the default thumbnail size changed, or we can agree on a single standard and then update the site to reflect that, I think we should stick to the status quo and not encourage editors to combine fixed and relative sizing. -- Ryan • (talk) • 19:05, 23 June 2013 (UTC)

I feel like I'm in wonderland again.

Shouldn't policy guide practice rather than the other way around?

What is the point of registered users setting their thumbnail width preferences if everyone is just going to override them willy-nilly?

The existing practice came about through ignorance - not through any rational discussion of connnection speeds, screen widths or data roaming costs! -- Alice^✉ 20:40, 23 June 2013 (UTC)

I've requested clarification on Bugzilla: 47332 to try to better understand why the request to change the default image size was rejected. It seems to me that if performance is a concern then that concern exists whether we change the default or whether we manually specify "thumb|270px" (or something relative) for all images, so I'd like to clarify whether or not changing the default really is out of the question or not. -- Ryan • (talk) • 16:28, 6 October 2013 (UTC)

Well done! This important issue has been swinging in the breeze, unresolved for too long. We desperately need to look better for most while preserving the option for roaming and low-bandwidth readers to see a less visually intensive version. --W. Frank^email_talk 17:07, 6 October 2013 (UTC)

Yes, the performance issue surely exists also when we would manually set all our thumbs to "thumb|270px". Now, Wikivoyage is currently small enough for the WMF tech team to hardly notice, I guess, but I'm pretty sure they would object if the enwp community or other large wikis would come up with the same plan. JuliasTravels (talk) 17:27, 6 October 2013 (UTC)

Renewed proposal to change default thumbnail size

More than 2 months have gone by with no community objections and just because the second proposal to expand the range of user preferences available has (understandably) been declined does not mean that we should not submit the first as a stand-alone proposal.

Therefore:

Per above, let's submit a bug request to have:

the default en.WV image size for unregistered users (and those registered users who have not changed their thumbnail image preferences from the default) to be set to 270px.

Please add your support (or provide reasons if you object) below.

-- Alice^✉ 12:59, 23 June 2013 (UTC)

• Support. 220px is too small for a travel guide. Even 270 is probably too small. LtPowers (talk) 02:22, 24 June 2013 (UTC)

• I think 270px is a good compromise to allow short articles to be well-illustrated, while not going so small as to make the pictures "unreadable." I usually use 270-300px for images, tending towards 270. --Peter ^Talk 06:34, 24 June 2013 (UTC)

• Oppose. As I read the above "[we don't configure] different thumbnail sizes per wiki", this has already been rejected and we should not waste energy trying to resurrect it.

Also, I do not think it is needed; thumbnails are supposed to be small. Users can always click for the big image. Editors can use "thumb|400px" or some such where needed. (My opinion here can be discounted some, though not entirely ignored. I don't work on graphics and am certainly not an expert on anything to do with visual presentation.) Pashley (talk) 13:57, 24 June 2013 (UTC)

If the images are not intelligible/beautiful in-article, that's poor design, and also we aim to have our content stand-alone (you can't click through when printed). While this request may go unfulfilled, it still is nice, I think, to demonstrate that we have a consensus for the idea. That way, if the WMF's position changes at some point (for example if a larger wiki—*ahem* en.w—decides they want a similar change), we'll be set to make the change. --Peter ^Talk 18:33, 24 June 2013 (UTC)

• Support. Images are more important for travel than for an encyclopedia. Thus we should have a larger default setting here. Travel Doc James (talk · contribs · email) 02:31, 1 August 2013 (UTC)

See also Wikivoyage_talk:How_to_add_an_image#Adding_text.3F. 23:09, 22 October 2013 (UTC)

• Oppose. 270px has never been commonly used as a thumbnail size on any project. Generating thousands of images just for use on en.wv is a waste of resources. The size should be a size that is already widely in use, such as 250px or 300px. See also this RfC on mediawiki.org. Kaldari (talk) 18:56, 31 December 2013 (UTC)

That's an interesting and relevant Rfc that you reference @Kaldari:. There was no real coherent opposition to the use of the relative image syntax using "upright" and factors of it (once it had been explained above) other than the default was too small, so without prejudice to that (the two issues are only mildly connected), I now propose that we submit as a stand-alone proposal:

Per above, let's submit a bug request to have:

the default en.WV image size for unregistered users (and those registered users who have not changed their thumbnail image preferences from the default) to be set to 300px.

Please add your support (or provide reasons if you object) below.

--118.93nzp (talk) 20:55, 31 December 2013 (UTC)

Policy for photos of businesses should be relaxed

In my opinion, the Photos of businesses policy is too harshly worded. There are many good reasons to include a photo of an individual commercial venue, including but not limited to:

• the photo being the only image from the city/district with a proper license and of decent quality
• the photo giving a better overall view of the city/district than other available photos
• the specific venue being culturally important
• the specific venue having a unique visual appearance

A better policy would be:

Prefer images of public areas or streets, rather than individual commercial venues. An image of a commercial venue could be useful if it provides more useful information for a traveller, than a written description, or another image, would do. Do not add an image of a venue only for promotion, and certainly do not display an image of an individual business in large size. A venue not being worth mentioning in text, is probably not a suitable motif for a photograph either. See Wikivoyage:Don't tout.

What do you think? /Yvwv (talk) 18:12, 25 January 2013 (UTC)

I don't see the difference. What you describe is the same policy, just written in a way that's more difficult to read. Globe-trotter (talk) 13:55, 31 January 2013 (UTC)

The previous policy said that photos of individual businesses should be deleted, with few exceptions. This policy says that photos of individual businesses should be deleted if they are promotional. /Yvwv (talk) 14:06, 31 January 2013 (UTC)

The newer wording is more nuanced and better in my opinion. Brevity is good - but not at the risk of imprecision, confusion or obfuscation. -- Alice^✉ 21:01, 31 January 2013 (UTC)

I agree with Globe-trotter—the main change that seemed clear to me was a loss of clarity. The original wording, which I've restored, makes the conditions under which we do allow photos of businesses clear. And I don't see a reason to change those conditions. --Peter ^Talk 23:18, 31 January 2013 (UTC)

A clear policy is not necessarily a good policy. If this policy was to be adopted strictly, we would need to delete several of the photos currently on Wikivoyage, many of them not added for commercial promotion. /Yvwv (talk) 22:04, 10 February 2013 (UTC)

Please point to the specific photos you have in mind and the contexts in which they are used, so that we can discuss them. Ikan Kekek (talk) 05:03, 20 February 2013 (UTC)

The issue here is with business each seeking to promote their own business by posting a photo. The policy needs to continue to give us a stick to delete these photos, without having to argue the nuances of whether they are promotional in each case. Again, coming back to Ikan Kekek's point, lets see an image that would not be allowed under the current policy that we would want to see in our articles? --Inas (talk) 22:31, 28 February 2013 (UTC)

I prefer the existing policy. In general, photos of business premises should not be used. Then we can talk about exceptions. Pashley (talk) 20:36, 24 September 2013 (UTC)

I also like the existing policy. There are plenty of other things that can be used to illustrate articles besides businesses. Kaldari (talk) 18:58, 31 December 2013 (UTC)

View on Wikipedia's city collages

Swept in from the pub

[[Image:Rostov.jpg|200px|thumb|Example of city collage for [[Rostov-on-Don]].]] I've been adding images from Wikipedia to cities the last few days (mostly remote Russian cities since they're an interest of mine). Anyway, for many larger cities Wikipedia have created a collage with important buildings and street scenes. I have always thought they would be great for Wikivoyage and that they fit into our vision of creating a more attractive looking guide but I'd like some input on this. And I feel a tiny bit bad about "stealing" them from WP! ;) --Jonte-- (talk) 00:18, 10 February 2013 (UTC)

I have no opinion, but I'll mention Wikivoyage:Image_policy#Montages as the current position.--Inas (talk) 00:31, 10 February 2013 (UTC)

There does seam to b be a lot of historic policies on this site that are putting a damper on new contributors enthusiasm. --Traveler100 (talk) 07:11, 10 February 2013 (UTC)

Perhaps it's time for some sort of review in order to make it clear just what Wikivoyage's values are and what sort of 'spirit' we're aiming for? I'm quite a new user and must confess I don't have an encyclopaedic knowledge of Wikivoyage's guidelines. Given the fact that at present we're looking at a Main Page consisting almost wholly of images, I don't think that montages would be particularly damaging; in fact, you could say they provide particularly good value in terms of space used. However, I would say that taking them straight from Wikipedia is not a good idea. As (see above and below) we attempt to insert more links between that site and this one, users will not want to see what, at first glance, looks like a page they have just left.

Personally, I think that travel guides have to look a bit 'glossy' because travel is (in the majority of cases) an aspirational thing. In order to retain the reader's interest and to supplement the text I personally feel that images are very important. --Nicholasjf21 (talk) 13:05, 10 February 2013 (UTC)

It's probably neatest if we discuss the policy at Wikivoyage talk:Image policy. I have some views, but I'll discuss them there. Please join me; it's important for Wikivoyage to be flexible, as long as the change serves the traveler. Ikan Kekek (talk) 13:52, 10 February 2013 (UTC)

Discussion started at Wikivoyage_talk:Image_policy#Montages. Please participate there. Ikan Kekek (talk) 14:07, 10 February 2013 (UTC)

(edit conflict) First and always: The traveller comes first, then see Goals and non-goals. New goals and non-goals can be added by consensus, removing either a goal or a non-goal would be theoretically possible, bur likely to be extremely contentious. The rest is commentary. If you can show that a change is in the spirit of a goal and not a non-goal, it is likely to get some support. Details of how to do it are another matter, and there is considerable inertia to be overcome to change something like formatting and layout, as we try to keep article style moderately consistent, and changes make for a lot of work to update the whole site. • • • Peter (Southwood) ^(talk): 14:16, 10 February 2013 (UTC)

Parallel discussion on this page (not swept)

Wikivoyage's policy on Montages is under discussion in the Travellers' pub right now. I suggested it would be neatest to continue the discussion here. Current policy reads as follows:

"Wikivoyage does not use montages, or really any type of image other than maps or simple photography. Montages are problematic in particular for a travel guide, because their aesthetic reminds of a travel brochure, or some other promotional, rather than informational, material."

I don't agree that montages are problematic because they look promotional. I have another problem with them: Each of the photos in a collage such as the one pictured here is tiny, too small to view well. Whether that's effectively promotional, I doubt, but it is not effectively informational, in my opinion.

But let's please discuss this further. I don't think that "because their aesthetic reminds of a travel brochure" is by itself a good reason to prohibit them, though I may be open to persuasion on this.

Are we not promoting travel? Promoting to some extent each destination we have an article for? I don't have a problem with a montage per se as long as it serves a useful purpose better than the separate images would. Perhaps this should be the criterion - does a montage do a better job than individual images? • • • Peter (Southwood) ^(talk): 14:22, 10 February 2013 (UTC)

There may be special purposes for which a montage is better, but in general, I think they are too cluttered, lacking in detail, require a lot of work to make, and are not very flexible for editing. However, for some purposes thay may work very well, better than a group of images or single image, and then we should use them. The montage will have to be high resolution and of very good quality to be worth using, and it may be difficult to convince enough people of its superiority to other options. • • • Peter (Southwood) ^(talk): 14:30, 10 February 2013 (UTC)

I think for an article in its early stages with little text then a single montage image on the page make sense. Images should not outweigh textual information but should awaken people interest to the location. However as an article grows in size towards a good feature article then single location/subject images should be added. --Traveler100 (talk) 14:36, 10 February 2013 (UTC)

I agree with Traveler100 here. I think that montages can be useful in certain situations - I'm not sure a blanket ban on them is necessary. For articles which only have a couple of general images, a montage could be useful to define the page, however as the page grows in detail, individual images will come to the fore. There are issues with sizing, so in the long term, separate pictures are preferable. I don't think that montages particularly scream 'Thomas Cook' to me and in fact I'd suggest that they help to 'share excitement' to the reader. One caveat: I don't think that we should use the Wikipedia montages if possible, as we do not want to seem a clone of that site. --Nicholasjf21 (talk) 14:51, 10 February 2013 (UTC)

We should not copy existing montages from Wikipedia. Wikivoyage (as well as any other wiki) is too often confused with Wikipedia. We need some level of distinction.

Otherwise, I am not against montages that convey the nature of the city and its main, most important attractions. The picture designed for Rostov-on-Don is a sublime example of the opposite. In my opinion, it should not appear in a travel guide. --Alexander (talk) 15:07, 10 February 2013 (UTC)

I was the one who started the discussion at the Travellers' pub. To me, apart from the pure facutal information, one of Wikivoyage's goals should be to entice people about travel and destinations, not by "selling" but more as a way to broaden the horizon of travellers'. After all there's voyage in Wikivoyage. Creating a quick overlook of what a destination offers is one way to do this. I see a use of montages as an lead image to a destination, in the same way we quite often use a panorama or an image of a iconic landmark. What can be problematic however is that we miss out important aspects of a destination. For example, the montages on WP are made up by images of buildings. However, as we all know a city is much more then just a collection of buildings. How do we for example show the jazz culture of New Orleans in an image/montage? I am very much in favour of using images and multimedia to entice our readers - issues with printing and low bandwith connections can be solved by technical means - so I would argue for a change in our image policy. With that said I can see a few problems that we need to sort out before hand, especially how to showcase "non-physical" aspects of a destination. --Jonte-- (talk) 15:55, 10 February 2013 (UTC)

Thanks for participating in this discussion. I support allowing montages, but I think they should be used judiciously, and only when they are the most effective way to show a set of different iconic images, to take your word. I don't think there's an important reason for a single montage to be comprehensive, though. Where it could make sense is in articles about destinations that should feature so many photos that more normal-sized thumbnails wouldn't easily fit in the allotted space. And as mentioned above, for a montage to work, the individual photos have to be of extremely high resolution, such that salient features are easily visible; otherwise, they defeat the whole purpose, which is to provide information and attract the viewer. This article under construction might benefit from some montages, though I think many of the thumbnails are too small: Diving in Barbados/Cobblers Reef. Ikan Kekek (talk) 16:07, 10 February 2013 (UTC)

I'd allow but discourage them, as they force the individual subimages into a fixed, inflexible layout which might not work optimally on a small mobile device. We should also avoid inclusion of prepared foods, hôtel rooms or products for sale so that the image does not become too blatantly promotional. K7L (talk) 19:33, 10 February 2013 (UTC)

I think montages don't really work for a travel guide. They show everything that exists in a place, so it's fine for an encyclopedia. But to me, a single iconic image of a particular landmark can really make a destination shine. Putting it together as just one of the images in a montage is less effective for making one enthusiastic about the destination. Globe-trotter (talk) 23:33, 10 February 2013 (UTC)

I dislike them in pretty much all cases. Don't like the frozen formatting, don't like the small size of each individual image, I don't like the idiosyncratic looks of montages, varying borders between the images etc. I think a lot of the proponents of montages are mostly people who feel some kind of artistic pride in how spiffy their own montage turned out. And I think montages are less informative in almost all cases. They are also very difficult to write captions for, making for very long captions half composed of phrases like "upper right" and "second from the bottom" and not leaving any room for anything but the name of the things; no room for the usual tidbits of lively writing, because that would make the caption that much longer. The alternative is to have no caption or a generic "most famous sights of" caption, which I do not find informative at all. I also think having a montage may encourage duplicate photos of things. One picture of a sight in the montage and yet another bigger one in the See section for more detail and a more informative caption. Overall, I simply don't think a montages are a very good use of real estate. Texugo (talk) 23:37, 10 February 2013 (UTC)

Great! A clear consensus that I agree with. Allow but discourage (and point out the disadvantages for 56k users on the policy page) -- Alice^✉ 23:40, 10 February 2013 (UTC)

If we use a montage we should try to make sure the source images are available. That way if we want to spread out the images as the article grows, or even rearrange the montage, we can. There is something un-wiki about having a preformatted mix of images, much like a preformatted mix of text. --Inas (talk) 00:05, 11 February 2013 (UTC)

That's an important point. We don't want to be restricted to montages if an article grows and has a lot of space for larger thumbnails of individual sights.

One point that was made above that I'd like to address is this one, but K7L:

"We should also avoid inclusion of prepared foods, hôtel rooms or products for sale so that the image does not become too blatantly promotional."

Do you mean only in montages? Because while I agree that hotel rooms normally should not be shown at all, prepared foods and products for sale can be iconic. Some good examples: In the Kota Bharu article, I inserted a thumbnail of a photo of wau bulan (a type of traditional kite) for sale. Kota Bharu is famous for these kites. Similarly, the Naples article would be impoverished by the loss of a thumbnail of la vera pizza napoletana, though the photo should probably be larger and I will now delete Wikipedia links I'm seeing in that article... Ikan Kekek (talk) 02:57, 11 February 2013 (UTC)

Yuck! Still can't stand montages, per Texugo reasonings and more. Don't see any added benefit at all, they are nearly always tacky – cacahuate ^talk 03:03, 11 February 2013 (UTC)

Should we discuss galleries here, too, or start a separate thread about them? I usually dislike them, too, and for the same reason I have a problem with montages: Because the thumbnails tend to be too small to get a good look at the images. There may be exceptions, though, where the images are clear enough and the number of important images to show on a page is too great to easily show them as separate 300px or even 200px thumbnails. On the other hand, if we completely nix galleries, what do we do with an article like Diving in Barbados/Cobblers Reef? Ikan Kekek (talk) 03:31, 11 February 2013 (UTC)

Peter started a discussion about galleries a few weeks ago: #Galleries. -- Ryan • (talk) • 03:45, 11 February 2013 (UTC)

I'm also not a fan of montages. Having a few single photos of interesting places/things is much more effective in getting my imagination going about a place than a montage full of pictures. In many cases, the montages actually make me feel more like all the cities are the same. They seem to diminish the intrigue of all the pictures when they're all mashed together. ChubbyWimbus (talk) 13:22, 14 February 2013 (UTC)

Please keep any discussion of montages and galleries seperate as they are very different. • • • Peter (Southwood) ^(talk): 14:56, 14 February 2013 (UTC)

If we had all the source images, I'm sure Southampton would be better with those images spread out down the page. --Inas (talk) 00:16, 15 February 2013 (UTC)

I agree completely. Ikan Kekek (talk) 05:10, 20 February 2013 (UTC)

Yes, the Southampton article is a good example. Looking at it as it is, it just looks like a bunch of buildings mashed together. Each picture loses its luster in the montage. I lose interest before I can even be bothered to read what each image depicts. If the same pictures were spread around the article, places that are 'just buildings' in the montage would then stand out as unique places of interest. ChubbyWimbus (talk) 05:45, 20 February 2013 (UTC)

Perhaps a guideline suggesting that a montage should only be used when:

• It is clearly better for its purpose than individual images.
• It consists of a logically connected set of images that do not function correctly for the desired purpose if separated
• It is useful and shows sufficient detail at the chosen/available resolution/image size.
• Other possible additional or alternative conditions...

This should reduce use of montages to those which are actually desirable (if any). I don't like blanket bans on principle, as they go against the general philosophy of a wiki, and may conflict with our guiding principles in specific cases. • • • Peter (Southwood) ^(talk): 07:19, 20 February 2013 (UTC)

The general philosophy of a wiki is that everything is editable and derivable. So a montage without the source images is very unwiki, because I can't rearrange it, distribute the original images, use one of the images in another article, etc. I certainly support your conditions, but I also think the availability of the individual images is the dealbreaker. --Inas (talk) 22:24, 28 February 2013 (UTC)

I accept your point, Quite happy to add the requirement for availability of original images. • • • Peter (Southwood) ^(talk): 06:15, 22 March 2013 (UTC)

Audio files

I think we should consider allowing audio files for pronunciation in phrasebooks and article titles. We could put in a note that they cannot serve as a replacement for a pseudo-phoneticization, but they would be a really useful addition for online users. Thoughts? --Peter ^Talk 21:04, 28 February 2013 (UTC)

That sounds like a nice idea, and one that I think is already in use on other WMF sites. As long as we didn't remove the present phoneticization, as you say, I think this would be an excellent addition to Wikivoyage. --Nick (talk) 21:12, 28 February 2013 (UTC)

New thought: Perhaps we could record whole articles in some cases - from what I've heard audio travel guides can be popular. They might be particularly good for itineraries that are navigable on foot...? --Nick (talk) 21:41, 28 February 2013 (UTC)

That could be really cool for our itineraries! --Peter ^Talk 21:49, 28 February 2013 (UTC)

Two great ideas. The latter might contribute to road safety by keeping drivers' eyes on the road. -- Alice^✉ 22:13, 28 February 2013 (UTC)

I think need to strictly enforce that any audio must mirror the text. I don't think we're quite ready for audio only audiotours. --Inas (talk) 22:19, 28 February 2013 (UTC)

I would agree that, at least for the moment, it should be a faithful reading of the text (except where obviously impossible eg: 'as on the map...'), which would also help with accessibility. Perhaps we could consider separate 'audiotours' as a long term goal to put on the roadmap. --Nick (talk) 22:23, 28 February 2013 (UTC)

I'd be leery of pure audiotours (why not write them down), but something like The Wire Tour would be pretty cool as an mp3. I've done the itinerary with friends, but it would be hard to navigate and drive by yourself. --Peter ^Talk 22:48, 28 February 2013 (UTC)

I don't have an opinion on audio files for phrasebooks or city names, but having an audio file as a recording of an entire article strikes me as a bad idea for two reasons: first, our content changes frequently and the audio file would thus get quickly out of date. Second, if having audio versions of articles is something we want to do I think we'd be better off including a toolbar link to an online reader service, or developing that as a Mediawiki plugin. In either case, provided the audio was downloadable, we would save manual work and provide better quality content by utilizing automated tools. -- Ryan • (talk) • 22:58, 28 February 2013 (UTC)

Our best itineraries have seen little change since being "finished," and generally have fewer things that require updating. Look at these —from the time they were essentially completed, there has been very little change that would affect a traveler using an outdated audio version. An entrance fee in Chicago is the only important difference I see in those three articles, despite 3-4 years passing. To your second point—I'm not familiar with online reader services, so I'm not sure what you mean. Save us which manual work? --Peter ^Talk 01:48, 1 March 2013 (UTC)

Tools for converting text-to-speech are becoming standard parts of operating systems - Android phones now include text-to-speech, and w:Speech synthesis#Internet has other examples. Given the reality that "reading" a web page is quickly becoming a task that computers are capable of doing, it seems that if we want audio versions of pages that it would be more productive to develop a plugin or other tool that will produce automated, computer-generated versions of our guides, rather than trying to keep manually-recorded versions up-to-date. If the idea of audio versions of guides gains support then manually recording a few guides for some star itineraries that are "finished" would be a way to get things started, but if the goal is to have audio guides for a significant number of itineraries or other articles then putting the effort into developing tools to automatically generate an audio version of the latest content would make more sense to me rather than devoting significant resources to manually recording (and re-recording as guides are updated). -- Ryan • (talk) • 03:16, 1 March 2013 (UTC)

There is a tendency to avoid creating "A day/night/weekend in X" as itinerary as we already have many of these which mostly end up just overlapping the main city/region article for X. An audio tour which covers a narrow area (such as "downtown" or "old town") in ,mp3 / .ogg might be a good reason to make an exception, as the landmarks do need to run in geographical order (instead of splitting by category - see, do... - or price - or listing alphabetically). K7L (talk) 22:55, 28 February 2013 (UTC)

I think if we were to narrate articles, itineraries should be our main priority, as I think they could work well. This might be something to annex to an expedition and see where it takes us. --Nick (talk) 23:05, 28 February 2013 (UTC)

Here's a quick, un-edited idea of what a narrated itinerary might sound like. I very quickly recorded the first bit of The Wire Tour, mentioned by Peter above. I dare say my British accent doesn't really fit this subject and I'm sure some of the pronunciations are wrong, but this is the sort of thing (when done to the end of an itinerary!) I think we could achieve. PS It's quite late here, hence the pseudo-whisper! --Nick (talk) 01:20, 1 March 2013 (UTC)

The Wire Tour

Most enjoyable! And you have a very clear and evocative voice, Nick. Thanks for the terrific exemplar! -- Alice^✉ 01:42, 1 March 2013 (UTC)

Very cool! It's something of a cliche to have British accented audio narrations at tourist traps, which provides some ironic humor in this tour of such decidedly non-touristy places. But then again, two of the main characters were played by English actors affecting American accents! --Peter ^Talk 01:48, 1 March 2013 (UTC)

Haha! You're both very kind! :) --Nick (talk) 01:49, 1 March 2013 (UTC)

I think that audio files would be very useful for helping people pronounce phrasebook phrases and destinations with "odd" names. The Wire Tour illustration has opened my ears to other possibilities, but I am not entirely clear how this would work as a Wiki for most itineraries. Maybe we could come up with a way of making each sentence a separate audio file and then automatically combining them into a single file. That way an edit could be done by just re-recording a single sentence if something (opening times etc) changed. There is still the drawback of different speakers - which is a bit like have handwritten rather than typed articles.

For phrasebooks and destination names, I would suggest the following guidelines:

• Audio files must be a recording of pure speech, with no significant background sounds.
• Audio files must exactly reproduce the text that is written in the article.
• Files must in Ogg format and uploaded to Wikimedia Commons (and follow any policies there).
• Files should be less than 15 seconds long.
• Music files are expressly forbidden
• Audio files must only play when the user selects then and must not be set to autoplay when the page is loaded.
• Audio files must not be used in Buy, Eat or Sleep listings.

Some of these maybe are on the restictive side, but we need to discourage corporate jingles in hotel listings etc.AlasdairW (talk) 23:25, 6 March 2013 (UTC)

I am OK with the above guidelines, only I would limit audio files to only phrasebooks and article titles, for now at least. Like AlasdairW, I am not sure how well it would work anywhere else. Texugo (talk) 00:09, 7 March 2013 (UTC)

I don't think we're as clever as those who devised the code napoleon. The English speaking tradition has not been to say "everything is forbidden except what is explicitly licensed". Such an approach stimeys innovation and leads to wikilawyering. I don't think we need to be so prescriptive and restrictive. All we need right now at this stage of our development is "Audio and Video files must not be used in Buy, Drink, Eat or Sleep listings. Files must only play when the user selects them and must not be set to autoplay when the page is loaded". Let's trust our admins to use their own judgement and stamp on any obvious abuses - the longer the lists we make of what folks can and can't do with audio, the more difficult it will be for an admin to uphold their decision because the miscreant will just turn round and say (justifiably) "Waaaaaah, that wasn't on the list!" -- Alice^✉ 00:25, 7 March 2013 (UTC)

I think it would be wiser to wade into it more slowly, given that it is completely new territory for us. If we find it works well, we can always expand later, so I'll stick with Peter's original suggestion of phrasebooks and article titles. We may run into some issues we aren't expecting, such as how to evaluate the correctness of non-native speakers recording phrases and such -- not every second-year Chinese or French student pronounces things as accurately as they think they do, and if we are going to do this right, we need to be able to ensure that our audio clips are accurate and professional. Texugo (talk) 00:32, 7 March 2013 (UTC)

I agree that we should stick with phrasebooks and titles for the moment, however, like Alice, I also think we shouldn't be quite so prescriptive or definite about what we're not going to allow - let's stick with what we do want for the moment as otherwise, should we come round to the idea of recorded itineraries (or anything else) we'll have to fight to repeal what we previously set down. Let's just say that, for the moment, single words are the way forward and we'll leave other things for further discussion. --Nick (talk) 00:43, 7 March 2013 (UTC)

I think at the very minimum we should make it clear that we are allowing audio files for pronunciation purposes only. Texugo (talk) 01:16, 7 March 2013 (UTC)

I agree with you there - I just didn't want to see some extremely strict rules implemented on this topic just yet. --Nick (talk) 01:19, 7 March 2013 (UTC)

Are people saying we should not allow audio narrations for existing itineraries? I don't see the harm, and I'd love to have one for The Wire Tour at least, since it would help for driving. I guess I could make one for myself and not share it on the site, but what's the advantage in not sharing it? --Peter ^Talk 19:13, 7 March 2013 (UTC)

I'm not a fan of this idea yet. Too easy for it to get out of date/out of sync with the article, not editable except in full, and ogg format isn't exactly something you just throw on your ipod, and streaming audio to a mobile phone is not cheap in many countries. Texugo (talk) 19:25, 7 March 2013 (UTC)

My suggested addition to policy remains limited to: "Audio and Video files must not be used in Buy, Drink, Eat or Sleep listings. Files must only play when the user selects them and must not be set to autoplay when the page is loaded" and, if implemented, that would remove your latter two objections. User:Peterfitzgerald has already suggested that audio itineraries be limited to relatively stable and mature articles, but perhaps an audio 'rider' of "This audio may have become outdated by later changes to the text of our Wikivoyage article from the eighth of March twenty-thirteen on which this was based." could be added right at the start of each recording?

User:Peterfitzgerald: Most are not, but since AlasdairW's suggestions included a 15 second limit supported by Texugo, it would be nice if they could both specifically clarify if their attitudes have changed during the course of this discussion. -- Alice^✉ 19:36, 7 March 2013 (UTC)

The audio 'rider' that Alice has suggested sounds fair. It's simple and easy to do and if people are willing to do it, I don't see the harm. I think audio itineraries do have plenty of potential as long as they are of high quality and reflect WV's values. --Nick (talk) 20:13, 7 March 2013 (UTC)

Nope I'll stick by my comments and by Ryan's last comments above that it would be better to focus on machine reading tools than to try to keep updated recordings of things. I don't think full recordings of articles are a very wiki-like thing at all, much like the last points made in the montage discussion above. Texugo (talk) 20:15, 7 March 2013 (UTC)

It would probably be better to focus on fairly 'stable' articles when recording, but I don't think it's impossible or harmful. In fact, Wikipedia has a project reading articles that's currently on-going http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Spoken_Wikipedia and, whilst we are not Wikipedia and do not follow all its customs, I don't think we can dismiss the idea as 'un-Wiki'. --Nick (talk) 20:25, 7 March 2013 (UTC)

Sorry, I don't think the WP version is very wiki either (nor does it appear to be terribly popular). I think with respect to reading full articles, we are just looking at a huge distraction with problematic and only very marginally useful results. Texugo (talk) 20:37, 7 March 2013 (UTC)

That's sort of like saying a printout isn't very wiki. Yes, it would be a snapshot, but I don't understand why providing one would be harmful in any way. And remember, this is something being proposed only for star itineraries that are not likely to change in a meaningful way in the short term. What's the good reason to ban this? --Peter ^Talk 21:30, 7 March 2013 (UTC)

Just to clarify my objections, I don't want my concerns to be seen as advocating that we "ban" audio versions of articles, but if this is something that people want to be used on more than just a couple of article then I'd worry about having to devote resources to creating and updating audio articles and feel strongly that we should automate the process rather than doing it manually. That said, if someone wants to try this out on a select handful of articles then we should encourage a limited experiment, and we can then revisit how useful it is and whether we want to broaden the scope. -- Ryan • (talk) • 22:00, 7 March 2013 (UTC)

(edit conflict) I don't think that is quite a fair analogy. The difference is that with text, a change of any size can be made by anyone and a perfect printout can be carried away from it immediately, but to carry away updated audio after a change, the whole thing must be re-recorded. Even the WP project specifically states than any edits to audio must be done by the original reader or else the whole thing must be recorded. Anyway, given that there are only 3 star itineraries, I can`t complain too much about a test run on those, but I fail to see much real utility in this and think that our efforts would be better spent in other areas. Texugo (talk) 22:14, 7 March 2013 (UTC)

(reindent} There are three drivers I see here.

1. As part of Access Expedition I would like to see as many of our guides read in audio as possible. If the audio gets hopelessly out of date, and we have to delete it, we're no worse off then we were without any audio. As long as the people who do the audio accept that this is the case, then we're no worse off. The automated process just isn't there yet. The downside I see is spam and quality filtering being very time consuming. For that reason, I support limiting to star guides for now. Possibly each section has a separate audio file would make it easier to update, and maintain. I know that this is a marginal audience. Perhaps we could try to engage with some vision groups to see how we could actually make this useful to their needs?
2. For phrasebooks and single words that are difficult to pronounce, this is quite straightforward. It's helpful to everyone, and we should include it.
3. For itineraries that we want other people to follow, then recording is quite a different proposition. We'd want a stop the tape now and drive/walk to. I think this requires a bit more thought as to what we want to achieve here, and how we do it well. Again, limiting this to star itineraries for now should allow us to refine or dump this process. --Inas (talk) 22:28, 7 March 2013 (UTC)

It seems that this discussion died out some time ago. I have created a new discussion thread below in relation to starting this again. --Comment by Selfie City (talk about my contributions) 18:49, 20 October 2018 (UTC)

necessity is the proper yardstick; rather, the potential usefulness of a medium is the question. And it's obvious to me that 4-dimensionality (3 dimensions plus time) is neither replicable in text nor fully in photos, either. As film has existed for over 100 years, it seems strange to need to argue for its capabilities, but some thoughts that comes to mind are that it can show sculptures, buildings, performances, and street scenes effectively. None of this addresses other substantive objections to allowing videos on this site, or the good points that have been made about complications involved in potentially allowing them, but dismissing an entire medium just seems strange to me.

Texugo, I agree that there are still plenty of places where internet access is unavailable, but that's the direction we're going in, and the issue to me is not that we should make these guides useless in printed form, but that it should be OK to add more web-only content for those who have access. Newspapers do this, too. Ikan Kekek (talk) 22:48, 1 August 2013 (UTC)

I think perhaps part of LtPowers' point is that aside from showing what things look like in motion, the video should not contain any additional information that is not already in the article. If the other information is important, it should already be in text and/or images in the article. If it's not important, well then it's not important and we don't need it. Texugo (talk) 22:53, 1 August 2013 (UTC)

If that's what he means, I agree with him. Ikan Kekek (talk) 22:57, 1 August 2013 (UTC)

I too agree! For that reason, I'd probably be against commentaries in videos on here (not necessarily on YouTube though). I think the value of videos is in their illustrative, immersive quality, much like the one posted in the Pub. As I said above, I really am not saying we should abandon paper compatibility - it's a very important part of what we do and whilst iPhones might be useful tools in some parts of the world, paper rules in others. Videos would be an extra element for the online audience; much like external links, banner images and editing. --Nick ^talk 23:03, 1 August 2013 (UTC)

A few ideas for guidelines (sorry if this a bit quick!):

1. All videos must (initially) be approved centrally - this reduces the patrolling load and ensures a light stream of video content; rather than a torrent.
2. No audio except ambient noise. Silent videos are acceptable - might sound a little puritanical but this removes concerns about informative commentaries and cheesy background music/copyvios.
3. Captions should only be used to describe what is being seen: they should not give any additional information that is not in the article - all info kept within the article.
4. Videos should be of at least 360p quality - we don't want any pixellated content.
5. Videos should not focus on people - let's keep this about the destination.
6. Videos should not be longer than 3 minutes - we don't want an epic.

These are just a few opening ideas and are all open to debate. I can foresee a few cases where there would need to be exceptions to the above as well, but I'd hope that they're a starting point. Finally, what do we think of slideshows? --Nick ^talk 23:22, 1 August 2013 (UTC)

The thing I dislike about video is that they are very unwiki like. They can take a long time to review. Editing them or changing them is complex, and can't be done on the site. My idea of a wiki is someone writes a sentence, someone else adds, updates, or changes it. This isn't the case of a video tour. Once someone has done a video tour, it can only really ever be replaced by another.

However, this is quite different for a short video of something that makes more sense in motion. For example a 5 sec video of Splash Mountain may add more meaning than a still shot. And the still shot is still meaningful for those who don't or can't hit play. I think I'm agreeing with Ikan Kekek again. Video where it serves a purpose in explaining something that can't be explained in text or a still. So no tours, no commentary, but scenes that have an inherent time element, I would support. --Inas (talk) 23:25, 1 August 2013 (UTC)

A couple of thoughts on your draft guidelines, Nick: How would you suggest central approval be accomplished? Also, if we allow videos, I think it's OK if they focus on people as long as the people are shown performing or, say, eagle hunting or playing an unusual sport. I also think that Inas has given very good guidelines. Ikan Kekek (talk) 23:38, 1 August 2013 (UTC)

I would suggest launching a Video Expedition or similar to approve the videos initially: an approval time of just a few days would probably be sufficient; it would only be a temporary measure and eventually we'd wind it down: I just think we would want to avoid the sudden explosion in implementation that we saw with the page banner images. I agree that people are ok in those instances - I probably need to fix the wording on that one. I was trying to prevent people from using their family holiday videos or featuring a presenter. I also agree with everything that Inas said. :) --Nick ^talk 23:45, 1 August 2013 (UTC)

If you propose to eventually wind down the expedition, how would you suggest approval of videos afterwards? I would think that we would leave the expedition open, as with the Airport expedition, and revive discussion whenever that's useful. By the way, I think that's an excellent precedent, as the consensus on what kinds of airports merit articles and how they should be structured has made it much easier to determine which new articles should be merged or redirected. Ikan Kekek (talk) 23:54, 1 August 2013 (UTC)

I agree - the Airport expedition has worked well! I meant rather that I would wind down the tight approval process once we were a little further on. The video expedition would remain open for discussion purposes. --Nick ^talk 23:56, 1 August 2013 (UTC)

The speed at which this conversation is moving forward makes me very uncomfortable. I really doubt I and possibly LtPowers are the only ones who think this is not at all a good idea. I am quite convinced that the standards necessary are much too high for this to really get anywhere, and I am not at all willing to stick amateurish video everywhere, or anywhere. Texugo (talk) 00:12, 2 August 2013 (UTC)

I don't think anyone would disagree with you that it is a bad idea to link to or otherwise use poor-quality videos. Is the precedent on using image files that are on Commons a good or bad one, in your opinion? Ikan Kekek (talk) 00:24, 2 August 2013 (UTC)

(edit conflict) Please see my previous comment: images are one thing and just about anyone can take a pleasing photograph these days. Creating well-edited, sharp, professional-looking video, however, is quite a different endeavor, and I would be very surprised if there were even a tiny handful of videos already on commons that are both appropriate and professional enough to use here. Texugo (talk) 01:32, 2 August 2013 (UTC)

I'm with Texugo in that I don't think it's yet time to create an expedition—we need to at least have some agreement that videos are ever something we want. For that we need some examples! The video that Smallbones created is nice, but doesn't provide anything other than images, which we already allow, are printable, and much more editable/swappable (more wiki). The one use of videos that immediately jumps out to me is instructional how-to guides to using Wikivoyage. But I'm not coming up with any uses for destination guides that wouldn't be better done otherwise. So... examples, please? Lastly, is the extra load time placed on the page the same as for any old thumbnail? --Peter ^Talk 01:24, 2 August 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

I don't think an outright ban is appropriate since there will always be use cases where a video would be valuable, but at the same time I think it makes sense to write any policy on video usage very strictly since this is a wiki, and as noted above a video isn't something that lends itself well to collaboration. If a video adds value to an article that could not be matched by text or photos then this might be an experiment worth trying, but I think that if we're going to move in this direction we want to start out sparingly, following some of the guidelines that Nick has proposed. I'd also suggest a limitation similar to the following: "Videos should be used sparingly, they should only be used in cases where a photo or text would not suffice, and they should provide significant added value for the article in question. Examples of situations where a video might enhance an article include a rocket launch in the Cape Canaveral article, a hula performance in the Hawaii article (provided appropriate model releases are obtained), or a geyser eruption in the Yellowstone National Park article." -- Ryan • (talk) • 01:33, 2 August 2013 (UTC)

(edit conflict) :We effectively already have an outright ban. I would not agree with changing the currently policy to your wording unless we establish and agree upon the need for any video at all. Texugo (talk) 01:41, 2 August 2013 (UTC)

I think Peter asks an important question about load time and I don't know the answer to it. The other thing I get from his post is that it's one thing to give theoretical examples of useful videos, as you just did, but quite another to actually present a video that fulfills them. But what is the best way to issue a challenge for videographers to submit videos that might convince the doubtful that it could be worth ever allowing videos on this site, other than through an expedition? Should a challenge be issued in the Pub? Ikan Kekek (talk) 01:38, 2 August 2013 (UTC)

(edit conflict) That would be up to the people who are for the idea, I'm afraid. An expedition implies that it is already something we have decided we want to do, which we have not. And as for issuing a challenge, why would the unconvinced have any interest in issuing a challenge to encourage something they oppose in the first place? Texugo (talk) 01:47, 2 August 2013 (UTC)

Hold it, Texugo: Are you opposed to including video even if, in your opinion, it's high-quality and adds an element that can't be added any other way? I thought your objection was based mainly on the idea that most videos are amateurish. Ikan Kekek (talk) 01:52, 2 August 2013 (UTC)

To Texugo's points on video quality: Perhaps a side benefit we can engender, by adopting exacting standards for approval of video clips, is to prompt talented people to meet the challenge to do great work.

I think we've reached a point of agreement that unless the work is really good, really adds something that couldn't be added a different way, and is of value if printed as a still, it shouldn't be considered for approval. So that's the challenge we need to put out to the public, and I think the challenge should include details on what constitutes good video production. Ikan Kekek (talk) 01:43, 2 August 2013 (UTC)

I agree. We don't wants poor video. We don't want video that just duplicates content that can be expressed just as well with stills and text. However, if someone want to go ahead and demonstrate some value, then they should, and we can discuss again. We can't cut a proposal off at the knees, because of an assumption that the video that is going to be added is poor quality. Ten years ago to think that a holiday snap would have made a travel guide would be unthinkable. These days, we're taking them on a phone. Video quality is heading the same direction. --Inas (talk) 01:54, 2 August 2013 (UTC)

Video editing quality, however, is not. And no, like Peter said, I am not convinced there is any video that would add anything we truly need that could not be better covered another way. And like LtPowers said, I am unclear on what the purpose would be. Are we trying as much as possible to recreate the experience of being there? Because that is not really what a travel guide is for and seems somewhat beside our goals in the same way that encyclopedia detail in text does. Texugo (talk) 02:20, 2 August 2013 (UTC)

I seem to have caused a bit of an upset by plunging forward and saying what I would do - sorry! My suggestions are purely hypothetical at this stage: I won't be creating an expedition or adding videos to any article any time soon. What I had hoped was, that by laying out some fairly strict ground rules, some qualms about Wikivoyage becoming a repository for people's holiday videos that were recorded with a potato would be removed. Either way, I'm sorry if anybody thought I was running away with this; I was merely trying to show that this is viable and lay out how it might be carried out.

As for examples, here are a few I found on Commons. I dare say purpose-made footage would be better...

The Strokkur geyser in Iceland, video (12 seconds).

The space shuttle Endeavour launches from Cape Canaveral to the International Space Station, video (21 seconds).

Climbing the Eiffel Tower.

A parade in Kim-Il-Sung Square, Pyongyang, video (61 seconds).

'Mind the gap' on the London Underground.

User:rogerz I prefer these:

Tower Bridge

Paris

Nepal video

Budapest video

Turkishd landscape

Norway video

Israeli beach video

QueenSt. BeatrixBarths Airport

cheese market

File:SLOVENIA, PIRAN (1-6).webm

Slovenia coast

Nick ^talk 02:33, 2 August 2013 (UTC)

I would tend to keep the guide as simple as possible and not become cluttered with a ton of videos and for that matter images (guess that makes me a minimalist). I remember the Michelin and Fodor guides from way back when and they only had certain basic images, maps etc. If I am interested; I would surf the net so to speak for more information. Yet; on the other hand, they can be somewhat of an added bonus. So why not create a sub-page to a guide page that would contain galleries of photos, videos, amplified text and related web links on it. (I think that could be done tastefully - hopefully anyhow)... The main guide page could have a link to that sub-page... ps. where do I post my nude sunbathing video at Playa Sant Sebastià in Barcelona (only kidding - Cheers! - Have a great day!) Matroc (talk) 03:37, 2 August 2013 (UTC)

Thanks, Nick. The parade is not sufficiently visible, at this resolution. I like the geyser, though, and I think it's a good example that would seem to fulfill the criteria we've discussed. However, I'll be interested to see critiques by others whose standards may be more exacting than mine.

Matroc, this is the net, so why wouldn't we want to make use of its capabilities? People like photos, and using several well-chosen photos makes a destination seem more attractive. Ikan Kekek (talk) 03:40, 2 August 2013 (UTC)

Thanks for the examples. Of all of them, I'd say the geyser one fits. It makes me want to book my ticket to Iceland right now, the way that no still image would. And the still image would still look good in a static page, should you care not to click, or if you are printing. I'm not so sure of the others, they seem a bit encyclopaedic, and the corresponding still image isn't as meaningful. --Inas (talk) 03:53, 2 August 2013 (UTC)

I am firmly against allowing videos for the following reasons:

1. As has been said before, most videos people make from their travels are rubbish. And even if they aren't rubbish to one person, who will put it in (hopefully not the original author), they will be to many others. Making a really good video from a travel destination is not easy. I've got a friend who does that really well, but he has many years of cumulative experience of his team behind it, plus a large house's worth of equipment (video drones, van with steadicam etc.), and he spends a few days per a 2-minute clip.
2. It is VERY hard to set out rules that would REALLY work and be relevant. Unless there is a very firmly, precisely set video standard (i.e. what should be in the video being defined), it is all a murky area left out to subjective interpretation. And I know from my own example that if people feel strongly about something, they will defend it to no end as long as they've got a gate open. And by allowing videos, even with strict rules, we are opening the gates to people who think they have found / made the best video EVAAAAAH.
3. While I am all for more images, as a picture tells a thousand words, I do not think that videos tell enough words more than pictures for them to be merited. Some of the above examples are really unique, but, again writing clear rules that would guarantee only such images can be included and not random collections of photos set to music or somebody's exploits with a cameraphone would be close to impossible. I am quite ready to lose to marginal benefit some really unique videos could bring to WV to prevent the unavoidable wave of cheese that would come with it should the gate be opened.
4. At the very end, this is not a Nazi state, but a community. If we agree some individual videos are really great and indispensable, we can include them against the general guideline, by consensus in each article's talk page. We are not trying to build an unfallible civil law system here, so we an have a rule that forbids inserting videos, and then agree on individual exceptions rather than try to write the exceptions into the rule.

Kindest, PrinceGloria (talk) 05:27, 2 August 2013 (UTC)

I think the two first examples there, of the geyser and the shuttle launch, actually would improve the quality of our guides (provided it doesn't lead to a loading time hit for slow connections). They both show major attractions that are brief, recurring events, the impact of which is much better understood via a video (or animated graphic). I'm a little at pains as to how to frame a policy that would allow for them, but still weed out the enormous amount of potential videos that would be a less desirable redundancy of our regularly scheduled wiki content.

One thing that I think we should be clear about is that information that a traveler would need should never be added in video format, since travelers would miss out on that content in printed form and on low bandwidth connections. Speaking of which, would offline copies via mobile apps wind up downloading video files in guides? That would be another potential downside. --Peter ^Talk 06:29, 2 August 2013 (UTC)

(ec):I see no harm in developing a proposed manual of style for videos as part of a discussion of whether they may be included in the project. If acceptable and workable standards come out of it, then the concept of whether to allow them becomes a useful discussion. If we can't come up with an acceptable and workable set of standards, the point becomes moot. So why not leave the people who support the inclusion of video to propose and develop a manual of style, and those who have objections can make reasoned objections when the proposed guidelines appear to be inadequate? "Not invented here" is generally a poor argument among rational people. "Can't be done" requires supporting evidence, just like "Can be done".

I don't see where videos are in conflict with fundamental principles of this project, so if they can be shown to be useful, viable, patrollable etc. they may be proposed for consensus. Rules that forbid everything unless specifically permitted go against the concept of plunging forward, and are actually more an indication of a repressive or totalitarian regime than I would be comfortable with.

Having said that all, I don't expect a large number of videos that will be worth allowing, as the points made above about most people being unable to record and edit quality video at present are probably correct. • • • Peter (Southwood) ^(talk): 07:00, 2 August 2013 (UTC)

A couple of suggestions for a video policy:

• Proposed videos get loaded to Commons, proposed on a Video Expedition page and vetted before linking in Wikivoyage. The usual consensus process can be applied in a similar way to Star article, DOTM etc. If there are so many good videos that we become overloaded, we can come up with a different procedure. Don't hold your breath for this...
• If there is a need for more control, we could store the acceptable videos in a new namespace and only allow videos stored there to be linked from our articles. • • • Peter (Southwood) ^(talk): 07:18, 2 August 2013 (UTC)

I don't think we need an expedition. I also agree with the concerns mentioned and with the idea that very few suitable video's are to be expected. Sure, we have to set a very high standard, in order to /not/ end up with cheesy amateur video's. However, I think we should be wary of excluding video as a rule out of fear for bad proposals or for printing reasons. Not so long ago, there were equally many very poor still pictures: times change, we should think ahead. I would have no problem though with a policy stating that only professional, high-quality videos will be allowed and that those that do not live up to the standard we're after will be removed, subject to community discussion. Now about such standards, what are the general thoughts about the original video that brought up this discussion? For the record, I think it a pity to directly remove that one experimental video from the article it was posted in, while the maker started an honest discussion in the pub. We allow experimental templates to remain even on star articles for long long times without consensus if old community members place them, but a new idea like this by someone else is cut out right away.. JuliasTravels (talk) 08:23, 2 August 2013 (UTC)

[Unindent] The original video is virtually a slide show, and a good one with classical music I like. But I think it would help more readers if several of the photos were linked as still thumbnails and inserted into the article, and the rest were collectively linked to as a category in Commons on the sidebar (if they aren't already). Ikan Kekek (talk) 10:07, 2 August 2013 (UTC)

We are unlikely to get many professional videos, Professionals tend to want money for their products, by definition.

High quality will have to be defined in this context, which will not be easy. I would recommend that each proposed video be submitted for approval and only linked after community approval by consensus, as the initial procedure, until the quality standard and other conditions of inclusion have stabilized. A few proposals will accelerate the guidelines by giving real examples to work with. Non-approved videos could be unlinked without discussion, but with an explanatory edit summary. • • • Peter (Southwood) ^(talk): 09:57, 2 August 2013 (UTC)

That sounds quite reasonable. In the meantime, though, what about the geyser video? Would it be acceptable to link that, providing that it does not greatly increase the loading time for the relevant page? I gather from Texugo's previous comments that his answer would be no, because he doesn't see what useful purpose can be served by even really high-quality videos. And I would say, the idea is not to vicariously experience a place but just to get a little taste of some aspect of it in 4-d. I don't think that watching that video will make anyone think they were actually there, or cause them to be less, rather than more interested in traveling there (unless they're afraid of geysers, in which case, it may have done them a useful service, anyway). The point of a travel site is not to be a virtual reality site, but I don't see that approving very carefully selected video clips has any chance of making it one. If that ever really becomes a danger, we should deal with it then. It's not like anyone proposed starting pages with 24-hour cams webcasting from Times Square or something, and that surely would not be OK to include or link from this site. I don't want it to seem like I'm pooh-poohing concerns about video quality and relevance; I completely respect those. But I think we should be flexible enough to consider the possibility of a high-quality video adding something to the online experience of our readers. Ikan Kekek (talk) 10:18, 2 August 2013 (UTC)

OK, We have a test case.

• Where do you want to put the link?
• I looked at the clip, it is short, shows the attraction objectively, and quality looks OK to me. I don't know how it affects load time. My guess is that it doesn't load the whole clip until you click on it, in which case probably very small effect. I don't have any objections based on what I know so far. • • • Peter (Southwood) ^(talk): 10:54, 2 August 2013 (UTC)

If a consensus develops, the video could be inserted into Upcountry Árnessýsla, an outline article that also needs to have photos and ideally a customized pagebanner added, and could use some copy-editing. Ikan Kekek (talk) 11:04, 2 August 2013 (UTC)

That looks like an appropriate application. • • • Peter (Southwood) ^(talk): 11:37, 2 August 2013 (UTC)

(Indent) I'm still not convinced the videos are necessary. Are the videos supposed to be viewable right here? I'm taken to a new window asking if I want to save it. I can't watch them. ChubbyWimbus (talk) 11:31, 2 August 2013 (UTC)

I can view them right here by simply clicking on the play arrow (Chrome) if you are using IE8 you will probaply have a problem, I could never get an ogv file to play on IE8. • • • Peter (Southwood) ^(talk): 11:37, 2 August 2013 (UTC)

I'm really still against it, per PrinceGloria's point #2 above: once we allow videos, we'll have people inserting and defending all manner of crap. A strict set of criteria could help to weed out some of the more egregriously cheesy stuff, but as PrinceGloria said, it would be virtually impossible to create criteria that didn't still leave a lot of very subjective gray area for cheesy or amateurish work to ooze in. There are still too many variables, and I think the type of person that makes and uploads this type of video clip tends to be very proud and very defensive of their work, however cheesy or amateurish it may seem to others. I think it far better not to open that can of worms. In addition to all that, with regard to the geyser video, I don't actually think it is a terribly well done or well-framed video. It's too up-close and focused only on the base, and I get the impression that the frame rate is rather low. A single photo, vertically framed to show the geyser in the full height of its eruption, would give a better impression of size and surroundings. The other videos are, in addition to any other problems, too encyclopedic, as someone said, and the space shuttle program is now historical. Texugo (talk) 11:39, 2 August 2013 (UTC)

I respect your point of view. I figure that we can revisit this some years in the future, if a significant quantity of higher-quality videos warrant doing so. Ikan Kekek (talk) 12:24, 2 August 2013 (UTC)

In addition to Texugo's concerns, I don't think I could ever support videos if I can't even watch them. ChubbyWimbus (talk) 12:30, 2 August 2013 (UTC)

I would suggest you consider using a browser other than IE, but I know that a lot of other readers probably use it, too. I think I can confidently predict that either IE will fix this problem, or people will eventually stop using it. Let's remember that Netscape was the dominant browser at one point. Things change. But for now, the limitations of IE are a relevant consideration. Ikan Kekek (talk) 12:39, 2 August 2013 (UTC)

I can see a limited application for certain videos, but I agree it would have to be tightly controlled. The geyser video is close, but it was not shot from a tripod, and as Texugo notes it's framed too closely. (The framerate and resolution seem good to me though.) LtPowers (talk) 13:22, 2 August 2013 (UTC)

There may be add-ons for IE8 to view ogvs, but I decided to rather go with a browser which would run on XP and was still getting support. Later versions of IE may work, but I have not tried them, and if you want to stay with XP you can't use them anyway.

I would accept the quality of the geyser video as good enough. It shows enough to be helpful and is sufficiently short and specific that it could easily be replaced by a better one at some stage. I think the article would be improved by its presence, but accept the consensus if it is against it on technical quality. Frame rate and resolution are standards that can be objectively applied. Does anyone have recommendations for minima? • • • Peter (Southwood) ^(talk): 20:31, 2 August 2013 (UTC)

I am not keen on seeing loads of videos, but I think that a few may be a useful addition to the site. I would like to see all videos approved on a central page (allow 1-2 weeks for discussion) before they are linked. Ideally this should start with a text script, and the video is only uploaded if the script is approved. The main use I see is in the rare case of explaining how to do something that is difficult to describe in words - something like how to eat with chopsticks (I am sure that there are better examples). I would like to see the length in seconds and size (in Mb) of videos given in the caption, so that I know whether it is worth watching on a slow or expensive connection. The video must be watchable with no sound (in libraries etc), and music should only be present if it is part of the scene, not as a backgound. A few how to videos could also be created for using and editing the site like how to edit and upload a banner. AlasdairW (talk) 22:05, 2 August 2013 (UTC)

Convenience break

I'm very glad I stopped by today to see if there was any follow up on my question/bold step/video insertion of yesterday. Frankly I'm taken aback at all the discussion, and haven't been able to get through more than half of it so far!

I won't try to address every objection, and if the consensus is that videos don't belong here that's ok with me. I just thought short, non-jerky, tasteful (I hope) videos of the "A Walk through ..." type would be a natural here. Many of the objections could likely be addressed with appropriate technology. For example the idea of having easily accessible content in poorly connected places (I'm thinking of Laos and Nepal) is great and a technical solution might be just having a text-only version for those situations (and an easily available selection mechanism). This is something like the mobile app in Wikipedia and I'd guess the techies at WMF could come up with something very quickly. Another solution suggested above, a linked sub-page having photos, video, external links, etc on it, could be implemented by us, probably without any help from WMF techies. The material on the main article page could be all text, if that is useful, and easily accessible and printable. I do think however that at least 90% of the pageviews here probably come from Europe and the US where folks have good connections and want to view online and just inserting more photos, video, etc. would be very useful for these readers. It's up to you guys which approach (or no new approach) you'd want to take.

Keeping up quality is certainly something you'd want to do. I hate the usual herky-jerky handheld stuff, and most bastardized local-guide commentary that I'd expect on most tourist video would drive me up a wall. Even worse would be commercialized "this is a great hotel, great restaurant" type of thing. Somehow though, I'd think that this could be easily regulated here. The comments about which techniques (or fonts!) to use, or sending in a script beforehand for pre-approval would not work, or would tend to freeze video here in an antique state.

Briefly, my suggestion here is to get together a committee/project/excursion with at least 5 members, have them set up some general rules, and let everybody know it's an experiment that might be stopped at any time. For the first month, let them approve say up to 4 videos for insertion. If there are no objections to the quality from the general editorship, let them approve up to 8 the next month, and let them keep on increasing the limit as long as the general editorship thinks it's going well. The subpage idea (where needed) would be the easiest way to implement it in the short term. Worse-comes-to-worst, after six months WV will have to delete about 100 videos. Low risk, and, I believe, high potential return.

I'll watch more carefully this time, to see what you think.

All the best,

Smallbones (talk) 01:57, 3 August 2013 (UTC)

The strange part is Wikipedia is trying to allow and develop all forms of information to spread better knowledge to everybody. But especially some people limiting videos in one part of Wikipedia sounds like some anarchy thing. Wikivoyage is likely be the prime place of videos so future travelers have glimps of his or her intended travel destination through short videos here in WV section. On TV channels everywhere they show tons of travel destinations in short or long forms which actually eases the travelers initial assumption on travel plans so in WV videos are absolute ingredient to improve the quality of information of pages here. Orgio89 (talk) 06:29, 5 August 2013 (UTC)

Thank you for your perspective, but how do you propose mitigating the concerns some of us have about video usage? LtPowers (talk) 20:27, 5 August 2013 (UTC)

If any video did not breach copyright law then let that be in WV. Even pixelerated poor quality of video does not matter. WV is all about travel and travelers interest. If some groups of travelers in Europe want to see that stinky flower of Amazon they'll never complain about poor quality of Stinky Flower video in an Amazon travel page, if groups of Asian travelers really want to see that really boring 200 year old buildings in some old European city then let that old black and white strange video be in that city's WV page. It is all about content delivery to the traveler. All editors of WV are only servants to the travelers not the kings themselves. WV is only supposed to serve for travelers interest not limiting the travelers destination learning possibility! For any of 99% of world travelers who never witness live rocket launch at Florida NASA site any of those Shuttle launch videos will still never bother them when he or she check out that Florida destinations pages here. Orgio89 (talk) 00:20, 6 August 2013 (UTC)

That is what our link to the respective page/category on Commons is for. We strive to build quality guides here and quality does matter very much. Even if I am ever convinced that we really need videos, I will never accept "any video no matter how crappy is better than no video". Texugo (talk) 00:33, 6 August 2013 (UTC)

Then only 2 restriction might better apply in current situation that 1. No copyright breaching on videos, 2. No pixelerated video, Maybe 3-d no less than 360p resolution. Editors in WV likely need to deliver richer content of a destination for a traveler rather than shrinking his or her destination learning window. Orgio89 (talk) 00:40, 6 August 2013 (UTC)

Today there are over 2 billion smartphones in use everywhere and most of them have GPS which means prime travel tool except communication use. And many of smartphone users will very easily take pictures of Destination A page in WV and he or she might take video of that optional getting around suggestions video in that page with their smartphone camera. So actually printing out of a WV page consideration might be little too old nowadays but smartphone full copying of a page has over 2 billion chances at the moment. Orgio89 (talk) 01:06, 6 August 2013 (UTC)

Those shaky cellphone videos are especially something we should avoid, and at any rate, please go back and read this whole thread. You are kind of repeating stuff that has already been brought up and responded to. Texugo (talk) 01:34, 6 August 2013 (UTC)

Re-opening discussion after a long hiatus. I'd be in favour of allowing links to sound or video with some clear restrictions. I'm not certain what restrictions would be needed, but here is my first cut:

• Only links to material on Commons. That saves us worrying about licenses & copyright status; Commons already has clear policies & enforcement rules for those.
• Only supplemental stuff; if it can be handled well with text & photos, it should be. Things like a sound file for language teaching or video for an intrinsically dynamic event like a Shuttle launch or a dance performance can be provided, though there should be text as well. Stuff like a powerpoint presentation of the points of interest somewhere or a video walk through the streets should not even be considered.
• The one exception to both the above is if somewhere like a museum of some town's tourist bureau has a good video; we could link to that but not embed it here.
• Quality is an issue. I'm not sure if the 360px restriction suggested above is the right one, but we need something.
• Length, too. 3 minutes sounds about right, or maybe just 2?

Comments? Or has everything worth saying been covered already? Pashley (talk) 18:58, 15 December 2013 (UTC)

There are a number of issues around images sizing. Can we reach firm conclusions on them, get some text into the policy page where needed, and end the discussions which I believe a number of people find silly, repetitive and/or annoying?

First off, Wikivoyage:Image_policy#Image_sizes has sensible advice about sizes for upload but says nothing at all about sizes for use in articles. Once we have settled the questions below, it should be updated to cover that.

Second, there is extensive discussion above of changing the default image sizes. My understanding is that WMF server admins have rejected that suggestion, so the discussion is over. Registered users can override the defaults, so this is not a disaster. In my view, we should just forget the whole thing. If that is not what we are doing, I'd like an update on the current plan.

Finally, there is the whole question of fixed image sizes like 300px versus sizes as a multiplier applied to the default size like upright=1.6. This has also been extensively argued above. (The third option, setting height with something like x60px and letting the system scale the width, has not been mentioned but might be useful at times.) see w:Wikipedia:Picture_tutorial#Thumbnail_sizes for background.

My position on that one is a plague on both their houses. I think policy should state that correct usage is 'thumb' alone except in very rare cases. Maps are the only exception I am sure of; lead images in articles are sometimes another, but I do not think that is necessary if there is a good banner.

When you do want to specify a size, I mildly prefer fixed sizing to relative; it seems simpler. Pashley (talk) 01:12, 23 May 2014 (UTC)

There are some cases in which the default thumbnail size is either unnecessarily large and problematic for the look and content of the article or too small to see salient features. I see the point that the default size should indeed be treated as the default, but I would hesitate to overly strongly urge people not to change the size. Ikan Kekek (talk) 03:42, 23 May 2014 (UTC)

I'd be curious about the cases in which the default thumbnail size is too big; I thought it was pretty universally agreed it was too small for anything except low-bandwidth connections. Powers ^(talk) 18:45, 23 May 2014 (UTC)

There are cases in which the default thumbnail size is too big to fit well with everything else being at default size, as the photo is just that much bigger. I'll try to find an example for you, as this is something I've dealt with in a few articles lately, but I don't remember which ones. Ikan Kekek (talk) 01:44, 24 May 2014 (UTC)

One case is the example given on the WP page I linked above, a very tall, narrow photo, God + headdress, that turns out huge at default width. That is their only example of where 'upright' should be used. Pashley (talk) 17:37, 24 May 2014 (UTC)

Right; that's such an obvious case that I guess I thought Ikan was talking about something else. =) Powers ^(talk) 17:01, 25 May 2014 (UTC)

I'll try to remember to post a link to an article on this site with an example of an oversized thumbnail that I felt needed to be reduced in size when I come across one. Ikan Kekek (talk) 10:06, 10 June 2014 (UTC)

Retina Display Considerations

I am the recent owner of a Mac Book Pro with a Retina display. I notice that the experience I get on WV seems different compared with my non-Retina systems.

At the same time I am working on some systems for publishing web content, and being able to handle Retina displays with CSS is a high requirement these days.

Is it something we are looking at for Wikivoyage? Can we use higher resolution images for thumbnails, banners and other images and scale down where required? --Andrewssi2 (talk) 13:21, 10 June 2014 (UTC)

We could certainly include encouragement for higher resolution images in our help page, but I'm not sure what else could be done. We can't exactly require a higher resolution since there aren't necessarily higher-res versions available for most of the images we already have, and a not-high-but-not-too-low-res image may in many cases be better than no image at all. Texugo (talk) 13:34, 10 June 2014 (UTC)

Would that be consistent with our current position of avoiding galleries of huge images to minimise load times on slow, expensive mobile connections? K7L (talk) 14:43, 10 June 2014 (UTC)

We may want to reconsider the abovementioned given the fact that there slow and expensive connections are on the decline, while high-definition displays are on the increase. Moreover, I believe we should start differentiating the viewing experience for the "desktop" (/laptop) and mobile users e.g. in terms of images. PrinceGloria (talk) 19:56, 10 June 2014 (UTC)

We had some feedback from User:Alice recently to suggest that we should do more to support low bandwidth connections.

However you are right to say the High definition displays are on the increase, and will probably become standard on laptops in the next few years. I think it would be great to start thinking how we could improve WV now for a better experience when that day inevitably arrives. Andrewssi2 (talk) 04:59, 12 June 2014 (UTC)

Animated Gifs v2

There was an earlier discussion about this in 2008. The conclusion was that animted gifs are not good.

I just saw the following on Stuttgart:

Take the superfast ICE trains to get to other German cities quickly

Am I correct in determining this is not allowed, and can we make an explicit statement about this on the policy page? --Andrewssi2 (talk) 05:03, 12 June 2014 (UTC)

That us seriously distracting when trying to read the article. --Traveler100 (talk) 05:07, 12 June 2014 (UTC)

I did not find it distracting when I put it there and actually nicer than just a view of the platform, but please feel free to replace it with a static version (it is in the Commons) if you do. PrinceGloria (talk) 05:20, 12 June 2014 (UTC)

I don't like the animated GIF, either, for the same reason Traveler100 states. And I don't think these are allowed. Ikan Kekek (talk) 06:49, 12 June 2014 (UTC)

Whether because it could be considered a kind of video, because it's a type of image other than maps or simple photography, or because gif is not one of the file types sanctioned at Wikivoyage:Image policy#Image formats, animated gifs do not jive with our image policy, so I have replaced it in the article with the static jpg. At any rate, I think most people know that trains move, so that fact probably doesn't need to be explicitly illustrated anyway. Personally, I think most animated gif's are awful eyesores straight out of 1997. Texugo (talk) 14:17, 13 June 2014 (UTC)

Are there any objections to adding the following text to Wikivoyage:Image_policy#Image_formats ?

"Animated Gifs are not allowed in any Wikivoyage article." Andrewssi2 (talk) 02:31, 18 June 2014 (UTC)

Fine by me! Texugo (talk) 02:38, 18 June 2014 (UTC)

Strongly seconded. Ikan Kekek (talk) 03:56, 18 June 2014 (UTC)

Can you change the wording to "Animated Gifs should not be used in any Wikivoyage article." Except in cases of legal issues I don't think any of the policies are written with absolute prohibitions. -- Ryan • (talk) • 05:08, 18 June 2014 (UTC)

As per Ryan's request, changing to:

"Animated Gifs should not be used in any Wikivoyage article."

I will apply tomorrow if no more comments. Andrewssi2 (talk) 00:29, 19 June 2014 (UTC)

Done Andrewssi2 (talk) 13:16, 22 June 2014 (UTC)

Licensing for locally-uploaded images

Swept in from the pub

Nominally, only nonfree content that falls under the exemption doctrine should be uploaded locally, but de facto the large majority of images that are hosted locally are DotM banners, which are sourced directly from Commons or CC-compatible Flickr images and are therefore free content. Many of these free images are public domain; however, currently locally-uploaded images can only be tagged with the Attribution 2.0 or 3.0 or Attribution-ShareAlike 2.0 or 3.0 licenses, or as a Wikivoyage webpage screenshot. We should probably add a public-domain option (and for that matter, also options for Attribution and Attribution-ShareAlike 4.0, which Commons now supports). -- AndreCarrotflower (talk) 15:20, 16 October 2014 (UTC)

BUMP. -- AndreCarrotflower (talk) 05:15, 18 October 2014 (UTC)

I've created the 4.0 license templates and a {{Cc-zero}} template. For the upload wizard, not sure there should be too many choices, so if 4.0 was added, 3.0 should be removed from the list. Just wondering if the 4.0 links should be added to {{Cc-by-sa-all}} and {{Dual-gfdl-cc-by-sa-any}}. Would also be good to add the cc0 option as you suggest. -- WOSlinker (talk) 21:02, 18 October 2014 (UTC)

Although thinking about it, may be worth staying with 3.0 in the list since the Wikitext is 3.0 licensed, so more convenient to have both the same. Worth having the templates though, for those who wish to use 4.0 instead. -- WOSlinker (talk) 21:19, 18 October 2014 (UTC)

It's necessary to keep 3.0 (and 2.0) in there because the vast majority of DotM banner images are sourced from other CC-compatible images on Commons and/or Flickr, and they have to be uploaded under the same version of the CC license as their source image. Any source image uploaded to Commons before CC 4.0 support began will retain the 3.0 (or previous version) license, and anything CC-compatible that's uploaded to Flickr is always 2.0. So those tags need to be available for locally-uploaded banners as well. -- AndreCarrotflower (talk) 21:38, 18 October 2014 (UTC)

Image licensing paperwork

Swept in from the pub

Have any of you seen this report on image licensing documentation here at the English Wikivoyage? https://tools.wmflabs.org/mrmetadata/wikivoyage/en/index.html

The goal is to standardize documentation so that bots and scripts can keep track of it and so that people are more likely to re-use images correctly. I looked at a couple of these, and I think that the "problem" (from the perspective of a bot) is just the location of the tags. On the couple I looked at, the "permissions" fields said "see below" rather than having the tags inside the {{information}} template. I'm thinking that if we just moved those tags, that Wikivoyage could have most of its images in the ideal format pretty quickly. WhatamIdoing (talk) 17:50, 21 October 2014 (UTC)

There are 4 machine generated categories:

• Category:Files with no machine-readable source
• Category:Files with no machine-readable license
• Category:Files with no machine-readable description
• Category:Files with no machine-readable author

I've made some changes to Template:Information, Template:Cc-by-sa-3.0, Template:Cc-by-3.0 and other templates to reduce the number of entries in those categories. There are still some of the license templates that need doing, mainly those with multiple licenses. I also changed Template:Imagecredit to use Template:Information but that was reverted. -- WOSlinker (talk) 18:58, 21 October 2014 (UTC)

I've done the rest of the license tags and it has revealed a few unlicensed images, which will need removing from articles and deleting. I'm listing here so that alternatives can be sourced if possible before deletion. -- WOSlinker (talk) 19:29, 21 October 2014 (UTC)

Image	Used on
File:Accra lighthouse.jpg	Accra - Replaced
File:Bam-severobaikalsk.jpg	Baikal-Amur Mainline, Severobaikalsk
File:Beirut818bpa6.jpg	Beirut - Replaced
File:Bozar IMG.JPG	Brussels - Replaced
File:Greater Sydney Discuss.png	Talk:Sydney/Archive 2003-2012
File:Hurshimchung Entrance.JPG	Hot springs - Replaced
File:Madisonbanner1.jpg	Wikivoyage:Destination of the month candidates/Banners/Archive
File:Malta Sliema Sign.JPG	Malta - Replaced, Wikivoyage:Joke articles/San Serriffe - Replaced
File:Pirelli Building, Milan, Italy.jpg	Italy, Milan/North

WOSlinker, File:Madisonbanner1.jpg's description clearly states that it was sourced from this photo on Commons. The reason why it doesn't have a license listed is probably because the source photo is public domain, which is precisely why I clamored for expanded licensing options for locally-hosted images a while back. -- AndreCarrotflower (talk) 19:36, 21 October 2014 (UTC)

I've addded {{Cc-zero}} to that image, so that it matches the license used on commons. -- WOSlinker (talk) 19:48, 21 October 2014 (UTC)

File:Bam-severobaikalsk.jpg has "photo license: Creative Commons Attribution-ShareAlike 1.0 or GFDL 1.2" as the second line of text. AlasdairW (talk) 22:10, 21 October 2014 (UTC)

I've added the license templates to match this. -- WOSlinker (talk) 22:37, 21 October 2014 (UTC)

It looks like 52% of the files have been fixed already. Congratulations! There are just 354 to go as of the last count. WhatamIdoing (talk) 21:24, 23 October 2014 (UTC)

I just wanted to let you know that envoy got a shout-out at today's m:WMF Metrics and activities meetings for making so much progress on this issue so quickly. You can see it around 50 or 51 minutes, I think. WhatamIdoing (talk) 20:07, 6 November 2014 (UTC)

Photolist

Swept in from the pub

Does something similar to it:Template:Photolist exist on en.voy? I'd like to translate the see section from it:Franciacorta, but I can also add photos manually. Thanks --Lkcl it _(Talk) 18:13, 5 January 2015 (UTC)

I love that See section! In my opinion we should implement the same here. I believe the picture should be the listings' picture, though, instead of specifying it outside of the listing. Yes, listings have a picture field, we should use it more often. Currently 4386 listings (out of 215593) have an image. This image is also used as a thumbnail in dynamic maps. Cheers! Nicolas1981 (talk) 04:28, 6 January 2015 (UTC)

Even though we've been moving further and further away from the "minimal use of images" credo in our image policy, I think the "See" section in it:Franciacorta is a bridge too far. We do still want to accommodate offline users and those on slow dialup connections, right? -- AndreCarrotflower (talk) 04:46, 6 January 2015 (UTC)

I think that the "minimal use of images" policy is still useful. I do like the "See" section in it:Franciacorta, which is very neat, but there are articles with over a dozen "See" listings that would make things difficult, especially if the entries are short for some of the listings. And for one example of currently relevant applications of Wikivoyage:Image policy#Minimal use of images, please have a look at these edits to Na'in and the discussion at Talk:Na'in. So we need to tread carefully here. I also know that there are some long-time users of this site who hate left-justified images in articles. Ikan Kekek (talk) 04:57, 6 January 2015 (UTC)

Also, regarding images in listings, there have been serious concerns expressed by some users regarding how that conflicts with our policy prohibiting photos of businesses. -- AndreCarrotflower (talk) 05:15, 6 January 2015 (UTC)

It wastes a good deal of vertical space unless you can get a good paragraph of text for each listing, like number 4 and 5 in the example (this translates to needless extra scrolling and a waste of paper when someone prints it). Moreover, while that particular See section looks nice and neat, in order for that formatting to look nice it is necessary to have an image for every listing, cropped to the same aspect ratio for alignment purposes. Forcing that format on any section with a bunch of listings, some with photos, some without, with photos of all different shapes, some oblong, some tall and skinny, etc., would not look nice at all. Making sections looks as nice as the small example given would by no means be a small task for an article with 30 See listings and 30 Do listings, etc., and to implement it sitewide without actually worsening the appearance of our current articles would be an absolutely inconceivable amount of work. Texugo (talk) 14:36, 6 January 2015 (UTC)

I share those concerns. It works for a few listings with long descriptions and good images for all, but it will look much less neat for many longer lists. Personally, I don't particularly like it; I prefer larger, quality images in an article over small thumbs next to each listing. That said, I'll admit that's a matter of taste and I see no need to prohibit the use of this concept on a couple of articles where it works and the author would like it, in the same way we allow for galleries here and there. While I encourage clever use of images (and the Na'in example is not it), slower connections seem less of a problem these days, as Wikimedia shows content without the images if it takes too long, right? JuliasTravels (talk) 14:59, 6 January 2015 (UTC)

To be clear, we don't actually "allow for galleries here and there" based on whether "the author would like it" — they are only allowed in the relatively rare and specific situation of "multiple examples of a specific topic" like fauna or flora, almost exclusively in park articles and dive guides. Texugo (talk) 16:29, 6 January 2015 (UTC)

Badly phrased on my part. I'm sure some (imho artificial) rationale was given. I fail to see how multiple examples of wildlife truly differ from multiple examples of monumental buildings; they are all the "sights" or attractions of their destination. But anyway. Point noted ;-) JuliasTravels (talk) 16:38, 6 January 2015 (UTC)

The types of galleries allowed serve as references to help the traveller identify things they may come across in the wild, whether they are birds or corals or highway signs, thus serving them up in a gallery has a specific purpose which justifies the resulting interruption to the flow of the article, whereas stopping any ol' place to have a picture party just breaks up the article needlessly and serves to encourage quantity over quality. Texugo (talk) 16:45, 6 January 2015 (UTC)

As a side note, on German WV they have invented a kind of photo gallery called "Scroll Gallery" that doesn't take up more space than one single photo (example, click the black arrows to switch photos). ϒpsilon (talk) 12:56, 7 January 2015 (UTC)

On the discussion of galleries: I take a dim view of galleries because they are a series of small photos, usually smaller than optimal for decent viewing of details. I think their use should be very exceptional on this site. Ikan Kekek (talk) 13:36, 7 January 2015 (UTC)

I have asked my question only because I like the result. Also on it:voy we rarely use the photolist template (sometimes there aren't enought photos, sometimes the descriptions are too short ...) and they aren't in the article's templates. By the way I understand the problem with the minimal use of images, so I'll try to obtain a similar result without the template. Thanks --Lkcl it _(Talk) 15:31, 7 January 2015 (UTC)

I would support allowing the template in a few articles on an experimental basis, for what it's worth, but I think some other longtime users would probably oppose even that. I'll let them speak for themselves, though. Ikan Kekek (talk) 15:40, 7 January 2015 (UTC)

Correct, I would oppose even that. If it is already unsuitable for implementation across the site, then it's no more than a proposed optional departure from the ubiquitous consistency of our standard layout for listings, and, experiment all you want, I would not support the introduction of randomly formatting some articles one way and others another way. That would be a big break from how we've structured the site thus far. Texugo (talk) 16:41, 7 January 2015 (UTC)

At some point, dial-up, CDMA and a few other historic signalling methods (such as Morse code heliograph, semaphore flag and carrier pigeon) will go the way of the dinosaur and we can back off a bit on this phobia of photos, audio or anything else that might take up space. K7L (talk) 03:16, 8 January 2015 (UTC)

The mere number of photos is hardly the only issue. I dislike overly small thumbnails or images that go past the end of the text in an obvious way. Ikan Kekek (talk) 03:37, 8 January 2015 (UTC)

I understand the issues that Photolist could cause, and I think that these issues can be solved one-by-one:ultra

• Looks bad if a picture is missing -> We need a mechanism that disables Photolist entirely if any picture is missing.
• Looks bad if all pictures are not the same size -> We need to design a smart resizing/margins-cropping algorithm.
• No pictures of businesses on articles -> Let's use Photolist only for the "See" section, where it is most useful.
• Bandwidth -> We need to wait a few more years, or disable Photolist/banners for low bandwidths. For instance this travellers-oriented website is reasonably lightweight on my phone, even though the normal website uses incredibly-large video banners (which is another extreme we should avoid imho).
• Left-justified images are bad -> Because they break the text flow, but here if the whole section's text is translated, no impact for the reader... a UI specialist's advice could help here. Or we could maybe put images to the right.

I also understand that the idea needs to be thought and rethought, no problem if it takes years before we implement it, but I believe our future Wikivoyage will use much more images than now, and be more visually pleasant, more readable. Really, I can't stop looking at it again, it looks so nice... you see the pictures and immediately understand what it is about, and which place you want to visit, much faster than reading all of the text. I will put this idea in a corner of my head and come back to it in a year, cheers! Nicolas1981 (talk) 08:17, 8 January 2015 (UTC)

I agree with you on the pros of Photolist. Ikan Kekek (talk) 08:32, 8 January 2015 (UTC)

Traditionally, Wikivoyage has been more of a text-oriented travel guide, which has its advantages and disadvantages. If you check commercial products, both text-based LP or RoughGuide and picture-based DK books are available on the market. Text-only travel guides are, of course, very boring (and LP recognizes this by adding color pages with illustrations), but glossy travel guides replete with pictures are not appealing to all. Moreover, it is very difficult to make them, especially in our case when 99% photos available on Wikimedia Commons are shamefully bad.

Another problem to consider is that the photolist imposes a very strict format with exactly one paragraph of nearly fixed size written about every attraction, no matter whether it deserves more or it deserves less. This will never work for many places including world-known attractions. The format has to be more flexible than "picture on the left and text on the right". Commercial travel guides demonstrate this very clearly.

On the positive side, one could try to develop this idea in other directions. Some of you might have seen the ongoing discussion on Ryan's talk page, where detailed descriptions of cities and regions are proposed. One possible format can be seen on the Russian site, where the idea of "text+photo" is applied to the lists of cities and subregions in regional articles. This might be easier to achieve, because it is possible (and reasonable) to write exactly one paragraph of text about each city or subregion. --Alexander (talk) 09:49, 8 January 2015 (UTC)

That's a really good-looking article! Ikan Kekek (talk) 10:23, 8 January 2015 (UTC)

I like the idea of the photos for attraction on the region pages, many regions are very dull at the moment serving only to create a structure, something like the Russian example would make the pages much more inviting. As for city pages I think a free format with most of the images on the right better. How about having thumbnail on mouse over a listing? We already have the ability to associate an image with a listing (see Wales Coast Path as example) but currently this is only seen in the dynamic map. --Traveler100 (talk) 12:06, 8 January 2015 (UTC)

Displaying photos when mouse is hovered over the listing would be great. I would like to try this. Do you know how to implement such a thing? --Alexander (talk) 12:29, 8 January 2015 (UTC)

Mouse over text can be done with standard wiki syntax but I think image on mouseover would require some programming above my current knowledge on the subject. --Traveler100 (talk) 08:12, 10 January 2015 (UTC)

The more I think about this the more I believe having something like the photolist or the Russian site cityitem would be a good idea. Not for city pages, here there can be a large list of See listings, not all warranting a picture or paragraph of text. However at the Bottom-level regions a small gallery of main attractions for the area would greatly improve the aesthetics of these pages. What I am talking about are the regions below state level in USA, Canada, Germany, India, etc. or county level in England and Wales. There are often not much more than a list of cities sitting at outline status and preventing important travel regions and countries becoming guides. Adding some good photographs and a little more information will make this site look more like a travel guide for new readers. --Traveler100 (talk) 08:21, 10 January 2015 (UTC)

Not a typical gallery with tiny thumbnails, though. Ikan Kekek (talk) 08:30, 10 January 2015 (UTC)

Something like the see section in this. Although I think this shows that need to do the whole page with the style, cannot just do one or two. --Traveler100 (talk) 08:41, 10 January 2015 (UTC)

For those sights, those little thumbnails are sufficient, but there are plenty of sights for which those photos would be too small to see essential details. Ikan Kekek (talk) 08:44, 10 January 2015 (UTC)

Yes but these entries should only be a method to link to the city page where the sight is, which hopefully should have more information and larger images. --Traveler100 (talk) 09:03, 10 January 2015 (UTC)

I'm not sure how much I like that idea. I'm bothered by non-functional maps in articles that have to be clicked to be usable, so tiny thumbnails that aren't really viewable but have to be clicked would present a similar problem. Ikan Kekek (talk) 09:17, 10 January 2015 (UTC)

Bit of a detailed sub-discussion here. --Traveler100 (talk) 10:14, 10 January 2015 (UTC)

(possibly off-topic) Independently from the picture, I just got a related half-baked idea: In region articles, how about taking each city's banner and making it much whiter so that it becomes a background on top of which text is comfortably readable? So the list of regions would be more colourful, each city's line using that city's banner as a light background. Like banners, the goal is mostly aesthetic, the goal is NOT to show a detailed view of everything in the city. We would have to somehow get the banners from Wikidata, which I don't think is feasible right now. Nicolas1981 (talk) 05:20, 13 January 2015 (UTC)

I think we should be very cautious about that. The banners are carefully chosen to keep the TOC readable – even as it is regarded non-essential. Using the same banner as background to a paragraph will almost certainly make parts of the text harder to read, at least for some. I think functionality is much more important than aesthetics. And compromising the images for readability, they may transform into clutter. --LPfi (talk) 11:55, 13 January 2015 (UTC)

Aesthetically I like the way Nicolas is thinking, but if we fade the images enough to make the text readable, I think we will lose any aesthetic value to the images themselves -- certainly not worth the bandwidth load. Powers ^(talk) 15:15, 13 January 2015 (UTC)

Event pictures

Swept in from the pub

I took the liberty of adding pictures of the Helsinki Samba Carnaval and the Helsinki Burlesque Festival to the Helsinki/Central article. Should I add more pictures of events, for example of the World Bodypainting Festival and BoundCon? The thing is, I have so many pictures to choose from, and I think one picture per event is quite enough. JIP (talk) 20:53, 2 March 2015 (UTC)

In cases where the article is already full of pictures, I would say events should have less priority as they have a lower probability of being useful than attractions that are available all year round, but Helsinki/Central does not seem to be full of pictures yet. By the way, whenever you add a picture related to a particular listing, I recommend also adding the picture as a "image=" attribute of the listing. That way, the picture will be used in the dynamic map, possibly reused in other places, and will remain attached even after in cases where the picture gets removed from the article for a reason or another. Cheers! Nicolas1981 (talk) 03:08, 3 March 2015 (UTC)

How do I add a picture as an "image=" attribute of a listing? JIP (talk) 05:09, 3 March 2015 (UTC)

Unfortunately this is not editable with the listing editor. You have to click "Edit" next to the relevant section title and edit the wiki code directly. See for instance . After the fax for instance, just add like "| image=Bregenz Rathaus 01.jpg" or whatever picture you see fit. Thanks! :-) Nicolas1981 (talk) 06:26, 3 March 2015 (UTC)

The best image for the article is not necessarily the best image for the listing, as the thumbnail will be smaller.

Images not used in the article are not wasted: most Wikipedia folk will know how to use the Wikimedia Commons link, and more of our readership will gradually learn to use it too. If the categories for the destination on Commons are well organized, the images will be found there (sadly not true for all destinations, much work remains).

--LPfi (talk) 07:24, 3 March 2015 (UTC)

Banner query

Swept in from the pub

Is it ok to use a montage of images on a banner for a city? Like this one File:Chittagong banner.png--AzaanJC (talk) 05:08, 27 April 2015 (UTC)

Thanks for asking. The answer is no, montages may not be used on this site. See Wikivoyage:Image policy#Montages and galleries. Ikan Kekek (talk) 05:15, 27 April 2015 (UTC)

Montage

At the risk of getting decline, I still would like to see if the community may consider reviving our image policy. We've been quite oppose to using too much photographs in our guides as the current policy says but we must all admit that photography is very essential for tourism. I realised tradional travel guides usually focus too much on photographs whereas we don't. So I suggest here if we can use photo montages in our guides — in particular country and region level guides in order to give broader overview of the place. We'll be using a template which will automatlcally create a photo montage, a collection of photographs without having to use any external application and each image can be enlarged individually. Opinions please. --Saqib (talk) 20:41, 9 May 2015 (UTC)

I would like to see more photographs on the region pages, the hierarchical structure of this site does tend to create some dull intermediate pages. What are the advantages of a montage over adding individual images though? --Traveler100 (talk) 20:51, 9 May 2015 (UTC)

I don't like montages for the exact reasons mentioned in image policy. Otherwise, I completely agree with Traveler100. You've probably noticed that I tend to add photos to articles every night, first of all by looking through the new Valued images, Photo of the day and featured Valued images on Commons. Ikan Kekek (talk) 20:57, 9 May 2015 (UTC)

Traveler100: One major advantage of adding a montage is that it will cater several photos in the place of one. Please be note montages should only goes in the lead section. Ikan Kekek: It seems to me the opposition in the policy page was for montage such as like this one. Proposed montage is not one image so it doesn't really look "travel brochure, or some other promotional" as current policy states. --Saqib (talk) 22:39, 9 May 2015 (UTC)

I just tend to find them messy - a bunch of miscellaneous sights put together, often too small for many or even all of them to be seen well. Ikan Kekek (talk) 22:49, 9 May 2015 (UTC)

I also think captions on single photos are a lot clearer than captions saying "Top right, a; top center, b; top left, c", etc. It becomes a long list and not that informative. Ikan Kekek (talk) 22:53, 9 May 2015 (UTC)

Generally I agree with the objections made above, but very occasionally montages could be useful when a single caption could usefully describe the collection of images e.g. "Banknotes of the country", and a composite photo isn't available. Also the template used for the example montage looks too complicated. AlasdairW (talk) 23:28, 9 May 2015 (UTC)

I'm not sure montages would be as good or better than galleries for that kind of purpose. Ikan Kekek (talk) 00:10, 10 May 2015 (UTC)

Montages work poorly on mobile as they provide no means to allow the browser to reposition the constituent images one-above-another on a small screen where they won't fit side-by-side. K7L (talk) 00:16, 10 May 2015 (UTC)

It's a no from me as well. Galleries are just fine. PrinceGloria (talk) 00:59, 10 May 2015 (UTC)

I usually don't like galleries, either. They are OK under a limited set of circumstances that's laid out in image policy, and in addition to the points made there, it's vital for all the small gallery pics to be clearly visible in their salient details. Ikan Kekek (talk) 06:37, 10 May 2015 (UTC)

I also dislike montages. I find they actually often make places that are otherwise interesting and make them appear boring. Every city starts to look the same; just "buildings" isntead of the historic sites they are. If it's nature, the montage just ends up looking like generic trees and lakes and flowers. Better to have one image that we force the focus on to really show off something interesting and noteworthy. One shot makes a greater impression than a hodge-podge of random images. ChubbyWimbus (talk) 13:07, 10 May 2015 (UTC)

Count me against them too, for essentially all of the above reasons. Too small, too jumbled, too generic, too finicky. Texugo (talk) 21:25, 10 May 2015 (UTC)

New retouching policy?

I noticed that a new section for retouching policy has been added without discussion Wikivoyage:Image_policy#Retouching_guidelines

Anyway the following line is confusing to me:

Details such as faces and car licence plates could be blurred for privacy, as long as the blurring does not disturb the image quality

If you blur anything on an image then it will disturb the image quality!

As it stands, the text in the section does not help me in anyway. Can we discuss what it should be? --Andrewssi2 (talk) 21:26, 18 June 2015 (UTC)

I have undone this change (preserved here) pending discussion. I also think we should avoid blurring as a general rule. Let's discuss this first. Texugo (talk) 21:35, 18 June 2015 (UTC)

Very occasionally I think that it is appropriate to edit a picture. I think that the first point that needs to be made is that editing a picture (except for whole picture brightness / colour etc. adjustments) should only be done in very exceptional situations. I can only think of doing this where there are recognisable people in the picture - two examples are the banners for Respect and Ayr. It is also more likely to be appropriate to edit a picture for a travel topic (trying to illustrate a concept) than for a destination.

On the other hand I think that we should be clear that a view of a destination should not be edited to remove anything that is fixed or regularly present in the location. So do not remove traffic or street-lights from a historic street. AlasdairW (talk) 22:55, 18 June 2015 (UTC)

I didn't find what retouched picture you were talking about in the case of Ayr, but even for the Respect one, I would suggest that a better banner photo could be found that didn't require 8 blurry spots. Texugo (talk) 23:18, 18 June 2015 (UTC)

Sorry I mean't Ayr (Scotland). At the right of the picture, I edited out the face of the lady in the white striped T shirt, by pasting a copy of the beach and seawall - it is just possible to see where (under second car from right) if you look at the banner full size. I did this pertly because of the policy of keeping people out of photos, and partly because I thought it looked better. AlasdairW (talk) 21:09, 19 June 2015 (UTC)

I'd also like to emphasise TTCF with regards to this policy. We are primarily concerned with accuracy and not aesthetics. If an image is changed so that it looks better but the location is less accurate as a result then it is a clear violation. --Andrewssi2 (talk) 23:42, 18 June 2015 (UTC)

Our existing policy is that we try to keep people out of landmark photography. We don't want photos where the traveller has posed their relatives in front of every beaten-path landmark in Europe, for instance. The proposal to allow photos with blurred faces contradicts this. Compose the image properly when taking the photo and keep these extraneous elements out. K7L (talk) 01:09, 19 June 2015 (UTC)

They aren't always extraneous. Powers ^(talk) 19:30, 19 June 2015 (UTC)

Pictures of food

Swept in from the pub

Is it OK to add pictures of food at restaurants mentioned on Wikivoyage? I already have several pictures of food, from Helsinki, Tampere, Turku, Stockholm, Munich, Nice, and other cities too, but not all of the restaurants are already mentioned on Wikivoyage. JIP (talk) 20:56, 9 June 2015 (UTC)

Should be fine if it is an example of regional food Germany#Typical dishes or a specific special dish of a local restaurant (Dayton#Eat). --Traveler100 (talk) 21:01, 9 June 2015 (UTC)

(edit conflict) Of course we allow food pictures! We used to have an entire hierarchy of image categories on WT Shared just for food. However, I would suggest keeping the images representative of the destination's cuisine rather than focusing on the specific restaurant at which the picture was taken (unless the dish is particularly notable as a specialty of that establishment). Powers ^(talk) 21:05, 9 June 2015 (UTC)

The question (as I read it) is not can we show pictures of food, but rather can we show pictures of food identified at listed restaurants? I think some high end restaurants have a policy around taking pictures and publishing their dishes. --Andrewssi2 (talk) 23:36, 9 June 2015 (UTC)

In the hypothetical case of a restaurant's no-photographing-the-food policy being violated and the resultant picture being placed on Commons (or here), the dispute is between the individual photographer and the restaurant. To my knowledge - and I don't think I'm wrong about this - there's no legal precedent for preemptively claiming copyright ownership of the image of food before it's even been cooked. -- AndreCarrotflower (talk) 00:42, 10 June 2015 (UTC)

It seems like a very edge case of a restauranteur taking exception to an image of their served food being placed on Commons. Since pictures of food are not known to be covered by copyright in any jurisdiction, I would say it is a non-issue at this point in time --Andrewssi2 (talk) 00:51, 10 June 2015 (UTC)

New York times article on how annoying the practice of food photography is, and how little legal structure there is around it. --Andrewssi2 (talk) 00:53, 10 June 2015 (UTC)

I think that just as a matter of good faith, we should honor any request by a restaurant to remove an image identified as being one of its food, if they so request. Otherwise, there is no problem as long as posting the photo isn't regarded as unduly promotional. I think, for example, that a photo of a Katz's pastrami sandwich, given that it's of a famous New York food served at a truly legendary restaurant that's highly respected by both New Yorkers and visitors, would be fine, but a photo of a tuna melt at Joe Schmo's Diner in Anywheresville would not be OK to post, as it's not special and Joe Schmo's Diner doesn't merit the publicity. Ikan Kekek (talk) 03:10, 10 June 2015 (UTC)

Each listing has an optional "image=" parameter. Usually we put an image of the outside or entrance of the restaurant, but if a dish is more representative (for instance if this restaurant is famous and recommended for this particular dish), I think that using a picture of that dish is a good idea. For instance the listing for Mère Poularde could have the picture of their world-famous omelette. I agree with the others that we should not worry about copyright on food pictures until a restaurant contact us (which I doubt will ever happen). Cheers! Syced (talk) 08:29, 10 June 2015 (UTC)

The image parameter in a listing is a very different thing from an image that's shown in an article. Images meant to identify a business on a map aren't governed strictly by the don't tout concerns applicable to articles. To give one example, it's perfectly reasonable to use a very recognizable company logo in the image parameter of a listing, but usually not reasonable at all to feature it in an article. Ikan Kekek (talk) 08:50, 10 June 2015 (UTC)

Unless these were shot as works for hire, the original copyright belongs to the photographer. We are more lax with "promotional images" in the {{listing|image...}} tags, but there is no clear policy. A picture of the establishment or a specific product closely associated with that venue may be reasonable in the "image=" field (where it would usually be avoided for the article page images) but endless repetition of a corporate logo (such as the "Golden Arches" for food or the "Great Sign" for inns) adds nothing useful. A picture of a hamburger, a glass of soda/pop or a slice of pizza could be just about any restaurant, so adds nothing descriptive, but that place in Montréal that just makes bagels has a close association to Montréal bagels as a distinctive identifier. If a food item is closely associated with a geographic region (such as Buffalo being hunted for their wings), then a photo of that item in the main article body (preferably in a vendor-neutral fashion) is reasonable and expected. K7L (talk) 13:46, 10 June 2015 (UTC)

What I would be wanting is to simply display pictures of food at restaurants that I've already added to Wikivoyage. I have taken all the pictures myself (and of course eaten the food myself too), and I don't think the restaurants would mind. I usually photograph every single restaurant dish I ever eat, except for normal lunch restaurants on a normal working day. I'm not planning on adding every single photograph of a restaurant dish I have eaten on Wikivoyage, just ones at restaurants already on Wikivoyage, and even then only one picture per restaurant. Case in point: The discussion here seems to have mentioned authentic local cuisine. As a specific case, when I was in Munich in late May, I took pictures of local Bavarian sausage dishes at the Augustiner-Keller and at Bratwurst Glöckl, and also of a hamburger at restaurant La Cucaracha. The Bavarian sausages fit well into the local cuisine, but the hamburger does not fit at all. Am I still allowed to add a picture of the hamburger, because I photographed and ate it in Munich, and there's already a listing of La Cucaracha, even though Mexican-themed hamburgers are nowhere near authentic Bavarian cuisine? JIP (talk) 21:15, 10 June 2015 (UTC)

There isn't a rule as to what food you are 'allowed' to show in an article. That said, it would be preferable to use pictures that are representative of the destination in question as well as not overwhelming the article with them.

FYI, you should check out Bavarian_cuisine that currently doesn't have many images and could probably use some of your photos. Andrewssi2 (talk) 22:31, 10 June 2015 (UTC)

One of the things that our friends at de-WV do better (as of now) is their coverage on food and cuisine. We might want to create some equivalents of their article on that topic in the next few months... Hobbitschuster (talk) 22:36, 10 June 2015 (UTC)

Agreed on Bavarian cuisine as a good article for pictures of Bavarian Würste, but it's definitely fine to put a picture of a Wurst from a famous Brauhaus either in the Munich article or the article for the relevant district within Munich. I don't think a photo of a hamburger in Munich is likely to be relevant to any WV article. Ikan Kekek (talk) 23:50, 10 June 2015 (UTC)

Freedom of Panorama in Europe in 2015

((swept}} Please read the article on Wikimedia, this EU proposal may affect photographs we can use on Wikivoyage. Although the page does not make it clear why the non-commercial clause would cause problems. --Traveler100 (talk) 10:06, 5 July 2015 (UTC)

Local uploads should be no problem, but one has to be prepared to transfer images from Wikimedia Commons because people there are very eager to delete things without ever looking at the file usage and thinking about consequences. --Alexander (talk) 11:34, 5 July 2015 (UTC)

Non-commercial is a problem because our guides are intended to be used commercially, as are all Wikimedia projects. Powers ^(talk) 15:19, 5 July 2015 (UTC)

In some cases we can use fair use provisions, but these do not allow keeping a public collection for possible use. The images we now use can perhaps be moved here, stored locally and stay in our articles, but I cannot upload photos without inserting them in an article. When I write an article I will not be able to choose from not yet used images, as those will be only in private collections – and possibly not even there, if people doubt they will come to any use and therefore (in some specific cases) do not make the effort needed to get a good image. --LPfi (talk) 16:43, 5 July 2015 (UTC)

The current fair use provisions (in Finland, supposedly in much of EU) allow using images in news and when writing about a work. I think there is no way to use the image of a building just as illustration – except that buildings are subject of the freedom of panorama. One might get by by telling something about the architecture, but maybe not, and I do not want to consult a lawyer every time I want to insert an image or change the prose. --LPfi (talk) 16:51, 5 July 2015 (UTC)

In short the proposal sucks and who ever proposed it clearly did not have the best of the majority of Europeans in mind... Hobbitschuster (talk) 18:36, 5 July 2015 (UTC)

LPfi, I would be surprised if those were the only possible fair use provisions. In the U.S., at least, so-called 'editorial' use of images is allowed for just about any publication, including travel guides. Powers ^(talk) 22:58, 5 July 2015 (UTC)

I think the related provision in Finnish law is restricted to scientific context, critics and "vid redogörelse för dagshändelser" (approximately: when discussing current matters). The last provision means newspapers are quite free to use any images, but travel guides can hardly use it. I cannot find any provision relevant to us. The law in Finnish and Swedish and a translation to English can be found at Commons:Copyright rules by territory#Finland. --LPfi (talk) 15:49, 6 July 2015 (UTC)

Speaking to Powers' earlier comment, what the WMF really ought to do (whether or not this legislation passes) is to complement Commons with an integrated search functionality to help users browse images that are hosted locally on each of the various wikis. -- AndreCarrotflower (talk) 05:06, 7 July 2015 (UTC)

Let's wait what really happens on Thursday and how it develops. It has been and still is more imortant to mark your own photos with the proper FoP template "FoP-Germany", "FoP-Austria" not only in European countries. I am about to add it even to my old WT images. -- DerFussi 07:51, 7 July 2015 (UTC)

PS: There are still more than 7.000 images to be checked, e.g. if there is FoP or not c:Category:Files moved from wts.oldwikivoyage to Commons requiring review :) :) -- DerFussi 07:54, 7 July 2015 (UTC)

Time to call your Members of European Parliament! Freedom of Panorama would make things so much easier for everyone. It also has no drawback: seriously, do architects earn their life by collecting a few cents for each picture used in a book or on a website? This makes everyone's life miserable for nothing. Syced (talk) 01:47, 8 July 2015 (UTC)

Apparently mobilization has helped avoid this nightmare. We still need to fight to bring Freedom of Panorama to France and other countries that do not have it. Syced (talk) 08:46, 10 July 2015 (UTC)

Yes. Fortunately. Let's fight it to spread out the FoP all over the world. :) -- DerFussi 09:56, 10 July 2015 (UTC)

There are a couple of related questions, which are as as important. Among them is the rights surrounding works in museums and private collections. Historic photos from most of the 20th century cannot be used if you do not know the author, and public domain works cannot be used as illustrations unless you get a public domain photo (taking it yourself is often prohibited). I cannot even publish my own passport on Commons, as I do not know who the photographer was (I doubt they earn much on people coming back to get more copies twenty years later). --LPfi (talk) 20:07, 11 July 2015 (UTC)

I'd be surprised if the photographer retained a copyright on passport photos. It's a work for hire, and in many cases you're given the physical photograph and the implied right to do whatever you need to do with it. Powers ^(talk) 01:24, 12 July 2015 (UTC)

I would guess (but I am no international copyright expert) that a photo of yourself, that is by definition not a work of art (passport photos have to follow rather strict rules) should be yours to do with as you please. Now the passport itself might be another thing, but not for copyright reasons, as some countries are really strict about passports technically never being any private person's property... Hobbitschuster (talk) 11:53, 12 July 2015 (UTC)

Passport photos are not works, but photos are covered by rights similar to copyright (50 year from creation in EU). There is no such thing as the US "work for hire" in Finnish legislation, and copyright does not follow the physical copy per se. It could, by implicit contract, such as probably when handing over your camera to a stranger, but I would not count on such an interpretation in this case. The Finnish copyright law explicitly gives you the right to make copies of "photographic portraits" in some specific contexts, such as to illustrate articles of yours (unless specifically disallowed by contract). The section would be unnecessary if implicit copyright transfer were the norm. Legally you should contact the photographer and ask for permission to make additional copies – and Commons is strict with nobody caring not being sufficient licensing. --LPfi (talk) 13:54, 13 July 2015 (UTC)

Proposal to create PNG thumbnails of static GIF images

Swept in from the pub

The thumbnail of this gif is of really bad quality.

How a PNG thumb of this GIF would look like

There is a proposal at the Commons Village Pump requesting feedback about the thumbnails of static GIF images: It states that static GIF files should have their thumbnails created in PNG. The advantages of PNG over GIF would be visible especially with GIF images using an alpha channel. (compare the thumbnails on the side)

This change would affect all wikis, so if you support/oppose or want to give general feedback/concerns, please post them to the proposal page. Thank you. --McZusatz (talk) & MediaWiki message delivery (talk) 05:07, 24 July 2015 (UTC)

Tool for finding and removing galleries

Per the image policy, galleries are not allowed, so they should probably be removed. Is there some tool for searching for articles with galleries in them? ϒpsilon (talk) 18:39, 7 October 2015 (UTC)

Galleries are discouraged, not disallowed, per Wikivoyage:Image policy#Montages and galleries. In general I wish we were more consistent in avoiding the wording "not allowed" since we really do want people to plunge forward and not immediately shut down new ideas. -- Ryan • (talk) • 18:53, 7 October 2015 (UTC)

Gyeongju, for example, is an article with a lot of galleries and they show different views of the same attraction, probably "used solely as a way to include a large number of different pictures in a destination article" — something explicitly mentioned in Wikivoyage:Image_policy#Montages_and_galleries. Ireland also has galleries serving the same purpose. It is articles like those I'm looking for. ϒpsilon (talk) 19:09, 7 October 2015 (UTC)

You could you Wikipedia:AutoWikiBrowser to search on <Galley in a page --Traveler100 (talk) 19:57, 7 October 2015 (UTC)

Left-aligned photos

I've always believed left-aligned photos are discouraged if not entirely disallowed, however I just noticed picture alignment isn't mentioned at all in the Image policy. "Left-" is mentioned on this talk page 115 times, notably in #Image alignment above, but apparently no official policy has been created.

The reason why I'm asking is that I was about to tell a certain new user (a veteran Wikipedian BTW) who's added some left-aligned photos to the Uusimaa article they're violating our image policy... but luckily I checked the policy page first.

So, once and for all, are left aligned photos allowed or not? ϒpsilon (talk) 13:50, 25 April 2016 (UTC)

There are very few things on Wikivoyage that are "disallowed". Images are encouraged to be right-aligned, but if there is a good reason for having them left-aligned then there is no prohibition against it. -- Ryan • (talk) • 14:09, 25 April 2016 (UTC)

OK. We should maybe add to the policy page that images should be right-aligned by default. Also, in this case there is text squeezed between photos on both sides, a problem that was also brought up in the discussion above (with Kaunas as an example). ϒpsilon (talk) 14:30, 25 April 2016 (UTC)

I see nothing wrong with left aligned images but I can see your concern with the example give with images left and right at the same document position. Maybe some guidelines on not cluttering an area of the article with images. Spread them out over the whole article (left and right). --Traveler100 (talk) 14:47, 25 April 2016 (UTC)

I plunged forward and updated the guidelines with the proposal that was under discussion above at #Image alignment, minus the first "vertical space" bullet point since that seemed to still be under discussion. -- Ryan • (talk) • 16:34, 25 April 2016 (UTC)

Great! Thanks, Ryan! ϒpsilon (talk) 16:58, 25 April 2016 (UTC)

Our policy on galleries

Swept in from the pub

I have forgotten what our policy on galleries is. In recent edits to Kassel, quite a few of them were added. IIRC we do have a policy of "there is such a thing as too many images", but I have forgotten the details. Hobbitschuster (talk) 17:40, 8 April 2016 (UTC)

Check this out. ϒpsilon (talk) 17:45, 8 April 2016 (UTC)

Thank you. So what should be done in the concrete example? Hobbitschuster (talk) 18:01, 8 April 2016 (UTC)

I think they need to be removed. ϒpsilon (talk) 18:19, 8 April 2016 (UTC)

Could you do that? I am weary of klutzing up the formatting Hobbitschuster (talk) 17:38, 9 April 2016 (UTC)

Done ϒpsilon (talk) 19:03, 9 April 2016 (UTC)

Thank you. Maybe we should communicate with the user who inserted the galleries why our policy exists. I think it has to do with bandwidth considerations, but apparently de-WV has drawn different conclusions... Hobbitschuster (talk) 22:05, 10 April 2016 (UTC)

Given past experience, I'm wary of asking anything relating to galleries :) That said do we have 'any' policy relating to bandwidth as a consideration? I thought that it was really down to aesthetics, with a recent example of someone thinking that 10 different taxi pictures in Singapore was a good idea. --Andrewssi2 (talk) 00:40, 9 August 2016 (UTC)

Yeah, basically it's because galleries usually suck. It's usually far better to have a smaller number of more visible thumbnails than a bunch of tiny photos that are centered and interrupt the text. Ikan Kekek (talk) 05:23, 9 August 2016 (UTC)

Further archiving

I think we should archive more of the discussions on this talk page. But how far should we go? Hobbitschuster (talk) 22:05, 8 August 2016 (UTC)

Minimal use of images - not appropriate

While sometimes too many images for an article with little content can be inappropriate, I generally find that we should not limit ourselves and apply a "minimal" approach as long as we have appropriate, quality images - and even go for lower-quality images. Travel guides need to be visually pleasing, and knowing how a landmark looks like helps locate it a lot more than just a pin on the map (and no, dynamic map images won't do as they don't print out). I find guides lacking images to be incomplete and believe the current wording is simply wrong. We may need a guideline on when not to add an image, but certainly not discourage from adding them. PrinceGloria (talk) 20:27, 29 August 2016 (UTC)

I think nothing you're advocating for here is hindered in any way by existing policy. Our existing policy does not keep guides from being visually pleasing, it does not keep users from knowing what landmarks look like, or forces guides to lack images. Since this is all coming up because of my recent edit to Manhattan/Central Park, let me ask: does the Central Park guide not look visually pleasing to you as is? Do you feel that you lack an idea of what the park looks like based on the images that are there now? Does the guide lack images?

Also, I am absolutely and unequivocally against encouraging people to go for lower-quality images. No freaking way. PerryPlanet (talk) 20:56, 29 August 2016 (UTC)

I agree with PerryPlanet on this. Yes, minimal use of images is outdated and I don't think our current practice is in any way focused on really limiting the use of images all together. Our guides need to look visually appealing - and they do. That doesn't mean that more is always better, though. Personally I find a good number of well-chosen, high-quality images, nicely positioned in the text, much more visually pleasing than a long list of images covering pretty much the entire right side of the article. Images beyond the end-line of the text is a no-go for me too (visually) and lower-quality images should never be encouraged, im my humble opinion. JuliasTravels (talk) 21:23, 29 August 2016 (UTC)

I agree that "minimal" use of images is a wrongheaded idea. Instead, I'd suggest changing the policy to be one of avoiding "excessive use of images", and in particular, images that go beyond what's otherwise the end of the article or that tend to prompt left-justification. Ikan Kekek (talk) 23:42, 29 August 2016 (UTC)

Wrongheaded? Outdated? You guys know we can't be judging our bandwidth requirements on first-world availability, right? Powers ^(talk) 01:16, 30 August 2016 (UTC)

I'm suggesting a change in tone and emphasis from "minimal use of images" to "avoiding excessive use of images". As for slow connections, would it be possible to provide a "safe mode" of imageless articles in such cases? Ikan Kekek (talk) 01:30, 30 August 2016 (UTC)

We might be having different interpretations of the word "minimal", which is understandable since the most literal interpretation of that statement would be zero images (even though that's obviously not the precedent we follow). Perhaps selective is the key word, and is the principle I would most want to emphasize (and is what I believe our image policy has always encouraged): we don't want you to throw images up on the screen for the sake of having images, we want you to take your time, choose images carefully (emphasizing high-quality photos representing a diversity of sights), and strategically place them in order to beautify the page and break up large blocks of text. Which is, in short, what we've basically always done. PerryPlanet (talk) 04:14, 30 August 2016 (UTC)

First, I support the edit you made to the Manhattan/Central Park article. When images go past the end of the article, there are obviously too many thumbnails in the article. But that said, I don't think there's really a viable interpretation of "minimal" other than "almost none". These definitions are from merriam-webster.com:

• a : the least possible <a victory won with minimal loss of life>
• b : barely adequate <a minimal standard of living>
• c : very small or slight <a minimal interest in art>

In practice, we aren't really using a truly minimal number of photographs. So my suggestion would be for our phrasing to more closely reflect current practice. What that amounts to is nothing more than changing the "Minimal use of images" subtitle to "Avoid excessive use of images". Nothing else needs to be changed, though a request for using quality photos and avoiding bad ones would be welcome. Ikan Kekek (talk) 04:28, 30 August 2016 (UTC)

Yes, Ikan. I think you kinda glazed over the main point I was driving at there. You don't need to convince me that "minimal" is a poor choice of words; I was already right there with you. My whole point was that I think selective is a better principle to emphasize than minimal. PerryPlanet (talk) 17:56, 30 August 2016 (UTC)

I didn't get that, no. "Selective" is fine with me, as long as it's associated with using good rather than bad images and doesn't seem to emphasize a restriction in the number of images within the bounds of an article. Ikan Kekek (talk) 18:54, 30 August 2016 (UTC)

"Avoid excessive use of images" is a better expression, "minimal use of images" reads more like avoid adding images unless you have a good reason. In my opinion photos should never drop below the text in the end, cut off level 2 heading lines or be left aligned (especially when there's a photo or infobox on the right side too), because all of these make the article look untidy and broken. Other than that, however, I do think a travel guide should strive to have more photos rather than less, also towards the end of the article. The Manhattan/Central Park article is IMO fine as it is now (though there is absolutely room for one or two more photos towards the end, and if Prince or someone else will expand the article, a few more). ϒpsilon (talk) 04:57, 30 August 2016 (UTC)

I am happy to see we agree on the fact that "minimal" is not an appropriate word. I would also not like to leave it as "avoid excessive use of images", as I don't find images excessive - we need images in articles. What I would find inappropriate are:

1. Images that have nothing to do with the article
2. Too many images of the same thing (User:PerryPlanet accused me of that with regards to Central Park, I may want to discuss, but in principle agree with removals based on that)
3. Poor-quality images
4. Otherwise violating guidelines

And yes, sometimes we will end up with more images than text length-wise, especially on narrow screens, but while aesthetically not pleasing, I still do not find this THAT much of a problem. Limiting the use of good images in an article still not having enough content is not serving the traveller - if they are good, illustrative images then they can somehow make up for the lack of content (not speaking of Central Park here, but rather cases where we have a stubby article but some good photos in the Commons).

I would also support a solution for users with low bandwidth. What I do is simply ask the browser not to load ANY images from all pages, as well as active content (look at the dynamic map), on WV or otherwise. PrinceGloria (talk) 05:40, 30 August 2016 (UTC)

I strongly disagree with allowing images to go below the end of the article, and I don't think you'll get a consensus behind that. Yes, it is sad to exclude beautiful photos from articles, but the reason they can't be included is that the content of the articles in question isn't long enough. And in that case, there's a link to the Commons category, so viewers can easily see more images. Ikan Kekek (talk) 06:05, 30 August 2016 (UTC)

I respect your point, but please do consider that it is very hard to ensure pictures will not run longer than the body in all possible screen resolutions. PrinceGloria (talk) 06:39, 30 August 2016 (UTC)

Understood, but as this is a guide anyone can edit, anyone is free to delete the last thumbnail if it runs over for them. Ikan Kekek (talk) 07:16, 30 August 2016 (UTC)

Indeed; pictures should simply not run beyond the body of the text on any reasonable screen. It makes the layout look completely unprofessional. Avoiding excessive use is not only about avoiding inappropriate images in the sense mentioned above. Too many similar images discourage average readers from really looking at them. This was definitely the case in the Central Park article, for me. When the whole right side is more or less covered in park images, I end up hardly looking at them. Images should be interesting and high-quality. We don't want boring and geeky images of highways, trains and tickets in our get-in sections simply because they are not "inappropriate" or violating guidelines. The very idea that more images by definition make a layout more pleasing or modern is simply outdated, especially in our style where all images are the same size and on the same side of the text.

As for the bandwidth issue, I do think it's less of an issue than it was a few years ago, since under the Wikimedia service the text simply seems to load first automatically. I encountered no problems the last time I was on very low bandwidth. The images would take longer to load, but that didn't keep me from reading the article.

I support changing the wording of the "minimal use" into "avoid excessive use". I don't think that is any change in actual practice. I do wonder sometimes if we shouldn't have a more visible link to Commons. We find it perfectly normal that a nicely visible link to our articles is placed under every WP-article, but we need to hide all links in the left hand bar. I tried people around me and a class in that respect, asking them to read an article and then find more info. Almost all or them opened Wikipedia in a new window, missing the whole link on the left. Would there be any way to test the use of the links, comparing the ones we have and a more visible sister-project link at the bottom? Just a thought. JuliasTravels (talk) 08:32, 30 August 2016 (UTC)

Julias, I remember there was a proposal recently to put the official destination link and the Wikipedia/Commons link in a nicely visible box, although the discussion kinda died due to general lack of interest. Still, if you're interested, might be something to revisit. PerryPlanet (talk) 20:19, 30 August 2016 (UTC)

I thought the Wikipedia extension had been approved. In any case, I very much support also linking Commons by default. Ikan Kekek (talk) 18:03, 31 August 2016 (UTC)

While it's true that an image is helpful in locating a place, our added location coordinates are even better and it is not a goal of ours to provide images of all locations, which means some will have to be left out. Leaving images out is not a bad thing. The current Manhattan/Central Park still has too many pictures. Looking at length of the article and the breakdown, I'd say no more than 3 pictures in the "See" section and delete the picture titled "The Lake" in the "Do" section as the other do picture with the runners seems to feature the same lake with the same buildings in the background. Central Park is a park, and regardless of how big it is, most people know what a park is and what sorts of things parks have (trees/lakes/ponds/nature/monuments), so just a few pictures that show its beauty and character will go a lot further than a lot of pictures that I think can have a watering-down affect similar to montages where everything starts looking the same to the point where it actually looks uninteresting. ChubbyWimbus (talk) 15:01, 30 August 2016 (UTC)

I love Julias' and ChubbyWimbus' point about avoiding similar images. I think aesthetically we're coming at this from a "less is more" perspective; a few really striking images go a lot further for us than a big line of images showing almost every single attraction. PerryPlanet (talk) 20:16, 30 August 2016 (UTC)

I disagree, I don't travel with a GPS and locate my landmarks by coordinates, I rather plan out a route to see them along the way and prefer to know how they look rather than guess if my coords are right. A photo tells a thousand words and while I may read that some fountain is nice or a hill in the park is great, I'd prefer to know how it looks like. When I choose print guides, I always go for Dorling Kindersley's Eyewitness, and it's for the pics more than the words - I need the text to link the pics to locations, that's all. It would really be hard to convince me to go to a location with only minimal amount of pics, and every pic, as long as it is nice, helps. PrinceGloria (talk) 21:08, 30 August 2016 (UTC)

If the photos are good, and especially if they're really good (e.g., Quality Images or Featured Pictures on Commons), within reason, more is more. Ikan Kekek (talk) 03:32, 31 August 2016 (UTC)

"Less is more" is definitely the goal of the policy and one I support. "More is more" doesn't sound good to me at all. That way of thinking would mean that the Central Park article should have over 40 images. It doesn't need that, and if the traveler requires that many images to make up their mind to go or not, they should probably do their own in-depth research or just not go. Most of the pictures just drive home the point that "this is a park". It has 2 fountains (parks have fountains), 5 pond pictures (If you've seen one, you've seen them all), 2 trees (how many parks don't have trees?), a gift shop, a castle (a unique point), and a museum picture (you'll already have to be in the museum to see that image, so not helpful in locating the museum itself). The banner is open space, like most parks have. Central Park is more than illustrated by the photos there (overillustrated). If those pictures bore you, adding 30-something more images is going to really put you to sleep! It doesn't need all that.

While some travelers like to have practically already visited before they arrive, others feel that spoils the experience. Either way, our images are not placed in the articles for navigation purposes. If that is wanted, you'd have to propose a reformatting of the entire WV article format to something like Japanese WT which does require photos of every listing.

As always, we can't please everyone. We aren't a photo gallery, nor are we able to write the entire history of every location with every permanent exhibit of every museum identified and explained, etc. While visually pleasing and good for people who are more visual, the Dorling Kindersley guides do sacrifice variety. The places they feature are quite select, so if you have any interest in catering to personal taste or just doing anything that every other tourist is not doing, they tend to be of little use. Also, as you said, if you have any intellectual interest in the locations, they do not really deliver. To me, those guides are good for garnering interest in the destination but after that, another guide is necessary to actually plan a trip. This site's goal is to be the only necessary source to plan a trip, so we need text much more than we need many pictures. ChubbyWimbus (talk) 12:59, 31 August 2016 (UTC)

Let us leave Central Park aside, as it is just one of the articles. To you, maybe "a park is a park", to me perhaps "a museum is a museum" - but I'd rather we elaborated on and illustrated what the museum is about than applied personal preference and decreed that the user should check the museum's web page themselves and info that "it's a museum" would be sufficient. I see no reason to specifically deprive users of information and aesthetic experience.

Again, I do need pics as much as I need text. I need to know how the landmarks and neighbourhoods look like, I want to see which train and bus is which, and how to find an entrance if it looks in a specific way. To me, simple text is not enough. Otherwise, I'd bought Pascal, and I always go for Dorling Kindersley. I believe we should respect the fact that some travellers are like that. PrinceGloria (talk) 14:47, 31 August 2016 (UTC)

I acknowledge that some travelers prefer pictures and that visual directions can be useful, but can we agree that WV isn't designed to show pictures of the proper door to enter a specific attraction even if it is helpful? You're also talking about many different uses for pictures, each of which would likely require its own image; page aesthetics, pictures of the neighborhoods/boroughs, substitute/enhancing directions, the appearance of each bus/train line in order to minimize confusion... This sounds like multiple pictures for everything: A picture of the museum so that we know what it looks like, a picture of what's inside for intrigue/aesthetics, a picture of the museum's entryway, maybe the nearest bus stop, the neighborhood it's in, etc. There's no way we can reasonably accommodate you the way that you want. It would make the experience for most people horrific and all of those navigation images would also be very unattractive.

I would support changing the wording to "avoid excessive use", but in your case, with all of the pictures you'd like to see added, I don't think there would be any such thing as "excessive use"... ChubbyWimbus (talk) 15:18, 31 August 2016 (UTC)

I think we may be having too much of a theoretical discussion. I'm concerned about appeals to a "less is more" aesthetic that I fear could bias things too much against the insertion of thumbnails of good pictures; you're concerned about a "more is more" aesthetic producing an extreme glut of pictures. I'd rather just agree on a wording to avoid excessive use of pictures and encourage a search for good photos (particularly Featured Pictures, Quality Images and Valued Images on Commons, when available), and then leave each article open to discussion when there isn't an obvious situation for reversion such as existed after PrinceGloria's edits to the Central Park article caused numerous images to go past the end of the article. Ikan Kekek (talk) 18:02, 31 August 2016 (UTC)

I would agree with you (and I'm definitely fine with adopting the wording "avoid excessive use of images"), except I think that this discussion is actually quite important because there seems to have been a shift in the justification for this policy. Until now, the argument for avoiding excessive use of images has been based pretty much solely on bandwidth concerns, something that has barely been brought up in this discussion (and has even been stated to be less of a problem now than in the past). So if not bandwidth concerns, what exactly is the basis for our policy of avoiding "excessive use" moving forward? To me, it looks like it has to be based on aesthetic concerns if we're not leaning on the bandwidth argument anymore (even restricting images from going past the end of the text is an aesthetic concern). So then the question becomes, what are our aesthetic concerns?

I think I can safely say that no one here is interested in setting a hard limit on the number of images a guide should have, but we might want to find something a little more specific than "find quality images", particularly in the case of heavily photographed attractions where there might be literally dozens of Quality or Valued Images on Commons. PerryPlanet (talk) 19:01, 31 August 2016 (UTC)

If I might illustrate why I want something a little more specific in defining "excessive use", let me point to a different example that's slightly less obvious than Central Park: Manhattan/Midtown East. Here, literally almost every single See listing has an image. The images may not go past the line of text, since Midtown East has nice long Eat and Sleep sections, but they do make it well into the Eat section on my screen. Do we consider this excessive use? PerryPlanet (talk) 19:14, 31 August 2016 (UTC)

I agree with you that this may be excessive, and some of the thumbnails could be removed. As a native New Yorker who spent 5 years going to schools in Midtown (though admittedly west of 5th Av.), I don't know where Greenacre Park is and don't find the photo of it compelling, I consider the photo captioned "The crown of the Chrysler Building towering over the neighbourhood" unnecessary because we already have a "Midtown skyline" panorama featuring the Chrysler Building and a photo of its doors, and there are a couple of other photos I could take or leave. In terms of finding quality images, in cases of attractions that have a lot of good photos on Commons, naturally, only one particularly good and helpful photo (or perhaps two, if it's important to show a detail or other view) should be used. If you feel like that needs to be clarified, do so, but I think it's unusual for multiple photos of the same view to be used in a single article. Another issue that crops up somewhat more often is the use of the same thumbnail in different articles. I would propose that we avoid that whenever another good photo of the same attraction is available, but I'm not sure this is essential to address as a matter of policy. Ikan Kekek (talk) 19:32, 31 August 2016 (UTC)

(edit conflict) This is mostly an aesthetic issue, yes. I do find it a bit ugly when photos cross the lines of level 2 headings, which is something that happens many times in the Midtown East article. However, it's good having photos also in sections further down (in this case some of the photos there could be moved down to the bottom half of the Eat and Sleep sections). ϒpsilon (talk) 19:42, 31 August 2016 (UTC)

As you may guess, I did put those images there as I am editing those guides with the view of using them for my upcoming trip to NYC. This is perhaps not a featured picture of Greenacre Park, but then either we don't consider it worthy of a listing or IMHO it needs an illustration - I believe we need at least a photo each for every "See" entry. I, for one, love small urban parks and plazas and consider it potentially adorable, I want to know how it looks like not to miss it and to know how to distinguish one from another (there are more I believe, I plan on adding listings once I do my research).

Also consider our mobile version - there, the pictures appear exactly where placed in the text and this is very helpful if every entry has a photo above it or below it (I prefer above for desktop/tablet layout issues), and I do actually use WV mobile while I am travelling, which is what I guess we all hope more and more people will do. PrinceGloria (talk) 19:47, 31 August 2016 (UTC)

PS. I consider it an aesthetic enhancement actually when the picture breaks the gray line, this is how many modern newsletters are laid out those days.

I don't agree that every "See" listing must or even necessarily should have a picture, or that if we decide to omit a picture, its "See" listing should be deleted. There are articles with dozens of "See" listings or more, not to mention that panoramas or pictures of activities, notable hotels or restaurants may sometimes be advisable to include. Ikan Kekek (talk) 21:12, 31 August 2016 (UTC)

Ikan, you make a good point that multiple photos of the same attraction is a rare enough occurrence that we probably don't need to address it in policy, so I'll let that drop. Anyway, I was wracking my brain and it occurred to me that the specific aesthetic concern I have with the Midtown East article right now is that there's so many images that I have to scroll way down to see the picture of the thing being described. So with that in mind, I would like to propose adding the following to our policy:

In general, we prefer that images be aligned so that they appear next to the text describing whatever it is that the image is illustrating. Unfortunately, this often means that not every attraction in a given destination can be illustrated. So be selective in your choice of imagery: focus on the visual highlights of the destination and use high-quality photos whenever possible.

This, as a matter of practicality, would address many of my concerns without placing any kind of hard limit on images. It's also already standard practice; this is just rooting it in a specific aesthetic concern. I also made a point of expressing it as a generality up front, which leaves some leeway; if you want to put some nice pictures down near the bottom of the article and don't have any particularly photogenic restaurants or hotels to illustrate, you should be able to do that. Thoughts? PerryPlanet (talk) 21:42, 31 August 2016 (UTC)

I oppose this because it would mean crowding all the images in the "See" section. Ikan Kekek (talk) 23:49, 31 August 2016 (UTC)

I think Ikan is right, and I think we should keep policies as general as possible to allow users to find the best options by trying it out. Also, we want people to pick images that are interesting or beautiful, not images that happen to fit the line-out. I also think this discussion is getting too broad. There's clearly no consensus for an overhaul of our current policy, and frankly, I don't think we need to change everything. It's clear that the most traditional reading of "minimal" images is no longer supported by consensus, so let's change it to the "avoid excessive images" line - and leave it at that. There's clearly no consensus to shift to a "more is more" policy, though, no consensus to encourage images of lesser quality and no consensus to allow images to continue below the text body. The exact number of images that is most aesthetically pleasing will always be a matter of taste, and our current practice of discussion and finding middle ground seems the best way to continue for now. JuliasTravels (talk) 08:25, 1 September 2016 (UTC)

Yes, "avoid excessive images" seems to be an uncontested word change. With that said, both of the articles cited above need to be sorted through and images removed, with Manhattan/Midtown East needing many/most of its images removed. Neither of those satisfy the current or proposed policy. ChubbyWimbus (talk) 12:46, 1 September 2016 (UTC)

I don't understand the problem with the word "minimal". It does not mean zero, as someone asserted above, because we deem the presence of images to be necessary to achieving our goal of creating an outstanding travel guide. What "minimal use of images" means -- and has always meant -- that we should be circumspect when adding new images. To quote from the original text: "This doesn't mean that 0 images is preferred to 1 image, but that no more images than are necessary to get across a point or impression should be used. 14 different photos of the Statue of Liberty don't really help travellers any more than one photo does. Not every street, hotel, restaurant, town square and statue needs to be memorialized with an image." —The preceding comment was added by LtPowers (talk • contribs)

It is clear that no proposal to mandate an optimal number of images is going to succeed. I would just rewrite this section to say something like "Articles should contain sufficient images to convey the major attractions of the destination. Multiple images of the the same or similar subjects are discouraged."

Specific policy is not really needed. For example somebody added 10 different pictures of Taxis to Singapore because they believed it useful, but most of them were images were removed on review. No harm done.

As far as I know, people aggressively adding images is a rare case here anyhow. Andrewssi2 (talk) 00:31, 2 September 2016 (UTC)

In many cases, the major attractions can't be pictured, either because there isn't much text or because there are too many major attractions. In any case, the problem with the word "minimal" is its dictionary definition. Simple as that. Powers, do you really object to "Avoid excessive images"? Ikan Kekek (talk) 09:13, 2 September 2016 (UTC)

(indent) The rarity of people aggressively adding images isn't really what we're debating. The OP has already "aggressively added images" to make the New York pages his own best guide and is pushing for us to change the policy to accommodate a more image-based guide, so we're responding to an actual change of policy proposal, not a hypothetical situation. For me, I cannot support an image-heavy/based/focused article. It's unattractive, distracting, and looks both unprofessional and even touty. For the record, while I don't mind "avoid excessive images", I also don't mind it as is. Minimal does have a stricter tone to it, but "avoid excessive images" is easier to twist into a liberal interpretation, as PrinceGloria has outlined his own interpretation that it would mean everything is okay as long as it is actually located in the city, isn't already pictured, isn't against policy, and is of high quality. That's a lot of pictures... ChubbyWimbus (talk) 11:44, 2 September 2016 (UTC)

I agree with you. Ikan Kekek (talk) 00:08, 3 September 2016 (UTC)

I did not know I am a "person aggresively adding images", but I guess by this definition I am. Do you believe this: is not a guide? I would be most perplexed if you'd rather have a text-only Pascal, but perhaps you would... PrinceGloria (talk) 08:48, 3 September 2016 (UTC)

Sure it's a guide, as were the Touring Club Italiano guides I used for Firenze e dintorni and Toscana (the latter of which covered all of the region other than Florence and environs), which identified every single artwork on every wall of every church, internally and externally, and the name and architect of every building on every street but didn't show pictures of any of them. I think that what you are finding in this discussion is that most of us want this site to be somewhere in between the two extremes.

I feel like you've been doing a lot of great work and that many of the images you've inserted are excellent and helpful. However, in some cases, I don't think you're being selective enough - not surprisingly, really, since you actually called for using poor-quality images. I spend a fair amount of time on Wikimedia Commons, looking through a lot of very good photos and searching for the best ones to promote to Featured Picture. You may notice that I also often insert thumbnails in Wikivoyage articles. They are almost always either specifically cited on Commons as Featured Pictures, Quality Images or Valued Images or simply good pictures. However, when I see that there isn't room, I don't insert a thumbnail. Sometimes, when I really like the photo, I'll link it on the talk page and mention that if more text is added to the article such that there's room, it would be great to add such-and-such a photo later.

I really like photos, but I find it a little mind-numbing to look at Manhattan/Midtown East, the way it is now. And I'd like to suggest to everyone to think about the Venice article by analogy. There's a lot to see in Venice, and the article is quite long, with a fair number of photos. Now, imagine if there were an unbroken stream of photos on the right margin, from the beginning of the article to the end. Perhaps you'd like that. I think it would be awful. I do think a few (I'm thinking perhaps 3-5) more carefully chosen and well-placed photos could be added to the Venice article, since it's so long, but there really is such a thing as going overboard.

Think about this, too: We seek to make Wikivoyage articles different from the more nearly exhaustive encyclopedic content on Wikipedia. By the same token, Commons exists as a repository of images. Do we want to make our articles simply resemble the entire contents of a Commons category plus text? I don't think so. I don't think Wikivoyage is meant as an exhaustive exhibition of images about anyplace. Nor, frankly, is it meant as an online version of Eyewitness guides, Michelin guides or any other type of guide. Ikan Kekek (talk) 09:06, 3 September 2016 (UTC)

TYPO: I meant to write "is this a GOOD guide" :) Yes, I'd like an unbroken stream of images. I cannot get excited about a destination without pics (and I may be a pervert, but I need a lot more than 3-5 pics), and I do not feel like I need to look up pics of stuff outside of theoretically self-sufficient Wikivoyage guide. I feel like we are very close in almost every respect (except for layout, due to our inherent flexibility) to DK's Eyewitness, who IMHO have cracked the perfect formula for the travel guide (and if you know them you'll agree that they stop far short of listing every painting or such, they are good all-rounders), and I feel we can take this formula one step farther with our crowdsourcing of ever-expanding content and everything else that online brings (e.g. dynamic maps), but this formula has pics. Loads of them. PrinceGloria (talk) 09:18, 3 September 2016 (UTC)

I think I come closer to your ideals than others who have participated in this discussion, but obviously, I differ strongly with you, if you want to have an unbroken stream of pictures at the right margin of every article on this site from beginning to end, and no-one else agrees with you so far, so in the spirit of Wiki, I think you should restrain yourself somewhat and compromise a bit (which means accepting the removal of some thumbnails from Manhattan/Midtown East, for example). I might say, too, that from what I saw of that Eyewitness guide, it didn't have an unbroken stream of images on every page, either. Ikan Kekek (talk) 09:25, 3 September 2016 (UTC)

Side point: I think you misread my use of "3-5" in discussing the Venice guide: That's 3-5 more photos, not 3-5 total. But my rule of thumb about the number of pictures would be (a) if an article is really short, no more than 1-2 photos will even fit; (b) in long articles, try to have a photo in every screen (thinking in terms of laptop readers, et al.) but allow a bit of space between at least some photos, to give the reader some relief. You don't want relief, so look at a Commons category as a slideshow. :-) Ikan Kekek (talk) 09:31, 3 September 2016 (UTC)

You are right, I strongly disagree. I thought about removing myself from WV for some time due to many factors, and I guess this is a good point. PrinceGloria (talk) 10:15, 3 September 2016 (UTC)

I would greatly regret your removing from yourself due to a need to compromise somewhat on a Wiki. But do you realize that you're making it sound like you as an individual should have the power to hold the rest of us hostage, in a way, by having a "my way or the highway" attitude? Wikis aren't individuals' projects but collective projects, and that means that everyone has to accept certain collective decisions s/he disagrees with, or there will be no project. I hope I'm misreading your tone or that you reconsider. Ikan Kekek (talk) 17:57, 3 September 2016 (UTC)

Just for the record, this is not an ultimatum, just a constation. I guess I should have kept it to myself. It is just something I feel strongly about enough to make me have little satisfaction from further contributing knowing I go against other's convictions and I will see my edits reverted, so it is just a good moment to devote more time to other stuff. No big whoop, discuss amongst yourselves ;) PrinceGloria (talk) 19:00, 3 September 2016 (UTC)

I'd definitely identify with the 'less is more' point of view, however I do not see a great issue with the image volume in Manhattan/Midtown_East . I could easily see removing 4 of the less interesting ones in order to lighten the load, but no great urgency around it.

Could we not just recommend the use of itineraries in the case that a contributor wants to provide a photo heavy experience? Then we actually get a best of both worlds scenario. Andrewssi2 (talk) 04:06, 4 September 2016 (UTC)

It looks like this discussion is winding down a bit, and I'm not sure if we even have a strong consensus to change the name of the section to "avoid excessive use of images". LtPowers doesn't seem to on board for that, and ChubbyWimbus makes the good point that "avoid excessive use" lends itself to more liberal interpretation. Personally, while I'm not necessarily opposed to changing the name, I wouldn't feel very comfortable doing so without some clarification of what we mean by "excessive use", and it looks like any effort to define that is going to get about as far off the ground as a SpaceX rocket.

Another possibility is that we could keep the existing section name, but add a little more language explaining what we mean by "minimal use". This could be as simple as restoring some of the original text LtPowers cited above. At any rate, the use of the word "minimal" hasn't prevented us from adding pictures to our guides, and I doubt it will moving forward. PerryPlanet (talk) 18:33, 4 September 2016 (UTC)

My opinion, don't know if everyone or anyone agrees: "Don't use photos excessively — they shouldn't be crammed in like sardines. There should never be more than 2-3 photos immediately after each other and with no space between them. Also, photos dropping below the text at the bottom of the article, cutting through level 2 heading lines or having to be left-aligned to fit in are signs that there's a too large cluster of photos. However this doesn't mean you should avoid adding photos — after all this is a travel guide. It's preferable that readers at every moment see one or two photos (also in the lower sections, which often are entirely void of photos), or at the very least a part of a photo. " ϒpsilon (talk) 19:00, 4 September 2016 (UTC)

I think these are good guidelines. I wouldn't make them hard and fast rules, except for not having photos after the end of the article, but I would like for them to be included as advice. Ikan Kekek (talk) 21:00, 4 September 2016 (UTC)

For the record, the images on Manhattan/Midtown East extend past the end of the text for me. It's way too many. I agree with ChubbyWimbus that "avoid excessive use" is more liberal and so I don't think it's an improvement. "Minimal" means "the least necessary", and some images are necessary in a travel guide (as User:PrinceGloria can attest). In fact, I would go so far as to recommend reversion to the original text of the section, to which I linked above. I think it is clearer that anything else proposed so far, including that used in later revisions of the policy page. Powers ^(talk) 22:52, 4 September 2016 (UTC)

The least necessary is none. A guide can be perfectly informative, though unattractive, with no pictures whatsoever. Ikan Kekek (talk) 07:59, 5 September 2016 (UTC)

I strongly disagree, and so did the original authors. Note the original text: "no more images than are necessary to get across a point or impression should be used" (emphasis mine). Powers ^(talk) 18:04, 5 September 2016 (UTC)

I previously mentioned the Touring Club Italiano guides. Other than basic information like diagrams of the overall shapes of some churches, those guides had no graphics whatsoever, but what they did have was very specific descriptions of every building, every carved figure on the exterior of every church, every artwork inside every church, and the precise positions of same. It was a terrific guidebook for the things that were most important to me at that time (early to mid 90s). It's not necessary to have photos; it's a style choice. I support the choice, but I don't have any illusions about its actual necessity. Ikan Kekek (talk) 19:11, 5 September 2016 (UTC)

You're missing the point. We've deemed images necessary to our purposes. They are necessary for the type of travel guide we're charged with writing, i.e., nicely illustrated ones. That it's strictly possible to write a travel guide without photographs is beside the point; our guides need photos. I don't think you'd get an article to Star without photos. Powers ^(talk) 14:43, 6 September 2016 (UTC)

I don't think I've missed the point. I think that what you said - that "we've deemed images necessary to our purposes" - is functionally the same as my saying that having images is a style choice (which we've made). We may express things differently, but we aren't really in disagreement that images should be used. If anything, I might sometimes want more of them than you do. Ikan Kekek (talk) 22:29, 6 September 2016 (UTC)

Well, yes, we agree about that. But you seem to think that the current "minimal" wording could mean "zero". While that's true without context, I think in the context of this project (and with the context provided by both the edit history and current text of the policy section) it's clear it doesn't mean "zero". Powers ^(talk) 13:47, 7 September 2016 (UTC)

If not zero, it could mean 1-2 images for a long article. That's truly minimal. Ikan Kekek (talk) 20:05, 7 September 2016 (UTC)

In proper context, no, I don't think it could. Powers ^(talk) 21:17, 7 September 2016 (UTC)

I strongly disagree. We are using a word in a way contrary to its dictionary definition and normal, almost universally understood usage. You're looking for a phrase like "adequate, but not excessive" or "sufficient to provide a selected taste of the destination", not "minimal". Ikan Kekek (talk) 21:45, 7 September 2016 (UTC)

Clearly even experienced editors disagree about the meaning of "minimal" - what hope has a new contributor for whom English is a second language? Let change to "selective". We could back this up with some number suggestions- if there is less than 3k of text then 3 images is probably enough, with another image for each 2-3k of text. AlasdairW (talk) 22:31, 7 September 2016 (UTC)

Thanks, AlasdairW. I like the idea of specific suggestions. Ikan Kekek (talk) 22:51, 7 September 2016 (UTC)

(indent) I think "Minimal" is being used appropriately, because we have context as Powers stated. Honestly though, if a user refrains from adding an image, it's not a big deal. Another user can add an image, and we have plenty of featured articles and star articles to reference for those who are overly concerned about breaking this particular policy. I think pointing them to those articles would be much more helpful than trying to pin how much you need to add to an article before you can add another picture... ChubbyWimbus (talk) 15:35, 9 September 2016 (UTC)

I still dissent on using the phrasing "minimal use of images", because if we really had such a policy, it is routinely honored in the breach. It's as if we had a policy of "use minimal speed" on highways and routine practice was to drive 100 kph/60 mph without raising an eyebrow. I'd rather accurately name the policy and accurately describe what it is. Ikan Kekek (talk) 02:18, 10 September 2016 (UTC)

If we have articles with the equivalent of 60mph worth of images on them, then they probably need some reduction. Powers ^(talk) 15:34, 10 September 2016 (UTC)

No, I think the problem would be if they had 120mph worth of images; 60 mph is in fact a normal highway speed limit. :-) Ikan Kekek (talk) 19:49, 10 September 2016 (UTC)

We have a lot of articles (outline and usable) which have no images. In most cases these would really benefit for the addition of one or two images. Our current "minimal" deters the occasional editor who has just been to the city/village from adding a photo, and in some cases commons will miss out also. Yes another user can add an image, but it is best done by somebody that has been there. AlasdairW (talk) 21:09, 10 September 2016 (UTC)

This has become a time-consuming discussion about basically nothing. It has turned into a discussion where only one or two long-time users are scared to change the wording of a policy, even when a dozen others indicate that they find it confusing and not in line with practice, because they fear that it will somehow lead to a huge loosening of the rules. It doesn't, though. How we, as a community, interpret the policy remains a matter of general consensus. Both "minimal use" and "avoid excessive images" call for a good deal of interpretation. It has become very clear that there's no consensus to change our common interpretation of the policy into anything resembling a "more is more" approach - and that's that for now. But why resist the change of wording so strongly when it is considered to be clearer by the majority of users? Frankly, I don't get what all the fuzz is about. Reaching consensus is about giving in sometime, too. In this particular case, that should be easy, since nothing really changes in practice. JuliasTravels (talk) 21:25, 10 September 2016 (UTC)

(indent) JuliasTravels, I suspect I'm one of the people you believe is needlessly holding everyone back, but if you read more carefully, I stated that I didn't mind changing it. However, the OP's belief was that "avoiding excessive use of images" meant essentially just not repeating images of the same place. That's problematic and if that's an interpretation taken from the policy discussion, there is reason to call the change into question. Also, although I agree that there seems to be a consensus to change the wording, I disagree that anyone in the discussion is actually confused by the current wording. I have not noticed anyone going on an all-image deletion spree because of their belief that "minimal" means "none".

The issue as I see it is: Does changing the wording from "minimal" to "avoid excessive use of images" better clarify the policy? You claim that it's "clearer", but the discussion seems to suggest that at best it doesn't clarify anything (which then begs the question "Why change it?") and at worst, it actually makes the policy less clear, in which case there is no logical reason to support the change. I'm not against changing the wording, but I am against changing policies because we're bored or we've gone down the rabbit hole of "what if"s with everyone in the discussion understanding the policy (and yes, everyone seems to understand it well as written) but acting as representatives for millions of hypothetical users who are super paranoid about breaking this policy and are actively seeking this policy page. If you happen to know of the perfect wording to close the discussion, please propose it. I suggested we find some articles that we feel exemplify our intent and direct users to them, and even provide a bit of commentary about why they exemplify our goals, but no one responded to that. Maybe no one saw it or maybe at this point the goal is just to change something and not to clarify anything. Remember, the OP makes the strongest case AGAINST the cuurent word change proposal, but the OP is in SUPPORT of the change...

I would like to also request once again that we assume good faith. I can only speak for myself, and I stated from the beginning that I'm not against changing it. I just want a sensible change and if it's not sensible, then I oppose change for change's sake. I am not a wall standing in everyone's way of "excellent policy reformation". I'm open, so I don't appreciate being accused (again) of being an obstructionist. If I am not who you are referencing, it still highlights an issue with broad accusations. If you feel there are users who are not open to any change, it's probably better to ask than to accuse. ChubbyWimbus (talk) 13:32, 11 September 2016 (UTC)

I saw your remark about star articles, but the thing is, they're subject to editing, too, as happened recently to Paris/1st arrondissement in preparing it for its DotM feature. I wonder if you or Powers feel that article has too many images now. Ikan Kekek (talk) 19:49, 11 September 2016 (UTC)

Good heavens, yes. That's way too many images. It didn't have that many when it was elevated to Star, did it? Powers ^(talk) 23:31, 12 September 2016 (UTC)

I doubt it. I added some images and User:PrinceGloria added more. I'm not upset with the number of images but could do without the ones captioned "Enjoy your meal in the shade of one of the many arcades in the district", "Rue Rivoli at dusk", "A cafe with a view of the Louvre", and possibly "Place Vendôme in the evening". I proposed to remove "The Thrill is Gone", but I conceded on the points that were made on the article's talk page; see Talk:Paris/1st arrondissement#Business photos. Ikan Kekek (talk) 00:25, 13 September 2016 (UTC)

Well my concern is that it's essentially a solid wall of photographs along the right hand side of the page. I can conceive of a travel guide deciding to use that as their standard format, with a separate right-hand pane for photos (perhaps independently scrollable), but that's never been our preference (and I think goes against both the spirit and the letter of both current and proposed policy wording). I think the wall-o-photo approach is visually overwhelming to the reader; a more carefully curated selection of photos (preferably with larger photographs) would be more visually appealing and informative. Less is more. Powers ^(talk) 01:46, 13 September 2016 (UTC)

I've given you some suggestions, in case you'd like to remove some of the thumbnails. If you would like to do that, I recommend posting to Talk:Paris/1st arrondissement and pointing to this discussion. Same with Manhattan/Midtown East. Incidentally, I have DSL, and I'm finding that with all those images, not all of them download the first time and I sometimes have to reload the page to see them all, so with this many images, it seems like the original issue of download times remains relevant. Ikan Kekek (talk) 03:13, 13 September 2016 (UTC)

(indent) That's a fair point that someone could add photo spam to our examples. I still think having examples is a good option. I feel like most users who care about the policy enough to find it will also be savvy enough to find star and guide articles to use as examples. But where are we at exactly in this discussion? Do people still want to change the wording? If so, do we have options or just "avoid excessive use of images"? If we do use that, we need to address some of the issues it seems to create. As a sidenote, since PrinceGloria has made it clear that s/he is no longer interested in being involved in this discussion, I think we should stop tagging him/her. It may start to feel rather patronizing, especially since it's abundantly clear that the user's proposal has been rejected. ChubbyWimbus (talk) 11:15, 13 September 2016 (UTC)

All good points. I don't see anything to disagree with.

It looks like there's pretty much of a consensus to avoid a long, unbroken stream of images, so that's a specific that could be added by way of clarification. I think most of us would also agree that the images shouldn't all be bunched up in the "See" section. Other than to mention that no image should extend beyond the end of the page and that images should not be justified left or center without a compelling reason to do so, these are probably the only things that need to be mentioned in terms of the number and placement of images. It should also be emphasized that whenever possible, high-quality images should be used. And once we make all of this clear, how about "avoid excessive or unselective use of images"? It's longer than "minimal use of images", but in conjunction with the kinds of guidelines I lay out in this post, isn't it clearer? Ikan Kekek (talk) 11:30, 13 September 2016 (UTC)

Resolution?

It looks like this discussion was dropped, rather than really resolved (and parenthetically, that Paris/1st arrondissement may still have too many images). I think it would be helpful to add guidelines like: "Short articles should have no more than 1-2 images", "For longer articles, 1 image per screen is generally adequate", "Try to avoid having more than 2-3 images in a row without space between them" and "Make sure no images extend below the end of an article". Do you all agree on such guidelines? Let's discuss that first before considering whether to reopen the more general language ("minimal", etc.). Ikan Kekek (talk) 08:49, 13 May 2018 (UTC)

Those sound fine to me, though I'd replace "2-3" with just "two". Pashley (talk) 09:50, 13 May 2018 (UTC)

Those are generally good. I would make two changes - clarify whether static and dynamic maps count as images, and clarify that these are guidelines, not absolute limits "Short articles should usually...". I think that occasionally it may be useful to exceed the guidelines in a travel topic - 4 photos may be the right number to show how to do a four step process, and I would rather have "too many" images in a short well written travel topic than have a load of waffle added to increase the text length to "allow" more images. AlasdairW (talk) 21:40, 13 May 2018 (UTC)

I agree, and maps are images. Ikan Kekek (talk) 23:47, 13 May 2018 (UTC)

I support this these additional guidelines. Ground Zero (talk) 00:27, 14 May 2018 (UTC)

It looks like no-one ever inserted these, even though we agreed on it. Shall we add them to Wikivoyage:Image policy#Minimal use of images or put them in some other subsection? I think this is the agreed-upon form of words:

• Short articles should usually have no more than 1-2 images, including a map.
• For longer articles, 1 image per screen is generally adequate.
• Try to avoid having more than 2 images in a row without space between them.
• Make sure no images extend below the end of an article. Ikan Kekek (talk) 08:37, 14 October 2018 (UTC)

I completely missed this discussion earlier, so my apologies for commenting at the 11th hour, but I don't completely with the proposed wording.

• How long is a 'short' article'?
• What size screen are we referring to? A single image will take up much more room on an 11-inch laptop than on a giant monitor. This issue would also apply to whether images extend below the end of the article.
• I occasionally like to add images in rows of 3, if I think they fit well within the article. Will we now have image police enforcing this policy, removing any third image they may find in a random article?

–StellarD (talk) 09:20, 14 October 2018 (UTC)

To answer your third question first, these are just guidelines, not rules, and won't be likely to affect the likelihood of someone doing anything. To take your second, I think most people edit either on laptops or cellphones, nowadays, but if the last image goes lower than the text on whatever you're using to view the article, delete it. I can't see trying to precisely define what a short article is, but basically, we're talking about articles without much content that don't have room for more than a couple of images. Ikan Kekek (talk) 09:41, 14 October 2018 (UTC)

You know, StellarD, I don't get why your response is to question what would be done to you. Why don't you propose different guidelines if you don't like the ones we've come up with? Ikan Kekek (talk) 11:06, 14 October 2018 (UTC)

To try to put some numbers to this, as a very rough guide, I would suggest that a short article is less than 3,000 bytes (e.g. Kinlochbervie is 3,213 bytes, Lochbuie is 1,455 bytes). A "screen" is generally 1,000 - 2,000 bytes, depending on how the article is formatted. I would expect that removing images because there are too many would be very rare - these words are trying to replace the old "Minimal use of images" which suggests less images than this. What is right for an article is really a matter of judgement - how many depends on the image aspect ratio (portrait images need more lines of text), and how informative the image is to a reader. AlasdairW (talk) 12:05, 14 October 2018 (UTC)

Thank you for the clarifications. Ikan Kekek: I have no guidelines to propose, because I thought there was nothing wrong with the previous guidelines to begin with. I am not concerned about 'what would be done to me', but rather about the many articles which do have three images in a row (most of which I have not personally edited). Poorly-defined or fuzzy rules can be a recipe for misunderstandings later on. –StellarD (talk) 12:36, 14 October 2018 (UTC)

I do not agree with "if the last image goes lower than the text on whatever you're using to view the article, delete it." Generally, I too think images extending below the text are to be avoided, but I have sometimes put images near the end of the article, because I think they fit with Stay safe or whatever. I suppose there are monitors in use where these images extend too far, but unless you are using something normal you should just ignore that problem, and if you do, rather try to adjust the layout (unless the image really is superfluous). --LPfi (talk) 16:20, 14 October 2018 (UTC)

Obviously, if an image can be moved up and that solves the problem, that's what should be done. Maybe that's not obvious? But I think "Make sure no images extend below the end of an article" shouldn't be controversial. It looks like crap when that's done. And by "end of an article", I include the visible codes at the bottom.

StellarD, I would agree with AlasdairW: The reason to include suggested guidelines is that "minimal use of images" is not only vague but suggests to at least some readers an extreme dearth of images (maybe 1-2 for a long article). But I think it's fine to discuss whether the guidelines should say "Try to avoid having more than 2 images in a row without space between them" or "Try to avoid having more than 2 or at most 3 images in a row without space between them." The reason I'm currently using 2 is that when I suggested 2-3, there was an objection from Pashley above. Pashley, would you strongly object to my compromise language in this reply? Also, shall we adopt AlasdairW's byte numbers for "short article" and "screen"? Ikan Kekek (talk) 18:47, 14 October 2018 (UTC)

Thank you for the explanation. If Pashley agrees, I would prefer to have the addition of 'at most 3 images', and including byte numbers sounds very reasonable to me. -StellarD (talk) 21:43, 14 October 2018 (UTC)

Articles like World Heritage are exceptions, but for normal city articles, it should be very rare for there to be rows of images. Image rows (even 2) are generally too much. ChubbyWimbus (talk) 10:33, 15 October 2018 (UTC)

I don't agree that 2 in a row are too many, but what form of words are you proposing for guidelines explaining what "minimal use of images" means in practice? Ikan Kekek (talk) 21:05, 15 October 2018 (UTC)

I have no objection to the apparent consensus. I do think it might benefit from some text about trying to strike a balance, enough images to illustrate the text & show some of the highlights but not enough to overwhelm the text & turn the article into a photo gallery. I have not thought this through in detail, so I won't try to add text now. Pashley (talk) 02:38, 16 October 2018 (UTC)

That sounds like a good addition. Ikan Kekek (talk) 03:27, 16 October 2018 (UTC)

[unindent]

OK, a new attempt at guidelines:

Minimal use of images doesn't mean none. Instead, it means enough images to illustrate the text and show some of the highlights but not so many as to overwhelm the text and turn the article into a photo gallery.

More specifically:

• Short articles (less than 3,000 bytes) should usually have no more than 1-2 images, including a map.
• For longer articles, 1 image per screen (1,000 - 2,000 bytes) is generally adequate.
• Try to avoid having more than 2 or at most 3 images in a row without space between them.
• Make sure no images extend below the end of an article.

Do we have a consensus for this language? Ikan Kekek (talk) 09:31, 16 October 2018 (UTC)

I think that sounds alright. While I think we should always do our best to make policies as clear as possible, lots of our policies leave wiggle room on purpose and out of necessity, so new users who want either rigid rules or free reign are going to end up frustrated no matter what we do. There is no policy that can be formed to ensure that edits will go unchallenged. ChubbyWimbus (talk) 13:30, 16 October 2018 (UTC)

I agree. Though that's kind of by design, as this is a Wiki. Ikan Kekek (talk) 15:29, 16 October 2018 (UTC)

I think this language is good, and should hopefully accommodate most people here. –StellarD (talk) 18:11, 16 October 2018 (UTC)

I like the words. Maybe "images in a row" could be "successive images", as a row suggests a horizontal gallery, but this is not important. AlasdairW (talk) 20:18, 16 October 2018 (UTC)

Sounds good, along with AlasdairW's recent idea for a slight change in the wording. I think, though, the problem needs to be addressed (if it hasn't already) that, just because there are five pictures on Commons that are related to "see" and no other pictures for the place, the five pictures don't all have to be crammed into that one section. The Barcelona article is a fairly "good" example of this. --Comment by Selfie City (talk about my contributions) 03:19, 17 October 2018 (UTC)

[unindent]

Yes, that absolutely does have to be addressed. So I'd suggest another bullet point:

• Images should be distributed throughout an article, not bunched up in any section. Ikan Kekek (talk) 06:50, 17 October 2018 (UTC)

Yes definitely! I can't remember how many times I've complained about the type of articles where the See section looks like a world record attempt in cramming in photos into one section, and while that row of photos might continue into Do or even further down, there's not one single photo below that. --ϒpsilon (talk) 07:39, 17 October 2018 (UTC)

It looks like there's a fair amount of agreement on the wording. I'm going to go ahead and post some text in the article, and of course any of you can and should edit it further or discuss anything that you'd like a consensus on changing. Ikan Kekek (talk) 07:49, 17 October 2018 (UTC)

Here's the edit. Ikan Kekek (talk) 07:52, 17 October 2018 (UTC)

How many pictures per page?

Swept in from the pub

How many pictures are permitted on a wiki voyage page?--Kwameghana (talk) 01:00, 26 August 2016 (UTC)

The long and short of it is there's no magic number, just don't overdo it. See Wikivoyage:Image policy for a more detailed answer. -- AndreCarrotflower (talk) 01:55, 26 August 2016 (UTC)

If there is a lot of text I usually try to restrain myself so that images do not go down further than the text. It is very unscientific and depends on screen width, but that's how I usually do. If there is not much text, I usually head for two pictures, or one picture and a map. Syced (talk) 02:56, 30 August 2016 (UTC)

Policy against using images with watermarks, etc.

Swept in from the pub

Hi, everyone. I know that Wikivoyage has a policy against using as thumbnails photos with watermarks or other writing added to the image. Where is the policy mentioned? I'd like to give a link to Renek78 in reference to the Hpa-an article. Ikan Kekek (talk) 18:57, 3 April 2017 (UTC)

At a stretch it could be argued that a watermark constitutes a montage which is against Wikivoyage:Image_policy. There seems to be an overall lack of guidance around image quality in our policies however. --Andrewssi2 (talk) 20:40, 3 April 2017 (UTC)

Image quality? Yeah. Not sure we need to add guidance, because "don't add terrible photos" is common sense and deleting such photos when they're added can be explained simply as a matter of logic. Ikan Kekek (talk) 20:45, 3 April 2017 (UTC)

I think photos with watermarks often can be deleted by the same logic: it is a disturbing element in the photo. The reason to accept them would be that watermarks are common, but they are not here at Wikivoyage. --LPfi (talk) 20:50, 3 April 2017 (UTC)

Another important thing to consider... many watermarks can be removed with Photoshop. I could help with that if there is a specific photo on WikiCommons that needs such a fix (and that you think would be a great addition to Wikivoyage if the watermark is removed). ויקיג'אנקי (talk) 02:43, 4 April 2017 (UTC)

Look at my uploads on commons. A bunch of them still have a timestamp, I fear. Hobbitschuster (talk) 13:50, 4 April 2017 (UTC)

I am against allowing images with watermarks, especially if they have been removed via photoshop. A watermark was placed on the image for a reason, usually to denote ownership. If the creator of the image wants others to know that it is theirs, why would we remove their mark of ownership? Additionally, watermarks are usually used to prevent people from "stealing" the image, so I would assume they don't want it used elsewhere. I think the argument against watermarked pictures shouldn't come from photo quality guidelines, but rather guidelines about fair use / open source / commons guidelines. Obviously, this is about watermarks of ownership/branding/etc, not things like timestamps. DethDestroyerOfWords (talk) 15:15, 7 April 2017 (UTC)

Commons strongly discourages watermarks. Since we get most of our images from Commons, we inherit their image guidelines. Powers ^(talk) 20:35, 2 May 2017 (UTC)

Proposal to change Special:Upload page

We would like to ask the developers maintain this site to change Special:Upload so that it adheres with current Wikivoyage Image Policy and only permits the upload of:

• JPG image files
• JPEG image files
• GIF Image files
• PNG image files

(note that SVG files are allowed on Wikivoyage, but not currently supported on the Wikivoyage local Upload page)

This is to prevent excessive spamming. The background for the motivation of this change can be read on Wikivoyage:Travellers'_pub#File_Spam.

The votes for this change are as follows:

• AGREE - --Andrewssi2 (talk) 22:39, 27 September 2017 (UTC)
• Agree -- Ikan Kekek (talk) 00:18, 28 September 2017 (UTC)
• Agree -- Pashley (talk) 00:54, 28 September 2017 (UTC)
• Agree -- AndreCarrotflower (talk) 00:56, 28 September 2017 (UTC)
• Agree -- Gizza ^(roam) 22:38, 5 October 2017 (UTC)
• Agree -- AlasdairW (talk) 22:59, 5 October 2017 (UTC)

I'll note that in addition to these, TIF/TIFF and SVG files currently exist on this wiki (see Special:MediaStatistics) and should probably either be explicitly allowed (by the policy and by the wiki configuration) or the existing ones should be deleted. Neither TIF/TIFF nor SVG files are common abuse vectors, so I suggest we keep and allow them. Matma Rex (talk) 17:51, 6 October 2017 (UTC)

Thanks Matma Rex . I'm really OK with your proposal. Andrewssi2 (talk) 21:34, 6 October 2017 (UTC)

File Spam

Swept in from the pub

Can we please do something about the people spam-uploading files here? Maybe some minimum number of edits before you can locally upload a file? Hobbitschuster (talk) 22:19, 19 September 2017 (UTC)

Is the spam an actual upload, or is this someone merely editing the image description page and writing gibberish on it? K7L (talk) 23:14, 19 September 2017 (UTC)

K7L, I assume Hobbitschuster is talking about the persistent problem we've had of users uploading pirated movies and music files to Wikivoyage. This is a problem that's apparently been cropping up all over the WMF. There's a simple solution to this problem - disabling uploads of all but static image files, which are already disallowed per policy - and it boggles my mind why it hasn't been instituted yet. -- AndreCarrotflower (talk) 19:57, 20 September 2017 (UTC)

I think that User:CKoerner (WMF) knows who can do that. WhatamIdoing (talk) 01:31, 22 September 2017 (UTC)

Hi all! There'a few things at play here. I hope to give a few links to explain what is being done in general with regards to illicit file uploads and what I need from you all to stem the tide here at English Wikivoyage. First, this is a known issue and is being worked on elsewhere in the movement. Here is the most useful task I can point interested folks to. There's work going on to address related concerns like files not being purged after deletion. If you see issues like this, please leave a note here or in Phabiricator so folks are aware.

Two questions I have for you all. What are the file formats we wish to prevent? Do we have community consensus to block these uploads? (I think we would, but I need ya'll to say so!) I created a task to track this work. CKoerner (WMF) (talk) 16:15, 25 September 2017 (UTC)

According to Wikivoyage:Image policy#Image formats and #Other media, the only file formats that should ever be hosted locally are JPEG, PNG, and SVG. All other files should be blocked, and I would think that the fact that we have a preexisting policy already in place that says files of other formats don't belong here is functionally equivalent to consensus. -- AndreCarrotflower (talk) 16:54, 25 September 2017 (UTC)

I agree with Andre here; all formats except those we use for images should be blocked.

Beyond that, I'm inclined to think we should restrict uploads even in those formats somewhat. No anon uploads, only logged in users? Only autopatrolled users? Only admins? Even just disable file upload completely, force everything to Commons? Either of the first two would be fine with me, with a mild preference for the second unless it is hard to do. I suspect the last two would cause problems. Pashley (talk) 17:13, 25 September 2017 (UTC)

Files should always be uploaded to commons unless you have a very good reason for uploading it here instead. In some case photos need to be uploaded locally for copyright reasons, also if we discuss problems and upload screenshots, it is better to upload them locally. But I can't understand why we should let people upload audio and video as this kind of media isn't allowed in our guides in the first place? ϒpsilon (talk) 17:45, 25 September 2017 (UTC)

FWIW, Wikivoyage_talk:Vandalism_in_progress#Prevent_video_uploads.2C_maybe_images_under_certain_conditions --Zhuyifei1999 (talk) 03:46, 26 September 2017 (UTC)

Ah ha! It looks like there is an abuse filter for media file uploads. I can't see the contents of the filter. Andrewssi2 could you please let us know if this address the concerns folks have mentioned here? CKoerner (WMF) (talk) 14:48, 26 September 2017 (UTC)

Evidently the filter is not effective, as just a few hours ago User:Ikan Kekek had to manually delete another boatload of files in one of the formats ostensibly covered by the filter. Frankly, rather than relying on an abuse filter that, even if it were effective, could be subverted easily enough by simply switching to different file formats that the filter doesn't cover, it seems a lot simpler to just limit uploads across the board to the three aforementioned approved formats. -- AndreCarrotflower (talk) 15:41, 26 September 2017 (UTC)

Yes, can we please do that? This file-upload spam is annoying. Ikan Kekek (talk) 18:43, 26 September 2017 (UTC)

I believe that I have fixed it (I tried uploading some open source offending file types, and they are not getting through.

Frankly the easiest way to fix this is just to edit Special:Upload to prevent these uploads. It is not right that we have a page that explicitly permits .ogg files to be uploaded (and actually states that clearly) and then have to prevent said .ogg file in the abuse filter. Any idea who to talk to for this? Andrewssi2 (talk) 21:52, 26 September 2017 (UTC)

No, a special page (like Special:Upload) cannot be "edited" as if it were content. There is a setting in mw:manual:LocalSettings.php on the servers that can specify which file types are accepted, but that's not part of the wiki content. Our users don't have access to change this; WMF might be able to do so on consensus if a phabricator ticket were opened. The actual boilerplate text displayed on the special pages sometimes is in the Mediawiki: namespace (as these "canned" strings need to be translated into multiple languages for localisation) but editing those wouldn't change the functionality. The abuse filter might be the path of least resistance? K7L (talk) 02:48, 27 September 2017 (UTC)

The abuse filter is certainly the easiest way, and it is not like Special:Upload gets a lot of use anyhow. Just don't like seeing functionality broken in this way. Andrewssi2 (talk) 03:26, 27 September 2017 (UTC)

Chris filed a Phab task for it, and I just leaned a little on it.  ;-)

You don't need abuse filters. The devs will happily do this for you. What they usually want is a sort of quick "All in favor of the Wikivoyage:Image policy, say 'aye', and all in favor of copyright-violating spammers, speak now, or forever hold your peace" thing. They've gotten burned a couple of times by a person asserting, "The community says X" when the local community said no such thing, so they usually want a link to a discussion, so that if there are objections later, they can say, "But it looked like there was a consensus..."

So: "All in favor of the image policy?"

You can put me down as supporting this change. WhatamIdoing (talk) 15:28, 27 September 2017 (UTC)

Aye. But maybe it would be clearest to have a separate subthread just for votes, for the sake of clarity?Ikan Kekek (talk) 17:00, 27 September 2017 (UTC)

Just to make this easier to point to (I doubt the developers would want to read all the thread above) I have created : Wikivoyage_talk:Image_policy#Proposal_to_change_Special:Upload_page Andrewssi2 (talk) 22:41, 27 September 2017 (UTC)

Hi WhatamIdoing . We have our voting recorded here : Wikivoyage_talk:Image_policy#Proposal_to_change_Special:Upload_page - can you please take this forward for implementation? Andrewssi2 (talk) 21:06, 5 October 2017 (UTC)

Done. Thanks for the link. (Anyone who's interested should feel free to add your name, too.)

The next step is waiting for an interested dev. I don't know how long it will take: maybe as early as next week if the right person has some time on his/her hands, but could be a couple of months, too. Any volunteer who knows how to write the necessary patch is welcome to submit it: it's not just something that paid staff are allowed to do. WhatamIdoing (talk) 22:12, 5 October 2017 (UTC)

I found an interested dev! The wonderful Matma Rex has submitted a patch and it should go live on Monday. CKoerner (WMF) (talk) 18:05, 6 October 2017 (UTC)

Thanks Matma Rex, CKoerner (WMF) & WhatamIdoing ! Andrewssi2 (talk) 21:35, 6 October 2017 (UTC)

This is done now. Matma Rex (talk) 13:26, 9 October 2017 (UTC)

Thanks Matma Rex. That is going to save us a great deal of trouble now. Andrewssi2 (talk) 11:22, 10 October 2017 (UTC)

Map/photo copyright question

Swept in from the pub

Tambobo Bay is a yachting harbour in the Philippines. Looking at it with Google Earth the profusion of boats is clearly visible. Wow! I'd like to use that type of image in our article but don't want to violate copyright. One link for the Earth image is here; the Bay is near the point East of the town & you need to zoom in to see the boats.

Are the underlying photos from NASA? Another source? Pashley (talk) 14:11, 3 January 2018 (UTC)

I am no expert at all, and may just be telling you what you already know, but am mainly answering so this post gets noticed in amongst all the other goings on at the pub. However, I think Google Earth material is all copyrighted to them, as they watermark everything with their logo. OTOH, if you find out the underlying images do indeed belong to NASA, then you are free to use them as you wish, as NASA photography is free of copyright as long as you credit them (it's a bit like our CC licence). --ThunderingTyphoons! (talk) 16:02, 5 January 2018 (UTC)

The Google images are under Google copyright, the purchased the images, not published by someone else. You can use them under "fair use" if attributed. See here for some information. Basically you can only use the image on an article covering the subject of the image, must clearly state it is from Google and cannot upload to Commons. Also under Philippines law you will have to make sure there are no pieces of art or architecture in the photo that is under copyright.--Traveler100 (talk) 16:38, 5 January 2018 (UTC)

I think using images from Google Earth would be prohibited by EDP. —Granger (talk · contribs) 16:46, 5 January 2018 (UTC)

I'm almost certain using a Google image would violate copyright; I definitely won't do that & am not expecting anyone else to.

There are plenty of good images about, e.g. ground level view. However, all the ones I find appear to be copyrighted & not usable here. Could someone with better image search skills than I find one we can use? Pashley (talk) 13:47, 4 August 2018 (UTC)

Unsuitable photos and Commons

@Ground Zero: Regarding the photos you just removed - it seems they were uploaded just to put here. Now that they are removed, would we take any action on Commons? Or leave them be? Thanks, ARR8 (talk) 13:05, 11 October 2018 (UTC)

I don't know much about how the Commons work. Will they automatically be removed at some point? It may be that some of those pictures (not the ones with people) could go in local articles. I was unable to identify where those pictures are. Maybe the poster will help us. Ground Zero (talk) 13:19, 11 October 2018 (UTC)

Images do not get automatically removed at Commons, but if they are thought to break copyright or thought to not be in scope, they are deleted. For the latter, use in a sister project such as Wikivoyage automatically make them qualify. That means photos that have no apparent educational value should be safe (not all admins honour that though) as long as they are used in an article over here, but can be deleted if not any more in use. The educational scope is interpreted liberally, so it is no problem for most images – but those with people can often be deleted as "personal images". I think they often should be kept, as documenting tourism has educational aspects (but for some destinations there is an abundance, and only an assortment is needed). --LPfi (talk) 19:35, 11 October 2018 (UTC)

Including audio files in certain Wikivoyage articles

In some cases, I think audio files are useful on Wikivoyage articles. What do others think in relation to this? --Comment by Selfie City (talk about my contributions) 18:47, 20 October 2018 (UTC)

See Russian phrasebook#Phrase list, where I've added some. ARR8 (talk) 20:06, 20 October 2018 (UTC)

The problem is that, currently, policy states not to include audio files in Wikivoyage articles. Do you think that should be change? It seems that you do. --Comment by Selfie City (talk about my contributions) 20:34, 20 October 2018 (UTC)

I remember someone saying they were allowed in some cases. Don't remember where, though. ARR8 (talk) 21:55, 20 October 2018 (UTC)

I'm not sure how the split was back in the day, but I think I was always in favor of IPA and/or sound files... Hobbitschuster (talk) 22:35, 20 October 2018 (UTC)

There was a proposal to allow them on phrasebooks, but I don't think that discussion ever became policy. I think that we should allow audio recordings of the phrases in phrasebooks (but not elsewhere initially). AlasdairW (talk) 22:41, 20 October 2018 (UTC)

So do I.--ThunderingTyphoons! (talk) 23:38, 20 October 2018 (UTC)

I also support allowing audio recordings in phrasebooks, of the sounds and of the phrases. —Granger (talk · contribs) 00:00, 21 October 2018 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘I agree about the audio files in phrasebooks. However, the reason I brought this up is the Jazz travel topic, where a sound byte of how the music sounded would be more than a little useful. --Comment by Selfie City (talk about my contributions) 01:32, 21 October 2018 (UTC)

I think it's most important in phrasebooks. I'm not sure it's important in travel articles about music, as the excepts could be left in analogous Wikipedia articles, instead. What do the rest of you think? Ikan Kekek (talk) 06:04, 21 October 2018 (UTC)

I would be happy to have musical excerpts in relevant travel topic articles, as long as they suited copyleft.--ThunderingTyphoons! (talk) 11:18, 21 October 2018 (UTC)

Well, there are some Dixieland jazz recordings on Commons, and from some research I did they were apparently the earliest jazz recordings that still exist. I think that's how they got to fit the copyleft. --Comment by Selfie City (talk about my contributions) 16:07, 21 October 2018 (UTC)

As a musician, I should probably should know this, but I don't: What are the rules on fair use of excerpts of recordings still under copyright? Because we probably don't want to have excerpts only from the very oldest recordings, if we want to use sound files to show style. Ikan Kekek (talk) 18:56, 21 October 2018 (UTC)

Anything produced by an employee of the US federal government (I'm not sure about state and local government) in that capacity is ipso facto free of copyright. I am not sure whether other countries have that rule, but that is why you can have copyright free recordings of many national anthems with modern audio quality, because employees of the US federal government in that capacity record them for state visits... Hobbitschuster (talk) 19:12, 21 October 2018 (UTC)

I believe those Dixieland jazz band recordings don't have bad sound quality, but I can check again. --Comment by Selfie City (talk about my contributions) 19:18, 21 October 2018 (UTC)

I think that we should start with phrasebooks, where copyright is less likely to be an issue. After we have sorted all the mechanics out for this, and assuming that there are no unexpected problems, we can then move on to other possibilities. Music for travel topics is one possibility, pronunciation of destinations is another. (Music produced by federal government employees is only copyright free if the musical score is not copyrighted - a military band playing the latest hit would not be PD.) AlasdairW (talk) 22:42, 21 October 2018 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Agreed. Should we now make a slight change the policy accordingly? --Comment by Selfie City (talk about my contributions) 22:53, 21 October 2018 (UTC)

Regarding the copyright issue, as long as we stick to files that meet Commons' requirements, we basically don't have to worry about copyright. I think that's the best way to go for audio files—better to stick to free content when possible and not try to use fair-use music recordings. EDP is a relevant policy. —Granger (talk · contribs) 04:15, 22 October 2018 (UTC)

I think we should go ahead and allow use in phrasebooks, but I think we need more discussion on the other uses (and I think the two need separate discussions). An important distinction is that it is quite easy for a native speaker and somebody with a little experience of sound recording to record all needed clips (now and when changes are needed), while the example on jazz highlights that we are very restricted in what we can use. I suppose musical quotes are allowed like any other quote, at least in some jurisdictions (including Finland, the one I know best), but we should check the legal situation and amend our Exemption Doctrine Policy. If we only use files on Commons, there will be a very big temptation to choose examples that are less relevant, but happen to be available. I am not sure such examples, or examples just of a few styles, make the articles better. --LPfi (talk) 12:02, 22 October 2018 (UTC)

I agree—music clips and similar are a more complicated issue that require further discussion. Let's allow audio in phrasebooks for now and see how that goes. —Granger (talk · contribs) 14:48, 22 October 2018 (UTC)

Yes to what LPfi posted above. The only thing I wonder about with sound files for phrasebooks is whether it's actually best to host those or to link to them. I don't care about that as a policy matter, though, only in terms of practical benefits for readers. Ikan Kekek (talk) 20:35, 22 October 2018 (UTC)

They are useful in all Wikivoyages and for language courses in Wikibooks, and having them at Commons may give them visibility resulting in other people developing better files than what we could create ourselves (or for more languages etc.). I do not see any special reason to host them here, but I may have overlooked also obvious reasons. --LPfi (talk) 21:01, 22 October 2018 (UTC)

Just what I was about to post. Commons also gets audio recordings regularly from projects like Wiktionary and freely-licensed projects elsewhere. ARR8 (talk) 21:06, 22 October 2018 (UTC)

There are already the basic phrases for some languages available on commons - see Commons:Category:Pronunciation. I think that there are questions of how exactly to best embed them. I assume that .ogg files can be readily played in all browsers including mobile ones. AlasdairW (talk) 21:15, 22 October 2018 (UTC)

Yes. ARR8 (talk) 21:57, 22 October 2018 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘I have updated the article, stating that phrasebooks are an exception. --Comment by Selfie City (talk about my contributions) 22:37, 22 October 2018 (UTC)

Commons, again...

Swept in from the pub

It's happening again... Commons is arbitrarily deleting valid copyleft media which is in active use here. The latest is this image (CC-BY-SA) of historic commemorations at the Mary Meachum freedom crossing on the Mississippi River in St. Louis, which appeared in a recent featured travel topic on the Underground Railroad. I raised the issue at commons:User talk:Jcb#Three re-enactors at Mary Meachum Freedom Crossing by Lynn DeLearie.jpg and received no reply. (The admin in question appears to have been de-opped in the past for questionable deletions, but was reinstated for some reason.)

I've long felt uncomfortable about a policy forcing Wikivoyagers to upload content (be it images, map traces, co-ordinates, Wikidata, whatever...) to another wiki for a number of reasons. Scattering content across three different projects (WV, Wikidata, Commons) makes it more difficult for new or inexperienced users to contribute or maintain existing content. Add to this the ongoing issues with content deletions on the external wiki breaking things on this wiki, and the harm done more than outweighs the very marginal benefit of being able to re-use content a bit more readily across multiple language versions.

Commons needs to make substantial changes to its deletion policy for items in active use in individual projects to notify those communities before items are deleted. The need to give them the chance to move the items local (if they're under valid copyleft, in this case CC-BY-SA) or bring them under EDP (if they're public art or architecture which is "fair use" here but not there). Unless and until they do so, the common repository does not serve our needs and is causing us to lose valid content in a manner which does not serve the voyager.

Currently, Wikivoyage:Upload file says "Go to Wikimedia Commons' Upload Wizard to contribute your freely-licensed media. If your file meets one of the exceptions set out in the exemption doctrine policy for non-free content, you can upload it locally to this wiki. Please do not upload free files locally, as they will be deleted."

I would like to propose that we scrap this policy as it is harming the project. If something is actively in use here, users should be permitted to upload it here. K7L (talk) 17:02, 22 October 2018 (UTC)

As someone who alreday transfered more than 2000 photos from Commons to Russian Wikivoyage, I wholeheartedly support this proposal. --Alexander (talk) 17:06, 22 October 2018 (UTC)

There is in fact a deletion notification system, but we have not tried it out yet. --Alexander (talk) 17:28, 22 October 2018 (UTC)

This is a serious shortcoming of Commons, but I'd still say they are doing a vary valuable job, and having to police the files ourselves would be a major undertaking, and not uploading to Commons would mean our images would not be available to the other projects w, ru-wv etc. other than by first finding the image here and then reuploading at Commons (or locally, repeated for every project). A big hassle. --LPfi (talk) 18:37, 22 October 2018 (UTC)

It looks like that deletion notification system would not have been helpful in this instance, as it only addresses cases where this has gone through some sort of due process (a vote for deletion or speedy deletion). The problems arise when someone arbitrarily tags an image with a template claiming that the permission information is incorrectly formatted or missing; this is usually done without any attempt to determine the actual copyright status of the image. If there's any notification given at all, it's merely posted to the talk page of some random Commons user (in this case, a n00b who uploaded this from Flickr in 2016) where it will never be seen; no notification is given to the project(s) actually using the image. Once the tag is present, the image is fair game for deletion with no further process or safeguard. Sadly, there's nothing new in this sort of thing... I remember Wikipedia was already this dysfunctional in 2006: some random Wikiproject posts a request for an image, a user shoots and uploads it with plain-text description "I took this photo twenty minutes ago, do what you want with it. I don't care.", a robot script tags it as "missing machine-readable permissions" and another robot script (impersonating a human admin, although these scripts were openly available on botwiki.sno.cc at the time) then merrily deletes it. To add insult to injury, once it's been deleted, we also lose all of the description and metadata needed to find the original source and status of the image, or even to determine why it was deleted. All that's left is a misleading one-line note like " ‎CommonsDelinker‎ (Removing Three_re-enactors_at_Mary_Meachum_Freedom_Crossing_by_Lynn_DeLearie.jpg, it has been deleted from Commons by Jcb because: [[:c:COM:OTRS|No permiss)" which actually throws us off the trail as what happened has nothing to do with OTRS (open ticket reporting system: a "support ticket" system for handling e-mail to info@... or support@... addresses which is not open or public - which appears as a red herring to eliminate any transparency from the process).

Clearly the intention is not to produce an encyclopaedia or a travel guide, it's to create a pile of images which can be harvested by automated means for commercial reuse for purposes which have nothing to do with the original project. In the eyes of Wikimedia Commons, we do not matter because we are not the client. While the creation of a "deletion notification system" is an initiative which was long overdue, at this point I'd suggest that the onus is on the WikiCommons community to establish that this is addressing any of the problems. The need to track the removal of valid images from our articles because of Commons shenanigans is now a bigger hassle than hosting them locally, so giving users the option of uploading locally is the lesser of two evils. K7L (talk) 18:51, 22 October 2018 (UTC)

The OTRS link is not a red herring: Writing to those e-mail messages is how photographers (or other copyright holders) can prove that they own images. (This is often done by revealing personal information that one would rather not have published on the internet. Consequently, e-mail is the appropriate communication medium.) If you are in a legal position to solve the problem of "no permission", then that link tells you how to do it. WhatamIdoing (talk) 19:41, 22 October 2018 (UTC)

The OTRS link is a red herring in the way it was used in the edit summary for this specific deletion. An edit summary of "it has been deleted from Commons by Jcb because: [[:c:COM:OTRS|No permiss)" is misleading if the motive for this deletion had nothing to do with OTRS and there is nothing in OTRS relevant to this case. Basically, it misleads the reader into believing that there was some legit reason to delete the image, but the admin is magically released from any obligation to reveal that reason because it's concealed deep within the star chamber of OTRS. The CC-BY-SA flag was posted openly, on the original image, on Flickr. Being sent on a wild goose chase into OTRS serves only to throw anyone questioning what's happened off the trail, which is not nice and certainly not helpful. K7L (talk) 20:04, 22 October 2018 (UTC)

This makes no sense. There is exactly one method of resolving the problem of "no permission", and that method is to send e-mail to the OTRS system. How could you possibly get from the fact that the OTRS page has the instructions on how to resolve the stated problem to a belief that "there is nothing in OTRS relevant"? WhatamIdoing (talk) 03:59, 23 October 2018 (UTC)

It's one method of solving "no permission" problems, but not the only one. I think K7L's point is that in this case, there was a straightforward way to solve the problem that didn't involve OTRS. —Granger (talk · contribs) 04:10, 23 October 2018 (UTC)

LPfi, ru-wv will certainly not bother about it. If there is a good image, I can afford spending one minute on transferring it to another project. That's considerably less time than what you need for finding any suitable image on Commons. --Alexander (talk) 22:47, 22 October 2018 (UTC)

I think we should get the deletion notification bot set up.

Also, could we maybe just talk about this subject like it's not the end of the world? K7L "received no reply"... or at least no reply within the first 12 hours. Are we on such a tight deadline that can't wait at least a whole day for responses? The file was, in fact, incorrectly labeled, but when asked (and when it was a reasonable hour in his timezone), the Commons admin promptly restored the image and fixed the tag. Asking for help was IMO a good idea. Complaining that a volunteer didn't reply within hours, and that this failure to be instantly available at all hours should result in dramatic changes to our structure, in ways that disadvantage all of the smaller Wikivoyages, is unfair. WhatamIdoing (talk) 19:54, 22 October 2018 (UTC)

Unfortunately, this isn't the first time these issues have come up. I would not have proposed a policy change here were this an isolated incident. We've had problems with Commons before, including one incident where they were demanding deletion of (lat, long) data just because it was sourced from the (copyleft) OpenStreetMap project. It's not even the first time that images have been removed from this one itinerary, Underground Railroad, because of Commons issues. K7L (talk) 20:07, 22 October 2018 (UTC)

On the face of it, hosting all images here seems too drastic a solution, and one that would bring problems, too. What's the total number of files that we've been using here that were erroneously deleted from Commons? Ikan Kekek (talk) 20:28, 22 October 2018 (UTC)

We should enable the deletion notification bot. I do find that commons can be a bit quick to delete files, and a couple of my uploads have been deleted. However I expect that the commons admins are severely overstretched, and a quick look at some of the recent uploads shows the massive problem of non-free files being uploaded. Many of the photos which we use have been taken by people who don't edit here. We do already upload the main page banners locally, and I would agree with uploading any other small set of significant images, but not doing so generally. AlasdairW (talk) 21:31, 22 October 2018 (UTC)

Comment: I am not sure if it was K7L's original intention or not, but I think the idea is to allow more local uploads whenever editors prefer to keep files locally. It's not about storing all photos here, but about additional flexibility that the community should use.

It is true that the current situation with the single file restored after some hours was not dramatic, but as the organizer of Wiki Loves Monuments in Russia I have to deal with thousands of photos and with similar deletion issues on a much larger scale. It is a pain, and it is a pain only because the Commons community does not see themselves as an image repository for Wikimedia projects. They treat their project as a unique collection of free images (whatever "free" means in their definition), and it is their choice, but then I don't see why we should deem Commons a unique image repository for our projects. It's nothing else than a place to store photos, just like Flickr, but Flickr gives you a lot more flexibility regarding tags, attributions, and licenses. I don't see why good photographers would upload their works to Commons instead of Flickr, and in fact they don't.

Finally, we should always remember one fantastic deletion request, where a dozen of experienced Commons users was doing all kinds of stupid things, including the point-by-point analysis of geo-coordinates, instead of familiarizing themselves with details of the OSM license policy. It is a very good example of how weird the Commons community is, and why it is often safer to store files locally. --Alexander (talk) 22:47, 22 October 2018 (UTC)

I agree with that idea. We should encourage local uploads, but not force anyone to upload pictures here or move thousands of pictures from one wiki to another. When fairly recently I wanted to upload some pictures I took to Wikivoyage, I was disappointed to find that you weren't allowed to do that. I'd support a change for that reason. --Comment by Selfie City (talk about my contributions) 00:37, 23 October 2018 (UTC)

(ec) I would oppose changing the current policy. If an image can go on Commons, it should. Allowing discretion here would only hurt smaller projects, and the problem it's meant to solve is one stemming from poor communication with Commons. ARR8 (talk) 00:59, 23 October 2018 (UTC)

Whatever else we do, it seems to me that enabling the deletion notification bot is a good step. I see some support for that—does anyone object?

I've also started a discussion at Meta to see if the bot will tell us when a "No permission since" tag is added to an image. —Granger (talk · contribs) 01:16, 23 October 2018 (UTC)

I think the abuse of "no permission since" should be ended. I think its intended use was on new uploads, where a grace period of a week is reasonable: either the uploader is still around and sees the change, or is away not necessarily ever to return. With old uploads it is just ridiculous: who but the active Commons users will check their watchlist every week? The problem is made worse by the practice K7L describes.

I think the description is a bit exaggerated, but yes, people do mark files as missing permission when the permission in fact is there, but not formatted according to current practice (which may have been introduced long after the upload), sometimes in a language the editor does not know. Then the busy admin comes along and does not see as his or her duty to really check – if no permission is found (again, perhaps due to inadequate language skills) or there is not clear evidence of a claimed permission (perhaps due to link rot) the file is gone, and if not in use nobody will know – I doubt anybody is checking deleted files systematically.

I think such hasty deletions are against the policies, and you can usually revert them if you argue your points, but the admins (and the original template adder - a pun?) will get away with it, partly because the paths to seriously question an admins manners is convoluted, partly because they do an immense work, deleting thousands of real copyvios, adding categories to newby uploads and maintaining the collection in other ways.

--LPfi (talk) 10:03, 23 October 2018 (UTC)

I agree with the notification bot (esp. if there would be a way to "subscribe" to some "watch over everything" group), that would help rule most cases of silent image removal, right? At the same time, I don't think moving images to WV is a good idea. Unless someone here wants to takeover the WC job and check copyright or the uploaded stuff... -- andree.sk(talk) 18:34, 23 October 2018 (UTC)

I don't think that we stop using commons for photos, but it may worth considering allowing local uploads for static maps. The main difference I see are:

• There is unlikely to be more than an average of one upload per day, so there is not a big workload increase.
• Static maps are much less likely to be used by other projects - other WVs would want a translation, WP would have different district or region boundaries and wouldn't want our selection of eat, drink etc.
• The impact on an article of a map being deleted is much greater than a photo being deleted.
• Maps are harder to replace than photos.
• It is much less likely that copyvio maps in our format would be uploaded.
• There are complexities about maps which may be hard to explain on commons.

Is this a reasonable comprimise? AlasdairW (talk) 23:00, 23 October 2018 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘I'm not sure. I'd still like to see an option to upload photos locally, but I'd prefer your compromise to the current state of things. --Comment by Selfie City (talk | contributions) 00:34, 24 October 2018 (UTC)

@AlasdairW: counterpoint: It's possible another WV could decide to display maps in a country's native language, and want to use our static maps on pages for Anglophone regions. After all, translating the name of an establishment just makes it harder to find. ARR8 (talk) 02:19, 24 October 2018 (UTC)

Maps are only a very small part of the content for which WV depends on other sibling wikis. Moving a handful of static maps local doesn't solve the issue that we're losing images, co-ordinate data, Wikidata {{listing}} info (which cropped up once a in de: featured article) or anything else. The use of Commons or other external wikis needs to be optional, period. Editors should have the discretion to upload locally if they so choose, as any of a number of missing pieces (not just maps) can diminish the quality of our guides. K7L (talk) 06:12, 24 October 2018 (UTC)

Neither does uploading some images locally on the uploaders' discretion solve the issue. We are using loads of images uploaded by other users. To solve the problem by local uploads the editors of individual articles should upload important images here, and also images that could be important should be uploaded locally. Then we need a system to mirror useful changes on Commons (correction of descriptions, deletion of copyvios etc.), and – if we have some solidarity – of copying local uploads to Commons to be found by others.

I think the real solution is to work with Commons, to solve the issues over there. If the main problem is missing manpower, then I am not sure what to do. I for one cannot check a hundred images a day to help carry the load.

--LPfi (talk) 13:55, 24 October 2018 (UTC)

@ARR8: I accept that another WV could use our maps, but in most cases they would be best edited first. City static maps should have the words "See", "Do", "Eat" etc in the key translated. Region and huge city maps are likely to need to be edited because of different boundaries, but I see that 3 of the 13 other languages that have articles on Edinburgh use our map of districts. I would consider including other map data like mapmasks. However photos should not be included, except to the extent that they are currently allowed. Copyvio uploads of photos would be likely to be a significant problem, as unfortunately many less experienced editors do not have a sufficient understanding of copyright. AlasdairW (talk) 19:55, 24 October 2018 (UTC)

Good news! Over at Meta, I got a reply from User:NKohli (WMF), who says among other things that the bot can notify us when the "no permission since" template is placed (as well as the other deletion templates). If I understand correctly, enabling this would largely solve the problem K7L pointed out. So far I see support for enabling the bot and no objections. If there are no major objections in the next few days, I think we can go ahead and enable it. —Granger (talk · contribs) 08:18, 24 October 2018 (UTC)

By all means, let's enable it! Thanks for asking at Meta. Ikan Kekek (talk) 08:45, 24 October 2018 (UTC)

Because I wasn't clear and it was requested - definitely support enabling the bot. ARR8 (talk) 13:13, 24 October 2018 (UTC)

• Is this bot that would tell us that some media was about to be deleted? If so, I support use of the bot. --Comment by Selfie City (talk | contributions) 14:10, 24 October 2018 (UTC)

• I support use of the bot and also support the removal of the existing "Please do not upload free files locally, as they will be deleted" policy at Wikivoyage:Upload file. The author of an individual guide should be free to decide whether the resources on which that page rely are best uploaded locally or to some other repository (such as Commons or Wikidata). K7L (talk) 15:53, 24 October 2018 (UTC)

Hi. I'm on the team that runs the bot Granger pointed to. I'd like to mention that the bot will post a notice about the file being tagged on the talk pages of the pages where that file is being used. I hope that will suffice for your purposes. Thanks. -- NKohli (WMF) (talk) 17:34, 24 October 2018 (UTC)

Great! I would tend to oppose allowing local uploads, willy-nilly. No-one has so far given a figure on how common it is for non-copyrighted images we're using on Wikivoyage to be arbitrarily deleted from Commons. I want to know whether we're using an axe on a housefly before I support this kind of drastic, unsisterly change. Ikan Kekek (talk) 19:23, 24 October 2018 (UTC)

I support using the bot, and I think that we should leave any thoughts of changing our upload policy for a few months to see how this works out. If an image on commons is likely to be deleted because of copyright issues about the subject of the photo (not the photo itself), then it an be uploaded locally in accordance with our exiting policy. AlasdairW (talk) 20:03, 24 October 2018 (UTC)

I still think, along with K7L, that we should allow uploads of pictures locally. Why have a system for local uploads of pictures if we practially never use it? --Comment by Selfie City (talk | contributions) 01:10, 25 October 2018 (UTC)

Because we're part of the Wikimedia Foundation group of sites, and Commons is the repository of images for all of them. And because there is a special, narrowly-defined purpose for local uploads. And finally, because still, no-one has given any figure on how many times a file we're using on Wikivoyage has been deleted from Commons on grounds other than valid copyright grounds. I'm still waiting for that answer. Ikan Kekek (talk) 03:10, 25 October 2018 (UTC)

I don't see why certain files were deleted has much to do with it, whether it's copyright or not.

I am willing, however, to start with us just doing static maps for local uploads if that is the best compromise. There is clearly strong opposition to local uploads, so if this is the best compromise we can do, in my opinion, it's better than nothing. --Comment by Selfie City (talk | contributions) 03:25, 25 October 2018 (UTC)

Why it matters is that if a photo is copyrighted and not Copyleft and we use it, the site could be liable for copyright violation. The whole reason for local uploads is for very important attractions that are themselves copyrighted (e.g. "The Bean" in Chicago) but for which photos are important enough for a travel guide that we are willing to consider them "fair use" and hope that no-one sues and that our view would prevail if they did. And yes, they are also to protect certain images that are so sensitive to possible edits and so forth that they have to be here. That would include DotM/OtBP/FTT banners. Maybe it would include static maps, too. I fail to see why it would include anything else, and that's why I keep asking for a quantification of the problem. Ikan Kekek (talk) 03:35, 25 October 2018 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Then perhaps the best thing to do would be to use the bot and upload static maps locally (and upload no other media except the banners we usually upload here, etc.) for a few months and then take further steps, say, around January or whenever. --Comment by Selfie City (talk | contributions) 03:38, 25 October 2018 (UTC)

(edit conflict) It seems to me that enabling the bot will essentially solve the problem that prompted this discussion. Let's start with that, and if there are still problems afterwards, we can reconsider other solutions. I don't see any reason why static maps should be an exception to the general policy. —Granger (talk · contribs) 03:41, 25 October 2018 (UTC)

Only if they might not be secure at Commons. But I think there was only once a problem with one? Ikan Kekek (talk) 03:44, 25 October 2018 (UTC)

I think it was data for a mapshape, rather than a static map, if it’s the one K7L and Alexandr referred to above.

I don’t know the site-wide experience, but my experience with Commons is it’s an occasional inconvenience but not a big problem (although everyone's definition of "big problem" is going to vary. I’ve uploaded about 300 images since migration and had another 100 or so transferred over from WT Shared, and only 3 have been nominated for deletion in five years — 2 static maps and 1 banner. Two images were kept after a simple explanation on my side and the third is pending (and seems to be a case of the nominator not understanding that our district maps aren’t meant to be official city maps).

My biggest concern with hosting more images locally is the amount of work that will be required to police it if the volume of uploads gets sizeable. Having patrolled the old WT Shared pre-migration, it takes time and resources. People would upload copyrighted pictures they got from other websites, or they wouldn’t pay attention to the license. Then there are the technical things like knowing the freedom of panorama rules. It takes time to learn this and develop the expertise to fairly quickly spot what are the likely copyvios and verify it. I think implementing the bot discussed above and dealing with the occasional Commons deletion nomination seems like a much easier course than patrolling local uploads. -Shaundd (talk) 06:14, 25 October 2018 (UTC)

CommonsDelinker has made 250 edits since 3 July 2017. This is mainly files which have been deleted on commons, but does include a few file moves on commons. This is probably a slight underestimate of the scale of the "problem", because there will be a few files that were manually removed either because somebody saw that they were VFD on commons, or reacted quicker than the bot to a red link. Howvere I think that we can be confident that there is less than one file per day that is deleted on commons which is used here. AlasdairW (talk) 19:03, 25 October 2018 (UTC)

Thanks. That's very helpful because it goes some way toward quantifying the problem. However, in order to understand it better, it would be important to know how many of the delinked pictures weren't delinked because a copyrighted photo was being used, as opposed to because there was some copyrighted building or work of public art in the photo - or, most importantly, for neither reason. We have no more right to host copyrighted images not covered by Creative Commons Copyleft than Commons does, but we have given ourselves the right to show copyrighted buildings and works of public art when they are among the main sights in a city and therefore important for prospective visitors to see. However, Wikivoyage's existing policy on local uploads already deals with that issue clearly. So how many images are being affected that are neither themselves covered by restrictive copyrights nor photos of copyrighted buildings or public art that are already locally uploadable? Ikan Kekek (talk) 21:12, 25 October 2018 (UTC)

One file that was deleted recently was the logo on Tokyo 2020 - File:Tokyo 2020 Olympics logo.svg. Strictly this would not be allowed to be uploaded locally because it is not a photo. I did find a replacement photo on commons which will do for the moment, but is not ideal.

I have had 6 of my 1500 uploads on commons deleted - 5 of these were freedom of panorama questions (one was a banner cropped from an image that was a copyvio). I think that four of these would have been kept had we had the much longer VFD discussion that we have here, as there was some evidence of permission to photograph. AlasdairW (talk) 22:20, 25 October 2018 (UTC)

What if we let only autopatrollers upload images at first? Then policing would not be so necessary, since anyone else who uploaded a picture would just have it deleted. --Comment by Selfie City (talk | contributions) 23:02, 25 October 2018 (UTC)

Thanks for recounting that, AlasdairW, that's very helpful. My reaction is that while these are frustrating experiences, they show Commons acting properly. The logo was obviously copyrighted, and the others were judged to violate laws not allowing freedom of panorama in those countries. And the solution is that such images should indeed be locally uploaded at Wikivoyage. Wikivoyage policies already allow for that. Ikan Kekek (talk) 23:44, 25 October 2018 (UTC)

I checked the last twenty or so CommonsDelinker actions, about a month worth (without being admin, so could not check the images, descriptions or revision histories, just logs and RfDs). One was of the Centre Pompidou, for which there probably are many deleted images we could use. One was a logo (the Tokyo Olympics), one a personal file, one just a renaming. Eight seemed to be confirmed copyvios. Seven were deleted as no permision/no source since or "copyvio" without further comment, a few of those old uploads, which should have been given an RfD. The actions come in chunks of admin action, so a bigger sample would be needed for a really representative picture. My guess is that at most one or two images were false positives, and if so, they might be uploads with little documentation by retired anonymous contributors – finding another picture may be easier. --LPfi (talk) 05:42, 26 October 2018 (UTC)

Seeing support for the bot and no opposition, I have requested that it be enabled, including for the "No permission since" template. —Granger (talk · contribs) 02:29, 5 November 2018 (UTC)

Good news! The bot has been enabled; its user page is here: User:Community Tech bot. —Granger (talk · contribs) 11:41, 15 December 2018 (UTC)

Good, this should help with the situation. --Comment by Selfie City (talk | contributions) 14:28, 15 December 2018 (UTC)

Commons deletion notification bot enabled

Swept in from the pub

Good news! The bot to notify us when files are tagged for deletion on Commons has been enabled. Here is its user page. For reference, the discussion that led to this is here, and the request I made on Meta is here. —Granger (talk · contribs) 11:40, 15 December 2018 (UTC)

Airports and Link Infoboxes

Swept in from the pub

I don't know where else to put this, but I think that the images that show up when you hold over the link to some cities should be photos of the city, rather than (one of) the airport(s) that service the city (for example, if you hold over the Ohrid link). I don't know if the airports are the images for the links for a reason or not, but as a traveler, I prefer seeing an image of the city I am researching, rather than of the airport I am flying into. Also, sometimes the airport's photo doesn't even exist on the city page. If this is irrelevant, just ignore it. I can understand the airports being the photos since they might be the first part of the city a traveler goes to, but if they are just there for no other reason I think it'd be better to put city photos in their place. Donaudamphschifffahrtselektrizitätenhauptbetriebswerkbauunterbeamtengesellschaft (talk) 03:11, 6 January 2019 (UTC)

I usually work with the preference disabled so had not noticed this. Would have also though it would be the first image on the page but it appears to be the image in the first listing on the page, which will often be the airport or the rail station in the Get in section. Agree not the best choice. Would be better to pick, first image or pagebanner or the image given in Wikidata for the article. Not sure what is controlling this, anyone know?--Traveler100 (talk) 06:46, 6 January 2019 (UTC)

Apparently selection is more to do with a size ranking of images on the page. See mw:Extension:PageImages#Image choice, but cannot say I fully understand it. info of page. --Traveler100 (talk) 07:32, 6 January 2019 (UTC)

Scroll gallery

Swept in from the pub

Moved from Wikivoyage talk:Travellers' pub

In the German version of Wikivoyage the Scroll Gallery, exists. It serves to present a picture sequence. Up to 30 pictures can be presented. If this would be adapted to the English version, that would put an end to the tiresome discussions of too many pictures.

https://de.wikivoyage.org/wiki/Vorlage:Scroll_Gallery

User:DocWoKav 4. March 2019

As I have stated on DocWoKav's talk page, I'm not an expert at code for this, but our friends at the WV:UX Expedition, I'm sure, could look into this. --Comment by Selfie City (talk | contributions) 14:50, 5 March 2019 (UTC)

Examples of this in use are de:Alexandria/Ost and de:Canberra. I think that the Alexandia example looks better due to the use of the maxHeight parameter, which stops the rest of the page jumping as the images are scrolled. AlasdairW (talk) 22:03, 5 March 2019 (UTC)

Is it adapted to the mobile version? This may be great!--Yuriy kosygin (talk) 18:06, 6 March 2019 (UTC)

We don't have to import anything. It's now a built-in feature of the gallery tag: gallery mode="slideshow". See User:WhatamIdoing/Sandbox for a trivial example. Yuriy, I don't think that this (the gallery tag slideshow) works for mobile. Please let me know if you'd like work-me to figure out whether there's been a request for that. WhatamIdoing (talk) 02:53, 7 March 2019 (UTC)

@WhatamIdoing: I've tried to do a slide show based on your example with other pictures, but it's getting too big. How can you reduce the size and then push to the right edge? Maybe you can make a second example with a mix of high-edge images and cross-edge images of different sizes, which lies on the right edge and fits into the flowing text. Then it's easy to just copy paste. User:DocWoKav 08:45 26.March 2019

WhatamIdoing I think the mobile version should require the Scroll gallery. Reduce many images to appear on one page at the same time.--Yuriy kosygin (talk) 18:27, 7 March 2019 (UTC)

phab:T194887. I pinged you in the comment, so it should be easy to find. WhatamIdoing (talk) 01:41, 12 March 2019 (UTC)

I don't know if I can login to that site to comment. I'll give my response to this:

With a volunteer hat on: Does this also mean the end of the archaic image policy on Wikivoyage? https://en.wikivoyage.org/wiki/Wikivoyage:Image_policy#Minimal_use_of_images

Answer: Not necessarily. This is still subject to discussion. Ikan Kekek (talk) 02:04, 12 March 2019 (UTC)

Any editor can log in there. It's the same accounts, etc. Click the "Log In" button in the top bar, and then click the "Log In or Register MediaWiki" button. OAuth will probably ask you to authorize it, but you'll be logged in via your regular Wikivoyage account. (Jon, if you want to talk content policies, this is probably a better venue.  ;-) WhatamIdoing (talk) 15:42, 12 March 2019 (UTC)

"that would put an end to the tiresome discussions of too many pictures." - It was my understanding that the concern mentioned on Wikivoyage:Image_policy#Minimal_use_of_images about "too many photos" was performance, which frankly is terribly misinformed. I'd love to see more images on English Wikivoyage and would help do anything I can to get the gallery template working in mobile to support this. Jdlrobson (talk) 15:55, 12 March 2019 (UTC)

ps. de:Vorlage:Scroll_Gallery seems to works perfectly on mobile. Good job! Jdlrobson (talk) 15:57, 12 March 2019 (UTC)

I don't think performance is the only issue. There are important questions of style that are encapsulated in the following statement: "Minimal use of images doesn't mean none. Instead, it means enough images to illustrate the text and show some of the highlights but not so many as to overwhelm the text and turn the article into a photo gallery." Of course, Commons is the Wiki where there are galleries, so why, other than to avoid conflict from Wikivoyage users who are inspired to put thumbnails into every square centimeter and then go far beyond the end of the article, would we change that policy? I strongly suggest you read the long thread at Wikivoyage talk:Image policy#Minimal use of images - not appropriate, including the Resolution? section. Also, watch your rhetoric. You won't get more supporters by putting up straw men like "This is absolutely not a reason to prohibit adding images on article" or ridiculing the entire long-established idea that Wikivoyage is primarily a text, not a photo gallery. Ikan Kekek (talk) 19:31, 12 March 2019 (UTC)

Misinformation about low bandwidth

"Don't get overexcited adding images to articles. Travellers may be using Wikivoyage from networks with very low bandwidth. In some countries, an internet café with ten computers connected to a single 56k modem is still fairly common. Even travellers in developed countries can often be limited to 10k mobile GPRS access."

This seems outdated. It's also not true. Images are downloaded differently from other resources. While true that images will continue to download slowly on poor connections, the article will still be accessible and readable, so this is a very bad piece of advice. On mobile, these images will also be lazy loaded (please read my blog post "How Wikimedia helped mobile web readers save on data" on this subject).

This is absolutely not a reason to prohibit adding images on article. I'd recommend you instead encourage images, but at the very least you should remove this badly informed piece of advice Jdlrobson (talk) 15:54, 12 March 2019 (UTC).

Agree on removing that justification, if not changing the policy. Some other corrections that should be made:

• Preferring PNG conversions of SVG source files. There is no reason to have this suggestion; the mediawiki software does this automatically for embedded SVGs, and, even if it didn't, every modern browser supports SVG files, and they are both smaller in file size and look better on unusual resolutions.
• Disallowing GIFs. There's no reason to disallow static GIFs, and not all animated images are GIFs. Any static image should be allowed, and the prohibition should be against animated images more generally.

ARR8 (talk | contribs) 17:36, 12 March 2019 (UTC)

Let's focus on the specifics. Obviously, adding images is not banned, so don't introduce that irrelevancy. Ikan Kekek (talk) 19:18, 12 March 2019 (UTC)

Everyone reading or participating in this thread needs to also consider questions of style, as hashed out at length in the #Minimal use of images - not appropriate thread, including the #Resolution? subthread. It's good if there are no longer technical limitations, but that's not the end of the discussion. Ikan Kekek (talk) 19:34, 12 March 2019 (UTC)

@Ikan Kekek: I think this is a separate discussion from that one. I'd urge you to reread the two comments that are a part of it so far. ARR8 (talk | contribs) 19:42, 12 March 2019 (UTC)

No reason to reread them. I understood them the first time. If bandwidth were truly no longer an issue, that would be great. Ikan Kekek (talk) 20:08, 12 March 2019 (UTC)

It's possible that the low bandwidth thing is not an issue almost anywhere in the world as of 2019. Still, as per my comments in threads above, we shouldn't add so many photos to the articles that they stop looking like travel guides and turn into some kind of WikiInstagram. ϒψιλον (talk) 20:45, 12 March 2019 (UTC)

[outdent]
Lazy loading does not help with pay-per-mega connections or overloaded cache, and lazy loading on a slow connection will either make the page jump around or leave white boxes until the images are loaded. I do not know how serious these problems are in practice, but I'd prefer not ignoring them. --LPfi (talk) 21:27, 12 March 2019 (UTC)

Here's a comment I made that is in the thread I linked above:

Incidentally, I have DSL, and I'm finding that with all those images, not all of them download the first time and I sometimes have to reload the page to see them all, so with this many images, it seems like the original issue of download times remains relevant. Ikan Kekek (talk) 03:13, 13 September 2016 (UTC)

I still have DSL, so I think that it's still problematic for download times if we were to allow unbroken rows of pictures along the entire right of the page in a long article, let alone also allowing rows in the left and center. Ikan Kekek (talk) 21:34, 12 March 2019 (UTC)

When I travelled 10 - 15 years ago i put $1 coins into an internet terminal in a hostel, and so total page size in bytes mattered. Now I use WiFi on a long distance coach and a few MB may have to last for a 5 hour journey, and expensive WiFi is available on some aircraft. So I think that there is still a reason to be concerned with the download size of a page.

Although I am not strongly against GIFs, I think that we need to be cautious about allowing them. When reviewing edits that others have made, I can't tell just by looking at the wikitext whether a GIF is a static or animated image. I also doubt that there are many GIFs which are desirable to add to our pages, as they are usually used for diagrams and drawings. AlasdairW (talk) 22:19, 12 March 2019 (UTC)

10-15 years ago, sure, but I can assure you this is not a problem any more. Browsers prioritise CSS and HTML downloading first. An image cannot possibly impact the page loading time. In terms of page download size, as I've stated lazy loading on mobile helps with this (and you can switch to airplane mode in cases where you have limited WiFi), but the biggest problem by far with images on Wikivoyage is banners. If you truly care about this, banners should be removed from Wikivoyage. To take an example the total download size of Singapore on desktop is 6.2mb and 2.4mb on mobile (which has better optimised JS, CSS and images). The banner accounts for 400kb of that download. Image thumbnails from MediaWiki are pretty optimised at this point - adding about 8kb each. So if you added 50 images to a page, the banner would still be larger.

I stick by my original statement - this policy is seriously outdated and terrible advice. Please remove it, as this kind of advice hinders creativity. Jdlrobson (talk) 18:44, 2 April 2019 (UTC)

FWIW that Singapore example has 181 images on it !!! (as the flags are images), so given my current read of the current policy it is in violation... that doesn't sound like minimal to me. That said I think it's a great example of an article which uses images effectively (but I'd argue doesn't have enough "thumbnails"). I'd much rather replace all those embassy flags with a couple of thumbnails of equal size in bytes! Jdlrobson (talk) 18:50, 2 April 2019 (UTC)

Those are tiny icons. You seem to be talking past the fact that I, with a DSL connection, would take a long time to download a long article with a row of unbroken regular-size thumbnails all along its left. That's not 15-year-old info. It's current. Not everyone everywhere has super-fast Internet connections. Ikan Kekek (talk) 19:43, 2 April 2019 (UTC)

6.2 MB takes a minute with a 1 Mb/s connection. That is a lot of time and a decent connection. I have 10 Mb/s at home, but there may be others beside me using it, and I may want to do something else at the same time (OS updates or whatever). And you might want to download a batch of articles to a memory stick in a hurry. If you think bandwidth is no issue with such articles, I suppose you live in a different reality from me. --LPfi (talk) 20:40, 2 April 2019 (UTC)

I think that the language at the start of the minimal use section looks dated. I think that we should replace:

• "Don't get overexcited adding images to articles. Travellers may be using Wikivoyage from networks with very low bandwidth. In some countries, an internet café with ten computers connected to a single 56k modem is still fairly common. Even travellers in developed countries can often be limited to 10k mobile GPRS access. "

with:

• "Don't get overexcited adding images to articles. Travellers may be using Wikivoyage from networks with low bandwidth, or with a cost for every MB used. Several travellers may be sharing the one poor mobile data connection. A traveller using the WiFi on a bus or train may only have a few MB of free data allowance for a long journey."

This changes the examples to something that applies in 2019, not 2009. AlasdairW (talk) 21:13, 2 April 2019 (UTC)

Sure, go ahead and change the wording like that. Ikan Kekek (talk) 21:16, 2 April 2019 (UTC)

• I think there are plenty of good reasons not to add too many images to one article, but I think mostly "very low bandwidth" is not a problem anymore. What I get more often, which is related, is — I can't remember its name — the appearance of a webpage without CSS. I agree with AlasdairW's wording. --Comment by Selfie City (talk | contributions) 15:17, 3 April 2019 (UTC)

As SelfieCity says, there are plenty of good reasons not to add images to an article, but honestly this is not a good one from my perspective given a t. If it helps I can pull in some people from Wikimedia performance team (who are paid experts in this field) to provide advice on image usage. I understand arguments against bandwidth (I worked on lazy loading images on mobile - see How Wikimedia helped mobile web readers save on data for this very motive), but I think that's the job for engineers - not the community. I think it's a shame that the community isn't focusing on advice around content creation and leaning on developers of the software to take care of performance concerns.

However, if you really want to cut the total bytes of a page, banners should be removed from the site. The banners on Spain, France and Paris are around 400-800kb and this seems to be common across the site. Looking at thumbnails on that page they are around 10-20ks, a A banner is thus equivalent to 400/20=20 thumbnails. As a result, I'm really struggling to understand the logic here and why you are fighting a bandwidth argument against thumbnails, yet including large banners.

Maybe instead of thinking about "number of images", it might be useful to guide people to measure the size of all image downloads on a page, and say something along the lines of "Be wary of page download size when adding images as travelers may be using Wikivoyage from networks with low bandwidth, or with a cost for every MB used. Several travelers may be sharing the one poor mobile data connection. A traveller using the WiFi on a bus or train may only have a few MB of free data allowance for a long journey. Total downloads for any given page should not exceed Xkb on a desktop/mobile device."

That said, I think most browsers and internet users are savvy enough to disable images, or use something like Kiwix if they are worried about data costs. We used to provide a disable images mode on the mobile site of MediaWiki, but we removed it given low usage and browser capabilities. Jdlrobson (talk) 05:36, 8 April 2019 (UTC)

Any improvements on the software end would be great, but there are also style considerations. A decision was made quite a while ago and confirmed higher up this page that there should be a sufficient number of images to intrigue the reader but that photo galleries showing dozens of pictures belonged in Commons, not a travel article. That's a style decision that not all guides follow. For example, Eyewitness guides have lots and lots of high-res photos, while the guides of the Touring Club Italiano that I used for Tuscany and Florence and Environs had no pictures whatsoever except for things like diagrams of floor plans of some churches. Instead, they mentioned every architect of every building in every city that was covered and the title, artist and exact location of every artwork in every church. Ikan Kekek (talk) 07:14, 8 April 2019 (UTC)

Make sure no images extend below the end of an article

"Make sure no images extend below the end of an article" is not good advice. Whether an image extends past the end of the text depends entirely on your font/thumbnail prefs/screen size combination. This rule amounts to "whoever uses the smallest font, on the widest screen, with the biggest image size, gets to decide whether you're allowed to put an image in the last section of the article" – because even in a fully developed guide, that last section might not have more than one or two lines, and thus any image is going to "extend below the end of the article", even if it's the only image on the entire page.

I think that the approach in #Resolution? has taken the wrong direction. Images should be added where they make sense for the content. Middle Eastern cuisine#Beverages has a very reasonable image, and it should not be removed merely because it's a vertical image towards the end of the page, even though we can say with great certainty that for some combinations of prefs it will "extend below the end of the article", nor should it be moved to a different part of the page to keep it from hanging down below the edge of the text.

I think what was actually meant was: Don't stack up so many images that a long string of images hangs down along the right side on a typical laptop-size screen. I could get behind that, but that wasn't what was actually written in the end.

However, I think a more relevant rule would be this: There should generally be no more than one image per == Level 2 Section Heading == unless that section is long, in which case, it may be more appropriate to have as many as one image per 1,000 characters. Then there cannot be disputes over whether the image being too tall on my wide screen, but not too tall on anyone else's, is actually a problem, and we still won't have a hundred images on any page. WhatamIdoing (talk) 18:34, 13 March 2019 (UTC)

What's a typical laptop screen? Is it 13 inches like mine or something else? I don't mind rephrasing if appropriate, but on images extending beyond the end of the page, it's not just the number of images but also sometimes their positioning that can be at issue. And I don't agree that "Images should be added where they make sense for the content", because that would result in a bunch of images in "See" (or at least theoretically in that section, as some will appear to be lower if there are a bunch of them) and then not much in most other sections. Ikan Kekek (talk) 03:14, 14 March 2019 (UTC)

I think it is not worth defining the window width with which to judge the layout, neither to give specifics on where images are to be placed. Usually some hints in the guideline, common sense and discussion work much better. I still think context should be given weight in placing images, but that does not mean every sight should be in See: a sight seen as symbol of a city could be in Understand, a landmark in Get around and so on. Usually I try to find a pretext for placing the image where it suits the layout, hinted at in the caption if the image otherwise seems out of context. For browser window width I think the judgement should be done with reasonably common settings. --LPfi (talk) 07:46, 14 March 2019 (UTC)

The images will be in somewhat different places on different screens, though, so it doesn't pay to be really exact, just to distribute them fairly evenly, with space between them. Ikan Kekek (talk) 07:53, 14 March 2019 (UTC)

PNG or SVG

User:ARR8 recently edited this policy to recommend embedding SVG images instead of PNG images in articles. I oppose this change on the grounds that the SVG maps look worse in the two articles where I've examined the difference, China and Europe. In the China map, some of the letters in the SVG version are not aligned, giving the words a wobbly look (as in, for instance, "SICHUAN" and "XINJIANG"), and in the Europe map, the words are slightly harder to read in the SVG version. I urge others to look at China PNG, China SVG, Europe PNG, and Europe SVG to compare for yourselves. —Granger (talk · contribs) 02:00, 19 March 2019 (UTC)

My first instinct would be to agree with you, but may I ask ARR8 if he perhaps has some other motive for wanting the change made, beside the quality of the images? I feel there must be some reason he wants to do what he's doing. --Comment by Selfie City (talk | contributions) 02:10, 19 March 2019 (UTC)

The SVG files have numerous advantages unrelated to quality. For example, it is now possible to redo the regions of China in about five seconds by editing a couple of lines of text in the file. Similarly, translating the file to another language should only take a few minutes. ARR8 (talk | contribs) 02:18, 19 March 2019 (UTC)

(ec) Granger, as I explained to you in the edit summary, this is not that simple and those two converted PNGs were modified after conversion and are not, in fact, equivalent to the original SVG. I now need to figure out what those modifications were and reproduce them in the SVG files. The policy is irrelevant here.

You've requested that I fix the images; I will. Please have some patience. Don't turn this into a bigger issue than it needs to be. This is the kind of thing that a person no longer want to work on maps. ARR8 (talk | contribs) 02:14, 19 March 2019 (UTC)

Thanks for the explanation. I misunderstood the edit summary and didn't realize that the PNGs were modified after conversion. I apologize for overreacting, and I'm happy to wait until you have the chance to fix the images. —Granger (talk · contribs) 02:18, 19 March 2019 (UTC)

Apology accepted. The intent is for the SVG images to look identical to the old ones, i.e. for the change to be unnoticeable and purely technical. This is the same policy I self-imposed when I was rewriting the Main Page for mobile support. If you can notice when I've made one of these backend changes, feel free to let me know, because something has gone wrong and slipped my notice. This is a busy time for me and I may not be able to fix the files right away. Thanks for understanding. ARR8 (talk | contribs) 02:27, 19 March 2019 (UTC)

Sure, that makes sense—no hurry. I have a lot going on in real life as well, and I might have overreacted because I'm a little stressed for reasons unrelated to Wikivoyage. I'll try not to let that happen again. I'm grateful for all the work you've been doing to improve the site's appearance and usability—it's good that we have someone with your technical knowledge. —Granger (talk · contribs) 02:41, 19 March 2019 (UTC)

Why the image policy matters

The article for Jeongeup, South Korea, a few weeks ago, with much more pictures and content comparable to pictures than text: https://en.wikivoyage.org/w/index.php?title=Jeongeup&oldid=3577188 --Ypsilon (talk) 15:17, 20 July 2019 (UTC)

I think it does not matter much for such outlines. Aesthetics start to matter when the content more or less is in place. Before that I think what matters is that it is easy and feels worthwhile to add content. A good description about the place itself helps at least with the former, while a few good images, even when they extend past the text, can help with the latter. When the article approaches usable, it is easy to get rid of a few extra images (although instead of loading a stub article full with images, one should make sure those images are in the right category on Commons, and that the category is linked to the article. --LPfi (talk) 16:54, 26 November 2019 (UTC)