This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

We've had this discussion several months ago, but as per this discussion, I am making an attempt at reviving this discussion. This time, though, I have done some more research into the symptoms:

Firstly, to recap, currently the page previews on Wikivoyage have the issue of wanting to fetch preview images from listings (with or without Wikidata IDs linked) rather than the article itself, which is far from ideal, as evidenced by some of these articles:

• Washington D.C. - unrecognisable and non-representative landmark,
• Amsterdam/Zuidoost - picture of historical event (Bijlmerramp). The sight of a cargo plane bored into a apartment building is far from appealing to anyone, let alone representative of the district,
• Haarlem and Alkmaar - pictures of the train station, which are unrepresentative of the destination,
• Hilversum - picture of Hilversum Airport, which isn't useful for many travellers, since it is a training ground and private airfield.

You barely have to try to run into bad images, is the point. Browse for a bit and you'll find them easily.

Secondly, how do these images make it into the preview? Well, Page Previews, which creates these previews, isn't at fault, it is PageImages instead. It's scoring for images is favoured towards Listings and Markers, especially those with an image that can be fetched from Wikidata IDs linked within said listing. The images added in the source code itself, the ones the reader always gets to see, and which are picked to be representative, are somewhere way down the scoring list. The only images with worse scoring seem to be pagebanners, which are blacklisted all-together. I can't exactly point at a certain part of the extension and say that it is at fault, since my ability to read the code is lacking, so perhaps someone else may be able to point that out.

Third, what can be done about this? The easy option is of course disabling Page Previews, but I'm out-ruling that as an option because all in all, it's not a bad feature, it's just badly optimised for usage here. Also out-ruled is manually going around articles to make sure they display useful images, for the simple reason that we editors have many better things to do. Much more plausible by my judgement would be either only fetching images from the lead section (described here) or reaching out to the developers of PageImages to explore the possibilities of optimising the extension for usage here. I've also explored the possibility of adding an empty {{marker}} in the lead section of articles to bump its priority, but that went without success. Making a template of sorts to force a certain image therefore isn't a very plausible approach.

What I'm looking for here is a consensus on what images are desirable: Only those defined and visible in the article? Those of listings as well, and if so, which types of listings? Et cetera. After that we can discuss our actions. Do we change the way PageImages works here by changing its settings, or do we ask for changes to its code and inner workings, or do we simply disable the extension here? All in all, a discussion on this topic is much needed. I'll be here to answer any questions you may have to the best of my abilities. Thank you in advance.
-- Wauteurz (talk) 20:07, 10 January 2019 (UTC)[reply]

Why not pick up the first image listed at the articles Wikidata? Either change the PageImages code or I was also thinking of placing a small collapsed icon of {{Wikidata Infobox}} at the top of pages. Maybe that would force a better image. --Traveler100 (talk) 20:46, 10 January 2019 (UTC)[reply]

If I was selecting the image manually, the first place I would look is the image which was cropped to create the banner image. My second choice would be the banner image, or possibly the left half or third of the banner image if a taller image was wanted. A well chosen banner image reflects the character of the destination. It is also an image that the reader will see then they go to the article page, and so can be useful if the reader is unsure if they have already looked at that page. Banner images are all at least 1800 pixels wide and so we can be sure that they have enough resolution, and with few exceptions are of good enough quality. After that I would prefer using an image that is in the article, ideally avoiding those in Get in and Get around, which includes maps and photos of airports. I would avoid using images which are not displayed in the article. AlasdairW (talk) 21:34, 10 January 2019 (UTC)[reply]

Thanks to Wauteurz for taking the time to do some research and write all this out for us. To answer the questions you posed in the final paragraph, for my part, I think only images with are visible in the article should be used, for the reason that at least then an image a Wikivoyager has chosen will show up on the preview, rather than being something which almost seems randomly generated. I also think we should "ask for changes to its code and inner workings"; disabling what ought to be a useful extension should be a last resort if the developers of PageImages can't or won't help us.--ThunderingTyphoons! (talk) 21:46, 10 January 2019 (UTC)[reply]

@Traveler100: That would be an option, yes, but I didn't find anything that suggested that PageImages supports that as-is. I figured it'd be easier to work with what we have, and if none of the options we have available out of the box suffice, we can reach out to PageImage's developers. I have no prior experience with extensions, so I don't know if every project would be able to change the entire extension to fit its needs. If anyone wants to inform me on that, then that would be much appreciated.

Fetching the article's associated Wikidata ID's image may just work in theory, since the images for cities and towns on Wikidata are generally fetched from Wikipedia, which will have a decent image most of the time. The question then is if the infobox gets picked up by PageImage. The easiest way to find out if the result for the previews is as desired, would be to put the template in a handful of articles that have 'bad' preview images and see if anything changes. You've got my support to give it a shot.
-- Wauteurz (talk) 22:00, 10 January 2019 (UTC)[reply]

@AlasdairW: Reusing the banner images won't be a great solution. Since the banners have a 7:1 ratio, and cropping that to 4:3 or whatever the preview uses would break off a lot of the banner. Besides, some banners are oriented to the left, the right or centre of the image. We'd have to manually set the center of the banner (which is a feature, albeit a little used feature of the pagebanner) for every one of the ~15.800 custom banners. Using the banner's source material would be my preferred way of action in that scenario. Nonetheless, it might also be possible to make the preview shorter in height and force it to use the 7:1 pagebanner. I am hesitant to say that maps are a good alternative. Look at the Achterhoek, for example. It has no listings, no images in the lead section and thus defaults to the region map, which doesn't look appealing. Maps don't show much aside from some infrastructure and cities and towns. As for airports, they don't do the article justice if you'd ask me. Taking Amsterdam for example, you're seeing Schiphol in the preview, instead of the UNESCO-listed canals and city centre, which would be a lot better to show.

I fully agree that we should use images that editors on Wikivoyage have added, preferably images that can be seen when the reader reads the article (so excluding the hidden images in the listings and mapframes). I think that is something we can all agree on.

