Wikivoyage talk:Image policy

From Wikivoyage
Jump to: navigation, search

For archived talk page discussions see:

Images under the Exemption Policy[edit]

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 "Ontario 401.svg 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[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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

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[edit]

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[edit]

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[edit]

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[edit]

Swept in from the pub

Hi guys! I've seen this nice panorama feature in German wikivoyage: [1] 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)

Proposal to change default thumbnail size[edit]


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. Frankemailtalk 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[edit]

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[edit]

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[edit]

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)[edit]

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[edit]

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 [2][3][4]—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)
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)

How many images is too many?[edit]

I know dive guides tend to have a lot of pictures and all, and we sort of have an unofficial blanket exception for using galleries in such articles, but isn't having 193 images in one article at least 500% more than necessary? Ignoring for the moment that several of them also seem to violate our people in photos and montage policies, do we actually consider it acceptable to load an article with this many images? Texugo (talk) 22:48, 15 April 2013 (UTC)

Yes. No. LtPowers (talk) 23:17, 15 April 2013 (UTC)
I think Peter S. has already suggested to the author to move out most photos to a gallery subpage a la Diving the Cape Peninsula and False Bay/Pinnacle/Gallery. But yes, that page would be unloadable on many internet cafe connections! --Peter Talk 03:05, 16 April 2013 (UTC)
Even on a special gallery page, does this one location really warrant so many pictures? It's just a subpage of a larger dive site. Texugo (talk) 03:08, 16 April 2013 (UTC)
It wouldn't for a usual destination guide, but it would be OK if the images have a specific function (like helping identify species on the dive or something like that?). I'm not a diver, though, so I don't really know. An ever so slightly similar example would be the Chicago skyline guide, which uses a bunch of big images for a specific function, rather than general illustration. --Peter Talk 03:16, 16 April 2013 (UTC)
Peter Southwoods proposal for a gallery sub-page (with a "size" warning) will work just fine here. The primary author is providing us with a rather unique resource here. -- Alice 04:58, 16 April 2013 (UTC)
But, ok, even considering only the 25 images of types of coral, are they 25 types that can only be seen at Cobbler's reef? Anywhere off Barbados? Anywhere in the Carribean? Anywhere in the North Atlantic? Anywhere in the world? Wouldn't it fit better with our other practices of non-duplication to cut down on stuff that is not unique to this site? Texugo (talk) 12:43, 16 April 2013 (UTC)
Also, does a dive site need 10-20 aerial shots? Multiple shots of the same beaches from different angles, photos of divers which otherwise don't show anything much? Texugo (talk) 12:49, 16 April 2013 (UTC)
A lot of the shots would be better suited to a travelogue than a travel guide, as they seem to recount a specific person's experiences. Those are the ones that trouble me the most. LtPowers (talk) 13:35, 16 April 2013 (UTC)
I agree that there are more images than are necessary on the Cobbler's Reef article, but I have avoided interfering with its development in the interests of finding out where it may go. The contributor is new to WV and to wiki culture in general, and is approaching the structure of the article differently to how I do it, and I think that an alternative layout and approach to content for a diving topic is interesting and refreshing. I do not advocate such high bandwidth pages as a general policy, but would like to see whay comes out of this one. I think that as it develops some of the pictures will be removed or replaced, and a sub-page gallery will be needed. My suggestion would be to make tactful constructive suggestions on the talk page for changes that would actually improve the article. I am intentionally minimizing my influence there as I don't want to force the development to my own preconceptions. As Alice says, this is becoming a rather interesting and unique resource, and I don't want to chase the contributor away. • • • Peter (Southwood) (talk): 09:14, 17 April 2013 (UTC)

Short videos[edit]

Swept in from the pub

I was a bit bold and just added a 2 minute video to Lancaster (Pennsylvania), so I might as well do it here also.

A Walk up Main Street, Adamstown, Pennsylvania, video (2 minutes)

I've done a couple of these historic districts as videos on Wikipedia and figure that Adamstown, PA is much better known than Delta, PA, or (the soon to be released) Wellsville, PA. My main question is whether Wikivoyage would be interested in this type of "video" if I were to get into better known topics such as "A walk up Broadway, NYC", "A walk on the National Mall, DC" or maybe even "A tour of the Kremlin"?

Please let me know either here or on my Wikipedia talk page.

Smallbones (talk) 19:13, 1 August 2013 (UTC)

Since videos can't be watched when our guides are printed. I doubt if it would be a good idea to introduce videos in the articles. --Saqib (talk) 19:33, 1 August 2013 (UTC)
For this type of video, any frame can be shown as a photo from Commons, so the video can easily be changed into a single photo for printing. I'm more surprised, however, by the implied policy that everything here must be printable. I know WP:NOTPRINT doesn't apply here directly, but it seems like a surprising departure. Is audio allowed here? gif files? External links? Smallbones (talk) 20:07, 1 August 2013 (UTC)
The policy of "neutrality of medium" is explicit here, not implied, though I can't find the page right now. To answer your questions: Audio: No. Images: Upload them to Wikimedia Commons, then link them as thumbnails. External links: Please read the external links page for guidelines. Ikan Kekek (talk) 20:13, 1 August 2013 (UTC)
Nice video: appropriate music, well lit and a steady camera. Personally, I don't think that the inability to print a video should no more veto video embedding than the inability of blind people to see still images should veto their use.
However, even though I'm probably one of the more aged editors here, I'm usually ahead of the curve here in my opinions and (remembering what happened to another editor's earlier introduction of a non-still image file about penguin calls) I wouldn't hold your breath. --W. Franke-mailtalk 20:22, 1 August 2013 (UTC)
The basic idea sounds really cool! Seriously! Sadly I'm afraid it can't be implemented here for the above mentioned reasons. Your idea also got me thinking more about the combination WV+video. How about making 2-5 minute video guides highlighting the most important points of interest of our destinations a bit like an extremely short version of Lonely Planet's Globe Trekker episodes. They'd be uploaded to YouTube where also people who've never heard about Wikivoyage could find them (and subsequently come here to read the rest, get more and more interested, eventually become contributors themselves and...). Comments? ϒpsilon (talk) 20:35, 1 August 2013 (UTC)
Great promotional idea! It's no good having great articles if few people read them. Terrific! --W. Franke-mailtalk 21:00, 1 August 2013 (UTC)
As you know, Frank, this site operates on consensus, and you also know how to try to change consensus. I'm not convinced it's so important for everything in this guide to be printable, myself, as online reading is increasingly standard. Would you like to reopen a discussion about that? What would be the right talk page for such a discussion? I like your idea, too, Ypsilon. Ikan Kekek (talk) 20:37, 1 August 2013 (UTC)
Sometime in the last 7 years, this consensus thing got twisted back to front. At the beginning we were able to plunge forward and do new things and only if there was a consensus not to do something did we have to halt progress. Now it seems that consensus is needed to make any change, however much this benefits the traveller, or however much it seems obvious. A prime example of this negative attitude is our current image policy. This really isn't the Wiki way. --W. Franke-mailtalk 20:57, 1 August 2013 (UTC)
I may not be as longtime an editor on this site as you are, but I think what you're trying to do - unilaterally buck an established consensus instead of trying to change it with an argument in a discussion - is not the Wiki way. So please stop freelancing and engage in a discussion. I would like to reopen this, too - the right way. Ikan Kekek (talk) 21:02, 1 August 2013 (UTC)
Can you point me towards that strong-verging-on-unanimous consensus discussion not to have video? This is the only mention I could find: Wikivoyage_talk:Image_policy#Audio_files The way I read that, it tailed off inconclusively like too many of our recent discussions. This "consensus of stasis" needs to be reversed so that we have less of the Germanic attitude of "what is not specifically allowed is forbidden"! --W. Franke-mailtalk 21:28, 1 August 2013 (UTC)
Wikivoyage:Image policy#Other media - "...do not use other media files like digital sound clips or video images.". As Ikan noted, your tendency to make contentious changes for the sake (apparently) of making a point is counter-productive to actually implementing the change you want to see put in place. -- Ryan • (talk) • 21:35, 1 August 2013 (UTC)
Ryan, where do you think the best place for reopening this discussion is, Wikivoyage talk:Goals and non-goals or Wikivoyage talk:Image policy? Ikan Kekek (talk) 21:39, 1 August 2013 (UTC)
The broader discussion about whether the emphasis on print is still relevant as an overriding goal and whether it is implemented at the expense of our online presence is probably best done at Wikivoyage talk:Goals and non-goals, but if we're just discussing the specific point about whether videos should be allowed, and if so what standards should govern their inclusion then the image policy talk page would make sense to me. -- Ryan • (talk) • 21:57, 1 August 2013 (UTC)
I too think that's a discussion worth re-opening. I get why we want our guides to be easily printable, but I don't see why that should prevent us from having /additional/ multimedia features online. If, as Smallbones says, a short video like this could be easily replaced with a single picture, no-one loses anything when printing. I guess we'd need a separate discussion about when and how video's (or whatever else) are wanted in an article, but let's not throw out a whole concept like this, because it doesn't print. Thanks for bringing it to the table, Smallbones :-) And Ypsilon, I like your idea, although I imagine it will be hard, as it would have to be pretty cool productions.JuliasTravels (talk) 21:08, 1 August 2013 (UTC)

