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).
@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]
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]
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:
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.
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.
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: 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.
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.
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,511 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]
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]
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]
A new beta feature will soon be released on all wikis: The FileExporter. It allows exports of files from a local wiki to Wikimedia Commons, including their file history and page history. Which files can be exported is defined by each wiki's community: Please check your wiki's configuration file if you want to use this feature.
The FileExporter has already been a beta feature on mediawiki.org, meta.wikimedia, deWP, faWP, arWP, koWP and on wikisource.org. After some functionality was added, it's now becoming a beta feature on all wikis. Deployment is planned for January 16. More information can be found on the project page.
As always, feedback is highly appreciated. If you want to test the FileExporter, please activate it in your user preferences. The best place for feedback is the central talk page. Thank you from Wikimedia Deutschland's Technical Wishes project.
@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]
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]
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]
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]
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]
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).
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]
Talk to us about talking
The Wikimedia Foundation is planning a global consultation about communication. The goal is to bring Wikimedians and wiki-minded people together to improve tools for communication.
We want all contributors to be able to talk to each other on the wikis, whatever their experience, their skills or their devices.
We are looking for input from as many different parts of the Wikimedia community as possible. It will come from multiple projects, in multiple languages, and with multiple perspectives.
We are currently planning the consultation. We need your help.
We need volunteers to help talk to their communities or user groups.
You can help by hosting a discussion at your wiki. Here's what to do:
Next, create a page (or a section on a Village pump, or an e-mail thread – whatever is natural for your group) to collect information from other people in your group. This is not a vote or decision-making discussion: we are just collecting feedback.
Then ask people what they think about communication processes. We want to hear stories and other information about how people communicate with each other on and off wiki. Please consider asking these five questions:
When you want to discuss a topic with your community, what tools work for you, and what problems block you?
What about talk pages works for newcomers, and what blocks them?
What do others struggle with in your community about talk pages?
What do you wish you could do on talk pages, but can't due to the technical limitations?
What are the important aspects of a "wiki discussion"?
You can also help build the list of the many different ways people talk to each other.
Not all groups active on wikis or around wikis use the same way to discuss things: it can happen on wiki, on social networks, through external tools... Tell us how your group communicates.
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]
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]
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.
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]
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]
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]
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]
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]
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.) OhanaUnitedTalk page03: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. OhanaUnitedTalk page03:42, 3 April 2019 (UTC)[reply]
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]
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.
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]
Wikivoyage is A and the other travel websites are B. They are not the same as us but there is still overlap. And one of our ultimate goals should be to become the first source most people on the internet choose to use to learn about the intersecting travel knowledge.
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]
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]
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]
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]
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]
A proposal for WikiJournals to become a new sister project
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)
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) OhanaUnitedTalk page23: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]
Wikivoyage's YouTube channel requires more language administrators
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]
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]
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]
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]
Disruptive editing at current OtBP Letchworth State Park which requires immediate attention
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.
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]
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 exceptLetchworth 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]
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.
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?
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.
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.
Powers needs to be told that his action is wrong, and he needs to make clear that he will not do this again.
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]
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.
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.
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.
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.
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]
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.
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]
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]
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.
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?)
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).
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.
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.
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]
@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]
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]
A new beta feature will soon be deployed to your wiki: Reference Previews. As you might guess from the name, this feature gives you a preview of references in the article text. That means, you can look up a reference without jumping down to the bottom of the page.
Reference Previews have already been a beta feature on German and Arabic Wikipedia since April. Now they will become available on more wikis. Deployment is planned for October 24. More information can be found on the project page.
As always, feedback is highly appreciated. If you want to test Reference Previews, please activate the beta feature in your user preferences and let us know what you think. The best place for feedback is the central talk page. We hope the feature will serve you well in your work. Thank you from Wikimedia Deutschland's Technical Wishes project.
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]
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]
App-based delivery services, tipping, and the American cuisine article (if you're a Wikivoyager who lives outside the U.S., this one's for you)
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]
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.
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]
What talk page interactions do you remember? Is it a story about how someone helped you to learn something new? Is it a story about how someone helped you get involved in a group? Something else? Whatever your story is, we want to hear it!
Please tell us a story about how you used a talk page. Please share a link to a memorable discussion, or describe it on the talk page for this project. The team wants your examples. These examples will help everyone develop a shared understanding of what this project should support and encourage.
Talk pages project
The Talk Pages Consultation was a global consultation to define better tools for wiki communication. From February through June 2019, more than 500 volunteers on 20 wikis, across 15 languages and multiple projects, came together with members of the Foundation to create a product direction for a set of discussion tools. The Phase 2 Report of the Talk Page Consultation was published in August. It summarizes the product direction the team has started to work on, which you can read more about here: Talk Page Project project page.
The team needs and wants your help at this early stage. They are starting to develop the first idea. Please add your name to the "Getting involved" section of the project page, if you would like to hear about opportunities to participate.
Mobile visual editor
The Editing team is trying to make it simpler to edit on mobile devices. The team is changing the visual editor on mobile. If you have something to say about editing on a mobile device, please leave a message at Talk:VisualEditor on mobile.
In September, the Editing team updated the mobile visual editor's editing toolbar. Anyone could see these changes in the mobile visual editor.
One toolbar: All of the editing tools are located in one toolbar. Previously, the toolbar changed when you clicked on different things.
New navigation: The buttons for moving forward and backward in the edit flow have changed.
Seamless switching: an improved workflow for switching between the visual and wikitext modes.
Feedback: You can try the refreshed toolbar by opening the mobile VisualEditor on a smartphone. Please post your feedback on the Toolbar feedback talk page.
Talk Pages Project: The team is thinking about the first set of proposed changes. The team will be working with a few communities to pilot those changes. The best way to stay informed is by adding your username to the list on the project page: Getting involved.
Testing the mobile visual editor as the default: The Editing team plans to post results before the end of the calendar year. The best way to stay informed is by adding the project page to your watchlist: VisualEditor as mobile default project page.
Measuring the impact of Edit Cards: This study asks whether the project helped editors add links and citations. The Editing team hopes to share results in November. The best way to stay informed is by adding the project page to your watchlist: Edit Cards project page.
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]
How to Reach Female Solo Travelers, the Biggest Market in the US
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]
Hacking attempts?
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.
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]
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:
The application searches in the English wikivoyage for a page containing a listing whose update is older than a certain date or never update.
The application "save" as "note" the name, alt and lastedit parameters.
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.
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
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]
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]
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.
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 are top sights. If you like art museums at all and visit Paris, you'd be mistaken not to visit the Louvre at least once if not 2-3 times on your trip; you don't want to miss seeing the Duomo in Florence or looking at the view from one of the viewpoints on the Oltrarno side; etc. Other main tourist sights are tourist traps, but you still might want to see them once. I'd put Times Square and the Hollywood Walk of Fame in that category. A travel guide doesn't exist to discourage travel, so while we should put everything in a fair and helpful perspective, if we don't keep in mind why people travel and what they travel for, we could consider giving up and telling people that traveling is bad for the environment and they should find great things to do at home, instead. Ikan Kekek (talk) 21:01, 8 November 2019 (UTC)[reply]
True. But going to Louvre just to queue for Mona Lisa to be able to tick it off the list is not what I'd recommend. What I kinda thought was to try to tone down all "tick off the list" thinking, but I really don't know how to do that sensibly, other than by finding and highlighting also those alternative sights/destinations (which often requires some local knowledge or much effort) --LPfi (talk) 21:33, 8 November 2019 (UTC)[reply]
But there are many travellers who are only too happy to check boxes on their checklist of the world's most famous and popular attractions; people who revel in tacky tourist traps like Times Square, Disney World, and so forth. We don't have to understand or agree with that approach - I certainly don't - but Wikivoyage is at the service of those people too. -- AndreCarrotflower (talk) 22:25, 8 November 2019 (UTC)[reply]
I think it's our responsibility to mention the main attractions of a destination, whether we'd really recommend them or not. But per anr, we can list a famous sight while still gently advising people against seeing it—for instance, our listing for the Louvre could say something like, "The long queues for a distant glimpse of the Mona Lisa aren't worth it—it's more rewarding to see the other, less crowded but equally beautiful, sections of the museum." —Granger (talk·contribs) 23:33, 8 November 2019 (UTC)[reply]
Another example of what we can do: the most popular attraction in Danxiashan is a big penis-shaped rock, which I found less interesting than the interesting rock formations and panoramic views elsewhere in the park. In writing the article, while I listed the famous rock and indicated its importance, I de-emphasized it and recommended spending time exploring other parts of the park too. —Granger (talk·contribs) 23:47, 8 November 2019 (UTC)[reply]
[Edit conflict:] I wouldn't support that wording. I'd word it more like this: "The Mona Lisa is a famous and great painting. Unfortunately, there are nowadays long queues and great overcrowding around the work. So consider whether it wouldn't be a better use of your time to see lots of other great art in this extremely rich museum, rather than waiting for some time for a chance to get a glimpse of this painting amid a crowd." For the record, I think it's unquestionable that the Mona Lisa is a great painting. I thought it was overrated compared to some other really great paintings I saw at the Louvre, but my father, who was himself a painter, disagreed. Some attractions are hyped for a reason. Ikan Kekek (talk) 23:51, 8 November 2019 (UTC)[reply]
Sure, that works. My point isn't the exact wording (I just used the Mona Lisa as an example because it was mentioned above) but just that we can and should say something if a famous attraction is overly crowded, overrated, or not worth the trouble. —Granger (talk·contribs) 00:07, 9 November 2019 (UTC)[reply]
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ There's a portrait of the same woman made by someone (or several someones) in da Vinci's workshop on exhibit in the Prado in Madrid. It's a mostly overlooked painting there. Hobbitschuster (talk) 00:22, 9 November 2019 (UTC)[reply]
I think for us, the best thing to do is just be honest. If it's a tacky tourist trap, we should state so, but whether or not people decide to go to that destination is not up to us. But we can also provide advice for people who want to avoid the crowds. For instance, if you want to avoid the crowds at the Alhambra in Spain, a good piece of advice will be to go in the winter, when it is the tourism low season in Spain. I actually enjoyed visiting the tourist attractions in Spain in the winter, when the crowds were not so crazy. The downside though is that there are fewer English speakers working at the restaurants, so you'll need to get creative if you don't speak Spanish. The dog2 (talk) 00:35, 9 November 2019 (UTC)[reply]
Or just teach yourself survival-level Spanish. It's got enough overlap with English that it's not that hard for a lot of people to learn the basics. Ikan Kekek (talk) 00:42, 9 November 2019 (UTC)[reply]
Nosedive of our U.S. Alexa rank
For some reason that's of yet unclear to me (it can't be seasonal variation alone) our Alexa ranking in the U.S. has taken a worse nosedive than a 737 max with mcas on steroids. It doesn't seem to have caused real world consequences yet, but we should probably find out what's going on before it's too late Hobbitschuster (talk) 23:38, 19 November 2019 (UTC)[reply]
Unfortunately, this observation is true. The cause is as unexplainable as the jump about two years ago. The nosedive started about three months ago (see here), is not yet stopped and was combined with a decrease of the count of U.S. visitors from about 15 % to 10 %. The values for India and Germany are more stable. The usual temporary changes within a year cannot explain this behavior, too. Maybe Wikitravel could improve its U.S. ranking. Unfortunately, the awareness of Wikivoyage is still low. The major part of traffic is coming from search engines and Wikipedias but not from direct access or from other websites. Social media cannot help, too, because of low usage. A better visibility of Wikivoyage could surely help but I do not know how to do this. --RolandUnger (talk) 06:28, 20 November 2019 (UTC)[reply]
It would be good to compare it with other website rankings sites like SimilarWeb and see if it is a trend occurring everywhere or only on Alexa (in which case the way Alexa measures website popularity in the U.S. might have changed). The German Wikivoyage shows a Seitwert ranking though I don't quite understand it. As you say, Wikivoyage still has low general awareness. Many people who end up here from search or Wikipedia don't leave with a sufficiently strong impression that they remember the site and visit directly from then on or follow us on social media. Apart from the fork, we tend to get minimal mainstream media coverage as well. The only thing I can think of is to place "Share" buttons at the bottom of articles, so when a reader finishes an article and thinks it's worth sharing, they can share it via email or a social media platform. Gizza (roam)08:57, 20 November 2019 (UTC)[reply]
Yeah, we should in theory enable sharing, but there's a problem with that, in that it could be controversial to associate ourselves in any way with sites like Twitter and Facebook that, shall we say, have played very dubious roles in world politics. Ikan Kekek (talk) 09:22, 20 November 2019 (UTC)[reply]
Traffic for travel sites usually drops during northern autumn. Wikivoyage's drop in global Alexa rank is not worse than previous years. Also, the other site is no longer a relevant competitor. /Yvwv (talk) 09:52, 20 November 2019 (UTC)[reply]
I support exploring the idea of a share button, though think the politics stuff is a red herring. For better or worse, billions of people use Twitter and Facebook, and our content getting shared on those platforms to reach more people should be seen as a good thing.
I'm not taking about our global rank. Our U.S. rank shows dramatic short term movement that's not mirrored by that other site (in fact we've fallen behind it in the U.S.) or the global rank of either site... Could there be an explanation related to Google trying its hand with travel guides? Hobbitschuster (talk) 10:53, 20 November 2019 (UTC)[reply]
According to the data Roland linked to there are not one but two drops in the U.S. ranking as of lately; early August to mid-September 8,886 down to 18,911 (the ordinal numeral a little more than doubled) then the ranking improved somewhat up to 13,799 in October and then down to 28,458 until now (again the ordinal numeral a little more than doubled). Is that really normal? --Ypsilon (talk) 11:53, 20 November 2019 (UTC)[reply]
Hello, just chiming in here as a staff member who use to work with the search team and cares about Wikivoyage. :) It's possible that wikivoyage.org (the portal) traffic has diminished, but not the actual language variants. That's a little less alarming IMHO. Here's the stats for English Wikivoyage showing that since the beginning of 2019, page views have increased! And traffic to English Wikivoyage from the US makes up the overwhelming majority of traffic. That's pretty consistent over time too. Not to say we shouldn't be watching and be concerned, but to provide a little contextual relief (I hope!).
Throwing out another idea here: should Wikimedia be purchasing Google search ads? They could even be targeted to searches for "wikitravel", so that people could be educated and redirected to us. WT may not be a relevant competitor in terms of quality, but they are still very much a competitor in terms of traffic: their articles outrank ours for many search terms, leading many casual readers to make edits there. By representing themselves to the casual reader as the Wikipedia for travel, they also hijack and do ongoing harm to our reputation. Sdkb (talk) 20:11, 26 November 2019 (UTC)[reply]
Indeed we do not advertise. The only place where Wikvoyage can and has promoted and raised awareness of itself are other Wikimedian sites. The edit-a-thon (to celebrate our 5th anniversary) was a moderate success. Many people came to the site for the first time and some new editors stayed on to varying degrees. As far as arbitrary statistical landmarks go, we are close to hitting 30,000 articles soon. Perhaps we should ask the WMF to post a box on the top of pages highlighting this and include a link directing people to main page. While it was nice to get people editing, it would be great to get people reading our best content. Gizza (roam)10:02, 27 November 2019 (UTC)[reply]
There is a big difference between advertising and being a profit/non-profit organisation. Would be interested to see Wikimedia guidelines on promotion of sites, can anyone point us in the right direction? --Traveler100 (talk) 17:28, 27 November 2019 (UTC)[reply]
I rather agree with Traveler100. We don't, and shouldn't, allow advertising on Wikivoyage, but isn't that different from advertising of Wikivoyage? I think that's a question that's unanswered by virtue of never having been asked: Wikipedia obviously has enough name recognition to preclude any need for advertising, and the issue has apparently never come up in any of the smaller WMF wikis, but that doesn't mean we know how the WMF would respond to such an idea. -- AndreCarrotflower (talk) 17:53, 27 November 2019 (UTC)[reply]
Google used to donate a small amount of free advertising to non-profits, but I'm not sure if (a) they still do this, or (b) if we would qualify. (My guess is that they probably have the program, but that we wouldn't qualify.) WhatamIdoing (talk) 18:11, 27 November 2019 (UTC)[reply]
I, perhaps wrongly, read Ikan's comment as less about what we as a nonprofit should be doing, more about what we realistically can do. The Wikimedia Foundation is a charity, and clearly charities do advertise. But how much does an ad campaign on YouTube, targeted at travel videos, say, cost? How much would it cost to purchase Google search ads, as suggested above by Sdkb? I like the idea of advertising outside of the Wikimedia bubble in principle, but my concern is how practical it is. The first question the WMF would ask if we were to propose this as an idea is "how much will this cost?" --ThunderingTyphoons! (talk) 18:21, 27 November 2019 (UTC)[reply]
On a separate note, while I know that one person is unlikely to significantly change the website's rank, there was a period when I was extremely active here, sometimes making thousands of edits within a few days. Since I've not been so active on Wikivoyage, especially over the last couple of months, the rank has dropped noticably. Is it possible that there is a connection? Or would one user not be enough to impact the U.S. rank even by a thousand or so? --Comment by Selfie City (talk | contributions) 18:53, 27 November 2019 (UTC)[reply]
Getting back to the suggestion of Google advertising: Since Wikimedia doesn't profit from an increase in this site's Alexa ranking, what would be the good reason to spend money advertising it? Charities advertise because they need money for poor people, disaster areas, political causes, arts organizations, etc. I suppose Wikimedia needs money for servers, paid staff and such, so if they thought it was cost-effective to advertise, they'd probably already be doing it. But I don't think advertising on Google to raise a Wikimedia site's profile is likely to be cost-effective. Ikan Kekek (talk) 19:21, 27 November 2019 (UTC)[reply]
It would not be aimed at making money, i.e. financial contributions, but encouraging new readers to the site and hopefully more contributors. --Traveler100 (talk) 19:35, 27 November 2019 (UTC)[reply]
On how much it costs, you decide what your daily budget is and are charge between $1 and $2 dollars per click through. So basically look at $2 per new reader, but obviously no guarantee they will stay. --Traveler100 (talk) 19:43, 27 November 2019 (UTC)[reply]
Sure, if the Wikimedia Foundation feels like just spending money with no money coming back to them. You think they do, considering that they've been asking for contributions for Wikipedia? I think not. I wouldn't even consider suggesting this to them. Ikan Kekek (talk) 19:53, 27 November 2019 (UTC)[reply]
Their aim isn't to make money, though, so the fact that no profit will be generated from this venture is irrelevant. What is relevant is whether the potential rewards of the venture (attracting more readers, a subset of whom will become contributors - this ought to be a goal the Foundation shares) are significant enough to outweigh the cost. What do they fundraise for if not to make the wikis better in various ways, whether that be by hiring full-time staff, developing software improvements, or in this case increasing traffic? I still think it could be rather costly, and certainly don't think the chances of this being approved are very high, but it's worth exploring, potentially alongside other smaller sister-wikis. I am also grateful to Traveler100 for the brief explanation.ThunderingTyphoons! (talk) 21:48, 27 November 2019 (UTC)[reply]
The last half year or so Alexa have had more information. E.g., Similar sites by audience overlap and sites linking in. It is clear that WV is way behind on sites linking in, except that one of them is Wikipedia (92 percent comes from Dictionaries and Encyclopedias of which Wikipedia is of course the top one). Elgaard (talk) 16:55, 4 December 2019 (UTC)[reply]
If you look at the Google Trends comparison of Wikivoyage with WT ([5]), you will notice that WT is a more popular search term everywhere except in Venezuela. Some countries are greyed out but it seems that WT triumphs over Wikivoyage is well over 100 countries. We benefit from Wikipedia's links to us, but apart from that I still feel WV is behind the old site on many measures. Gizza (roam)23:27, 11 December 2019 (UTC)[reply]
Actually over a 5-year trend, we have made progress against them. In 2014, WT was being searched for 20 times more than us and now it's only 8 times more than us. That can be partially attributed to WT declining rather than us becoming more well known though [6]. When you compare Wikivoyage with Lonely Planet, in 2014 LP was searched 30x more than WV, while nowadays is 20x. So you could say moderate but not substantial progress has been made [7]. Gizza (roam)23:33, 11 December 2019 (UTC)[reply]
Re WikiTravel vs WikiVoyage: Probably not completely relevant to Alexa Rankings but earlier this year travelling Peru, Bolivia & Chile I started using WikiVoyage but switched to WikiTravel as their coverage was more up to date and broader (i.e. they included towns WikiVoyage had nothing about). I believe there are reasons for this but I'm travelling SE Asia at the moment and not ready to get into a discussion (which would be a separate subject/thread/section anyway). I'll start a new discussion when I get home in a few months (or longer or whenever). Maybe relevant to Google search results (I've no idea how those affect Alexa. Reality is WikiVoyage should be way way above other other sites e.g. TripAdvisor keeps coming up in Google searches but whenever I look at it it's pretty useless and they "tours" they advertise are a complete joke. PsamatheM (talk) 15:50, 2 January 2020 (UTC)[reply]
Thanks for the update @PsamatheM:. Do you remember the names of any of the towns where Wikivoyage's coverage was weak or non-existent? We should make closing any gaps with them a priority. Gizza (roam)05:05, 8 January 2020 (UTC)[reply]
@DaGizza: I'm travelling at the moment on "variable" internet and with only a tablet. So for now it's brief (and unverified) responses. From memory e.g. I wasted a lot of walking and sweat (very hot) in Trujillo (Peru) as the bus information is/was disastrously wrong (relevant bus companies have their own ticket sales not at central bus station so its walk and walk and walk). When I visited Jauja (Peru) WV then had no page (and Jauja is a quite amazing place, massive Tunanmarca ruins, Canoncitos de Pichiluli, etc.). But even now WV's page is pretty poor compared to what WT offer. Inaccurate information that causes travellers problems is a guaranteed way to quickly drive people away from the site. I gave up applying updates to WV soon after arriving in Peru when I posted a listing for an excellent tour (I'd done, free) and the "policy police" descended deleting it, followed by endless discussion to try and form consensus and I believe the listing was restored but "life is too short" and for one listing it was a farce. I actually have a really strong belief in projects like Wikipedia, WV, etc. but I believe WV needs to significantly reconsider aspects of it's attitude. I'm sort of preparing my ideas but wont start putting them up until I'm home and can properly engage in any discussion they might prompt (of course the might not prompt anything).PsamatheM (talk) 07:44, 9 January 2020 (UTC)[reply]
@PsamatheM: I agree that there's excess biting of newbies and even semi-established editors and blind adherence to many policies which don't necessarily improve Wikivoyage in the long run. One policy we do need to adopt from Wikipedia is "If a rule prevents you from improving or maintaining Wikipedia (or in our case Wikivoyage), ignore it." See wikipedia:Wikipedia:Ignore_all_rules. Many times, edits are just reverted without even an explanation in the edit summary let alone a personal message to the good-faith editor who would feel like they're being stalked and not welcome here. Gizza (roam)01:03, 10 January 2020 (UTC)[reply]
There are a lot of things that I'd think could improve Wikivoyage that would deviate greatly from the Wikivoyage Manual of style, but that's my opinion, not the collective opinion of the site. And my question to you would be: How does Wikipedia prevent people from driving a truck through their guidelines, with their policy of ignoring rules? Ikan Kekek (talk) 03:26, 10 January 2020 (UTC)[reply]
Reverting an edit without explanation is just plain ignorant, except in the case of (a) obvious vandalism, or (b) repeated touting. At the same time, giving people licence to ignore rules would set us up for edit wars between someone who wants things done one way, and someone who thinks it's better done another way. The rules resolve these disputes and avoid wasteful edit warring. Eventually, anyone who joins a collaborative project has to learn that their work will be edited and changed by other users. It does not help newbies to let them think that their contributions are perfect just the way they are and aren't going to be changed by others. At the same time, not biting newbies is a really important practice, and I am sure I have been guilty of doing so in the past. Where an experienced editor is too heavy handed with newbies, it is important that other oldsters call them out on it. Ground Zero (talk) 04:03, 10 January 2020 (UTC)[reply]
@PsamatheM: I have substantially expanded the Jauja article with text adapted from the Wikipedia article. Could you take a look at it and add/delete/improve on my contributions as you see fit based on your experience there? With your help, and selective borrowing from Wikipedia, we could end up with a decent article, Thanks. Ground Zero (talk) 04:39, 10 January 2020 (UTC)[reply]
1. I was not being critical of the article but using it as an example of somewhere that WT had good coverage for but (at that time) WV have no page at all about. (One of the contributory reasons that back then I gave up using WV as a source of information whilst travelling Peru, Bolivia & Chile.
2. Having only tablet, phone and variable internet I would not be able to work on the article until I return (maybe many months away). Probably breaking rules but specifically see posts on my own web site https://psamathe.net/tag/jauja/. Tunamarca is a very significant site. Cañoncitos de Pichiluli is amazing. There are not any tours so info on e.g. WV becomes even more useful. Both are close to the town to be part of the town article. Pueblo Viejo isn't enough to visit on its own but is worth going via it on your walk to Cañoncitos de Pichiluli (but you'd need the GPS coordinates as there is no "way to go" just a good start point and a network of paths used by local farmers and shepherds).
So for now (due to my current "mid-travels" state) I'll have to pass any work on the article back to you (or others). Feel free to take any info/text from my personal website, you have my permission to take any photos (either directly into WV or onto Commons (though please credit them to psamathe.net - though they are just a few photos I'd be putting up there anyway in due course and but I'd be exporting them from raws so quality/resolution would be better (but more about info than photographic perfection). Let me know if you need any details or info and anything (but I don't have originals with me). Sorry if I appear lazy not doing the work myself but if you/somebody could do the bulk I doubt there would be much for me to tweak.PsamatheM (talk) 05:13, 10 January 2020 (UTC)[reply]
I've added a bunch of stuff from your cool blog, and another hotel, but I should stop procrastinating and get to planning my imminent trip. Ground Zero (talk) 13:49, 10 January 2020 (UTC)[reply]
Ikan Kekek, the English Wikipedia addresses the "Ignore all rules" problem these days mostly by giving it lip service and then rigidly enforcing Teh Rules in contradiction of the policy. When it does come up, there's usually a conversation about it. In its best form, it's really no different than how we decide things that aren't regulated, like whether a particular restaurant/bar combination business should be listed in ==Eat== or ==Drink==. WhatamIdoing (talk) 22:13, 11 January 2020 (UTC)[reply]
Thanks for explaining that, WhatamIdoing. So I'm not sure having a similar policy would really result in any change here, other than confusion. Would you agree, or do you think it would be useful somehow? Ikan Kekek (talk) 23:19, 11 January 2020 (UTC)[reply]
I suppose that it has the potential to reduce the number of "Can we really block this guy, even though technically there's no obvious category in the blocking policy?" discussions from maybe two per year to one, which might be a small win. WhatamIdoing (talk) 04:07, 12 January 2020 (UTC)[reply]
By replacing the long discussion about whether it's okay to block a user with a statement that "I decided to 'ignore all rules' and block that guy". It won't stop them all, but it might stop some of them. WhatamIdoing (talk) 16:55, 13 January 2020 (UTC)[reply]
@PsamatheM: - I empathize. Same thing happened to me when I listed a tour in Berlin. We happily list hotels, and other businesses without any qualms, but somehow tours are off-limits. We are inconsistent in our policies, and its very frustrating. Pick up any guidebook that people pay good money for. You will see that hotels, tours, and other businesses are listed if they are helpful to the traveller. We seem to have made some sort of inconsistent purity pledge that shortchanges the fundamental goals of this project. Marvin The Paranoid (talk) 15:44, 26 January 2020 (UTC)[reply]
The walking tour in Peru that PsamatheM mentions was the occasion for a discussion that resulted in a site-wide exception for walking tours, so while PsamatheM's experience may have been trying, it actually led to a presumably permanent change (the guidelines changed over a year ago and haven't produced any disruption, so while not everyone agrees with them, they seem unlikely to be rolled back).
But when you say the tour policy "shortchanges the fundamental goals of this project", this is one of the goals:
Tours can be listed on Wikivoyage as long as they constitute a value-added activity. If a traveller could fulfill the substance of the tour on their own, the tour should not be listed.
And if it wasn't already clear that this site is directed at independent travelers, the end of the linked section is:
In practice this policy disallows listing most audio tours and guided tours since the substance of such tours can generally be fulfilled by an independent traveller, and the information provided on such tours should ideally be included in the appropriate Wikivoyage article.
The other part of this is something that you wouldn't remember because it happened a long time ago, but when we did allow tour links, articles like Florence were absolutely filled with spammy tour links and listings. A consensus on this site has so far agreed that the purpose of our guides is to enable independent travelers to visit the destinations we cover. Anyone who would rather take package tours probably doesn't need this site and won't have trouble finding such tours. Moreover, we simply lack the readership and expertise to try to do what we used to try to do with such listings, which is to judge which tours are good and which are pure money-sucks.
That said, exceptions to guidelines and policies are always possible (barring legal requirements, of course), but they have to be argued for on the relevant article's talk page. And if you want to change the tour-listing policy for the entire site, you can always start a thread at Wikivoyage talk:Listings and see if you can persuade a consensus to agree with your proposal. Whatever the results, someone will be unhappy, and that's the way it is and the reason why there are so many different sites - it's a Worldwide Web out there. Ikan Kekek (talk) 16:12, 26 January 2020 (UTC)[reply]
Thanks for the explanation and the history. It is good to know that there has been forward movement in this area. My edit was made a while back, when I was still new to WV, and I did not realize that a discussion could have been used to make my case for keeping it. --Marvin The Paranoid (talk) 16:39, 26 January 2020 (UTC)[reply]
We should make this clearer. I'm wondering where the best place is to start a discussion about where and how to make it clearer that all policies and guidelines that are not legally required could possibly be subject to exceptions on a case-by-case basis if a compelling argument results in a consensus for an exception on a particular article's talk page. That's how we've been operating, but perhaps there may be objections to the idea of case-by-case exceptions, too. Ikan Kekek (talk) 16:44, 26 January 2020 (UTC)[reply]
Ikan Kekek One of the great problems with "organised tours" is how they are used. When completely independently travelling in Peru last years, in northern costal areas I took organised tours several occasions because no public transport was available and taxis were far far more expensive than the tour (and independent traveller could take a bus to a town, maybe then a taxi, maybe meaning an overnight stay but all ludicrous when an organised tour can provide transport cheaper and easier). Tour minibus would arrive at the site, I'd ask the driver or guide what time they were heading back and say "See you then" and I'd head off on my own - using them for transport but it is an organised tour. I'd given up bothering to add anything to WV after the "walking tour" grief mentioned above, but would I have got away with listing an organised tour on the basis it was way cheaper as transport than alternatives? or would it have caused another involved discussion ..... PsamatheM (talk) 16:52, 26 January 2020 (UTC)[reply]
Sure, on that basis. There are examples of listings of tour buses on the basis that they are transportation in various articles. I'm sorry you gave up adding content to Wikivoyage after a listing you posted caused a change in policy; how much more responsiveness could you ask for? Ikan Kekek (talk) 17:54, 26 January 2020 (UTC)[reply]
Reason I stopped bothering was that I posted a useful, valid listing, useful to many independent travellers - it was immediately taken out followed by a "consensus discussion" .... Life is too short and given the massive shortcomings in so many articles on the site (both in complying with policy and with badly out of date information then the issue my listing created well illustrates how the site is missing the bigger picture. Spend ages focusing on a minor listing overlooking the vast amount of work needed elsewhere. And that is why I believe some changes in attitude are needed to stop driving much needed travellers away when they are the ones who could spot errors and fix them (but then they'll make a "style" or policy error and .....). But that is another topic and one I don't have time or resources to engage in discussion over at the moment. PsamatheM (talk) 13:52, 28 January 2020 (UTC)[reply]
@PsamatheM: It's easy to endlessly criticise this community's approach and then when challenged say "I don't have time to engage", but if you have an idea of how your old "grief" could have been better handled than by a discussion resulting in a change of policy that makes it easier for the type of tour you were advocating for be listed, then please share it. You got the outcome you wanted, but still it's not good enough. You talk about changing attitudes, but instead of presenting the better alternative for this site that you clearly envision, you carry on bemoaning things from months ago which you feel didn't go your way. I think we would all be more receptive to suggestions if you presented them in a positive way ("Here's an idea I had, this is why I think it would make Wikivoyage better, what do you think?"). But at the moment - and I apologise if I'm perceiving you incorrectly - I feel that you're quite happy to tell us all what we're doing wrong, but are not interested in putting forward constructive suggestions of how we could do better. I'd love to be proven wrong. --ThunderingTyphoons! (talk) 15:26, 28 January 2020 (UTC)[reply]
@ ThunderingTyphoons!: As I said some way back in this discussion, I don’t have time to engage at the moment (I said “but I'm travelling SE Asia at the moment and not ready to get into a did (which would be a separate subject/thread/section anyway). I'll start a new discussion when I get home in a few months (or longer or whenever).” Struggling to even backup my photos to the cloud the internet is so slow and unreliable so to start a discussion now I’d probably disappear for a week and it would get very disjointed -hence my saying later not refusing to engage as your comment suggests.
I’m not bemoaning the past but using it as an illustration about issues. The grief to get one listing up was ludicrous. Better way to handle it would have been e.g. to leave the listing up and ask me to justify it as an exception, to trust somebody independently travelling “on the spot” to make a sensible judgement, etc.
I didn’t “get the outcome I wanted” - I wanted to provide information to help other independent travellers. The work to get one listing up made me decide my time was better spent travelling so all the horrendously out of date, wrong, misleading info about e.g. bus routes is probably all still misleading other travellers.
As I said I would be putting forward suggestions when I get home and have internet, laptop & time to discuss - now I’m not sure I can be bothered. I was interested in putting forward constructive ideas as I said earlier. PsamatheM (talk) 01:55, 29 January 2020 (UTC)[reply]
After all, Wikivoyage is not as well-known as Wikipedia. In addition, the main active people are mostly people in the community, and even many competitors like us are encountered, so the need for external promotion is necessary. Basically, the Wikivoyage channel I created on YouTube is to help the anyone know our Wikivoyage. I also hope that there are friends who want to publish promotional or teaching videos. You can provide to me about your G-Mail. I will Provide willing people to become admin, so you can post videos to YouTube channel of Wikivoyage.--✈ IGOR ／ ✉ TALK?!．WIKIVOYAGER !16:21, 5 February 2020 (UTC)[reply]
Please vote for Wikivoyage proposals at the Community Wishlist 2020
Since November 20 the voting for wishlist proposals is open. Please give support for Wikivoyage proposals.
Unfortunately, the map-related proposals were removed. User IFried from the Wikimdia Foundation explained it: "..., thank you for submitting this proposal! We have reviewed this as a team, and we will unfortunately be unable to take on this wish. Here's why: Our infrastructure team is currently discussing options to switch out the maps frontend and backend to a different technology stack, which would be more robust and easier to maintain. If we can make that work, then it could take care of many of the concerns expressed in this proposal. It will be at least several months until we'll know for sure what the decision will be, so for this year's wishlist, we're not going to take on any possible commitments to working on the existing maps stack. Thank you again!" --RolandUnger (talk) 07:48, 22 November 2019 (UTC)[reply]
I'm a little surprised that the last two weren't removed for not being specific to Wikivoyage (they are "global" requests that could benefit any wiki, not just Wikivoyage).
We should also look through the other projects' lists, to see if any of them would incidentally benefit us as well.
The voting rules are: YES, YOU ARE ALREADY ELIGIBLE TO VOTE, so please do. Basically, if you've made any edits at all, and you don't look like an account created for the purpose of voting, then you're eligible to vote in the Wishlist. WhatamIdoing (talk) 21:13, 22 November 2019 (UTC)[reply]
That would be useful, too. Voting ends on Monday. At the moment, there's one (labeled) Wikivoyage wish in the top 5 (only the top 5 "win"). There's another that is (currently) six votes short of winning. Remember that you can vote for any wish that you think is a good idea, not just ones that have the Wikivoyage label on them. Some folks are active on other projects, and we want to support them. Also, some of the "non-Wikivoyage" might be useful here as well. m:Community Wishlist Survey 2020/Wikiquote/"Add quote" button in the Visual Editor toolbar springs to mind in that category. I don't think that one is going to win this year, but work-me has been talking to the Editing team about one way to implement that, which would also let us put a list of the Do/Buy/See/Eat/Sleep templates in the toolbar here. The important thing is just to go vote for what you want. WhatamIdoing (talk) 20:51, 29 November 2019 (UTC)[reply]
More hacking attempts
I got another warning of multiple failed attempts to log in to Wikivoyage under my username from a new device. Am I the only one getting these warnings? Ikan Kekek (talk) 01:13, 6 December 2019 (UTC)[reply]
Making the Content Translation Tool available for Wikivoyage
I don't know if any of you have ever tried Wikipedia's Content translation Tool, but i'll just say that this is a very strong tool that has helped the Wikipedia community translate A LOT of articles between the various Wikipedia editions (mostly translation of articles from the English Wikipedia to the smaller Wikipedia editions).
So far this tool is only used in Wikipedia.
As part of the current Community Wishlist Survey, a suggestion has been brought forward to make this tool available for all Wikivoyage editions as well:
This one is just a handful of votes away from winning. Voting is very simple: Go to the page, and click the blue button to "Support". You can add an optional comment if you want, but most people don't. Voting ends soon. WhatamIdoing (talk) 18:13, 1 December 2019 (UTC)[reply]
This one could be really valuable, guys; mainly for our smaller sisters, but also where destination articles are more developed on another language version than they are here. I encourage you all to vote. —The preceding comment was added by ThunderingTyphoons! (talk • contribs)
Google Translate isn't good enough to be presented as a final document, but it is good enough to do a lot of the initial legwork of translating meaning. A decent (human) translator can then focus on improving flow, getting the idiomatic language nailed, and cleaning up any errors in understanding or missed nuances caused by the machine. That is how professional translators work (not necessarily with Google, but certainly with translation software), because it's quicker, and thus the translator can dedicate more of their time on doing the stuff that actually requires their expertise.--ThunderingTyphoons! (talk) 20:01, 1 December 2019 (UTC)[reply]
I haven't used it, so can't answer your question. It seems to me that these questions can come later though; the vote is the priority. Just because it passes the vote, doesn't mean we have to use it.--ThunderingTyphoons! (talk) 22:04, 1 December 2019 (UTC)[reply]
And do you know how it has worked in practice? The worst problem that I see, is that there are a lot of people who would skip the "cleaning up any errors in understanding or missed nuances caused by the machine" part, especially as using a machine you do not necessarily have to understand the origin language. I haven't looked for a long time, but Google used to sometimes produce good-looking text with severe misinformation, as it was good at finding idiomatic language, but useless at understanding. The worst I saw was it translating currencies (dollars to markka) without changing the numbers. I think we should vote for the tool only if we find it useful and not too dangerous. We can fix bad language, but it is hard to fix non-obvious misinformation --LPfi (talk) 13:47, 2 December 2019 (UTC)[reply]
Ikan Kekek, it's software to make it easy for bilingual editors to translate articles. It isn't automatic translation. There's a setting to make sure that pure machine translation doesn't get dumped in articles. It won't let you click the "Publish" button if you don't clean it up first. The minimum amount of clean up work is configurable per language. Also, there's some system that basically stops individual editors (IPs can't use it at all) from using it if the articles they translate get deleted too many times. It's really quite a well-designed system overall. WhatamIdoing (talk) 16:52, 2 December 2019 (UTC)[reply]
I got an error message, "Sorry! The survey has closed." Next time, if an announcement could be made a bit further in advance, to give us time to discuss a proposal, that would work out better. You can't really blame us for not being willing to vote for something purely on faith or just because we were asked to do so. Ikan Kekek (talk) 20:07, 2 December 2019 (UTC)[reply]
The Wishlist vote was announced in the Pub on 4th November, with a reminder on 22nd November. If you wanted to vote for any of the proposals, leaving it to the very last day was not the best idea. Of course this particular proposal was only brought up here a couple of days ago, but all the proposals have been there to see for the best part of a month. It's not blame to point out that everyone here had an opportunity to vote.
Hello friends. Could those of you with a good knowledge of how the filters work please direct your attention to filter #37? There seems to be an issue or a bug. I'd be grateful for some expertise.--ThunderingTyphoons! (talk) 07:42, 16 December 2019 (UTC)[reply]
Do we have a page about best practices for making changes to the filter? You don't get to be administrator because of your experience with regular expressions, bug tracking & al, so we cannot expect our admins to have the expertise (we do have some experts, but they are not always available). I spent quite some time figuring out the syntax and how some of the filter tools work, and learning more would make this kind of work a lot easier. I am able to read and understand the technical documentation, but still I would benefit from a tutorial. --LPfi (talk) 14:12, 17 December 2019 (UTC)[reply]