Just to put it to words, my preference goes to in-line images (thumbnails) in the first place, followed by editor-defined or editor-redacted images in listings (so ones where the image parameter is filled in), followed by banner source material, followed by no preview image at all. The easiest way to achieve something like this is to adapt the scoring system of PageImages to retract 100% of the score for listing images and images or maps in {{regionlist}} and similar templates (to be clear, I don't know whether it is possible or not for individual projects to change said scoring system), or to set $wgPageImagesLeadSectionOnly to true, meaning that only thumbnails in the lead section get used (which I know for a fact is possible for one of our administrators to change).
-- Wauteurz (talk) 22:00, 10 January 2019 (UTC)[reply]

Sorry if I wasn't completely clear. I would like to use images displayed in the article, except those in Get in and Get around. That would usually exclude images of airports and stations which appear in Get in, and exclude maps which are usually in Get around. That would mean using images in See or Do if there aren't any in Understand. I am thinking of city articles here, and some other sections may need to be excluded for other articles. AlasdairW (talk) 22:53, 10 January 2019 (UTC)[reply]

That sounds sensible. I think the image should be visible in the article, not to cause confusion. If the pagebanner source image could be fetched it would probably be a good choice in most cases, but that would probably involve some coding and perhaps a link as a pagebanner template parameter. Without such an explicit reference there could be some weird results (the cropped-away parts can be anything). Ideally you would be able to specify the preview image manually. Using the first image (usually in Understand) should be straight-forward, but I haven't read the code. Avoiding some sections would require some parsing, which probably hasn't been coded. --LPfi (talk) 23:03, 10 January 2019 (UTC)[reply]

I think, generally, as LPfi says, we should go with the first image of the article, which should be fairly easy to code. So I'd support a change, if possible (which it seems is possible).

P.S. Sorry for changing my signature again. I am finding the olive color overwhelming, so I have changed it back to blue. --Comment by Selfie City (talk | contributions) 02:39, 11 January 2019 (UTC)[reply]

@AlasdairW: You were clear on that, I just read over it. The problem with taking images from See, Do and other paragraphs like it is that listings linked to Wikidata don't always have useful imagery linked in Wikidata. The previous discussion even came to be because of such a listing.

@LPfi, SelfieCity: Understand doesn't always have images, and neither does the lead section before it. Where such a method of fetching the images would fix Sierra Nevada, it wouldn't improve Lake Tahoe since the latter has no images in these sections. Yet I support this method more than anything because we can, with relative ease, get a bot (or perhaps a petscan) to find articles without images in the lead or Understand, and organise a CotM (or a goal for 2019 if there are loads upon loads of such articles) to get images into these sections.

If we are able to configure the scoring system of PageImages, then perhaps it may be worthwhile to blacklist images used in {{listing}}, {{marker}}, {{regionlist}} and the like, and instead score images based on their order in the article, with, if possible, bonuses for images that were previously featured on Commons or ones with quality tags. Looking at some examples, I came to the conclusion that perhaps we should just blacklist all templates if possible, since getting the checkmark in nominated articles for FTT, DotM or OtBP to 'represent' articles is far from desirable. Anywho, this scoring method would ideally score the images in Rail travel in the Netherlands by their appearance in the article, and thus fetch the picture of Amsterdam Centraal, which would have a bonus for being a Quality Image according to Commons. Perhaps a template for modifying the score to allow editors to have more control over what images appear may be useful, but let's not think that far ahead just yet.

If I am not mistaken, then I am seeing an overall tendency to want images from the lead section and/or Understand. This, as I said previously, should be configurable for our admins and/or bureaucrats by setting the parameter $wgPageImagesLeadSectionOnly to true. I'm holding out on starting a vote for this since there are plenty of more options, and I'd like to hear some more Wikivoyagers leave their ten cents on the matter, so that we can eventually vote on a set of several methods. At that point, it may also be worthwhile to get some people from MediaWiki responsible for the PageImages extension in here to guide us towards a good choice.
-- Wauteurz (talk) 10:55, 11 January 2019 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘I agree about your thoughts on a possible COTM, etc. --Comment by Selfie City (talk | contributions) 23:36, 11 January 2019 (UTC)[reply]

If we go the route of adding image to the Understand section, or before the Get in section if does not exist, I am not sure how we can easy track the progress of such a project. On initial look I cannot see a way of restricting an advanced Search or a Petscan to a section of an article. Any one any ideas or tips? I could see a possibility of running a bot over pages and tagging them but then there is no guarantee of being removed. --Traveler100 (talk) 07:45, 13 January 2019 (UTC)[reply]

Neither am I, really. As I mentioned in my reply to your question below, the API Sandbox may be a method of finding that out, but that would mean that a bot would be needed to find and tag these pages rather than a PetScan. Only once a page has been tagged with a template (let's say {{NoImageInLead}} for further reference) is when we can find those articles more easily using a PetScan. I don't think we could do the same process without involvement of a bot.
-- Wauteurz (talk) 12:06, 13 January 2019 (UTC)[reply]

Question - Does the size of the image displayed on the page (not its actual size) make a difference to the ranking? It would be possible to place a small image at the very top of the page (not easily seen) with an extension to the {{geo}} tag that is already in all articles. This would then be the first image in the article and could be by default the wikidata standard image or you could add an image file name to the geo template to define another one. --Traveler100 (talk) 08:15, 13 January 2019 (UTC)[reply]

Not understanding the PageImages calculation. For example the first image in the article Ohrid is same actual size as the one in the airport listing but is still not the selected preview image. --Traveler100 (talk) 09:38, 13 January 2019 (UTC)[reply]

@Traveler100: In short, yes, the size of images matters. I never fully understood how the scoring works myself, but from what I gathered, I have a decent idea of the scoring system, albeit that I don't know what numbers the scoring applies:

• Anything smaller than 119px or whatever is defined in $wgPageImagesScores['width'] is highly favoured against and anything inside of a <gallery smaller than 100px is ignored. Since we don't use galleries, small images on Wikivoyage (say, for example one 50px wide) will still get considered.
• 400-600 pixels is the width the template searches, with a preference towards the lower bound - In other words, 400px is ideal, anything up to 50% wider is still acceptable. I am not sure how a 400×600px thumbnail of a 4.000×6.000px image gets favoured in this, but I think the thumbnail is fetched from the article as is, meaning that the thumbnail gets fetched, not the original much larger image.
• The first four images in an article get considered, unless that number is changed with $wgPageImagesScores['position']. I suspect that in one way or another, be it the rendering order of articles, map-frames or listings, the images in listings, which are causing the most issue on Wikivoyage, get seen as having a higher position because of being rendered first. This would explain why Ohrid has its preview image, but I am only speculating here. I couldn't say that this is why with any certainty.
• Lastly, the ratio of the image is considered. Anything wider than 2:1, such as our page banners, gets automatically discarded or highly favoured against. I am not sure if this also goes for portrait images which are, say, 1.500×500px, since documentation doesn't explicitly say so, but let's assume that they are. In that case, anything wider than 2:1 or taller than 1:2 is ignored. Again, this ratio (0.5 by default) can be customised with $wgPageImagesScores['ratio']. This would not mean that anything wider, like a pagebanner, would get preference, but merely adjusts the bounds of what gets considered.

I did my best to make the given explanation on PageImages' documentation page more readable, but in case that didn't work, the original documentation can be found here. I am not sure if adding an image in {{geo}} would help, since I don't know what templates are and are not blacklisted. You could always give it a shot. It may not, since {{geo}} is one of the last templates in the code, and only visually the first template for a reader. Machines may read it differently because of how the article gets rendered. The only way to find out is to try, I'd say. Perhaps anyone with more experience with Wikimedia API can give it a shot, but it seems that we can work out what images get considered by using the API Sandbox. If anyone is willing and able to give that a shot, then have a look at PageImages#API and see if such requests can be done for articles on Wikivoyage.
-- Wauteurz (talk) 12:06, 13 January 2019 (UTC)[reply]

@Wauteurz: Thanks those comments helped me work out what is happening here. As you say listings are parsed first, but only listing with coordinates and obviously an image. So first 4 listings with coordinates and image parameters are candidates. --Traveler100 (talk) 12:27, 13 January 2019 (UTC)[reply]

You are right that geo template will not work, even adding a listing in the template that shows at the top is still regarded as the last image of the listings. So only way I can see to control this without change of wikimedia code is to have a listing with a coordinate at the top of every page, say showing town centre position. Not sure if that would be wanted. I think we need to ask the developer of the image ranker code to ignore listing images.--Traveler100 (talk) 12:50, 13 January 2019 (UTC)[reply]

@Traveler100: Precisely. If there are less than 4 listings with coordinates and images, the next candidates are the images in the article, more or less as they appear. Templates such as {{featurenomination}} seem to be either very negatively scored or to be blacklisted/ignored all-together. I haven't ever found that a featured article displayed the check mark in its preview. On the other hand, does it need to be blacklisted at all? The feature nominees have plenty of imagery to outrank that little check mark. I know that isn't very relevant, but I felt like I needed to rectify what I said before about that being a possibility.
-- Wauteurz (talk) 12:54, 13 January 2019 (UTC)[reply]

T213652 request to change ranking to put visible images before listing images. --Traveler100 (talk) 13:19, 13 January 2019 (UTC)[reply]

Post-Phabricator update

Here's an update from the Phabricator ticket: A method of letting contributors manually set the previewed image is already being worked on. As per Jdlrobson's reply on Phabricator, I am led to assume that the idea as we had in mind (being able to blacklist templates) is not feasible. Feasible alternative solutions for now are as follows:

1. Set the aforementioned parameter $wgPageImagesLeadSectionOnly to true, meaning that all images for the previews will get fetched from the lead section and only the lead section. Many articles have images, but not within the lead section, which would require a bot and a possible Collaboration of the Month to optimise. We would then manually work off the lists provided by a bot and add images where needed or set the same bot up to move the first image in the article to the lead section.
2. Switch around listings to have preferable imagery get fetched. We know that the images get fetched by their appearance in listings. Listing #1 will always be chosen over listing #3 if both have images. If listing #3 has a better image than #1, then we can switch these two around to get the desired effect. The main downside is that is will be a much more intensive process than the option above. Where I can see option 1 get resolved with a CotM, this one will probably need a Collaboration of the Year.
3. Do nothing. A solution that's good for us is already in the works. I haven't found an ETA for it though. The obvious downside is that we'll have to deal with the current situation for what can be anything varying from weeks to years.

It may be best to let things over on Phabricator unfold for a bit, after which we can seek some consensus on what we will do to resolve the issue as it stands now. Feel free to discuss the options above or suggest any new ones, or chime into the discussion on Phabricator as well.
-- Wauteurz (talk) 20:26, 14 January 2019 (UTC)[reply]

User:Wauteurz has done a great job of explaining how this works. When I proposed enabling the page previews feature, I did flag that we'd need to rethink out descriptions and images to support it, but I figured that was good for the project and a problem with editing we could solve.

I'd strongly advise, not setting $wgPageImagesLeadSectionOnly to true. This leads to I'd guess at least 70% of articles without an image. This negatively impacts page previews, mobile web search as well as external clients. We also have data somewhere that suggests that we get more interactions when images are presented alongside the link. I'd argue this is much worse than the status quo.

The algorithm that chooses an image is also very dumb. phab:T91683 has been proposed as a long term solution for dealing with these situations and is simply lacking some impetus to fix this which would help every wiki, but in the mean time, the best possible thing to do IMO is to make sure the first image in the article represents the article and is a suitable page image! This seems useful for page preview users and users entering an article for information! For instance, it's bizarre that Siem Reap contains no image of Angkor Wat, its most iconic sight, other than in the page banner. From my POV overloading the banners is problematic - it provides no caption for mobile users (you cannot hover over banners on mobile!) and will not render on clients who are not banner aware. Could we not setup a Page image expedition? I feel that would be lots of fun.

Frustratingly, in cases like Washington,_D.C. this seems to be the case - a picture of Abe Lincoln seems pretty iconic and relevant, but for some reason that's not being chosen as the page image. I'd love to tinker with that some more, to see why that's the case. That seems like a bug to me. Hopefully that would eradicate some of the bad page images we're seeing.

Jdlrobson (talk) 20:31, 14 January 2019 (UTC)[reply]

@Jdlrobson: I'm well-aware that I am not the only one with an opinion here, but $wgPageImagesLeadSectionOnly seems the best option to me. I am, however, very much in favour of an imagery expedition or Collaboration of the Month(/Season?) as I said before. A goal for such an expedition would be to get an image in every lead section, after which, we would ideally have a large majority of articles with images in their lead sections. Only once that has been achieved would I be in favour of changing $wgPageImagesLeadSectionOnly to true. I haven't been clear that that's the order I had in mind, I'll admit. Since phab:T91683 has already taken a few years and none of the goals have been ticked off, I would be more than content with achieving this goal by the end of the year or sometime in 2020.

I can report that the image for Washington, D.C. originates from the first listing in the article with coordinates: The Afghan embassy. It's not like the image gets fetched from a seemingly random place. Like you said, the algorithm isn't smart. I've already speculated before that listings get prioritized because they or the mapframe get loaded before the page content. I can't confirm any of this, but it may be worth looking into. On the same note, if the algorithm is that dumb, then why not rewrite it to differentiate images that are in plain sight (thumbnails, etc.) from the 'invisible' images (listings, etc.)? I may be massively oversimplifying the whole ordeal, but forgive me for I lack the technical knowledge. The coding and technological insight I learnt in school has long faded on me.

Anywho, I'm all for an image expedition, but I'd like to hear the insights of others as well.
-- Wauteurz (talk) 21:21, 14 January 2019 (UTC)[reply]

It seems to me that any solution which requires editing every page or manually setting preview images is problematic. While we could do this for our most popular articles, the vast majority of our pages are lean on text as-is, and many lack a custom pagebanner, let alone an image to put in the lead. Even if we do find an image, it will in many cases then dominate the article.

Would it be possible, as a fourth solution, to adjust the weights on the image scores to strongly favor Wikidata images? This, I think, is the best solution: most of our articles would immediately have a photo, which someone felt represented the destination, as the preview image, and the ones with less-than-stellar Wikidata images would be easy to change, and doing so would benefit other projects. Plus, destinations without an image in Wikidata but with a banner could have the banner source image added to Wikidata, and destinations without an image or banner will still have other kinds of images to fall back on.

If this isn't possible, seems that would be a much simpler change for the Phabricator guys to make. ARR8 (talk | contribs) 01:37, 15 January 2019 (UTC)[reply]

Suggest more people subscribe to the two issues logged at Phabricator, cannot see why this cannot technically be possible, probably just not regarded as too important and there are lost of other issues to solve. Alternatively I think it would be possible to add a marker at the start of every city page pointing to the wikidata image (see below). But adding a location icon at the start of articles is going to need a discussion and some consensus as I see plus and minus points with it. --Traveler100 (talk) 10:03, 15 January 2019 (UTC)[reply]

I'm not a fan of any solution that involves mass edits to every page. This sort of thing should be done transparently. If we want it working now, then we do have to do something kludgy like that, but I'd rather the devs fix the underlying issue before we start changing the way all our pages look.

I do appreciate that you've found the least obtrusive way to do it, though. However, I think having an edit button right after the destination name might confuse new editors, who might click that instead of the page edit button. ARR8 (talk | contribs) 13:50, 15 January 2019 (UTC)[reply]

@ARR8: I am not suggesting that every one of our 32,521 articles gets manually edited. Wikidata has images available for most of these articles and not using those through the means of a bot would be a wasted opportunity. This will, however, still require some manual input as well, and a collaboration or expedition will help bring some structure to this. Like you said yourself, Wikidata has less desirable images too, and hopefully we can fix those along the way. Not every article has imagery in the preview right now either, if anything, that number would increase some. None of us have exact numbers on this, but it may be worthwhile to look into this, as the change in article previews with images in said preview might be a notable factor in choosing the eventual method. All in all, integration with Wikidata is something I recall as being wished for in previous years, hence the linking of listings to Wikidata. This might just be an opportunity to chase that wish and put it into further practise. I, for one, am not at all opposed to setting banner source images to be Wikidata's images for said ID, let alone using images in Wikidata IDs linked to our articles.

We all prefer for PageImages to just be working as it should be, but I don't expect it to be working as desired, allowing editors the control they are promised with T91683 to be done any time soon. This March, that task will have been up for 4 years, and I'm not sure it will be done by the end of this year. Another option would be T95026, which aims to allow PageImages to fetch images directly from the Wikidata ID linked to the article that's being previewed. Since Jdlrobson is involved in both these projects, perhaps they can tell us how process is coming along on those two projects.
-- Wauteurz (talk) 18:32, 15 January 2019 (UTC)[reply]

Would not need any manual editing, can add a template into the pagebanner template to extract wikidata and create a listing top right corner of the page. --Traveler100 (talk) 11:58, 16 January 2019 (UTC)[reply]

One solution I see today

Maybe this is using a sledgehammer to crack a nut but here is a solution Washington, D.C./sandbox. And would not take a year to edit page, probably could be done with a bot edit. Comments? --Traveler100 (talk) 21:41, 14 January 2019 (UTC)[reply]

Not saying we should do this but basically the only visible change would be a coordinate number (with location of city centre) at the start of city articles, e.g. Ohrid/sandbox. is this an acceptable change to get a better preview image? --Traveler100 (talk) 09:58, 15 January 2019 (UTC)[reply]

I'd prefer not to do this. The number is only a little confusing at the beginning of the article, but it's quite confusing when it displays on the dynamic map. —Granger (talk · contribs) 14:13, 15 January 2019 (UTC)[reply]

Can move the number to top right hand corner (see Washington, D.C./sandbox) and remove the need to edit pages (update to pagebanner), but cannot get it off the map. (note current pagebanner sandbox is fix image and coords but could change to be wikidata values of page) --Traveler100 (talk) 18:17, 15 January 2019 (UTC)[reply]

I'm not in favour of this. On the one hand, it does fix the preview image, but on the other hand it does also add 1 to each and every preview blurb, which my by judgement is not a worth-while trade-off. What I would be more in favour of is this idea, but with a mapshape instead of a map marker. No template currently exists to do that trick though, and I am not sure if that can be done either. This would then not display the listing number (1) in the preview, but instead just the blurb with its mark-up -no labels, no links- just plain text as it should be. This template can then get an image and wikidata link assigned. Neither of which would show on the map.
-- Wauteurz (talk) 18:20, 15 January 2019 (UTC)[reply]

the number can be removed from the preview by attaching the class noexcerpt! See MW:Extension:Popups#FAQ
2607:FB90:9D55:EEEC:AD28:E0EF:5ED3:DBD0 02:20, 16 January 2019 (UTC)[reply]

Right, that is a possibility indeed. Still, though, if we use noexcerpt, we will have to make a separate instance of the {{listing}} template. At that point, it is more worthwhile to look into creating a template as I described above, which adds a mapframe around the governing body rather than a marker on the map which adds no information whatsoever.
-- Wauteurz (talk) 20:02, 16 January 2019 (UTC)[reply]

Updated solution that works today

Created a test at Bitola. This does not require any manual updates to pages as adding code to the pagebanner. Will use image and coordinates from Wikidata. Note the extra icon and text at top right of page. Still creates an icon on map but is light grey. Does not create any marker on the preview. The current test template in my user space would need to some work to be make really usable as does not handle well at the moment if wikidata not there. Can work further on this if people think this is a workable solution. Reason proposing this is that I do not think the chances to mediawiki code will happen any time soon. --Traveler100 (talk) 09:03, 21 January 2019 (UTC)[reply]

Johanna Strodt (WMDE) 09:41, 14 January 2019 (UTC)[reply]

@Jdlrobson:, Page previews doesn't seem to be respecting Navpops at this wiki (for me, anyway). When the Navpops gadget is enabled, Page previews is supposed to be suppressed. However, when I hover on links to articles (on this page; I haven't checked anywhere else), I'm seeing both. Is that your territory? WhatamIdoing (talk) 16:56, 27 January 2019 (UTC)[reply]

I can confirm this bug. I have had to manually disable page previews due to this. ARR8 (talk | contribs) 16:57, 27 January 2019 (UTC)[reply]

This is now fixed thanks to User:X-Savitar :-) 19:58, 14 February 2019 (UTC)[reply]

Based on work done by @Seddon (WMF): I have changed to mobile entry page for Wikivoyage. It was very dull. Potential for more improvements, but this is a start, brings some color to the page. --Traveler100 (talk) 14:23, 10 February 2019 (UTC)[reply]

Excellent work! Massive thank you for doing that.--ThunderingTyphoons! (talk) 14:38, 10 February 2019 (UTC)[reply]

I'm so glad this has been implemented. Big improvement. —Granger (talk · contribs) 11:39, 11 February 2019 (UTC)[reply]

Have improved pages somewhat but now starting to struggle, particularly were tables have been used to format pages. --Traveler100 (talk) 18:29, 12 February 2019 (UTC)[reply]

Sorted out format without table widths but still cannot see why {{bottomboxesn}} does not show in mobile view when on main page but works from sandbox?--Traveler100 (talk) 21:53, 12 February 2019 (UTC)[reply]

Wooow! Our Chinese Wikivoyage also update the mobile version about main page. :D--Yuriy kosygin (talk) 17:57, 15 February 2019 (UTC)[reply]

Thanks to @ARR8: for making an even better mobile main page. --Traveler100 (talk) 06:57, 23 February 2019 (UTC)[reply]

Travellers' pub

This page was not displaying the Welcome block on mobile devices. I have split the introduction and the clean-up sections so the first part shows on mobile while the second does not. A little better but not perfect. Suggestion for improvements? --Traveler100 (talk) 17:41, 12 February 2019 (UTC)[reply]

Is the question mark with the green background really needed? --Traveler100 (talk) 17:49, 12 February 2019 (UTC)[reply]

I don't mind splitting them, but I think now the new box should be by default aligned the same as the other one, more like Pub/sandbox. But I'm not sure how that would look on mobile. --Comment by Selfie City (talk | contributions) 01:35, 13 February 2019 (UTC)[reply]

Wikivoyage:Community portal

The Community portal does not look good on a typical sized smartphone. Getting the individual blocks to run one under the other in mobile mode and side by side in desktop mode could be some over the topic piece of code to write and edit (unless someone can see an easy way of doing this). What do people think, either keep existing design for desktop viewing and a new design for mobile or come up with a new style that fits both? Any suggestions welcome. --Traveler100 (talk) 17:37, 12 February 2019 (UTC)[reply]

Think I have worked out a solution Wikivoyage:Community portal/sandbox. Not totally finished but see the end of the tunnel. --Traveler100 (talk) 21:42, 12 February 2019 (UTC)[reply]

The sandbox doesn't look right to me. Maybe, though, that's because you're still working on it. What if you just had one column of boxes, instead of two or three? --Comment by Selfie City (talk | contributions) 01:32, 13 February 2019 (UTC)[reply]