Not the least bit interested in re-opening this discussion at this point. There are just too many variables and it's nearly guaranteed that the vast majority of videos uploaded are going to be cheesy in some way or other. I wouldn't even really want to consider allowing them unless we developed and enforced extremely professional, very consistent, and very high-quality standards which define a Wikivoyage-style of making videos for use in our articles, with very clearly established purposes and goals which included strict guidelines on content, titling styles and fonts, scene-changing, people in videos, music/sound/narration, credits, length and format restrictions, etc. etc. I really don't mean to criticize the video posted above, since it's fine for what it is, but even that one is not acceptable to me, not least because it is actually not even a video but a somewhat glorified slideshow of still shots with some zoom and pan added to them, containing zero actual video footage (and I don't think we are necessarily after new ways to squeeze in more still shots). Still, I cannot help imagine that most submissions will be much worse, either with cheesy music or cheesy fonts or cheesy scene change effects or something else cheesy. Let's face it, lots of people can take good pictures but the overwhelming majority of the editing public at large generally does not know how to make high quality, professionally edited videos, despite what they may think. I don't think arguing about this is going to be a very good use of our time at this point. There is way too much cheese on that pizza. Texugo (talk) 22:08, 1 August 2013 (UTC)

Like our travel writing, this is a subjective call of judgement. If you don't like a video and think it's not useful to travellers, then you have the same right to remove it from an article as you do with any other file or piece of writing you think is cheesy - no substantive difference.
I do think it would be useful to give some positive and helpful guidance as you suggest. --W. Franke-mailtalk 22:32, 1 August 2013 (UTC)
Well, before reading this, I started a discussion at Wikivoyage talk:Image policy#Proposal to allow video files. You make good points. Ikan Kekek (talk) 22:18, 1 August 2013 (UTC)

This is a really nice video (and I mean it, I enjoyed it), but in the end it is just a collection of steady images set to some music. Frankly, to me it doesn't really make much difference. I'd rather have more pics in the article and a good map than videos. Moreover, try to update a video like that, especially if well-cut and really set to music (rather than just having music in the background while the pics change every 5 secs). I would be against allowing such not to waste people's creative energy on making those. That said, if you enjoy doing those, there is nothing to prevents you from making those and uploading to Commons and YouTube. PrinceGloria (talk) 04:56, 2 August 2013 (UTC)

I, for one, think we need to take the scope of the question beyond merely allowing video files, and instead rethink the entire part of our policy that discourages content that a) isn't easily translatable to the print format and b) encourages, or rather over-encourages, articles that are short in length and light on non-textual bells and whistles that would take a long time to load on a slow Internet connection.
I think of it in terms of a simple cost/benefit analysis. Perhaps when we began on Wikitravel in 2003, there were large swaths of the world where high-speed Internet was unavailable or prohibitively expensive. Nowadays, however, this is true in far, far fewer cases than ten years ago—most places at least have Internet cafés where decent connections are available. There's certainly some remnant of that segment of our readership that benefits noticeably from our policy favoring quick-loading pages, but let's contrast that with the much larger segment that does have reliable access to affordable high-speed Internet, and is struck by the frankly boring look to much of our website, particularly compared to Tripadvisor and other travel-related sites. The new Main Page that we introduced earlier this year, with the banner images, was a step in the right direction—but at the same time, it violates the spirit of our less-is-more images policy, which, though it's gradually fallen by the wayside over the past years, is technically still in effect. If nothing else, we should reconcile those two things.
I think it's a mistake to deprive our site of the kind of visual pizzazz and innovative features that might potentially make Wikivoyage stand out from the pack and give our struggling readership levels a little boost (especially absent any solution to our massive SEO issues) in order to spoon-feed a relatively small number of travelers who happen to be visiting places that are true backwaters and didn't have the foresight to print off the pages they needed in advance. Sometimes when I surf our site I have to be reminded that this is 2013, not the '90s. A lot about Wikivoyage looks so old-school that I half-wonder where the cutesy little animated GIF icons, "Under Construction" clip-art, and web counters are.
-- AndreCarrotflower (talk) 03:23, 3 August 2013 (UTC)
I do agree with Andrew here - we need to be remember that, unlike Wikipedia, Wikivoyage exists in a market swamped by free travel guides. Yes, ours comes with a community and yes, it's a friendly, not-for-profit one at that, but to the end-user who simply wants a travel guide, that is of little importance. I am certainly not saying that we are unprepared to change - in the time I've been on here I've seen several very large changes to Wikivoyage but, as has been said, it still looks quite 'old school'. Whilst the Media-Wiki software is responsible for a lot of the aesthetics, I believe that more could be done. The world today is a lot more connected than it was when this site began and we need to keep up - prioritising offline use for an online travel guide when books still abound and print-outs will convey most (if not all) the necessary information feels like we are pandering to something of a niche audience.
In truth, there is no 'magic wand' (at least as yet) that we can wave and boost our Google rankings - the best way to get more people through the door is to make Wikivoyage better than the rest. Yes, our coverage is wider than some other sites, but a lot of it is either very limited or focussed on *ahem* sub-prime tourism destinations. I think WV needs some sort of unique selling point, something that we don't presently have (Feel free to disagree!). Could videos go some way to filling the gap or are there any other ideas?
We do have a lot of very high-quality content on here, but we need to display it in the best possible light - easily navigable but exciting and different. At present we remain very similar to a (much) more popular site that holds a grudge against us - not the best position to be in. To counter the other site we need to pull out all the stops and try every possible technique (including short, specially selected videos) to give this site the 'razzmatazz' it needs to flourish. The pagebanners that are now present on almost every page are a great example of the sort of innovations that we require; if we want WV to grow in the future we need to embrace what is available at present. :) --Nick talk 01:52, 5 August 2013 (UTC)
A house on Main Street, Adamstown, PA
Video from Wikimedia Commons
A Walk up Main Street, Adamstown, Pennsylvania (2:09 minutes) 13 MB
From the objections I understand, I've revised the proposed video presentation/link (see right). The photo is printable just like any other photo, the link to the video on Commons will add essentially nothing to upload times - only readers who click the link will see the video in any way. I don't think you should expect too much from this type of video right away - I think it might be of use in limited articles, and I'm not about to run around the world making them. On the other hand, I could very well do - and would enjoy doing - similar things with the Boston and Baltimore Heritage Trails, Independence Park in Philadelphia, or maybe a short battlefield tour at Gettysburg. I'd think the traveller and WV could very well benefit from these. Smallbones (talk) 03:10, 5 August 2013 (UTC)


Proposal to allow video files[edit]

This is a spinoff of the discussion at Wikivoyage:Travellers' pub#Short videos.

Current policy is laid out at the end of the "Image policy" page: "One of Wikivoyage's goals is to have Wikivoyage articles useful as printed pages. We therefore do not use other media files like digital sound clips or video images."

I do think that we should keep articles in a format that's useful as a printout, but I disagree with the conclusion and would also argue that online reading is increasingly becoming the standard, especially for sites about travel that are frequently consulted on smartphones while taking a train, sitting in a cafe, or walking on a street. So the crux of my proposal is that materials useful to travellers that can't be printed - such as short videos (or, possibly, sound clips, though that suggestion was recently shot down) - should be allowable, and that we should discuss creating new guidelines governing what kind and how many such files can be used or linked to. I would argue that allowing a video now and then doesn't decrease the quality of the printed pages; it just adds additional content that benefits those travellers who have access to the internet. And I think the risk of not keeping up with online technical capabilities that can make or/and keep this site cutting-edge is a lot greater than someone's mild disappointment at not being able to see a video from a printout. This is, after all, a website, not a book, and the external links many pages are replete with aren't clickable from a printout, either, but we include them at least in part because they are useful to people reading online. Ikan Kekek (talk) 22:16, 1 August 2013 (UTC)

