Wikivoyage:Travellers' pub/2019

From Wikivoyage
Jump to navigation Jump to search

Page preview pop-ups[edit]

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)

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)
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)
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)
@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)
@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)
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)
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)
I think, generally, as LPfi says, we should go with the first image of the article, which should be fairly easy to code. So I'd support a change, if possible (which it seems is possible).
P.S. Sorry for changing my signature again. I am finding the olive color overwhelming, so I have changed it back to blue. --Comment by Selfie City (talk | contributions) 02:39, 11 January 2019 (UTC)
@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)

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

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

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)

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)
@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)
@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 and image. So first 4 listings with coordinates and image parameters are candidates. --Traveler100 (talk) 12:27, 13 January 2019 (UTC)
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)
@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)
T213652 request to change ranking to put visible images before listing images. --Traveler100 (talk) 13:19, 13 January 2019 (UTC)

Post-Phabricator update[edit]

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

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

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

User:Wauteurz has done a great job of explaining how this works. When I proposed enabling the page previews feature, I did flag that we'd need to rethink out descriptions and images to support it, but I figured that was good for the project and a problem with editing we could solve.
I'd strongly advise, not setting $wgPageImagesLeadSectionOnly to true. This leads to I'd guess at least 70% of articles without an image. This negatively impacts page previews, mobile web search as well as external clients. We also have data somewhere that suggests that we get more interactions when images are presented alongside the link. I'd argue this is much worse than the status quo.
The algorithm that chooses an image is also very dumb. phab:T91683 has been proposed as a long term solution for dealing with these situations and is simply lacking some impetus to fix this which would help every wiki, but in the mean time, the best possible thing to do IMO is to make sure the first image in the article represents the article and is a suitable page image! This seems useful for page preview users and users entering an article for information! For instance, it's bizarre that Siem Reap contains no image of Angkor Wat, its most iconic sight, other than in the page banner. From my POV overloading the banners is problematic - it provides no caption for mobile users (you cannot hover over banners on mobile!) and will not render on clients who are not banner aware. Could we not setup a Page image expedition? I feel that would be lots of fun.
Frustratingly, in cases like Washington,_D.C. this seems to be the case - a picture of Abe Lincoln seems pretty iconic and relevant, but for some reason that's not being chosen as the page image. I'd love to tinker with that some more, to see why that's the case. That seems like a bug to me. Hopefully that would eradicate some of the bad page images we're seeing.
Jdlrobson (talk) 20:31, 14 January 2019 (UTC)
@Jdlrobson: I'm well-aware that I am not the only one with an opinion here, but $wgPageImagesLeadSectionOnly seems the best option to me. I am, however, very much in favour of an imagery expedition or Collaboration of the Month(/Season?) as I said before. A goal for such an expedition would be to get an image in every lead section, after which, we would ideally have a large majority of articles with images in their lead sections. Only once that has been achieved would I be in favour of changing $wgPageImagesLeadSectionOnly to true. I haven't been clear that that's the order I had in mind, I'll admit. Since phab:T91683 has already taken a few years and none of the goals have been ticked off, I would be more than content with achieving this goal by the end of the year or sometime in 2020.
I can report that the image for Washington, D.C. originates from the first listing in the article with coordinates: The Afghan embassy. It's not like the image gets fetched from a seemingly random place. Like you said, the algorithm isn't smart. I've already speculated before that listings get prioritized because they or the mapframe get loaded before the page content. I can't confirm any of this, but it may be worth looking into. On the same note, if the algorithm is that dumb, then why not rewrite it to differentiate images that are in plain sight (thumbnails, etc.) from the 'invisible' images (listings, etc.)? I may be massively oversimplifying the whole ordeal, but forgive me for I lack the technical knowledge. The coding and technological insight I learnt in school has long faded on me.
Anywho, I'm all for an image expedition, but I'd like to hear the insights of others as well.
-- Wauteurz (talk) 21:21, 14 January 2019 (UTC)
It seems to me that any solution which requires editing every page or manually setting preview images is problematic. While we could do this for our most popular articles, the vast majority of our pages are lean on text as-is, and many lack a custom pagebanner, let alone an image to put in the lead. Even if we do find an image, it will in many cases then dominate the article.
Would it be possible, as a fourth solution, to adjust the weights on the image scores to strongly favor Wikidata images? This, I think, is the best solution: most of our articles would immediately have a photo, which someone felt represented the destination, as the preview image, and the ones with less-than-stellar Wikidata images would be easy to change, and doing so would benefit other projects. Plus, destinations without an image in Wikidata but with a banner could have the banner source image added to Wikidata, and destinations without an image or banner will still have other kinds of images to fall back on.
If this isn't possible, seems that would be a much simpler change for the Phabricator guys to make. ARR8 (talk | contribs) 01:37, 15 January 2019 (UTC)
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)
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)
@ARR8: I am not suggesting that every one of our 29,327 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)
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)