There were some errors in the original page which did not show up until made changes. Wikivoyage:Community portal/sandbox is where I want it to be when viewed on smart phone and on desktop using Firefox and Explorer but not working as I would like on Chrome. --Traveler100 (talk) 20:03, 13 February 2019 (UTC)[reply]

Help resources

I found mw:Mobile Gateway/Mobile homepage formatting. Any more useful resources, maybe with a little more detail on class and style code to use and how to use them? Looks like the code we are using for main and project pages is not recommend for mobile viewing. Looking for resources that would help write better pages that work on all devises? --Traveler100 (talk) 18:29, 12 February 2019 (UTC)[reply]

The French Wikipedia re-designed their Main Page a few years ago, and if you can figure out who did that, then you'd probably be able to find some examples. User:Quiddity could probably tell us if there are any active editors from enwiki with an interest in making Main Pages accessible. (I miss User:Edokter.) WhatamIdoing (talk) 21:43, 13 February 2019 (UTC)[reply]

Hi. +1 to looking at the w:fr: mainpage code - IIRC they paid attention to accessibility, and the result does appear to look good in both desktop and mobilefrontend when viewed in a thin window. Re: Enwiki, I'm not uptodate on whos active in that area, but I know the folks at w:WT:WPACCESS and w:WT:ACCESS are usually very nice and happy to have the topic be considered! (And yeah, I wish we had some better template-style-design-variations of these things to share among the communities. (ditto templates, etc etc etc! ∞ wishlist...)) HTH. Quiddity (talk) 07:50, 14 February 2019 (UTC)[reply]

Hello,

A few months ago we mentioned a change that was coming to how certain templates appear on mobile web. I just wanted to drop a note that this change is now in effect here on English Wikivoyage. As you may be aware, as of January mobile traffic counts for about a third of traffic on English Wikivoyage (and we're approaching twice as many unique devices using the mobile site over the desktop site), so making templates present on mobile is important.

We've deployed this update to all other wikis and we ran A/B tests on Wikipedia to measure the impact (Summary: Users interact with the new treatment more frequently than the old. They interact with higher-severity issues more than than lower-severity issues. The new design does not cause more frequent edits).

We have noticed that these templates have a few styling inconsistencies here on English Wikivoyage and would like to ask for your help. For template editors, we have some recommendations on how to make templates that are mobile-friendly and further documentation on our work so far.

If you have questions about formatting templates for mobile, please leave a note on the project talk page or file a task in Phabricator and we can help. CKoerner (WMF) (talk) 18:30, 20 February 2019 (UTC)[reply]

Good news! This should have a great impact on the WV:UX Expedition. --Comment by Selfie City (talk | contributions) 03:11, 21 February 2019 (UTC)[reply]

These are relatively minor changes for WV, but I'm glad we were notified. ARR8 (talk | contribs) 04:14, 21 February 2019 (UTC)[reply]

Oh, OK. But still, good news. --Comment by Selfie City (talk | contributions) 04:48, 21 February 2019 (UTC)[reply]

This means that if you put a template about problems at the top of an article, then readers are (at least initially, and the effect may not persist) clicking on the links in the templates to learn what that newly visible template is about. Nobody extra edits the articles, so I consider it basically a failure. (To be fair, the failure may be in the whole idea of maintenance templates as a way to encourage editing, rather than a problem with the work that team did. But either way, we shouldn't expect much.) WhatamIdoing (talk) 06:19, 22 February 2019 (UTC)[reply]

Trizek (WMF) 15:01, 21 February 2019 (UTC)[reply]

Swept in from the pub

Johnny Harris made a great video about tourist clichés; well-known places, views and activities which might get over-exploited, with Hallstatt in Austria as a case study. He says some words about how to find experiences beyond them. What could writers of Wikivoyage learn of this video? If we describe a tourist attraction which gets overcrowded, overpriced or compromised, should we give advice about times to avoid the worst stampede? Or alternative attractions nearby? /Yvwv (talk) 14:47, 4 March 2019 (UTC)[reply]

Also, perhaps when we show pictures of famous tourist destintaions, we could do ones that aren't so well-known. Like for London, if we tried to show some sites besides the most famous ones. --Comment by Selfie City (talk | contributions) 15:09, 4 March 2019 (UTC)[reply]

Agree with all of the above suggestions. These are all fundamental features of a successful travel guide.--ThunderingTyphoons! (talk) 19:05, 4 March 2019 (UTC)[reply]

I believe somewhere about the WV:Banner expedition it talks about choosing pagebanners that show a more unique view of the place pictured. --Comment by Selfie City (talk | contributions) 23:22, 4 March 2019 (UTC)[reply]

Both the banners of Austria and Hallstatt are shots of Hallstatt similar to the picture mentioned above, but in reverse angle. /Yvwv (talk) 03:18, 5 March 2019 (UTC)[reply]

Still, the way I see it, if it's a nice place, no harm is done in photographing it. If the banner for these two pages are considered too similar, though, the one for Austria could perhaps be changed. --Comment by Selfie City (talk | contributions) 01:02, 9 March 2019 (UTC)[reply]

Swept in from the pub

I like to follow Alexa ranks. From mid-2018 to October 2018, Wikivoyage's Alexa rank climbed quite quickly, but steadily. However, the rank suddenly stopped climbing around this time, when it flattened out. Over the next couple months, it has started to fall, and though it seems to be fairly flat now, it's still not exactly in the position to start climbing greatly again. I wonder why this has occurred.

Back in early 2018, there was some kind of project where editors were encouraged to expand articles. Then more recently there was a project on Russian Wikivoyage. These were considered to be why the Alexa rank climbed in the past. Are any similar events coming up in the near future, or later this year?

Just curious. In the end of the day, we still get excellent numbers of readers, and we're working hard to make the travel guide better and better. But it would be interesting to know if these techniques could be used in future to get more readers. Just some thoughts. --Comment by Selfie City (talk | contributions) 05:43, 8 February 2019 (UTC)[reply]

Anecdotally, I've noticed it seems quieter on here recently, especially during the daytime (UTC). Talking about edits, of course, rather than readers, but I imagine a certain percentage of readers will also edit too. (On that theme, anyone know if there are any studies on what the average percentage of a wiki's readership make at least one edit? And how many of those become regular contributors?) Wikimedia ought to have a small external advertising budget, imo, because as effective as initiatives like the Editathon are, they're only targetted internally, i.e. other WMF wikis. Failing that, maybe we (as in Wikivoyage) should try to be noisier on social media. We have Facebook, YouTube (Twitter?), but does anyone follow us on them?--ThunderingTyphoons! (talk) 14:10, 8 February 2019 (UTC)[reply]

The usual figure given is 10%. We have another problem, in that our search rankings are usually low, especially compared to Wikipedia. Most people don't come to Wikivoyage to look for travel information, but look it up and then find themselves here. I was going to propose a COTM for this - there are several high-profile pages, that, when searched for, return results from Lonely Planet, TripAdvisor, Wikitravel, etc., on the first page, but not us. Probably the worst example I've found is Croatia. ARR8 (talk | contribs) 14:47, 8 February 2019 (UTC)[reply]

As I understand it, in the case of SEO, it's probably because the Croatia article has a lot of similar (or even duplicate) content to Wikitravel, or the content of the article does not use many catchphrases that would be picked up by a search engine.

I think it's true that it has been quieter lately. I was looking at the recent changes at 5:00 UTC (today, UTC) and I found that I could easily scroll through the changes. One example was that, apart from an account being created, no edits were made in the hour from 3:00-4:00. Imagine if a vandal had been on the site then, how much damage he could have caused.

I agree about social media. We have a social media nominations page, but it is rarely used. We ought to use it more, if possible. We could mention articles that have been significantly improved lately, etc. DOTMs are published on social media as I understand it. --Comment by Selfie City (talk | contributions) 14:55, 8 February 2019 (UTC)[reply]

Previous years, both Wikivoyage and The Other Site have had low activity during October-February. Not strange, since English-speakers usually make their big holiday journeys during northern summer. We can expect more traffic during the coming months. /Yvwv (talk) 15:08, 8 February 2019 (UTC)[reply]

I'm presently the only active administrator of Wikivoyage's Facebook account who is more than marginally active on Wikivoyage itself. Currently every new DotM, OtBP and FTT gets posted on Facebook. I definitely feel like our account should be more active than that, but as I've said before, I feel like it's too big of a job for one person, especially someone as overextended as I am. But every time in the past that I've called out to the Wikivoyage community for anyone interested in helping manage our FB presence, whoever takes on the challenge seems like clockwork to fall inactive before very long. I still would love the help, but I hope that if I get any responses here from folks who'd like to be inducted as administrators to our FB page, it's from someone who plans to stick around awhile. -- AndreCarrotflower (talk) 15:50, 8 February 2019 (UTC)[reply]

I started Uni in October. Question solved. ;-) Hobbitschuster (talk) 22:11, 8 February 2019 (UTC)[reply]

If you compare our Alexa rank to 12 months ago, it is much higher. It has jumped from about 21,500 to 16,500. And that's the important measure since throughout the year there are seasonal chances as Yvwv mentioned above. But of course, there is always room for improvement. I have sometimes promoted Wikivoyage articles on online travel forums where I thought it was relevant to the question or conversation. All of the anecdotal feedback I've received is that of the people who read Wikivoyage, most of them like us. Very few people are not fans. It is just that barely anyone is aware that we exist. Our target audience is quite large (anyone interested in travel with an internet connection and is English-speaking including non-native) but of this large population how many have heard of us. All of the major alternatives to WV whether similar in scope (e.g. the other site, Lonely Planet, Frommers, Rough Guides) or having somewhat different but overlapping goals like TripAdvisor, BBC Travel and Nat Geo Travel, have millions of followers on social media. We have thousands. Our goal should be just getting our name out there so that travellers get to know about this site. SEO is the big reason why many of our articles are almost ghosts but there have to be other ways to create awareness in addition to differentiating ourselves from the other site. Gizza ^(roam) 13:52, 9 February 2019 (UTC)[reply]

Agreed. Name recognition is very important. --Comment by Selfie City (talk | contributions) 17:23, 9 February 2019 (UTC)[reply]

Ideas

Has it ever been considered for WV to have some sort of blog? Didn't WT used have that back at one time? If we started it, we'd want it to be a group effort, of course, and if so, I'd be happy to help. --Comment by Selfie City (talk | contributions) 23:48, 8 February 2019 (UTC)[reply]

It might be worth trying to partner with some existing Wikipedia-focused events. For example, maybe someone who is writing about a famous artist would also like to update the entry here about a museum where the art can be seen. If anyone's in New York City, London, or Berlin, then there are a lot of potential events there. WhatamIdoing (talk) 04:54, 9 February 2019 (UTC)[reply]

