Wikivoyage talk:Image policy

For archived talk page discussions see: Wikivoyage talk:Image policy/old-en archive Wikivoyage talk:Image policy/archive2007-2013 Wikivoyage talk:Image policy/archive 2014-2019

WebP

I've seen some WebP images uploaded to the Commons, so is there any discussion for this file format? --Great Brightstar (talk) 17:06, 30 August 2020 (UTC)

At the moment there appear to be very few WebP files on Commons (a search revealed a total of 2,500 files compared to 3 million .png files). Can you give an example of a WebP image on commons which you think would be useful here? AlasdairW (talk) 20:19, 30 August 2020 (UTC)

Watermarks

I know that we don't allow images with watermarks to be used on this site. Wouldn't it be easiest if we stated that explicitly and clearly on this page? Ikan Kekek (talk) 22:41, 18 September 2020 (UTC)

Is it that we don't allow them or that we don't use them? I though it was the latter. I have never seen anybody claim they are not allowed, but if I see one I try to find one without, if an image is needed, in the same way as when I see a blurry or otherwise bad image. –LPfi (talk) 07:52, 19 September 2020 (UTC)

A watermark can of course be seen as giving credit to the photographer (or an organisation) in a way not given to other photographers providing photos under CC-BY or CC-BY-SA, both requiring equal credit. Seen that way we cannot use them without violating the licence. –LPfi (talk) 08:05, 19 September 2020 (UTC)

I don't think there's a distinction between not using them and not allowing the use of them. How about this language? Images with watermarks of any kind cannot be used on this site. Ikan Kekek (talk) 08:10, 19 September 2020 (UTC)

 :-)

I don't know about "any kind". There might be times we want the watermark included – banknotes? "Images with watermarks cannot be used on this site, unless the watermark is an essential reason to choose that image"?

We could also have a remark on bylines: "We do not use bylines. Photographers are credited on the file description page, and giving some photographers more credit than others violates the CC BY-SA licence used for many images. The author can be mentioned in the caption of historic images, paintings and the like, when it is supposed to be of interest for the reader."

–LPfi (talk) 08:29, 19 September 2020 (UTC)

Looks good to me. Ikan Kekek (talk) 09:13, 19 September 2020 (UTC)

Question

Wikivoyage:Image_policy#Attribution_and_watermarks includes the text "giving some photographers more credit than others violates the CC BY-SA licence used for many images." I'm not a lawyer & it has been some time since I read the license, but the statement looks false to me.

I want to delete it. What do others think? Pashley (talk) 17:57, 4 October 2020 (UTC)

I don't know whether that violates the license or not, but the point is that it's manifestly unfair and against site policy. Maybe that's enough to state? Ikan Kekek (talk) 18:12, 4 October 2020 (UTC)

I remembered a bit wrongly, the licence reads:

"The credit required by this Section 4(c) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors."

I had not noticed the "if a credit for all ...". I think the requirement of fairness is enough for requesting equal credit also absent such a list, but my interpretation (IANAL) is I have been wrong. –LPfi (talk) 19:13, 4 October 2020 (UTC)

People in photos

Swept in from the pub

Our upload form says "Avoid people in photos, unless you have their written permission". I do not know from where that comes. At least our image policy does not have any corresponding wording in People in photos. I suppose we don't want to have images that show deserted roads when visitors will see them crowded (and you wouldn't get the written permission of a crowd). Sometimes also having somebody look out over a landscape makes a better photo than the landscape alone. Commons' guideline Photographs of identifiable people is quite lenient.

Can we simply remove the wording from the upload form, should we have a link to the relevant section in our policy, and perhaps a link to the Commons guideline, or is there any reason we would want the present language to stay in some form?

–LPfi (talk) 07:40, 11 February 2021 (UTC)

I concur. This policy has always struck me as unnecessary. Perhaps in the Wikitravel days, before we were affiliated with the WMF, it made sense because as a small independent wiki, we would have been less able to finance a legal defense in case someone sued (regardless if such a case had merit or not). But we're in a different situation now. First of all, in the vast majority of cases we're supposed to source our media from Commons, with local hosting remaining appropriate in only a narrow range of special cases which mostly exclude any context in which you'd see images of people. Secondly, LPfi correctly points out how much more lenient Commons' "photographs of identifiable people" policy is than ours; as a sister project whose entire purpose is to serve as a repository for copyleft-compatible media, they presumably know better than we do what passes legal muster and what doesn't, so it's perfectly sensible to follow their lead in determining where the boundary lies. Thirdly, in the infinitesimal chance that we do miscalculate and find ourselves in legal trouble for allegedly violating someone's privacy in a locally-hosted image, WMF Legal is a resource we now have at our disposal that we didn't before. -- AndreCarrotflower (talk) 20:56, 11 February 2021 (UTC)

On the other hand, we don't really want people uploading photos of themselves posing in front of the attraction. A crowd of people or a few incidental people in the background, but I don't think we want photos that feature identifiable individuals prominently. WhatamIdoing (talk) 19:34, 12 February 2021 (UTC)

True, but if we want written permissions, that is easier to get from your own company – the wording furthers exactly that kind of images. The wording in our image policy, on the other hand, discourages exactly such selfies. –LPfi (talk) 21:11, 12 February 2021 (UTC)

Former policy ca April 2006 (text by Evan and WTjk44) In general, photos of people will be removed from Wikitravel. There are two reasons for this policy: A photo of the Taj Mahal is useful for travellers; a photo of your girlfriend in a funny hat standing in front of the Taj Mahal is not. In general, we don't really want pictures of travellers or other people in Wikitravel. Some exceptions might be for particular sports or activities or crowd scenes or illustrating some costume or uniform. In the United States and elsewhere human beings have privacy rights, that is, a right to control the use of their own image, even if they didn't create the image. Image creators need to get authorization from human subjects of photos to publish the images. See http://www.danheller.com/model-release.html for a description of why and when a model release is required. A general rule of thumb is that if an image contains a subject that is identifiable, a model release is needed.

"Avoid people in photos, unless you have their permission to publish their image" was present in the very first revision of the Upload page, written by Evan. At the time that was written, our image policy read as seen here. For convenience, I've put the text in an infobox. Powers ^(talk) 00:37, 23 February 2021 (UTC)

There are times where a person is convenient to give a sense of scale, or just to identify that rockclimbing, snowboarding or skiing etc actually take place there. I'm uncomfortable with doing so in ways that make those people identifiable. WereSpielChequers (talk) 09:51, 14 March 2021 (UTC)

Sound files

Please see this edit for background. Apparently current policy explicitly allows sound files only in phrasebooks. Wikimedia Commons already has pronunciation clips for every municipality in Portugal. They're used in Wikipedia, and I believe that they would be very useful to our travellers, saving them the embarrassment of massacring the pronunciation of Portuguese place names. Beyond here, such pronunciation files will be helpful in other countries as well (including for many places in the Anglosphere that have counterintuitive pronunciations). Our made-up pseudo-pronunciations are inadequate, not as straightforward as we would like to think, and barely less complicated than IPA.

I, therefore, recommend that we expand our policy to allow sound files in destination articles for place name pronunciation in addition to the current allowance of using such files in phrasebooks. I do not wish to replace pseudo-pronunciation as our principle pronunciation help; I want to supplement it for the benefit of our travellers.

