Jump to content

Wikivoyage:Travellers' pub/2017

From Wikivoyage

Most viewed articles

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

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]

New template to replace magic words

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

Wikimania 2017

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 . 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 .
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]

Have a great 2017 - goals and projects for the new year

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)TCM 17:10, 31 December 2016 (UTC)[reply]

Review of initial updates on Wikimedia movement strategy process

Swept in from the pub

Note: Apologies for cross-posting and sending in English. Message is available for translation on Meta-Wiki.

The Wikimedia movement is beginning a movement-wide strategy discussion, a process which will run throughout 2017. For 15 years, Wikimedians have worked together to build the largest free knowledge resource in human history. During this time, we've grown from a small group of editors to a diverse network of editors, developers, affiliates, readers, donors, and partners. Today, we are more than a group of websites. We are a movement rooted in values and a powerful vision: all knowledge for all people. As a movement, we have an opportunity to decide where we go from here.

This movement strategy discussion will focus on the future of our movement: where we want to go together, and what we want to achieve. We hope to design an inclusive process that makes space for everyone: editors, community leaders, affiliates, developers, readers, donors, technology platforms, institutional partners, and people we have yet to reach. There will be multiple ways to participate including on-wiki, in private spaces, and in-person meetings. You are warmly invited to join and make your voice heard.

The immediate goal is to have a strategic direction by Wikimania 2017 to help frame a discussion on how we work together toward that strategic direction.

Regular updates are being sent to the Wikimedia-l mailing list, and posted on Meta-Wiki. Beginning with this message, monthly reviews of these updates will be sent to this page as well. Sign up to receive future announcements and monthly highlights of strategy updates on your user talk page.

Here is a review of the updates that have been sent so far:

More information about the movement strategy is available on the Meta-Wiki 2017 Wikimedia movement strategy portal.

Posted by MediaWiki message delivery on behalf of the Wikimedia Foundation, 20:31, 15 February 2017 (UTC) • Please help translate to your languageGet help

Is there a way to see whom are the top contributors for a specific article + how much they actually contributed?

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:

Top 10 Editors of the Barcelona Article in the Hebrew Wikipedia

Username #1 Minor edits % First edit Latest edit Added (Bytes)
Deror avi572543.92005-02-17, 17:042013-04-02, 07:0015,292 Bytes
ליז'אנסק11218.22007-01-14, 20:132007-03-05, 16:113,077 Bytes
אריאל11218.22006-09-26, 20:402006-10-10, 20:052,048 Bytes
רפאל לירז11002004-03-21, 15:152004-03-21, 16:272,025 Bytes
הידוען האלמוני51202009-02-17, 17:362009-02-17, 18:071,419 Bytes
Poxsi3133.32008-09-02, 21:332011-01-15, 15:471,324 Bytes
Hmbr331002010-07-19, 23:062010-07-24, 23:011,187 Bytes
Tt10011002009-10-05, 19:072013-10-12, 09:261,060 Bytes
Alonr41252007-05-16, 09:522008-01-27, 17:581,039 Bytes
62.90.235.2441002004-03-21, 15:022004-03-21, 15:02753 Bytes

Top 10 Editors of the Barcelona Article in the Hebrew Wikivoyage

Username #1 Minor edits % First edit Latest edit Added (Bytes)
ויקיג'אנקי103002013-02-25, 06:002017-02-14, 23:3058,293 Bytes
אלמוג שווד1002016-01-20, 15:152016-01-20, 15:154,789 Bytes
יעל י11002013-03-31, 08:552013-07-27, 19:043,154 Bytes
בנימין5002013-03-18, 13:162015-01-05, 14:272,066 Bytes
Urilei~hewikivoyage4002013-09-13, 22:122013-09-13, 23:391,019 Bytes
Tzafrir21502013-04-11, 13:422014-03-28, 09:30748 Bytes
DL322243752013-04-09, 14:272014-04-20, 13:06321 Bytes
Guycn2111002016-12-30, 13:452016-12-30, 13:45248 Bytes
24.1.7.51002013-05-12, 15:092013-05-12, 15:091 Bytes
DekelEBot331002014-01-03, 06:532016-02-06, 15:000 Bytes
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]


Mobile mode

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)TCM 20:53, 22 February 2017 (UTC)[reply]

Having a central page where pointers to merger discussions can be put or merger discussions can be had

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]

Overview #2 of updates on Wikimedia movement strategy process

Swept in from the pub

Note: Apologies for cross-posting and sending in English. This message is available for translation on Meta-Wiki.

As we mentioned last month, the Wikimedia movement is beginning a movement-wide strategy discussion, a process which will run throughout 2017. This movement strategy discussion will focus on the future of our movement: where we want to go together, and what we want to achieve.

Regular updates are being sent to the Wikimedia-l mailing list, and posted on Meta-Wiki. Each month, we are sending overviews of these updates to this page as well. Sign up to receive future announcements and monthly highlights of strategy updates on your user talk page.

Here is a overview of the updates that have been sent since our message last month:

More information about the movement strategy is available on the Meta-Wiki 2017 Wikimedia movement strategy portal.

Posted by MediaWiki message delivery on behalf of the Wikimedia Foundation, 19:43, 9 March 2017 (UTC) • Please help translate to your languageGet help

Upcoming changes

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]

We invite you to join the movement strategy conversation (now through April 15)

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]

Commons Picture of the Year

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-elections(at)wikimedia.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 languageGet help

The last week of the 1st cycle of Wikimedia strategy conversation

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.

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]

Proposal: Use new modernised version of Extension:RelatedArticles

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]

Where can I find a list of Wikivoyage articles sorted by the amount of articles that exists for each destination in each wikivoyage edition?

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]

Pedantic analysis tools....

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]

The mobile version seems to suck

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]

Found a mistake in the dynamic maps. How do we fix it?

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]

Beta Feature Two Column Edit Conflict View

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]

Editing News #1—2017

Swept in from the pub

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]

RevisionSlider

Swept in from the pub

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

Mobile Site: Banner Image Looking Rather Terrible

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).
Wroxham and Hoveton
Norfolk Broads
Wymondham

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]

How we render PDFs will change – feedback?

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

21:05, 23 May 2017 (UTC)

Commons and deletion of static maps

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

Branding

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)TCM 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)TCM 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)TCM 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)TCM 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)TCM 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)TCM 23:09, 30 May 2017 (UTC)[reply]

Merging articles

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]

Easier discussions?

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]

Removing opacity from table of contents dropdowns

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]

What do you care for most? What are you concerned with? Take part in the strategy discussion

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]

Wikivoyage at the Wikimania 2017

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]

Fires and other Emergencies

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]

(Performance) Magic

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]

Join the strategy discussion. How do our communities and content stay relevant in a changing world?

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]

New "flag" for certain edits?

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]