Wikivoyage is not very popular, after all, everyone only knows Wikipedia, not us... To make more people interested in our Wikivoyage, I think we need to work with other travel sites(eg [https://www.backpackers.com.tw/guide/ Backpackers).--Yuriy kosygin (talk) 18:45, 2 April 2019 (UTC)[reply]

DOTM banners

I now have the tools (GIMP) and the know-how to do banners for DOTM, OTBP, and FTT. Hopefully this can take some of the burden off AndreCarrotflower in doing the banners, which can be quite a lot of work. Ypsilon has also been a help recently. --Comment by Selfie City (talk | contributions) 00:23, 10 February 2019 (UTC)[reply]

Alexa rank rise

Suddenly, in mid-March, Wikivoyage has zoomed up to its previous heights a few months before and is now between 15,000 and 16,000. This is interesting, and perhaps someone has a theory for why this has happened. --Comment by Selfie City (talk | contributions) 02:14, 19 March 2019 (UTC)[reply]

Wikitravel rank

Just in case this was not yet mentioned before. Because we always compare ourself to Wikitravel; WT has gradually declined over the last couple of months/years: https://www.alexa.com/siteinfo/wikitravel.org It is almost at par with WV now. So, I reckon we are doing pretty well. Cheers Ceever (talk) 12:12, 19 March 2019 (UTC)[reply]

There are people who buy old travel guides at garage sales, so I guess it is not surprising that people are still reading Wikitravel. It is also interesting that of Wikivoyage's readers, 14% are from the US, and 35% are from the next four countries combined (Germany, Italy, China, Iran), meaning that a lot of our readers are not people whose first language is English. (You need a subscription to Alexa to find out about the remaining 51% of readers.) Ground Zero (talk) 12:26, 19 March 2019 (UTC)[reply]

Keep in mind, they are probably not reading our articles. They are probably going to de:, it: (the original WV sites and those with the biggest content advantage over WT), zh:, and fa:. I'm surprised ru: isn't near the top, with the all the work they do with monuments.

Based on this, I think it would be good for WV for the WMF to focus on creating more WV language editions, especially ones that WT already has, as, the later they are created, the harder it is to overcome that content gap, especially its effect on search engine rankings. There's little most of us can do about that, though. But, it is notable that 8.5% of WT's traffic comes from Japan, and ja: is still in incubator. ARR8 (talk | contribs) 15:18, 19 March 2019 (UTC)[reply]

WV's Alexa rank just surpassed WT's (see Wikivoyage:Wikivoyage and Wikitravel). WT is still bigger in the United States (which makes up much of the Anglosphere). /Yvwv (talk) 14:44, 23 March 2019 (UTC)[reply]

I've done a little work in Spanish-language Wikivoyage, but generally my knowledge of the language isn't nearly good enough that I can contribute significantly or freely there. --Comment by Selfie City (talk | contributions) 00:35, 1 April 2019 (UTC)[reply]

I edited Chinese Wikivoyage a little bit and their coverage is abysmal. Even capital cities like Helsinki, Riga and Kiev are purely skeletons. (If I could type Chinese easily on computer rather than use dictation software on Android keyboard, I would have contributed more.) OhanaUnited^{Talk page} 03:52, 1 April 2019 (UTC)[reply]

Sorry, I am late... In our Chinese Wikivoyage, we have a lot more articles and editors than Chinese Wikitravel, but our Chinese Wikivoyage are still improving in the interface and funtion. Anyway,I think that Japanese and Korean really need to be incubated as soon as possible. After all, the long delay will be very unfavorable for the development of Wikivoyage in Korea and Japan.--Yuriy kosygin (talk) 18:31, 2 April 2019 (UTC)[reply]

IIRC, when the fork happened, the Japanese Wikitravel community was the only one that voted to stick with Internet Brands rather than migrating to the WMF. At last check, they're still an active community and still happy to stay put where they are. -- AndreCarrotflower (talk) 23:47, 2 April 2019 (UTC)[reply]

@Yuriy kosygin: No need to apologize, I was only pointing out the current state of Chinese WV articles and hopefully someone who's reading this discussion and can type in Chinese easily to contribute. OhanaUnited^{Talk page} 03:42, 3 April 2019 (UTC)[reply]

• A BIG congratulations to everyone here. We have finally pulled ahead of WT in the Alexa rankings :-) Travel Doc James (talk · contribs · email) 17:37, 14 April 2019 (UTC)[reply]

travellerspoint.com wiki too...

Alexa rank is nice and all, but most users probably come from google. Lately it seems that the above page often "wins" there if I enter "destination wiki guide". Our guides are usually much more comprehensive, so it'd be good find a reason why this happens... Could some of WV policies actually be cause of the relatively mediocre SEO results? -- andree.sk(talk) 13:57, 16 April 2019 (UTC)[reply]

Hum that website is down below the 100,000s in popularity. Travel Doc James (talk · contribs · email) 21:11, 16 April 2019 (UTC)[reply]

Contrary to what many of us seem to have assumed (self included)...

...Wikivoyage is actually doing pretty well by comparison to our for-profit competition. Alexa puts us slightly ahead of Wikitravel and Fodor's; far ahead of Rough Guides, Frommer's, Travellerspoint, Backpackers.com, and Moon Travel Guides; and behind only Lonely Planet and TripAdvisor. I think this puts any talk of synergy with other sites squarely out of bounds, seeing as the only sites it would make sense for us to collaborate with (the latter two) are ones that are run very much on a commercial basis and thus any such collaboration would violate the WMF's nonprofit ethos.

Cc: Yuriy kosygin and andree.

-- AndreCarrotflower (talk) 21:30, 16 April 2019 (UTC)[reply]

Alexa's list of Travel Guide and Directories sites puts us in 7th position behind TripAdvisor, Timeout, Lonely Planet, Tripsavvy, Travelzoo and Ixigo. I hadn't heard of some of these sites but looking deeper, they seem to be very popular in a handful of countries. And Travelzoo doesn't seem to be a travel guide. There is also a list of Travel Publications websites which are travel magazines and cover similar territory and there a couple of websites with higher rankings at the moment. Also many news and documentary sites have popular travel guide sections like CNN Travel, BBC Travel and National Geographic Travel but unfortunately Alexa doesn't capture the rankings of the travel sections (though circumstantial evidence like social media followers suggests they are much more popular than WV).

I think Wikivoyage is close to peak popularity in many continental European countries (5774th in Germany, 2458th in Italy) and Iran (5273th) but still has significant opportunities for growth in native English-speaking countries and Asia. The US rank for WV is lower than WT and in Australia for example, Wikivoyage is not among the top 15 travel guide sites [1]. The main source of online travel knowledge in Australia is "Traveller" which has a rank in the 600s but it's not used in any other country. It is an offshoot of the Sydney Morning Herald but has a separate domain name so you can see how popular it is. The German and Italian Wikivoyages forked out earlier which is why they have become well established. But there is no reason why Wikivoyage can't become just as well known across the entire world. Gizza ^(roam) 22:35, 16 April 2019 (UTC)[reply]

I think it's important not to compare apples with oranges. The sites you mentioned are travel-related, but they're not travel guides per se and thus we're not really competing with them. Wikivoyage is not a hack listicle site like Timeout, we're not an Expedia-esque booking engine like Travelzoo or Ixigo, we don't host travel essays or magazine-style articles as National Geographic does, and we're not analogous to the travel features on a television network like CNN or the BBC. (Frankly, though I know I was the one who brought TripAdvisor up, we're not even really comparable to them; I see them as being more akin to Yelp or Google Reviews than a site like ours.) -- AndreCarrotflower (talk) 23:02, 16 April 2019 (UTC)[reply]

Speaking of apples and oranges, I'd say that Tripadvisor isn't a travel guide but since it is used like a travel guide by many people, it's worth using for comparison. --Comment by Selfie City (talk | contributions) 23:39, 16 April 2019 (UTC)[reply]

We present our information in a different format to many of the above but the information itself overlaps to a significant degree. From the traveller's perspective, it's the same information from different sources. Much of Nat Geo's online content on treks are very similar to our itinerary articles. In the case of Traveller in Australia, it not only has listicles and travel news articles but in-depth guides on particular destinations. The BBC has a section on travel tips which contains articles very similar to some of our travel topics such as budget travel. Many of the websites have a travel forum which has the same purpose as the tourist office here. I'd say most of the sites compared to us are apples and pears as opposed to oranges. It's similar to Wikipedia where its competitors (and therefore websites affected by its rise) were not just encyclopedias like Britannica but other general reference websites that presented similar information in a different way.

In any case, my point was more about being cautiously optimistic in the long run. Wikivoyage is capable of becoming just as famous and used in every country as it is in e.g. Italy, where it is a top 2,500 site. Regardless of whether the other sites mentioned are true alternatives to us, that is what we should be aiming for. Gizza ^(roam) 04:05, 17 April 2019 (UTC)[reply]

Swept in from the pub

Is there a syntax error here, or is there a maximum number of listings for an article? --Traveler100 (talk) 06:25, 17 April 2019 (UTC)[reply]

I suspect it's a maximum number of templates, rather than a maximum number of listings. Some non-listing templates at the bottom of the article are messed up too. That article has a very large number of templates, because it uses Template:rint and Template:station to make all the public transit information colorful. —Granger (talk · contribs) 06:46, 17 April 2019 (UTC)[reply]

Yes that was it. I have commented out the stations from drink and eat listings. Output error has gone. --Traveler100 (talk) 07:55, 17 April 2019 (UTC)[reply]

That fixes the issue, but it means we've lost the directions for all the listings in those sections. Come to think of it, the directions in the other listings are not very clear either (what does "Remetehegyi út 165" mean? Is "Remetehegyi út" the name of a station or a line?). Confusingly, the icons are different from the ones used in the Budapest article. It might be better to replace them with text that's clearer and more specific. The "Get in" section is pretty opaque too if you're not familiar with Budapest public transit—are those metro lines? Trams? Buses? —Granger (talk · contribs) 09:04, 17 April 2019 (UTC)[reply]

Why is there a limit on templates? Is there possibly a way to get that limit changed for this article in particular? --Comment by Selfie City (talk | contributions) 13:41, 17 April 2019 (UTC)[reply]

Saw the same issue in Germany the other day, we should probably increase the memory limits somewhat (by 1/2?) if possible... wgLuaMaxTime and such? -- andree.sk(talk) 06:22, 18 April 2019 (UTC)[reply]

With whom should we get in touch to change such things? --Comment by Selfie City (talk | contributions) 13:32, 18 April 2019 (UTC)[reply]

Swept in from the pub

I uploaded a lot of instructional videos in the Chinese playlist. However, I hope that many Wikivoyage friends can provide a little video so that I can help promote the Wikivoyage on the Youtube channel, I also welcome friends who want to participate can become administrators to manage Youtube channels.

If you want promote about Wikivoyage, please provide a video about Wikivoyage at Commons, or upload it directly to Youtube. I will assist in uploading or emploing on the Wikivoyage Channel, thank you.--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 17:44, 17 April 2019 (UTC)[reply]

Swept in from the pub

Over the last few years, the WikiJournal User Group has been building and testing a set of peer reviewed academic journals on a mediawiki platform. The main types of articles are:

• Existing Wikipedia articles submitted for external review and feedback (example)
• From-scratch articles that, after review, are imported to Wikipedia (example)
• Original research articles that are not imported to Wikipedia (example)

Proposal: WikiJournals as a new sister project

From a Wikipedian point of view, this is a complementary system to Featured article review, but bridging the gap with external experts, implementing established scholarly practices, and generating citable, doi-linked publications.

Please take a look and support/oppose/comment! Evolution and evolvability (talk) 04:25, 3 June 2019 (UTC)[reply]

Looks good to me. Where do you need people to express an opinion? Also, is there any coverage of music or any thought of covering it? What disciplines are currently covered? Ikan Kekek (talk) 06:03, 3 June 2019 (UTC)[reply]

@Ikan Kekek: This post is to solicit people's feedback as a wide-scale announcement so it's not only those who already knew about the project will comment on it. Right now the proposed sister project has 3 journals written in English with a diamond/platinum open access model (no charge for readers or authors): Medicine, Science and Humanities. It can be scaled to other languages such as French, Spanish, Chinese, etc. in the future. As a science person, I don't know much about humanities but music might full under that journal's scope. Certainly it can be a possibility in the future to have a journal dedicated to music if there are enough submissions to warrant a standalone journal for this subject. (Full disclosure, I'm one of the editorial board member on WikiJournal of Science) OhanaUnited^{Talk page} 23:37, 3 June 2019 (UTC)[reply]

• Sounds like a good idea. Would it be open only to scholars? In case no-one's noticed, this will mean that the mentions on Wikimedia sites that "Wikivoyage is the newest of the Wikimedia projects" will have to be adjusted. --Comment by Selfie City (talk | contributions) 00:27, 4 June 2019 (UTC)[reply]

OhanaUnited, the nature of my question is that I don't understand where you need people to express an opinion pro or con on WikiJournals being accepted by the Wikimedia Foundation as a sister project, which I think was the purpose of the announcement. Giving an opinion here won't have much weight. Ikan Kekek (talk) 01:15, 4 June 2019 (UTC)[reply]

@Ikan Kekek: The link to the discussion is actually in bold and says "Proposal: WikiJournals as a new sister project", which will direct you to the Meta page. OhanaUnited^{Talk page} 01:30, 4 June 2019 (UTC)[reply]

Thanks. :-) Ikan Kekek (talk) 04:20, 4 June 2019 (UTC)[reply]

Yes. The proposal had almost unanimous support until very recently, but now it has more publicity, the votes have become more mixed. --Comment by Selfie City (talk | contributions) 14:19, 5 June 2019 (UTC)[reply]

I want to add Wikivoyage friends from English and other languages ​​to manage and upload YouTube instructional videos so that wikivoyage can fully advertise in all languages. We already have a lot of videos and live broadcasts in Chinese, and we hope that more English and other languages ​​will be added to the channel!

If you are an administrator of any language in a Wikivoyage, I look forward to provide your personal G-Mail to me, so that I can add you become a YouTube administrator, you will can upload videos on the YouTube channel! and everyone can click subscribe it, Thank you!(see Wikivoyage Channel)--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 16:23, 30 September 2019 (UTC)[reply]

Do you also plan on doing 'travel' content in English Language on the chnanel? Like for example a London resident talking about the obscure museum that exists in Hampstead for example, or a Melbourne Resident talking about the trams. (There are other independent You Tubers that make travel related content.)ShakespeareFan00 (talk) 22:12, 30 September 2019 (UTC)[reply]

@ShakespeareFan00: We have English List, but I only using Chinese. Your Idea is good, I hope you can help us with YouTube Channel. After all, my English is very poor and really bad.--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 14:44, 1 October 2019 (UTC)[reply]

I don't have the ability or skill level to help with that sadly. ShakespeareFan00 (talk) 15:42, 1 October 2019 (UTC)[reply]

If you want travel content for the YouTube channel, I wonder whether m:VideoWiki would be useful to you. User:Ian Furst could probably explain it better than I can. WhatamIdoing (talk) 17:05, 1 October 2019 (UTC)[reply]

Here is an example of a video script [2] The video is than auto generated from the script. And here is the video up on youtube[3] Travel Doc James (talk · contribs · email) 03:56, 3 October 2019 (UTC)[reply]

@WhatamIdoing, Doc_James: Good idea, but m:VideoWiki no videos about travel...--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 15:08, 6 October 2019 (UTC)[reply]

I'll think about doing that, as the more we can use the YouTube account, the better. --Comment by Selfie City (talk | contributions) 12:48, 6 October 2019 (UTC)[reply]

@SelfieCity: Thanks.✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 15:11, 6 October 2019 (UTC)[reply]

The only thing is that I have multiple G-Mail accounts (one is specifically for Wiki). I guess I'd use that one, then; I just don't want to get the accounts confused. --Comment by Selfie City (talk | contributions) 17:53, 6 October 2019 (UTC)[reply]

@SelfieCity: OK.--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 14:39, 7 October 2019 (UTC)[reply]

I imagine you would want to keep the scripts on Wikivoyage? Build one in a sandbox on WP. Than move over to Wikivoyage and I can see about getting this tool working here. Travel Doc James (talk · contribs · email) 23:41, 6 October 2019 (UTC)[reply]

@Doc_James: After all, I don't know how to move to a Wikivoyage... as like this?--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 14:39, 7 October 2019 (UTC)[reply]

Have started building some of the background tools at Template:Videowiki

Basically you want to create something like this[4] on a travel topic correct? Travel Doc James (talk · contribs · email) 19:10, 7 October 2019 (UTC)[reply]

@Doc_James: Yes!--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 17:15, 9 October 2019 (UTC)[reply]

Okay you can create one on Wikipedia to start with. I will try to figure out how to get this working on Wikivoyage. Travel Doc James (talk · contribs · email) 02:28, 10 October 2019 (UTC)[reply]

It appears we do not have the template for infoboxes here. This does not format well Template:Videowiki Travel Doc James (talk · contribs · email) 12:31, 10 October 2019 (UTC)[reply]

Unless the VideoWiki project is meant to only work at a couple of wikis, then its dependence upon any templates, especially the English Wikipedia's complicated Infobox module system, needs to be removed. Until Global Templates are a reality (that's a large, multi-year technical project), then projects like this have to choose between "works everywhere" or "uses local templates". WhatamIdoing (talk) 17:06, 10 October 2019 (UTC)[reply]

Well, it looks complicated; I just hoped that everyone could help promote Wikivoyage by providing YouTube videos.--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 15:24, 13 October 2019 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ What app do you use? iMovie? --Comment by Selfie City (talk | contributions) 17:05, 13 October 2019 (UTC)[reply]

@SelfieCity: I have reply mail to you, and I use Wondershare Filmora, thanks.--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 13:41, 14 October 2019 (UTC)[reply]

Thanks! I'll take a look at that app when I have the time. --Comment by Selfie City (talk | contributions) 13:42, 14 October 2019 (UTC)[reply]

Hello all! Lately, we've been switching all wikis to use a new, faster parser for the AbuseFilter. Unfortunately, this wiki cannot be switched because one of the filters contains unsupported syntax. Specifically, it is filter 36. In order to fix it, you should remove the trailing &! at line 5. Could anyone please take a look? Should you have any questions, please feel free to ping me back! Thanks, --Daimona Eaytoy (talk) 16:56, 5 October 2019 (UTC)[reply]

I've simply removed the text you mention. If that removal harms the filter in any way, it will be necessary for someone with more knowledge to make those fixes. --Comment by Selfie City (talk | contributions) 16:58, 5 October 2019 (UTC)[reply]

@SelfieCity: Thanks! Technically, that part was equivalent to & !null, i.e. & true, so removing it has no effect at all. Thanks again, --Daimona Eaytoy (talk) 17:07, 5 October 2019 (UTC)[reply]

Good — thanks for explaining that. --Comment by Selfie City (talk | contributions) 19:30, 5 October 2019 (UTC)[reply]

@SelfieCity: Hi, I've just realized that filter 34 has the same problem, at line 7. Could you please fix it as well? Also, FTR, the new parser is now enabled here on enwikivoyage as well :) Thanks, --Daimona Eaytoy (talk) 16:45, 8 October 2019 (UTC)[reply]

In as few words as possible: there's a currently ongoing edit war at the above-linked page involving myself and Powers, who many of you know is a user whose advocacy against dynamic maps and for static ones has grown from strong, to strident, and now it seems to fanatical and disruptive.

A few days ago, I replaced Letchworth's static map - which, as you can see, includes no listed POIs and is basically useless to travellers - with a dynamic one in which all POIs are labeled. My edit was reverted, on the basis that the park entrances were not marked on the dynamic map. I then reverted the reversion, stating that the simplest solution to that problem would be to mark the entrances on the dynamic map (which I did), rather than 1) restoring a static map that is, again, basically useless to travellers and 2) sabotaging the dynamic map by downsizing it to a point where it's no more useful than the static one, which was also a part of the earlier edit. For my troubles, my revert of the reversion was then itself reverted. Needless to say, this is not the sort of conduct that is acceptable, especially from a user of Powers' standing.

Zooming out, our community has recently been able to come to a resolution of a protracted dispute about when dynamic maps should be used and when static maps are appropriate - respectively, in bottom-level destinations like Letchworth and in the case of region articles whose specifics (national boundaries, location of cities, etc.) change very infrequently or not at all (important when the number of active Wikivoyagers who know how to edit static maps is very small). And to be perfectly honest and frank about it, a big part of the reason why we succeeded in forging this consensus despite being unable to do so before was because Powers' edit history has become increasingly sporadic, and we've thus been able to enjoy breaks from his one-man anti-dynamic map crusade that were long enough to push policy through while he was away. Furthermore, we've also recently come to the consensus that with the exception of a few special cases, articles should generally only contain one map, and should never contain multiple maps with redundant information, as indeed is the case with the two Letchworth maps. Now I'll be damned if we're going to re-litigate these issues for the benefit of a barely-active user who can't handle the idea of consensus disagreeing with him, and I'll be double-damned if a currently-active Main Page feature, one of the most-viewed articles on Wikivoyage for this month, is going to be the place where this conflict plays itself out.

Ordinarily under these circumstances, the easiest solution would be to semiprotect the article for the duration of its term on the Main Page. However, since Powers is an admin/bureaucrat, there's no level of article lockdown that would affect him. Given that, the solution I propose is to revert the article back to its status at the time of its placement on the Main Page - i.e. prominent and usable dynamic map, no static map - and that further disruption on Powers' part will result in a partial ban covering the Letchworth State Park article only, to take immediate effect (waiting fourteen days for a userban discussion to resolve would be fairly pointless) and to last the duration of the article's tenure as OtBP. However, because partial bans are a relatively new software feature that have never been used on this site, I would rather not enact that solution unilaterally. Your feedback is appreciated, the more expeditiously the better.

-- AndreCarrotflower (talk) 23:56, 14 October 2019 (UTC)[reply]

I don't see how a ban of a bureaucrat/admin could be effective without their assent, because they have the power to revert the ban. My feeling is this: Static maps are, all things being equal, just plain better. However, in this instance, it's patently obvious that the better map is the one that shows points of interest, which is the dynamic map. My feeling is that if a user ban has to be proposed, it would be necessary to also desysop Powers, and that would require a vote, normally at Wikivoyage:Administrator nominations, but in this case, I suppose at Wikivoyage:User ban nominations, concurrent with the topic ban proposal. Ikan Kekek (talk) 00:30, 15 October 2019 (UTC)[reply]

Ikan - I'm pretty sure userbans enacted on sysops also block use of the sysop tools, making it impossible for them to unban themselves. Otherwise my accidental blocks of Ibaman and Traveler100 last year (sorry again, guys) wouldn't have caused the problems they did. I'm not sure if it works differently for bureaucrats, but I doubt it. -- AndreCarrotflower (talk) 00:52, 15 October 2019 (UTC)[reply]

OK, if so, no problem, then. Let's hope the edit warring will cease and we won't have to do anything more. Ikan Kekek (talk) 01:17, 15 October 2019 (UTC)[reply]

Restore the status quo until it's off the OTBP. Then we can decide whether we want to "de-bureaucrat" Powers. --Comment by Selfie City (talk | contributions) 01:19, 15 October 2019 (UTC)[reply]

SelfieCity - This isn't about desysopping Powers, which would have to be a separate discussion (nor for that matter would this be a topic ban, a phrase I heard floated above). This is about how to prevent edits to an article by an editor whose level of user rights renders them unaffected by page protection, either semi- or full. If we're treating this as an emergency case that's handled outside the usual userban channels, then I think it's important that we keep the scope as narrow as possible; in the case of a partial ban for Powers, he would remain fully able to both edit and use the sysop tools on all pages except Letchworth State Park. -- AndreCarrotflower (talk) 01:23, 15 October 2019 (UTC)[reply]

OK. I was busy at the time and I didn't read much of what you wrote. I think we could do with a rule that says changes to a featured article are not allowed unless they are an important correction, update, or revert of a problematic edit. If there is a clear rule and punishment, I don't think this will happen again. --Comment by Selfie City (talk | contributions) 01:37, 15 October 2019 (UTC)[reply]

(Also, reading your post: I did use a partial block once on a user.) --Comment by Selfie City (talk | contributions) 02:15, 15 October 2019 (UTC)[reply]

Agree the dynamic map is better in this case but talking about blocking a long standing user, even temporary I think a bit excessive for what I see is two reverts and no discussion of differences in views between editors on the article talk page. --Traveler100 (talk) 05:24, 15 October 2019 (UTC)[reply]

Agree with the above. I see no attempt from either André or Powers to discuss this disagreement respectfully on any talk page, which would be by far the best and simplest option. Any ban in these circumstances is absurd and sets a bad precedent. I would encourage you both to talk about it.--ThunderingTyphoons! (talk) 06:04, 15 October 2019 (UTC)[reply]

I do not think a ban is warranted. If we did ban anyone. I'd say block both users for edit warring & failing to discuss it on the talk page. Pashley (talk) 08:26, 15 October 2019 (UTC)[reply]

If someone gives a reason for an edit that's not obviously against policy (or demonstrably poor grammar, factually incorrect or whatever), and you've edited the page once and they've restored it with a reason, your job is to take it upon yourself to start a talk page thread. The standard of edit warring, as I understand it, is to revert something twice. I will do that only when someone is touting, vandalizing or restoring text I find impossible to really understand because it's in such bad English, or demonstrably incorrect spelling or grammar - and in that latter case, I also start a talk page thread on the page or their user talk page, explaining why their edit was in my view clearly incorrect, and may hold off on reverting a second time for a day or so.

What that means to me is that Powers is more at fault here, especially as we seem to all agree so far that his argument isn't logical in this instance. Yes, Andre could have started a thread on that talk page, but I don't see where he was incorrect to start the thread here, since that page is being featured and he wanted to make sure more people paid attention to his position. This thread can be swept to that page's talk page any time we like.

The other thing is that no-one, I think, is suggesting any kind of ban now. The proposal is about what to do if Powers persists in edit warring. And those of you who are objecting to the lack of a thread at Talk:Letchworth State Park would in my opinion do better to focus on what we should do if the edit warring persists than only on your preferred procedure. So what do you think? Would it be OK for these reversions to go on and on, or not? And if not, what do you propose to do about it? Ikan Kekek (talk) 09:49, 15 October 2019 (UTC)[reply]

Well since no discussion has been had, we have no idea whether Powers intends to continue edit warring over this, or what his thoughts are beyond a single edit summary. I would say it's pretty self evident that were he to continue an edit war, a block would be justified in line with existing policy. But we're not at that stage yet, because a grand total of four edits doesn't equal a serious edit war.

But let's just ask him: @LtPowers: Will you please either join in a discussion about the map on Letchworth, or back off on the edit warring? Thank you.

For the record, while I agree that "Powers is more at fault here", since André's role in the 'edit war' was defending what consensus says, I also feel the way this discussion was opened (not pinging the other person involved, and describing them as a "fanatic" while discussing banning them in front of the whole community when they're not here to defend themselves, and all before any attempt to *speak* directly) was below the belt. --ThunderingTyphoons! (talk) 10:33, 15 October 2019 (UTC)[reply]