@Ikan Kekek

--Nelson Ricardo (talk) 23:43, 5 July 2021 (UTC)

I'd support this change, but let's see what countervailing points are brought up and give it 5-7 days or so. Ikan Kekek (talk) 23:45, 5 July 2021 (UTC)

Seems reasonable to me. —Granger (talk · contribs) 06:57, 6 July 2021 (UTC)

I'd support it. Dunno about rest of the world, but Australian names are hard to pronounce. (e.g. Tjuntjuntjura, Wooloomooloo, Balranald, Oodnadatta etc.) SHB2000 (talk | contribs | en.wikipedia) 07:01, 6 July 2021 (UTC)

Those Australian names aren't phonetic (choon-choon-choorah, woo-loo-moo-loo, bahl-rahn-ahld, etc.)? Ikan Kekek (talk) 07:23, 6 July 2021 (UTC)

Some are, some aren't and have a completely different pronunciation. SHB2000 (talk | contribs | en.wikipedia) 09:13, 6 July 2021 (UTC)

• Support.--ThunderingTyphoons! (talk) 08:57, 6 July 2021 (UTC)

• Comment. I will support the proposal, but I'd first like to have a guideline on how they'd be used. "Place names" sounds like at least the place an article is about, and I suppose the pronunciation link should be close to the boldface place name with link to its official tourism web site. But what should the link look like? Should a pronunciation parameter also be added to the listing templates? Perhaps pronunciation links could be included inline elsewhere. I don't think we are ready to allow someone adding a link everywhere they deem it suitable. –LPfi (talk) 09:12, 6 July 2021 (UTC)

  I believe that the top of the Understand section is the best place to put it. Please see this old page version for an example. I don't think we want to clutter up the lead with pronunciation info. We're not Wikipedia.

  By the way, policy was changed last year to place the official tourism site toward the end of Understand section rather than in the lead. Wikivoyage:External links#External link usage. Nelson Ricardo (talk) 09:42, 6 July 2021 (UTC)

• Support. --Comment by Selfie City (talk | contributions) 11:25, 6 July 2021 (UTC)
• Support. I agree with putting it in Understand. I think adding (/ˈgɾɐ̃.du.ɫɐ/, GRUHN-doo-luh) to the lead paragraph is a bad idea as it makes Wikivoyage look encyclopedic and unappealing when only the first couple of lines show up in a search engine result. We should not, however, include them in Brazilian articles as no English-speaker is ever going to be able to pronounce Brazilian Portuguese anyway. (I'm joking, of course. Maybe it's just me.) Ground Zero (talk) 11:33, 6 July 2021 (UTC)

@Ground Zero: that's me as well. Especially with the r's. SHB2000 (talk | contribs | meta.wikimedia) 11:38, 6 July 2021 (UTC)

Some of us have more difficulties than others. Regardless of how one's pronunciation ends up, it is nice (and often useful) to know the local pronunciation, or at least recognise it. Even for me in Sweden, some local pronunciations are surprising (cf the Anglosphere comment in the original post). –LPfi (talk) 12:28, 6 July 2021 (UTC)

tbh, I've never heard a tourist say an Australian indigenous name properly. Even I myself find pronunciations quite surprizing. SHB2000 (talk | contribs | meta.wikimedia) 12:32, 6 July 2021 (UTC)

"Regardless of how one's pronunciation ends up, it is nice (and often useful) to know the local pronunciation, or at least recognise it." I agree. I also agree on the guidelines proposed above: Put or link the audio file in "Understand" and restrict it to the name of the destination the article is about, not the umpteen "See" listings, etc. Ikan Kekek (talk) 17:23, 6 July 2021 (UTC)

I agree with Ikan Kekek's description of the guidelines. Ground Zero (talk) 17:52, 6 July 2021 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ It looks like consensus will be to allow place name pronunciation audio files. I propose we edit the end of the Wikivoyage:Image_policy#Other_media section as follows after we close this discussion.

“ ...with two exceptions:

• Audio files for pronunciation may be used in phrasebooks.
• Audio files for place name pronunciation may be used in destination articles in the Understand section. Such files should not be used alone, but as a supplement to pseudo-phoneticization (our preferred pronunciation help). Audio file usage is limited to the article's destination name itself. See Caldas da Rainha#Understand for an example of usage.

”

--Nelson Ricardo (talk) 19:57, 6 July 2021 (UTC)

I support the addition of destination pronunciation, and the words above look good. It will be a welcome addition, and in many cases the files have already been recorded for WP. I would also suuport their use in the Talk section of articles (essentially mini-phrasebooks), but this can come later. AlasdairW (talk) 20:06, 6 July 2021 (UTC)

About a week has passed without opposition. I'll go ahead and add my edits to the policy. Thank you for your support. --Nelson Ricardo (talk) 20:53, 11 July 2021 (UTC)

Upright image sizes

I recall vividly that these are against Wikivoyage policy and that that led to long, acrimonious edit wars with Frank, but where is it actually stated that you are not allowed to use them? Ikan Kekek (talk) 20:49, 10 August 2021 (UTC)

No comments? Ikan Kekek (talk) 20:14, 18 August 2021 (UTC)

Do you mean portrait-oriented (taller than wide) pics vs. landscape-oriented (wider than tall) pics? I have no idea, but clarifying may jog other contributors' memories. Nelson Ricardo 2500 (talk) 20:24, 18 August 2021 (UTC)

No, it's not about orientation. Have a look at this edit. Where it says "upright=" is the issue. Ikan Kekek (talk) 20:34, 18 August 2021 (UTC)

Why is it an issue and what difference does it make to the image? --ThunderingTyphoons! (talk) 21:55, 18 August 2021 (UTC)

I think it may have been a policy, and was much discussed in Wikivoyage:User_ban_nominations/Archive#User:W._Frank, but I don't know where it is stated. It is notable that "upright=" isn't mentioned in Wikivoyage:How_to_add_an_image#Sizing. Using "upright=" does make it harder to have a set of images of the same width in the right column, which might be a reason for forbidding it.

I also note that it does allow editors to put large images on a page without it being visible in the source. If an edit changes [[File:picture|thumb|caption]] to [[File:picture|thumb|900px|caption]], I can immediately see the change in a diff, and would probably hit undo. However if the change is to [[File:picture|thumb|upright=2|caption]], I have to look at the page to see if the edit is ok. AlasdairW (talk) 22:01, 18 August 2021 (UTC)

The claim was that since proportional sizes will look very different on different browsers, they can be user-unfriendly. I never had a personal beef with them, but since they were the occasion of years of knock-down, drag-out fights with W. Frank/Alice, yet I can't see where any policy about them is actually on a policy page, it would be good to make a decision about them. Ikan Kekek (talk) 02:18, 19 August 2021 (UTC)

I don't understand. "upright=2" is explicitly making the image double the normal size. Why would one have to look at the rendering to see that? And why is it harder to have a set of images of the same width when they are "upright=1.3" than when they are "320px"? The parameter is just for changing image sizes in relation to the user's default image size, instead of in relation to what the editor has on their screen. The difference between the two ways of changing image sizes concerns only those users who have chosen a default image size themselves – and specifying a bigger size in pixels, those users may actually get a smaller version of that image. With different browser window sizes you won't get the same layout anyway. –LPfi (talk) 04:13, 19 August 2021 (UTC)