Commons Android app - IEG renewal proposal

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]


What is this?

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]

Usage of <center>

So in topics like Early United States History we previously had a line break between <center>United States historical travel topics:</center> and '''[[Indigenous cultures of North America|Indigenous nations]] → [[Early United States history|Pre-Civil War]] → [[American Civil War|Civil War]] → [[Old West]] → [[Industrialization of the United States|Industrialization]] → [[Post-war United States|Post-war]]''' - now the <center> has recently been removed resulting in what looks to me a less aesthetically pleasing layout. Now if it only produces a change in layout on my OS/Browser, why are we changing it? And if produces the same outcome in other OS/Browsers, who thinks that that outcome is better? Hobbitschuster (talk) 19:30, 23 July 2017 (UTC)[reply]

The center tag is a legacy browser feature. I've now switched this out with some CSS but still keeping the same layout. -- WOSlinker (talk) 19:56, 23 July 2017 (UTC)[reply]
This looks to be related to #Lint errors, above. I'm seeing cases where editors are actively removing <center> tags, affecting the formatting of existing text, just to make this rather trivial and pointless warning go away. Is this necessary? K7L (talk) 21:22, 23 July 2017 (UTC)[reply]
Yes. Or, if not strictly "necesary", it is at least highly desirable.
I have no view on whether the tags should be removed or replaced by the modern HTML equivalent, but the center tags themselves should not be be used. Whatamidoing (WMF) (talk) 21:37, 23 July 2017 (UTC)[reply]
And let me add to the chorus: we shouldn't deliberately make pages which are not valid HTML. MediaWiki should be able to strip that out and replace it with a style but until/unless that happens, we should still not be intentionally adding bad HTML. —Justin (koavf)TCM 00:05, 24 July 2017 (UTC)[reply]
Would a center template be useful at all? -- Matroc (talk) 05:02, 24 July 2017 (UTC)[reply]
@Matroc: It could be very useful, certainly but all that MediaWiki code like {{center|...}} will still translate into HTML since this is the Web. The question is if it will be valid or invalid HTML. —Justin (koavf)TCM 04:56, 25 July 2017 (UTC)[reply]

Sorry to ask so "stupidly" but why do those tags have to be removed and or replaced? Hobbitschuster (talk) 11:54, 24 July 2017 (UTC)[reply]

MediaWiki is planning to implement a new parser that will have much stricter requirements about markup than the current parser (which is already stricter than your average web browser). Powers (talk) 13:55, 24 July 2017 (UTC)[reply]
And what's the benefit of that? Hobbitschuster (talk) 16:12, 24 July 2017 (UTC)[reply]
@Hobbitschuster: There are rules to how HTML should be written and when authors ignore those rules, it makes it much harder to predict what behavior a browser is supposed to have or how things should render. This makes browsers far more difficult to create. If web pages use HTML properly and everyone obeys the rules, it will be much more efficient for everyone: indexing robots will easily understand what is in a page, browsers can more effectively render content, etc. —Justin (koavf)TCM 04:56, 25 July 2017 (UTC)[reply]
The behaviour of <center> is perfectly predictable as it's part of the original HTML 1.0 spec and has always worked the same way. It's individual editors here randomly pulling the <center> tags and leaving text left-justified not for valid editorial reasons, but because they're on a technical crusade against the <center> tag, that are the unpredictable factor here. The effects are subtle and annoying. I've seen a couple of examples; one was a navigation box linking to a list of U.S. history articles, the other was an infobox on Oregon Trail#Across Nebraska where Susan has died of cholera was centred over her grave stone until somebody disturbed her grave, believing the <center> tag is so evil that they just had to leave a left-justified title over a centre-justified image instead. The formatting is an editorial decision, its removal should also be subject to editorial consensus instead of just "I hate <center> tags". K7L (talk) 13:02, 25 July 2017 (UTC)[reply]
I think we might want to go easy on removing those tags for a bit... Hobbitschuster (talk) 13:33, 25 July 2017 (UTC)[reply]

UEFA Women's 2017 template.

I have no idea whether this is still worth doing, as the championship is long underway, but I've made a mock-up of an event template for the UEFA Women's 2017 European Championship Football/Soccer, currently taking place in seven host cities in the Netherlands.