I agree. The edit war has stopped, so I don't think it's fair to continue a "What if he..." discussion about a particular user. Making it a gossip/slam thread I'd say is worse than edit warring. If he has something he wants to say or discuss, we should wait and allow him to do that. The edit warring has stopped, so there's nothing else to talk about. ChubbyWimbus (talk) 12:06, 15 October 2019 (UTC)[reply]

ThunderingTyphoons! - I thought I made it clear in my original comment that this is not an isolated incident, but rather part of an issue we've had with Powers going back to when dynamic maps were first introduced to Wikivoyage, and that we have, in fact, tried on many occasions in the past to have discussions with him about maps and have pretty consistently been vexed by his unreasonable approach. (His comments at Wikivoyage talk:Dynamic maps Expedition/Archive 2014-2015 in particular contain many, many examples of this, and just look at how many perfectly worthy Starnoms were either scuttled or left in limbo for extended periods solely because of his objections to dynamic maps.) If I'd had reason to believe that a talk page discussion would resolve the issue, I would never have suggested what I suggested above, but I can tell you right now how such a discussion would have gone: I would have been raked over the coals for daring to suggest the map that he worked so hard on be removed, told that dynamic maps are a "cop-out" for those too lazy to learn how to edit static maps, had to hear about how the icons on dynamic maps are too close together as if the solution to that problem weren't as simple as zooming in, and all the other petty nitpicks he's used over and over again to obstruct resolution of this issue as if his points hadn't already been addressed numerous times in the past. At some point, enough becomes enough, and it's no longer our responsibility to try to reason with him for the 5,000th time but rather his responsibility to let the issue go. And if a current featured article, again one of the most visible on the site, is what's at stake, then the time for this issue to come to a head and be decisively resolved is now.

As for Powers not being "here to defend [him]sel[f]": if he wants to do that, there's nothing stopping him. We're not all huddled in some smoke-filled room where no one can see what's happening. This is the Travellers' Pub. I can scarcely think of a more visible and accessible page on which to undertake this discussion. If Powers is an admin and a bureaucrat, he should already have the Pub on his watchlist, and if he cares enough about this issue to repeatedly revert my edits, he shouldn't need to be pinged.

Pashley - your comment about "block both users for edit warring & failing to discuss it on the talk page" is unhelpful and betrays a fundamental misunderstanding of the nature of edit wars and the policy regarding them. The fact of the matter is that the "discussion" has been over for a long time. We've already come to a consensus about whether and in what cases dynamic maps should be used. Again, this has become a case where one user's refusal to accept a consensus that hasn't gone his way has crossed the line into disruptive behavior. (I would actually argue that line was crossed several incidents ago, but at any rate the disruptive nature of the conduct should no longer be in question for anyone.) The blame for any edit war that may result from a scenario like that is certainly not shared equally by the person whose edits restore an article to the consensus-based status quo.

ChubbyWimbus - there's no reason to believe that "the edit war has stopped". It's simply proceeding at an unusually slow pace. It took Powers 30 and 19 hours, respectively, to respond to my edits at the Letchworth article, and it's only been 16 hours since the most recent volley. "What if" is still very much an apropos question. -- AndreCarrotflower (talk) 15:20, 15 October 2019 (UTC)[reply]

Andre, I think your critics are correct about this thread, in an overall-general-approximate way. This little edit war didn't need to be an edit war, and even if it happened, we didn't need 600 words telling us that the only way to get anything done is to wait for a long-time contributor to be absent.

I really think it would have been sufficient for you to post something like "Hey, Powers and I can't seem to agree about which map is better. Could some of y'all make the decision? I promise to be cool with whatever you decide." This is really too minor for anyone to get this bothered about it.

A while ago, one of my co-workers, who lives in one of those places with lots of travel warnings, sent me a chat message in the middle of his night, asking me if I had time to talk about something serious. My first thought was that one of his children had been hurt. But, no: he was just losing sleep because he was afraid there would be a big dispute on wiki over which of two slightly different options was better. Let's not have that here. Let's not actually lose sleep over which map gets used. If two editors can't sort it out amicably, then dump the dispute on the rest of us, take the page off your watchlist, secretly resolve not to participate in further discussions, and let us handle it for you. Nobody's dying. Let's not kill our friendly environment over this. WhatamIdoing (talk) 16:03, 15 October 2019 (UTC)[reply]

WhatamIdoing - We can get carried away putting "our friendly environment" on a pedestal. I've been an active Wikivoyager for going on eight years, and for most of that time, Wikivoyage was a place where debates lingered unresolved and fundamental problems festered for years because people were too "friendly" to step on each other's toes. It made me want to tear what little is left of my hair out. Thankfully that's finally beginning to change, though we've got a ways to go yet before we can truly say we've learned how to handle situations where the gears are gummed up by small but vocal minorities. We don't have to become a toxic cesspool of antisocial behavior like Wikipedia, but personally, I think taking it on the chin every once in a while and losing the occasional argument is a fair price to pay for a community where things run smoothly. -- AndreCarrotflower (talk) 16:11, 15 October 2019 (UTC)[reply]

I don't think we get carried away with a friendly environment. I don't mind a debate: That's my day job, and then I go over to the English Wikipedia and argue about how to write policies. However, I do mind seeing minor disputes personalized like this. Which map belongs on that article is not a fundamental problem that festered for years. IMO it would have been resolved much faster and with much less hair-pulling if you had decided to bow out instead of leading the attack.

