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

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

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

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

{{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)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(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)[reply]

(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)[reply]

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

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

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

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

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

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

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

(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)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@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)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{{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)[reply]

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

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

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

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

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

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

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

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

Proposal to change default thumbnail size[edit]

A rough consensus has emerged: We should change our default thumbnail size to 270px, and range of user preference options set to 120px, 150px, 180px, 220px, 250px, 270px, 300px, 350px, 400px, 450px and 500px. Added by: Peter Talk 19:37, 15 April 2013 (UTC)[reply]

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

• 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)[reply]
• 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)[reply]
• 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)[reply]

• 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)[reply]

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

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

• 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)[reply]

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

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)[reply]
• 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)[reply]

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

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

• 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)[reply]

• 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)[reply]

• 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)[reply]

• 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)[reply]

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

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

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

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

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

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

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

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

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

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:

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

• 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)[reply]

• 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)[reply]

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

• 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)[reply]

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(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)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(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)[reply]

(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)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

(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)[reply]

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

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

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

(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)[reply]

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

(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)[reply]

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

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

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

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

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