I doubt that it's useful to add at such a late stage, though if anyone thinks it should be added, then please go ahead. On the other hand, I haven't seen that many event templates (I've only seen the Sochi 2014 one since I started editing here), and am not even sure whether this is still something that is done in general. Please feel free to talk me up-to-date on that subject. The additional info about the event you would need is listed on the template page.

The event takes place until the 6th of August. Please ignore this subject when reading this after that date.
-- Wauteurz (talk) 16:58, 26 July 2017 (UTC)[reply]

I agree that it is too late to usefully add a template - it would be best added 6-18 months before the event starts. I doubt that the championship has a big enough impact on the host cities to justify having a template - several stadiums used seat 10k spectators, whilst the smallest used for football in London 2012 Olympics seated 30k, with the rest 50k+. (The logo on the mock-up also needs to be changed or removed.) AlasdairW (talk) 21:36, 26 July 2017 (UTC)[reply]
I am aware of the logo needing a change - just to get that out of the way. It being too late to add the template is something we agree on, though I disagree that the impact on the host cities is minor. I myself live in Doetinchem, one of the host cities, and during the time that the event has been going on, I've seen loads more foreign tourists come to the city (the number has been doubled several times over), whereas usually around this time we're mostly seeing German and Dutch tourists. The span of the event however, is bigger than just the host cities. While the amount of occupied hotel rooms might not change a lot due to the low amount of hotels in, for example, Doetinchem, the greater area benefits from the event as well. Duiven, for example, has a very large hotel that houses many visitors as well as one or two teams. But yes, compared to the Olympics UEFA Women's is rather small, as are many more international and continental events.
-- Wauteurz (talk) 10:10, 27 July 2017 (UTC)[reply]
Wroclaw currently hosts the World Games and even though I live rather close to the Polish border (though thanks to disinvestment in the railway infrastructure you wouldn't know that from casual observation), I only know of it because there was an American Football tournament involved... Hobbitschuster (talk) 11:48, 27 July 2017 (UTC)[reply]
I think that the Olympics is the only event for which we have created templates. One of the uses of the template is to direct the reader to our article on the specific games, and I think that it is best not to create a template without first creating the Sochi 2014 games article explaining ticketing, special transport provisions etc. The Olympics causes serious disruption to the host city - new stadia being built, large areas blocked off behind security cordons, road closures etc - to the extent that some travellers may wish to avoid the city for the time around the games. AlasdairW (talk) 22:11, 27 July 2017 (UTC)[reply]


A 180-degree turnaround at dotm

Swept in from the pub

Folks, I wanted to note (and do so on as highly visible a page as possible) the marked improvement I've been seeing vis-à-vis the earlier situation at DotM. As I noted elsewhere, when I sounded the alarm about Groningen, we pulled together and whipped the article into shape in record time, and now we're in the process of doing the same with the even bigger task at hand at Aarhus. (Kind thanks go out to Andrewssi2 and Pashley for their help with that latter article.) This is the kind of thing that makes me feel very heartened, and very optimistic about the future of DotM and Wikivoyage in general. You guys are all doing great. Keep it up!

-- AndreCarrotflower (talk) 18:53, 13 July 2017 (UTC)[reply]

Script oddity

Using a Linux version of Firefox, and I keep getting this error message:

A script on this page may be busy, or it may have stopped responding. ...
Script: https://en.wikivoyage.org/w/lo…ts&skin=vector&version=02u0abl:12

I do not recall seeing such messages before on WV, though Facebook gives them fairly often. Since I started editing the Aarhus article, though, I am seeing them often, I think only for Aarhus & mostly when I go to edit a listing. Pashley (talk) 12:16, 13 July 2017 (UTC)[reply]

Lint errors

See m:Wikivoyage/Lounge#Lint_errors. --Andyrom75 (talk) 08:04, 17 July 2017 (UTC)[reply]

@Andyrom75: I've fixed several hundred myself now. If you can amend {{Regionlist}}, then I think that would empty out Special:LintErrors/bogus-image-options. —Justin (koavf)TCM 06:33, 23 July 2017 (UTC)[reply]
@Koavf:, sorry the delay but I've been pretty busy. That template is different from the one used in it:voy, but at a first glance it seems that it doesn't produce issues anymore. Whether I'm wrong, please highlight me the category and the page where you have seen the issue and I'll take a look. --Andyrom75 (talk) 15:01, 25 July 2017 (UTC)[reply]


Accessible editing buttons

Swept in from the pub

--Whatamidoing (WMF) (talk) 16:56, 27 July 2017 (UTC)[reply]

Edit dates for listing

Swept in from the pub

Is there a general agreement whether to keep or drop the edit dates (lastedit) for any listing (see, do, etc.)? They are sometimes helpful but also make articles less nice to read.

Cheers Ceever (talk) 07:18, 25 July 2017 (UTC)[reply]

  • Keep - if I see an edit date of May 2017, I'll go to the restaurant or museum with some confidence that the time and price info are fairly correct. If I see an edit date of 2008, I will verify the existence of the place before setting foot out the door. People updating articles will likely choose to focus on checking the oldest listings. Ground Zero (talk) 12:22, 25 July 2017 (UTC)[reply]
I know we had a discussion ahead if implementing this, but I don't know where it is. I think the lastedit field is very valuable and it gives an idea as to how up-to-date an individual listing is. If the aesthetic considerations are indeed so major, we might make it an opt-out feature for registered users or for the printable versions... Hobbitschuster (talk) 13:32, 25 July 2017 (UTC)[reply]
I think we should keep the field, but should stop auto-populating the current date into the field every time a user adds a new listing. Often, listings are added based not on the contributor being physically present at the venue today, but based on secondary sources or even the property's own promotional website - which might not have been updated in years. If a user finds a motel website for tiny Cartwright (Labrador) today and adds that listing, but the motel last updated their website on Tripod in 2004, that should be lastedit=2004-01-01 not lastedit=2017-07-25 as much of the info risks being out of date. We know this place still exists and passed an annual provincial inspection, but any info we obtained from their website is of historical interest only. K7L (talk) 14:37, 25 July 2017 (UTC)[reply]
We can manually remove or alter the date there. And I think only experienced users (who'd know how to do that) add listings based on the website of the business. Hobbitschuster (talk) 14:51, 25 July 2017 (UTC)[reply]
Another advantage is you have and idea where to look in the history if you want to find out who did the last edit. Use when I have a question about an entry. --Traveler100 (talk) 18:32, 25 July 2017 (UTC)[reply]
I think the discussion was here. The autofill for the date saves a lot of time, and normally will produce the right result. The Cartwright error was mine. I believed when I updated it that the website was valid, and would have manually added the date if the line had been blanked. I learned from that mistake to be on the look-out for out-of-date websites. I have not come across another Tripod site since then. Cartwright was a pretty unusual circumstance, and should be used to set policy. Ground Zero (talk) 11:05, 26 July 2017 (UTC)[reply]
The tiny motel in Cartwright isn't the only business to have outdated information on the web. They're plentiful. I only mentioned Cartwright as it was a particularly blatant example and I know some of the info on that site is wrong (the Eagle River CU branch does not exist, as it's not in the list of branches on the credit union's site, but the motel lists it as available). I don't know how much of the info is wrong. The only conditions under which today's date should be inserted as lastedit=... ("mark as up to date") is if the Wikivoyager is either (a) in the destination city right now to see first-hand, (b) picks up a telephone and verifies this directly with someone at destination, (c) has other current communication (e-mail, carrier pigeon, whatever) to the venue or some source of local info (like a destination marketing organisation or visitor info booth) at destination or (d) is looking at something which was posted today with a clear date - they're still getting online reviews, the food inspector posted this year's results today, they're posting timeline to blog or social media with today's date stamp (on a page they control, the existence of a "facebook unofficial page" is meaningless and useless per-se), they just made the front page of the Cartwright Daily Codswallop (extra! extra! read all about it!) and the article is on the newspaper's website with an actual dateline. Otherwise, outdated info stays around for years online, where it risks being sucked into WV and stamped "current" by well-intentioned armchair Wikivoyageurs. Not helpful. Don't add "lastedit=2025" unless you've verified the info is still valid in 2025.
The timestamp isn't intended to determine when the listing was added to the article. On the article's "view history" page, there's a link "External tools: Search" at the top to do what you're looking for. The lastedit timestamp indicates a Wikivoyageur directly verified the information is still current as of that date. Lose that concept, and the datestamp becomes much less valuable. That's why I think we shouldn't be autopopulating 2025 in this field. K7L (talk) 14:31, 26 July 2017 (UTC)[reply]
It is only populated with the current date if and when we checkmark "mark listing as up to date". And when a listing is created from scratch. However, in the latter case it's almost always a) someone who is there / has been there recently b) the owner or someone close to them trying to tout or c) an experienced wikivoyager. In the first two cases, we don't have to worry about the up-to-dateness. In case c we only have to worry about the subset of experienced Wikivoyagers doing armchair research online who find something that is not up to date any more and who do not verify with more than one source. Now of course there is also the unlikely case d) - someone doing armchair research who doesn't know how to remove the "current date" from the field, but really, how likely is that to be a bigger problem than hypothetical malicious editors making stuff up? That said, maybe I should depopulate the "last edit" field when I add the one eat or sleep listing to places in e.g. Switzerland. Even though I think my method of finding them is quite good at catching what might not be up to date. I go to the town tourism site, then see what hotels / restaurants there are, chose one at semi-random (I try to prefer local cuisine) go to the website of the business to fill out the fields, go to a map service to get the coordinates and then hit safe. I really doubt that a listing would be listed in those three and not exist at the time of writing, but other than physically going there, there is probably no way to make sure... Hobbitschuster (talk) 16:51, 26 July 2017 (UTC)[reply]
It's not a case of "someone doing armchair research who doesn't know how to remove the 'current date' from the field" but of the date being there as a default on a new listing unless conscious and repeated efforts are made to remove it, manually, every time. This exploits user inattention and laziness - unless the user is ever-vigilant to remove this, they get put in whether the info is fresh today or just the leftovers from a venue's out-of-date website or an outdated secondary source. The default should be to leave lastedit= blank unless the user actively is saying 'yes, I verified this with someone at the destination today'. K7L (talk) 18:31, 27 July 2017 (UTC)[reply]
The default is that lastedit is filled in with the current date in one of two cases: The listing is newly created or the listing is updated and the checkmark "mark this listing as up to date" is explicitly set. Your wording implies that it is also changed in other cases. That's not the case. Hobbitschuster (talk) 18:35, 27 July 2017 (UTC)[reply]

Hi there guys. I would like to reignite this discussion again on another point of view. I noticed that when editing listing where the date is older, the date does not get updated (see line "762" in this history: https://en.wikivoyage.org/w/index.php?title=Yerevan&type=revision&diff=3258608&oldid=3239980).

This is not just bad, because of the inaccurate date. In general old dates like 2015 give the impression to the reader that the listings are out of date, which they not necessarily are. This, in turn, might be bad publicity on the internet if people start thinking that the information on WV is outdated and rather opt for WT or LP. Btw, the latter is often praised with "completely new researched", which , of course, just seems to be good marketing.

So, maybe it would be a good idea to at least remove older lastedit dates, because then it just says "that it is not the newest information but might still be reliable", instead of say "look, this information is from 2015 and two years old, rather go and get an up to date LP".

Ceever (talk) 13:38, 15 August 2017 (UTC)[reply]

Please stop removing the edit dates while this discussion is on-going. When you update a listing, you have to update the edit manually (type the new date in). It doesn't update automatically. I'd like to know if the information is two years old (i.e., still pretty relevant, or seven years old (probably not useful at all), so yes, I think an edit date of 2015 is useful, and fair to the reader, so they don't go expecting the prices to be the same. LP tells you when the book was published, but not when the info was collected. We win by being more transparent. Ground Zero (talk) 13:50, 15 August 2017 (UTC)[reply]
In the listing editor? There's a check box "mark as up-to-date". Checking that inserts today's date, unchecking this leaves the original information. Unfortunately, two options are missing:
  • There's no way to tell the listing editor to blank the field. If someone's bringing in new info from a secondary source or from a venue website, they might not know when the upstream source was last updated. In that case, leaving the date blank is best.
  • There's no way to tell the listing editor to leave "lastedit" blank when creating a new listing. The "mark as up-to-date" box is gone.
I run into this constantly when I find some small town which has no article at all, construct something from online sources and need to leave "lastedit" blank on everything as I don't have any info on when those upstream sources were last updated. Usually, I just edit the page manually (without the listing editor) and remove "lastedit=" from each newly-created listing. K7L (talk) 13:56, 15 August 2017 (UTC)[reply]
Sorry, but regarding the older dates, this does not look like a consensus to me. @Ground Zero, stop playing police if there is no law here. More importantly, if there is a bug such that the update of lastedit to the current date does not work, I have even more reason to remove such confusing information. Ceever (talk) 16:36, 23 August 2017 (UTC)[reply]
The lastedit function was added as a result of consensus. It is clear that you don't like it, but that doesn't mean you get to remove it from listings. Furthermore, there is no support for your campaign to remove it. The lastedit function remains a part of our listings, so your claim that "there is no law" is invalid. Further, there is no bug, as you call it. The edit date is auto-populated when the listing is createdted, and then must be manually updated if the listing info is updated. As the discussion shows, there will be lots of cases where auto-updating would be the wrong thing to do (e.g., someone fixing phone number or time or currency formats, or removing touting). Unless someone can devise programming that can determine what kind of edit it is, there is no bug. Ground Zero (talk) 02:20, 31 August 2017 (UTC)[reply]
Ok, agreed. Ceever (talk) 12:17, 31 August 2017 (UTC)[reply]
I would prefer that people don't remove the last-edit dates. If you think it's embarrassing to tell readers that a listing hasn't been verified for two years, then it would be more appropriate to request that the template not display that information to readers, than to remove it. Removing it means that editors don't know which listings are in the most urgent need of review.
Also, updating the lastedit parameter works perfectly in my experience. WhatamIdoing (talk) 16:53, 23 August 2017 (UTC)[reply]
I like to see the last edit dates. At the moment we don't have any really out of date ones here, as we have only been adding dates for a couple of years. There may come a point in future when we want to hide the last edit dates from readers who are not logged in, but I think that is some time away. I do sometimes find it irritating that last edit is added if I convert a text paragraph to a listing, but the date can easily be deleted in this case. If I add somewhere new, I will usually be fairly sure that the place was still going quite recently (e.g. an online review 2 months ago, or a hotel offering an online booking for next month). AlasdairW (talk) 22:16, 23 August 2017 (UTC)[reply]
I agree, I do think we should not remove old dates from the listings. This is very valuable information to the traveler. If I'd see a listing with a date of 2013, then I'd go research online more on it before attempting to visit the place. Also when I go through articles, I will sometimes check those listings with no date/an old date and update whatever needs to be updated, so I think this information is also very valuable as an editor, just to see which listings probably need checking whether they are still up to date or whether they even still exist. However, I agree, it is an issue if the field gets autopopulated when creating a new listing, this should definitely be changed and only be added as a conscious choice. Drat70 (talk) 01:02, 24 August 2017 (UTC)[reply]

Is it possible that some here are talking at cross purposes due to misunderstanding one another? Hobbitschuster (talk) 03:42, 31 August 2017 (UTC)[reply]

Collaboration of the month and phone numbers

Swept in from the pub

Having had the same collaboration of the month since September 2014 I think it is time for a new one. I would like to propose that we complete cleaning up phone numbers on the site. After 4 years of work by a small number of dedicated editors we have Category:Listing with phone missing country code down to just over 200 and Category:Listing with phone format issue down to 8 from what was originally in the thousands of pages. The bot is no longer a productive tool for what remains so this will be a manual task, but I think with a little extra help a very achievable one. Should with make this Collaboration of the month for August (and September if needed)?. --Traveler100 (talk) 08:21, 30 July 2017 (UTC)[reply]

I'm fully in support of this telephone number initiative, but I doubt that naming it CotM would draw any interest to it that it wouldn't have accrued otherwise. Frankly, I honestly don't know why we haven't killed CotM yet. The fact that we have a supposedly monthly feature that hasn't been updated since 2014 is an embarrassment to our site. -- AndreCarrotflower (talk) 15:54, 30 July 2017 (UTC)[reply]
I agree with Andre. We have enough trouble maintaing Destinations of the Month. Let's focus on that page. Colloborations can be managed through the pub. Ground Zero (talk) 17:55, 30 July 2017 (UTC)[reply]
You are both probably right, lets just remove CotM from the main page. --Traveler100 (talk) 20:56, 30 July 2017 (UTC)[reply]
I have looked a couple of pages on the list, and I think that quite a few of these numbers are ones which won't work from outside the country, e.g. the two on Pyeongchang 2018 or Melbourne/Inner north. Maybe we should add another keyword to list of descriptions which result in the number being ignored: "domestic" or something similar. AlasdairW (talk) 22:21, 30 July 2017 (UTC)[reply]
Great Work, and I have been advocating for this since 2004 Wikivoyage_talk:Phone_numbers. A key for for local numbers is a good idea. And it could be used to show a diffent icon so WV users know which ones to use from outside the country. I also think we should have a keywork for toll free number, which also normally do not work internationally. Eg North American 800 numbers can be said to have a +1 prefix, but does not really work outside North America. Elgaard (talk) 23:30, 1 August 2017 (UTC)[reply]
I have added the option to add after a number (in country only) , this will remove the country code check. --Traveler100 (talk) 07:52, 3 August 2017 (UTC)[reply]
Have changed the collaboration of the month. If it works and other suggestions come forward later we can re-energies this, otherwise after a couple of months if little action, suggest removing the Cotm from the main page. --Traveler100 (talk) 07:54, 3 August 2017 (UTC)[reply]
A possible future collaboration, in a similar vein, would be fixing dead links: Category:Articles with dead external links. I've been fixing a lot of them, but often I come across one where I can't figure out if the POI still exists or not or where all the information online is in a language I can't read, so help from people with more local knowledge would be great. —Granger (talk · contribs) 10:54, 3 August 2017 (UTC)[reply]

Great job by all involved, first time on the site, no phone format or country code error checks!!! --Traveler100 (talk) 18:37, 14 August 2017 (UTC)[reply]

Yes, well done everyone. And I agree with Mx. Granger on fixing the dead external links. But it will definitely take more than one month to clean the category (still over 5000 articles with dead external links). Perhaps CotM can alternate between a maintenance category and improving articles/content every month? Gizza (roam) 22:23, 14 August 2017 (UTC)[reply]
I like that idea. So next month would be an articles/content month. —Granger (talk · contribs) 03:26, 22 August 2017 (UTC)[reply]
Just throwing a suggestion out there. How about Chennai, this is the largest city article that is at usable status. Plenty of listings to be verified, expanded or deleted. --Traveler100 (talk) 06:08, 22 August 2017 (UTC)[reply]
Sounds good to me. For anyone who is interested, there are now four nominations at Wikivoyage:Collaboration of the month#Unscheduled nominations. —Granger (talk · contribs) 19:08, 28 August 2017 (UTC)[reply]

Wikivoyage for local

Swept in from the pub

Love the Wikivoyage idea! Great for tourists to get around. Is there a similar project for locals to share tips, tricks and best experiences? --Orschiro (talk) 09:44, 2 August 2017 (UTC)[reply]

We certainly appreciate and encourage local knowledge, but keep in mind that the traveler comes first Hobbitschuster (talk) 15:14, 2 August 2017 (UTC)[reply]
Sure! Is there a sister project for locals? --Orschiro (talk) 15:39, 2 August 2017 (UTC)[reply]
There is not, but I am not entirely sure what you think such a project would do / try to accomplish... Hobbitschuster (talk) 15:53, 2 August 2017 (UTC)[reply]
For instance, a tourist is not interested in where to find local traditional shops that provide general high quality goods or services for the household. Locals, however, are. Hence, sharing best practices and knowledge on good alternatives to the mainstream, essentially. --Orschiro (talk) 17:54, 3 August 2017 (UTC)[reply]
This might be what you're looking for (not a sister project but an unaffiliated wiki): https://localwiki.org/Granger (talk · contribs) 15:59, 2 August 2017 (UTC)[reply]
Thanks! Looks interesting. Would be nice to see this under the Wikimedia umbrella for it to gain critical mass. :-) --Orschiro (talk) 17:54, 3 August 2017 (UTC)[reply]
Since the four ways that you might be looking for that I can think of haven't been mentioned yet, I think I shall:
  1. We have some sort of a project for locals to help travellers visiting the place they live, or regions they know a lot about in general. Have a look at Wikivoyage:Docents for that.
  2. Aside from that, no-one is stopping you from working out some more in-depth travel guides in your own userspace.
  3. Furthermore, we are writing a travel guide on this project, and we want to tell our readers all about their destination of choice. Adding some quirky facts or trivia about the destinations you know a lot about helps keeping hold of their attention, so feel free to plunge forward.
  4. Lastly, and I am not too sure about this one myself, Trip reports might be an option to write, albeit one from a local's point of view. There aren't any of these reports yet, and I am not sure if this is a concept that was mocked up and then abandoned or something scrapped all-together.
-- Wauteurz (talk) 21:43, 3 August 2017 (UTC)[reply]
Thanks! I put myself up as a docent. :-) --Orschiro (talk) 03:54, 4 August 2017 (UTC)[reply]
There was a Wikivoyage:My Voyage but I doubt the person originally proposing this is still active. Is the trip reports category part of this? K7L (talk) 11:43, 4 August 2017 (UTC)[reply]
What's the idea behind? Don't fully understand the connection to my question. --Orschiro (talk) 13:00, 4 August 2017 (UTC)[reply]
@K7L: It seems that the trip reports are related to it, yes. The user responsible for My Voyage seems to not have been contributing to Wikimedia Projects since May of 2016 , so the project has basically stranded, though we might want to bring new life into it if people want it. I'll tag @Nicholasjf21: in case he still checks in every so often. He's most likely the best person to explain the thought behind the project.
@Orschiro: The question K7L asked was directed at me and the category I linked. The idea behind My Voyage for as far as I can see is to give Wikivoyagers the ability to report on their travels and make notes of what they've seen and done, seen as how some of us frequently hop across borders. It is however very much an unfinished and inactive project, so don't bother about it.
-- Wauteurz (talk) 16:53, 4 August 2017 (UTC)[reply]
I see, thanks. Still don't see how that fits here. I was asking about a Wikimedia Wiki for locals to share their knowledge with each other. Not tourists, not travelers who want to share their travel experience. :-) --Orschiro (talk) 19:01, 4 August 2017 (UTC)[reply]
I more interpreted your original question, Is there a similar project for locals to share tips, tricks and best experiences?, as a project within Wikivoyage. That lead to me bringing up Category:Trip reports as a possible way to for locals to contribute to Wikivoyage, which derailed to K7L bringing up Wikivoyage:My Voyage. The thread got a bit derailed is all.
-- Wauteurz (talk) 09:15, 5 August 2017 (UTC)[reply]
I appreciate your help! Let's leave it here for now and I will see myself how and where to best contribute. :-) --Orschiro (talk) 13:15, 5 August 2017 (UTC)[reply]

Outline Districts once more

Swept in from the pub

So our list of outline districts has grown to almost 200 again. Now some of them are clearly clerical errors, where a region or city article has been labeled a district by mistake, but some are not and have sat at outline for years. I think there should be zero outline districts, as districtification should only be done and done if it is done in such a way as to produce usable or better district articles. The hurdle, after all, is low. A usable district needs nothing more than one listing each in eat and sleep and should there be no possibility for a listing in either of those categories a good reason and explanation for why the district borders have been drawn thusly (e.g. a district has a lot of sights but no hotels, but there are hotels in another district). We should keep in mind that our districtified cities are among the most high-profile and among those where sub-par quality is the most visible. Now I fear some of those district articles sit unedited, because none of our editors know the cities in question, but if more than half the districts of a city have sat at outline for quite some time, maybe it is time to do something about it, and if that means merging the districts into the city article, so be it. Also, if there are geo-coordinates somewhat plausible district boundaries can be drawn even by those who don't know the place... Hobbitschuster (talk) 14:58, 5 August 2017 (UTC)[reply]

In addition to the above, there are several existing distrification schemes that contain holes, overlaps or both. Hobbitschuster (talk) 15:07, 5 August 2017 (UTC)[reply]
I don't think it's much of a problem if one or two districts are just outlines, but sadly it's not uncommon to see a whole stash of outline articles and a great deal of listings in the main article and every time it's frustrating to see that. Otherwise I completely agree with your points. One good thing is that some of these articles might fulfil usable status already but the editors have forgotten to update the status. And yes, while one likely cannot on one's own write up an article of a place one hasn't been to from scratch to Star, it's definitely not rocket science to (even greatly) improve such an article. I'm more and more tempted to write a w:For Dummies essay about the topic. ϒpsilon (talk) 17:42, 5 August 2017 (UTC)[reply]
There are places where what would be an obvious DotM candidate if it were guide is held back because some districts are still at outline. See Talk:Shanghai#Getting_to_guide.3F for one example. The Shanghai district structure already underwent one major revision; see Talk:Shanghai#District_changes.3F for the discussion. The current scheme has mostly one article per official district; see Shanghai#Districts for details.
Should the divisions be revised again? Perhaps consolidate some outline districts? Or is there a way to get those outlines up to spec? Perhaps a collaboration of the month? Pashley (talk) 18:32, 5 August 2017 (UTC)[reply]
It may just be my perception, but there seem to be a particular overhang of American cities represented on the "outline districts" list linked above.. Asian cities seem to not do so bad. Hobbitschuster (talk) 18:49, 5 August 2017 (UTC)[reply]
The most are in Melbourne. I think that one problem is that a district often has enough See, Eat etc to be worthwhile, but may be lacking in Sleep listings. Often hotels are mostly found in a few districts of a city and may be completely lacking in others. I would prefer that we didn't simply list the only hotel in a district if it is not somewhere that would be worth listing if all the city hotels were together. I have wondered whether we would be better to have City/Sleep and put all the sleep listings (arranged by district) in the one article. This is how paper guidebooks tend to do, and I think is better for readers who may not be too fussy about the exact district that they stay in. AlasdairW (talk) 22:37, 5 August 2017 (UTC)[reply]

Technical question

Swept in from the pub

The admins of the website "The Israel Travel and Bicycle Maps Website" (http://israelhiking.osm.org.il/), whom specialize in developing and sharing different open source maps in Hebrew which are presented as different layers above the original map layer from OSM, have experessed interested creating a map layer based on all the listings of the Hebrew Wikivoyage (they already have a map layer one can use to visually see wherever across the globe places exist which already have articles about them at the Hebrew Wikipedia).

They haven't tried to create this map layer yet, but as far as I understand it , this might be difficult to do since, unlike Wikipedia, where individual articles have a geo location... with Wikivoyage (although we have geo locations for individual articles, that are mostly about bigger regions) they are probably mostly interested in getting the geo locations of the listings (See, Do, Buy, Eat, Drink, Sleep), which as far as I understand are mostly stored within thousands of different articles.

Is there any way they would be able to access one local Wikivoyage file which contains all the geo locations of all the Hebvoy lightnings? or is there any other technical way they would be able to use this info in order to produce a layer with all the Hebvoy listings ? ויקיג'אנקי (talk) 03:04, 9 August 2017 (UTC)[reply]

@ויקיג'אנקי: I'm confused: Why would a single geo coordinate be easier to scrape than the structured listings in all our individual {{See}} and {{Do}} templates? Can you point us to any of their conversations? Since a lot of Israelis know English, I imagine that we could talk with them about it. —Justin (koavf)TCM 03:19, 9 August 2017 (UTC)[reply]
I have just invited their developers to participate in this discussion. I guess what I am asking, what would be the easiest way to produce a map layer that would have all the Hebvoy listings that have coordinates? (I assume that there is one main file generated monthly by the Wikimedia Foundation, which contains basically all this info, which they would be able to work with.... right?) ויקיג'אנקי (talk) 03:28, 9 August 2017 (UTC)[reply]
@Koavf:Our goal is to show individual "See" and "Do" POIs on the map with links to the appropriate place in the relevant Wikivoyage article.
As far as I understand, there is an API for geo-searching articles (for example ). There is also an API for POIs, such as "See" and "Do", on a page-by-page bases (for example ). The API also allows combining the two queries, using one as a pageids generator for the other . In any case, the geo-search is limited to a 10000 meter radius.
Alternatively, the global list of Wikivoyage articles is available from Wikimadia Toolforge. When using either the API or the Toolforge approaches, the client does not directly scrape Wikivoyage.
My question: Is there a way to get all POIs in an area larger than a 10000 meter radius, such as all of Israel? 5.29.181.199 15:58, 9 August 2017 (UTC)[reply]
@5.29.181.199, ויקיג'אנקי: Hm. I'm actually not sure. The best bet I would have is generating a list of individual articles from Category:Israel and then combining data from that. The best I can do is @Pigsonthewing:, whom I have known to make some useful tools in the past and to post on phabricator: or maybe at mw:Maps. Have you tried any of those options yet? —Justin (koavf)TCM 16:26, 9 August 2017 (UTC)[reply]
@Koavf, Pigsonthewing: I could only find where bug reports for WikiMedia-API can be posted. Is there a place to post questions about the API? For example, using Category:Israel to find all applicable WikiVoyage articles is a great idea. It seems to require some coding on the client side as each API call lists just one level of sub-categories in the category hierarchy. I would like to ask the API experts if the tree traversal can be done on the server side. 5.29.181.199 07:53, 11 August 2017 (UTC)[reply]
@5.29.181.199: I would think that between mw:Project:Current issues, mw:Maps, and mw:Project:Support desk, someone could give an intelligent answer to this. —Justin (koavf)TCM 15:52, 11 August 2017 (UTC)[reply]
It seems to me that the easiest way to do this might be to query Wikidata instead of Wikivoyage. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:55, 24 August 2017 (UTC)[reply]

@5.29.181.199: Zeev, in order for you to be able to use ALL of the Destination + Itinerary articles on the Hebrew Wikivoyage (instead of only using Destination + Itinerary articles that are about locations in Israel, I created the following category on the Hebrew Wikivoyage, which I am hoping would be of use to you for this purpose. ויקיג'אנקי (talk) 20:15, 11 August 2017 (UTC)[reply]

Thanks for your help! I've created a GitHub issue for adding a WikiVoyage overlay to the map, in case you want to follow the progress. 5.29.181.199 21:17, 14 August 2017 (UTC)[reply]

Displaying currency symbols

Swept in from the pub

In the discussion about the symbol for the Bangladeshi taka, we found there are sometimes problems displaying "৳", so instead we're using "Tk", which is also commonly used in the country. In a similar discussion about the Armenian dram, it seems that "Դ" is commonly used. Are there any problems with displaying it? If so, it may be better to spell it out as "dram", but it would be best if we could use the symbol that travellers will see in the country. @Ceever: @LtPowers: @Hobbitschuster: Ground Zero (talk)

Well in the above text I am not having display problems (Ubuntu, Firefox) Hobbitschuster (talk) 20:52, 10 August 2017 (UTC)[reply]
I do not see and display problems either. Does this display - - also show a problem? Or how about using {{BDT|2}} to get Tk2--Traveler100 (talk) 21:37, 10 August 2017 (UTC)[reply]
The symbol shows up fine with Google Chrome on Windows 7 as well. -- AndreCarrotflower (talk) 00:54, 12 August 2017 (UTC)[reply]
I suppose using the template is safer than using the character directly. It gives those without the character in their font the possibility to hover to see the Tk "title". If this is a common problem we still leave some readers (who do not hover) confused. --LPfi (talk) 15:46, 13 August 2017 (UTC)[reply]
Since our correspondent on the ground in Bangladesh says that "Tk" is also commonly used, it would be easier to stick with that. Random contributors are unlikely to use the template. As for the Armenian dram, if there are no objections, we can start using the "Դ" symbol. Ground Zero (talk) 15:55, 13 August 2017 (UTC)[reply]
Could swap the display round to show Tk and on mouse over Դ. --Traveler100 (talk) 15:56, 13 August 2017 (UTC)[reply]
Sorry, I don't follow. We're talking about Bangladeshi Taka (Tk) and Armenian dram (Դ) as two different issues. One taka = 5.92 dram, which is probably not useful information, but I'll mention it anyway. Ground Zero (talk) 18:04, 13 August 2017 (UTC)[reply]
I suppose what was meant was swapping "৳" and "Tk", so that Tk was showed by default and "৳" as when hovering (it is the other way round now in the template). --LPfi (talk) 19:09, 13 August 2017 (UTC)[reply]
The display issues are likely caused by not having the relevant character-set installed in the user's browser, rather than anything happening on Wikivoyage. That is, of course, outside our control. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:59, 24 August 2017 (UTC)[reply]
Yes. The question is whether we want to use characters that are missing from the (default) fonts of many users. I think we should make sure the pages show in a somewhat sensible way regardless of what fonts people use, and in a good way for all common configurations. --LPfi (talk) 10:36, 25 August 2017 (UTC)[reply]
That's why I continue to support restricting graphic currency symbols to just the most common (probably Dollar, Pound, Euro, Yen, and maybe Yuan). Powers (talk) 01:21, 6 September 2017 (UTC)[reply]

How bureaucratic do we want to sound?

Swept in from the pub

Have a look at these edits to Spain. They seem to violate our WV:Tone by being too bureaucratic sounding. On the other hand, we may want to be as accurate as we can on legal matters... Hobbitschuster (talk) 15:14, 10 August 2017 (UTC)[reply]

I think the earlier text was about enough, although we could warn about carrying personal use amounts, and update the fines. Those who want to "facilitate consumption of drugs" should seek advice elsewhere, so legalese about that is unnecessary. I also think this is a matter where we do not want to sound accurate: those who want to stretch the limits need better advice than what we can give. --LPfi (talk) 17:56, 10 August 2017 (UTC)[reply]

I'm not sure the new edit added anything that was really needed, but certainly there was nothing wrong with it. While we don't want to sound bureaucratic, the "tone" is probably more related to he fun parts of traveling. The law is bureaucratic and talking about it in this way is probably for the best. --Willthewanderer (talk) 22:12, 10 August 2017 (UTC)[reply]

When I compare the two versions, the change that stands out to me is all about content: "possession and consumption of illegal drugs at private places is not prosecuted" vs "These rules are actively enforced." Before worrying about the tone, I think it is important to figure out the real risk of criminal charges. WhatamIdoing (talk) 16:52, 11 August 2017 (UTC)[reply]
In fact, the rules in the two versions seem to be the same: the rules that are going to be enforced in the latter version are about public places, not the private places where the former one says you are safe. As I read them, both say private consumption in private places is OK, while possession and use in public is not, and severely punished when not about small quantities and personal use. I do not know how one is supposed to get the drugs for personal use safely to the private place were one is going to consume them, but I do not think that is our problem. --LPfi (talk) 15:37, 13 August 2017 (UTC)[reply]
We could vary tone depending on context; Stay Safe and Stay Healthy sections should use serious wording, as well as topics such as Holocaust remembrance. More enjoyable topics such as shopping and nightlife can be described more casually. /Yvwv (talk) 03:41, 17 August 2017 (UTC)[reply]

Why hasn't the Wikivoyage Pageview statistics Page been updated since July 23?

Swept in from the pub

? ויקיג'אנקי (talk) 17:29, 12 August 2017 (UTC)[reply]

@ויקיג'אנקי: Have you checked with the users at https://stats.wikimedia.org/#fragment-15? —Justin (koavf)TCM 17:34, 12 August 2017 (UTC)[reply]
@Koavf: which users exactly? (link didn't properly work). ויקיג'אנקי (talk) 18:34, 12 August 2017 (UTC)[reply]
@ויקיג'אנקי:Sorry, it's not on that page: Author:Erik Zachte, ezachte@### (no spam: ### = wikimedia.org) —Justin (koavf)TCM 18:47, 12 August 2017 (UTC)[reply]
I think it's some kind of stats database problem. They're working on it. See w:en:Wikipedia:Village pump (technical)#Pagecounts-ez dataset hasn't generated since JUL-23 if you're interested in this. WhatamIdoing (talk) 23:23, 13 August 2017 (UTC)[reply]

Russian or Ukrainian

Swept in from the pub

Is anyone familiar with these languages? These edits by a new editor appear to me to be converting the translations from the Latin alphabet to the Cyrillic alphabet from from Russian to Ukrainian. Is this an appropriate change for a city in eastern Ukraine? Isn't Russian the principal language there? Perhaps someone more familiar with the region could weigh in. Ground Zero (talk) 02:46, 14 August 2017 (UTC)[reply]

It is not an easy question. Whereas Russian is the main spoken language in this area, Ukraininan is the only official language, and its usage has been enforced recently. Ideally, both Russian and Ukrainian translations should be kept, but this renders the listings too long in general. --Alexander (talk) 07:15, 14 August 2017 (UTC)[reply]
I think that as the traveller comes first, the solution of keeping the Russian and adding Ukrainian is the best one, regardless of length, and it's the one I suggested at User talk:Dƶoxar. Ikan Kekek (talk) 19:39, 14 August 2017 (UTC)[reply]

Air Berlin filing for bankruptcy

Swept in from the pub

So Air Berlin has had economical problems for a while now and it also used to have Hartmut Mehdorn as a CEO, which usually doesn't end well, but a few days ago it finally filed for bankruptcy. Apparently the German federal government (there is a federal election in September) helped out with an emergency loan but it is clear that something will happen with Air Berlin in the foreseeable future. If media reports are to be believed Lufthansa, which already bought up / leased / whatever several of Air Berlin's planes is interested in taking over either the airline as a whole or some of its assets. However despite Lufthansa certainly being a buyer with the necessary liquid assets as well as the necessary expertise, such a takeover would raise very real antitrust issues and the Bundeskartellamt may not approve it. Another potential buyer is Hans Rudolf Wöhrl who has in the past owned several airlines (ironically selling one to Air Berlin) and seems to have specialized in the "buy cheap, own for some time, sell high" model but it is unclear whether he has deep enough pockets and some have labeled his attempt to take over the airline a "PR stunt". Nationalization - even temporary - seems out of the question despite the Feds already being on the hook for the money they just loaned Air Berlin, but I think we should certainly keep an eye on the situation, not least because several articles for Germany still portray Air Berlin as a bigger airline than it currently is - its domestic network for one is much smaller than just two or three years ago. Hobbitschuster (talk) 12:08, 22 August 2017 (UTC)[reply]

Swept in from the pub

I have seen it very often in "by plane" sections or even airport articles that it says "there are flights from London" or something of the sorts, without mentioning which airport. Sorry, but this is anything but helpful. Hobbitschuster (talk) 20:36, 25 August 2017 (UTC)[reply]

It is going to be tough to ask that of new contributors. Even if we do link to the city directly, it isn't the worst thing surely? --Andrewssi2 (talk) 02:00, 28 August 2017 (UTC)[reply]
Most of those things are not done by new editors, but rather legacy edits that haven't been changed in years. At any rate, many (though by no means all) WP articles on airports contain a list of flights to/from them. Should we copy them? Is there a way to have them stored in Wikidata? Should we simply point to WP for those and not list a single flight connection ourselves? Hobbitschuster (talk) 15:52, 28 August 2017 (UTC)[reply]
Sorry, but I think that saying that "there are flights from London" is 98% helpful. I think that we can assume that readers will book a flight, not head straight to the airport. Some cities are served by 2 or more of the 5 London airports, but this is a detail that doesn't matter at the initial planning stage. It is much more useful to say which railway station(s) have trains from London, as it is quite practical to go to the station and buy a ticket minutes before getting on the train (not good value for money for long journeys). AlasdairW (talk) 23:12, 28 August 2017 (UTC)[reply]
Well when I book a flight I tend to enter various IATA codes into a search engine. There are of course metropolitan IATA codes, but not all search engines know them. What is more fundamentally the issue here however is that we have articles on a bunch of airports, so why not link to them where we are clearly talking about Luton Airport or Gatwick Airport or Heathrow Airport and not London as a city? And besides that, those lists are, I fear, among the most outdated parts of our site. I don't have a good answer as to how to avoid their being outdated, but I fail to see how a list of questionable up-to-date ness including gems like "There are flights to London with Intersky starting in 1979" (exaggerating slightly for comedic effect) help either us as a site or our readers. Hobbitschuster (talk) 23:31, 28 August 2017 (UTC)[reply]

Should we create an article for Jeju airport?

Swept in from the pub

Jeju airport has passenger numbers above 25 000 000 as of 2015 and likely those are even higher for 2016 and will rise in the future. It's true, most of those are domestic travelers, but it is thus bigger in terms of passenger traffic than Gimhae Airport and several other airports on which we have articles. Should we thus create an article? Hobbitschuster (talk) 17:04, 27 August 2017 (UTC)[reply]

I do not know if it rates an article of its own, will happily leave that decision to people who know the region and/or are working on the Wikivoyage:Airport Expedition. However, it seems worth mentioning that if there is no separate article immediately, we should create a redirect as I did for Mactan-Cebu International Airport. Other articles can then link to the redirect & will not need changes if the redirect is later replaced by a full article. Pashley (talk) 17:37, 27 August 2017 (UTC)[reply]
Like many places in the Caribbean or Mediterranean, virtually all flights come and go from the north and it's by no means a transit airport but more of "the end of the line" serving people going to and from Jeju. So no, I don't think it should get an article on its own. Andrew probably agrees. ϒpsilon (talk) 17:47, 27 August 2017 (UTC)[reply]
On that note: Link to the redirect itself, do not bypass the redirect and link directly to the target! A lot of people (both on this wiki and others) seem to be in the habit of "fixing" links to redirects by having them point directly to the target. But if a redirect is changed into an article, or re-targeted somewhere else, then the "fixed" links are no longer pointing where they should, and that just creates a huge mess. See w:wp:Do not fix links to redirects that are not broken for more information But in short: Links to redirects are (usually) not broken and should not be "fixed". Emmette Hernandez Coleman (talk) 23:50, 27 August 2017 (UTC)[reply]
If the airport guide were simply merged into the Gimhae guide, the content about the airport would overwhelm the city guide. For a merge to work: A lot of the the airport content would have to be cut. Emmette Hernandez Coleman (talk) 23:50, 27 August 2017 (UTC)