I think the argument was that we should use the default size almost all the time and that if we specify a different size, it's somehow more predictable to use numbers of pixels than proportions. If that's not true, it's not true. As I said, I don't care greatly, but I think we should resolve the issue. Maybe there are some longtimers who have a better memory than I of why this question was important. I do remember ultimately seeing their point, but for the longest time, I favored Frank's argument (though not his behavior in the face of a consensus against his point of view on that and other things). User:Pashley, User:Inas, User:Jpatokal, Powers, User:AndreCarrotflower, do you guys remember why Frank always lost the argument on proportional image sizes and it was considered important enough not to concede on? Ikan Kekek (talk) 05:04, 19 August 2021 (UTC)

If you say 320px, the image will predictably be shown at about 320px. It might, though, show smaller rather than larger than an image at default size, for users who have changed their default size. To have all images show at predictable sizes – in pixels – you have to override the user preferences for all images by providing px sizes. You still don't know how big they will be in inches. A user with extreme resolution will get relatively small images, as you override their large preferred size, as will a user who just prefers large images. If you don't use px sizes the user gets their preferred size (or WMF's default). With upright= you can still make some images larger, relative the user/WMF default. I was never involved in the Frank dispute, and I don't know those arguments. –LPfi (talk) 05:56, 19 August 2021 (UTC)

Sorry, Ikan, I avoided those arguments whenever possible. Powers ^(talk) 01:20, 20 August 2021 (UTC)

A very wise decision! Ikan Kekek (talk) and 01:25, 20 August 2021 (UTC)

Hi Ikan, do you mean this discussion? I didn't participate in the original discussion, but the point about maps/graphics makes sense to me (it's toward end of the discussion). I make maps to a specific size usually to ensure readability, although it's probably not a problem if the map ends up bigger than intended. -Shaundd (talk) 02:23, 20 August 2021 (UTC)

That's a relevant thread; thanks, Shaundd. I guess the question is, is it still enough of an issue that either (1) everyone has a different default width for thumbnails or (2) anyone is asking Wikimedia to change the default size of thumbnails and they might actually change that? Part of the problem is, if we do decide to uphold a ban on upright image sizes and note that on this page, it will be really annoying for User:Travelwriter1000, who's been really helpful in adding quality images and pagebanners and uses upright image sizes all the time. I'd be content to leave well enough alone, but considering how much trouble previous arguments over this policy caused, it seemed to warrant a discussion. Ikan Kekek (talk) 02:49, 20 August 2021 (UTC)

hard to see

takes up way too much space

I actually switched to the upright option because I thought I was supposed to avoid using the #px option 😅. Upright solves the problem of having a default width to all thumbnails, which is highly relevant for pictures like these of Qeshm Island and the Empire State Building. In other words, having all images display at the same width isn't actually a good thing.

I just dug up the way to change the default thumbnail width of 220px (which is just way too small) at Special:Preferences#mw-prefsection-rendering, but probably only the most diehard users would ever find that. For what it's worth, I look at this site mostly for the pictures, since it's usually a little better at giving me an idea what a place looks like than Google or Wikipedia, so it's nice to have the images big(ger) and beautiful. The travel information isn't too relevant these days, since COVID has screwed up travel 🙄. Travelwriter1000 (talk) 14:39, 20 August 2021 (UTC)

Thanks for your input. There's no question that some thumbnails shouldn't be presented in default size. It seems like no-one really cares greatly about upright image sizes anymore. Would anyone object to just leaving well enough alone, or should we state that it's OK, recommended or not recommended to use them? Ikan Kekek (talk) 00:08, 21 August 2021 (UTC)

[outdent] It is really a pity that WMF doesn't allow changing the default image size. I think that would solve most problems, and I think that is what eventually has to be done. One possibility would be to just ignore the possibility of choosing your own default size. If only "the most diehard users" do that, we might regard the layout for other users as more important. For those who haven't set it, default size and 220px are equivalent, as are "upright=1.2" and 264px. With upright= we can change relative sizes, which works well with portrait/landscape, and the lead image if we want it bigger, but we should not have a default of "default + 30%". The only way to cleanly get bigger images all over is by specifying sizes in pixels.

We could change the image policy to recommend 400px (or whatever) as default. If we do this, we should use a size from the list of possible preferences. For the servers it will not be worse than every article being read by one user with 400px as preference, with images at default size (the thumbnails would have to be generated for that user, and will then be cached). Still, this is voiding the WMF decision not to allow different defaults in server settings; I don't know how (or whether) they'd react.

–LPfi (talk) 06:12, 21 August 2021 (UTC)

I kind of feel like we never really came to a full resolution on this question. What is our position on upright image sizes? Ikan Kekek (talk) 21:10, 15 January 2022 (UTC)

I think that we should recommend using pixel sizes either for all images in an article or only for those that are best (or adequately) viewed at a specific size, such as often maps and graphs. Using pixel sizes, we should probably have some site-wide recommendation on an editor default. If default/relative sizes are used, then you should use the upright parameter as appropriate, and there is no reason not to use it when it makes sense for the layout. The problems come when mixing the two. If we aren't going to recommend "default=default+30%", then relative sized images will default to the (small) WMF default. I think it'd be a pity to have to specify sizes in pixels, but if we want bigger images, it seems that's the way to go. –LPfi (talk) 14:33, 16 January 2022 (UTC)

So I think we have three choices:

# Use the default size, with upright as needed (and maps etc. possibly in px).

# Specify sizes in pixels, recommended some size as default.

# Use the default size with upright=1.3 (or whatever) as default.

One choice per article, and perhaps a site-wide recommendation.

–LPfi (talk) 14:43, 16 January 2022 (UTC)

It seems that in the 2013 discussion 1.2×220px ≈ 270px was deemed a good default. Is our default thumbnail size still 220px? –LPfi (talk) 15:24, 16 January 2022 (UTC)

Thumbnails of 250px and 300 px are available as personal defaults, and thus would perhaps not increase the server load as much as 270/280px. Does somebody have current knowledge about server implications? –LPfi (talk) 15:56, 16 January 2022 (UTC)

A change to a 300 px default was proposed back in 2014, but turned down, with this summary: "So for anyone visiting this ticket: 'Please show that you have the support of a substantial number of wikimedia communities and NO, for technical reasons, this is NOT a per project decision.'" The techs were worried that bigger sizes would be detrimental for some parts of the communities. Non-logged in users cannot change their default sizes, and some may pay per kB. The bug was reopened in 2020 as stalled, waiting for community input, which would require somebody to raise the issue across wikis. Sigh. I don't see any recent discussions on the cache issues that were holding the original requests back, referenced also in this bug discussion. –LPfi (talk) 17:15, 16 January 2022 (UTC)

I would support establishing in policy that pixel sizes are to be used rather than upright. I don’t think we need to change existing upright formatted images but going forward having a policy or guideline for the more straightforward pixels seems like a good idea. --Comment by Selfie City (talk) (contributions) 19:12, 16 January 2022 (UTC)

