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.

Not sure if people have seen this new list of most viewed articles?

[1]

Best Travel Doc James (talk · contribs · email) 18:31, 31 December 2016 (UTC)[reply]

Thanks for stopping by, Travel Doc. Really interesting list! A lot of the rankings seem counter-intuitive to me. Ikan Kekek (talk) 18:35, 31 December 2016 (UTC)[reply]

Travelling with a criminal history both here and on WT are top results for related Google searches. Apparently there aren't a lot of resources out there on that topic. Powers ^(talk) 19:04, 31 December 2016 (UTC)[reply]

That wasn't the result that surprised me most. Why is Deauville the #1 destination guide? Why is Tianjin the 2nd-most-viewed city article? Why is Bikol phrasebook the top phrasebook, and viewed more than any city guide other than the two already mentioned? Why is Al Khor more popular than China and London? Etc. There's a lot to wonder at, but that's what makes the results interesting. And perhaps the list might impel us to improve some of the most viewed articles. Ikan Kekek (talk) 19:30, 31 December 2016 (UTC)[reply]

I was wondering about the popularity of the Tswana_phrasebook , which is rather niche. A quick google search shows that we are 5th ranked for that, which unfortunately goes to show how important SEO is. Still it should inspire us to develop new niche (and valid travel!) articles that will gain higher SEO ratings and help the site's overall traffic. --Andrewssi2 (talk) 20:57, 31 December 2016 (UTC)[reply]

I agree with Andrew. The popularity of our obscure topics is because we're the only online travel guide that has written about these things. I also wonder if social media played a role. A few of those niche articles may have been shared on Facebook, Twitter, Reddit, etc. and they may have gone moderately viral. Gizza ^(roam) 23:57, 2 January 2017 (UTC)[reply]

Template:ISBN I have ported over w:Template:ISBN and w:Module:Check isxn from en.wp. Magic words as links are being phased out and although we don't have to replace all instances of them now, they will all be removed from MediaWiki in 2017. See mw:Requests_for_comment/Future_of_magic_links. We have about 50 entries in Category:Pages using ISBN magic links. —Justin (koavf)❤T☮C☺M☯ 02:28, 1 January 2017 (UTC)[reply]

That's fine, but they should be marked experimental and discussed before widespread deployment, per our Wikivoyage:Using MediaWiki templates policy. Powers ^(talk) 00:08, 2 January 2017 (UTC)[reply]

I wish the WV community a happy and peaceful new year 2017. After the presentation together with Doc James in 2013 I decided to attend the Wikimania 2017 (if I will be one of the happy ones with a scholarship granted). After bad experiences at the WikiCon (denied submissions). I think about a lightning talk and a poster or WV booth. Maybe I will present some of our Wikidata features together with the Wikidata guys. Will some of you guys be around there?

What feature should be presented and talked about? I have the map features and our full automatic infoboxes and Wikidata features on the list. How about you? I think about your banners, listings but I am not 100 per cent up-to-date. I would be happy for some information and suggestions? -- DerFussi 07:21, 2 January 2017 (UTC)[reply]

Look forwards to seeing you there :-) Travel Doc James (talk · contribs · email) 10:55, 2 January 2017 (UTC)[reply]

I think features that distinguish Wikivoyage from other Wikimedia wikis include the breadcrumbs, the use of dynamic maps (Wikivoyage seems to be an early adopter of changes including the new OpenStreetMap integration via {{mapshape}}), the listing editor (particularly the new integration with wikidata), and the banners. There will probably be presentations at Wikimania about plans for better utilizing Wikidata as well as using structured data on commons for map shapes and tabular data like climate tables, both of which would be of huge benefit here, so any news you hear would be great to share. Enjoy the conference! -- Ryan • (talk) • 15:58, 2 January 2017 (UTC)[reply]

Thanks I will keep that in mind. We have talked with Wikidata project manager about climate data at our association birthday in Berlin. We think only a bot should transfer the huge amount of data to WD. Do you know any free source for such data? Or a project that would provide the data under a free license. We have somebody here in Berlin for official communication. But currently we have no ides where we should the data get from.

Wikimedia Germany would like to have some little items made for us, like WV pens WV leaflets. Do you have any ideas what kind of items would be good to be spread out on meetings or at tourist information offices? Any ideas are welcome. I'll keep you up-to-date. -- DerFussi 06:54, 3 January 2017 (UTC)[reply]

I'm not sure about non-US sources for climate data, but for the US the National Oceanographic and Atmospheric Administration (NOAA) provides public domain data. I built a climate table generator that can be accessed at [2]. I would expect that Wikipedia may eventually transfer their climate data to Commons in order to take advantage of the new shared data capabilities, at which time Wikivoyage could then make use of the data as well. -- Ryan • (talk) • 07:03, 3 January 2017 (UTC)[reply]

Just because I don't see it mentioned above, Montreal will be the location this year. I still feel bad that I didn't get to visit the one in Hong Kong a few years back because of a crazy work deadline Andrewssi2 (talk) 09:52, 3 January 2017 (UTC)[reply]

Dates are August 9-13th. Details at [3].

Lots of WV folk are nearby. I will be by then, User:AndreCarrotflower is not far, the original WT founders User:EvanProdromou and User:(WT-en)_Maj live in Montreal, and there are others. Pashley (talk) 11:38, 3 January 2017 (UTC)[reply]

Sorry, I forgot to mention the venue for Wikimania. @Andrewssi2. Yeah. Would had been great to meet in Hong Kong. That was the Wikimania when I did the presentation with James. Nice to hear that some of you guys will be nearby then. -- DerFussi 13:33, 3 January 2017 (UTC)[reply]

User:DerFussi, I think that a travel-related gift might be appropriate. A luggage tag or a pair of disposable foam earplugs (in a box with the Wikivoyage logo) could be relatively inexpensive. WhatamIdoing (talk) 17:56, 4 January 2017 (UTC)[reply]

User:WhatamIdoing. Both ideas are really great. I'll put it on my list when I talk with the WMDE guy. Thanks. -- DerFussi 19:36, 4 January 2017 (UTC)[reply]

So this year is invariably drawing to a close and while we have had some successes here at WV, we are far from finished with anything (no wiki ever truly is). I think the past year has been mostly positive for the community (I neither recall any high profile conflicts nor anybody of note leaving, but I may have overlooked something), although it was not a good year for people interested in travel as a whole. War zones seem to be getting worse, not better, and the calls for ever tighter "security", especially in the context of borders bear ill for the future. Brexit may well mean travel between the UK and the EU becoming more difficult. But at any rate our community here can do nothing about those developments and I hope we can keep discussions as apolitical as possible, even if some users might be able to guess the political biases of some others.

So, let us not further focus on what was in 2016, but rather what we want to do in 2017. I think there are some ongoing projects as well as some new ones to keep us busy starting tomorrow.

1. Develop at least one of American football, Intercity buses in Germany or rail travel in Germany to be ready to be featured
2. Continue SEO edits, especially to high profile articles (countries, continent(al section)s, major cities) in order to hopefully draw more eyeballs our way
3. Reduce the number of bare outlines through mergers, deletions and more content, promoting them if possible to usable
4. Hopefully do some on the ground research for articles on Nicaragua
5. If possible do some on the ground research on other destinations as well

At any rate, I hope you have a safe and pleasant New Year's Eve (take a piece of advice from a New York Giants fan: Be careful around fireworks) and a good 2017. I would love to hear your plans on wiki, and if you want to share them off-wiki. Guten Rutsch Hobbitschuster (talk) 15:03, 31 December 2016 (UTC)[reply]

@Hobbitschuster: My only big goal is really perfecting Indianapolis and building on all of the hard work that Sarah did and that I have done since. I wish I could have found the time to polish it up as featured for the Indy 500 but it wasn't going to happen with my schedule. I will be more free this year which is exciting. —Justin (koavf)❤T☮C☺M☯ 17:10, 31 December 2016 (UTC)[reply]

Swept in from the pub

Swept in from the pub

If I'm not mistaken, there is such a tool that does this quite fast (and I am hoping such a tool would help me tremendously in locating the most prolific and knowledgeable "local experts" over at Wikipedia for specific destinations, whom I'm hoping would agree to help expand the parallel articles on Wikivoyage). ויקיג'אנקי (talk) 02:31, 16 February 2017 (UTC)[reply]

Yup, there is https://tools.wmflabs.org/xtools-articleinfo/index.php?article=busan&project=en.wikivoyage.org --Andrewssi2 (talk) 02:39, 16 February 2017 (UTC)[reply]

Thanks Andrewssi2. I tried using this tool in order to find out if any Hebrew-speaking "local experts" took part in the the creation of specific top destinations articles over at the Hebrew Wikipedia since the early 2000s... unfortunately, I ended up finding out three things - (1) even prominent articles on Wikipedia, that appear to be very complex, and have been gradually improved for a very long while, aren't very big in size or complex with travel oriented details in comparison to our Wikivoyage articles (2) most top contributions on those Wikipedia articles were actually made in the previous decade (3) to my surprise, in many cases there are very few people whom actually contributed most of the content to each of those articles, and most of those people are the same ~40 most active editors on the Hebrew Wikipedia whom in many cases contribute translations from the English Wikipedia content and therefore it seems that many Hebrew speaking "local experts" were involved the creation of the content, but in reality it usually is only 1-3 translators translating the majority of the content about a destinations they most likely have never been to.

Here's an example of what I mean.... a comparison of the top 10 editors of the Barcelona article in the Hebrew Wikipedia (this has been the most popular destinations among Hebrew speakers) with a comparison to the top 10 editors of the Barcelona article in the Hebrew Wikivoyage:

As you can see, my contribution alone, on the Barcelona article in Hebvoy, is much bigger than all top contributions to the same article on the Hebrew Wikipedia.

This method might work better for getting English speaking local experts from the English Wikipedia. ויקיג'אנקי (talk) 01:32, 17 February 2017 (UTC)[reply]

Swept in from the pub

As mentioned above most web interaction is now by smart phone. To get more visitors to this site we need to get the mobile app more useful for users and easier to use. Do we have a forum page to discuss ideas and suggest improvement? If not how should this be structured? Would this be a Wikivoyage Expedition page? Sort of ideas I am thinking about see User:Traveler100/mobile, where should I copy/move this to? I have no idea how the mobile app is managed and who controls it. --Traveler100 (talk) 10:04, 24 December 2016 (UTC)[reply]

Is there a Wikivoyage app for android and where can I get it? I think it's OK if this is handled in an expedition page. --Zerabat (talk) 20:39, 22 February 2017 (UTC)[reply]

@zerabat: There is this one and a European one from m:Wikimedia CH. —Justin (koavf)❤T☮C☺M☯ 20:53, 22 February 2017 (UTC)[reply]

Swept in from the pub

So merger discussions are a rather frustrating experience on this wiki. Usually the merge template sits on a page for weeks or even months without much input. Votes for Deletion has much more participation, but the consensus seems to be that vfd is not for discussing mergers (even though there are preciously few articles for which vfd is even the right page - many pages are either candidates for speedy deletion or for mergers). So what should be done about this? My proposal is to have one page similar to vfd where proposed mergers have to be put and people can argue there whether the mergers makes sense or not. What do you say? Hobbitschuster (talk) 00:05, 7 March 2017 (UTC)[reply]

Support unreservedly. Sometimes you never know you want something until someone else mentions it. --ThunderingTyphoons! (talk) 00:15, 7 March 2017 (UTC)[reply]

Mild Support. I'll agree that merge discussions on individual articles has low visibility, although I'm not keen to set up more bureaucracy. Would like some alternative suggestions how this can be achieved. Andrewssi2 (talk) 00:37, 7 March 2017 (UTC)[reply]

Why?. There is a list here, text should be in the template and further discussion on the talk page. Also for countries with active Expeditions have an additional central point to highlight. Why do we need more? --Traveler100 (talk) 00:55, 7 March 2017 (UTC)[reply]

Clearly nobody uses those. I think it would be better not to have the merge discussion at individual talk pages but rather at something like WV:Merger discussions that would work similar to vfd. Hobbitschuster (talk) 01:19, 7 March 2017 (UTC)[reply]

It should not be about another talk shop page but about doing. --Traveler100 (talk) 03:45, 7 March 2017 (UTC)[reply]