One of the things that I do at the English Wikipedia is deal with questions and complaints about RFCs. One of the things that I've learned over the years is that when someone turns up with complaints about certain subjective matters ("The question is misleading!"), then it usually means "I'm losing! Help me win on a technicality!" From that POV, if you were actually confident that consensus and policy is on your side, then you could have immediately handed this whole thing over to the rest of us, without bothering to run down the other guy and without trying to explain why you're right. If you're really right, we'd come to the same conclusion, and it's easier to stop a dispute when lots of people are saying the same thing, instead of just one contributor repeating the same claim. You can still take that approach. You can still leave this to the community. I recommend doing that. WhatamIdoing (talk) 16:34, 15 October 2019 (UTC)[reply]

WhatamIdoing, I wish you would stop minimizing this issue and pretending it's just about one map on one article and inferring that I'm blowing things out of proportion. This is, in fact, merely the latest chapter in a years-long pattern of unreasonable behavior on Powers' part and unreasonable accommodation of said behavior on the community's part. I've given many examples above of past occasions on which this same pattern of behavior has caused problems for the community, and there's no reason to expect that it wouldn't continue to happen going forward. So as I see it, in responding decisively here, we have the opportunity to prevent any number of future recurrences of this pattern of behavior that we might otherwise have to slog through. That last part bears repeating: I don't want to waste my time with this dispute any more than anyone else here, but if doing so now prevents us having to continue to do so over and over again into the indefinite future, then I'm willing.

Also, given that several things are happening or being proposed here that have never occurred before on Wikivoyage, this discussion is also necessary to establish precedent in those areas: namely, what to do in a situation where someone with sysop tools is making disruptive edits and file protection would be useless to stop them, and when it's appropriate to use partial bans. Those are the kind of questions that can't be answered unilaterally by one user. If I could have avoided "leading the attack" and instead resolved this quietly using established procedures, I would have, but this is a special case.

-- AndreCarrotflower (talk) 16:50, 15 October 2019 (UTC)[reply]

I prefer the dynamic map, but I don't see it as such an important issue. I am not opposed to having two maps, particularly when they complement each other, and having both maps on the page whilst having a discussion on the talk page might have been a better approach (just putting the two maps on the talk page doesn't work as there would be no markers). I have recently been using the Kwix offline reader, and note that it (and other offline readers) don't display dynamic maps - if the park has large areas with no signal, then that is an argument for including a static map (maybe in addition to the dynamic one). Calling the static map "rather useless" in the first edit summary was not a diplomatic start to things. AlasdairW (talk) 20:31, 15 October 2019 (UTC)[reply]

Andre, I'm not minimizing the current problem or the history. I'm telling you that you (you personally) are not able to solve this problem. I'm also telling you that the more you are involved in this discussion, and especially the more you tell anyone who might disagree with you that they're wrong or bad or don't understand, the less likely this problem is to be solved this week. If you actually want this problem solved, then you have to step back and let all the people-who-are-not-Andre handle the rest of this. WhatamIdoing (talk) 16:31, 16 October 2019 (UTC)[reply]

• (edit conflict) First, Ikan Kekek and WhatamIdoing are both saying some sensible things here that do a good job of weighing up the big picture. I don't think they're either defending Powers or attacking Andre. I've looked at the static map by going to the revision by Powers and it's really not as bad as is being implied. While I believe Powers acted wrongly, and this was to some extent an edit war, it wasn't an emergency.

However, Powers' actions need to be addressed, possibly by a removal of bureaucrat rights (which is not the same as a block or a ban). Hopefully that could be done in a positive way if Powers is not willing to submit to consensus on this issue. If he can apologize and make clear he will no longer do what he did to the article, he should absolutely keep his bureaucrat rights if he desires to do so.

I've prepared a list of statements through which I hope we can come to a consensus. Are we agreed on the following?

1. Powers' actions on the Letchworth State Park article were improper and were made urgent by the fact that the article is featured. Powers should have known not to take such action on an important page, especially being a bureaucrat; such action created an unnecessary sense of division and urgency within the Wikivoyage community.
2. As the dynamic map followed consensus approval and was already established as the map for that article, it should have remained until the end of the feature. Then, its potential replacement, the static map, could have been discussed. However, acting against the standard on a featured article was improper, as stated above. We must uphold consensus, especially on our featured articles.
3. Powers needs to be told that his action is wrong, and he needs to make clear that he will not do this again.

Do we agree on any of these? If not, we need to seriously re-consider whether we can form a consensus on what to do about this issue. --Comment by Selfie City (talk | contributions) 20:41, 15 October 2019 (UTC)[reply]

SelfieCity, that sounds like a reasonable course of action and I'm in agreement with all of those points. I'd prefer, though, if for the moment we did not deviate into talking about desysopping Powers. That would be a logical next step if indeed he does revert my edits at Letchworth again, but it's far from clear that such a thing is imminent, and I'd rather not sow any more discord than necessary by speculating about a desysopping that may be moot. -- AndreCarrotflower (talk) 20:48, 15 October 2019 (UTC)[reply]

That sounds fine with me, especially if that's how you feel about it. --Comment by Selfie City (talk | contributions) 20:59, 15 October 2019 (UTC)[reply]

Like AlasdairW, I'm a fan of having both a static and dynamic map on an article when both maps offer something unique to the reader and potential traveller. They are no more redundant to each other than two photos of a famous landmark, which is quite common on Wikivoyage articles (often where one of them is a banner and the other a non-banner but sometimes when both photos are non-banners shot at different angles or in different way). Gizza ^(roam) 21:10, 15 October 2019 (UTC)[reply]

The dispute that required immediate attention has successfully been brought to the attention of the community. Perhaps next time that can be done with a little less drama. Discussions of user bans or de-sysopping can take place at the pages Ikan Kekek linked above.

With respect to the content issue, I think the dynamic map is better in this case, though including both maps would be fine too. —Granger (talk · contribs) 00:09, 16 October 2019 (UTC)[reply]

I don't understand what would be accomplished by including both maps other than rewarding Powers' bad behavior and perhaps, as a result, encouraging future incidents like this. The static map does not include any information that's not also included in the dynamic one. -- AndreCarrotflower (talk) 00:12, 16 October 2019 (UTC)[reply]

Including both maps helps people who can't see the dynamic map. This includes anyone who's reading offline or on a device that doesn't support Javascript. The existence of this benefit is completely independent from anyone's behavior. WhatamIdoing (talk) 17:03, 16 October 2019 (UTC)[reply]

Selfie, I'm sorry, but I can't fully agree.

1. I agree that Powers' actions were less than ideal, but I don't think Powers created any sense of division and urgency within the Wikivoyage community. I think the sense of division and urgency has come from the way Andre has chosen to respond to it, i.e., by insulting Powers and continuing to pound on the table instead of reporting the problem neutrally and trusting other people to take care of it.
2. I cannot agree that pages should not be edited while they're featured. Whether Powers' changes constitute improvements is IMO doubtful, but discussion should be an option at any time, and plunging forward (but not edit-warring) should normally be encouraged, even when an article is featured on the Main Page.
3. I agree that Powers needs to be told that there's a consensus to include the dynamic map (because we have generally agreed upon that, right?), and of course nobody should be edit warring. On the other half of that statement, determining whether a specific dynamic map is better than a specific static map requires people to use their best judgment. I would therefore regard any undertakings to never replace the one kind with the other kind as inappropriate and only barely credible. I do not want us to push contributors to make "piecrust promises" – as easy to make as a pie crust, and very likely to get broken when it comes time to serve the pie. WhatamIdoing (talk) 16:54, 16 October 2019 (UTC)[reply]

(indent) I now see that I didn't fully understand the issue at the beginning. For me, even though you did try to explain that it was an ongoing and common occurrence, this all appeared out of nowhere (and it seems like a similar thing happened to others). I think I agree with SelfieCity's points. On AndreCarrotflower's point about "rewarding bad behaviors" I will add that users should refrain from "I'm okay with both maps"/"I don't care either way"/"This article isn't important so who cares"/etc type of arguments. These are not legitimate arguments. It may feel like it softens the tension, but these statements only muddy the waters and stand in the face of consensus, as well as ignore the specific concerns brought up here. Those who are ambivalent should support the status quo. Arguments in favor of the static map being reinstated need to explicitly state what benefit this map provides beyond the dynamic map and/or what benefits are lost with its deletion. In other words; the inclusion/reinstation of the static map must have a reason that is consistent with policy and consensus. Saying both are okay out of apathy towards the city/article/issue are not helpful and not fair to Andre who is acting according to consensus. And indeed if we made concessions on such a weak basis, it would be an invitation for anyone who wants to disregard a policy in the future to do so with a citation of this discussion for which we wouldn't have any defense. ChubbyWimbus (talk) 11:39, 16 October 2019 (UTC)[reply]

Actually, I think that all of those are legitimate arguments. If there are reasons to have both maps, or at least not harm, then we should say so ("I'm okay with both"). If the two maps have an equal balance of advantages/disadvantages, then that's important to call that out ("I don't care either way"). And if the cost to the community to see a pile of insults, to deal with people's emotional reactions, and the hours of people's time spent looking into this is much higher than the cost to the article of having one less-than-perfect map or the other also less-than-perfect map, then we should say that, too ("isn't important"). It's perfectly reasonable of me and others to point out that the immediate "urgent" problem could be trivially solved by Andre washing his hands of the whole thing and the rest of us camping out on RecentChanges for a few days, instead of someone actively involved in the edit war coming here to complain at very great length about an "unreasonable", "fanatical and disruptive" contributor on a "one-man anti-dynamic map crusade" "who can't handle the idea of consensus disagreeing with him" over "petty nitpicks" about which single map is better. WhatamIdoing (talk) 16:42, 16 October 2019 (UTC)[reply]

I agree with WhatamIdoing on all the numbered points, & the post just above as well. Pashley (talk) 18:11, 16 October 2019 (UTC)[reply]

WhatamIdoing and Pashley - No. What ChubbyWimbus said about the illigitimacy of arguments in favor of duplicate maps is exactly right. We have a consensus that dynamic maps are preferred in all articles that aren't regions, that articles should in most cases contain only one map each, and that multiple maps should never be used in the same article to display the same information. That consensus took a lot of time and a lot of hard work to forge. And it is binding. It doesn't just magically disappear whenever its existence is inconvenient vis-à-vis the resolution of an unconnected issue, or for the sake of not making waves and the maintenance of a "friendly environment", or because you personally disagree with and/or weren't involved in building that consensus, or because you personally don't think enforcing policy is important in this particular case, or because you personally think the person on the opposite side of the debate from you is a jerk, or for any other reason. If you're going to argue in favor of duplicate maps on Letchworth, you had better thoroughly read the thread I linked to above, and you had better come up with arguments in favor of duplicate maps that both 1) were not previously advanced and 2) are convincing enough to get all those who argued the opposing side to change their minds, or 3) you had better come up with a pretty convincing reason why Letchworth is the exception that proves the rule and is different from all the other articles on this site that do just fine with one or the other kind of map. Otherwise, sorry, but status quo bias applies, and the pro-duplicate maps arguments at issue in this discussion should be dismissed as non-policy-based. -- AndreCarrotflower (talk) 21:51, 16 October 2019 (UTC)[reply]

I agree with Andre, though I do continue to maintain that, all things being equal, static maps are better, and I continue to argue for exceptions to the general consensus for static maps that are complete, up-to-date and clearer than dynamic maps in any article. Ikan Kekek (talk) 22:05, 16 October 2019 (UTC)[reply]

Also, WhatamIdoing, regarding the tone of my original post: consider that out of all of us in this discussion, I'm the only one who came into it remembering offhand all the previous map-related incidents with Powers. A huge proportion of my original post was dedicated to rehashing the history of the conflict for the benefit of those who needed to be reminded or weren't here at the time, in hopes that people would respond to this not as an isolated incident but as the further escalation of a problematic pattern of behavior going back years. Which people did anyway, thus causing me further frustration. If because of that I came off as excessively vindictive toward Powers and/or a drama queen in general, that's unfortunate and was not intentional, but better that than failing to put the Letchworth incident in its proper context. And yes, Powers' overall behavior pattern remains an important consideration even if a lot of editors don't personally remember the past incidents. That's exactly the reason we archive old talk page discussions rather than simply deleting them.

Also, if I used some incendiary language in my original post, I apologize, but also consider that I'm a human being with emotions, and I just got done having my consensus-based edit reverted for the second time in a row, and that ever since I first changed the static map to dynamic during the final preparations before Letchworth's stint as OtBP, I kind of had it in the back of my mind that he might show up and make trouble. So yeah, I was a little miffed, as anyone would be, and maybe I let it show a little too much in the tone of what I wrote. Regardless of that, it remains incumbent on anyone responding to this thread to look past my choice of vocabulary and focus instead on the actual issues I'm conveying. And, most importantly, to not fail to see the forest for the trees.

- AndreCarrotflower (talk) 22:31, 16 October 2019 (UTC)[reply]

I think that it may be time to review our draft policy at Wikivoyage:Map, which has been a draft for two years. The "Should I replace a static map with a dynamic map?" section seems to be relevant here. However it may be better to do this next month so that we are not too focussed on one particular article. AlasdairW (talk) 23:04, 16 October 2019 (UTC)[reply]

The maps aren't duplicates if they are not the same. I agree with WhatamIdoing and Pashley. Saying that having both maps improves the article is very much a legitimate argument. Being forced to pick one when neither are adequate on their own if anything is an argument that's detrimental to the traveller. I also agree with AlasdairW that it's time to review the draft policy on maps. Gizza ^(roam) 00:28, 17 October 2019 (UTC)[reply]

I'm confused by this reply. How are the maps not the same? -- AndreCarrotflower (talk) 00:32, 17 October 2019 (UTC)[reply]

We could easily have 5 different kinds of maps, but in what way does that serve the traveler? This is not an atlas focusing on different ways to map a given city. The only uses for different maps, really, are when they're necessary to show different things. Ikan Kekek (talk) 00:40, 17 October 2019 (UTC)[reply]