Texugo made a lot of good points about video quality and so on in a reply to the thread in the Pub before I posted this, so I'm having very strong second thoughts about reopening this discussion, but have at it, anyway. Ikan Kekek (talk) 22:20, 1 August 2013 (UTC)
Here is what I posted in the pub:
Not the least bit interested in re-opening this discussion at this point. There are just too many variables and it's nearly guaranteed that the vast majority of videos uploaded are going to be cheesy in some way or other. I wouldn't even really want to consider allowing them unless we developed and enforced extremely professional, very consistent, and very high-quality standards which define a Wikivoyage-style of making videos for use in our articles, with very clearly established purposes and goals which included strict guidelines on content, titling styles and fonts, scene-changing, people in videos, music/sound/narration, credits, length and format restrictions, etc. etc. I really don't mean to criticize the video posted above (now at Wikivoyage:Travellers' pub#Short videos), since it's fine for what it is, but even that one is not acceptable to me, not least because it is actually not even a video but a somewhat glorified slideshow of still shots with some zoom and pan added to them, containing zero actual video footage (and I don't think we are necessarily after new ways to squeeze in more still shots). Still, I cannot help imagine that most submissions will be much worse, either with cheesy music or cheesy fonts or cheesy scene change effects or something else cheesy. Let's face it, lots of people can take good pictures but the overwhelming majority of the editing public at large generally does not know how to make high quality, professionally edited videos, despite what they may think. I don't think arguing about this is going to be a very good use of our time at this point. There is way too much cheese on that pizza. Texugo (talk) 22:08, 1 August 2013 (UTC)
I'm not clear on what kind of video content is envisioned. If it's truly "additional content", then it's either not necessary for the traveler, or it should be in our guides in text and pictures. If it just duplicates our text content, then I don't see the point. LtPowers (talk) 22:32, 1 August 2013 (UTC)
Personally, I would be cautiously in favour of allowing video content on here. The way the internet is used has changed rather a lot since the dawn of WV/WT and, with the advent of smartphones, people increasingly 'take the web with them'; even full of rich content, whilst apps offer the opportunity to download and keep our content on a local device. As a subject, travel is particular well-suited to video content and I'm sure we could do a lot of very imaginative and exciting things with it: video content can take the user to a destination like no other medium. That is not to say that we should do away with our current policy of making guides printable. When users are in an area without internet coverage, nothing beats a paper copy, whilst we should maintain a usable page on those travellers who just use dead tree guides out of preference. If what Smallbones suggests in the original discussion is correct, that shouldn't be a problem - the videos can be replaced by stills.
Despite this, to my mind, video content would (at least initially) need to be tightly controlled. I think we would need both a time limit and particular guidelines about content - we don't want a 30 minute personal documentary (although that might be good for our (as yet) non-existent YouTube account) and we'd have to discuss our thoughts on commentaries. In truth, I think it might be good, at first, to approve all videos centrally. A very slow process - yes - but at least initially that's what we want. I'd advocate the creation of a Video Expedition to oversee this process to stem the flow of keen but misguided efforts that we're likely to get. This would be a very work-intensive method, but probably what we'd need here.
A YouTube channel was also mentioned in the original Pub conversation, which I think was an excellent idea, though that too would need further discussion about content guidelines and the like, although overall control would probably be easier on an external site ,though licences might be tricky. Perhaps this is the easier short-term solution?
Overall: a good idea, but one that will take a lot of time and effort - I do have some sympathy with Texugo's view above! --Nick talk 22:33, 1 August 2013 (UTC)
While not part of my central argument, I do take issue with the notion that people have started taking smartphones everywhere. While that may be true for travel close to home, people travelling further afield still do not generally have use of their smart phones. Your iPhone is probably not going to just work when you're riding a rickety bus across Morocco or you pause between Khmer temple ruins, and if you are outside your carrier's range and you do have a signal, especially in a foreign country, you could easily run up a couple of thousand dollars` worth of roaming charges. I don't think we can safely assume people will generally have smartphone access. Texugo (talk) 22:46, 1 August 2013 (UTC)
LtPowers, nothing on this site is actually "necessary for the traveler," as shown by the fact that people have traveled for thousands of years before this site existed. So, at the risk of being overly literal and perhaps misunderstanding what you really mean, I don't think 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.

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[edit]

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)

Locally uploading photographs of copyrighted buildings[edit]

Swept in from the pub

I would like to upload my own photographs of copyrighted buildings (in Qatar) as a means of working around 'freedom of panorama' restrictions. I couldn't find any pages explaining how to upload directly to Wikivoyage, and so I uploaded them to Wikimedia Commons, which apparently is not the correct way to go about this.

Is there someone here who can explain how to upload directly to Wikivoyage, or possibly even how to move the existing images from Wikimedia Commons to Wikivoyage?

Many thanks, StellarD (talk) 11:06, 20 September 2013 (UTC)

StellarD, you can upload the file here: Special:Upload and this might be the category to put them to: Category:Photos of copyrighted works. Danapit (talk) 11:32, 20 September 2013 (UTC)
Thank you Danapit, this is exactly what I was looking for. StellarD (talk) 11:46, 20 September 2013 (UTC)
No, no, please don't add Category:Photos of copyrighted works directly! All photos of non-free works uploaded locally should include Template:Non-free image, and that takes care of the categorization! If there are any files so categorized without transcluding the template, that needs to be fixed! LtPowers (talk) 00:05, 21 September 2013 (UTC)
I hope I haven't created a mess here. I uploaded the files before LtPowers commented, but didn't add them to Category:Photos of copyrighted works because I didn't see where to do that, which it seems is just as well. They now appear in Category:GFDL_files – is this where they should be? And if not, how do I move them? Thanks, StellarD (talk) 07:37, 21 September 2013 (UTC)
You add a category with the following syntax: [[Category:Some category name]]. But, as noted, please don't do that in this case. The category addition should be handled by the addition of Template:Non-free image. The syntax for that is more complex, but you can see an example of it on the Template page under "Template use". LtPowers (talk) 16:05, 21 September 2013 (UTC)
Would it be possible to update documentation (probably on the upload page) so that it is clear how and when to add categories and when not? --Danapit (talk) 06:51, 24 September 2013 (UTC)
We never add categories manually. On files or on article pages. Until recently we didn't even use categories at all. Categories should be completely invisible to the average casual user, so we don't even mention them on the upload form; it would only confuse people. The Upload form does link to the non-free content policy, which clearly specifies that Template:Non-free image be added to the image description page. LtPowers (talk) 14:14, 24 September 2013 (UTC)
I see. Recently I have uploaded some candidates for featured articles banners and I added the category Category:DotM banners manually. Was that wrong, as well? How else does such photo get to a desired category? Danapit (talk) 15:40, 24 September 2013 (UTC)
Welcome to the wonderful world of wikis. I was unaware of that category, and obviously whoever first used it was unaware that we should only assign categories via templates. The solution here is to create a template that would go on the file description page of such files, rather than manually categorizing each of them. Either that, or delete the category, as I don't quite see its utility, especially since DotM banners should be deleted once they're no longer in use. LtPowers (talk) 17:43, 24 September 2013 (UTC)
Well, scratch that last part, as I forgot we keep the banners in the DotM archives. =) I'm still not sure we need the category, though. LtPowers (talk) 17:44, 24 September 2013 (UTC)

Upright image sizes[edit]

To my knowledge, upright image sizes are currently not allowed on this site, at least until the default size of thumbnails is potentially enlarged, but possibly not even after that. Can we please have a definitive clarification on this, because User:118.93.244.91 and other IPs, etc., of the same user have repeatedly introduced such image sizes in edits like this one. I believe 118 is intentionally acting against policy, but he claims there has never been an actual prohibition against upright image sizes.

For the record, I think that upright image sizes are a good idea in most instances, but that it's more important to respect the consensus decision-making process than to change pixel dimensions to upright dimensions. Ikan Kekek (talk) 22:02, 8 January 2014 (UTC)

To the best of my knowledge consensus has always been that we would switch to relative image sizing (upright parameters) only after changing the default thumbnail size, and that "upright" should not be used presently as we would then have to update all upright parameters after the default size is changed since "upright" means size relative to the default thumbnail size. -- Ryan • (talk) • 22:17, 8 January 2014 (UTC)
Ryan: That notion of a required change to the upright parameter if we ever succeed in changing our default to either 250px or 300px is just plain wrong.
If it is appropriate, by way of example, for a lead image to be larger than subsequent images, that relationship will hold good if "upright=1.3" is set for the lead image, whether subsequent images without sizing are displayed at a default of 220px (as currently), or changed to 250px or 300px). --118.93.244.91 22:59, 8 January 2014 (UTC)
If the default is 220px, then currently upright=1.3 will be used to display an image in the size that we want (~300px). As soon as the default is changed upright=1.3 means that same image is 390px, so we then have to go back and update all images using "upright" to remove the relative size parameter. Hence the consensus to get the default updated first, and the animosity towards the ongoing efforts to randomly sprinkle "upright" tags throughout the site. -- Ryan • (talk) • 23:44, 8 January 2014 (UTC)
Gentlemen, I'm afraid that the notion that respecting registered editors thumbnail default width sizes has ever been prohibited on this site (or on its predecessor, Wikitravel) is completely untrue.
If you examine the history of what should never have become a contentious issue, many of our most experienced editors were unaware of the concept of relative image sizing until last year - even though the software had update the image syntax possibilities many years ago.
Unfortunately the "upright" syntax was then linked (unnecessarily and unhelpfully in my view) with a proposal to both vary the range of default thumbnail sizes that registered users could prefer and increase the default thumbnail size that was displayed both to un-registered users (or users that had not logged in) and to registered users that had not changed their width preferences (ie the majority of readers).
Now that it is quite clear that neither the range nor default size will be changed in the near future, it is becoming increasingly urgent that we do not continue to make monkeys out of our registered readers by flouting the wishes of some users to have larger thumbnail image sizes displayed and the wishes of some users to have smaller thumbnail image sizes displayed.
I defy either of you to provide any diffs that show that the question was ever raised - never mind a consensus obtained to ban an integral software feature - before the very recent campaign to enforce bizarre and inconsistent fixed image widths regardless of users explicitly expressed preferences. --118.93.244.91 22:53, 8 January 2014 (UTC)

Image alignment[edit]

Since there seems to be some disagreement regarding the placement of images in articles and the appropriate alignments for those images, I would like to propose we codify some guidelines.

I think we're all agreed that right-alignment is preferred. The question before us, then, is whether to allow alternative alignments and if so, how strong of a justification is needed in case an alternative alignment is desired.

As a start, here's some proposed wording:

By default, images on Wikivoyage articles should be right-aligned. Sometimes, though, it may be better to left-align or center an image. For example, images that are much wider than they are tall (e.g., panorama photos, or the occasional map) should usually be centered. Left-alignment may be used to break up a long string of right-aligned images, to ensure that images appear close to the text that describes them, or to avoid visual conflict with infoboxes.
Don't left-align an image just to be able to squeeze more images into an article. Also avoid left-aligning an image if doing so would push a section heading or items in a bulleted list to the right; this can be confusing for the reader. Also do not place a left-aligned image directly underneath a section header, as it causes the first paragraph to be pushed to the right.
But most importantly, don't overuse alternative alignments. If in doubt, leave it right-aligned; that helps ensure the article doesn't have too many images, and prevents many formatting issues.

-- Powers (talk) 20:24, 16 February 2014 (UTC)

I recall in previous discussions that people have brought up some kind of problem that results when right-aligned images are printed. Would someone please address this? Ikan Kekek (talk) 20:59, 16 February 2014 (UTC)
I like this.
We should consider broadening it as well. In my view, at least 90% of images should have "thumb" as the only tag. both default right alignment and default thumbnail size. The "don't overuse" advice should apply to all exceptions to that. Pashley (talk) 21:04, 16 February 2014 (UTC)
Left image.PNG
All the avoids and don'ts above are absolutely right on, so I don't see any reason to reiterate the arguments behind all those, and though I've never been a fan of using extra panoramas in addition to the banner, I'm not of a mind to fight them at the moment, and I agree that they usually look better centered even though they break the flow. However, as for allowing left alignment for the specific purposes mentioned, some of us would still argue (and have several times) that left alignment can just about always be problematic for several additional reasons. I am not arguing that there should never ever be any exception ever, but left-aligning out of aesthetic preference can so easily backfire: the biggest problem that occurs to me is that due to varying screen and font sizes, the person left-aligning (to break up a string of right-aligned images or to get away from a text box) unintentionally creates awful-looking layouts for some other users, where the images squeeze the text into a meandering river, pinches it at points (like the illustration at right), chops it up, moves all of a paragraph to the right except for the last couple of words which wrap back under the picture on the left, or any number of other unfortunate effects which are unpredictable and typically unapparent to the person doing the alignment. To avoid this, I suggest that we that we essentially continue with the practice that has brought us to where we are, namely that we always right align, and any exceptions would require the talk page to be used to explain what other extenuating circumstance there may be, some special reason for not doing it the normal way, other that "i like it better this way".
As has been pointed out in previous discussions, left-alignment has always been controversial, and I contend that, despite the fact that it (very unfortunately) never got written on a policy page, our status quo is nevertheless represented by our very long-standing practice of only right-aligning, as evidenced by the fact that we have made left-aligning not only rare, but overwhelmingly so — Currently, a mere fraction of a percent of existing articles have any left-alignment, including only a small handful that would even pass LtPowers' wording above (mostly put in place by LtPowers or AndreCarrotflower) plus a few dozen more which clearly don't even meet the wording above. Most existing instances have popped up since the move to WMF, and would have been corrected by now had LtPowers and AndreCarrotflower not started taking issue with people correcting them. As the status quo, right-alignment-only is the default we should fall back on if we can't get a new consensus out of this new thread here, in accordance with our normal status-quo bias. As the proposed policy would be opening a door and endorsing left-alignment for a wide range of our better developed articles, it represents a sitewide change, which means it does in fact require a consensus here to go through. Failing that, we must fall back on the way it's always been done: the same policy that brought us to very nearly 100% right-alignment.
If you are new to discussions on this subject, please thoroughly read these relatively recent discussions before joining in with your views: here, here, here and above. Texugo (talk) 01:04, 17 February 2014 (UTC)
For every case where extremely skinny window widths causes problems with left-aligned images, I can find one where it causes problems with right-aligned images too. I don't think that's a valid reason to avoid them. Powers (talk) 02:33, 17 February 2014 (UTC)
Except that we aren't comparing right-alignment with left in isolation - left alignment would never occur in isolation even according to your proposal. What we are comparing is right with alternating-right-and-left, and there is no question that the latter presents many types of problem which the former does not. Moreover, even if we were talking about left in isolation, there are a whole class of problems which arise specifically from aligning images on the same side we align text on, which are thus unique to left alignment. Texugo (talk) 11:27, 17 February 2014 (UTC)
I think the proposed text is a step in the right direction. Yes, right-alignment is the preference and we use it by default. Everyone agrees. However, consensus as far as I can see it is indeed a right side preference, and a strong preference at that, but not the use of right-alignment exclusively. In fact, policy says little about this and offers several alignment possibilities. I would strongly oppose any move towards a policy that will prohibit left alignment (in my eyes thát would be a change in policy). I understand the concerns, and it's good to discuss the specific problems, but it would be silly to deny ourselves the option in the few cases where it does help layout. I also think we shouldn't want to make rules stricter than they need be and allow editors a little bit of leeway where we can (also to keep Wikivoyage fun). It works well enough on other large wikis (including Wikipedia) and hasn't at all led to layout mess here. Of course individual images can always be discussed in order to find the best solution. Looking at written policy and the number of valued editors who consider the status quo to allow left-side alignment in a few selected cases, it seems obvious that we don't want to move towards right-alignment only. When a small group of editors feels so strongly, opposing left-alignment, and "corrects" it, of course the practice becomes an almost 100% right-alignment. That doesn't make it policy though, and it's not a strong base to argue "right-only" alignment as a common practice, in my eyes. If we're going to end this discussion, what we need is indeed a policy text we can all live with, allowing for the exceptions we are after, but also addressing the concerns Texugo has. I can feel your frustration, Texugo, but are there any changes to the proposed wording that would bring us closer to an acceptable middle ground with some allowed use of non-right images? JuliasTravels (talk) 12:14, 17 February 2014 (UTC)
As I said, I'm not necessarily after "no exceptions ever", but I am strongly in favor of "no exceptions without justification/consensus". And if you think closing off the remaining 00.05% or so of articles with left alignments would represent a "change in policy", then it should be very very easy to see how expressly endorsing it for the first time and allowing that percentage to grow from 00.05% or so to upwards of 20 or 30% of our articles would represent a change in policy orders of magnitude greater. Failing a new consensus to start explicitly endorsing it, preserving the status quo has to mean keeping it as least as exceedingly rare as it has always been, and the only way I know to do that is to say "we don't use left-alignment unless exception is discussed". I am happy with that status quo.
Though it would not be nearly enough to make it acceptable to me, changes to the proposed wording that would bring us closer would definitely have to include some other don'ts in addition to the ones already given:
  • never squeeze the text on both sides, which means:
  • never put pictures in parallel
  • never put a picture across from a text box
  • never let a picture on one side start before the picture or text box on the other has finished
(if you feel like you have to do so, you are actually using left-alignment "just to be able to squeeze more images into an article", which is already included in the don'ts above)
  • never have the first picture in a section be on the left unless the first thing is a text box on the right
  • never set picture sizes in a section with mixed alignment, always use the default thumb size
  • never put multiple left-aligned images in a row
  • if there is not enough material to correctly use at least 2-3 left aligned images, don't use any - an article with 12 images on the right and one lonely one on the left looks odd and could likely be reworked easily to follow our preference of images on the right
  • don't whine or revert if someone comes along and makes it work without left-alignment — that is our stated preference, after all
Texugo (talk) 13:36, 17 February 2014 (UTC)
Way too many "nevers" in there. Why do you take such a hardline stance? In particular, left-aligning to avoid a textbox is sometimes necessary, and right-aligning an image that starts near a textbox also has problems; why are the left-aligned problems more important to avoid in your view than the right-aligned problems? Powers (talk) 13:46, 17 February 2014 (UTC)
Again you are trying to compare right with left instead of right with right+left. I'm not trying to avoid problems of left more than problems of right. I am trying to avoid problems of left and right together squeezing the text unpredictably or creating other layout problems. And remember, "don'ts", "nevers" and "avoids" can always be superseded by a bit of discussion on the relevant talk page to make an exception if there is some convincing reason to do otherwise. Texugo (talk) 13:54, 17 February 2014 (UTC)
Anyway, the number of "nevers" needed to prevent common problems is the main reason I oppose endorsing any left-alignment at all. Texugo (talk) 14:02, 17 February 2014 (UTC)
Well, we agree on the "nevers" at least then :-) Any policy consisting of a long list of "nevers" is highly uninviting, especially for new editors, and brings almost any discussion to the trenches from the start. I fail to see why we need them though, if we can set a good bunch of ground rules. We don't even need "never" as an outcome, we want "rarely". That should be possible. For my understanding, are there more regular users that share this hard line opposition to any left-side alignment, that we know of? JuliasTravels (talk) 14:11, 17 February 2014 (UTC)
Frame them as "nevers", frame them as "don't", frame them as "avoids", whatever. They are ever bit as important and no less flexible than the "don't" and "avoids" already given in the proposed wording. Stop focusing on me "being hard-line" and address the specific problems I am trying to avoid. Texugo (talk) 14:17, 17 February 2014 (UTC)
Also, Julia, you appear not to have read up on previous discussions, as I recommended. I am not the only one. Texugo (talk) 14:31, 17 February 2014 (UTC)
Oh but I did, and I usually do too, when I join a discussion :-) I saw a bunch of people who understand and share some or all of the concerns, and you might add me to that list, but most seem to want to work towards a middle way, without long lists of don't or avoids or however you put them. I might be wrong though. Rather than wanting to put you in any corner, however, my thought was that we should get their eyes on this discussion too. JuliasTravels (talk) 14:41, 17 February 2014 (UTC)
Considering that my preferred way is none and LtPowers et al's preferred way would be endorsing them to a large degree, I think the middle way might actually be endorsing left-alignment (my side's concession) but having substantial guidance including all the above "things to avoid" (the other side's concession). I would consider that to already be a considerable compromise on the part of both sides, one that I might grudgingly be convinced to accept, whereas the original proposed wording would just represent a total defeat for those sharing my perspective. Perhaps the guidance could be condensed in a way that still encompasses all our concerns in fewer words though. I'll see if I can combine my ideas with LtPowers' proposed wording in a more succinct way, and then we'll see if it is something both sides would be willing to compromise for. Texugo (talk) 15:00, 17 February 2014 (UTC)
Your proposed way is far too restrictive. Leaving the status quo of "prefer" right alignment leaves the last word with the author of the page, where it belongs, where "avoid" and "don't" is just being needlessly inflexible. You're trying to fix something that isn't broken when you approach a topic and offer this as your only contribution to a page which needs expansion in other, more constructive ways. K7L (talk) 15:53, 17 February 2014 (UTC)
I support Texugo's proposal and would even support an unconditional ban on left-aligning pictures, they just look outright wrong IMHO (I mean, look at Kaunas#See!) even if there isn't a text box squeezing the text from the right like in the screenshot above. If someone would necessarily need to put a picture exactly where there's already a text box and for some reason the textbox can't be moved, the case can always be discussed on the particular article's talk page. There's often plenty of space for "surplus" pictures of sights towards the end of the article, where there's a list of restaurants, bars and hotels (no pictures of individual businesses) and Stay safe etc. that often could need a little more color. ϒpsilon (talk) 16:11, 17 February 2014 (UTC)
"Avoids" and "don'ts" are a standard part of any manual of style, and there is no more reason to leave this style choice up to a given contributor's discretion than there is to abandon rules for anything else we have standardized. If you look through the small list of currently existing left-alignments, most of what you'll see constitutes a whole menagerie of different bad formatting choices, and it is easily possible for us to generalize about what's wrong with them and state that as guidance in our style guide - LtPowers' wording captures a few of those generalizations, and my observations capture a few others. That's it. That does not make it "needlessly inflexible".
It is a big and unprecedented step for me to admit that I might endorse any left-alignment at all, so I would humbly ask you to seriously consider whether you could give a few steps too, so we could meet in the middle somewhere around this wording:
By default, we prefer that images in Wikivoyage articles be right-aligned. Occasionally, though, it may be better to left-align or center an image. For example, images that are much wider than they are tall (e.g., panorama photos, or the occasional map) should usually be centered. Left-alignment may be used to break up a long string of right-aligned images, to ensure that images appear close to the text that describes them, or to avoid visual conflict with infoboxes. Layouts are finicky, and what looks good on your screen can sometimes look bad for someone else, so if you opt for non-standard alignments, here are a few guidelines to consider:
  • Use the default thumb size and avoid having objects overlap the same vertical space as those on the other side; this helps prevent the text from being squeezed from both sides.
  • Don't use left-alignment just to squeeze more images into an article. A likely indicator that you're doing so is that vertical overlap seems necessary.
  • In a given section, put the first object (whether image or text box) to the right, especially if directly underneath the section header, and alternate right-left-right-left.
  • Avoid left-aligning an image if doing so would push any section heading or items in a bulleted list to the right; this can be confusing for the reader.
  • If there isn’t enough material to warrant more than one left-alignment in an article, it probably isn’t worth it.
  • Most importantly, don't overuse alternative alignments. If in doubt, leave it right-aligned; that helps ensure the article doesn't have too many images, and prevents many formatting issues.
While I would still favor, as Ypsilon put it, an "unconditional ban on left-aligned images". I might be persuaded to support something like the above as a compromise, if left-alignment supporters could be persuaded to get behind it. There are not any further items in this new proposed wording that I'd at all be willing to part with, though the wording itself could of course be tweaked. Texugo (talk) 16:28, 17 February 2014 (UTC)
I know you don't like the thank button so I won't use it ;-) I think I could roughly live with this, even with the text, so kudos for trying to find the words. As for the Kaunas example Ypsilon mentions, we probably all agree that's not the most successful use of left-alignment. It's clearly trying to put too many images in one section. JuliasTravels (talk) 16:42, 17 February 2014 (UTC)
Why do people think I don't like the thank-you button? It was the little pink heart icon for sending kittens that I didn't like. Texugo (talk) 17:13, 17 February 2014 (UTC)
Haha, okay, that's a typical example of misunderstandings leading their own life. I never even heard of any kittens here hehe.. Anyway, I'll keep it in mind, sorry :-) JuliasTravels (talk) 17:21, 17 February 2014 (UTC)
I've seen a "lovely" kitten here exactly once :P. ϒpsilon (talk) 18:14, 17 February 2014 (UTC)
Oh my God. A left-aligned kitten. I just puked in my mouth a little, haha... Texugo (talk) 18:16, 17 February 2014 (UTC)
What's there now as policy already is a compromise, presumably between no layout restrictions at one extreme and forcing everything to the right of the tea party on the other. No need to change that. K7L (talk) 20:57, 17 February 2014 (UTC)
K7L has a good point; my proposal was a compromise proposal, attempting to balance Texugo's concerns with the ability of editors to make our articles look better. That said, Texugo's proposed wording is mostly very good. I'm curious about the reasons for requesting strict left-right-left-right alternation, and for requiring the default thumbnail size (which we all know is way too small, especially for maps). Powers (talk) 21:26, 17 February 2014 (UTC)
Incredibly, it seems like we might finally be getting somewhere after more than two years of bickering about this. To answer your questions, I phrased it as right-left-right-left alternation, but the underlying point was that there not be two or more left-aligned images in a row — if there are two or more in a row, it would basically mean you're doing it out of personal preference anyway, rather than with the legitimate purpose of breaking up a long string of righthand images. As for requiring the default size, I didn't mean it so much as a requirement, but I agree with what Pashley said far above, that the vast majority of images in general should be the default size, and I think it should apply even moreso in cases of mixed alignment for two reasons: 1) if you boost the sizes of images on both sides, you inevitably increase the likelihood of bad layout/pinched text on some screens, and 2) if there are different-sized images on both sides, with the text wrapping willy-nilly, the resulting overall layout looks pretty random. I might not mind so terribly if it were softened slightly to "Try to stick to the default thumb size", but I do think it's an important point. Texugo (talk) 22:26, 17 February 2014 (UTC)
I'd like to let go of that first idea. I get what you're trying to say, but I'm afraid it may hurt the layout you're trying to protect rather than help, in some cases. Breaking up a long list of images is mostly a visual effect. Once that's necessary, we should go with the best available arrangement, taking into account the blocks of text. That might be left-right alternation, it might also be a few on the left and then back to the right (e.g. doing one long section left aligned and then going back to the default). The right choice would depend on so many things that I don't think we should try to catch it in a rule. If you have a particular "bad example" in mind, we could look for a way to include that, trying to explain what we are and are not after. We could also do that on an individual case base though, for the time being, and see if it really poses a problem or not. I agree with the thumb size, although I think it's covered in other policies. It shouldn't be a hard requirement but I'm fine with reminding people of our preference in that. JuliasTravels (talk) 09:09, 18 February 2014 (UTC)

Well, as I stated, there are not really any further points I am willing to just give up, though we might find another compromise on that point. Perhaps I should have explained a little further to say that the exhortation to alternate alignments also serves to help keep left-alignments to a minimum, precluding unnecessary formatting possibilities like R-L-L-L-L-L-L and helping to keep the threshold low for when an article can sustain left-alignment. The reason I feel strongly that they should still be kept to a minimum even within any article where left-alignment has been opted for is that there are still other types of formatting problems unique to left-alignment alone that I was unable to address with any of the other guidance. A common one, for example, is the situation where you've arranged so that you see an image on the left and a paragraph sitting neatly beside it, while someone whose screen, font, or browser size is the tiniest notch different sees an image to the left with a paragraph beside but with just the last word or two cut off and brought all the way back to the left margin under the picture — I think everyone can agree that this is an instance of poor layout. I could not think of any concrete guidelines to specifically help us avoid common problems like this, but the least we can do is to minimize opportunities for them to occur. As for a compromise, hmmmm. I think I'd accept dropping that altogether and strengthening the wording of the last item somewhat and combining it with the penultimate item, perhaps like this:


By default, we prefer that images in Wikivoyage articles be right-aligned. Occasionally, though, it may be better to left-align or center an image. For example, images that are much wider than they are tall (e.g., panorama photos, or the occasional map) should usually be centered. Left-alignment may be used to break up a long string of right-aligned images, to ensure that images appear close to the text that describes them, or to avoid visual conflict with infoboxes. Layouts are finicky, and what looks good on your screen can sometimes look bad for someone else, so if you do opt for non-standard alignments, here are a few guidelines to be considered, in order to help ensure the article doesn't have too many images, and to prevent many formatting issues:
  • Try to stick to the default thumb size and avoid having objects overlap the same vertical space as those on the other side; this helps prevent the text from being squeezed from both sides.
  • Don't use left-alignment just to squeeze more images into an article. A likely indicator that you're doing so is that vertical overlap seems necessary.
  • In a given section, put the first object (whether image or text box) to the right, especially if directly underneath the section header.
  • Avoid left-aligning an image if doing so would push any section heading or items in a bulleted list to the right; this can be confusing for the reader.
  • Any given layout should endeavor to use as few left alignments as possible, and if no more than one makes sense, prefer none. When in doubt, leave it right-aligned.

Added bonus: 5 bullets instead of 6. Would that be more acceptable to you? Texugo (talk) 11:44, 18 February 2014 (UTC)

That last bullet was the only place we explained why we prefer right-alignment; I'd like to keep that in some form. Powers (talk) 13:26, 18 February 2014 (UTC)
Perhaps you didn't notice that I moved your phrase "to help ensure the article doesn't have too many images, and to prevent many formatting issues" from the last bullet point to the end of the first paragraph, since it applies more generally. Is that ok? Texugo (talk) 13:52, 18 February 2014 (UTC)
Indeed, I hadn't noticed. Apologies. I'm fine with this. Powers (talk) 02:32, 19 February 2014 (UTC)
Another possibility would be to refashion it as a stand-alone sentence after the bullet points, to sort of cap off the section. Texugo (talk) 14:37, 18 February 2014 (UTC)

By default, we prefer that images in Wikivoyage articles be right-aligned. Occasionally, though, it may be better to left-align or center an image. For example, images that are much wider than they are tall (e.g., panorama photos, or the occasional map) should usually be centered. Left-alignment may be used to break up a long string of right-aligned images, to ensure that images appear close to the text that describes them, or to avoid visual conflict with infoboxes. Layouts are finicky, and what looks good on your screen can often look bad on someone else's, so if you do opt for non-standard alignments, here are a few guidelines to consider:
  • Try to stick to the default thumb size and avoid having objects overlap the same vertical space as those on the other side; this helps prevent the text from being squeezed from both sides.
  • Don't use left-alignment just to squeeze more images into an article. A likely indicator that you're doing so is that vertical overlap seems necessary.
  • In a given section, put the first object (whether image or text box) to the right, especially if directly underneath the section header.
  • Avoid left-aligning an image if doing so would push any section heading or items in a bulleted list to the right; this can be confusing for the reader.
  • Any given layout should endeavor to use as few left alignments as possible, and if no more than one makes sense, prefer none. When in doubt, leave it right-aligned.
Following these guidelines will help to ensure the article doesn't have too many images, and prevent many unforeseeable formatting issues.

Like this? Texugo (talk) 18:57, 18 February 2014 (UTC)
Powers just directed me to this discussion; sorry for being a latecomer.
Let me start by saying that despite the fact that my name has come up as a habitual left-aligner, I don't really have strong feelings on the subject. After I came to Wikivoyage and started editing Buffalo but before I began districting it, there were issues with the density of photographs on the Buffalo article. The proposed wording of the new policy says "don't use left-alignment just to squeeze more images into an article", but the issue with Buffalo at that time was a bit different - certain sections of the article (specifically, #Architecture) were crammed with photographs that I had previously taken for a separate, unfinished writing project and repurposed for Wikivoyage, but other sections were longer in terms of text while containing few or no images. Not having any idea at that time that we preferred one alignment over another, the solution that I came up with was to left-align some of the images in the sections that were densely packed with them. However, after the district articles went up, there was less of a need for this measure as the photographs were then spread over eight different articles. You'll notice now that there are no left-aligned images in any article that I've written, with the possible exception of the three unfinished district article templates in my userspace that will, rest assured, be corrected before being transferred to mainspace.
As to the proposed policy, I would support it as long as we allow for left-aligned images in exceptional cases (i.e. if we reject the unconditional ban Ypsilon proposes), subject to consensus on each individual article's Talk page. I would also be in favor of a complete ban on centered images, which strike me as never necessary.
On a perhaps only tangentially related topic, in my opinion we should seriously consider abandoning or softening the "minimal use of images" clause of the current policy. Given that we reformatted the Main Page about a year ago with huge, high-resolution banner images that take up the vast majority of the page as well as other graphical elements to emphasize visual pizzazz, and also given the fact that high-speed internet is much more prevalent worldwide than it was when policy was written, to doggedly continue to enforce a text-heavy, aesthetically boring format for the articles (for ease of page loading on slow connections, I assume) seems to be an unnecessary hindrance and more than a bit hypocritical.
-- AndreCarrotflower (talk) 23:45, 18 February 2014 (UTC)

[Unindent]On the tangent: We can continue that discussion in a separate thread, with reference to Wikivoyage talk:Image policy#Guidelines for "minimal use" of photos and Wikivoyage talk:Image policy#How many images is too many? further up this page. My understanding is that "minimal use" does not really mean "minimal," just not an insane number, but I agree that it would be good to rephrase the policy to reflect actual (and visually good) practice. I'll see you at the new thread, if you'd like to start one.

I should also say that I have watched this discussion with interest and I'm happy to see agreement forming, but I've never had strong views one way or the other about which side images should be on. As long as it looks good, it's all the same to me, but I do understand the arguments that have been made about that. Ikan Kekek (talk) 05:37, 20 February 2014 (UTC)

Hopefully we can avoid confounding the minimal-use policy with this separate policy proposal. Might I ask your opinion on the last proposed wording just above? Texugo (talk) 00:07, 19 February 2014 (UTC)
As I said, so long as we reject any unconditional ban on left-aligned images, I'm all for it. -- AndreCarrotflower (talk) 00:11, 19 February 2014 (UTC)
I also like the proposed text, as long we have some kind of understanding amongst us where we want it to lead. I don't think I've ever used left-aligned images, and I won't mind "correcting" most of the instances where it'll be used; by users unaware of the issues behind this policy and in cases clearly covered by this new policy. I'm fine with making sure we don't get to any "30%" rate of left-alignment, that you seemed to fear, Texugo :-) However, in the light of "keeping it fun" I also hope that we can avoid any "left-alignment-policing" when good editors and long articles are concerned, and where it might boil down to a judgement call. That's the one problem I see; layout is essentially a matter of preferences, and whether or not a long list of pictures needs some breaking up is a call. It's perfectly fine to bring up issues, but I do ask that in those few cases where people put lots of work in an article and then feel they need a left-alignment, and it's not clearly against any conditions we've agreed upon here, we'll let it go and allow them. I really hope that would get us in any serious percentages (as it would mean many long articles ;-)) but I'm pretty sure it will not, and if it ever threatens to, we'll fix it. Is that workable? JuliasTravels (talk) 09:21, 19 February 2014 (UTC)
I actually think it's workable, or at least won't cause any more fights over aesthetics than our minimal image policy or the question of which banner/images to use, which is to say a manageable very few. I'm not actually that concerned about the instances where LtPowers or AndreCarrotflower or another competent user have used them, for example, as long as they conform to the proposed wording. I just want to have this concrete criteria to back me up in order to correct the more egregious and problematic instances that crop up, which seem to be the majority of cases, and have something to point to when new users come in and start trying to do it inappropriately. LtPowers, can you support this last wording too? Texugo (talk) 11:16, 19 February 2014 (UTC)
Largely, although I do have a concern about the vertical-space requirement. Requiring no vertical overlap seems to conflict with one of the stated goals of left-alignment, to avoid infobox conflicts. But to resolve this, we may need some case studies. Powers (talk) 14:27, 19 February 2014 (UTC)
Would adding a "when possible" to the end of that phrase alleviate your concerns for the time being? Texugo (talk) 14:29, 19 February 2014 (UTC)
On second thought, I would prefer to just change the word "objects". How about this:
  • Try to stick to the default thumb size and avoid having images overlap the same vertical space as images on the other side; this helps prevent the text from being squeezed from both sides.
That way it doesn't include other kinds of boxes in its prohibition (though I still believe it should be avoided when possible). What do you say? Texugo (talk) 15:12, 19 February 2014 (UTC)
Well, I think the concern is still valid for images. That's one of the main reasons I'd want to move an image to the left; if I have two images that apply to nearby blocks of text. To avoid the "squeezing" issue, perhaps we could suggest that the left-aligned image come first? Powers (talk) 18:12, 19 February 2014 (UTC)
I don't see what putting the left aligned image first would do, except to be more likely to interfere with headers or have people left-aligning an image after only one line of text. And it is still best to steer away from vertical overlap when at all possible, or else you can get weird one- or two- line spikes of text sticking between images that are close but not quite touching, which is also makes for a pretty poor layout. Would you be more amenable to my first suggestion of "when possible"? Texugo (talk) 18:33, 19 February 2014 (UTC)
Hmm, not sure what I was thinking. Maybe my confusion is because the issue of two images occupying the same horizontal line is dependent on resolution. If the images are adjacent (in the wikicode) to two different paragraphs, then they will separate vertically as the window width shrinks, which is when the potential layout issues arise. Actually a good rule of thumb for all "floating" page elements (TOC, infoboxes, right- and left-aligned images) is to make sure there isn't more than one consecutively without intervening text. Powers (talk) 01:20, 20 February 2014 (UTC)
Hmmm....I'm not really seeing how that helps us move forward on this. Is one of my suggested compromises workable? Yes, it is somewhat dependent on resolution, as are many of the potential layout problems involved here, but the lower the chance of squeezing both sides at once, the better our chance of avoiding poor layouts like the above screenshot, so it's better to try and avoid it than to just be silent on the matter. You didn't exactly answer: would you be more amenable to my first suggestion of avoiding vertical overlap "when possible"? Texugo (talk) 11:21, 20 February 2014 (UTC)
Frankly, I don't think this particular wording matters much. It's all about bad layout concerns, and I think when that's the case the image placements (whatever they are) should be changed, even when a particular arrangement is theoretically allowed under policy. For me, when possible is okay, if it's not used as a stick in the handful of cases where vertical overlap does no harm. I think we're really talking about a few individual cases anyway, it's easy enough to discuss those on their talkpages if need be. JuliasTravels (talk) 13:33, 20 February 2014 (UTC)
I was saying, Texugo, that if we provide advice to not put more than two images consecutively, regardless of alignment, then following that advice is likely to prevent more bad layout issues than advising against overlap, which is resolution-dependent. (In other words, there's no way to objectively say "these two images overlap vertically".) Powers (talk) 14:50, 20 February 2014 (UTC)
Consecutively placed images are a completely different issue and do not present the same potential layout problem of having a mere line or two of text show up between them. Moreover, a huge percentage of our pages already have consecutively placed right-aligned images, and they do not create any serious layout problem in particular since they do not interact with the left-alignment of the text. If a person left-aligning, whatever their screensize, follows the advice to avoid vertical overlap as they see it on their screen, there is still a lower chance of problems than there would be without that advice. And if someone else comes along with a different screen and sees it as overlapping, the advice is there to suggest fixing it further and thus further reducing the chance of a bad layout for others. It's not an ideal situation, but it's still far better than not advising against it at all and then having no policy basis to help us avoid arguments when we try to fix the screenshot above. Texugo (talk) 15:15, 20 February 2014 (UTC)

[unindent]I think that by any standard, the Subotica article is one of the worst offenders in terms of left- and center-justification and image placement, generally. I'll delete an old photo, and I don't have the time or inclination to thoroughly fix the article now, but I think it belongs here as an example of what we don't want. Ikan Kekek (talk) 23:12, 19 November 2014 (UTC)

Actually, I "fixed" it, but you can see the changes here. Those "multiple image" templates were a disaster in terms of WV policy. Can they be disabled on this site? Ikan Kekek (talk) 23:25, 19 November 2014 (UTC)
It's now called Template:Multiplemaps, as it was agreed that it should only be used for maps and other graphics, not for photos. Template talk:Multiplemaps has examples of proper use. Powers (talk) 21:40, 20 November 2014 (UTC)

Proposal to use audio files in phrasebooks[edit]

Greetings, all.

I would like to propose that we overturn the current ban on the use of audio files in our articles. Before I go any further, I'd just like to make it known I am aware there was already a discussion relating to this topic last year, but since it didn't produce any kind of consensus I decided to start a new conversation here. As this may be a controversial proposal, I am more than willing to limit its scope to audio files being used for language phrasebooks; in fact this is the reason I am making the proposal in the first place. The introduction of audio files to phrasebooks as pronunciation aids would be the most beneficial use for audio tech on Wikivoyage.

This idea arose from a discussion over on Talk:French phrasebook, where we have discovered how difficult it is to choose the right letter combinations that effectively convey to English speakers how French words should be pronounced (for example the pronunciation of “merci” may be written as “merr-SEE”).

I suggested the use of audio files for individual sounds as well as words and phrases that ideally would be spoken by native speakers of French, to provide the best guide to pronunciation we can manage for our readers without actually hiring a real life French tutor. These files would be of far more practical use than ambiguous written approximations. Readers would be able to just click on the desired letter, word or sentence and find out exactly how it sounds, and then do their best to mimic the correct pronunciation.

The sound function would be especially useful for whole sentences, as these can be very hard to read in ‘pronunciation guide form’: for example, it’s not clear that our guide’s use of “ess keel-ee-AH kel-KUHN ee-see kee PAHRL ahng-LEH” is any more helpful to a beginner than the original French “Est-ce qu’il y a quelqu’un ici qui parle anglais ?” (“Is there anyone here who speaks English?”). Compare this confusing muddle with a sound file similar to this one (but even better because it would be a real person's voice rather than a computer model) that would tell you exactly how to say the sentence and that could be replayed over and over until you could say the sentence for yourself.

I’ve been informed that many of the sounds are already in the Commons archive, but we’re just not allowed to use them. For the sounds which aren’t already existent it will take a bit of effort, but once they are recorded and uploaded they can be in our guides forever.

Admittedly this change in policy wouldn't fit with the stated project aim that everything on Wikivoyage should be printable, but the number of people taking their smartphones and tablets on trips is only going to keep increasing, and I'm not advocating the widespread introduction of audio files all over Wikivoyage, just the phrasebook series. Plus, I think I'm right in saying that you can download all the Wikimedia sound files on here as MP3 files to your computer or mobile device. These sound files could offer excellent help for travellers while they are in a foreign language environment, and could also act as handy learning tools for while they are on the move.

I apologise for the length, but hope I have explained the proposal clearly enough. Anyone interested in knowing more about the background reasoning should take a look at the original ongoing discussion for French. Though I am personally only involved with French, I am confident that sound files would be a tool that all the language phrasebooks could make good use of.

Over to you, Wikivoyagers! --ThunderingTyphoons! (talk) 22:32, 11 May 2014 (UTC)

I'd like to say, as a participant in the linked discussion on the difficulties of English pseudo-pronunciations for a basic French word like comment, that I support this proposal: Sound files to be eligible for linking, but only for phrasebooks, nothing else. They wouldn't replace pseudo-pronunciation, just supplement it in a similar way that thumbnails of photos supplement but don't replace the text of destination articles. Thanks for writing the proposal, ThunderingTyphoons!. Ikan Kekek (talk) 23:12, 11 May 2014 (UTC)
Support. Actually I don't even bother with the phrasebooks as they stand because the pseudo-pronunciations are not helpful at all. I'd probably use the phrasebooks if they came with corresponding audio.
You might have the issue that some people get hung-up on their prefered accent and pronounciation. Andrewssi2 (talk) 01:20, 12 May 2014 (UTC)
Indeed, the same word can be pronounced differently by different native speakers. That's a concern. The other concern I'd have is that we're talking about a hell of a lot of audio files. We have a policy on minimal use of images, and any similar policy for audio files would be completely blown away if put to this use. Personally, I don't find the audio nearly as helpful as the pseudo-pronunciations, though both in conjunction could potentially be useful. Powers (talk) 20:04, 12 May 2014 (UTC)
There is definitely no proposal to insert audio links in place of pseudo-pronunciations, and if there were, I would oppose it. Ikan Kekek (talk) 21:42, 12 May 2014 (UTC)
Support. Many paper phrasebooks come with CDs. I think that we should allow audio files on phrasebooks. Maybe later we can consider phrases within destination articles (eg. Glasgow#Dialect). It would be worth selecting 1-3 phrasebooks for a trial to iron out any technical issues. AlasdairW (talk) 22:25, 12 May 2014 (UTC)
I suppose these trial phrasebooks should be for a couple of the more major languages. I would of course volunteer French, but would also stress the importance of finding native speakers to make the recordings. For our own ease, we could even use English as one of the trial languages, but obviously for a foreign language WV.
To respond to LtPowers, I guess different people have different styles of language learning, with many finding reading a lot easier than listening, and vice versa. But catering for both learning styles can only be better for everyone. Personally, I find the pseudo-pronunciations a chore to read and an even greater chore to come up with in the first place, but I recognise many people find them helpful.
Wouldn't limiting the use of audio files to phrasebooks by its very nature mean there wouldn't be a sudden flurry of audio files appearing all over WV? There would be a lot in the phrasebooks themselves, but that shouldn't (at least initially) affect the wider audio policy.
The only way around the fact that different accents and dialects exist within a language would be to make sure the same dialect / accent was used throughout any one phrasebook. The main challenge will be in selecting which variety to use over another. --ThunderingTyphoons! (talk) 00:03, 13 May 2014 (UTC)
Which accent to use would be a good topic of discussion on the talk pages of particular phrasebooks. Ikan Kekek (talk) 00:16, 13 May 2014 (UTC)
I'd presume the valley girl phrasebook should be treated as a foreign language in its own right, instead of being lumped in with other languages like English or American? K7L (talk) 15:14, 13 May 2014 (UTC)
A historical language, no longer in use. :-) Ikan Kekek (talk) 18:45, 13 May 2014 (UTC)

[unindent]I don't yet see a consensus to go forward with this, as there are still things that need to be addressed to everyone's satisfaction. Andrewssi2 brought up a concern about potential arguments about which accent to use, and Powers also added the point that this new policy would eventually add a large number of links to sound files, thereby deviating substantially from the "minimal use of images" policy.

One question I have about the second point is, would it help if all the sound files are simply external links to files on Commons and not embedded in any other way (i.e., readers would have to click a link to go to a Commons file, if they want to listen to a sound)? I don't know about ThunderingTyphoons!, but that's how I was conceptualizing this. Of course, that would involve a large number of sister-site links to Commons, but we already do that with all the numerous articles that have multiple thumbnails on them.

In terms of accents, is the idea that this can be discussed in each phrasebook's talk page satisfactory? I think it is, and what accents we should prefer should be obvious much of the time. For French, if we can get an accent from Paris/Ile de France, though would be optimal. For Spanish, a Castillian accent is optimal because it will be recognized most widely by Spanish speakers around the world. For Mandarin, a Beijing-area accent is probably the best, for similar reasons. For Italian, a Tuscan accent is optimal because standard Italian is based on the Tuscan dialect, but we don't want to thick a Tuscan accent (no "cohomero" for "cocomero," etc.). I think we can discuss these things for each language in turn, but still, even if we don't get the ideal accent, if we get one that's close enough, that's fine, but no Swiss-German in place of standard German German, and no Quebecois in place of French French, and no Napulitano in place of Tuscan (or similar) Italian. Ikan Kekek (talk) 10:47, 17 May 2014 (UTC)

I completely agree that the accent question should be left up to the individual editors of their respective phrasebooks, if only because they're likely to know more about their language of interest / expertise than us.
I was actually thinking of embedding the sound in the article, if only because it would be easier for people to be able to still see how the sound / word / phrase is written while listening. That said, if it will help us reach a consensus I'd happy to go with external links as long as they are quick and easy to follow (no more than two clicks ideally).
Just to clarify, and forgive my ignorance of how the Wikimedia Commons work, is it the case that anyone (or for our purposes, any Wikivoyage editor) is free to upload any sound files they wish? --ThunderingTyphoons! (talk) 13:51, 17 May 2014 (UTC)
I believe the only requirement to upload a sound file is that you be registered and logged in. As for the external links idea, I'm pretty sure embedded sound files don't start downloading any actual audio until you click on them, so it should be fine to just go ahead and embed them.
Thatotherpersontalkcontribs 21:41, 17 May 2014 (UTC)
You might want to consider other issues with accents. Japanese (for example) is a gendered language meaning that its gramatical use and sound can depend on the gender of the person speaking. I'm not sure of other languages where this is the case. Andrewssi2 (talk) 23:44, 18 May 2014 (UTC)
Wouldn't Talk:Japanese phrasebook be the place to discuss that, if indeed audio files are proposed for it? (And I think it would be a low priority, as Japanese pronunciation is easy to represent in pseudo-pronunciation.) In this thread, we're simply trying to see if there can be a consensus to allow sound files in (or linked from) phrasebooks. Could you please share your views on this? Ikan Kekek (talk) 00:17, 19 May 2014 (UTC)
It was an example to show that the whole subject of pronounciation (not just Japanese) is rather complex. If audio goes ahead then of course it could be discussed on that page.
An experimental page (perhaps under ThunderingTyphoons! user space?) could best show how the audio could work. (eigher as link, or embedded if WV could support that) Andrewssi2 (talk) 00:57, 19 May 2014 (UTC)
An experimental page sounds like a good idea, and I'd be happy for it to be set up in my user space. --ThunderingTyphoons! (talk) 14:24, 19 May 2014 (UTC)
I believe embedded files are more useful, but it seems like they would have a performance impact. I mean, we're talking about literally hundreds and hundreds of files per page. Powers (talk) 01:17, 20 May 2014 (UTC)
True, although perhaps that would be acceptable for a reader who is specifically looking for a French lanaguage guide?
One similar page on about.com has links to WAV files. 'À bientôt' is a file of 16k in size. If we had 50 embedded in an article then it would be around 0.78MB. For comparision this Talk page is about 0.48MB in size.
Disclaimer: Yes, these are rough calculations for 'rough order of magnitude' purposes only. Exactly article sizes will vary based on many more factors. Andrewssi2 (talk) 01:55, 20 May 2014 (UTC)
I believe you're off by an order of magnitude, so we're talking more like 5 MB. Powers (talk) 11:22, 20 May 2014 (UTC)
I think that the 16k estimate is a little on the low side, but not massively. We will probably be using ogg format files (the preferred format on commons), and recordings of a single word take around 20 - 40k. For examples see Commons:Category:Pronunciation of names of places in Scotland. From other files, it looks like 1 minute occupies 1 - 3MB. I don't see this size as a big problem, for phrasebooks - a short phrase is similar to a thumbnail picture in size. AlasdairW (talk) 22:17, 20 May 2014 (UTC)
See the comment above from Thatotherperson - the audio files are included in articles as links and have no impact on performance beyond the few bytes it takes to render the player. As an example, this file:
...is 1.32 MB, but none of that data is downloaded until you try to play the file. -- Ryan • (talk) • 22:42, 20 May 2014 (UTC)

Photos of businesses[edit]

Regarding K7L's recent edits: I'm wondering what is meant by "purely promotional" images. The photos in question only appear when you deliberately click on a specific business, so obviously the reader would already be interested in the place and looking for more info. What photo would be promotional without being of any use to this person? I would consider it ideal if every listing on the site had a map marker photo.
Thatotherpersontalkcontribs 04:46, 18 May 2014 (UTC)

The primary concern is business owners uploading photos of their own businesses and editing the corresponding listings to reflect those businesses in an artificially favourable light. For instance, a management company might run fifty hotels under different franchised brands in various towns in the same region. The individual properties are economy, limited service - something like "Journey's End" or "Comfort Inn" where they all look basically identical - and uploading a photo of each of them adds little for the traveller... much like uploading a photo of every Burger Queen location (or whatever franchise) adds nothing useful. A photo of just the company logo, or placeholder (logo as a sign with just sky in backround) promotes the logo's brand but tells the traveller nothing. We're not a directory, we're not an advertising medium. K7L (talk) 15:23, 18 May 2014 (UTC)
Commons doesn't disallow photos of multiple locations within a business chain. They even have categories for it, including over 60 categories for Burger King alone. Maybe the Comfort Inns all have a similar look, but if a traveler is unfamiliar with the chain and wants to learn a little bit about it before booking, we shouldn't make them hunt down a photo of a similar-looking Comfort Inn when Commons has a photo of the Comfort Inn location they just clicked on.
Thatotherpersontalkcontribs 00:37, 19 May 2014 (UTC)
This isn't Commons and is not meant to be a repository of any and all images. Having said that, I think there's a lack of understanding of what you propose. You are not proposing having images of non-iconic businesses that are viewable in destination articles, correct? What exactly are you proposing, and how would it work? Ikan Kekek (talk) 01:50, 19 May 2014 (UTC)
I'm not proposing any new use of images, I just think the map marker photos already in use on some pages should be encouraged sitewide, whereas the language recently introduced to the policy page by K7L sounds like we're discouraging their use. If you aren't familiar with the map marker photos, you can see how they work by clicking any POI marker on this map except Drink listing #1. They don't involve uploading anything to Wikivoyage itself; the uploading happens on Commons and the photos appear on the dynamic map when an attraction is clicked. The only thing that gets added directly to Wikivoyage is one string of code per listing: |image=Attraction-photo-filename.jpg
Thatotherpersontalkcontribs 03:41, 19 May 2014 (UTC)
Thanks for the explanation. I find that business photos, in that context, are wholly unobjectionable, and that a specific exception should be made to the policy on business photos for this situation only. Ikan Kekek (talk) 03:48, 19 May 2014 (UTC)
I concur that a specific exception should be made - for the reasons stated above. -- Alice 19:29, 22 May 2014 (UTC)

Logos that should be included[edit]

The only text about logos currently in the article is "Purely promotional images, such as logos for each location of identical chain restaurants and hotels, are best avoided; the content needs to be useful to the traveller." I think that is obviously correct.

However, those are not the only logos we might show, and we should show logos that are useful to the traveller. There is discussion at Talk:Netherlands#VVV_logo of whether to show the logo for the national tourist organisation whose information offices are very useful indeed. In many cities, it will be essential for travellers to recognise the logo for the local transport system: bus, metro or whatever. No doubt there are other examples.

I'd like an addition to policy here saying that such logos should be shown wherever possible.

All such logos are presumably protected by trademark or copyright law. I think this usage would be protected as fair use, and I doubt the organisations involved would object to free advertising anyway, but this may need analysis from a lawyer. Pashley (talk) 15:21, 21 May 2014 (UTC)

I certainly agree. We'll have to agree on a clear phrasing, though. Ikan Kekek (talk) 16:17, 21 May 2014 (UTC)
I would say that any mention of logos is unnecessary - it is enough for us to say that "Images that serve no particular purpose other than promotional should be avoided." If you believe it needs saying, we may add that logos and other particular features of POIs that have no competition and that a traveller may find necessary to locate, such as tourist information, bus stops etc. are OK to be included - but I find it long-winded and unnecessary. Wikivoyage works better when we simply state our general goals and use common sense and, if necessary, consensus, to determine how to act to fulfill them. Our goal is to help the traveller the best we can, and our goal is not to promote a particular business in a competitive environment. This kinda helps deciding when a logo is useful and OK to display, and when it should not be.
Let us also be aware that by over-codifying we will run into trouble when e.g. a landmark features a commercial logo prominently - should we not show the landmark? Should we cover the logo, but then not render the landmark's true appearance? I believe we should de-codify Wikivoyage a bit with regard to this particular bit of policy and let common sense and our principles prevail. PrinceGloria (talk) 20:09, 5 June 2014 (UTC)

Image sizing[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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:
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[edit]

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[edit]

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 [5]. 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)

[edit]

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[edit]

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?[edit]

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[edit]

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[edit]

((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[edit]

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[edit]

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[edit]

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[edit]

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)
Yes 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[edit]

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[edit]

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 (talkcontribs)
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: [6] 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)

How many pictures per page?[edit]

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)