I'm not sure you quite understand what I'm saying. Imagine all vfd discussions were held at the talk pages of the article nominated for deletion. This I think is an absurd thing for a wiki of this size. What I propose is in essence to have the same collection page for merge discussions as we have for deletion discussions and for discussion to take place there exclusively, which reduces the need for pointers and reminders. Of course the actual discussion process will be slightly different as we have no policy not to redirect real places and so on, but I hope you get what I am aiming towards. Hobbitschuster (talk) 03:47, 7 March 2017 (UTC)[reply]

Why do you think more attention will be paid to merge/redirect discussions if they're held at a dedicated page? I'm unconvinced. Ikan Kekek (talk) 09:38, 7 March 2017 (UTC)[reply]

Because people can watchlist that page, while they probably do not have the random to-be-merged articles on their watchlist. The cure is for everybody to watchlist Category:Articles to be merged – that works nowadays. Also, if that does not work, why not just go ahead and merge, if nobody interested in the involved articles (and therefore noticing the merge suggestion) cares enough to voice an opinion. --LPfi (talk) 11:57, 7 March 2017 (UTC)[reply]

(starting at the left again) the event that caused me to raise this issue is that Soazza was merged not following established protocol, likely out of frustration how that usually goes and then unmerged by another user who thinks it should not have been merged. I think vfd for all its faults works better than having deletion discussions on individual talk pages or the pub. Why not do the exact same thing for merger discussions? Maybe we can introduce it with a trial period and if after x amount of time we decide it didn't work we can go back to the old way or try an entirely different approach... Hobbitschuster (talk) 18:44, 7 March 2017 (UTC)[reply]

You know what? I want to be able to have these conversations in both places at the same time. I want it on a central page and on the article's talk page, and without any participation-preventing complications like transcluding subpages. This kind of multi-location discussion was planned years ago for mw:Flow (along with features such as being able to watch one discussion but not the rest of a page), but it hasn't been implemented anywhere. It would be ideal for something like VFD.