I tend to agree with Ikan Kekek that the static maps are overall better when all things are in fact equal, but that is quite often not the case, and in this article, the static map doesn't have any listings, so I don't think it could be argued to be better. I definitely don't think the static map should always be the one to go either (I'd still like to delete the hideous dynamic maps in the Japanese region articles). WhatamIdoing, Having an established consensus or policy means you don't have to address the emotional reaction of users to the issue. You only need to refer to the consensus. I think telling users that consensus "isn't important" because their issue is not your issue is unfair. If an issue is brought up and consensus is suddenly invalid because a group of users decides they just don't want to hear you whining/they don't like you/they don't like the consensus/etc then when is it valid? Because it's going to sound like your argument is "Consensus matters when I care about the issue and the consensus is with me, but it doesn't matter when YOU care regardless." I don't foresee that being superior to or leaving users feeling better than referencing policy or consensus. As I said, users who truly don't care should be fine upholding the status quo. If you are not okay with that then there must be something that you DO care about. ChubbyWimbus (talk) 11:36, 17 October 2019 (UTC)[reply]

I agree with this post completely. Ikan Kekek (talk) 13:25, 17 October 2019 (UTC)[reply]

Chubby, the question of whether all of us are being asked to do w:en:emotional labor because someone was upset over an edit is completely separate from whether there's a consensus about which map is best for the article. There are things that I DO care about: I don't want to read insults here. That matters to me. I don't want to read a note that makes me think, "Oh dear, he must think none of us remember that long slog" or "he's losing his temper" or "it doesn't sound like he respects the community's ability to take care of even trivial problems like this". I care about how people treat each other. Our track record in this conversation is getting better, but it started off pretty poorly.

For those who remember the previous discussions around maps, you'll remember that I'm pretty solidly pro-dynamic map. I'm able to hold that position while acknowledging that they have some limitations (e.g., not being available to offline readers, which is kind of a big limitation in a community that lists printed copies as an official goal). My concerns here are less about the map (I trust the community to handle it, and we have), and more about the "meta" question of how we handle disputes. I hope that in the future, it will be with fewer insults, less badgering, and more trust that "there's a consensus" means that you don't need to do it all yourself, because the people who formed that consensus can and will take care of any disputes for you. WhatamIdoing (talk) 16:30, 18 October 2019 (UTC)[reply]

I apologize unreservedly. First, for the second reversion to the article to include the static map without discussing it first, and second, for the delay in responding.

It's no secret I've not been active on Wikivoyage for a while. But while I was surprised to find an article I'd started and worked on as a featured article, I was shocked and dismayed to find the map I'd taken a similar amount of time to create had been unceremoniously removed just one day before being featured -- and with a snide edit comment to boot. I found the wholesale removal of content that took me quite some time and effort to add to the article to be inappropriate without discussion. The dynamic map is not a longstanding feature of this article (even now, it's been there less than two weeks), so I felt comfortable reverting to status quo ante with an edit comment explaining that the dynamic map better shows how to get in. (Andre has interpreted this to mean "the dynamic map didn't show entrances", but it goes beyond that; the static map also shows highway and trail approaches, nearby landmarks and communities, expressway exits, etc.) As a compromise, you'll note I didn't *revert* the edit that removed the static map; I re-added the static map and shrunk the dynamic map to compensate.

If Andre disagreed with this compromise, he could have discussed it. Instead, he simply reverted it unilaterally. I shouldn't have undone the reversion, but I still maintain it was inappropriate. And I certainly reject the argument that an article's current status as featured on the front page means that edits made just one day before are sacrosanct and shouldn't be undone.

And of course this thread is horrifying to me. I'm a bit conflict-averse (which is why I've not responded until now), and this thread isn't exactly encouraging when I consider where I should spend my time.

-- Powers ^(talk) 13:15, 23 October 2019 (UTC)[reply]

I should also point out that the reason none of the POIs are on the static map is because I always intended to add a second map showing just the southern portion of the park, where most of the POIs are, at a larger scale for readability. The crowded nature of the POIs is quite obvious in the dynamic map, which is why I find it unsuitable. Powers ^(talk) 13:17, 23 October 2019 (UTC)[reply]

Looking back several days later over the way I conducted myself in the above thread, I have to reluctantly agree with some of my critics that my zeal to resolve this dispute and bring everyone back in line with consensus tipped over a few times into personal attacks against Powers. Despite the fact that the two of us often don't see eye to eye on issues related to the site, and we can both be pretty stubborn about our viewpoints when we want to be, I still consider Powers a colleague and friend. And I should not have let myself lose sight of that just because of our exchange at the Letchworth article. So, Powers, please accept my apology for those things.

However, another thing that anyone worth his salt does for a colleague or friend is to call him or her to account when necessary. And for the most part, I stand behind the substantive parts of what I've said. As far as the points in your above comment: Powers, you've made your feelings about dynamic maps known ever since we rolled the feature out, and this is far from your first clash with other editors on the issue, so perhaps the reason for my "snide edit summary" was because I couldn't help but see your act of reverting my edits to the Letchworth article through that prism. As for the amount of time it took you to create the static map for Letchworth, is that not a pretty cogent argument against using static maps for bottom-level destinations? You may be willing to donate large amounts of your uncompensated time to 1) learning how to make static maps and 2) making individual static maps for every article you work on, but how many other editors is that true of? I can count them on one hand: you, Ypsilon, Saqib, and Shaundd; and Ypsilon is the only one out of those four who's more than sporadically active on this site. Is letting articles for bottom-level destinations go without maps, or (more apropos to this case) sticking them with static maps that quickly become outdated for want of anyone who knows how and/or has the time to update them, really a better solution than presenting the same information in a less aesthetically perfect but easier-to-keep-up-to-date way? The answer is no, not only according to me but also according to consensus. (And if you really had "always intended to add a second map showing just the southern portion of the park, where most of the POIs are", why didn't you do so at any time during the 15-month period between Letchworth's nomination as DotM and its Main Page debut, especially given that its map-related deficiencies had already been singled out as a problem?)

-- AndreCarrotflower (talk) 16:19, 24 October 2019 (UTC)[reply]

Thank you, Andre.

For the record, the edit summary to which I referred came from your initial removal of the static map, before I re-added it.

It's certainly true that some map is better than no map, and outdatedness is certainly a problem in many areas of the site (not just maps). But I'm not aware of anything in the Letchworth map actually being out of date (at least not significantly so), and I maintain it was bad form to make the replacement without discussion or preamble (especially just one day before it was to go up on the Main Page).

-- Powers ^(talk) 01:24, 25 October 2019 (UTC)[reply]

The wishlist for this year opens today. There will be only five wishes accepted, and they are only for non-Wikipedia sister projects. m:Community Wishlist Survey 2020/Wikivoyage is currently empty.

I have notes about two ideas that we considered last year:

• Playing audio inline for Wikivoyage phrasebooks: Imagine being able to read the phrasebook, click a button, and hear the word being pronounced without leaving the page. (phab:T20852) This might also be interesting to the Wiktionaries.
• Further map improvements: Disputed borders (phab:T113008) is one of them, but we could probably think of several map improvements.

Does anyone have any other ideas? WhatamIdoing (talk) 17:05, 21 October 2019 (UTC)[reply]

I think the most important enhancement that is needed is to have current position marked on dynamic maps. Particularly important as most web users are now mobile users, and knowing what is near you is a crucial feature for any travel/location guide. (phab:T208713) --Traveler100 (talk) 17:47, 21 October 2019 (UTC)[reply]

The location map thing should be relatively easy (I naively think) since the mobile version already finds articles for nearby places.

Isn't the audio file on the same page thing already possible? There are definitely inline audio files in use on Wiktionary, e.g.. Has this somehow passed us by? --ThunderingTyphoons! (talk) 18:03, 21 October 2019 (UTC)[reply]

We worked on the inline audio thing for a while, and I don't think we got it sorted out. When I click on the audio icon at German phrasebook#Numbers, it opens a new tab for me. WhatamIdoing (talk) 18:05, 21 October 2019 (UTC)[reply]

How hard can it be to just use whatever system they use on Wiktionary? --ThunderingTyphoons! (talk) 19:41, 21 October 2019 (UTC)[reply]

I guess it was hard enough that we didn't figure it out? WhatamIdoing (talk) 15:30, 22 October 2019 (UTC)[reply]

User:TheDJ wrote phab:T208713. WhatamIdoing (talk) 18:07, 21 October 2019 (UTC)[reply]

How about the ability to reorient dynamic maps in directions other than strictly up is north, down is south? In maps of Manhattan, up should be uptown, not strictly north by the compass. However, I disagree that we would want to show "disputed borders". That's against Wikivoyage policy of recognizing all reasonably stable faits accomplis and not getting into disputes, except inasmuch as they affect the traveler. Ikan Kekek (talk) 19:59, 21 October 2019 (UTC)[reply]

Look at a dynamic region map like on Chugoku or Japan. The shaded regions for each prefecture or region are including territorial water, because that's what the OSM relation for an administrative boundary represents. Unfortunately that's pretty ugly compared to the static map, which simply shows land that's part of each prefecture. AFAIK there's not an OSM entity that represents that; you'd have to compute it programmatically. --Bigpeteb (talk) 22:41, 21 October 2019 (UTC)[reply]

I agree with User:Traveler100—the most important feature needed is showing the user's location on dynamic maps. I also agree that it seems like we should be able to include audios the same way Wiktionary does. User:Bigpeteb's suggestion not to show territorial waters would be nice too. —Granger (talk · contribs) 23:33, 21 October 2019 (UTC)[reply]

Oops... I have create task about Add maps of sightseeing spot to help visitors find nearby sightseeing spots and information through maps, but not first to discussed in Travellers pub here, I am so sorry...--✈ IGOR ／ ✉ TALK?! ^{．WIKIVOYAGER !} 13:46, 27 October 2019 (UTC)[reply]

• What about a way to draw polygons (to form districts and regions) directly onto the mapshape? --Comment by Selfie City (talk | contributions) 01:51, 22 October 2019 (UTC)[reply]

  @SelfieCity: This is doable now. I don't remember exactly how, but I remember it's a pain in the butt. You have to create a standalone file somewhere else on the wiki that has the coordinates of the polygon, which you then link to somehow in the map. I've seen examples before but don't have time this instant to find one, but if I had one (maybe you can link me to one you know of) I can dissect it to explain how it's done. --Bigpeteb (talk) 19:19, 31 October 2019 (UTC)[reply]

• The wishlist should have regard to whatever the readership are saying is most deficient at present. It should therefore include full mobile functionality both for reading and editing. i-phones in their present guise have been around for nigh-on a decade, a rock of stability in a maelstrom of innovation, imagine if we'd taken that long to adapt to the Blackberry. While this wish applies to all WF projects, it's particularly pressing for WV which is the most likely to be accessed on the go. I'm guessing work is in hand but how visible is it, eg with a project page, objectives and timescales and all that managerial good stuff, and a forum to debate project components? It's more than just a nice-to-do. And beyond that, we need to think ahead of the technology, and consider maximum voice-activated functionality. Alexa and her successors could become the predominant search method in the coming years, and WV needs to be positioned as first choice to answer such travel-related queries. Grahamsands (talk) 14:37, 24 October 2019 (UTC)[reply]

I couldn't agree with you more strongly! And when I had an Android, the user interface sucked for that, too, but it's worse for the iPhone. Ikan Kekek (talk) 23:44, 24 October 2019 (UTC)[reply]

What about the mobile display of pagebanners? Is that something we could fix in-house, or does it need a change in the media wiki software? --ThunderingTyphoons! (talk) 12:43, 9 November 2019 (UTC)[reply]

The deadline is Monday

We've got about 60 hours to get this finished. So far, the proposals made are:

• Add maps of sightseeing spot to help visitors find nearby sightseeing spots and information through maps
• Show user's current location on maps
• ContentTranslation work for Wikivoyage
• Comments in Local Time
• Special page "Nearby" should show an input form and coordinate picker when geolocation is deactivated