Pixels are not at all straight forward. We'd either need to recommend certain sizes, and editors need to remember them, or then everybody is specifying their own sizes depending on what screen they happen to use. The "uprigh" option in its simplest form means not specifying the size at all, other than where necessary, and then using the upright, usually with a factor of 0.5, 0.7, 1.2, 1.5 or 2. If we choose a default separate from WMF default, those times 1.2 or whatever we choose. –LPfi (talk) 19:33, 16 January 2022 (UTC)

Clarification on image distribution needed

It says in the image guide that images should be evenly distributed across chapters of an article.

However, when images belong to a specific See or Do, doesn't make it sense to put them there? This especially helps the mobile view of WV (here on the site and in OsmAnd), because every See or Do would start or end with the approriate image.

Of course the downsite would be thay if See and Do are too short in text, images would stack up too much.

Nevertheless, I would like to adjust the image guide accordingly that for cases of pictures with existing See and Do where pictures indeed end up next to their listing in the regular view, the images are placed above the according See or Do listing.

Opinions?

Cheers Ceever (talk) 09:51, 16 October 2022 (UTC)

There are different opinions on this. I always try to find a good context for any image and avoid using images that wouldn't match the surrounding text. I have heard others say that the important thing is to have nice images (throughout the article). The current wording is good to point to for editors who like to stack up the articles in the lead (with a wide screen that makes little difference to the layout).

The mobile view issue makes it clear that images should be placed in an appropriate section, preferably at least one image in each of the major ones if they are long enough (Stay safe and the like might not need images). It is quite common to put an image at the end the previous section, to have it start at the heading instead of below it, which apparently shouldn't be done. The main problem is that it usually is easy to find nice images for See, while it often is harder to find anything nice for the other sections.

We also avoid images of specific businesses, so having the image by a specific listing might not be what we want. The rafting image would get into Do, but not necessarily by Rafting Someriver Ltd, and the company name would be left out. If rafting is the thing at this destination, the image could be in Understand instead of Do.

–LPfi (talk) 12:33, 16 October 2022 (UTC)

I think this discussion was prompted by an edit of mine.

More about how the relevant consensus developed is at this long discussion.

I don't have statistics at hand, but I guess a good portion of our viewings should be coming from mobile devices. But nevertheless, that doesn't mean we shouldn't be considerate of how the pages of this website are viewed on desktop.

I agree with LPfi that the images are best used within the context they make most sense. However, the possibility of us forcing the readers view the image of a place minutes before and after they read the description about that place for aesthetical reasons isn't the end of the world.

And then there is a sort-of metaphorical way of placing the images; e.g. an image of an ancient sign supposedly showing the way to a brothel next to a "Sleep" header (when viewed on desktop) fits well with Wikivoyage:Tone I think. Vidimian (talk) 18:03, 16 October 2022 (UTC)

