Wikivoyage talk:Image policy/archive 2014-2019

Images under the Exemption Policy

Swept in from the pub

Hello,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Non-free images

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

Feel free to tweak as necessary.

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

File on Commons message

Swept in from the pub

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

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

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

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

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

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

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

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

Privacy rights shed

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

Thumb alignment

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

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

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

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

Our Image policy article should clearly state:

"

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

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

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

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

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

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

Again

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re the reasons listed above:

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

Proposed wording

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The only options I see are to

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Galleries

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

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

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

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

How about:

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

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

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

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

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

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

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

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

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

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

Gallery text title not collapsed

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Guidelines for "minimal use" of photos

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

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

Sizing of images

Wondering about greater consistency in image sizing.

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

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

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

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

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

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

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

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

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

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

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

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

to this:

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

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

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

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

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

If a larger range is available, then this:

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

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

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

Image sized as factor of default

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

There are two things I'm not understanding:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Panorama pictures

Swept in from the pub

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

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

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

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

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

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

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

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

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

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

Proposal to change default thumbnail size

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

Proposal: Based on threads above:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bug rejected April 17 for server load and storage reasons:

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

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

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

space it takes

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

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

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

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

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

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

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

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

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

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

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

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

I feel like I'm in wonderland again.

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

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

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

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

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

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

Renewed proposal to change default thumbnail size

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

Therefore:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Policy for photos of businesses should be relaxed

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

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

A better policy would be:

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

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

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

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

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

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

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

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

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

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

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

View on Wikipedia's city collages

Swept in from the pub

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

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

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

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

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

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

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

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

Parallel discussion on this page (not swept)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Audio files

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Wire Tour

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(reindent} There are three drivers I see here.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Climbing the Eiffel Tower.

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

'Mind the gap' on the London Underground.

User:rogerz I prefer these:

Tower Bridge

Paris

Nepal video

Budapest video

Turkishd landscape

Norway video

Israeli beach video

QueenSt. BeatrixBarths Airport

cheese market

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

Slovenia coast

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

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

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

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

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

I am firmly against allowing videos for the following reasons:

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

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

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

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

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

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

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

A couple of suggestions for a video policy:

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

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

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

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

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

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

OK, We have a test case.

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

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

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

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

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

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

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

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

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

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

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

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

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

Convenience break

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

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

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

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

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

All the best,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Retina Display Considerations

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

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

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

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

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

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

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

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

Animated Gifs v2

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

I just saw the following on Stuttgart:

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

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

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

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

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

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

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

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

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

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

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

As per Ryan's request, changing to:

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

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

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

Licensing for locally-uploaded images

Swept in from the pub

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

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

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

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

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

Image licensing paperwork

Swept in from the pub

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

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

There are 4 machine generated categories:

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

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

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

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

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

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

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

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

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

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

Photolist

Swept in from the pub

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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