One solution I see today[edit]

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

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)
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)
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)
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)
the number can be removed from the preview by attaching the class noexcerpt! See MW:Extension:Popups#FAQ
2607:FB90:9D55:EEEC:AD28:E0EF:5ED3:DBD0 02:20, 16 January 2019 (UTC)
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)

Updated solution that works today[edit]

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)

FileExporter beta feature[edit]

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

Page previews and Navpops[edit]

@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)

I can confirm this bug. I have had to manually disable page previews due to this. ARR8 (talk | contribs) 16:57, 27 January 2019 (UTC)
This is now fixed thanks to User:X-Savitar :-) 19:58, 14 February 2019 (UTC)

mobile main page[edit]

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)

Excellent work! Massive thank you for doing that.--ThunderingTyphoons! (talk) 14:38, 10 February 2019 (UTC)
I'm so glad this has been implemented. Big improvement. —Granger (talk · contribs) 11:39, 11 February 2019 (UTC)
Have improved pages somewhat but now starting to struggle, particularly were tables have been used to format pages. --Traveler100 (talk) 18:29, 12 February 2019 (UTC)
Sorted out format without table widths but still cannot see why {{bottomboxesn}} does not show in mobile view when on main page but works from sandbox?--Traveler100 (talk) 21:53, 12 February 2019 (UTC)
Wooow! Our Chinese Wikivoyage also update the mobile version about main page. :D--Yuriy kosygin (talk) 17:57, 15 February 2019 (UTC)
Thanks to @ARR8: for making an even better mobile main page. --Traveler100 (talk) 06:57, 23 February 2019 (UTC)

Travellers' pub[edit]

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)

Is the question mark with the green background really needed? --Traveler100 (talk) 17:49, 12 February 2019 (UTC)
I don't mind splitting them, but I think now the new box should be by default aligned the same as the other one, more like Pub/sandbox. But I'm not sure how that would look on mobile. --Comment by Selfie City (talk | contributions) 01:35, 13 February 2019 (UTC)

Wikivoyage:Community portal[edit]

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)

Think I have worked out a solution Wikivoyage:Community portal/sandbox. Not totally finished but see the end of the tunnel. --Traveler100 (talk) 21:42, 12 February 2019 (UTC)
The sandbox doesn't look right to me. Maybe, though, that's because you're still working on it. What if you just had one column of boxes, instead of two or three? --Comment by Selfie City (talk | contributions) 01:32, 13 February 2019 (UTC)
There were some errors in the original page which did not show up until made changes. Wikivoyage:Community portal/sandbox is where I want it to be when viewed on smart phone and on desktop using Firefox and Explorer but not working as I would like on Chrome. --Traveler100 (talk) 20:03, 13 February 2019 (UTC)

Help resources[edit]

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)

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

An update on templates on mobile web[edit]


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

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

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

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

Good news! This should have a great impact on the WV:UX Expedition. --Comment by Selfie City (talk | contributions) 03:11, 21 February 2019 (UTC)
These are relatively minor changes for WV, but I'm glad we were notified. ARR8 (talk | contribs) 04:14, 21 February 2019 (UTC)
Oh, OK. But still, good news. --Comment by Selfie City (talk | contributions) 04:48, 21 February 2019 (UTC)
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)

Talk to us about talking[edit]

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

Cliché views and what to find beyond them[edit]

Swept in from the pub
The view of Hallstatt that everyone knows.

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)

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)
Agree with all of the above suggestions. These are all fundamental features of a successful travel guide.--ThunderingTyphoons! (talk) 19:05, 4 March 2019 (UTC)
I believe somewhere about the WV:Banner expedition it talks about choosing pagebanners that show a more unique view of the place pictured. --Comment by Selfie City (talk | contributions) 23:22, 4 March 2019 (UTC)
Both the banners of Austria and Hallstatt are shots of Hallstatt similar to the picture mentioned above, but in reverse angle. /Yvwv (talk) 03:18, 5 March 2019 (UTC)
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)