When the images are lined up with specific listings, to me it implies they are illustrations to that listing, which is quite confusing after the linked edit. With a maximized browser window (on my tabletop screen), the layout is more or less the same: there is little space between the images, just enough to cause the confusion. With my standard width, before the edit there was a screenful without images, which is a little more than ideal but no big deal (the five images more or less in a row is a bigger issue, but this isn't a star), while after the edit they are literally evenly spaced, which does not look nice. (I don't appreciate the "sleep" humour, but I wouldn't have noticed it without it being pointed out.)

Note the wordings in the guideline about groups of at most three images; grouping some images and having varying distance between groups or individual images give a much more lively layout. Evidently the guideline needs to be reworded to avoid the literal interpretation.

A note to everybody: when there is a blank line or a line with an image, between the bullets in a list, the list is broken up, which sounds terrible when the page is listened to. I usually do like this:

• {{listing| [...]}}<!--

-->[[File:whatever.jpg|thumb|whatever]]

• {{listing| [...]}}

Commenting out the line break avoids it breaking the list, while having it on a line of its own makes it easier to find when looking at the wikitext.

–LPfi (talk) 19:25, 16 October 2022 (UTC)

I would probably redistribute the images, to avoid useless tiny gaps and instead have some bigger ones, ponder whether all images are essential, whether they could be smaller and whether one of them could be moved to (or exchanged for one that fits) Get in. If the images are not adjacent to the listings, it helps if the name in the listing is reflected in the caption (now we have Great Theatre and Grand Theatre, are those different?). –LPfi (talk) 19:37, 16 October 2022 (UTC)

As for the particular article on hand; I'll probably try my hand at rearranging images tomorrow (though without bringing all of them into a single section creating a wall of pictures), if anyone else doesn't beat me to it. Note that what I did was (mostly) reverting the order of images to an older version (that I took no part in initially creating) I found more in line with the image policy, and honestly more aesthetically pleasing. The "sleep humour" is just my interpretation — I don't really know if the original contributor had that idea in mind — and was offered as an example that each and every image doesn't have to perfectly align with the listing describing it. Out of the descriptions, I gather that the Great and Grand Theatres are the same place.

As for the general guideline; I would support clarifying it further by adding something in line with your suggestions (varying distance between groups or individual images, and varying sizes for a livelier layout). Commenting out the line break should probably also be added to the policy (and perhaps to WV:Accessibility) for accessibility issues. Vidimian (talk) 20:50, 16 October 2022 (UTC)

Varying sizes are a difficult art, and I wouldn't want to recommend it in the guideline. Here smaller images would help with the problem with a wall of images (as there would be more space between them). I think varying distances is something that should preferably be recommended between the lines, I think i might be able to come up with some wording, but not tonight. –LPfi (talk) 21:25, 16 October 2022 (UTC)

Just a reminder, I never read a book where pictures belonging to a certain topic turn up arbitrarily throughout the book.

Furthermore, that conceived "wall of pictures" is only visible in that specific and rather less used view. It is not an issue in the mobile view, where it actually aligns nice with the listings. I have seen articles that are much worse with barely any text in the listings, where I would be totally on your side and prevent such stacking of pictures. But this is not the case here, where we have sufficient text so that pictures are aligned properly with their information. However, I would rather skip the specific listing images in exchange for images that belong elsewhere instead of distributing images without meaning throughout the article.

@LPfi: I like the idea with commenting out the line breaks or just putting the picture at the end of the listing, that definitely helps. Unfortunately, there is just too many rules and style guides around on WV that it is almost impossible to keep track of them all. I don't know how such accessibility feature can be applied consquently and consistently on WV, where many new editors do no have an idea of these. Especially when it say, "be bold in editing pages" ... that doesn't fit together with the reality here.

Last but not least, we also have to acknowledge that the only sections where generally pictures really make sense are the Understand, See and Do (and maybe Buy) sections. People looking into the Get in/around, Eat, Sleep, Cope, Stay safe and Go next sections are looking for hard facts not sugarcoated and fancy looking magazine text.

I think the latter is also an important point here. Do we want to win beauty contests with the articles or do we want to provide the travellers with the most efficient way to obtain useful information. I believe the latter is the case. However, I think the style guide is often written with such widely differing goals, which is why we end up in such discussions here.

@Vidimian: For the specific article I would suggest to just reduce the amount of pictures under See and have one or two (more) relevant pictures beyond See or in Understand.

Cheers Ceever (talk) 08:32, 17 October 2022 (UTC)

I use this site mostly on my laptop, not on my cellphone, but that said, there are definitely appropriate photos for other sections. "Get in" could have a photo of a railway station or airport, but it could also have a photo of a view of a city or something else that appeals to you such that you would want to get into that place. "Get around" could again have a photo of some form of transportation, or of a landmark. "Eat" could have a photo of a famous restaurant or a local dish. Etc., etc. But it's a problem when mobile and computer views are incompatible, and I don't know what the solution is. Ikan Kekek (talk) 09:46, 17 October 2022 (UTC)

Freedom of panorama under US regulations

English Wikipedia has the following template (Template:FoP-USonly) which allows global images of architecture under a US interpretation of freedom of panorama (images which would not otherwise be allowed on Wikimedia Commons). I was wondering if there was support for creating a template like that for English Wikivoyage as it is hosted in the United States. I understand that such images can be uploaded currently as fair use, but there are restrictions on fair use images which would not be present with this proposal. I'm interested to hear what people think. IronGargoyle (talk) 21:45, 22 December 2022 (UTC)

There may be problems with our international editor base (only a minority is based in USA, I think). Fair use isn't handled the same over jurisdictions, but it may give more protection than the US FoP clause (and people might know their own equivalent). The US FoP is probably irrelevant for a non-US editor, whose country is known (such that litigation is reasonably easy). What about me as an EU citizen if I work with French no-FoP images? Having articles about France that people in France cannot touch seems awkward. –LPfi (talk) 10:00, 23 December 2022 (UTC)

You're saying it's awkward for French users not to be able to sell images or use them in commercials when they are used here with a warning not to use them for commercial purposes? I don't understand why you think that's a problem. French FoP allows non-commercial use of images by individuals. See here. Ikan Kekek (talk) 10:16, 23 December 2022 (UTC)

I understand that you are frustrated by the copyleft ideology, but that is not what I am talking about. I say that if we use a photo of French architecture that is not allowed by fair use, then a Frenchman may not be allowed to touch that photo in the Wikivoyage context. As it is most likely used in articles about France, that's awkward. As EU citizen, I might be in the same situation as the Frenchman. I don't know the legal consequences, but I am afraid that my moving around images in an article about France may result in my getting sued. I would also be forbidden from printing the guide to give it to a colleague (although that would hardly be a legal risk). If so, I should check the file description page for every image I am going to do anything about (other than removing it), and every article I am going to share. –LPfi (talk) 10:29, 23 December 2022 (UTC)

What special building are you thinking of? From the link I posted above: "On 7 October 2016, the French parliament approved a law recognizing a limited version of the freedom of panorama that authorizes the reproduction by individuals (not organizations) of buildings and sculptures permanently located in public space, but only for non-commercial utilizations." Ikan Kekek (talk) 20:19, 24 December 2022 (UTC)

Road icons

Swept in from the pub

Do we have a specific policy on not using road icons in text, e.g., and in the Get in section of Mulkiteo? To me it seems to make reading our articles more difficult for sight-impaired people and for travellers with low bandwidth. Ground Zero (talk) 19:22, 25 June 2023 (UTC)

Minimal use of images is the most concrete mention of this rule that I know. Other than that, I am only aware of it being a stylistic choice. The MOS doesn't seem to include it, in any case. I know this policy was discussed several times around the introduction of {{Rint}}, but I can't seem to find those discussions anymore. #Using images, which is only tangentially related. ― Wauteurz (talk) 19:52, 25 June 2023 (UTC)

I assume that you mean Mukilteo. I think it has been discussed here in the past, possibly regarding their use for rail lines or other public transport routes. These are useful in the See and Do sections of an article to find other places to see that are on the same Subway line etc, and probably also in a rural area to find the sites on the same road. In the case of Mukilteo, the icons are not very clear for the 3 digit route numbers - I need to look very closely to see the difference between and . AlasdairW (talk) 20:44, 25 June 2023 (UTC)

We should not use images to replace text within sentences as is done at Mukilteo. This is bad for accessibility and will make the text incomprehensible for readers who read it without images (which sometimes includes me – I have a text-only version of Wikivoyage downloaded to my phone for use when I'm traveling without internet access). —Granger (talk · contribs) 21:10, 25 June 2023 (UTC)

While I'm okay with using templates in text-form (e.g. {{rint}} or {{AUR}}), this creates accessibility issues for users using screen readers. I would replace the route markers with text, which I'll fix right in a moment. SHB2000 (talk | contribs | meta) 22:25, 25 June 2023 (UTC)

Are those templates not providing alt text? WhatamIdoing (talk) 19:58, 26 June 2023 (UTC)

{{AUR}} uses text form as an alternate means of having routeboxes for Australian destinations (since route marks apparently fail c:COM:TOO Australia) and it would be a tedious job uploading (and also maintaining) 1000+ files locally. AFAIK, it should work with screen readers, but I'm not 100% sure. SHB2000 (talk | contribs | meta) 13:43, 29 June 2023 (UTC)

We certainly use {{rint}} a lot for metro lines in some cities, e.g. see Shanghai/French_Concession#Get_in, & that seems basically a fine idea. However I do not know how it affects screen readers. Pashley (talk) 12:38, 29 June 2023 (UTC)

Screen readers, for as far as I have tested, treat Rint labels as any other word in a sentence. Rint only prints pre-configured instances of {{RbE}}, which is nothing more than a few HTML elements (mostly spans) and some CSS styling. The only thing in Rint that tends to be lost by screen readers is the optional mouse-over or alt text detailing the transit service that the icon depicts. That information tends to be written in the Get-around sections though. ― Wauteurz (talk) 13:27, 29 June 2023 (UTC)

Deploying the Phonos in-line audio player to your Wiki

Swept in from the pub

Hello!

Apologies if this message is not in your language, Please help translate to your language to your language.

This wiki will soon be able to use the inline audio player implemented by the Phonos extension. This is part of fulfilling a wishlist proposal of providing audio links that play on click.

With the inline audio player, you can add text-to-speech audio snippets to wiki pages by simply using a tag:

<phonos file="audio file" label="Listen"/>

The above tag will show the text next to a speaker icon, and clicking on it will play the audio instantly without taking you to another page. A common example where you can use this feature is in adding pronunciation to words as illustrated on the English Wiktionary below.

{{audio|en|En-uk-English.oga|Audio (UK)}}

Could become:

<phonos file="En-uk-English.oga" label="Audio (UK)"/>

The inline audio player will be available in your wiki in 2 weeks time; in the meantime, we would like you to read about the features and give us feedback or ask questions about it in this talk page.

Thank you!

UOzurumba (WMF), on behalf of the Foundation's Language team

02:26, 27 July 2023 (UTC)

I think we want to do this, especially for the phrasebooks. Who has the necessary user rights to enable it? WhatamIdoing (talk) 17:13, 28 July 2023 (UTC)

Links to external Photography Gallery?

Swept in from the pub

I would like to find a way to link to some of my external photo galleries of my travels. I do understand that this is frowned upon, since its not all contained within the Wikivoyage bubble. However in terms of meeting the "traveler comes first" prime directive, I know for me, being able to see photos of a possible destination is very helpful. I am a retired photographer, and take a LOT of photos when I travel, that many end up in my non-monetized retirement blog. It would not be practical or desirable to upload all these into Wikicommons.

Here is a basic example of a tagged section of one of my blog articles, that is a bunch of restaurant photos. Panama - Beautiful Mountain Town Of Boquete - yesRetired, restaurants. There are other sections in the same article for sleeping, hiking, etc.

Perhaps a category of links similar to adding restaurants and hotels, where "appropriate" non-monetized photos that are directly related to the article would work? Robvann (talk) 13:00, 13 October 2023 (UTC)

Hi Robvann, it's an interesting question, and I can understand why you'd be proud of the pictures you take, but I really doubt most folks on Wikivoyage will want to set a precedent for something like what you're describing. Most important is that the site is collaborative and the photos that are used should be uploaded without copyright or with a creative commons license so that they can be reused by others. That's the spirit of sharing, not linking to a place where you keep ownership and control. When you link to a site like that, you're not really sharing, you're trying to drive traffic for your own benefit (whether or monetary or not). That's not a whole lot better than a tout who comes here posting links and "rave reviews" of their only marginally interesting business. I hope you'll continue posting useful content about places in Panama, but please, no links to blogs or personal photo galleries. Regards, Mrkstvns (talk) 15:03, 13 October 2023 (UTC)

Why don't you upload some photos to Wikimedia Commons? It needn't be all or nothing. Just upload the photos you want to upload. Ikan Kekek (talk) 18:23, 13 October 2023 (UTC)

Yes, I have uploaded a few anchor photos, but the general philosophy here seems to be fewer photos is better. Unfortunately as a visual artist this aspect contradicts my general approach to looking for new travel destinations. I assume other travelers also appreciate a way to see relevant photos of a given place and category. I have lots of great content that is easy to add via a simple link as per the example above which has 12 photos for that one place and category. I have over 500,000 photos in my portfolio... so it seems like an opportunity missed for the travel audience here. Robvann (talk) 18:54, 13 October 2023 (UTC)

Commons doesn't have a philosophy of "fewer photos is better." They don't want photos that are all but dupes, but otherwise, anything that could reasonably be useful to any wiki project is welcome! Ikan Kekek (talk) 19:10, 13 October 2023 (UTC)

Perhaps there is leniency there. This page is where I got that idea. Wikivoyage:Image policy – Travel guide at Wikivoyage

• Short articles (less than 3,000 bytes) should usually have no more than 1–2 images, including a map.
• For longer articles, 1 image per screen (1,000–2,000 bytes) is generally adequate.

Robvann (talk) 19:45, 13 October 2023 (UTC)

commons.wikimedia.org is a repository of images. Have a look at c:Commons:Welcome. Ikan Kekek (talk) 23:02, 13 October 2023 (UTC)

There is a link at the left side to Commons if there is a category that matches the article. So readers will get the chance to see all your photos of a city on Commons. Commons is happy if you add 500 photos of one city, preferably not all of the same view. As an extreme example, see Commons:Category:Exterior of Elizabeth Tower where there are 1,139 views of the one clock tower, and within that 261 views of the Big Ben clock face. AlasdairW (talk) 23:08, 13 October 2023 (UTC)

Thanks. This turned out to be better that I thought. I really like the "slideshow" button that is available and was able to add it to the bottom of a Wikivoyage page as a photogallery (in Boquete). Now to see if that is considered to be ok... Robvann (talk) 12:07, 14 October 2023 (UTC)

@Ikan Kekek:, I hope you don't mind that I reformatted your links so it works better on mobile. --SHB2000 (talk | contribs | meta) 23:11, 13 October 2023 (UTC)

Of course I don't mind. Thank you! Ikan Kekek (talk) 02:06, 14 October 2023 (UTC)

For popular destinations, the Commons categories are often not very handy to get to the most relevant images. The way to come around this is to create what you said – a gallery – on Commons. Categories have made many galleries obsolete, but a well-designed one is still appreciated, and if it is linked at Wikidata as the Commons equivalent to a Wikivoyage page, that gallery will be the primary target of the left-margin Commons link. An example would be Winter driving/Commons:Winter driving. –LPfi (talk) 07:22, 14 October 2023 (UTC)

Another example would be Turku/Commons:Turku, which is about a city (scroll down to the photos). –LPfi (talk) 08:25, 14 October 2023 (UTC)

Wow I didn't realize you can create information pages in the WikiCommons area. That is a good example.

Ideally, it would be nice if it was ok in Wikivoyage to make an obvious visual link to be clicked on (like: Click here to see a Gallery of related photos). Currently the end user needs to just know that if they click on the WikiCommons link in the Other Projects section that they will see related images. My 86 year old mother would not figure that out. Robvann (talk) 17:32, 18 October 2023 (UTC)

What about reviving the idea of Template:GalleryPageOf? Was it shut down by the WMF or did it just never get used? PragmaFisch (talk) 14:30, 18 October 2023 (UTC)

As galleries are accepted at Commons, I don't see the need for such pages here. If there are issues, I trust they can be dealt with. Is there something the Commons galleries wouldn't handle? Ah! FoP issues. Let's see whether those are severe. Is it enough to include the most iconic no-FoP sights in the article proper? –LPfi (talk) 17:05, 18 October 2023 (UTC)

It does look like there was a vision at one stage to have a way to link to Galleries from withing Wikivoyage. Not sure the date of the "experiment". Robvann (talk) 17:34, 18 October 2023 (UTC)

The template seems to have been created in April 2013‎ (the WT/WV fork was finalised three months earlier). I don't know how much the community knew about Commons at that time. –LPfi (talk) 08:55, 19 October 2023 (UTC)

Picture format

Swept in from the pub

Images are important to the readability of WV. A good size for the majority of pictures is 300px, and this is widely used, but some contributors prefer “default” with no px size set.

I therefore compared images as viewed on an office worktop, a laptop, a tablet and a smart phone. I took the example of Lanzarote as displayed on WV, Wikipedia, Jet2 and TUI – these two are the leading providers of holidays to Lanzarote so their brochures are likely to reflect good practice. Jet2 appear to be at 300px and TUI at 250px.

The results were consistent: images at 300px worked well on all devices. They loaded quickly, were clear and eye-catching, and did not crowd out the text or distort the page balance.

Default images were never better, but acceptable provided the image was intrinsically bold and the display size was not less than 250px. For instance the pic of Lagomar is bold and still works, whereas Cactus Garden is a great pic at 300px but loses its wealth of colour and texture at 250px.

Some default images on WV were smaller, down to 150px, and these were just miserable postage stamps that threw away all their impact. All smaller formats had the problem that greater gaps between pix gave the page a slabby stodgy appearance.

These results were confirmed by a couple of colleagues “blind”, unaware of my own preferences or input to the pages.

Could advocates of “default” please explain the circumstances in which those images show to advantage? Otherwise I recommend 300px as the size to specify for most. Grahamsands (talk) 19:55, 9 February 2024 (UTC)

I never set a size because I assume the default is the preferred size. If 300px is better, can we change the default to 300px, instead of changing every picture? Ground Zero (talk) 20:31, 9 February 2024 (UTC)

Remember that pictures have to be public domain (or your own work given to public domain). For significant locations such as Paris then it isn't a problem to find images of high resolution, however some small town in Nebraska or a tiny island in Japan may have very limited pd images. Question is, are these 'postage stamps' a worse reader experience than having none at all? Andrewssi2 (talk) 20:45, 9 February 2024 (UTC)

(Technically, images have to be "free". Public domain is a specific, narrower concept in copyright law.) WhatamIdoing (talk) 17:16, 10 February 2024 (UTC)

I agree 300px is better – 250px is far too small to read. --SHB2000 (talk | contribs | meta) 21:55, 9 February 2024 (UTC)

The problem here is that the WMF denied us a change of site-wide default. Users can set their default to 300 px, but that doesn't help non-logged in readers, or those that aren't aware of preference options. The rationale was that the WMF doesn't want to cache multiple sizes according to whims of different projects, and doesn't want to special-case us. I think allowing one more default size would be no issue, but I am not sure the time has come to re-raise the request. –LPfi (talk) 09:30, 10 February 2024 (UTC)

We can unilaterally change policy to by default explicitly use 300 px. The downside is, in addition to oddness in the transitional period, that users who have set their preference to, say, 400 px will then get the same 300 px. –LPfi (talk) 09:34, 10 February 2024 (UTC)

I don't know how the feature for image size in preferences came there, but the makers of the Wiki-software must have reacted to signals coming from users who wanted some control over the size of the images. With "traveller comes first" we should also respect the size preference of the users. So I think we must not force 300px images upon them when another size is their preference. Exeptions sould only be made for images that contain text that must be legible when it is displayed in the article and clicking it to enlarge is not wanted in that situation; maps are an example of such images. --FredTC (talk) 11:21, 10 February 2024 (UTC)

@LPfi, when did we request the site-wide change? This is a small wiki. They shouldn't care. WhatamIdoing (talk) 16:56, 10 February 2024 (UTC)

They were worried that it would set a precedent. I think it has been discussed several times and there are several discussion not directly involving Wikivoyage. I don't find the discussion I tried to find, but Wikivoyage:Travellers' pub/2013#Can we make image defaults bigger now? points to phab:T49332, with some of the reasons for turning this down. Setting a global default of 300 px has been suggested, and in phab:T69709 ("eternally stalled") TheDJ writes:

"I propose we just have this sit around until someone comes asking again, and then we point them here, saying there is no technical reasons not to do it, only political and that if they show us something that resembles a community agreement _across_ the wiki's, we will deploy this."

That seems to be where this is standing: too big a mess for anybody in the tech teams to want to take the initiative. The default image size in MediaWiki seems to have been changed to 300 px.

For getting this forward, note the "across the wikis". en-wp seems to have rejected the proposal (in 2014) in a confused discussion ending in "no consensus": w:Wikipedia:Village pump_(technical)/Archive 128#Time for the semi-annual enlarging of thumbnail images.

–LPfi (talk) 18:50, 10 February 2024 (UTC)

To clarify, I am not advocating for 300px to become a new default. Apart from the technical difficulty, there are bound to be too many exceptions where that size is unwanted. My proposal is that 300px can and should be specified for the majority of pictures, because they look good and because "default" looks worse. Please state circumstances in which they don't?

I am left behind by the discussion about "preferences" because in my user area I can see a button to change my gender, which could save a lot of bother at the dysphoria clinic, but nothing referring to image sizes. And IMHO it is the very opposite of TTCF to say that's what folk should do. It drives away the casual reader, tomorrow's contributor, who stumbles upon WV and needs to be grabbed by powerful images and engaging informative text. Does TUI or Jet2 or any other travel mag tell me I must sign up to something and turn somersaults to render their brochures attractive? To insist upon such a process is to empower only a signed-up WV brotherhood while offering the real world out there a poor product. Grahamsands (talk) 14:06, 11 February 2024 (UTC)

@LPfi, that Phab task was ten years ago. It's okay now. Big wikis require some thought and advance work, but small wikis are just a matter of flipping a switch. (See, e.g., the comment from @Jdforrester (WMF) in phab:T355914#9494792 that "small wikis can get away with this").

Graham, if 300px should be used for the majority of pictures, we should make that the default, and specify a different size for the ones where it doesn't work (if any). Any logged-in user can change the setting for themselves at Special:Preferences#mw-prefsection-rendering-files (the "Thumbnail size"). The problem we want to avoid is:

1. We agree that most images should be 300px.
2. We decide to leave the default at 220px, and manually override the default for most images.
3. A logged-in user has picked a non-standard default (e.g., the biggest size because of visual impairments, or the smallest size to save bandwidth).
4. But they get 300px on most images anyway, because we are manually overriding their chosen settings.

The better approach is:

1. We agree that most images should be 300px.
2. We change the default to 300px, although there are a few images for which we decide to manually override the default setting.
3. Almost everyone sees 300px, and we don't have to do any extra work to specify the size of each image. But if you picked a different size, then you get your chosen size on almost all images.

WhatamIdoing (talk) 22:21, 11 February 2024 (UTC)

Okay, sounds like that would achieve the objective, that non-signed-in readers automatically see images at a good size. So if it is nowadays technically simple and has no serious side effects then I support. But to check on the latter point, could those who have set a user preference please state their chosen size, and their reasons for it? Grahamsands (talk) 14:09, 12 February 2024 (UTC)

Normally I use 120px, but occasionally 400px.

• The 120px is what I standard use when I access an article direct at the website (not PDF of printed), which I call interactive use. In that case the 120px size photo's, as small as they are, give me a good idea of what is on the photo's and of which ones I want to have a closer look by clicking them.
• I use 400px only if I look together with 1 or 2 others to the article on my laptop screen and there s a need to see the photo's an not read big parts of the text. I also tried 400px when doing an export to PDF but that did not result in bigger photo's in the PDF.

btw, I just checked the 400px with the PDF export on the Penicuik article to be shure that what I wrote above is still true, and I noticed that the balance between text and photo is about ⅔ text an ⅓ photo for 250px (and no px specified) photo's, which is ½ text and ½ photo for the 300px photo's. For me the ⅔–⅓ balance looked better, but that is a matter of personal taste. --FredTC (talk) 02:16, 13 February 2024 (UTC)

Nice to hear. It seems I searched in the wrong way – and there should probably be better practices to make finding such chances easier. I myself usually use the default, on Wikivoyage to see what most readers see, on Wikipedia because I am more interested in the textual content than in the illustrations (which is true also here). On a slow connection, I often click stop before the images have loaded, when I suppose I already got the essentials. One thing that is irritating is static maps or in-image legends being fuzzy enough to be unreadable, probably because of an unlucky resizing ratio. –LPfi (talk) 09:51, 13 February 2024 (UTC)

As there is no objection to setting default = 300px, and we're told no technical barrier, can this now be actioned? Grahamsands (talk) 17:50, 14 February 2024 (UTC)

If default= 300 px cannot be implemented for whatever reason, I go back to my original proposal, that this size is specified for most pictures. It appears that only a few users would have minor inconvenience from this, and it would much improve the reading experience for the majority. Grahamsands (talk) 11:15, 19 February 2024 (UTC)

I see no objection against changing the default to 300px, so we could ask for it and leave any discussions for the case it is denied. One thing to look out for are images with "upright=1.5" or the like, which may get too large with the new default (I found 123 searching for 'insource:"upright=1.5"', 197 for …=2, which includes 2.5 & al, and 5 for …=3, including this). I tried to look for how this works out with "?useskin=vector-2022" added to the page URLs, as the line length is restricted in that layout (or so I have understood), but did not get any comprehensible results. –LPfi (talk) 12:32, 19 February 2024 (UTC)

Okay, so what is the lever to pull to launch this request? I've not been involved in a system tweak before. Grahamsands (talk) 21:08, 19 February 2024 (UTC)

Tracked in Phabricator ^(?)
Task T357943

I filed a request. On the technical side, there's no significant barrier. We are a tiny fraction of the pages the servers parse, and a tiny fraction page views. However, the English Wikipedia has made a similar request, which does involve substantial technical barriers, so there's a chance that they'll block everyone else while they worry about enwiki. Even if they had unlimited staffing resources, enwiki's problems would take a few months to solve, and doing it right would probably take a few months more than that (because pre-generating tens of millions of thumbnails doesn't happen instantly). WhatamIdoing (talk) 00:11, 20 February 2024 (UTC)

Many thanks for that. We can but hope. Grahamsands (talk) 16:39, 20 February 2024 (UTC)

Video

Swept in from the pub

Hey All, We at Wiki Project Med have build a tool to create short clips zooming into specific locations in the world, as part of our VideoWiki effort. Not sure if some folks here have an interest in creation videos. Here is an example of one of the videos made with this tool. Additionally we are having a meeting about video at Wikimania 2024. Travel Doc James (talk · contribs · email) 12:20, 15 July 2024 (UTC)

We have generally thought that videos are too difficult to make well for them to be useful here. For me, I think a video zooming in on a map is less useful than the dynamic map centred on the location, where I can zoom in (and out) at my own pace. Also the tuberculosis video linked as example would work better for me as just audio: I had difficulty following the speech while something was happening in the animation.

People differ, of course, and one doesn't need to play a video just because there is a link. It would be good to see examples where the videos really are worthwhile for at least some people.

–LPfi (talk) 12:58, 15 July 2024 (UTC)

I think one of the big difficulties with videos is providing for a wiki friendly way of editing them. If we have a text guide to a city, it is easy for any editor to make a small change to say that the museum now is closed on Wednesday, but it is much harder to do that with a video without the edit sticking out (different voice?). It is hard to provide an easy way to insert the extra or replacement words at exactly the correct moment. If I look at a city guide, it is not immediately obvious whether I am looking at the work of 3 editors over 1 month or 30 editors over 15 years, but unless there are really great tools to support co-operative editing a video updated by 30 editors will be far too jumpy. How will other editors review changes to see that touts haven't plugged their wares without re-watching the video?

Very short videos may be useful for some instructional matters, to explain things that are hard to put into to words - maybe how to eat with chopsticks, or open an unusual train door. AlasdairW (talk) 20:41, 15 July 2024 (UTC)

The videos are compiled with text to speech. Thus one can change a single word and easily create a new version. VideoWiki basically allows easy collaborative video editing within a mediawiki. Travel Doc James (talk · contribs · email) 23:19, 15 July 2024 (UTC)

I find that video size is the Kryptonite of any videos. Compress the file size too much and the video becomes too blurry to be useful. Keep the video high quality and it takes a long time to buffer (sometimes won't even load in remote places). OhanaUnited^{Talk page} 15:02, 16 July 2024 (UTC)

The size of the images with thumb and no px is wrong

Swept in from the pub

Tracked in Phabricator ^(?)
Task T375981

I noticed that the images in an article generated with [[file:filename.jpg|thumb|caption]] (no px value) results in a much bigger result than my 120px preference. However, when I'm viewing the result (Using the "Show preview" button) while editing, the size is correct. FredTC (talk) 07:24, 27 September 2024 (UTC)

I have no experience with Phabricator, so I don't recognize what is done to the problem now. Could someone explain? --FredTC (talk) 01:45, 14 November 2024 (UTC)

Well, on the 3rd of October someone put the ticket in the "Phase 5: Later" category. You can look at the current Parsoid workboard and see what tasks Phases 0-5 contain, and how many of them are resolved... Let's hope they are not working on them in strict phase order. Daggerstab (talk) 07:03, 14 November 2024 (UTC)

@FredTC, in Special:Preferences#mw-prefsection-rendering, what's your skin setting in the first section? And you have 120px set in Special:Preferences#mw-prefsection-rendering-files? Do you have anything set in Special:GlobalPreferences#mw-prefsection-rendering-files ? WhatamIdoing (talk) 19:43, 27 September 2024 (UTC)

@WhatamIdoing, My skin is "Vector legacy (2010)", but for this problem I also tried it with "Vector (2022)". The problem occurred with both skins. I have 120px at "Thumbnail size". The problem also occurred at nl:Wikivoyage, but not at Wikipedia. I have nothing set at "Global preferences". FredTC (talk) 06:56, 28 September 2024 (UTC)

What's the "correct" size? I think it is better that when editing, you see images at the size people with default settings will see. Your personal preferences should not affect what image size you choose when editing. –LPfi (talk) 09:28, 28 September 2024 (UTC)

@LPfi: I think the idea of having image sizes as for users with default settings and not logged-in users (when editing), would be a good idea. So, that is exactly the opposite of the situation now. --FredTC (talk) 04:02, 30 October 2024 (UTC)

When I have this [[file:filename.jpg|thumb|caption]] image, it displays incorrect like a [[file:filename.jpg|thumb|220px|caption]] when I read pages, having "Thumbnail size" set at 120px. When I edit such a page and use the "Show preview" button, [[file:filename.jpg|thumb|caption]], displays correct like a [[file:filename.jpg|thumb|120px|caption]]. Correct displaying also happens when I compare versions using "View history". I think 220px is the size that is used for not logged-in users. The problem started happening just 1 or 2 days ago. --FredTC (talk) 10:12, 28 September 2024 (UTC)

It was probably Wednesday's update. Ladsgroup, do you know what team this would be? (Your work account hasn't been here, so I'm pinging your volunteer one.) WhatamIdoing (talk) 19:39, 28 September 2024 (UTC)

That Wednesday is now 3 weeks ago. It is still not working correct. Using the "Switch to legacy parser" link makes it OK. So, the new Parsoid parser must be the problem. FredTC (talk) 12:03, 16 October 2024 (UTC)

And another 2 weeks later, nothing happened. This cannot be such a great problem that it takes so much time!? FredTC (talk) 01:31, 30 October 2024 (UTC)

A few days ago I could change a preference, and now things are the way I like them to be. But very strange, for this read problem, I had to change an edit preference!!! FredTC (talk) 11:08, 25 November 2024 (UTC)

@WhatamIdoing and @LPfi This is very very likely because of Parsoid for read project. I'd say create a ticket and tag "content transformers" team and Parsoid. Ladsgroup (talk) 11:28, 29 September 2024 (UTC)

Done Thanks for the advice. WhatamIdoing (talk) 18:25, 29 September 2024 (UTC)

Recall that we agreed to change the default to 300px. This Phabricator request T357943 has stalled. Grahamsands (talk) 20:42, 29 September 2024 (UTC)

Linking phab:T357943 for recordkeeping. --SHB2000 (t | c | m) 22:36, 29 September 2024 (UTC)