As an aside, the more I use Flow at mediawiki.org, the more I like it. (Just don't tell the devs that, because I have a long list of demands friendly requests for improvements, like "remind me of this discussion next week, especially if nobody's commented since then".) If you haven't seen it before, then you can try it out at mw:Flow/Sandbox. WhatamIdoing (talk) 23:02, 7 March 2017 (UTC)[reply]

Support - I reverted the merger of Soazza, partly because I was irritated that it was done with no discussion just a few hours after I had done several edits and added a banner photo. So I would emphasise the importance of providing the opportunity for such discussions. Mergers should only be done without discussion if there have been no edits in the last year (ignoring technical edits by regular contributors, but taking particular note of content additions by occasional editors or IPs). We don't want to frustrate the occasional editor that drops by once a month. I think that the article talk page should be used for the discussion, but a central index page would be useful. This could just have a link to the article, the country and the date. A central discussion page might be off-putting to occasional contributors. It is important to provide the opportunity for discussion, even if most times there are no takers - this can be taken as approval after a few weeks. I do like the sound of Flow, but it is probably not today's solution. AlasdairW (talk) 23:33, 7 March 2017 (UTC)[reply]

Technical question Is it possible to have some script that has a discussion transcluded to another page? What I mean by that is having the discussion displayed both on the talk page and on (tentative name) WV:Votes for Merger and users able to contribute to both. That way many of the potential downsides (that I frankly don't see, but whatever) of having the discussion only at one central page would disappear. Hobbitschuster (talk) 23:37, 7 March 2017 (UTC)[reply]

We already have Requests for comment. Should we simply use that page to advise everyone about merge/redirect discussions? Ikan Kekek (talk) 23:47, 7 March 2017 (UTC)[reply]

I myself hardly ever read requests for comment and I fear the same is true for many users here. Hobbitschuster (talk) 01:19, 8 March 2017 (UTC)[reply]

Pardon me for putting it this way, but: So what? If you knew merge/redirect discussions were pointed to there, you'd look at it, and if you think no-one would, then your proposed new page won't be followed, either. Ikan Kekek (talk) 01:57, 8 March 2017 (UTC)[reply]

I just looked at requests for comment - apparently there is one request from way back in 2015 still up there. And I still don't get why we should handle merge discussions and deletion discussions so fundamentally differently. Imho we could also have articles nominated for redirecting on vfd, because "deletion" is a valid outcome in only a fraction of the articles we have as is. Hobbitschuster (talk) 13:24, 8 March 2017 (UTC)[reply]

I think the point is that merge/redirect discussions should be on the talk page of the relevant article. Anywhere else, they would be pointers to that page. And I still doubt your point about Requests for comment is valid, unless there's some psychological reason people dislike the phrase "Requests for comment". But as I see it, either people will pay attention to pointers or they won't, regardless of what you call the pointer page. Ikan Kekek (talk) 13:57, 8 March 2017 (UTC)[reply]

As others have noted, "merge" is often the outcome of a VfD discussion. Since the VfD page is not overly burdened, how about combining the two sets of discussions into a "Votes for deletion or merger" page? Or, if that is a problem, and I don't know why it should be, then at least allow pointers to merge discussions on the VfD page. Ground Zero (talk) 15:37, 8 March 2017 (UTC)[reply]

So how would you handle something like Paradise (Michigan) and Whitefish Bay where there was some disagreement as to which direction the merger should go? Paradise is a tiny speck-on-a-map village which had just one {{listing}} for some venue which is now closed. As a destination, it was useful primarily as a target for jokes about the distance from Paradise (Michigan) to Hell (Michigan). Whitefish Bay was created as a large, sparse rural area - there's a lighthouse and museum on Whitefish Point with some tie to the Edmund Fitzgerald sinking but little else. IIRC, someone tagged {{merge}} onto Whitefish Bay because they didn't like bodies of water, then someone else tagged {{merge}} to go the other way (merging Paradise village into the larger rural area as there's nothing there). I look at the history of both pages and see little or no actual discussion taking place - just randomly merge this somewhere on the assumption the next editor could undo the mess? K7L (talk) 15:47, 8 March 2017 (UTC)[reply]

One important thing to remember is that mergers do not necessarily require a discussion. For pages where others have invested time, especially recently (like AlasdairW's example) it is common sense and proper courtesy to discuss on the talk page first. In most cases, such talk pages are also on those editors' watchlists. For underdeveloped, more straightforward cases I don't see why we would let go of the "plunge forward" principle by introducing a new VfD-like discussion page, with accompanying policies and waiting times. That seems like bureaucracy - which is the last thing we need. If we think more pointers are needed, we could simply start by using the requests for comments page more extensively for that purpose. If there is more "traffic" on that page, I imagine people with an interest who haven't done so yet can simply put that page on their watchlist. I don't see why we need a new page because "some" people hardly read requests for comments. JuliasTravels (talk) 17:05, 8 March 2017 (UTC)[reply]

Hobbitschuster, on your technical question: You can do that, sort of, by creating a separate page. You can see how it works (or doesn't) on a page such as https://en.wikipedia.org/wiki/Talk:Henrietta_Lacks#GA_Review That's only transcluded onto the one talk page, but it could theoretically be transcluded to a nearly infinite number. WhatamIdoing (talk) 21:50, 8 March 2017 (UTC)[reply]

I was the one who did the merger in Soazza and I wanted to give my inputs on the whole topic. I have done a couple of merges in the past year or so, as I was trying to clean up regions and articles in Switzerland. There is quiet a few small destinations with articles which have not been edited in sometimes 10 years and with very little content and not fulfilling the criteria to merit an article on their own. I found that, as mentioned above, most of the times calls for input on talk pages have no to little effect, which is a bit frustrating, especially when it comes to more complex merges such as reorganisations of regions etc. (For instance here: Talk:Surselva#Should_we_simplify_the_region_hierarchy or Talk:Graubünden). As pointed out above by others, I'm not sure whether creating a new page to centralise these discussions will help, as this just adds another page people might not notice. What would help in my opinion is clearer guidelines on when it's okay to merge without having to wait for inputs and what an adequate period of time would be to wait for inputs after starting a discussion on the talk page. For instance, I do agree that for Soazza I should have started a discussion, as there were recent edits, but I don't think an article that hasn't had any substantial content added since 2007 needs much discussion (such as Talk:Finhaut). Wikivoyage:How_to_merge_two_pages is rather vague on this. Drat70 (talk) 04:07, 9 March 2017 (UTC)[reply]

There is the general problem that some "specks on the map" are clearly candidates for merging, but the person who sees that is not necessarily willing or able to do the legwork of finding out what a good reorganization of the hamlets in the area would look like. In general geotagged listings would help a bunch, because when you look at the map of Soazza, you can see that those listings cover a linear area. Hobbitschuster (talk) 21:25, 9 March 2017 (UTC)[reply]

In some cases, the {{geo}} tag on individual articles is enough to flag that two very tiny places are adjacent, for instance Blumenort and Steinbach, Manitoba. Unfortunately, the 'nearby destinations' layer on the dynamic map doesn't indicate whether the actual articles are outline or even rubbish - only that two point to almost the same geographic area. K7L (talk) 18:46, 10 March 2017 (UTC)[reply]

The question of how long is reasonable to leave a merger discussion open is a good one. I just came across Sevagram, which I have proposed to merge. There has been little activity on the article, and its creator has not been seen for two years. I have posted on RfC, and plan to complete the merger in one week unless there are objections. I think that is a reasonable time, as we do want to keep things moving here. Is one week too short? Ground Zero (talk) 18:21, 10 March 2017 (UTC)[reply]

Swept in from the pub

Swept in from the pub

There are a lot of small changes happening in the next couple of weeks, and I wanted to give you all a quick heads-up about them. Please share this information with other people/languages/projects that will be interested:

• There's a change to how columns in reference lists are handled, at the request of the German Wikipedia. This change will improve accessibility by automatically formatting long lists of <ref>s into columns, based on each reader's screen width.
  • What you need to do: Nothing visible is happening now. If your project uses the normal <references /> tag (or doesn't really use refs at all), then file a Phabricator task or just tell me, and I'll get your wiki on the list for the next config change. If your project uses a "reflist" template to create columns, then please consider deprecating it, or update the template to work with the new feature.
• The label on the Save changes" button will change on most projects tomorrow (Wednesday) to say "Publish page". This has been discussed for years, is supported by user research, and is meant to be clearer for new contributors. (Most of us who have been editing for years don't even look at the button any more, and we all already know that all of our changes can be seen by anyone on the internet, so this doesn't really affect us.)
  • If you have questions or encounter problems (e.g., a bad translation, problems fixing the documentation, etc.), then please tell me as soon as possible.
  • When we split "Save page" into "Save page" and "Save changes" last August, a couple of communities wondered whether a local label would be possible. (For example, the Chinese Wikipedia has some extra language on their "Save page" button; I think it's about the importance of previewing.) Whether the Legal team can agree to a change may depend upon the language/country involved, so please ask me first.
• As part of the ongoing, years-long user-interface standardization project, the color and shape of the "Save changes" (or now "Publish page"), "Show preview" and "Show changes" buttons on some desktop wikitext editors will change. The buttons will be bigger and easier to find, and the "Save" button will be bright blue. (phab:T111088) Unfortunately, it is not technically possible to completely override this change and restore the appearance of the old buttons for either your account or an entire site.
• Do you remember last April, when nobody could edit for about 30 minutes twice, because of some work that Technical Ops was doing on the servers? The same kind of planned maintenance is happening again. It's currently scheduled for Wednesday, April 19th and Wednesday, May 3rd. The time of day is unknown, but it will probably afternoon in Europe and morning in North America. This will be announced repeatedly, but please mark your calendars now.

That's everything on my mind at the moment, but I may have forgotten something. If you have questions (about this or any other WMF work), then please {{ping}} me, and I'll see what I can find out for you. Thanks, Whatamidoing (WMF) (talk) 18:37, 13 March 2017 (UTC)[reply]

The time for the server switch project has been confirmed. All of the wikis will be in read-only mode for 20 to 30 minutes on two days soon:

• Wednesday, 19 April 2017, starting at 14:00 UTC
• Wednesday, 3 May 2017 (two weeks later), starting at 14:00 UTC

If you are a MediaWiki hacker, then please note that the normal deployment schedule has been canceled during both of those weeks.

There is more information at m:Tech/Server switch 2017, including a link to the official schedule. Please leave a message on my user talk page or "ping" me if you have any questions. Whatamidoing (WMF) (talk) 22:03, 29 March 2017 (UTC)[reply]

Swept in from the pub

05:09, 18 March 2017 (UTC)

A local page for this at Wikivoyage:Wikimedia Strategy 2017 has been created, if you'd prefer to participate here instead of on Metawiki. Looking forward to your input! :) Quiddity (WMF) (talk) 00:42, 22 March 2017 (UTC)[reply]

Swept in from the pub

The annual Commons Picture of the Year competition has started, and I think that it may be good to see if there are any pictures there that could be put in the articles here, they are all high quality pictures.  Seagull123  Φ  16:59, 18 March 2017 (UTC)[reply]

Swept in from the pub

Please accept our apologies for cross-posting this message. This message is available for translation on Meta-Wiki.

On behalf of the Wikimedia Foundation Elections Committee, I am pleased to announce that self-nominations are being accepted for the 2017 Wikimedia Foundation Board of Trustees Elections.

The Board of Trustees (Board) is the decision-making body that is ultimately responsible for the long-term sustainability of the Wikimedia Foundation, so we value wide input into its selection. More information about this role can be found on Meta-Wiki. Please read the letter from the Board of Trustees calling for candidates.

The candidacy submission phase will last from April 7 (00:00 UTC) to April 20 (23:59 UTC).

We will also be accepting questions to ask the candidates from April 7 to April 20. You can submit your questions on Meta-Wiki.

Once the questions submission period has ended on April 20, the Elections Committee will then collate the questions for the candidates to respond to beginning on April 21.

The goal of this process is to fill the three community-selected seats on the Wikimedia Foundation Board of Trustees. The election results will be used by the Board itself to select its new members.

The full schedule for the Board elections is as follows. All dates are inclusive, that is, from the beginning of the first day (UTC) to the end of the last.

• April 7 (00:00 UTC) – April 20 (23:59 UTC) – Board nominations
• April 7 – April 20 – Board candidates questions submission period
• April 21 – April 30 – Board candidates answer questions
• May 1 – May 14 – Board voting period
• May 15–19 – Board vote checking
• May 20 – Board result announcement goal

In addition to the Board elections, we will also soon be holding elections for the following roles:

• Funds Dissemination Committee (FDC)
  • There are five positions being filled. More information about this election will be available on Meta-Wiki.

• Funds Dissemination Committee Ombudsperson (Ombuds)
  • One position is being filled. More information about this election will be available on Meta-Wiki.

Please note that this year the Board of Trustees elections will be held before the FDC and Ombuds elections. Candidates who are not elected to the Board are explicitly permitted and encouraged to submit themselves as candidates to the FDC or Ombuds positions after the results of the Board elections are announced.

More information on this year's elections can be found on Meta-Wiki. Any questions related to the election can be posted on the election talk page on Meta-Wiki, or sent to the election committee's mailing list, board-electionswikimedia.org.

On behalf of the Election Committee,
Katie Chan, Chair, Wikimedia Foundation Elections Committee
Joe Sutherland, Community Advocate, Wikimedia Foundation

Posted by MediaWiki message delivery on behalf of the Wikimedia Foundation Elections Committee, 03:37, 7 April 2017 (UTC) • Please help translate to your language • Get help

Swept in from the pub

Hi, I'm Szymon, a MetaWiki Strategy Coordinator. 3 weeks ago, we invited you to join a broad discussion about Wikimedia's future role in the world. The discussion is divided into 3 cycles, and the first one ends on April, 15. So far, Wikimedians have been discussing mainly about technological improvements, multilingual support, friendly environment, cooperation with other organizations and networks.

• If you'd like to get detailed information about the discussed topics, have a look at → that page.
• If you'd like to join the discussions, please comment → on the talk page of that page or on Meta-Wiki.
• If you have any questions that weren't answered there, feel free to ask me.

I'm pinging a few recently active admins. I hope you'll help me with passing along the news, maybe even join the discussion. @AndreCarrotflower, Andrewssi2, ‎Ikan Kekek, WOSlinker, ‎Shaundd:.

Looking forward to your input. Thank you in advance! SGrabarczuk (WMF) (talk) 00:46, 8 April 2017 (UTC)[reply]

Szymon's "real" name is Tar Lócesilion, and I suspect that some of you have encountered him under that name. I encourage you all to take him up on the invitation to talk about what you'd like to see happen during the next 10–20 years. Better mobile experience? Easier cross-language or cross-project integration? Efforts to engage potential editors, maybe with something that uses smartphone-based geolocation to request specific updates and edits? Whatever's on your mind, especially if it's a big idea, it should be proposed now. WhatamIdoing (talk) 01:58, 8 April 2017 (UTC)[reply]

Not a big idea by any means, but today I found myself copying geo-coordinates by hand from de-WV Herzogenaurach to the en-WV equivalent and was thinking to myself: There's gotta be a better way. Hobbitschuster (talk) 02:02, 8 April 2017 (UTC)[reply]

@SGrabarczuk (WMF), WhatamIdoing: in Russian Wikivoyage, we came up with a rather long list of thoughts and ideas concerning the strategy and the strategy-building process itself. We have a short English summary toward the end of this page and plan on translating the rest later this week.

As a side note, the Russian-speaking strategy coordinator, who promised to make the translation for us, already disappeared, which kind of tells us what to expect from this strategy in the future. --Alexander (talk) 23:21, 9 April 2017 (UTC)[reply]

Now we have a full English translation for our vision of the strategy. A significant part of it describes the development of Wikivoyage. Any comments are welcome. --Alexander (talk) 19:56, 14 April 2017 (UTC)[reply]

Swept in from the pub

Wikivoyage currently shows related articles on a handful of pages where editors have added them for example on the New_York_City page New_York_City_with_children appears in the sidebar (Although it's rather hidden away!) of the desktop skin and does not work on mobile.

It uses the mw:Extension:RelatedArticles extension.

Wikimedia recently enabled a much more visual form of the related pages feature on a variety of projects. I was curious if Wikivoyage were interested in switching from the sidebar view to the footer view?

Benefits:

• More visual and discoverable
• It can be configured to algorithmly suggest related pages (you can see how this would look by scrolling to the bottom and clicking on links in https://trending.wmflabs.org/en.wikivoyage/Bagan )
• It works on mobile

An illustration can be seen here: https://www.mediawiki.org/wiki/File:Readmore-_desktop-_prototype.png

and you can see what it looks like on Vector by looking at Haitian Wikipedia: https://ht.wikipedia.org/wiki/Frank%C3%A9tienne

No pressure!

If you are interested I can enable it at a time of your choosing, and revert back to the old view if you decide you do not like it. Let me know! Jdlrobson (talk) 22:39, 20 April 2017 (UTC)[reply]

I am in favour of having trying this :-) I often fail to discover relevant articles when preparing a trip, and learn about them only after my trip is over. Syced (talk) 05:55, 21 April 2017 (UTC)[reply]

Jdlrobson, that sounds interesting. Could you elaborate on how this system chooses related pages? I read the descriptions but did not understand much. Thanks! --Alexander (talk) 07:40, 21 April 2017 (UTC)[reply]

I think this looks cool! --ButteBag (talk) 14:55, 21 April 2017 (UTC)[reply]

The algorithm version uses a CirrusSearch feature which relates pages with similar text. For instance if the phrase "Roman architecture" appears in two articles frequently they would be judged similar. All results can be overriden by editors using

{{related}}

magic word. The results are not always great as with any algorithm. Some pages, especially smaller articled may spit out strange related articles but it's a great way to encourage exploration and create editing opportunities IMO. Jdlrobson (talk) 15:39, 21 April 2017 (UTC)[reply]

I've had it turned on at a couple of wikis, and overall I like it. The last time I checked, the three articles it selects were usually next three articles that you'd find if you did a regular search on the current article's title. So for New York City, I'd expect it to list New York (state), Metro New York, and New York City with children, because those are the next in the normal list of search results. WhatamIdoing (talk) 21:31, 21 April 2017 (UTC)[reply]

Personally I don't generally like sidebars (though some for apps they are appropriate). The problem with them is that the sidebar content is invariably a different length from the main content so you invariably end-up with a column (normally in the sidebar) of blank space wasting screen space (many users will probably be on netbooks of small laptops with limited screen space). And on mobile where I don't get a sidebar I also lose the related Wikipedia link from the sidebar. So I think reducing the sidebar is a good thing, moving related links to the bottom is a good idea (including any wikipedia link). Unsure about algorithmically doing it through making "Read More" more prominent (as in the linked example) looks good and may encourage contributors to use it more (which must be a good thing). So I like the proposed change (even though I realise it will not get rid of the sidebar) PsamatheM (talk) 09:41, 22 April 2017 (UTC)[reply]

Would the Read More be limited to internal WV pages or external web sites and Wikipedia articles also be allowed. I can think of at least one example page I've contributed to where is more than one relevant (non-duplicate, non-overlapping wikipedia article thinking of Blakeney (Norfolk) where Wikipedia has seperate pages on Blakeney and Blakeney Point but WV only really warrants a single page for the two destinations). PsamatheM (talk) 09:41, 22 April 2017 (UTC)[reply]

I am not keen on a text based search that takes no account of geography. If I am reading York, I have no interest in New York City, or other random towns that have a York Hotel or York Road. What would be useful is automatic suggestions of places within 100 miles that had the matching text. AlasdairW (talk) 14:07, 22 April 2017 (UTC)[reply]

Yes it doesn't take into account geography and that's something important to factor in but it's also a little more clever than that for well written pages like York (it shows Bradford and Lincoln). The lack of geographical awareness isn't necessarily a bad thing as it may be useful (at least it is to me) to discover places in countries that the reader hasn't been to that might be related to places in countries they have been. Remember go next is about geography and this would not try to replace that.

As I've mentioned editors can override all articles related pages with whatever makes sense for the community definition of related.

Given the lack of use of related pages (it's on very few pages) and the increased invisibility of putting these links in the footer I would expect turning on the algorithm to increase editing of these results. Jdlrobson (talk) 14:57, 24 April 2017 (UTC)[reply]

If the automated results can be overridden then it just becomes part of authoring and maintaining the page. If you manually set the related pages (even just one) does this disable all the automatic ones - so if the automatic ones give "bad results" you can disable all the automated with just one manual one. Or is there some way to add something

{{ related }}

to just disable the automated system if the results are just bad. PsamatheM (talk) 15:12, 24 April 2017 (UTC)[reply]

This is currently not supported, but probably could be added. Jdlrobson (talk) 18:01, 26 April 2017 (UTC)[reply]

Swept in from the pub

Does such a list exist already or is there any way to generate such a list?

Such a list would be very handy for each Wikivoyage edition (including the English Wikivoyage) to get some more insight into which of the most popular travel destinations around the globe world didn't get yet their own articles (and by focusing on creating those articles, instead of articles of less popular destinations, eventually increasing the web traffic much more significantly for the same amount of work). ויקיג'אנקי (talk) 19:25, 22 April 2017 (UTC)[reply]

The problem with this is that most editors are unable to churn out article level prose in more than one to three languages. And even those that can may not want to spend their time writing about New York in Swahili, when they'd much rather cover stuff they personally know and care more about. Hobbitschuster (talk) 19:28, 22 April 2017 (UTC)[reply]

I understand that eventually each editor can only produce so much articles, and usually one would prefer to focus on what interests them. I myself have written articles in the Hebrew Wikivoyage for 4 years and 3 months (I mostly translate content from the English Wikivoyage), and I also follow closely after the page view statistics of the articles I have put most work into. Although up until today I have written mostly outline articles on Hebvoy, I have created probably close to a 100 expanded well written articles (some of which took me weeks to finish). Nevertheless, based on the page view statistics... some of them are only read by a few people each month even though a lot of work was put into creating them... simply because people don't necessarily care for well expanded articles if the destination isn't interesting enough to many people (even the Israel article in Hebvoy gets relatively few views every month, probably since most Hebrew speakers aren't interested in reading about their own country when they research travel options/ideas). Because of that, at this point, in order that the the amount of work I put into Hebvoy would eventually yield more interest among potential readers, I tend to prefer focusing on creating the content which is most sought after (rather then guessing what it is). ויקיג'אנקי (talk) 19:44, 22 April 2017 (UTC)[reply]

I think most potential users of hebvoy are more likely to use engvoy. First of all because many Hebrew speakers also speak at least passable English and secondly because for travel outside Israel, English is vastly more useful than Hebrew. Hobbitschuster (talk) 21:38, 22 April 2017 (UTC)[reply]

Possibly... but that doesn't mean that I should give up on Hebvoy. On the contrary, I believe that eventually the English Wikivoyage and the rest of the Wikivoyage editions are going to be a lot more popular, have a lot more writers whom speak many languages, and that even though the English Wikivoyage would probably always remain the biggest edition of Wikivoyage, the existence of the other editions would help us over time produce much more quality content collaboratively, and have many more people around the world involved in this process (and eventually, just like in the case of Wikipedia, in many instances you'll eventually see a lot of content being translated back to the English Wikivoyage as a result). ויקיג'אנקי (talk) 02:25, 23 April 2017 (UTC)[reply]

Instead, why not translating the articles with the largest number of views (you can get them here for the languages with the largest audience; you can get a rough idea of the audience of each Wikivoyage edition here? I translated pages about Japan from English to French based on both the page size and the audience, but the number of views stay quite limited (though Japan pages in French Wikivoyage have now the second largest audience and pages sizes, after France) so I am afraid that your efforts will only bring limited results. — Fabimaru (talk) 07:30, 23 April 2017 (UTC)[reply]

Does anyone know if it is possible to produce a list of Wikivoyage articles sorted by the amount of articles that exists for each destination in each wikivoyage edition? ויקיג'אנקי (talk) 02:25, 23 April 2017 (UTC)[reply]

The relationship are stored in Wikidata, and it may be possible to do a SPARQL query, but after a quick attempt I could not find how to do such a query. — Fabimaru (talk) 08:11, 23 April 2017 (UTC)[reply]

Ask at https://www.wikidata.org/wiki/Wikidata:Request_a_query and you will have your data soon :-) (and the query to check realtime) Syced (talk) 04:08, 26 April 2017 (UTC)[reply]

Swept in from the pub

As you know Mediawiki is to get a new parser. I've been over the past few days (in good faith), been trying to repair some of the templates/pages it's flagged up as having problems.

However, in some cases I've been unable to find a 'stable' fix for many of the errors.

I'm thus coming to the conclusion that I am either too stupid to actually understand what's going on, or that the analysis tool is being pedantic about something that's not techincally broken.

As such I've had enough of trying to work around an analysis tool that is being pedantic about precise nesting, matching of tags etc., Please either take the time to PROPERLY fix the relevant templates once and for all, or make very strong representations to the Mediawiki developers responsible for the new parser/Linter extension about it's inability to recognise otherwise valid situations, so that I'm not wasting my time apparently "breaking" templates, that did not need to repaired in the first place ...

The pages with "apparent errors" are here: https://en.wikivoyage.org/wiki/Special:LintErrors ShakespeareFan00 (talk) 08:44, 23 April 2017 (UTC)[reply]

I see what you are saying, some I cannot see what is wrong, others are very subtle. These got rid of errors markings: italics inside italics not sure maybe the web address in content or is there a spellchecker. --Traveler100 (talk) 09:26, 23 April 2017 (UTC)[reply]

I've been talking to the Parsing team about this off and on for a few months. The stuff that's flagged is stuff that "works" now but is going to break pages later (probably later this year). User:SSastry (WMF) has been awesome about answering questions, so if you have particular pages that you can't figure out from the documentation on mediawiki.org, then let's get a list together and ask him for help. Whatamidoing (WMF) (talk) 20:37, 23 April 2017 (UTC)[reply]

User:ShakespeareFan00, thanks for your proactive work trying to address this. This flow topic is relevant to this discussion. But, this is also the reason why we haven't yet made a wide announcement about Linter since we are trying to figure out the best way to provide actionable guidance. But, we have been discussing whether it might be better and more useful to categorize this in terms of specifying which class of linter warnings/errors to fix to aid which goal. SSastry (WMF) (talk) 01:17, 24 April 2017 (UTC)[reply]

User:SSastry (WMF) , Thanks for the response. As a side effect, the Linter extension HAS exposed some things that weren't considered when certain templates were originally designed. Like a template that uses a span, instead of a div, because it wasn't considered that the relevant paramater in the span may contain (multiple) block level elements. Trying to resolve this exposed a futher concern about how "Mediawiki" was scoping where to put end of element markers. (See my last 2 reports on Phabricator for example.) ShakespeareFan00 (talk) 08:53, 24 April 2017 (UTC)[reply]

Perhaps someone can explain why this template (which should be relatively straightforward to fix so that it WILL work with the new parser is creating SO many issues? https://en.wikivoyage.org/w/index.php?title=Template:Warningbox&action=history , I've tried at least three times to get it to behave in a consistent way, and I'd now like an apology for my wasted time. Thanks.ShakespeareFan00 (talk) 16:32, 24 April 2017 (UTC)[reply]

What is the lint error you are trying to fix there? Can you point me to a page / lint error that you encountered? SSastry (WMF) (talk) 17:18, 24 April 2017 (UTC)[reply]

The issue was that in the template (pre my efforts) you have a span for styling, inside which is a list. Under HTML5 structuring, you can't put a list (block level item) inside a Span.

I've tried following the last three attempts to fix the 'live' template, put an attempt at a DIV based version here :- Template:Warningbox/sandbox, However if certain (optional) parameters are omitted, there's some undesired whitespace, that shouldn't be there.

Fixing Template:Warningbox should have been a simple effort, but for whatever reason owing to some limitations or other processing Mediawiki does, what should have been simple apparently isn't.

The issue of trying to put 'block level elements' inside a span also crops up with other templates, and may be why a large number of pages are showing up on the relevant Special page, because Template:Listing uses a span internally, despite on a number of pages, the relevant paramater to that template contains block level elements such as lists or wiki-text style paragraphs.

The thought was to convert spans like that to divs, but this ran into a different issue, namely that reported in https://phabricator.wikimedia.org/T163650, meaning that even if the template was converted, paragraphs would still need to be explicitly laid out using <p></p> which is time consuming.

It also doesn't help that elsewhere people seem to have a cultural issues with admitting that using unmatched </p> or <p>, is a 'bodge' to cover up a limitation of what could be a scoping glitch in the parser itself.

I've got a "little list" of other concerns about various 'bodge' or 'clever' solutions that shouldn't be necessary if certain things were properly fixed or re-desgined, but here probably isn't the best place to discuss them. ShakespeareFan00 (talk) 17:43, 24 April 2017 (UTC)[reply]

And another thing, which is a very big 'breaks everything' point, is that the colon notation used to indent on talk pages, are technically supposed to be for creating a definition list, NOT for indentation apparently. Of course changing this and getting EVERY talk page updated appropriately would be a massive undertaking. ShakespeareFan00 (talk) 17:46, 24 April 2017 (UTC)[reply]

I wanted to clarify something here. Not all the lint errors being identified are related to the replacement of Tidy with RemexHTML. Some lint errors are just markup issues that the new and old parser can "handle fine". But, this is in the same way that humans can understand most grammatical, spelling, and punctuation errors just fine. Some of it is definitely pedantic related to cleaning up markup for clarity and being explicit about intentions. Anyway, this will get clearer as we figure out the best way to categorize the lint issues we identify and surface them for editors. SSastry (WMF) (talk) 17:18, 24 April 2017 (UTC)[reply]

Summarising

Is it fair to summarise that moving from the sidebar to the footer is uncontroversial but using the algorithm requires a little bit more thought? If so would there be any objections to me enabling the display in the footer? Do I need to create an RFC to do that or can I just do it? Jdlrobson (talk) 18:01, 26 April 2017 (UTC)[reply]

User:Jdlrobson, go ahead and make the change. You'll wait forever for explicit consensus here. =) If we don't like it, we'll ask you to switch it back. Powers ^(talk) 20:35, 2 May 2017 (UTC)[reply]

Swept in from the pub

I am trying out a smart phone that I will be switching to very soon, and I found that in the mobile version, there are no images on the front page. When I switch to the desktop version on my smart phone, I see the banners for the featured articles (dotm, etc.), but everything is too wide to the right for me to be able to work with it effectively. It's very hard to find recent changes in the mobile version (I couldn't figure out how to do so).

So are the rest of you finding that the mobile version sucks? Is anything planned to improve it? Ikan Kekek (talk) 07:17, 26 April 2017 (UTC)[reply]

I raised this a while ago, got no response. Willing to help improve this but have no idea how to do that. How is the format of the mobile addition controlled? Who has access to the code to define what is shown and how the mobile form works? More to the point how can we change it? This is an important topic as most web browsing today is on mobile devises. --Traveler100 (talk) 07:26, 26 April 2017 (UTC)[reply]

I asked around, and local admins can make (at least) some changes. See mw:Mobile Gateway/Mobile homepage formatting for more information. Whatamidoing (WMF) (talk) 15:21, 26 April 2017 (UTC)[reply]

I think the current mobile view is a result of the limitations with the current architecture.

I had a look at this in a user page User:Jdlrobson/main_page to see how this might be improved.

A few suggestions after looking at this. 1) The map/ links at the top of the page are not as exciting as the content that follows and given search is so prominent in mobile (and branding) it doesn't really add much value there. Consider moving them down or removing them altogether from the mobile experience via nomobile class. 2) The banners are not mobile friendly - Inside the banners apply a mobile friendly min-width: e.g. 260px to the banner-box2 so that on mobile it takes up as much space as it possibly can. Shrink margin top from 2em to 0.2em. Update the css rule in MediaWiki:Common.css to 2em via media query. 3) Stop using a table based layout for Discover/Get involved. Tables are the most unfriendly mobile element you can use - use div's that stack in mobile.

Some limitations with the current design: 1) Mobile doesn't easily allow changing the color of link. The TemplateStyles extension is coming soon which will correct this. This will also allow you to put media queries in the Main page which will improve things a lot. 2) There is a bug that messes up formatting of headings for section collapsing (https://phabricator.wikimedia.org/T152055 will fix). In mean time you may want to use divs or strong tags instead of h2s and h3s in banners. 3) Currently page banners are used for these boxes. The problem with those is they are not ideal for mobile usage (short and wide) and they tend to be lots of kb to download - consider switching to image thumbnails so that they format more nicely on a 320px device. This also impacts the text inside the banners as they have limited vertical space to work with. 4) The carousel JS will not load on mobile. I'm not sure how friendly it is to mobile devices but that can be checked and added if the other problems can be worked out.

Hope this helps! Jdlrobson (talk) 16:52, 1 May 2017 (UTC)[reply]

Swept in from the pub

Dear Colleagues,

Wiki Loves Earth 2017, the photo competition aimed at collecting photos of protected natural areas, has started today. We seek to collect photos that can be used on Wikivoyage and also organize a satellite competition dedicated to page banners. We have held such a competition already last year and received 88 beautiful page banners for Russia, many of them currently used on Wikivoyage.

The submission rules are described here. In short, only banners which are made of your own regular submissions to WLE 2017 are eligible, and they must be uploaded via a special link. If you fancy page banner for a Russian destination, use a different upload link, because we will award a separate prize. The competition runs till the end of May.

All banners submitted for this competition will be evaluated by our jury. We will consider both artistic value of individual banners and their merit for Wikivoyage, namely whether the banner is used or can be used in Wikivoyage articles, how well it conveys the feel of the destination, etc. We will have two small prizes, one for banners of Russian destinations and one for banners from abroad.

If you don't fancy uploading page banners but feel interested in our initiative, you can join our jury and help us in grading the banners. Just leave us a note here or contact us in person, and we will get back to you.--Ymblanter (talk) 06:37, 1 May 2017 (UTC)[reply]

Hi Ymblanter . As far as I can tell the 'special link' is actually just the standard Upload Form with a new category ( Category:Page_banners_from_Wiki_Loves_Earth_2017 ) added. Can we just tag banner images with this category? --Andrewssi2 (talk) 06:56, 1 May 2017 (UTC)[reply]

Yes, all banners are uploaded into the special category. That's the idea. --Alexander (talk) 06:59, 1 May 2017 (UTC)[reply]

What happens if someone uploads a Crimea banner? Do the Russians start a war with Ukraine to claim it for themselves? K7L (talk) 13:29, 1 May 2017 (UTC)[reply]

Nothing happens. Since last year, Crimean natural objects are part of both Russian and Ukrainian competitions. The uploader decides which one he or she wants to be part of. --Alexander (talk) 19:41, 1 May 2017 (UTC)[reply]

Swept in from the pub

look closely at the dynamic map of Sydney/City Centre - according to this map the water in the bay that surrounds the Sydney Opera House has all dried up. How do we fix this funny mistake ASAP? ויקיג'אנקי (talk) 14:48, 1 May 2017 (UTC)[reply]

Interesting. The source map on OpenStreetMaps (LINK) looks OK, but the cached version on WikiMedia Maps (LINK) has this sudden land fill.

The help page suggests to fix OpenStreetMaps directly. It is possible the somebody vandalized the OSM map and it was cached before it was fixed. Perhaps look again later? Andrewssi2 (talk) 21:41, 1 May 2017 (UTC)[reply]

If it does not fix when the caches update, I have seen similar strangeness with water/land divisions under some rendering of OSM. In the case I have previously seen it was where the renderer (one of the best 3rd party rendering apps with an excellent reputation) was mis classifying area classed as "marina" as "water" rather than land, but these strange effects can come from minor issues with the renderer. In my own case it was a small area only apparent where river boundaries extended too far. openstreetmap.org rendered it fine, app just got land vs water wrong in the detail. Just a thought and I've not looked at why the harbour in Sydney appears empty. PsamatheM (talk) 21:51, 1 May 2017 (UTC)[reply]

If you zoom out - eventually the water reappears which may also be a clue - other maps appear to work fine. -- Matroc (talk) 21:54, 1 May 2017 (UTC)[reply]

Does anyone know whether the images are SVGs? There's some talk this week about w:en:WP:VPT about odd artifacts in SVGs. WhatamIdoing (talk) 04:49, 4 May 2017 (UTC)[reply]

PNG's PsamatheM (talk) 17:04, 4 May 2017 (UTC)[reply]

Who can we contact when stuff like this needs to be fixed? No one can do it from the Wikivoyage/Wikimedia community? ויקיג'אנקי (talk) 20:16, 2 May 2017 (UTC)[reply]

Swept in from the pub

Birgit Müller (WMDE) 14:29, 8 May 2017 (UTC)[reply]

I haven't tried this out yet, but it's supposed to be good.

Also, Birgit's super nice and helpful, so if you try it and run into any problems, then just ping her. WhatamIdoing (talk) 18:18, 8 May 2017 (UTC)[reply]

Swept in from the pub

Read this in another language • Subscription list for this multilingual newsletter

Did you know?

Did you know that you can review your changes visually?

When you are finished editing the page, type your edit summary and then choose "Review your changes".

In visual mode, you will see additions, removals, new links, and formatting highlighted. Other changes, such as changing the size of an image, are described in notes on the side.

Click the toggle button to switch between visual and wikitext diffs.

The wikitext diff is the same diff tool that is used in the wikitext editors and in the page history. You can read and help translate the user guide, which has more information about how to use the visual editor.

Since the last newsletter, the VisualEditor Team has spent most of their time supporting the 2017 wikitext editor mode which is available inside the visual editor as a Beta Feature, and adding the new visual diff tool. Their workboard is available in Phabricator. You can find links to the work finished each week at mw:VisualEditor/Weekly triage meetings. Their current priorities are fixing bugs, supporting the 2017 wikitext editor as a beta feature, and improving the visual diff tool.

Recent changes

• A new wikitext editing mode is available as a Beta Feature on desktop devices. The 2017 wikitext editor has the same toolbar as the visual editor and can use the citoid service and other modern tools. Go to Special:Preferences#mw-prefsection-betafeatures to enable the ⧼Visualeditor-preference-newwikitexteditor-label⧽.
• A new visual diff tool is available in VisualEditor's visual mode. You can toggle between wikitext and visual diffs. More features will be added to this later. In the future, this tool may be integrated into other MediaWiki components. [4]
• The team have added multi-column support for lists of footnotes. The <references /> block can automatically display long lists of references in columns on wide screens. This makes footnotes easier to read. You can request multi-column support for your wiki. [5]
• You can now use your web browser's function to switch typing direction in the new wikitext mode. This is particularly helpful for RTL language users like Urdu or Hebrew who have to write JavaScript or CSS. You can use Command+Shift+X or Control+Shift+X to trigger this. [6]
• The way to switch between the visual editing mode and the wikitext editing mode is now consistent. There is a drop-down menu that shows the two options. This is now the same in desktop and mobile web editing, and inside things that embed editing, such as Flow. [7]
• The Categories item has been moved to the top of the Page options menu (from clicking on the "hamburger" icon) for quicker access. [8] There is also now a "Templates used on this page" feature there. [9]
• You can now create <chem> tags (sometimes used as <ce>) for chemical formulas inside the visual editor. [10]
• Tables can be set as collapsed or un-collapsed. [11]
• The Special character menu now includes characters for Canadian Aboriginal Syllabics and angle quotation marks (‹› and ⟨⟩) . The team thanks the volunteer developer, Tpt. [12]
• A bug caused some section edit conflicts to blank the rest of the page. This has been fixed. The team are sorry for the disruption. [13]
• There is a new keyboard shortcut for citations: Control+Shift+K on a PC, or Command+Shift+K on a Mac. It is based on the keyboard shortcut for making links, which is Control+K or Command+K respectively. [14]

Does not seem to support listings like the current text editor does (i.e. the buttons to add the different types of listing). I tried it for a bit but fiund it slower to load and visually harder to use than the old one so I quickly switched back. PsamatheM (talk) 18:24, 12 May 2017 (UTC)[reply]

Future changes

• The team is working on a syntax highlighting tool. It will highlight matching pairs of <ref> tags and other types of wikitext syntax. You will be able to turn it on and off. It will first become available in VisualEditor's built-in wikitext mode, maybe late in 2017. [15]
• The kind of button used to Show preview, Show changes, and finish an edit will change in all WMF-supported wikitext editors. The new buttons will use OOjs UI. The buttons will be larger, brighter, and easier to read. The labels will remain the same. You can test the new button by editing a page and adding &ooui=1 to the end of the URL, like this: https://www.mediawiki.org/wiki/Project:Sandbox?action=edit&ooui=1 The old appearance will no longer be possible, even with local CSS changes. [16]
• The outdated 2006 wikitext editor will be removed later this year. It is used by approximately 0.03% of active editors. See a list of editing tools on mediawiki.org if you are uncertain which one you use. [17]
• If you aren't reading this in your preferred language, then please help us with translations! Subscribe to the Translators mailing list or contact us directly, so that we can notify you when the next issue is ready. Thank you!

—Elitre (WMF)

18:05, 12 May 2017 (UTC)

Does not seem to support listings like the current text editor does (i.e. the buttons to add the different types of listing). I tried it for a bit but fiund it slower to load and visually harder to use than the old one so I quickly switched back. Font too large (and fixed width) meaning you get less on the screen (not an issue for large screen users but some of us use small laptops and I can't see many people on their travels using a 42" monitor, more likely an e.g. 11" screen. If it's going to default to such large text font size (and fixed width font) then it needs options to change the view (i.e. shrink the text and change the font). PsamatheM (talk) 18:26, 12 May 2017 (UTC)[reply]

Swept in from the pub

Birgit Müller (WMDE) 14:39, 16 May 2017 (UTC)[reply]

Swept in from the pub

Just tried the mobile site on my iPhone 5 and the banner photos are looking "terrible" (being polite). Nothing wrong with the banners (I tested a couple where I knew they were of more than adequate resolution and worked fine on laptop). They are coming out truncated (right side and some of left but not centred) and almost blurred (but not zoomed to cause blurring. I've no idea how to look into what might be the cause (they do look bad!). I'm unable to upload files to WV and seems a bit bad to upload a example of something for sort term to commons, but happy to take some screenshort and post somehwere if that helps anybody diagnose and fix. PsamatheM (talk) 22:06, 16 May 2017 (UTC)[reply]

If you decide to do that, then my favorite set of instructions for this may be useful to you: w:en:Wikipedia:Screenshots of Wikipedia. WhatamIdoing (talk) 15:30, 17 May 2017 (UTC)[reply]

Yes, a screenshot would be helpful :-) Thanks for the feedback! Syced (talk) 07:24, 18 May 2017 (UTC)[reply]

3 examples. Wroxham and Hoveton looks bad and Norfolk Broads and Wymondham probably illustrate the cause also don't look great.These all appear fine in desktop browser (Safari on Mac).

Screenshots from Safari on iPhone 5S iOS 10. PsamatheM (talk) 09:11, 19 May 2017 (UTC)[reply]

n.b. please, if anybody can layout these screenshots on the page better please do edit (and I'll learn how to d it in future. I tried left, centre and right but too big gap. PsamatheM (talk) 09:11, 19 May 2017 (UTC)[reply]

The pagebanner template/extension could show the normal image on mobile websites delivered by Wikidata instead of the banner. -- DerFussi 11:51, 19 May 2017 (UTC)[reply]

I am just guessing here, but I think there is some kind of "most interesting" algorithm that runs against the banners to generate the mobile banners. You can see it's trying to pick out a focal point within the image, and not simply centering it. Maybe there could be an override option on banner templates? FWIW, the mobile crop of the Boston banner works well, (and probably many others) so I wouldn't throw out this functionality altogether. --ButteBag (talk) 13:47, 19 May 2017 (UTC)[reply]

One thought I've had since is that on a desktop/laptop (larger screen) the banner adds a lot and includes the section links/menu. On the small phone screen it contains nothing but takes up a lot of screen space and does not look great. My guess (without trying it) is that if the aspect ratio were maintained and the image shown full width(i.e. a lot smaller vertically) it would take a lot less screen space and generally look a lot better. At the moment it's taking up over 1/3 of the browser screen space! Then with the breadcrumbs you've lost over half the browser screen space in the examples. (OK that reduced/goes as you scroll but not a useful starting point for getting info to the user. PsamatheM (talk) 15:09, 19 May 2017 (UTC)[reply]

Oh just noticed this. There is an "origin" param you can use documented here: Template:Pagebanner. Disagree about keeping the desktop aspect ratio on mobile, but agree the breadcrumbs and page actions could be handled better (made less tall somehow). --ButteBag (talk) 21:01, 19 May 2017 (UTC)[reply]

I've brought this up before. Essentially the problem here is that landscape banners dont look nice on a mobile screen. I think you use a 7:1 ratio but what this means is a banner to fit on a mobile screen will have a tiny height to the point is it tiny. Thus the banners have a fixed minimum height on mobile.

I think the banners being used need to be reconsidered. Either

1. relax the ratio a little. Banners will clip on desktop too (todo: i'll add an example)
2. choose banners which can be clipped using the origin focal point.. For instance a banner for London might show tower bridge on mobile but the entire city scape on desktop.

Jdlrobson (talk) 14:47, 24 May 2017 (UTC)[reply]

Swept in from the pub

Hi everyone,

I’m looking for feedback from people who use the function to create PDFs on the Wikimedia wikis, which feels relevant for the travel guides on Wikivoyage. In short, the main technology we’re using to render them – OCG – is breaking down. The code is old, it’s difficult to maintain, and if we don’t replace it now we might suddenly find ourselves in a situation where we'd have to take it down without having planned to do so.

We have some plans for the future at mw:Reading/Web/PDF Functionality. If you care about the PDF function, please head over there and tell us on the talk page if anything is missing, or if there’s something in there we shouldn’t spend our time and energy on. /Johan (WMF) (talk) 12:24, 18 May 2017 (UTC)[reply]

Use to often render articles using the function when they were displayed as they appear before rendering. Then took them on trips using laptop. When they changed PDF output to two columns, I had to switch to PDFs rendered by my search engine (i.e., Firefox) in order to retain original format for ease of highlighting and to avoid many page-up/down reading actions on-screen. Now encounter loss of only a few pictures...usually the banner, but no text. If we choose a new "converter", suggest it allow users to designate the basic output format. Regards, Hennejohn (talk) 18:20, 18 May 2017 (UTC)[reply]

Left an extensive comment here. --Alexander (talk) 18:57, 18 May 2017 (UTC)[reply]

@Johan (WMF): How is that page different from mw:Reading/Web/PDF Rendering? I left a detailed comment on that talk page some months ago. Powers ^(talk) 23:41, 18 May 2017 (UTC)[reply]

Hopefully slightly clearer. Sorry for the confusion; we should probably post something explaining the relationship between the pages – thanks for asking. You don't need to repost anything that was posted there, it's been noted. /Johan (WMF) (talk) 23:51, 18 May 2017 (UTC)[reply]

Formerly Wikivoyage used few images to make printed articles more compact and download require less bandwidth. With smartphones/tablets and 3G being more common, we have eased on that recommendation. Now it seems we are back to discussing the images (on the linked talk page).

CSS allows different layouts for different media (desktop/tablet/print/...). I think it would be possible to use that feature, and the possibility to choose between style sheets, to indicate what images to include in different situations. We should be able to make better default choices than the PDF rendering engine. This would need some changes in guidelines and probably some new templates, in addition to the MediaWiki/Electron support.

Do we want a mechanism for marking important and less important images? There is already the suggestion to render some images as larger for offline use, where you cannot expand the image. Other variants?

--LPfi (talk) 07:06, 19 May 2017 (UTC)[reply]

Yes, there should be a mechanism for marking important images = images needed in the print version. But the problem is that images are included directly without any templates, so we can't define their CSS classes or anything. Placing each image inside a template would be an awkward solution. Therefore, I thought of labeling a few 'important' images with a template, where CSS classes can be eventually defined, and leaving all other images as they are. That would be easiest. --Alexander (talk) 08:39, 19 May 2017 (UTC)[reply]

Swept in from the pub

Translations of this message are available on Meta-Wiki.

On behalf of the Wikimedia Foundation Elections Committee, we are pleased to announce that self-nominations are being accepted for the 2017 Wikimedia Foundation Funds Dissemination Committee and Funds Dissemination Committee Ombudsperson elections. Please read the letter from the Wikimedia Foundation calling for candidates at on the 2017 Wikimedia Foundation elections portal.

Funds Dissemination Committee
The Funds Dissemination Committee (FDC) makes recommendations about how to allocate Wikimedia movement funds to eligible entities. There are five positions being filled. More information about this role can be found at the FDC elections page.

Funds Dissemination Committee Ombudsperson
The Funds Dissemination Committee Ombudsperson receives complaints and feedback about the FDC process, investigates complaints at the request of the Board of Trustees, and summarizes the investigations and feedback for the Board of Trustees on an annual basis. One position is being filled. More information about this role can be found at the FDC Ombudsperson elections page.

The candidacy submission phase will last until May 28 (23:59 UTC).

We will also be accepting questions to ask the candidates until May 28. You can submit your questions on Meta-Wiki. Once the questions submission period has ended on May 28, the Elections Committee will then collate the questions for the candidates to respond to.

The goal of this process is to fill the five community-selected seats on the Wikimedia Foundation Funds Dissemination Committee and the community-selected ombudsperson. The election results will be used by the Board itself to make the appointments.

The full schedule for the FDC elections is as follows. All dates are inclusive, that is, from the beginning of the first day (UTC) to the end of the last.

• May 15 (00:00 UTC) – May 28 (23:59 UTC) – Nominations
• May 15 – May 28 – Candidates questions submission period
• May 29 – June 2 – Candidates answer questions
• June 3 – June 11 – Voting period
• June 12–14 – Vote checking
• June 15 – Goal date for announcing election results

More information on this year's elections can be found at the 2017 Wikimedia Foundation elections portal.

Please feel free to post a note about the election on your project's village pump. Any questions related to the election can be posted on the talk page on Meta-Wiki, or sent to the election committee's mailing list, board-electionswikimedia.org.

On behalf of the Election Committee,
Katie Chan, Chair, Wikimedia Foundation Elections Committee
Joe Sutherland, Community Advocate, Wikimedia Foundation

Posted by the MediaWiki message delivery • Translate • Get help

21:05, 23 May 2017 (UTC)

Swept in from the pub

I'm wondering if we should reconsider our stance on hosting graphics on Commons? We're losing stuff for no good reason, for instance c:Commons:Deletion requests/File:Kimberley map.png just removed the static map from Kimberley (Western Australia) on basically one person's say-so with little or no discussion. As this is happening on another wiki, we usually have no warning until an image (or even a static map) vanishes at the hands of User:CommonsDelinker - and by then it's too late. K7L (talk) 20:43, 23 May 2017 (UTC

@K7L: Definitely. Otherwise, we are hosting maps all over (e.g. Wikivoyage is in several languages). The solution here is simply to keep an eye on Commons. Would you like me to request it to be undeleted? —Justin (koavf)❤T☮C☺M☯ 21:33, 23 May 2017 (UTC)[reply]

I suppose WT was quite sloppy about licences, like most people, while Commons is very strict. In this case the source of the base map seems not to have been explicit. If we know it, that information should be added, in other case we do not really know whether the map is free. In the worst case most old maps have to be redrawn with known base maps. Sad, but possibly hard to avoid. It may of course be that the source is evident or the base map de minimis (too little copyrightable material copied for the result to be a derived work), but not seeing the map or the description page that is hard to know. --LPfi (talk) 15:27, 24 May 2017 (UTC)[reply]

Commons can be a little overly aggressive / straight on copyright sometimes. Yes we need to keep an eye on things there. But the benefits are generally greater than the drawbacks.Travel Doc James (talk · contribs · email) 22:47, 24 May 2017 (UTC)[reply]

Swept in from the pub

The idea of better tying together the branding of the various sister sites has been bantered about for a number of years. The idea is basically to also brand Wikivoyage as "Wikipedia Voyage". And to also use the url en.wikivoyage.wikipedia.org

Potential benefits include:

1. increasing the page rank of the sister sites and thus potentially readership
2. making clear to our readers what is and is not a Wikimedia movement sister site

My personal position is that:

1. any such change should only be carried out with the consensus of the sister site in question
2. the changes should be done gradually so that actual benefits can be determined

Would this be something the WV community would be interested in considering? Travel Doc James (talk · contribs · email) 23:02, 24 May 2017 (UTC)[reply]

@Doc James: Can you put a finer point on this? E.g. would anyone ever link to en.voy.p.org? Would there be promotional material calling this "Wikipedia Voyage"? —Justin (koavf)❤T☮C☺M☯ 04:53, 25 May 2017 (UTC)[reply]

Wikipedia Voyage would still be short-enable to WikiVoyage or WV. Would this lead to an increase in readership as WV's association with Wikipedia is clearer? I think it might. Is this worth a try? Maybe. Could it be used in promotional material, sure. Travel Doc James (talk · contribs · email) 05:37, 25 May 2017 (UTC)[reply]

@Doc James: Wait--are you suggesting actually changing the name of the site from "Wikivoyage" to "Wikipedia Voyage"?! —Justin (koavf)❤T☮C☺M☯ 05:48, 25 May 2017 (UTC)[reply]

I like seeing a bold initiative around this, but A) are we sure the benefits would be realized? and B) Would this change our current governance structure in any way? Andrewssi2 (talk) 06:20, 25 May 2017 (UTC)[reply]

A) No we are not sure. One would have to try to see. We could set it up such that one could switch back if they were not realized. B) No this would not change current governance in any way. Projects shall always be self governing. Travel Doc James (talk · contribs · email) 14:01, 25 May 2017 (UTC)[reply]

I think we also need to think about what does "Wikipedia Voyage" mean to someone who hears it... Are they going to expect an encyclopedia of travel or a travel guide? It would be great to leverage Wikipedia's name recognition but the two sites have some significant differences and I wonder if it will create an expectations gap with what people expect when they hear "Wikipedia" and what they see with a travel guide. -Shaundd (talk) 06:39, 25 May 2017 (UTC)[reply]

None of the other sister sites have "Wikipedia" in their names. I oppose this idea per Shaundd's points. Ikan Kekek (talk) 07:50, 25 May 2017 (UTC)[reply]

Agree with Shaundd and Ikan Kekek and oppose. I do really hope WMF get rid of any ideas about changing how things work for marketing reasons, or confusing facts to make them more attractive. We are not a subproject of the encyclopaedia. If the projects are to be consolidated, it is Wikimedia, not Wikipedia, that is the common factor. To me this sounds as one more indication that WMF has forgot what the movement is about and started to adopt marketing practices from the business world (I stopped contributing to the fund raising when they insisted on calling "wolf" despite criticism from sv-wp).

Wikivoyage needs more users, and I suppose many other projects do, but at least those other projects should be well-known by active wikipedians by now. An awkward url like the one suggested is hardly the way to attract people.

--LPfi (talk) 09:18, 25 May 2017 (UTC)[reply]

I also support the general initiative but strongly oppose this particular name. It's convoluted, confusing and misleading as we're not an encyclopedia. In many ways, we're the opposite. Original research is often better than sourced material here.

But I have sometimes thought that "voyage" is a somewhat obscure word in the English language and in particular doesn't flow with the word "wiki". There may have been better synonyms of travel to use, like Wikitrips, Wikijourney, Wikiwander, Wikitourist, Wikinomad or even Wikigo since to travel you have to go somewhere. They sound better to my ear but everyone is different and Wikivoyage might sound good to others. Gizza ^(roam) 10:25, 25 May 2017 (UTC)[reply]

I could see it causing confusion amongst some. Casual users might look up e.g. Paris on Wikipedia or Wikipedia Voyage or does it matter or why are they different ... "I've checked one why check the other" ... "Wikipedia does not tell me about good places to say for that place". I see the sites as having ver different purpose and the different branding helps distinguish that different purpose. I think more cross links Wikipedia to WikiVoyage for e.g. matching subject pages (in the Wikipedia "See Also" at the bottom) would help, but merging the branding - oppose. PsamatheM (talk) 10:36, 25 May 2017 (UTC)[reply]

Yes. I think many wikipedians who come to Wikimedia Commons are very confused, regarding it an en-wp subsidiary, and quoting (English) Wikipedia policies to defend their point of view. Few regulars would have such expectations here, but I think the example shows that clear separation has its merits. --LPfi (talk) 13:14, 25 May 2017 (UTC)[reply]

The question is does Wikipedia only mean an encyclopedia? Or can it be applied in a broader manner to the entire movement? Should all the sister sites contain "Wikipedia" in the name? Should the chapters be "Wikipedia Canada", should it be the "Wikipedia Foundation"? Basically should "Wikimedia" simply be replaced by "Wikipedia".

I agree there are potential pluses and minuses and we do not know the exact result that will occur if tried. Wikimedia however does result in a lot of confusion and I frequently heard "you mean Wikipedia Canada right" when I called it "Wikimedia Canada".

Another benefit is that while we do not own the term "wiki", we do own the term "Wikipedia". That is likely a lessor benefit though. Travel Doc James (talk · contribs · email) 13:55, 25 May 2017 (UTC)[reply]

Oppose this specific idea, but I really like your moxie! To most internet users the answer to the question "does Wikipedia only mean an encyclopedia?" is definitely yes. I would actually be fine with all urls being brought under the wikimedia umbrella. So like, en.wikipedia.wikimedia.org, en.wikivoyage.wikimedia.org, etc. Although, it's a bit overlong now that I type it out... Anyway, good luck! --ButteBag (talk) 14:48, 25 May 2017 (UTC)[reply]

Adding another voice to the oppose chorus. -- AndreCarrotflower (talk) 16:07, 25 May 2017 (UTC)[reply]

Thanks all for your perspectives. I will bring this view forward and oppose such a change on your behalf. Travel Doc James (talk · contribs · email) 22:29, 25 May 2017 (UTC)[reply]

User:Doc James : Thanks for your bold initiative. I was really hoping this would be the genesis of a new discussion rather than just simply shot down. I'm personally quite in favor of looking for radical ways into improving the site and would like to see more discussion around it. Andrewssi2 (talk) 03:39, 26 May 2017 (UTC)[reply]

I agree that your boldness is to be praised, and I'm sorry I have no alternative suggestions at the moment, except that I agree with ButteBag that explicitly adding "Wikimedia" to the URL is totally fine. Ikan Kekek (talk) 03:59, 26 May 2017 (UTC)[reply]

Always happy to consider other suggestions. Wikipedia is our best known brand and the though was to simply try to leverage that to the benefit of the sister sites. We could try to improve awareness around Wikimedia and it might be similar enough to succeed. Travel Doc James (talk · contribs · email) 15:45, 26 May 2017 (UTC)[reply]

Thinking aloud (i.e. not thought through/off-top-of-head) what about a "Part of WikiMedia Group" small graphic that is added to the existing logos. Maybe based on the Wikipedia "W" (to keep it small and already well recognised), some element that can be added to without swamping each of the project icons indicating it's part of the "group" (a bit like companies do except they tend to use text as in "a member of the xxx group of companies". So everybody gets to keep their icons, individuality, separation but at the same time the icon/logo shows it is a member of the WikiMedia Foundation. BUT, the trouble is that the WikiMedia icon/logo is not well recognised amongst the users of most of the sites (even aid Wikipedia users are probably unaware of the way the organisation is structured or even that it is even structured and has other projects). The idea behind the original proposal to leverage off the Wikipedia widespread awareness is a good idea but I don't think general users are aware of WikiMedia so it would have to be Wikipedia based PsamatheM (talk) 16:29, 26 May 2017 (UTC)[reply]

I agree with the idea of having a "Part of Wikimedia", or something similar, displayed at least on the front page (on every page would be fine with me, too, if it's visible though not cumbersome). Ikan Kekek (talk) 19:33, 26 May 2017 (UTC)[reply]

What, something like https://en.wikivoyage.org/static/images/wikimedia-button.png at the bottom of every page? K7L (talk) 20:30, 26 May 2017 (UTC)[reply]

Yes, and preferably bigger than that image. Ikan Kekek (talk) 22:42, 26 May 2017 (UTC)[reply]

I would agree. My only question is about how widespread "WikiMedia" is understood (or even known about) in the general public/users. I wonder if it's an association with Wikipedia that would help most rather than WikiMedia. And in some regards (maybe I've misunderstood) WikiTravel also uses WikiMedia software so would the WikiMedia association distinguish enough (they and many others start with "Wiki" and many would think beyond that). Original proposal was to associate closer with Wikipedia which is where I think most of the benefit would be (mainly because most internet users are aware of Wikipedia). PsamatheM (talk) 08:42, 27 May 2017 (UTC)[reply]

@PsamatheM: Wikimedia is the non-profit that operates these sites; MediaWiki is the software. The WMF never had any association with Wikitravel but Wikitravel is built on MediaWiki. —Justin (koavf)❤T☮C☺M☯ 09:08, 27 May 2017 (UTC)[reply]

So if I had understood it wrong (and given I contribute here sometimes, made a couple of corrections to WikiData and Wikipedia) what chance do others who e.g. just use Wikipedia sometimes have and thus would they appreciate the difference between WikiMedia and MediaWiki and thus would WV get any benefit from association from MediaWiki rather than Wikipedia? PsamatheM (talk) 09:20, 27 May 2017 (UTC)[reply]

@PsamatheM: 0%. —Justin (koavf)❤T☮C☺M☯ 09:23, 27 May 2017 (UTC)[reply]

@ Koavf: Afraid I don't understand that (I must be having a "senior moment"?) PsamatheM (talk) 09:25, 27 May 2017 (UTC)[reply]

@PsamatheM: No problem. Your question was: How much will rebranding the site help, since these names can be so confusing. My answer was: I do not think it will help. —Justin (koavf)❤T☮C☺M☯ 19:15, 27 May 2017 (UTC)[reply]

Here's how I think it could work: If it could be agreed on, it would be good for every Wikimedia site to have that same notice on every page. Then, over time, it will become more highly recognizable as the Wikimedia brand. I think it's worth trying and arguably a per se good thing to do, regardless. Ikan Kekek (talk) 20:47, 27 May 2017 (UTC)[reply]

I would agree. Whilst I think Wikipedia is the publicly recognised "brand" as you say, if all Wikipedia pages included the same notice on every page then the "brand" get broadened. For me the crucial site is Wikipedia as without that site doing it it would be much less effective. But a move I'd be in favour of but how does such an initiative/change get agreed on Wikipedia and how does it get implemented ? PsamatheM (talk) 22:07, 27 May 2017 (UTC)[reply]

Yes, we agree: Wikipedia's participation is crucial. I don't know how we could best propose this to all Wikimedia sites. Ikan Kekek (talk) 06:40, 28 May 2017 (UTC)[reply]

I'm more incline to change wikipedia.org into wikipedia.wikimedia.org than to change wikivoyage.org into wikivoyage.wikipedia.org. We are a part of wikimedia not a part of wikipedia. --Andyrom75 (talk) 10:27, 29 May 2017 (UTC)[reply]

I could get on board making the Wikimedia "family" brands more prominent on each of its wikis, including WV but I'm not a fan of lengthening the url at all, or making our name longer. The world's leading web/app brands all have short, sharp, easy-to-remember names and urls: Google, Facebook, YouTube, Amazon, Snapchat, Instagram, Whatsapp, Twitter, Netflix, Reddit, Tumblr, eBay, Skype, Tinder. Nearly all of them are 2-3 syllables, 10 letters max. Wikipedia has 5 syllables but still flows well while Wikivoyage feels long with 4. In the travel space there's Airbnb, booking.com, hotels.com, Kayak, Uber, Agoda, Trivago, with only TripAdvisor being the big exception (but still much easier to say than either Wikipedia Wikivoyage or Wikimedia Wikivoyage). We shouldn't swim against the tide. Gizza ^(roam) 11:45, 29 May 2017 (UTC)[reply]

Have I been overlooking the two logos bottom right of each page (on WV as well as Wikipedia) "A WikiMedia Project" and "Powered by WikiMedia" or are they new ? (I can stare at things and not see them (as witnessed by supermarket assistants ...). Nice if they were more prominent (e.g. same size at the top of the page maybe (e.g. under the project logo) but I'd never noticed the branding there. PsamatheM (talk) 23:00, 30 May 2017 (UTC)[reply]

@PsamatheM: Yes, you have--those buttons have been there for a decade. —Justin (koavf)❤T☮C☺M☯ 23:09, 30 May 2017 (UTC)[reply]

Swept in from the pub

We have a bunch of outstanding propsals for article mergers. In principle, the idea of getting consensus for article mergers makes sense, but where only one or two people have commented over a period of months, it is clear that there isn't enough interest to settle the discussion, and we end up with "merge" tags cluttering these articles indefinitely.

I have gone through most of the articles (listed here Wikivoyage:Requests for comment). I have plunged forward and completed some mergers where the article clearly did not meet wia or where there was negligible information to merge into another article.

I am proposing to define "consensus" on other articles as follows: after a further ten-day comment period, I will execute proposed mergers where there is no "oppose" vote. Where there is an "oppose" vote and no large number of "support" votes (e.g. Talk:Petersham), I will close the discussion as "no consensus to merge" and remove the "merge" tag from the article. Please add your comments to any of the discussions. Merger discussions can be re-opened at any time, and merged articles can be split out at any time if someone wants to put the work into creating an article with information (and the subject meets wia).

This should clean up most of the outstanding merger proposals, aside from a few where I lack the knowledge or interest to join the discussion (e.g. Filipino phrasebooks). Ground Zero (talk) 15:29, 31 May 2017 (UTC)[reply]

I agree, it's quite frustrating for the person suggesting the merger as well. There was a discussion on this a while ago, after I (wrongly in hindsight) merged two articles without putting it up for discussion, and I think the conclusion was that it was okay to go ahead with the merger if there's no opposition for a while after the merger has been proposed on the talk page. Drat70 (talk) 01:19, 5 June 2017 (UTC)[reply]

I would suggest that if you know a given area quite well, going ahead and merging within a week or perhaps even a day or less if you know there couldn't be a reason for controversy is fine, but if you don't personally know an area and it's not blindingly obvious that a given place couldn't have a good article, you might want to delay merging if no-one comments, or at least delay for a week or so. Ikan Kekek (talk) 01:30, 5 June 2017 (UTC)[reply]

With the help of some other editors, many of the mergers have been completed, and other merger discussions have been closed. I don't know what to do about some cases where editors do a "drive-by" tagging, i.e., they proper a merger or article move, there is support for it, but then they leave it and move on to other stuff. In some cases, if the merger is straightforward, I'll do it, but where the merger is more complex or requires local knowledge, I'm inclined to remove the merger tag if the proposer can be bothered to compete the merger. This sort of tagging strikes me as a bit of "someone else should do this, but I'm not willing to." These sort of tags are not helpful, and clutter the articles without adding value. Ground Zero (talk) 14:12, 15 June 2017 (UTC)[reply]

Swept in from the pub

I was thinking about this comment, and thinking how common that kind of problem is for new people. How many of you have tried mw:Flow? I've been using it more this last year. It took me a little while to get used to a few of its quirks, but I'm pretty satisfied overall.^[1]

It works pretty well for basic discussions. I think it is better for talking to newcomers, and highly effective at getting responses from people. It has an explicit reply button (two of them, actually), which is really helpful to new contributors, and replies appear in Echo (unless you disable that in your prefs) as well as your watchlist (very handy for reaching the person who doesn't use a watchlist or doesn't visit your wiki very often). You can even watch a single thread, rather than a whole page. I was thinking that it might be appropriate to try it out at the Tourist Office sometime, since that page brings in a higher proportion of non-editors.

If you haven't used Flow, then perhaps this is a good way to start: Go to mw:Flow/Sandbox and start a new discussion. Feel free to ping me or your favorite contributors. Be sure to click the pencil icon in the lower right corner and try switching between visual mode (handy for newbies) and wikitext (familiar to us).

[1] Please do not tell the Flow devs that I'm satisfied. As far as they are concerned, I will only be satisfied when they add all of my favorite feature requests. 😉

WhatamIdoing (talk) 16:59, 31 May 2017 (UTC)[reply]

I have understood it has some pretty serious shortcomings, e.g. regarding history. We have not enabled it on sv-wp, so I have very limited experience, but I hope it will not be introduced without a thorough understanding of the problems. --LPfi (talk) 09:39, 1 June 2017 (UTC)[reply]

I think that a lack of integration with Special:Search is the biggest practical problem. (Each thread has a history page, and changes appear in your watchlist.) But search is perhaps less critical to the Tourist Office. (Also, I hope that fixing search will be high on the list of improvements that are scheduled to begin next month). I really think that you need to use it a few times to know how it works. WhatamIdoing (talk) 14:25, 2 June 2017 (UTC)[reply]

Swept in from the pub

There is a longstanding bug on phabricator regarding the opacity of the table of contents dropdown. Is this a problem shared by other community members? Please comment on the task (using your Phabricator account). If I don't see any objections I am going to remove the opacity from the menus. Thanks in advance! Jdlrobson (talk) 18:45, 5 June 2017 (UTC)[reply]

Do you like this idea? Wikivoyage:Travellers'_pub#Alt_pagebanner_layout.3F Would be easy to roll the opacity fix into that. --ButteBag (talk) 22:18, 5 June 2017 (UTC)[reply]

Swept in from the pub

Hi!

The more involved we are, the more ideas or wishes concerning the future of Wikipedia we have. We want to change some things, but other things we prefer not to be changed at all, and we can explain why for each of those things. At some point, we don’t think only about the recent changes or personal lists of to-dos, but also about, for example, groups of users, the software, institutional partners, money!, etc. When we discuss with other Wikimedians, we want them to have at least similar priorities that we have. Otherwise, we feel we wasted our time and efforts.

We need to find something that could be predictable, clear and certain to everybody. A uniting idea that would be more nearby and close to the every day’s reality than the Vision (every human can freely share in the sum of all knowledge).

But people contribute to Wikimedia in so many ways. The thing that should unite us should also fit various needs of editors and affiliates from many countries. What’s more, we can’t ignore other groups of people who care about or depend on us, like regular donors or “power readers” (people who read our content a lot and often).

That’s why we’re running the movement strategy discussions. Between 2019 and 2034, the main idea that results from these discussions, considered by Wikimedians as the most important one, will influence big and small decisions, e.g. in grant programs, or software development. For example: are we more educational, or more IT-like?

We want to take into account everybody’s voice. Really: each community is important. We don’t want you to be or even feel excluded.

Please, if you are interested in the Wikimedia strategy, follow these steps:

• Have a look at this page. There are drafts of 5 potential candidates for the strategic priority. You can comment on the talk pages.
• The last day for the discussion is June, 12. Later, we’ll read all your comments, and shortly after that, there’ll be another round of discussions (see the timeline). I will give you more details before that happens.
• If you have any questions, ask me. If you ask me here, mention me please.

Friendly disclaimer: this message wasn't written by a bot, a bureaucrat or a person who doesn't care about your project. I’m a Polish Wikipedian, and I hope my words are straightforward enough. SGrabarczuk (WMF) (talk) 11:02, 9 June 2017 (UTC)[reply]

Dear Wikivoyage community members. The Wikimania 2017 conference will take place in August 2017. I am going to take part and I hope to meet some other community members. To prepare for the conference properly I would like to know more about all your wishes, problems and ideas related to Wikivoyage. I have created a small site on the meta-wiki where you can drop all your thoughts, wishes and concerns. Feel free to create sub sites if needed. It would be great to have a meeting at the conference venue or anywhere in town. -- DerFussi (talk) -- MediaWiki message delivery (talk) 20:04, 23 April 2017 (UTC)[reply]

Swept in from the pub

Yes we have a short article on Wildfires, but what about how to handle fires in other travel related situations?

Is it Captain Obvious to tell people to ensure they know evacuation procedures in a hotel and so on?

Related would be how to check that the travel industry operators have done their bit as well?.

Both these questions are prompted indirectly by claims in the UK media, that Premier Inns (a major motel operator in the UK), was looking into the cladding it used on it's locations following the major incident at West London tower block last week.

I am not sure consumer safety/protection as it relates to travel is something Wikivoyage does, but perhaps it should be borne in mind? ShakespeareFan00 (talk) 15:53, 23 June 2017 (UTC)[reply]

My initial reaction is that this is unnecessary. Most people spend a lot of their lives in or near buildings, and have been doing fire drills since primary school.

Wildfires and campfires are certainly travel related. Fires on a cruise ship would also count. But a fire in a hotel is no different than any other building, and I think we can reasonably expect almost everyone to already know what to do. --Bigpeteb (talk) 18:26, 23 June 2017 (UTC)[reply]

We do run into third-world destinations with lax regulation in which there are no consequences for builders if a structure is a fire trap and no consequences for proprietors if they've blocked the emergency exits to prevent patrons sneaking out without paying. At least there are no consequences until tragedy strikes – and then it's too late. How do you advise the voyager spot these issues? K7L (talk) 13:17, 24 June 2017 (UTC)[reply]

Yes. I think locked or blocked emergency exits can be found even in EU countries, as can safety instructions copied from some other building or not updated when there were changes. And I think fire drills are mostly to train staff and check procedures are working, not much about how to act in an emergency in an unfamiliar environment where you do not (or should not) trust procedures.

Also tent fabric, gas installations and camping stoves are things not all are sufficiently acquainted with. Perhaps a short note about the importance of following safety directions is enough, perhaps some more advice and reasoning is needed.

These things may be best handled in Stay safe sections and the Stay safe article. Perhaps just checking them and adding any important missing stuff would be enough.

--LPfi (talk) 15:29, 24 June 2017 (UTC)[reply]

I am also assuming fire safety signs and building evacuation routes are now (or should now) all be ISO ones, so most travellers would be familiar with them? (On the other hand would some local variations need to be noted in relevant region articles?). All the ones I've seen in the UK were standardised since at least the mid 1980's (albiet BS not ISO until a few years ago.).

ShakespeareFan00 (talk) 15:59, 24 June 2017 (UTC)[reply]

I spend about 3 to 4 months of the year in different hotels. Have had to evacuate a few times over the years. I now make a point of checking the fire exit route (walk down stairs at least once. It is surprising how many stir wells from room floors come out in strange meeting rooms or in the kitchen or back loading bay. Can be a challenge in calm good visibility conditions to find the way out the building, best to know before you need it in a dark smokey building. Have also twice been stuck behind locked doors and have had to call hotel reception on my mobile to let me out or back into the main building! --Traveler100 (talk) 16:33, 24 June 2017 (UTC)[reply]

Swept in from the pub

Okay, I couldn't find Magic, as a topic, and didn't want to create a redirect to Fringe Phenomena as what most people call magic is of the distinctly non-supernatural performance kind.

Wikivoyage doesn't have an article on Performance Magic so I am considering what to put in a stub (currently here)

The main focus of a travel topic, should be venues that have regular live "magic", prop museums, or sites connected with famous illusionists.

I'm not sure but there may be some Stay Safe advice that could be added as well, although most of it is of the "don't get ripped off" design, already covered in Commons Scams, ( Like the "Find the lady" confidence trick in particular.).

Thoughts? ShakespeareFan00 (talk) 11:42, 24 June 2017 (UTC)[reply]

Seriously getting frustrated by the recent trend of creating two sentence Travel Topics. They serve no use to readers, just gives the impression of a very bitty amateurish web site. Not just a comment about this topic but others too, if you do not have a good amount of information on a subject do not start a stub page on it. --Traveler100 (talk) 12:51, 24 June 2017 (UTC)[reply]

Fair enough. I'll review some of the other articles recently created as well.

ShakespeareFan00 (talk) 13:16, 24 June 2017 (UTC)[reply]

I really couldn't agree more with Traveler100 on his general point. Ikan Kekek (talk) 13:21, 24 June 2017 (UTC)[reply]

Right a few marked for direct deletion, some others at VfD. Thank you for your co-operation so far ShakespeareFan00 (talk) 13:40, 24 June 2017 (UTC)[reply]

I disagree with edits like Special:Diff/3194593/3227197 and Special:Diff/3209556/3227190. If something's up for discussion on VfD, it would be best to let that discussion run its course before removing all inbound internal links to the page in question.

We do normally wait until a page is usable before tagging {{wikivoyage}} boxes onto the corresponding Wikipedia article "external links" section, but no corresponding restriction applies to internal links to articles from within Wikivoyage. K7L (talk) 14:17, 24 June 2017 (UTC)[reply]

But do not get me wrong, a number of new contributions I do support. For example I actually think Inland waterways in the United Kingdom would make a great article, I though about it myself but would take a little time to write. --Traveler100 (talk) 14:22, 24 June 2017 (UTC)[reply]

We don't have a Draft: namespace at Wikivoyage, hence why Performance Magic was in userspace, but certain comments here have suggested even a user-space stub isn't appropriate. ShakespeareFan00 (talk) 14:26, 24 June 2017 (UTC)[reply]

Did not intend to give that impression. Developing in user space is fine, just stay away from adding tags that put it into clean-up lists. And I was talking about travel topics with just a couple of lines not ones with a reasonable number of entries or locations with just a couple of listings. --Traveler100 (talk) 14:36, 24 June 2017 (UTC)[reply]

(Personal opinion:) For me the priority is getting the many existing destinations and articles up to a better standard. As a general comment on the Votes for Deletion, I'd prefer time spent on adding content to the destinations rather than spending time trawling through emptier places or creating stub pages for others to write. I suspect we all have great ideas for new pages that would enhance the site, but we don't have time to write them and creating "stubs" for others to do the hard work on ... I find adding content to the vast number rather "empty" destinations quite a hard and boring slog but it needs doing. I think better to write and create one new page with adequate content to stand alone than throw many "ideas" out there in the form of "empty" pages. I feel content for many existing destinations really needs to get done to improve the site. PsamatheM (talk) 16:06, 24 June 2017 (UTC)[reply]

Swept in from the pub

Hi!

I'm a Polish Wikipedian currently working for WMF. My task is to ensure that various online communities are aware of the movement-wide strategy discussion, and to facilitate and summarize your talk. Now, I’d like to invite you to Cycle 3 of the discussion.

Between March and May, members of many communities shared their opinions on what they want the Wikimedia movement to build or achieve. (The report written after Cycle 1 is here, and a similar report after Cycle 2 will be available soon.) At the same time, designated people did a research outside of our movement. They:

• talked with more than 150 experts and partners from technology, knowledge, education, media, entrepreneurs, and other sectors,
• researched potential readers and experts in places where Wikimedia projects are not well known or used,
• researched by age group in places where Wikimedia projects are well known and used.

Now, the research conclusions are published, and Cycle 3 has begun. Our task is to discuss the identified challenges and think how we want to change or align to changes happening around us. Each week, a new challenge will be posted. The discussions will take place until the end of July. The first challenge is: How do our communities and content stay relevant in a changing world?

All of you are invited! If you want to ask a question, ping me please. You might also take a look at our the FAQ (recently changed and updated).

Thanks! SGrabarczuk (WMF) (talk) 14:53, 5 July 2017 (UTC)[reply]

Should we introduce a "flag" - similar to existing flags like "mobile edit" or "smileys" - for edits where an URL is replaced which has not been marked as a dead link? That way stuff like this would be more immediately obvious, without having to look through all edits first. Hobbitschuster (talk) 20:34, 21 April 2017 (UTC)[reply]

It's a good idea. You can create a new filter here: Special:AbuseFilter/new Powers ^(talk) 20:39, 2 May 2017 (UTC)[reply]

don't you have to be an administrator to do that?Hobbitschuster (talk) 19:22, 11 June 2017 (UTC)[reply]

Yes, you need to be an admin. As far as I understand it you want to detect if a URL has been changed and Tag it as such? --Andrewssi2 (talk) 23:31, 11 June 2017 (UTC)[reply]

So can we make that flag? Hobbitschuster (talk) 13:54, 9 July 2017 (UTC)[reply]

Someone has to code the regex to detect it. Powers ^(talk) 00:32, 23 July 2017 (UTC)[reply]

You do not need to be an admin for that part (although having been one on some MediaWiki project may help getting the regex right). --LPfi (talk) 09:46, 23 July 2017 (UTC)[reply]

Hi folks,

The Wikimedia Commons app (a community-maintained Android app that allows users to upload photos to Commons from their phone) was funded via an Individual Engagement Grant last year and has several new features - a list and map of nearby places that need photos (based on Wikidata), category suggestions based on the image title and location (if geotagging is enabled in camera app), prevention of duplicate uploads, and a new tutorial to educate new users on what types of photos should or should not be uploaded. The final report for the completed IEG can be viewed here.

While we are very happy with the progress made, there are many other improvements that we would like to make but were not able to fit into the scope of the previous grant. Thus we are proposing a renewal of the IEG in order to work on these. Highlights of the proposed improvements include:

• Enhancing the "Nearby places that need photos" feature by (1) allowing users to upload their image directly from a location on the list or map, with suggested title and categories based on the associated Wikidata item, and (2) displaying the user's real-time position on the map to allow easier navigation to the location they wish to photograph
• A sleeker, more intuitive, and more interactive user interface - a floating action button for uploads, "Nearby places that need photos" in a tab alongside the user's contributions, and a panel to display Commons account notifications and information about the nearest place that needs photos
• Various technical and quality-of-life improvements, such as two-factor authentication login, multiple uploads, preventing overwrites, and fixing memory leaks and battery drain issues
• Improving user education by displaying Commons account and user talk notifications (e.g. picture nominated for deletion) in the app, adding a gallery of featured images, and adding various notices and explanations in the upload screen

We would very much appreciate feedback and suggestions on the renewal proposal - we are especially excited about the "Nearby places that need photos" feature, as we feel that it can help close the gap of geo-located Wikidata items that lack photos, and provide photos for articles that need them. Please do take a look at our proposal, feel free to ask questions and make new suggestions on the Discussion page, and/or endorse the proposal if you see fit. If you would like to be part of the project, new volunteers and additions to our diverse team are always welcome - please visit our GitHub repository or Google groups forum and say "Hi". :)

Many thanks! Misaochan (talk) 10:28, 17 July 2017 (UTC)[reply]

It seems somebody attempted to do something with this some four years ago (maybe even with some consensus behind it) but now? What are we to do with this? Hobbitschuster (talk) 16:37, 18 July 2017 (UTC)[reply]

Ahh, I remember this. This was a pet project of a no-longer-active user that he started shortly after our move to the WMF, then abandoned somewhere along the way. As I remember it, it was an attempt at a more interactive and personalized user experience. One of those ideas that frequently come along that are good but we don't have the manpower to see through to fruition. I'd say the best course of action would be to move it to his userspace in case he comes back and wants to pick up where he left off, or some other user happens across it. However, I'd wait to do that until you get feedback from other people besides just me. -- AndreCarrotflower (talk) 18:29, 18 July 2017 (UTC)[reply]

Andre's approach makes sense to me. Ground Zero (talk) 11:14, 21 July 2017 (UTC)[reply]