Alexa rank[edit]

Swept in from the pub

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

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

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

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)
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)
As I understand it, in the case of SEO, it's probably because the Croatia article has a lot of similar (or even duplicate) content to Wikitravel, or the content of the article does not use many catchphrases that would be picked up by a search engine.
I think it's true that it has been quieter lately. I was looking at the recent changes at 5:00 UTC (today, UTC) and I found that I could easily scroll through the changes. One example was that, apart from an account being created, no edits were made in the hour from 3:00-4:00. Imagine if a vandal had been on the site then, how much damage he could have caused.
I agree about social media. We have a social media nominations page, but it is rarely used. We ought to use it more, if possible. We could mention articles that have been significantly improved lately, etc. DOTMs are published on social media as I understand it. --Comment by Selfie City (talk | contributions) 14:55, 8 February 2019 (UTC)
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)
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)
I started Uni in October. Question solved. ;-) Hobbitschuster (talk) 22:11, 8 February 2019 (UTC)
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)
Agreed. Name recognition is very important. --Comment by Selfie City (talk | contributions) 17:23, 9 February 2019 (UTC)


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)

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)
Wikivoyage is not very popular, after all, everyone only knows Wikipedia, not us... To make more people interested in our Wikivoyage, I think we need to work with other travel sites(eg [ Backpackers).--Yuriy kosygin (talk) 18:45, 2 April 2019 (UTC)

DOTM banners[edit]

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

Alexa rank rise[edit]

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)

Wikitravel rank[edit]

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

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)
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)
WV's Alexa rank just surpassed WT's (see Wikivoyage:Wikivoyage and Wikitravel). WT is still bigger in the United States (which makes up much of the Anglosphere). /Yvwv (talk) 14:44, 23 March 2019 (UTC)
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)
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 page 03:52, 1 April 2019 (UTC)
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)
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)
@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 page 03:42, 3 April 2019 (UTC)
  • A BIG congratulations to everyone here. We have finally pulled ahead of WT in the Alexa rankings :-) Travel Doc James (talk · contribs · email) 17:37, 14 April 2019 (UTC) wiki too...[edit]

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? -- 13:57, 16 April 2019 (UTC)

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

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

...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,, and Moon Travel Guides; and behind only Lonely Planet and TripAdvisor. I think this puts any talk of synergy with other sites squarely out of bounds, seeing as the only sites it would make sense for us to collaborate with (the latter two) are ones that are run very much on a commercial basis and thus any such collaboration would violate the WMF's nonprofit ethos.

Cc: Yuriy kosygin and andree.

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

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

Error at Budapest/Óbuda[edit]

Swept in from the pub

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

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)
Yes that was it. I have commented out the stations from drink and eat listings. Output error has gone. --Traveler100 (talk) 07:55, 17 April 2019 (UTC)
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)
Why is there a limit on templates? Is there possibly a way to get that limit changed for this article in particular? --Comment by Selfie City (talk | contributions) 13:41, 17 April 2019 (UTC)
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? -- 06:22, 18 April 2019 (UTC)
With whom should we get in touch to change such things? --Comment by Selfie City (talk | contributions) 13:32, 18 April 2019 (UTC)

I want to help promote Wikivoyage on Youtube.[edit]

Swept in from the pub

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

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

A proposal for WikiJournals to become a new sister project[edit]

Swept in from the pub

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

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

Proposal: WikiJournals as a new sister project

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

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

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)
@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 page 23:37, 3 June 2019 (UTC)
  • 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)
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)
@Ikan Kekek: The link to the discussion is actually in bold and says "Proposal: WikiJournals as a new sister project", which will direct you to the Meta page. OhanaUnitedTalk page 01:30, 4 June 2019 (UTC)
Thanks. :-) Ikan Kekek (talk) 04:20, 4 June 2019 (UTC)
Yes. The proposal had almost unanimous support until very recently, but now it has more publicity, the votes have become more mixed. --Comment by Selfie City (talk | contributions) 14:19, 5 June 2019 (UTC)