(The "Comments in Local Time" script isn't really specific to Wikivoyage (that could be useful to any project), so it might be declared out of scope. The others are specific to Wikivoyage, but any proposal has a chance of being considered too big for this team to fulfill.)

What else do we want to add to the list? Keep in mind that theoretically Wikivoyage could win all five wishes. The proposals are being sorted according to project, but there's no rule saying that the results have to be evenly divided between the sister projects. WhatamIdoing (talk) 19:26, 9 November 2019 (UTC)[reply]

• I have added request for Wanted Pages to show only results of redlinks from main article namespace. --Traveler100 (talk) 06:21, 10 November 2019 (UTC)[reply]

https://hyperallergic.com/523009/peregrinatio-in-terram-sanctam-british-museum/ —Justin (koavf)❤T☮C☺M☯ 15:45, 22 October 2019 (UTC)[reply]

It seems from the pictures more like an illustrated atlas than a travel guide but is still a fascinating piece of historical reference material. --Comment by Selfie City (talk | contributions) 19:27, 22 October 2019 (UTC)[reply]

Interesting indeed. Thanks for posting it.

But arguably it is not the first; the ancient Greeks had books a few centuries BCE that listed the Seven_Wonders_of_the_Ancient_World & for all I know the Chinese, Indians or Persians may have had something earlier as well. Pashley (talk) 02:02, 23 October 2019 (UTC)[reply]

-- Johanna Strodt (WMDE) 09:47, 23 October 2019 (UTC)[reply]

Hi, Johanna, and welcome to Wikivoyage. I believe that ref tags are almost entirely unused on Wikivoyage. It's probably not necessary to send updates here for this project. (I don't know if it's worth changing the whole mailing list over, though...) WhatamIdoing (talk) 17:30, 23 October 2019 (UTC)[reply]

More than that, they're against this site's external links guidelines. Ikan Kekek (talk) 17:35, 23 October 2019 (UTC)[reply]

Not all uses of ref tags necessarily involve external links.

At the moment, we seem to have 47 pages with ref tags, but only a few (example, another) actually display to readers. These are probably people who are used to Wikipedia's rules about how to link, and just need to be reformatted. Most of these 47 ref tags are related to climate boxes and aren't displayed to anyone. WhatamIdoing (talk) 17:01, 24 October 2019 (UTC)[reply]

So I recently took a second job as a GrubHub driver, and I had a few things to say in the American cuisine article about tipping conventions when using app-based food delivery services like mine (the situation is a little more nuanced than the typical $2-5 cash you give to the pizza guy). I'd like to also include the same information in the article on tipping, but the problem is, I'm not sure if what I said applies worldwide or if it's germane to the U.S. only. I imagine app-based delivery services would likely work differently in countries where tipping practices are very different from the U.S. Are there any Wikivoyagers living outside the U.S. who have experience with these apps and can confirm what the procedure is for tipping drivers in their home country? If not, should this information go in the Tipping article anyway, even with a disclaimer that it applies to the U.S. or North America only? -- AndreCarrotflower (talk) 14:26, 26 October 2019 (UTC)[reply]

Here in China, tipping is rare. I've never seen anyone tip delivery people here, and the two delivery apps I use have no option to add a tip as far as I can tell. —Granger (talk · contribs) 15:04, 26 October 2019 (UTC)[reply]

To the best of my knowledge those services are not really "a thing" yet in Germany, most likely due to regulatory issues. Lieferando and the likes exist but they work differently from uber eats and whatnot in that (to my knowledge) they also put price pressure on the restaurants... Hobbitschuster (talk) 17:18, 26 October 2019 (UTC)[reply]

I know that Uber and Lyft drivers tend to prefer cash tips. Is that the same for Grubhub drivers? Ikan Kekek (talk) 18:11, 26 October 2019 (UTC)[reply]

Although app and phone based takeaway ordering is common in the UK, I am not a regular user. Just Eat say only a third of customers would regularly tip, and its notes for drivers say that they may not request a tip. AlasdairW (talk) 21:22, 26 October 2019 (UTC)[reply]

This is all very interesting. I can't claim firsthand experience with other apps, but in the U.S., GrubHub actually makes it extremely difficult not to tip. The app interface defaults to a tip of 20%; anyone who wants to decline to tip not only has to manually change that to zero but also click through a guilt-inducing "Are you sure?" pop-up window that explains about how "drivers are GrubHub's most indispensable asset" or somesuch. It sounds like, even if food delivery apps in some other countries may offer a way to tip the driver, they're unlikely to be quite so insistent about it, so the advice I added to American cuisine is probably not germane to a non-country-specific tipping article.

Ikan Kekek - I suppose if you were to survey GrubHub drivers about it, you might hear a mild preference for cash tips, but the different ways in which the GrubHub app handles tips by comparison with Uber/Lyft make it an apples-and-oranges comparison. With Uber and Lyft, tipping happens (or doesn't happen) only after the ride is over; if a prospective passenger has a low star rating, a driver might interpret that as a sign that s/he might be a bad tipper, but that's not foolproof, and indeed star ratings can be based on any number of factors. With GrubHub, tipping is done in advance; the driver is told upon receiving the delivery offer how much the customer has tipped and then goes on to accept or reject it based on that information. There's a "notes" section in the app where the customer can indicate if s/he intends to tip in cash, but there's no guarantee the driver will bother to read it, and the universal assumption among drivers is that a zero tip is a zero tip, not an indication of intent to tip in cash.

-- AndreCarrotflower (talk) 05:23, 27 October 2019 (UTC)[reply]

I think UK apps default to no tip. One regular user of an app complained that the app had no way of setting a preferred default tip, it had to be selected each time. We could have country specific advice on tipping drivers, and also saying something about how the drivers are paid. In the UK there is possibly a stronger argument for tipping drivers than waiters - waiters are employees and must be paid the minimum wage for every hour they work, but drivers for apps are usually "self employed", and get paid per delivery. AlasdairW (talk) 13:41, 27 October 2019 (UTC)[reply]

Here in Finland I suppose the drivers are not tipped (except in special circumstances): They are very badly paid, without any employment based social security, but I don't see that as a reason to tip, rather to boycott the delivery services unless you find one offering decent employments. --LPfi (talk) 20:29, 28 October 2019 (UTC)[reply]

11:13, 29 October 2019 (UTC)

One of the areas where I think we have a lot of room for improvement is in copy editing. Some fixes (such as my ongoing war against improper comma usage that some of you may have noticed) will probably just need to be done manually, but others, such as typo corrections, could probably benefit from taking inspiration from the Wikipedia Typo Team's automated and semi-automated tools, and I think it might be good to have an expedition to look into that. There are also WV-specific fixes we could implement, such as correcting improperly formatted phone numbers. I can't commit to keeping such an expedition all that active (I just don't have that sort of free time), but I do think it'd be a good idea to have a dedicated space for us to search for more systemic ways to clean up all the small errors that can make WV seem less professional if unaddressed. Sdkb (talk) 07:15, 30 October 2019 (UTC)[reply]

https://ux.nearsoft.com/blog/travel/how-to-reach-female-solo-travelers-the-biggest-market-in-the-us/ —Justin (koavf)❤T☮C☺M☯ 18:53, 30 October 2019 (UTC)[reply]

It seems they interviewed seven women and then tell what "FSTs" do, reporting percentages and whatever. Did I miss something? You don't need a large random sample to get interesting viewpoints, but if you want to tell what a group like that thinks as a whole, a decent representative sample helps a lot. --LPfi (talk) 20:45, 30 October 2019 (UTC)[reply]

I got a notice a few minutes ago that someone has made multiple failed attempts to log in to my account from a new device. I would suggest that everyone make sure you have a good password, and whoever is savvy about security, please monitor the situation in whatever way you do. Ikan Kekek (talk) 21:44, 3 November 2019 (UTC)[reply]

I suppose cracking an account by trying to guess passwords manually is a quite futile attempt, unless they have some clue, like having got a password from another site and trying variations of it (or using your cat's and girlfriend's names, with variations, if you use that kind of passwords). If you deem there is such a risk, you might want to change your password.

The real risk, which motivates good passwords, is that somebody might find a way to try passwords on their own machine(s) or a way to bypass the tries-per-minute limits of the server. Then they might try billions of variations and in the former case you never know until they log in with the correct one.

--LPfi (talk) 14:57, 4 November 2019 (UTC)[reply]

Does Wikivoyage have 2-factor authentication? I know Wikipedia does, but that it's still only available to admins. Sdkb (talk) 18:26, 4 November 2019 (UTC)[reply]

I believe that "2FA" is available to any admin on any WMF-hosted project. Also, there are a couple of workarounds for non-admins, if someone really wants it. WhatamIdoing (talk) 03:03, 5 November 2019 (UTC)[reply]

I'm not too worried about someone hacking my password, but I thought it was good to alert people that someone was trying. Ikan Kekek (talk) 20:51, 8 November 2019 (UTC)[reply]

As can be seen, it is sometimes difficult to keep the information on wikivoyage up-to-date. Interaction between wikivoyages must help maintain these updates. Here is my idea to help. And this can work in any direction (understand this as the linguistic versions of wikivoyage). Here is what the application would offer:

1. The application searches in the English wikivoyage for a page containing a listing whose update is older than a certain date or never update.
2. The application "save" as "note" the name, alt and lastedit parameters.
3. The application searches in other language versions (interwiki via wikidata) a "listing" whose name or alt is closest to one of the previous elements and whose lastedit is later than ours, at best. At worst, it searches for the text in a section containing the element.
4. The application displays the publisher of the listings of the version as well as the source code of the element (listing or section) of each of the other languages
5. We update the elements according to the reading thus compared and save.

Here is a summary of the work that we could do the application. What do you think ? So yes we have ideas, but to implement them, there are fewer people. But the idea is to have a fairly well structured project and advance to submit to "programmers". Crochet.david (talk) 11:18, 11 November 2019 (UTC)[reply]

The ideas of being able to compare a similar listing on another language sounds interesting. Would have to be an interactive compare and the user able to chose what is transferred. Maybe something similar to the synchronise to Wikidata options in the listing editor. Also rather than an interactive run on a page, which will probably very often not give any useful results, how about a batch run of the whole site and mark any candidate listings will a tag (and category) that is only visible with the ErrorHighlighter gadget active (similar to what we do with dead links {{Dead link}}). --Traveler100 (talk) 18:21, 11 November 2019 (UTC)[reply]

We certainly need something, which has to involve automatic translation, because the task is much bigger than updating listings. There are whole major destinations that are barely a series of headers in some common languages. And look at the size of the active contributorship: in the last hour English WV had 52 updates, German had 15, Russian 12 and French 12. Spanish had 11 the entire day, Hebrew 19 and Mandarin 31. Human editors can't remotely keep up. However we need to pause and consider whether WV and indeed the entire WMF can stay with the current model, of versions in multiple languages. The combination of better translations and 5G transmission suggests a future model of a single version, which is translated in real time into any known language; and in reverse for contributions. Do we see this happening soon, or is it away off? Grahamsands (talk) 23:42, 11 November 2019 (UTC)[reply]

E.g. German wikivoyage is already ahead of this discussion. They move some information to wikidata and thus the basic information could easily be shared between language editions, automatically. Description would obviously have to be translated (or private to each WV language version), but that part doesn't usually change too much, compared to emails, phone numbers etc. For example - Bergschänke hotel in Halle (Saale) / Q42298625 -- andree.sk(talk) 07:28, 12 November 2019 (UTC)[reply]

At this point we will still need human translators, since computer translations are still awkward. Some idiomatic phrases and other expressions are extremely difficult to translate, and may not even have an equivalent in other languages. My Japanese is far from fluent, but even at my level, I am still able to spot and correct some mistakes made by Google Translate, so it's still a long way off before automated translation between different language versions of WV can become a reality. The dog2 (talk) 05:29, 13 November 2019 (UTC)[reply]

Agreed. Speaking as a polyglot and a translator, machine translation is a nonstarter as far as I'm concerned. The technology has a long, long, long way to go before machine translation programs get even basic grammar rules correct on a consistent basis, let alone can capture all the subtle nuance and colorful idioms and metaphors that human-generated language includes. -- AndreCarrotflower (talk) 14:59, 13 November 2019 (UTC)[reply]

I think we can agree that the qualitative information of a listing (i.e. the written description in the 'content' field and where appropriate the 'directions' field) will need to be a translated by humans for the foreseeable future. What I do think is worth exploring is whether, as Andree (SK) was suggesting the Germans are already doing, we can make automatic sharing of the 'quantitative' information (i.e. the address, phone number, website, pricing etc) easier to share across the different language versions of Wikivoyage. We already use Wikidata to quickly share the lat and long of a POI (with admittedly mixed results based on the differences in priority between us and Wikidata, or us and the encyclopedia) across the projects, so it is worth considering what else we can automatise to make our limited manpower more efficient.

As an unrelated aside purely triggered by Andre (NY)'s first sentence, I am moved to celebrate the fact that we have an overwhelmingly multilingual community, when compared even to English Wikipedia, with its much larger editorship.--ThunderingTyphoons! (talk) 15:53, 13 November 2019 (UTC)[reply]

A short lecture about tourist-related problems and solutions in Prague. Relates to responsible travel and common scams. /Yvwv (talk) 17:40, 24 October 2019 (UTC)[reply]

I should have watched this sooner! What a great short talk, and some fun ideas he's had!

The question it raises is what WV policy should be on something like his #honestlamp. What he did is akin to us writing "Admire the lovely wrought-iron statue, and be sure to touch the lamp to its right for good luck and fortune." Is it okay for us to write that now, even though it's a modern 'tradition' that people have only been doing for less than a year? Since WV is not WP and our tone is different, surely we're okay not saying "There used to be a tradition of putting locks on the artwork, but instead...". Would it even be okay for WV to do what he did, and use ourselves as a force for positive change by creating a new tradition whole cloth as he did with #honestlamp? --Bigpeteb (talk) 17:34, 6 November 2019 (UTC)[reply]

I understand the desire to get high-minded and effect positive change, I really do. But the nature of the problem of overtourism, or even whether it is a problem, is a contentious issue about which there are cogent arguments on both sides. In situations like this, where the right answer is not obvious and taking a stand might generate ill will among a certain faction of our readers or even our editors, we should remain neutral, just as we do in the case of contentious political disputes. Our job is to provide people with information, not to tell them how to use that information. -- AndreCarrotflower (talk) 17:39, 6 November 2019 (UTC)[reply]

What are the two sides to overtourism? I don't think I've ever heard any argument (cogent or otherwise) in favor of it. WhatamIdoing (talk) 19:01, 7 November 2019 (UTC)[reply]

just how much tourism is "too much"? The "argument in favor of overtourism" could be heard recently at a CDU (German center right "natural governing party") party convention "We are the party of those who fly to Mallorca" prompting the attendants to "spontaneously" sing a song about getting drunk on MallorcaHobbitschuster (talk) 22:13, 7 November 2019 (UTC)[reply]

Overtourism means so many people visiting that there are traffic jams, trouble visiting the attractions that interest you, an inability for locals to afford living there, accidental destruction of sites (e.g., too many people climbing the historic stone stairs = no more stairs), etc. I doubt that "the party of those who fly to Mallorca" want Mallorca to have these problems, and if most people stopped going to Mallorca, they might be pleased by the results.

"How much is too much?" is partly a matter of subjective perception (any amount of tourism that raises *my* rent is a problem; an amount of tourism that raises *your* rent is okay), but there are some cases that aren't seriously disputed by anyone (e.g., safety during Mecca pilgrimmages and some fragile ecosystems). WhatamIdoing (talk) 23:33, 7 November 2019 (UTC)[reply]

In some travel topic and destination articles we talk about this, in others we hint at it. E.g. in Europe we talk against hurrying from one of the iconic sights to the next and we have Sustainable travel and Leave-no-trace camping. We should tell people not to touch that statue. Describing a until now non-existing ritual as the real one is a step too far, but we could describe the alternative as a "what about instead ..." (both for the statue and for queuing to see Mona Lisa). I think most of this is non-controversial.

Then we have two real problems: we do highlight the "top attractions" whether or not a less visited attraction would be equally nice – and we join in marketing that last untouched paradise. We do some good things about this and more could be done, but there is no complete solution.

--LPfi (talk) 09:15, 8 November 2019 (UTC)[reply]

Wikivoyage can promote underrated and less exploited destinations near the most visited ones. Articles such as Metropolitan Venice can be expanded a lot beyond Venice itself. /Yvwv (talk) 10:50, 8 November 2019 (UTC)[reply]

There are also nearby cities like Padua, where many people stay to save some money and take day trips into Venice. They also have worthwhile sights. My observation about the Venice guide is that there are many more sights that could be listed, which I know just from having looked at a bunch of photos taken by people like Commons user Moroder, and it would be best for Venice to be districted on this site, which would help to promote areas other than the core tourist sights of San Marco and so forth. I've never visited Venice myself, so I won't take the lead in such work, but that's what I think would be ideal. Now, as for not stating what the top sights are in a given city, it would ill serve a visitor to Siena not to know what they are, especially if they have limited time, and there's a reason why many of the top sights ar