Wikivoyage talk:Technical details

Wikivoyage Code?

moved from travellers' pub by (WT-en) Evan

I could not find any links on the main page, in the footer, in the FAQ, or the Help pages about what code you use to run this wiki. Is it something you wrote yourself, or are you using the MediaWiki project, or something else?

You probably haven't tried looking for MediaWiki with the "Find" thingy? :) If you had you knew it was MediaWiki. (WT-en) Guaka 09:51, 28 Jan 2004 (EST)

It's in the FAQ. Actually, our version is slightly modified in some ways -- mostly stylesheet changes. I've added an RFE to MediaWiki to add a "powered by" logo, but it's not in the current version. But you're right -- we should probably have that info on the Project:About page, too. --(WT-en) Evan 12:45, 28 Jan 2004 (EST)

The FAQ does mention MediaWiki, though it doesn't note what version you're running, BTW. -- (WT-en) Beland 03:05, 25 Jul 2004 (EDT)

---

min·us·cule ( P ) Pronunciation Key (mn-skyl, m-nskyl) also min·is·cule (mn-skyl)-- www.dictionary.com

WikiMedia upgrade?

I'm guessing that the version of WikiMedia that Wikivoyage is using is older than the one Wikipedia is using. The latter seems to have an easier-to-read layout and I find its editing interfaces a little spluftier. Are there plans in the works to upgrade, if that's the case? -- (WT-en) Beland 02:56, 25 Jul 2004 (EDT)

long term stability?

i'm just wondering what plans there are for long term stability of the site, e.g.:

• Is there any formal relation to the Wikimedia Foundation?
• Most probably there are many informal links with wikimedia techies/projects. Can someone say roughly what these are, so we have some idea of how independent and/or crosslinked the projects are?
• i guess there should be details in [1] but so far there's nothing... :(

The point is that many of us already have some trust that wikimedia projects are properly backed up and sql dumps are available etc, and we wouldn't like to contribute to a web site which might get lost and so lose all our work... Canaca.com presumably would not want to lose its reputation by allowing things to get lost, but in any case, maximum transparency etc etc would be a good idea.

There is no formal relationship of any kind, although there's a lot of cooperation as many users are shared. (WT-en) Jpatokal 12:14, 9 Aug 2005 (EDT)

No formal relationship, but we're friendly. Many if not most users are Wikimedia editors, too. I'm a MediaWiki developer and I fix bugs and add features to the MediaWiki codebase -- both stuff that helps Wikivoyage and stuff that helps Wikimedia sites. I've been a Wikipedian since 2002.

I understand that some people who haven't got a lot of experience with wikis think Wikimedia is the be-all and end-all of the wiki world. It is not; there are tens of thousands of wikis in the world, and that number is growing by leaps and bounds.

:) i'm not trying to suggest that wikimedia is the be-all and end-all of the wiki world, i don't like centralisation and hierarchy :). (WT-en) Boud 08:21, 10 Aug 2005 (EDT)

As for long-term stability: we've been around for 2 years, and we don't intend to go off the air any time soon. --(WT-en) Evan 15:47, 9 Aug 2005 (EDT)

Good :) (WT-en) Boud 08:21, 10 Aug 2005 (EDT)

backups

Is there somewhere where people can download weekly sql files? (WT-en) Boud 12:02, 9 Aug 2005 (EDT)

This gets asked a lot, but the answer remains "No". (WT-en) Jpatokal 12:14, 9 Aug 2005 (EDT)

Private backups of the entire site are made on a daily basis, for the record. --(WT-en) Evan 15:37, 9 Aug 2005 (EDT)

Thanks - it's good to know about the backups and the link that Jpatoka gave: Project:How to re-use Wikivoyage guides provides a good explanation for the "No" (which to me reads as "Not yet, and also probably not soon"). (WT-en) Boud 08:21, 10 Aug 2005 (EDT)

Software setup

The following was moved from Evan's talk page, and seems like valuable info to include under Project:Technical details. The only reason I didn't include it there is that (WT-en) Evan is (at present) the only person who can keep it up-to-date, and I'm not sure it's something he wants to deal with:

Cache 404

The key difference is the 404-handler caching system, which flops plain HTML files out onto the filesystem when a file isn't found. This way, Wikivoyage serves mostly flat HTML files. This is our "medium-sized" solution -- generating every page every time is too costly for us, but we don't have an array of reverse-squids, like Wikimedia does.

There's a read-only arch repository for the Cache404 extension at http://bad.dynu.ca/~evan/arch/ (category mw-cache404). It should have at least some of the info you need to get it set up. It's an extension, not a patch-- you should be able to cp -R everything to your MediaWiki setup.

The key thing for Apache is to set up MediaWiki as an ErrorDocument for a directory, so that if a file isn't there, MW+Cache404 will try to put it there. The one in /en/ looks like this:

 ErrorDocument 404 /wiki/en/index.php
 ExpiresActive on
 ExpiresDefault M0

 RewriteEngine On
 RewriteBase /en/

 RewriteRule ^(Special:.*) /wiki/en/index.php?title=$1&%{QUERY_STRING} [L]

 RewriteRule \.html$ - [L]
 RewriteRule ^$ Main_Page.html [L]

 RewriteRule ^(.*)$ $1.html [L]

I think the Rewrites for .html aren't terribly necessary -- they could be done with MultiViews. The Rewrite for Special: is to make sure that e.g. Recent changes isn't cached.

For LocalSettings.php, you have to include the extension, and set a couple of variables. The most important is to turn off file caching in MediaWiki (else you get a redirect loop).

 $LP = "$WEBROOT/$wgLanguageCode";
 
 # ...
 
 $wgCachePages = false;

 require_once("extensions/Cache404.php");

 $wgCacheDirectory = "$LP";
 $wgCachePath = "/$wgLanguageCode";
 $wgCache404MaxCount = 800;
 $wgCache404MaxSize = 25600000;

Here, "directory" and "path" are the filesystem and Web path, respectively.

URL creation

I've also noticed a pretty big difference in the way vanilla mediawiki (either REV1_4 or the trunk) constructs URLs from the way Wikivoyage does it. Would this also be a change to LocalSettings.php? -- (WT-en) Mark 08:39, 11 Jul 2005 (EDT)

Nevermind. Found it:

 $wgArticlePath    = "$wgScriptPath/$1";

-- (WT-en) Mark 08:46, 11 Jul 2005 (EDT)

Canaca link

When we were hosted on XLInternet, we had a link to their site (they gave us a discount, as the owner is a personal friend). Canaca isn't giving us a discount or really anything more than a reasonably-priced hosting service. I don't think it's particularly cogent that Canaca.com is the hosting service, and I think the link might be misleading -- that it's appropriate for Wikivoyagers to contact Canaca directly (it's not -- please don't do that). So, unless there's a good reason, I'm removing the link. --(WT-en) Evan 15:40, 9 Aug 2005 (EDT)

wiki.travel

A new .travel domain has been tentatively accepted by ICANN [2]. No word on which proposal has been accepted, but eg. for this one the eligibility requirements look pretty strict:

Applicants for a .travel domain name must be verifiable participants in the travel industry and each name applied for be a name to which there is a right that has been established through rights registration or use. Each applicant will be required to declare which category of right it relies on for the registration. In all applications, eligibility and name selection rights will be authenticated by a third party specialist as detailed in Part B (C).

Time to create a shoebox company or association for Wikivoyage and join ACTA? They charge a fairly steep $175/year for the privilege though. (WT-en) Jpatokal 04:01, 16 Dec 2004 (EST)

I think there's some work underway on starting a non-profit or a foundation or something like that. If there's enough money left over after paying for bandwidth this might be useful, but it seems like it could be a lot to pay for very little in return. -- (WT-en) Mark 04:40, 16 Dec 2004 (EST)

Let me add that it is a neat idea, I just don't know about the cost. -- (WT-en) Mark 06:12, 16 Dec 2004 (EST)

Wiki software upgrade

Swept in from the Project:Travelers' pub:

Hi there, I have seen in the wikipedia that they are busy with a software upgrade from 1.4 to 1.5. Will this have any effect on wikivoyage? (WV-en) Felix 27/06/2005, 16:31 (GMT)

Barring any problems we'll probably move up to 1.5 sometime after it's released. Or are you asking whether the 1.5 upgrade at Wikipedia is going to affect us? I'm not sure about that, but I doubt it. --(WT-en) Evan 12:00, 27 Jun 2005 (EDT)

I actually meant, if we are also going to upgrade! Felix

Show changes

Swept in from the Project:Travelers' pub:

Could we add "Show changes" button to the edit page, like wikipedia has? I find it helpful if I make several changes in one edit and don't remember them all, to make sure I haven't made typos and such before I commit them and check the "show changes" equivalent in history (Compare selected versions). (WT-en) TransUtopian 03:09, 2 Sep 2005 (EDT)

That's a feature of the MediaWiki 1.5 software, which is currently in beta (see http://www.mediawiki.org/wiki/Download#Testing). When a stable version is released Wikivoyage will most likely update, and the show changes button will then be available. -- (WT-en) Wrh2 03:19, 2 Sep 2005 (EDT)

Thanks, Wrh2! And nice job on the sweeping. -- (WT-en) TransUtopian 09:07, 2 Sep 2005 (EDT)

Breadcrumbs code?

First of all let me say "Great Site!" Now that's out of the way.

Could you share with us what it takes to get the style of bread crumbs that appear at the top of each of your pages? I've been asking at mediawiki.org and mwusers.com and there is no definitive answer. Thanks in advance.

-Jeff

It's our IsIn template, which can be found here. Which wiki are you using this on, because some changes may be required? -- (WT-en) Andrew Haggard (Sapphire) 10:50, 5 September 2006 (EDT)

Where can the latest version of the RDF extension be downloaded? The one in MediaWiki SVN is 0.4, but I've seen Evan refer to 0.5, but couldn't download it from there [[3]]. Also I imagine there is some change needed to the skin to actually print the trail. Where can that be found?

--Alex

Attribution Question

Most articles say "Based on the work by ...." at the bottom of the page. I've just added a page (Hsipaw). Why doesn't it say "Based on the work by Wandering?" --(WT-en) Wandering 12:54, 16 May 2007 (EDT)

Because it says "This page was last modified 16:17, 16 May 2007 by Wandering." Once the next person edits it, your name gets moved into the "Based on..." list. (WT-en) Jpatokal 13:06, 16 May 2007 (EDT)

Thanks! All is now clear :-). --(WT-en) Wandering 13:14, 16 May 2007 (EDT)

Google-analytics

Swept in from the pub:

What's the deal with google-analytics? I assume this is something that's connected with the Wikivoyage site rather than just my browser, right? It seems like with a page of any length, it usually hangs while trying forever to finish loading something from there. The page appears complete, except sometimes some of the images don't load, and you can't (at least in Firefox) use the Print Preview function. (WT-en) Sailsetter 10:57, 22 March 2008 (EDT)

I believe it's something that IB installed to track page hits, etc... and I think it also may have contributed greatly to the site slowdown. Things are getting back up to speed, and I believe they're planning some new magic in the near future as well that'll fix even more issues... but you may care to comment on that link on shared – (WT-en) cacahuate ^talk 22:50, 22 March 2008 (EDT)

Page title extension?

Swept in from the pub:

Looking at Special:Version there's an extension "setupTravelGuideTitle". Is this the extension that allows a page like Kingston (Ontario) to show up in the title bar of the browser as "Kingston travel guide - Wikivoyage"? (I.e. the "(Ontario)" is stopped from displaying.)

Could we find out more about this extension? Much appreciated. --(WT-en) Chriswaterguy 22:55, 18 August 2008 (EDT)

List of Wikivoyage articles in easy to gather format

Swept in from the pub:

Hello all,

I was wondering if there was a list of wikivoyage articles available in a format which is easy to import into a text doucumant such as notepad. I have found Special:Allpages, however it is not easy to extract this list to a usable format. Any suggestions to where i could locate such a list?

Many thanks,

--(WT-en) Sirtrebuchet 17:57, 24 August 2008 (EDT)

I'm not sure if there is a way to list all of the articles on one page or not, but I don't imagine it would be too difficult to write a Word macro (or equivalent) to organize the data in a way that would be helpful to you. If you would like help doing this please contact me. --(WT-en) Matt ^Talk 22:14, 24 August 2008 (EDT)

You can also use the api if you have some programming experience. The following link will return the first 50 article names in XML: http://en.wikivoyage.org/w/api.php?action=query&list=allpages&aplimit=50. Info on the API is available at http://en.wikivoyage.org/w/index.php. If you decide to use it, be careful not to abuse the WT servers. Keep total number of articles requested at a time small (less than 500) and implement delays between requests. --(WT-en) Nick 08:07, 25 August 2008 (EDT)

Thanks for all of the ideas. You guys are a great help. I am currently working with the second idea suggested, as it seems to be what i am looking for and i think i will be able to get it to do what i want. Thanks for the quick and helpful replies. --(WT-en) Sirtrebuchet 22:04, 25 August 2008 (EDT)

MediaWiki upgrade is in staging and ready for testing

Swept in from the pub

There is now a version of WT with the Mediawiki upgrade, live at this URL:

http://staging.en.wikivoyage.org/wiki/Main_Page

No credentials or password are needed to access this server. Just click through, poke around, and report any issues you find under BETA here:

http://shared.wikivoyage.org/wiki/Tech:Upgrade_to_MediaWiki_1.17

Testing this is critical to ensuring that the transition to the full new site is smooth. This will be happening very soon (weeks or sooner) and we're anxious to hear feedback. So please, go look.

KNOWN ISSUES:

1. This is NOT the "real" Wikivoyage site -- your updates won't carry over to the real site. This is just a testing environment for debugging; it will mimic the look & feel of the new site however.

2. The article data you will see on this staging server are several months old. New edits will not appear. Don't panic -- all the data will of course appear when the real site is switched over.

3. Speed will be okay; not as fast as the full site, but not nearly as slow as the previous testing environment.

Thank you,--(WT-en) IBobi 14:43, 11 April 2012 (EDT)

FYI the staging server is now closed. The next step will be adding the booking tool and internally testing the site, then opening it up again on staging for the community to test before it goes live. This should happen in the next week.--(WT-en) IBobi 14:57, 20 April 2012 (EDT)

Just a reminder—MediaWiki is the name of the software. --(WT-en) Peter ^Talk 17:53, 20 April 2012 (EDT)

Thanks Peter -- think I reversed my MW and WM a couple times there.--(WT-en) IBobi 19:06, 20 April 2012 (EDT)

***RESCHEDULED for next week*** MediaWiki upgrade is scheduled for Monday 5/14/12

Swept in from the pub

Site will be READ-ONLY for up to TWO DAYS while the upgrade is occurring.

If there are edits you'd like to make, please do so over the weekend and on Monday.

When the new site comes online, it will be on new hardware as well. Bug reporting is available here:

http://shared.wikivoyage.org/wiki/Tech:Upgrade_to_MediaWiki_1.17#1.17_UPGRADE_BUG_REPORTS

If for any reason you need to contact me, I can be reached on my Talk page or my email address paul.obrien at internetbrands.com.

Thank you for hanging in there with us; once this major upgrade is complete we expect to be able to update the site software in a much more timely manner (1.11 to 1.17 is a big jump), and we have development resources to address any technical issues still lingering after the upgrade, as well as to address the next set of feature requests from the community. We're looking forward to the next stage of the project and hope you are too!--(WT-en) IBobi 17:47, 4 May 2012 (EDT)

I've updated MediaWiki:Sitenotice to note the scheduled outage. -- (WT-en) Ryan • (talk) • 18:36, 4 May 2012 (EDT)

Thank you Ryan.--(WT-en) IBobi 18:59, 4 May 2012 (EDT)

Might be helpful to list the time in UTC (for the non-US users) in the message that displayed at the top. So: A MediaWiki upgrade is scheduled for Tuesday 8-May at 10AM PST (17:00 UTC). The site will be READ-ONLY for up to two days during the upgrade. (WT-en) AHeneen 23:38, 4 May 2012 (EDT)

Done (WT-en) –sumone10154 10:58, 5 May 2012 (EDT)

THIS HAS BEEN RESCHEDULED FOR 5/15/2012 due to network issues today. As we get closer to the day, I'll post a time -- it is likely to be around 5am PST (12:00 UTC).--(WT-en) IBobi 14:22, 7 May 2012 (EDT)

THIS HAS BEEN RESCHEDULED FOR 5/14/2012. It is still likely to be around 5am PST (12:00 UTC).--(WT-en) IBobi 16:28, 11 May 2012 (EDT)

Since the site isn't read-only as of 8AM (Pacific) on 14-May, is there any update on when the upgrade is going to happen? -- (WT-en) Ryan • (talk) • 10:56, 14 May 2012 (EDT)

I'm told 2 minutes from now.--(WT-en) IBobi 12:58, 14 May 2012 (EDT)

I'm following GW Bush's counsel [4]. --(WT-en) Peter ^Talk 13:33, 14 May 2012 (EDT)

I will update shortly on the upgrade status.--(WT-en) IBobi 16:55, 17 May 2012 (EDT)

Mission Accomplished!? --(WT-en) Peter ^Talk 20:18, 17 May 2012 (EDT)

Mediawiki upgrade status

Swept in from the pub

The planned MW upgrade has been postponed.

During the last 2 days, as you may have noticed, Wikivoyage has been in read-only mode for a planned upgrade. Due to unforeseen technical circumstances, we had to re-schedule.

We have been working to transfer the entire site to new hardware while simultaneously migrating it to MW version 1.17 from 1.11.

As you can see, the existing version of the site running on 1.11 is back online for read-write access. Our technical department has built testing tools specific to the customized version of MW that runs Wikivoyage, and we'll be using them to troubleshoot and log potential causes of the upgrade failure.

As soon as we have it, I will post a new timetable for the switchover to the new site.

Please let me know if you have any questions or concerns,--(WT-en) IBobi 20:37, 17 May 2012 (EDT)

Hi, this is (WV-ja) Shoestring, an admin of ja:.

It will be very much helpful if you could kindly leave a brief message about the concrete schedule of the next system maintenance on the MediaWiki:Sitenotice of shared and en:, at least prior to a week.

Usually ja: users don't check the pubs on en: and shared so frequently, and we have totally no idea what on earth was happening on the site for the last couple of days.--(WT-en) Shoestring 07:22, 18 May 2012 (EDT)

Out of interest, what are the changes? Is it just performance improvements, or will this bring in new ads? Are we getting upgraded to the Vector skin, because the Monobook is starting to look quite old. I've seen non-Wikimedia sites do it; we should too. (WT-en) JamesA ^>talk 21:40, 19 May 2012 (EDT)

Any chance of providing a database dump for download at the same time? Please? (WT-en) Anjocu 23:05, 21 May 2012 (EST)

Parser functions

Swept in from the pub

Is there a way to use something like the parser functions on Wikipedia? Member (talk) 08:21, 15 January 2013 (UTC)

The same software (MediaWiki) is being used, so I don't see why not... --Rschen7754 08:23, 15 January 2013 (UTC)

The parser functions are an extension, not MediaWiki core code. Predictably, most of the extensions from Wikipedia are here (as both are WMF-hosted projects); the Special:Version page has a list of which ones are installed. There are also a few Wikivoyage-specific extras, such as mw:extension:GeoCrumbs, special:mapsources and the mw:extension:RelatedSites and mw:extension:RelatedArticles. K7L (talk) 00:00, 16 January 2013 (UTC)

UserMerge permissions removed

Swept in from the pub

Hi,

Today we removed the "usermerge" right from all bureaucrats on Wikivoyage. The UserMerge extension was used during the transition period when some users had two accounts and this let them reclaim their contributions. However, it has not been used for some time, and was blocking the eventual m:SUL finalisation, in addition to possibly causing database inconsistencies. If a user must be merged, you can contact m:User:Hoo man for assistance. Please let me know if you have any questions or concerns on my meta talk page.

Thanks, Legoktm (talk) 14:58, 7 August 2014 (UTC)

This really should have been raised here *before* breaking things, instead of merely presenting this after the fact as a fait accompli. K7L (talk) 15:04, 7 August 2014 (UTC)

This has still been used occasionally, including quite recently. This is a bad move, and should be reversed. Ikan Kekek (talk) 18:12, 7 August 2014 (UTC)

While it has been used somewhat recently, it's pretty rare. If it was blocking SUL finalization, then it has to go. The chances of someone with an editing history (significant enough to make merging worthwhile) finally coming by after nearly two years are pretty slim, and if it does happen, we can talk to User:Hoo man. Powers ^(talk) 21:33, 7 August 2014 (UTC)

If people would like to know what's going on, they should subscribe to m:Tech/News. There are more than a dozen developer teams (involving both volunteers and paid staff) supporting 800+ wikis in about 300 languages. Realistically speaking, they cannot separately raise all issues "here" for every change. However, they do make general announcements for many things, and they often contact directly affected groups (in the case of SUL, the global stewards, who are getting stuck with all the extra work). WhatamIdoing (talk) 16:55, 8 August 2014 (UTC)

The usermerge issue affects Wikivoyage specifically in a way that it doesn't affect all "800+ wikis in about 300 languages" because of a quirk in this project's history. We have a mess of imported edits from (WT-en) and (WV-en) users that no other Wikimedia project (outside WV) has, so we have a greater need to merge users. The same would be true if a change were to specifically affect a Wikivoyage-specific extension (RelatedSites, RelatedPages, Insider, MapSources) that no other WMF project uses. WV, and not just the global stewards, is a directly-affected group. K7L (talk) 17:20, 8 August 2014 (UTC)

Even so, there's 16 Wikivoyages, most of which used that extension... --Rschen7754 03:21, 10 August 2014 (UTC)

...a far cry from 800 wikis. How much of Wikivoyage:User account migration and Wikivoyage:Changing username is incorrect now? K7L (talk) 03:43, 10 August 2014 (UTC)

...and this is far from that team's only task. As I said, if you want to know what tech issues will affect this community, you need to be looking out for changes, not assuming that the devs will bring everything to you in advance.

Also, as a practical matter, if your bureaucrats aren't worried about a change to a tool whose use was "somewhat rare", then you probably shouldn't worry about it either. The work can still be done, just not in the old way. WhatamIdoing (talk) 16:03, 11 August 2014 (UTC)

That's a fairly condescending attitude that I, for one, don't appreciate. Regardless of whether the bureaucrats are concerned or not, I think the points raised by the rest of the community are quite valid. -- AndreCarrotflower (talk) 16:20, 11 August 2014 (UTC)

I'll just chime in to say that, having worked on various software projects, I understand & fully support WhatamIdoing's comments above. There is no need at all for a tempest in this particular teapot, and anyone who cares about other changes should be reading m:Tech/News. Pashley (talk) 16:59, 11 August 2014 (UTC)

This is a very small issue, compared to recent events happening elsewhere on Wikimedia... --Rschen7754 03:50, 12 August 2014 (UTC)

• It seems that there will soon be a tool to merge global accounts (see mw:SUL finalisation/Global account merge), so I assume that users simply will have to wait until that tool is available and then request a global merge. --Stefan2 (talk) 10:39, 7 September 2014 (UTC)

Change in renaming process

Swept in from the pub

Part or all of this message may be in English. Please help translate if possible.

Single-user login (SUL) finalisation's goal is so that every Wikimedia editor has a single, recognized global account with one username across all projects. As you may know, after a long delay, it's now underway as an effort between bureaucrats, stewards, and Wikimedia Foundation engineers. This will also allow for development of cross-wiki tools like global notifications and watchlists. There is no set date for the completion of single-user login finalization at this time.

The process involves changing all rename processes into one global renaming process. The ability for local bureaucrats to rename users on this wiki will be turned off on Monday, 15 September 2014, as one of the first steps. Global renamers are in the process of being created to make sure projects and languages are represented by the time this occurs. I sent a note to every bureaucrat about this process three weeks ago with an invitation to participate and many have begun requesting to be a part of the group. Together with the stewards, the global renamers will be empowered to help editors work through the often difficult process of getting a global name.

In parting, visit Special:MergeAccount to unify your account if you have never done so. If your local pages about renaming still need to be updated, please do so and consider pointing people to m:SRUC for future rename requests, especially if this project does not have bureaucrats that hold global renamer permissions. If you have any questions, you can read more on the help page on Meta. You can also follow the technical progress on mediawiki.org. Contact me on Meta any time with questions as well. Thank you for your time.

-- User:Keegan (WMF) (talk) 9 September 2014 16.22 (UTC)

Javascript changes coming soon ("All your scripts are going to break" edition)

Swept in from the pub

This information has been sent out for weeks, if not months, but I'm not sure if it's reached the right people at Wikivoyage. This message is for you if you could be described (even a little bit) by one of these categories:

• Volunteers developing gadgets (such as Twinkle, HotCat, etc.).
• Users that maintain their wiki's MediaWiki:Common.js scripts.
• Users that have their own personal scripts.
• Users who get questions when other people's scripts break.

Several deprecated methods in MediaWiki's JavaScript modules will be removed soon (early October). Please check your code to ensure it won't break with these changes, and update it if needed. Please also check and fix any gadgets or scripts you or your wikis rely upon, to prevent breakage.

What's going to break

Deprecated methods to be removed in MediaWiki 1.25:

• Remove mw.user.name() method. 1 Use mw.user.getName() instead.
• Remove mw.user.anon() method. 1 Use mw.user.isAnon() instead.
• Remove mediawiki.api methods' "ok" and "err" callback parameters. 2 Use the returned Promise interface instead.
• Remove mediawiki.api.category "async" parameter. 2 The ability to override $.ajax() to not be asynchronous has been removed. The default (asynchronous) behaviour remains. Use the Promise interface to retreive the fetched data from the API.
• Remove jquery.json module. 3 Use standardised JSON.stringify and JSON.parse methods. And depend on the "json" module to ensure a polyfill is lazy-loaded for cross-browser support.

If your script contains these functions, then they're going to break. If you use a script, and the author isn't active any more, and you don't know whether it's going to break, then I believe that all you need to do for the first couple is read (or search) the script and see whether the bold-faced words appear in them. If not, then it should be okay. I saw some of the cleanup over at the English Wikipedia a few weeks ago, and it didn't look too difficult.

When it's going to break

These removals will land in MediaWiki 1.25alpha in early October 2014, being deployed to Wikimedia wikis in October 2014 (probably 1.25wmf2 or 1.25wmf3).

How to stop things from breaking

If nobody here can figure out what needs to be done, then you can ask for assistance on the the wikitech-ambassadors mailing list.

If you know more, if you've already updated certain scripts, or if you're able to help people, then please feel free to post that information here. Also, if you are active at any other languages of Wikivoyage or any other small projects, please pass this information along to them. Thanks, WhatamIdoing (talk) 05:27, 18 September 2014 (UTC)

Extension:CreditsSource

Swept in from the pub

Something seems to be wrong with mw:Extension:CreditsSource, it's not displaying MediaWiki:Creditssource-credits properly in the page footer but instead displaying a hard-coded default which contains two clickable links to a rival travel wiki and one redlink labelled as "history". The link should go to the history page here, not red-link or off-site. I don't see anything in Bugzilla and no one has edited any relevant MediaWiki: messages lately, has someone or something broken the underlying extension code? K7L (talk) 13:58, 27 September 2014 (UTC)

The links above the edit box when creating a new page are also missing; there used to be a one-click option to drop {{smallcity skeleton}} or a few of the others onto a blank page. K7L (talk) 16:12, 27 September 2014 (UTC)

Everything looks fine to me at the moment. Powers ^(talk) 20:06, 27 September 2014 (UTC)

Weird. I'm seeing this only if I'm logged in to Wikivoyage; the same pages look fine if I log out or go to another computer which is not logged in. K7L (talk) 13:17, 6 October 2014 (UTC)

I see the problem now. Any messages which have been customised in MediaWiki: space for 'en' are likely to go back to default text if I have 'en-gb' or anything else selected as my language in my profile. That would explain why no one else noticed this, as well as why it only appears when logged in. K7L (talk) 17:00, 11 October 2014 (UTC)

I read at the English Wikipedia that someone was going to add a warning to Special:Preferences to alert people to this unexpected behavior. (Most people thinks it's a problem, but some say it's a feature that allows them to ignore a lot of unwanted detail and messages.) WhatamIdoing (talk) 17:16, 13 October 2014 (UTC)

Derivative FX

Swept in from the pub

Tracked in Bugzilla
Bug 67283

Since the tool Derivative FX for uploading the derivative images from Commons doesn't work, I'm not able (in an easy/quick way) to perform that activity. There's an alternative tool that I can use? Any suggestion would be highly appreciated. Thank you. Massimo Telò (talk) 16:57, 30 September 2014 (UTC)

I have the very same problem, very frustrating. So I usually just upload as new files and mention in the description. Cheers! Nicolas1981 (talk) 10:57, 1 October 2014 (UTC)

Supposedly it's been moved to Labs, but I get an error message about it not being enabled. WhatamIdoing (talk) 16:04, 4 October 2014 (UTC)

I feel like it's something the Wikimedia Foundation might want to take into their hands, as it affects copyright attributions. Has a bug been opened about this? Nicolas1981 (talk) 05:38, 9 October 2014 (UTC)

A report was filed a couple of months ago at bugzilla:67283. I believe that all of the attribution work could be done by hand, so this is probably not a serious copyright problem. WhatamIdoing (talk) 17:22, 13 October 2014 (UTC)

Bug with Internet Explorer

Swept in from the pub

Most of the small icons to add listings to the site do not show up properly with Internet Explorer (see screenshot). Anyone know how to fix this bug? Globe-trotter (talk) 14:42, 1 October 2014 (UTC)

With what version of Internet Explorer? Nicolas1981 (talk) 06:26, 2 October 2014 (UTC)

I see exactly the same thing with IE 11 under Windows 8.1 (64 bit). I never use IE for Wikivoyage, but this may be a CSS issue. --Andrewssi2 (talk) 08:15, 2 October 2014 (UTC)

Yes that's also my version. Globe-trotter (talk) 09:33, 8 October 2014 (UTC)

Is there nobody who can solve this problem? I have no experience with CSS and I am also not authorized (I think) to make changes. --FredTC (talk) 12:38, 23 October 2014 (UTC)

It appears to be an issue with IE's scaling of SVG images - see http://stackoverflow.com/questions/9777143/svg-in-img-element-proportions-not-respected-in-ie9. The code that adds the buttons to the edit toolbar is in MediaWiki:Common.js, but it's using functionality that appears to be part of MediaWiki (and not custom Wikivoyage code), so I'm hesitant to overwrite anything in the CSS or JS. One possible workaround might be to try recreating the toolbar icons as 22x22 PNG icons (instead of SVGs), in which case no scaling would be necessary. -- Ryan • (talk) • 13:43, 23 October 2014 (UTC)

Thanks, I think our admin Globetrotter can use your suggestions to solve the problem. --FredTC (talk) 07:54, 24 October 2014 (UTC)

Article statistics available?

Swept in from the pub

Quick question: Are there statistics available per article (e.g. number of article impressions)? Thanks! User4353 (talk) 09:12, 24 October 2014 (UTC)

Click the history tab for any article. Near the top there's an external link that says "Page view statistics". Powers ^(talk) 14:04, 24 October 2014 (UTC)

Thank you very much! User4353 (talk) 14:10, 24 October 2014 (UTC)

How would I be able to get the image Carousel feature working on the Hebvoy main page?

Swept in from the pub

Need the help of the tech experts on this one. I am interested in having a display of the Hebvoy star articles on the main page of Hebvoy, which would be done with the same Carousel feature used on the envoy main page. I noticed the newly launched Persian Wikivoyage uses the same feature on their main page as well. Unfortunately, so far I haven't been capable of getting this feature to work on Hebvoy by simply importing the page as is. I assume I have to install some special extension for it to work. How exactly would I be able to get it to work? (I am, by the way, an admin on the Hebvoy) ויקיג'אנקי (talk) 15:27, 30 October 2014 (UTC)

Have a look at MediaWiki:Common.js and MediaWiki:Common.css - copy everything from those two files from the "BEGIN Main Page carousel code" section until the "END Main Page carousel code" section to the corresponding files on Hebrew Wikivoyage. You'll also need Template:Banner. Beyond that, make sure your carousel is set up the same way that English one is done on the Main Page:

<div class="jcarousel-wrapper">
  <div class="jcarousel">
    <div class="jcarousel-list">
        <div class="jcarousel-item">
{{banner|direction=left|title=Karachi|section=Destination of the Month|section-link=Previous Destinations of the month|image=KarachiBanner1.jpg|quote=Pakistan's largest metropolis blends glass-and-steel modernity with colonial British architecture of yesteryear.}}
        </div>
        <!-- more carousel items go here -->
    </div>
  </div>
  <span class="jcarousel-control-prev">[[#|‹]]</span>
  <span class="jcarousel-control-next">[[#|›]]</span>
  <p class="jcarousel-pagination"></p>
</div>

-- Ryan • (talk) • 03:31, 31 October 2014 (UTC)

Thanks for the help Ryan. Yesterday we added the carousel feature to the hebvoy main page. This feature is used to display all of the hebvoy starred articles of 2014 on the main page. I think this would greatly help to expose the hebvoy readers to some of the best articles our little community created so far, thus encouraging more people to create expanded quality articles which would also be linked to from the main page. ויקיג'אנקי (talk) 14:07, 2 November 2014 (UTC)

Are the Numbers Accurate?

Swept in from the pub

Are the numbers accurate when you look at the pageviews of an article? I noticed that for example Tsuyama says it has been viewed 48 times in the past month and ranks as the 8964th in traffic [5] while Takahashi [6] has been viewed only 44 times but ranks higher in traffic at 7942. Do I simply not understand what the traffic rank is? Shouldn't the one that is visited more rank higher? ChubbyWimbus (talk) 17:19, 11 November 2014 (UTC)

The rankings haven't updated since March, although I don't know how accurate they were even when they were fresh. Looking through the user talk archives of the editor responsible for those graphs, there were complaints about inaccurate rankings even back when they were updated more often.
Thatotherperson^talkcontribs 23:57, 11 November 2014 (UTC)

Is there no other analytic service that can help? A lot of our discussions around increasing readership would be helped greatly by numbers that we had confidence in. --Andrewssi2 (talk) 01:57, 12 November 2014 (UTC)

Are the visits accurate? It would definitely be helpful to have this feature working. ChubbyWimbus (talk) 15:46, 12 November 2014 (UTC)

Just to clarify, it's the ranking numbers that I believe are inaccurate. I can't personally vouch for the total views being accurate, but I have no reason to doubt them. I don't know of any way to update the rankings or any alternative service we could switch to.
Thatotherperson^talkcontribs 22:33, 14 November 2014 (UTC)

VisualEditor coming to this wiki as a Beta Feature

Swept in from the pub

Hello. Please excuse the English. I would be grateful if you translated this message!

VisualEditor, a rich-text editor for MediaWiki, will soon be available on this wiki as a Beta Feature. The estimated date of activation is Wednesday, 26 November.

To access it, you will need to visit the Beta features page after the deployment and tick the box next to "⧼Visualeditor-preference-core-label⧽". (If you have enabled the "Automatically enable most beta features" option, VisualEditor will be automatically available for you.) There will also be a "⧼Visualeditor-preference-language-label⧽" that you can enable if you need it.

Then, you just have to click on "Edit" to start VisualEditor, or on "Edit source" to edit using wikitext markup. You can even begin to edit pages with VisualEditor and then switch to the wikitext editor simply by clicking on its tab at any point, and you can keep your changes when doing so.

A guide was just published at mediawiki.org so that you can learn how to support your community with this transition: please read and translate it if you can! You will find all the information about the next steps there. Please report any suggestions or issues at the main feedback page. You will also receive the next issues of the multilingual monthly newsletter here on this page: if you want it delivered elsewhere, for example at your personal talk page, please add the relevant page here.

Thanks for your attention and happy editing, Elitre (WMF) 18:12, 21 November 2014 (UTC)

VisualEditor coming to this wiki as a Beta Feature (errata)

Swept in from the pub

Please notice the correct direct link to access Beta features is this one. Thanks for your understanding! Elitre (WMF) 18:35, 21 November 2014 (UTC)

Wikivoyage:Changing username

Swept in from the pub

Recently the renaming process was changed so that only stewards and m:global renamers can rename users, so that the process is global. Perhaps requests should be made at Meta (m:SRUC), and this process should be closed? --Rschen7754 16:30, 25 October 2014 (UTC)

Strong support. It seems like common sense that if we can't rename users here then we should redirect Wikivoyage:Changing username to m:Steward requests/Username changes and either archive or delete the various sub-pages (Special:PrefixIndex/Wikivoyage:Changing username). As a side note, as a bureaucrat I'm very glad that figuring out what to do about global username conflicts is no longer something that needs to be dealt with. -- Ryan • (talk) • 16:46, 25 October 2014 (UTC)

@LtPowers: and @DerFussi: as others who may be interested in this. --Rschen7754 17:22, 25 October 2014 (UTC)

I certainly have no objection, but I wasn't clear enough on the change to say if that's the correct course of action or not. Powers ^(talk) 20:12, 25 October 2014 (UTC)

This sounds like a no-brainer. Let's redirect. Ikan Kekek (talk) 19:05, 26 October 2014 (UTC)

Perhaps an explanatory page is better, with a link to meta and some comment on Wikivoyage:User account migration. The meta page seems not to yet reflect that all changes are "global" - and being redirected to another site (Wikimedia instead of Wikivoyage) is obviously confusing at least for some. --LPfi (talk) 07:21, 27 October 2014 (UTC)

I've closed the process; feel free to add to the page. --Rschen7754 04:56, 26 November 2014 (UTC)

Mainpage carousel

Swept in from the pub

Hi, I am trying to get functioning mainpage carousel similar to wikivoyages at a different wiki. I ran into a stack exchange question by local editor. He obviously solved the carousel issue and I would like to ask him, how did he do it :-) Can any1 kindly point me to the person, which used "Nicholasjf21" nick at stackexchange? Big thanks to you! --Wesalius (talk) 10:08, 15 November 2014 (UTC)

Not me... Nicolas1981 (talk) 08:41, 20 November 2014 (UTC)

Special:EmailUser/Nicholasjf21? -- AndreCarrotflower (talk) 14:15, 20 November 2014 (UTC)

Thank you very much AndreCarrotflower. --Wesalius (talk) 06:59, 27 November 2014 (UTC)

Would you be interested in a PageBanner extension?

Swept in from the pub

The mobile web team that powers your mobile site are interested in page banners across all projects, not just Wikivoyage. I was curious, if I was to write an extension that used the Wikidata property https://www.wikidata.org/wiki/Property:P948 would you be willing to install it and remove usage of your existing pagebanner template? Currently the banners are drastically broken on mobile, an image as big as 1mb could block the loading of the rest of the page. Using an extension would allow us to adapt the image based on the size of the browser and would bring performance gains to the desktop site too. Jdlrobson (talk) 19:12, 5 December 2014 (UTC)

I don't know a lot about Wikidata, so how would this work in cases where a Wikidata property isn't set, or if envoy wanted to use something different than what was set up in Wikidata? Also, I'm not super-familiar with Wikimedia extensions, so how would the page banner code be invoked once converted to an extension? Is it still called through Template:Pagebanner, thus leaving some room for local customizations?

On a side note, if there is a good way to return more appropriately sized images using an extension that would be a huge win - right now we're pulling in some very large images in cases where they might not be needed, which is far from ideal on slower connections. -- Ryan • (talk) • 19:24, 5 December 2014 (UTC)

I like the idea of an extension in principle, but I want to know more about how it would work. Continuing to allow local customization would be key. Different language versions of Wikivoyage don't always have the same banner (and I'm not convinced we need to). If the banner is used by other projects, I could foresee a travel-focused banner that works for Wikivoyage may not be the best banner for a different project, and vice-versa. We also add icons to the banner like previously featured destination and disambiguation, which can vary from Wikivoyage project to Wikivoyage project.

All that said, I think it's a great idea to explore. Something that has potential performance gains is worth considering. -Shaundd (talk) 04:57, 8 December 2014 (UTC)

As someone who contributes to several Wikivoyage sites, I personally would not mind loosing the ability to override Wikidata's banner. I always use the same in all languages anyway. Apparently Shaundd (and probably others) want to keep this ability so it would be great to have though. By the way, in how many articles does the English Wikivoyage override the Wikidata banner? If none, the experiment could start with the English Wikivoyage alone. Or start with the Wikivoyages who have a policy of not overriding Wikidata banners. Cheers! Nicolas1981 (talk) 05:13, 8 December 2014 (UTC)

Hi Jdlrobson! Sounds wonderful! Banners are an easy way to make articles very attractive, and even though some projects (like Wikipedia or Wiktionary) might not like it, other sites like Wikiquote (they really really like images over there), Wikisource, Wikibooks, Wikiversity, etc would love it. Best of luck with the project, and don't hesitate to use us for testing (I don't speak for the whole community but I think most people here will love the idea). Nicolas1981 (talk) 05:01, 8 December 2014 (UTC)

Thanks for the feedback User:Nicolas1981 :-) Shaundd essentially the template would no longer needed but you would be able to style it using MediaWiki:Common.css - but I'd be looking at porting over your existing styles as a starting point so you would notice no difference. It would be an extension so projects would be able to turn it on only if they felt it useful but the community as a whole would benefit from such a feature. It would be great to use Wikidata as the basis for the data as this means we wouldn't have to resort to magic words in wikitext and keep the wikitext clean and friendly to new editors! I've setup https://phabricator.wikimedia.org/T77925 so we have a central place to talk about this topic. Jdlrobson (talk) 22:04, 8 December 2014 (UTC)

I'm all for making things simple and user-friendly, where possible. A dumb question though -- how do I add myself as a subscriber to the Phabricator discussion? I didn't see anything, but it also wouldn't let me log in with my WM username. -Shaundd (talk) 06:42, 9 December 2014 (UTC)

Shaundd: Push the round on/off button in the upper-right, click the Wikimedia button, and accept the OAuth authentication. Nicolas1981 (talk) 08:25, 9 December 2014 (UTC)

VisualEditor News #10—2014

Swept in from the pub

Did you know?

Basic table editing is now available in VisualEditor. You can add and remove rows and columns from tables at the click of a button.

The user guide has more information about how to use VisualEditor.

Since the last newsletter, the Editing Team has fixed many bugs and worked on table editing and performance. Their weekly status reports are posted on mediawiki.org. Upcoming plans are posted at the VisualEditor roadmap.

VisualEditor was deployed to several hundred remaining wikis as an opt-in beta feature at the end of November, except for most Wiktionaries (which depend heavily upon templates) and all Wikisources (which await integration with ProofreadPage).

Recent improvements

Basic support for editing tables is now available. You can add and delete tables, add and remove rows and columns, set or remove a caption for a table, and merge cells together. To change the contents of a cell, double-click inside it. More features will be added in the coming months. In addition, VisualEditor now ignores broken, invalid rowspan and colspan elements, instead of trying to repair them.

You can now use find and replace in VisualEditor, reachable through the tool menu or by pressing ^ Ctrl+F or ⌘ Cmd+F.

You can now create and edit simple <blockquote> paragraphs for quoting and indenting content. This changes a "Paragraph" into a "Block quote".

Some new keyboard sequences can be used to format content. At the start of the line, typing "* " will make the line a bullet list; "1." or "#" will make it a numbered list; "==" will make it a section heading; ": " will make it a blockquote. If you didn't mean to use these tools, you can press undo to undo the formatting change.

There are also two other keyboard sequences: "[[" for opening the link tool, and "{{" for opening the template tool, to help experienced editors. The existing standard keyboard shortcuts, like ^ Ctrl+K to open the link editor, still work.

If you add a category that has been redirected, then VisualEditor now adds its target. Categories without description pages show up as red.

You can again create and edit galleries as wikitext code.

Looking ahead

The current VisualEditor design will be replaced with a new theme designed by the User Experience group. The new theme will be visible for desktop systems at mediawiki.org in late December and on other sites in early January. (You can see a developer preview of the old "Apex" theme and the new "MediaWiki" one which will replace it.)

The Editing team plans to add auto-fill features for citations in January.

Planned changes to the media search dialog will make choosing between possible images easier.

Let's work together

• Share your ideas and ask questions at mw:VisualEditor/Feedback.
• Translations of the user guide for most languages are outdated. Only Ukrainian, Portuguese, Spanish, French, and Dutch translations are nearly current. Please help complete the current translations for users who speak your language.
• Talk to the Editing team during the office hours via IRC. The next session is on Wednesday, 7 January 2015 at 22:00 UTC.
• File requests for language-appropriate "Bold" and "Italic" icons for the character formatting menu in Phabricator.
• The design research team wants to see how real editors work. Please sign up for their research program.
• If you would like to help with translations of this newsletter, please subscribe to the Translators mailing list or contact us directly, so that we can notify you when the next issue is ready. Subscribe or unsubscribe at Meta. Thank you!

— Elitre (WMF)

19:00, 26 December 2014 (UTC)

Help fix all of these simple syntax errors

Swept in from the pub

My script has found a few hundreds syntax errors, your help is needed to fix them: User:Nicolas1981/Syntax_checks

Easy and helpful :-)
Please remove each line you fix.

Also, I generated a new CSV file containing all listings: http://datahub.io/dataset/listings

Thanks a lot! Nicolas1981 (talk) 06:42, 6 January 2015 (UTC)

Does anyone know why the mobile view of the Hebvoy main page doesn't display most of that page's content?

Swept in from the pub

I noticed recently that the mobile view of the Hebvoy main page doesn't display most of that page's content (the mobile readers see many {{{section}}} wiki codes instead). Does anyone know why this happens and how to fix it? ויקיג'אנקי (talk) 16:47, 15 January 2015 (UTC)

Any section on the main page with class="nomobile" is hidden in mobile. See User talk:Jdlrobson#Mobile Main Page question for a recent discussion about similar issues on English Wikivoyage. -- Ryan • (talk) • 16:53, 15 January 2015 (UTC)

Mobile layout

Swept in from the pub

Comparing the Wikivoyage mobile layout with the one of Wikipedia, I've noticed that the "edit" & "watch" icons are in the wrong position, causing a bad layout (ovelapping the pagebanner). Most likely is because of the customization of the pagebanner because it doesn't happens on de:voy.

As a nice to have, would be possible have the horizontal menu on the mobile view as in the desktop one? --Andyrom75 (talk) 17:54, 20 January 2015 (UTC)

Curiosity: none is able to do it or at least interested? --Andyrom75 (talk) 07:52, 28 January 2015 (UTC)

Few people here have familiarity with how the mobile version is constructed. Definitely log a bug on Phabricator. Powers ^(talk) 01:56, 29 January 2015 (UTC)

Slower than Wikitravel in the Philippines

Swept in from the pub

You guys should know that for the last week or so, it's been nearly impossible to contribute due to crawling servers. Annoyingly, the inferior Wikitravel hasn't shown the same problems. --112.198.90.214 05:12, 30 January 2015 (UTC)

Very strange, it is very fast in Japan... thanks for letting us know! Could you please install Firebug in Firefox then press "Network" in Firebug, then load a Wikivoyage article, then take a screenshot and post it here? Example: https://i.imgur.com/lCc5InE.png That would help us identify what is going wrong. Thanks for your feedback! Nicolas1981 (talk) 05:28, 30 January 2015 (UTC)

Under what circumstances can this happen? Personally I experienced issues accessing WV in Mainland China in 2013, including very slow response times (Wikipedia as a whole was being blocked intermittently at the time) . I don't see ISP's in the Philippines doing anything like this... --Andrewssi2 (talk) 06:01, 30 January 2015 (UTC)

Ph ISPs don't censor but I could believe they'd try to save some pesos. Well, it seems to have repaired itself to a degree or two now, but both WP & WV were unusable for more than a week with the same message about waiting for mediawiki.bits or some such. I wrote down the actual message at the time, but couldnt posdt it after waiting 2h for this page to load. Do you have a bug report email address? I can't see one posted prominently...--112.198.90.214 09:38, 30 January 2015 (UTC)

If it affects WP as well, and if it's waiting for bits.wikimedia.org, then it sounds like a Wikimedia routing/network issue that affects access from the Philippines. Because of the bigger pool of users at WP, you would be best to report it at Wikipedia:Village_pump_(technical). If you have no luck there, try Wikipedia:Bug reports and feature requests, which explains how to report problems at Phabricator, Wikimedia's newish bug reporting system (which hopefully deals with tech problems other than just bugs). I sympathise, because I have experienced similar problems in the past, and it is difficult to report slow access using a site that itself is subject to the problem. Nurg (talk) 20:32, 30 January 2015 (UTC)

That's the one: bits.wikimedia.org !

What do you think of having an email address featured to report these kinds of problems? --49.151.114.202 13:41, 31 January 2015 (UTC)

I see no real need to encourage communication per email. Of course such bugs are very unpleasant and it's good that people report issues. However, this is a wiki. There's Phabricator or - for those who find that too unfamiliar or complicated - simply the travellers' pub. Chances of getting an answer or (better yet) a solution are much better on-wiki, where any report gets far more eyes on it than an email would. JuliasTravels (talk) 22:08, 31 January 2015 (UTC)

Tbose are all valid points, Julia, but lose sight of the main point that I've had to wait 3 days again for bits.wikimedia.org to settle down again b4 I could write this. You're not going to get better Ohiljlppines artkcles with these obstacles. Also, when i use my Globe mobile I keep getting weird messages about Andrew Carrot blocking and send him an email but, again, no email address! --222.127.250.223 05:46, 3 February 2015 (UTC)

Thanks for posting this information, 222.127. I'm sorry that you're dealing with these problems. I'll tell the Ops team about this. Problems with bits.wikimedia.org don't usually last so long. In the meantime, it might be helpful to have information about whether it affects only Wikivoyage, or if it affects sites like Wikipedia: or Wiktionary:, too, and whether there are times of day that are better or worse. (For example, a while ago we had a problem with the English Wikipedia being slow in the eastern United States, but only in the evening and only on one large ISP—just when everyone got home from work.) Thanks, Whatamidoing (WMF) (talk) 07:05, 3 February 2015 (UTC)

Also: if you can't reach anyone on wiki or find a better way to report a problem, you can e-mail me. I can't really fix technical problems, but I can forward e-mail messages.  ;-) Whatamidoing (WMF) (talk) 07:10, 3 February 2015 (UTC)

And just 16 minutes after sending that message, Faidon the Awesome has set up a temporary patch and started the process of getting permanent corrections made to the upstream providers. This problem was probably affecting most or all of the Philippines plus some other users in the region, so the Operations team sends grateful thanks for your persistence in reporting it. If it comes back, then please let me (or them) know. Whatamidoing (WMF) (talk) 07:35, 3 February 2015 (UTC)

Listings as CSV, OsmAnd

Swept in from the pub

New extracted Wikivoyage listings data is available: .CSV to check/hack listings, .OBF to display listings in OsmAnd, .OSM to integrate with OpenStreetMap data. Enjoy! Nicolas1981 (talk) 13:50, 30 January 2015 (UTC)

Thank you for new .csv file... I have found it very useful in the past for some checks etc.; however, there is an issue in that not all articles are using the listings templates and unfortunately that information would not be represented in the .csv file... To correct this would probably be a very large undertaking indeed... Matroc (talk) 03:40, 31 January 2015 (UTC)

Transforming all POIs to listings templates is indeed a large undertaking, but like banners we will make it, little by little (banners are currently at 32%). It should actually be faster than banners, because it is fast to do for small destinations, whereas banners are more difficult for small destinations. Personally I transform into templates every time I see a not-yet-template POI. If you want to help with this, that would be great! Cheers! Nicolas1981 (talk) 04:04, 5 February 2015 (UTC)

VisualEditor News #1—2015

Since the last newsletter, the Editing Team has fixed many bugs and worked on VisualEditor's appearance, the coming Citoid reference service, and support for languages with complex input requirements. Status reports are posted on mediawiki.org. Upcoming plans are posted at the VisualEditor roadmap.

The Wikimedia Foundation has named its top priorities for this quarter (January to March). The first priority is making VisualEditor ready for deployment by default to all new users and logged-out users at the remaining large Wikipedias. You can help identify these requirements. There will be weekly triage meetings which will be open to volunteers beginning Wednesday, 11 February 2015 at 12:00 (noon) PST (20:00 UTC). Tell Vice President of Engineering Damon Sicore, Product Manager James Forrester and other team members which bugs and features are most important to you. The decisions made at these meetings will determine what work is necessary for this quarter's goal of making VisualEditor ready for deployment to new users. The presence of volunteers who enjoy contributing MediaWiki code is particularly appreciated. Information about how to join the meeting will be posted at mw:Talk:VisualEditor/Portal shortly before the meeting begins.

Due to some breaking changes in MobileFrontend and VisualEditor, VisualEditor was not working correctly on the mobile site for a couple of days in early January. The teams apologize for the problem.

Recent improvements

The new design for VisualEditor aligns with MediaWiki's Front-End Standards as led by the Design team. Several new versions of the OOjs UI library have also been released, and these also affect the appearance of VisualEditor and other MediaWiki software extensions. Most changes were minor, like changing the text size and the amount of white space in some windows. Buttons are consistently color-coded to indicate whether the action:

• starts a new task, like opening the ⧼visualeditor-toolbar-savedialog⧽ dialog: blue ,
• takes a constructive action, like inserting a citation: green ,
• might remove or lose your work, like removing a link: red , or
• is neutral, like opening a link in a new browser window: gray .

The TemplateData editor has been completely re-written to use a different design based on the same OOjs UI system as VisualEditor. (T67815, T73746.) This change fixed a couple of existing bugs and improved usability. (T73077, T73078.)

Search and replace in long documents is now faster. It does not highlight every occurrence if there are more than 100 on-screen at once.(T78234.)

Editors at the Hebrew and Russian Wikipedia requested the ability to use VisualEditor in the "Article Incubator" or drafts namespace. (T86688, T87027.) If your community would like VisualEditor enabled on another namespace on your wiki, then you can file a request in Phabricator. Please include a link to a community discussion about the requested change.

Looking ahead

The Editing team will soon add auto-fill features for citations. The Citoid service takes a URL or DOI for a reliable source, and returns a pre-filled, pre-formatted bibliographic citation. After creating it, you will be able to change or add information to the citation, in the same way that you edit any other pre-existing citation in VisualEditor. Support for ISBNs, PMIDs, and other identifiers is planned. Later, editors will be able to contribute to the Citoid service's definitions for each website, to improve precision and reduce the need for manual corrections.

We will need editors to help test the new design of the special character inserter, especially if you speak Welsh, Breton, or another language that uses diacritics or special characters extensively. The new version should be available for testing next week. Please contact User:Whatamidoing (WMF) if you would like to be notified when the new version is available. After the special character tool is completed, VisualEditor will be deployed to all users at Phase 5 Wikipedias. This will affect about 50 mid-size and smaller Wikipedias, including Afrikaans, Azerbaijani, Breton, Kyrgyz, Macedonian, Mongolian, Tatar, and Welsh. The date for this change has not been determined.

Let's work together

• Share your ideas and ask questions at mw:VisualEditor/Feedback.
• Please help complete translations of the user guide for users who speak your language.
• Join the weekly bug triage meetings beginning Wednesday, 11 February 2015 at 12:00 (noon) PST (20:00 UTC); information about how to join the meeting will be posted at mw:Talk:VisualEditor/Portal shortly before the meeting begins, and you can also contact James F. to learn more about this initiative.
• Talk to the Editing team during the office hours via IRC. The next session is on Thursday, 19 February 2015 at 19:00 UTC.
• Subscribe or unsubscribe at Meta. If you would like to help with translations of this newsletter, please subscribe to the Translators mailing list or contact us directly, so that we can notify you when the next issue is ready. Thank you!

— Elitre (WMF)

18:30, 5 February 2015 (UTC)

Listing editor flickering

Swept in from the pub

Since about a week, whenever I edit a listing and move the mouse to the Description field, the dialog's size changes, and the field moves a bit, making it impossible to actually click inside the field. I have to click a field before and then use Tab to reach it. Anyone having the same problem? Could it be due to the recent font size change? Firefox 35.0.1 on Ubuntu Linux. Nicolas1981 (talk) 09:05, 12 February 2015 (UTC)

The timing matches the font size changes. I'll take some time after work to see if I can reproduce and find a fix. Are there any other problems? -- Ryan • (talk) • 15:25, 12 February 2015 (UTC)

I just tried editing a few listings in the Culver City article using Firefox 35.0.1 on Ubuntu, but didn't encounter any issues. Is there a specific listing you're trying to edit that is causing this behavior? If you're seeing it everywhere, can you upload a screenshot, or something else that might help to narrow down the problem? -- Ryan • (talk) • 16:20, 12 February 2015 (UTC)

It happens for every article. I will try to take a video, probably not before e few days though. Nicolas1981 (talk) 10:42, 13 February 2015 (UTC)

Update coming: global user pages

Swept in from the pub

Per m:Tech/News/2015/08, it looks like starting tomorrow, if you have a user page at meta:, that user page will be displayed on all Mediawiki wikis unless you have created a local user page - read more at mw:Help:Extension:GlobalUserPage. The concept seems to be similar to how images work now - [[File:SomeImage.jpg]] will load the version from commons unless a local file with the same name exists. The new global user page functionality should be a useful feature for everyone whose home wiki isn't envoy, although I expect we should be ready for a lot of deletion requests for local user pages once this feature goes live. -- Ryan • (talk) • 18:28, 16 February 2015 (UTC)

It's possible that Pathoschild may be running his bot to delete pages on user request, since otherwise people would have to request deletion across 800+ wikis. --Rschen7754 04:46, 17 February 2015 (UTC)

Thanks for pointing this out, Ryan. I had completely forgot I had a meta user page. It gave me a chance to fix some outdated links. -Shaundd (talk) 04:47, 17 February 2015 (UTC)

Bulleted points look weird in Safari

Swept in from the pub

Click to enlarge

Since more than 24 hours, bulleted points on WV articles look weird in the Safari browser. The point has shrunk and moved to the left and down. Another odd thing is that they look normal when using Firefox. Anyone else (Mac or iOS users, obviously) seeing this? ϒpsilon (talk) 18:26, 26 February 2015 (UTC)

I don't see any problem using Chrome, but the issue you're seeing may be a CSS bug in the latest Mediawiki release (mw:ediaWiki_1.25/wmf18), which was pushed yesterday per meta:Tech/News/2015/09. Someone else may know where to go to check and see if there is an existing bug report. -- Ryan • (talk) • 19:02, 26 February 2015 (UTC)

Just to confirm, yes I see the same thing with Safari on Yosemite. (I also just use Chrome as my default browser) --Andrewssi2 (talk) 20:33, 26 February 2015 (UTC)

Me, too Safari. Having same issue since yesterday afternoon. --Saqib (talk) 12:51, 27 February 2015 (UTC)

No data dump since last year

Swept in from the pub

Data dumps used to get generated every 2 weeks, but since July 2014 the frequency has started to fall down dramatically. Currently, the last dump is from 42 days ago. I am a bit sad as I have improved/added a lot of content recently while preparing my trip, and I won't be able to benefit from it using Kiwix/OxygenGuide/OsmAnd offline tools. Data dumps are one of the reasons why we forked from WT.

Any idea why? Is it inevitable, and if not where I should ask for the frequency to be restored to about a dump every 2 weeks? Cheers! Nicolas1981 (talk) 03:49, 5 February 2015 (UTC)

I guess someone on Wikimedia would be better placed to answer your question, since we at WV don't (I believe) have any control over this process.

That said, monthly data dumps seem like an OK frequency to me, although I wonder where January 2015 went to. --Andrewssi2 (talk) 04:34, 5 February 2015 (UTC)

I know that, currently (within the past month) we've had some issues with the dumps servers which may be why but I will poke ops to see what the issues are with the wikivoyage dumps in general as well. Jalexander-WMF (talk) 20:48, 5 February 2015 (UTC)

A new dump has just appeared, right in time before my trip tomorrow :-D Nicolas1981 (talk) 04:59, 20 February 2015 (UTC)

Hi, as a side information, I just wanted to inform you that new ZIM files of Wikivoyage are now released one time a month - and this is independent of the XML data dumps. Regards Kelson (talk) 13:37, 5 March 2015 (UTC)

Database of embassies and consulates

Swept in from the pub

Dear all,

I just wrote a script to extract embassies/consulates data from Wikivoyage. Download the CSV file here, 4480 entries, 800 KB. I did this because a student asked me for this database for a thesis, but we can also use it ourselves, in particular to complete our data, as many consulates are missing from Wikivoyage. People interested in making this data more complete are invited to check this project, and complete either manually (many countries list their list of embassies) or by script (from other open data sources).

By the way, I also updated the extracted listings database and OxygenGuide. Cheers! Nicolas1981 (talk) 03:59, 3 March 2015 (UTC)

This is a great thing to ad to WV! I would however caution that since this is not an official source, all listings should be verified (i.e. visit the embassy's website/foreign ministry website) before entry into WV. --Andrewssi2 (talk) 20:22, 5 March 2015 (UTC)

Useful stuff. The wider we can make the content we cover the better. It is always a pain figuring out were the consulates are. Travel Doc James (talk · contribs · email) 17:01, 7 March 2015 (UTC)

Something strange with section titles

Swept in from the pub

I can't see section titles here (travellers' pub) anymore... is it just me? Nicolas1981 (talk) 01:59, 4 March 2015 (UTC)

And now I can see them... even though I refreshed to check before posting this... strange. Nicolas1981 (talk) 02:00, 4 March 2015 (UTC)

There is definitely something strange with section titles... now the § symbol (which is usually present at the left of each section when hovering, to facilitate deep linking, see "HeadAnchor" preference) is superimposed over the first character of the section title, instead of showing up at its left. Nicolas1981 (talk) 06:11, 4 March 2015 (UTC)

Maybe it is your OS or your browser doing strange things? Hobbitschuster (talk) 15:16, 4 March 2015 (UTC)

Could be! I am using Ubuntu, it happens on Firefox but not on Chromium. Nicolas1981 (talk) 02:29, 5 March 2015 (UTC)

Firefox looks normal here (pir8 copy of Ubuntu 14), haven't noticed anything out of the ordinary. K7L (talk) 04:00, 5 March 2015 (UTC)

Section titles disappeared again, this time in article space: Screenshot. I haven't changed anything in my Firefox (35.0.1 on Ubuntu 2014.04) recently, and this started happening yesterday. Nicolas1981 (talk) 04:06, 5 March 2015 (UTC)

I use Lubuntu (Ubuntu with a lightweight window manager) and Firefox. Both are updated fairly often. Section titles almost always look fine. Once in a blue moon I get something like your screenshot, usually when the system is heavily loaded. Reloading the page fixes it. Pashley (talk) 03:04, 6 March 2015 (UTC)

Exact same problem with Chromium. Section titles never show on any article. When I log out, they show up. So something is wrong with my Wikivoyage account. Nicolas1981 (talk) 04:39, 26 March 2015 (UTC)

Disabling HeadAnchor in Preferences>Gadgets fixed the problem. Nicolas1981 (talk) 04:42, 26 March 2015 (UTC)

Error: API returned error code "badtoken": Invalid token

Swept in from the pub

I get this error several times per week, and each time it means I loose 1 to 10 minutes of work. It happens when working on an article whose page was already open in the browser. I try to think to refresh the browser before doing any edition, but despite this I sometimes forget. I imagine many new users get frustrated about this too, especially if they don't understand the HTTP technicalities.

We need to fix this. If the request fails, we should acquire a new token and try again. At all we should not make the editor's precious content disappear. Thanks! Nicolas1981 (talk) 01:45, 9 March 2015 (UTC)

I have no idea if it will fix the problem, but it shouldn't make it worse - this change is completely untested but should hopefully at least give you the option to get your changes back in the case of a failure. If you encounter the problem again please provide any feedback as to whether this change actually restores the listing editor (with your changes in it), whether resubmitting works, etc. -- Ryan • (talk) • 03:32, 9 March 2015 (UTC)

Has anyone else been having this kind of problem? Nicolas1981, is there anything unusual about your computer/browser/account/preferences/internet connection that you think might cause this? WhatamIdoing (talk) 18:39, 9 March 2015 (UTC)

Nothing unusual. I sometimes change from a WiFi to another, but I wouldn't consider this unusual. It happens very often: just let an article open for a day or two, go back to it, click "edit" to get the listing editor, and it will happen. Nicolas1981 (talk) 07:05, 10 March 2015 (UTC)

That is completely expected behavior given that tokens should expire in about an hour. Legoktm (talk) 22:51, 10 March 2015 (UTC)

Hi, you should use mw.Api#postWithToken which automatically handles these kinds of issues. Legoktm (talk) 18:49, 9 March 2015 (UTC)

By "you", I'm pretty sure the Lego means "whatever gadgets you're using". WhatamIdoing (talk) 00:48, 13 March 2015 (UTC)

Pagebanner extension for Wikivoyage

Swept in from the pub

Tracked in Phabricator ^(?)
Task T77925

Hi all, I'm a mediawiki contriutor and there's a discussion on a project for developing the functionality provided by the pagebanner template into an extension here, with a purpose to make the banners render well on mobile in addition to desktop, as well as solve any size issues arising in any browser. It would be great to get feedback as well as if someone could help along, in providing valuable suggestions as to the look and feel of the banners in the new extension as the project progresses. Comments on the phabricator task are welcome. Looking forward to your help and support. Thank you! --Sumit.iitp (talk) 05:40, 15 March 2015 (UTC)

I suggested this in the phabricator ticket already, but I think the place to start on this task is creating a set of requirements - I'm in favor of cleaning up the banner code, but it's still not clear to me what advantages the extension is going to offer, what the trade-offs might be, etc. -- Ryan • (talk) • 06:13, 15 March 2015 (UTC)

The banners have been a huge improvement, but the change also caused some problems; we did not reach consensus on a solution. My preferred fix might only be possible with help from Mediawiki developers. Please have a look at these issues while planning any extension. Pashley (talk) 09:18, 15 March 2015 (UTC)

Dhivehi text not rendering on Mac OS

Swept in from the pub

I noticed that the Dhivehi text for Maldives does not render on my MacBook. I tried with native Safari, Chrome and Firefox browsers and none of them work. Windows on the other hand has no problem.

Where is the best place to raise this issue? --Andrewssi2 (talk) 02:49, 8 April 2015 (UTC)

[7]. The instructions there seem to be for Lion or something, System Preferences doesn't seem to have any input sources box in Yosemite. Nevertheless, download the package from the link, open and install it. I just did and it works well in Safari and Firefox. ϒpsilon (talk) 12:04, 8 April 2015 (UTC)

VisualEditor News #2—2015

Swept in from the pub

Did you know?

With Citoid in VisualEditor, you click the 'book with bookmark' icon and paste in the URL for a reliable source:

Citoid looks up the source for you and returns the citation results. Click the green "Insert" button to accept its results and add them to the article:

After inserting the citation, you can change it. Select the reference, and click the "Edit" button in the context menu to make changes.

The user guide has more information about how to use VisualEditor.

Since the last newsletter, the Editing Team has fixed many bugs and worked on VisualEditor's performance, the Citoid reference service, and support for languages with complex input requirements. Status reports are posted on Mediawiki.org. The worklist for April through June is available in Phabricator.

The weekly task triage meetings continue to be open to volunteers, each Wednesday at 11:00 (noon) PDT (18:00 UTC). You do not need to attend the meeting to nominate a bug for consideration as a Q4 blocker. Instead, go to Phabricator and "associate" the Editing team's Q4 blocker project with the bug. Learn how to join the meetings and how to nominate bugs at mw:Talk:VisualEditor/Portal.

Recent improvements

VisualEditor is now substantially faster. In many cases, opening the page in VisualEditor is now faster than opening it in the wikitext editor. The new system has improved the code speed by 37% and network speed by almost 40%.

The Editing team is slowly adding auto-fill features for citations. This is currently available only at the French, Italian, and English Wikipedias. The Citoid service takes a URL or DOI for a reliable source, and returns a pre-filled, pre-formatted bibliographic citation. After creating it, you will be able to change or add information to the citation, in the same way that you edit any other pre-existing citation in VisualEditor. Support for ISBNs, PMIDs, and other identifiers is planned. Later, editors will be able to improve precision and reduce the need for manual corrections by contributing to the Citoid service's definitions for each website.

Citoid requires good TemplateData for your citation templates. If you would like to request this feature for your wiki, please post a request in the Citoid project on Phabricator. Include links to the TemplateData for the most important citation templates on your wiki.

The special character inserter has been improved, based upon feedback from active users. After this, VisualEditor was made available to all users of Wikipedias on the Phase 5 list on 30 March. This affected 53 mid-size and smaller Wikipedias, including Afrikaans, Azerbaijani, Breton, Kyrgyz, Macedonian, Mongolian, Tatar, and Welsh.

Work continues to support languages with complex requirements, such as Korean and Japanese. These languages use input method editors ("IMEs”). Recent improvements to cursoring, backspace, and delete behavior will simplify typing in VisualEditor for these users.

The design for the image selection process is now using a "masonry fit" model. Images in the search results are displayed at the same height but at variable widths, similar to bricks of different sizes in a masonry wall, or the "packed" mode in image galleries. This style helps you find the right image by making it easier to see more details in images.

You can now drag and drop categories to re-arrange their order of appearance ​on the page.

The pop-up window that appears when you click on a reference, image, link, or other element, is called the "context menu". It now displays additional useful information, such as the destination of the link or the image's filename. The team has also added an explicit "Edit" button in the context menu, which helps new editors open the tool to change the item.

Invisible templates are marked by a puzzle piece icon so they can be interacted with. Users also will be able to see and edit HTML anchors now in section headings.

Users of the TemplateData GUI editor can now set a string as an optional text for the 'deprecated' property in addition to boolean value, which lets you tell users of the template what they should do instead. (T90734)

Looking ahead

The special character inserter in VisualEditor will soon use the same special character list as the wikitext editor. Admins at each wiki will also have the option of creating a custom section for frequently used characters at the top of the list. Instructions for customizing the list will be posted at mediawiki.org.

The team is discussing a test of VisualEditor with new users at the English Wikipedia, to see whether they have met their goals of making VisualEditor suitable for those editors. The timing is unknown, but might be relatively soon. (T90666)

Let's work together

• Share your ideas and ask questions at mw:VisualEditor/Feedback.
• Can you translate from English into any other language? Please check this list to see whether more interface translations are needed for your language. Contact us to get an account if you want to help!
• The design research team wants to see how real editors work. Please sign up for their research program.
• File requests for language-appropriate "Bold" and "Italic" icons for the character formatting menu in Phabricator.

Subscribe, unsubscribe or change the page where this newsletter is delivered at Meta. If you aren't reading this in your favorite language, then please help us with translations! Subscribe to the Translators mailing list or contact us directly, so that we can notify you when the next issue is ready. Thank you!

— Elitre (WMF)

19:48, 10 April 2015 (UTC)

Installing Gather on Wikivoyage

Swept in from the pub

Tracked in Phabricator ^(?)
Task T97488

My team has been working on a feature which we think would be highly useful on Wikivoyage and we'd really like to install it on your project as we think you are a community who can really help us grow it into what we think will be an amazing feature for all Wikimedia projects. It's called "Gather" and it allows users to collect personal lists of pages. We hope this will lead to increased engagement in our project, drawing attention to articles and then hopefully leading to more readers/editors.

In future we want this to do so much more, for example to support collaborative list editing, provide different views on lists e.g. watch edits on lists (a la Watchlist)... (feel free to check out our backlog.

As a travel addict, I can see lots of uses for your projects - here are some travel themed lists I have written for example:

• https://en.m.wikipedia.org/wiki/Special:Gather/by/Jdlrobson/23
• https://en.m.wikipedia.org/wiki/Special:Gather/by/Jdlrobson/657

If installed it could be available on mobile and via desktop via a beta feature. Thoughts? Questions? Jon (WMF) (talk) 19:56, 16 April 2015 (UTC)

cc. User:Melamrawy (WMF) User:Diablanco User:jdlrobson

There's no downside to installing this extension, right? It's just another bit of functionality for users who might want to use it, and is invisible to everyone else? If so I'd say go ahead and install it so that those who want this type of functionality have it available, although personally I'm not sure that it would be something I would be likely to use. -- Ryan • (talk) • 20:35, 16 April 2015 (UTC)

I'll second that. I might not use it personally but it couldn't hurt as a beta feature, so I'd also say go ahead. Texugo (talk) 20:43, 16 April 2015 (UTC)

Fine by me. It'd be nice to be able to tie it into the books extension, to make it easy to print books using a Gathered list of articles. Powers ^(talk) 19:18, 17 April 2015 (UTC)

Sounds very useful, when preparing a trip I usually have a collection of relevant articles open in browser tabs. Any tool would be more convenient, especially if the same list is accessible on mobile. Cheers! Syced (talk) 08:22, 21 April 2015 (UTC)

Ryan, it's not entirely invisible to everyone else. Jon just gave you links that let you see his lists, so someone could share a list on Facebook or something. But it doesn't change anything in the articles or anything like that. It's just a list of links and has no effect on the mainspace (except possibly increase page views). WhatamIdoing (talk) 21:22, 25 April 2015 (UTC)

Ryan, Texugo, Powers, Syced, I wanted to give you guys a heads-up on this. The downside is that these are publicly viewable, it is directly targeted for use and public sharing by non-editors, it has a text field and people can and do create abusive Collections (such as attacking people they hate), they need to be patrolled for legal violations or abuses. It has no real use-case for editors because it's simpler and more flexible to just link article titles in wikitext. It has been heatedly rejected at Wikipedia Wikipedia Administrators'_noticeboard#Moderation_of_Collections and other scattered discussions. WMF staff don't even respond to requests for WMF-Community discussion on whether it should be turned off. I have no edits on Voyage, so I'll leave it to you guys here. I just wanted you guys to know that this isn't "invisible". Alsee (talk) 11:54, 12 May 2015 (UTC)

"Locate!" search box in "Map of all articles"

At https://tools.wmflabs.org/wikivoyage/w/artmap.php?lang=en there seems to be a new search box, which is a wonderful idea :-)

It does not seem to work either with the Enter key nor by pushing the button, though... is it being developed right now, or is it a bug with Firefox/Linux? Syced (talk) 08:52, 21 April 2015 (UTC)

The reason is again the WMFLabs server. The response times are too long. Mixed active content (http: / https:) is blocked on WMFLabs server. Please wait for the next update in a few days. On the German WVeV server (http:) http://maps.wikivoyage-ev.org/w/artmap.php?lang=en everything is in order. -- Joachim Mey2008 (talk) 13:20, 21 April 2015 (UTC)

Update is done. Search function now also works with the https: protocol. -- Joachim Mey2008 (talk) 12:03, 23 April 2015 (UTC)

Localization

I didn't know there was an interactive map which is automatically updated at https://tools.wmflabs.org/wikivoyage/w/artmap.php?lang=he for HebVoy. From which prominent page/s at the English Wikivoyage is/are there link/s to this awesome map. (I want to created links to that page from similar pages on HebVoy).

See http://en.wikivoyage.org/wiki/Destinations . You can put it in a mapframe too: {{mapframe|25|6|zoom=1|layer=E|width=600|align=none}}. - The map is updated monthly and used the data dumps. -- Joachim Mey2008 (talk) 13:50, 21 April 2015 (UTC)

I added the interactive map to the parallel page in HebVoy. Although it works, there are two apparent annoying bugs bugs I haven't figured out how to solve yet :

• In the caption of the map window I get a red notice saying it is missing the unit "BASICPAGENAME". (See link).
• The search button says "Locate!" instead of
  "חפש!"
  .

ויקיג'אנקי (talk) 14:41, 21 April 2015 (UTC)

The localization for all 17 language versions is still an unsolved problem. The text output come from different modules were written by external authors. The implementation is complex. - This will take time, I suspect. - Joachim Mey2008 (talk) 18:07, 21 April 2015 (UTC)

Selection of images

Another question... how do I modify the {{geo}} syntax so that I would be able to determine which pictures are presented for each destination at https://tools.wmflabs.org/wikivoyage/w/artmap.php?lang=he  ? ויקיג'אנקי (talk) 13:03, 21 April 2015 (UTC)

Currently will be selected, the first best image with .jpg extension. A control by the Geo template is not possible at this time. But the idea is good and is now on my to-do list. -- Joachim Mey2008 (talk) 14:13, 21 April 2015 (UTC)

Mobile usability

Swept in from the pub

Hi. There is currently a discussion at de-WV about implementing banners and one of the argument against them was that banners as used on en-WV don't look good on mobile devices and make the page less usable. One of the arguments over there was that in light of rising numbers of smartphones in use globally, WV should aim to include only those innovations that work on mobile devices as well. What are your thoughts on that? How should we deal with mobile devices? And what about our banners? (I think they're fine). Best wishes Hobbitschuster (talk) 22:17, 7 May 2015 (UTC)

Wouldn't it be relatively simple to disable the pagebanner template for mobile pages? Texugo (talk) 22:18, 7 May 2015 (UTC)

Presumably the effort underway to turn the banners into a proper MediaWiki extension will address mobile use. But I should think disabling them on mobile devices would be a useful interim solution. Powers ^(talk) 23:42, 7 May 2015 (UTC)

How would that affect the table of contents that is currently included in the banner if I am not mistaken? Hobbitschuster (talk) 23:50, 7 May 2015 (UTC)

If it banner template disabled itself on mobile, I presume the TOC would display the same way as a non-bannered page does. Texugo (talk) 01:10, 8 May 2015 (UTC)

When the banner were first introduced, I believe they were turned off on mobile because they didn't work well. At some point they came back -- I've always assumed its because the mobile team turned banners back on because it behaves differently on mobile than desktop, but I don't know for sure.

As to the TOC, it doesn't appear in mobile view. The banner appears but the TOC is the traditional vertical Wikemedia style... at least on my Android phone and tablet. -172.218.40.145 06:05, 8 May 2015 (UTC) (Shaundd)

Actually there is a known feature where Banners for high definition displays (such as MacBook Retinas) produce a larger image for the Banner than a standard display. This becomes problematic for mobile phones, since even mid-range models now also have high definition displays as well. This is a download performance problem rather than a style issue.

We also have a problem that some other language wiki's have an irrational belief that banners download the original size of the image hosted on WikiMedia (this is false - images are scaled before downloading)

Can you link to the German Wikivoyage discussion on this? "Banners don't look good" on mobile doesn't match my experience. --Andrewssi2 (talk) 10:47, 8 May 2015 (UTC)

Well the discussion in de-WV is spread over several areas... let's see.... my talk page, Their pub, and here. I have not been following the debate all that intensely lately as some of the objections appear to make little sense to me or rather I am not knowledgeable enough to say anything of substance regarding them. Hobbitschuster (talk) 11:30, 8 May 2015 (UTC)

One night in Bangkok makes the hard man humble

Based on your talk page it seems they have a point. Looking at the Bangkok article on my iPhone 6 in Desktop mode the banner looks OK (not perfect)

However in Mobile mode it does look something like that screenshot. We need to separate the strange transparent edit overlay from the Banner in Mobile view and then it should be fine again.

Some people like DerFussi do concern mobile roaming charges a lot, although I don't agree that should be the base and overriding concern for our content --Andrewssi2 (talk) 12:05, 8 May 2015 (UTC)

"Some other language wiki's have an irrational belief that banners download the original size of the image hosted on WikiMedia (this is false - images are scaled before downloading)"? I disagree. The image is scaled, at least in the desktop version, to an 1800px wide "thumbnail" - even on a screen that isn't 1800px wide. Any further downscaling only takes place in the browser, after the bandwidth cost has already been incurred. K7L (talk) 12:58, 8 May 2015 (UTC)

Disagree if you like. If you check the resolution size of the banners actually downloaded it will be 1800 pixels wide on standard screens and 3600 pixels with on high definition screens. --Andrewssi2 (talk) 04:38, 9 May 2015 (UTC)

So how do we fix this? Hobbitschuster (talk) 13:13, 8 May 2015 (UTC)

See https://en.wikivoyage.org/w/index.php?title=Wikivoyage:Travellers%27_pub&oldid=2782789#Table_of_contents above

We can fix through editing the Mobile template.. an area I haven't looked at yet. Maybe now is the time. --Andrewssi2 (talk) 04:40, 9 May 2015 (UTC)

Other mobile issues

What about other mobile issues? e.g. How do maps work on mobile devices? And has the original issue of banners been addressed? Hobbitschuster (talk) 19:10, 11 May 2015 (UTC)

Wikidata: Access to data from arbitrary items is coming

Swept in from the pub

(Sorry for writing in English)

When using data from Wikidata on Wikipedia and other sister projects, there is currently a limitation in place that hinders some use cases: data can only be accessed from the corresponding item. So, for example, the Wikipedia article about Berlin can only get data from the Wikidata item about Berlin but not from the item about Germany. This had technical reasons. We are now removing this limitation. It is already done for French Wikisource and Dutch Wikipedia. Your project is one of the next ones:

• 18. May: Farsi Wikipedia, English Wikivoyage, Hebrew Wikipedia
• 1. June: Italian Wikipedia, all remaining Wikisource

We hope to have it rolled out nearly everywhere by the end of June 2015.

We invite you to play around with this new feature if you are one of the people who have been waiting for this for a long time. If you have technical issues/questions with this you can come to d:Wikidata:Contact the development team.

A note of caution: Please be careful with how many items you use for a single page. If it is too many pages, loading might get slow. We will have to see how the feature behaves in production to see where we need to tweak and how.

How to use it, once it is enabled:

• Parser function: {{#property:P36|from=Q183}} to get the capital from the item about Germany
• Lua: see mw:Extension:Wikibase Client/Lua

Cheers Lydia Pintscher 15:19, 13 May 2015 (UTC)

So what are the consequences if we add an extra field to the {{listing}} template, something like {{see| name=Musée du Louvre | address=Place du Carrousel | lat=48.86106 | long=2.33562 | directions=Métro: Louvre | phone=+33 1 40-20-53-17 | wikidata=Q19675 }}? Would pulling any Wikidata information for an individual venue slow the servers too much? K7L (talk) 17:50, 13 May 2015 (UTC)

That sounds like tempting server slowdown, according to what Lydia just said, since that template is used dozens of times on many pages. Texugo (talk) 18:43, 13 May 2015 (UTC)

True, though the number of listings with Wikidata entries is currently small for most destinations. In theory, though, someday, there could be an entry for every single one. Powers ^(talk) 18:55, 13 May 2015 (UTC)

Wonderful!!! Now listings collaboration can really become a reality. There is still a lot of effort ahead, but we should definitely start experimenting on a particular article. I see the following tasks:

• Identify what Wikidata properties we can reuse as listing properties (ex: latitude longitude URL etc)
• Define new Wikidata properties if there is no match yet
• Make the templates use these properties if a Wikidata identifier is specified
• Make the listing editor read/from from Wikidata if a Wikidata identifier is specified. Should work on mobile too, as editing these properties in wikicode (source) will become impossible
• Long-term: For properties that contain human language (like description or price), I suggest doing nothing for now, and when we have more experience, see whether using Wikidata for that too would bring us any benefit
• Long-term: Create a Wikidata property like "See Listings" in "Timbuktu". While big Wikivoyages might not use it, smaller Wikivoyages might want to just write something like "==Eat=={{wikidata_eat}} ==Drink=={{wikidata_drink}}" to get started. In that case, localized description would probably have to be stored on Wikidata too.

Cheers! Syced (talk) 03:46, 14 May 2015 (UTC)

Taking coordinates from Wikidata may not be practical because this will largely complicate the scripts for dynamic maps and any similar applications. There are only two easy thing to retrieve, the web-link and image. One could also retrieve links to Wikipedia and Commons if they are needed. Transferring phone numbers to Wikidata may be possible. However, the most important thing is also the most difficult one. The synchronization of web-links and images is by far less important than the synchronization of opening times and prices, so the whole thing is about these fields, not about anything else, which is rather unimportant (recall the template for opening hours; this is one place where it becomes extremely useful).

And question number one is: how to connect listings in different language versions? How to connect listings to existing Wikidata items? Some language versions have been adding links to Wikipedia or Wikidata IDs since years, so things are more or less prepared, and integration with Wikidata can start immediately. But English Wikivoyage has never tried this, and it will take a while before listings are ready for integration. --Alexander (talk) 06:19, 14 May 2015 (UTC)

I agree for opening hours: A few months ago I suggested using the standard format that other Wikivoyages are using, but it had been decided against because it is less readable for humans without a graphical user interface. With inter-language listing collaboration now a reality, it might be time to reconsider the question :-) As for your question number one: Yes the English Wikivoyage is being Wikivoyages that have Wikipedia links, but anyway it is time to get started! I have added a "wikidata" property to the listings template, and I added the wikidata property to all listings of the See section of Tokyo/Roppongi. Let's use that page as a prototype to see how Wikidata fares performance-wise. Cheers! Syced (talk) 07:52, 14 May 2015 (UTC)

Musings

• Overcoming the limitation of working with the current page is a definite plus when accessing Wikidata using Lua....
• List of Wikidata properties in French - I remember there was a list of properties in English but can't seem to find it now.
• The current Module:wikibase can be used to obtain a limited number of properties such as lat/long/capital etc. (can easily add banner as well). Would it not then be reasonable to beef that module or another to perform future work?
• I am under the impression that one would use a parser function {{#property:P36|from=Q183}} rather than calling a Lua Module directly {{#invoke:xxxxxxx|P36|from=Q183}}. One would still have to know the ID in order for either to work? Would then a call be needed to a Lua module to get the ID in the first place? .... {{#property:P36|from=Germany}} (Let process find the ID?) - Also would have to know the property (P numbers)
• To get more than one data element probably would be easier to do with a single call to a Lua module.
• Doing a quickbar or some infobox would also be rather simple though.
• There may be an issue with timing and page parsing. (ie. numbering of listings and when that occurs - before or after you get the lat/long from Wikidata).
• Putting listing information into Wikidata is an admirable idea; however, I am not as optimistic when it comes to sorting, updating, editing, duplicate names and parsing etc.
• More to consider - All the best! ... Matroc (talk) 06:13, 14 May 2015 (UTC)

What about editing of listings with some entries from Wikidata (as long as the information on Wikidata is correct and up to date, there is no problem – those in the know can handle it, for others it's just magic), by the listing editor or by hand?

If what you see is just the item/property code, then you can probably replace it with correct information, but often you want to correct just part of it, you would prefer to have the current version available for editing.

And, of course, in most cases the edit should be done to the Wikidata object. Directing a random user to Wikidata (as is now done for iw-links) is very confusing. In some cases the information is correct, but corresponds to something other than what the listing is supposed to be about. We rely on random users much more than Wikipedia, especially regarding the listings.

--LPfi (talk) 08:32, 14 May 2015 (UTC)

Opening Hours

What is the proposed universal format of opening hours? I can see that as being a problem, considering the different ways hours are represented in French, Italian, and in English in different parts of the world. Ikan Kekek (talk) 09:17, 14 May 2015 (UTC)

Here is the hours format used by the French Wikivoyage. Day names are of course translated, see for instance the same format in Russian. Syced (talk) 11:10, 14 May 2015 (UTC)

I listed what we might be able to reuse, property-by-property. Needless to see, feel free to edit :-) Syced (talk) 11:10, 14 May 2015 (UTC)

Also consider that hours are not only different between languages, but they differ in complexity from establishment to establishment, with different days open, different holidays, some open only seasonally, etc. Some have the same hours each day, others have different hours on different days, and some with two (or occasionally even three) shifts per day, such as restaurants with separate breakfast/lunch/dinner hours. A WD element truly capable of holding all the information we need would probably have to be at least a 7-by-3 array of start/end-time pairs plus some additional way to handle the bits on seasonality and holidays, etc. Then, on the WV side, we would need a very smart template that would be able to read that info and collapse it to remove the redundancy, so that we can still say "Tu-Th 11AM-3PM and 6PM-11PM; Fr, Su 11AM-3PM and 6PM-1AM; Sa and holidays 11AM-1AM, closed Mondays" instead of taking 3-4 times as much space to list each day of the week separately, one after the other with its respective hours. Then, on top of all that complexity, it would have to be able to do all that in the various languages. Texugo (talk) 12:35, 14 May 2015 (UTC)

A restaurant might also have a bar which stays open into the wee hours, even though the kitchen closes early in the evening. Our "just list it once" policy for mixed entities like a hotel (sleep) with a restaurant (eat) that has a bar (drink) on a golf course (do) will make a mess when this bundle of related businesses on the same site each keeps different hours. K7L (talk) 13:54, 14 May 2015 (UTC)

That's another good point. Similarly shopping centers sometimes have different hours from their food courts, etc. Texugo (talk) 14:04, 14 May 2015 (UTC)

You need exactly one string to code whatever you want about working hours. For example, 109002000_20900200_309002000_409002000_509002000_609001700_7 would mean Mo-Fr 9-20, Sa 9-17, Su closed. Then you will also need to teach listing editor how to transform these numbers into human-readable templates, and you will need something like {{hours}} for the final display in the text. Months or seasons are trivial as well. When there are two different objects within one listing, you will need two strings with standard (and translated into different languages) identifiers such as 'restaurant', 'bar', or 'food-court'. Wikidata people may come up with other ideas, but even this "one-string-based" is the working solution that relies on the existing functionality of Wikidata only.

Of course, it is possible that one listing out of 1000 will have something very special. This listing can stay intact, while 99.9% other listings can be converted to standard format and shared on Wikidata, which would be a big step forward.

This is nothing but a very straight-forward coding. As I mentioned, the most difficult task is not this one, but finding connections between listings in different language versions and identifying existing Wikidata items where some of these listings belong. This requires joint effort of all editors who should understand what is going on and why it is needed. And this may be difficult to achieve. --Alexander (talk) 15:41, 14 May 2015 (UTC)

So how do I represent "Open weekends only from Victoria Day to Dominion Day, open daily from July 1 to Labour Day, then open when we feel like it until Thanksgiving. Closed for the winter, except for New Year's Eve and Winterlude, and if we're bored we usually go home early on Easter Sunday"? SnowBound DriveIn's showings of "Closed for the Winter" tend to be very seasonal; campgrounds, waterparks and tourism venues staffed by summer students are just as bad or worse. K7L (talk) 15:56, 14 May 2015 (UTC)

I am sorry, but the majority of things are not like that, even in US and Canada. I said that we would likely end up with 0.1% exceptions. Even we have 1% of those, it does not matter. I created thousands of listings for different European countries, and I never ever wrote descriptions like the one you quoted. They all follow the bloody simple month-day-time scheme.

If "closed for the winter" has no particular definition of winter, this could be a standard string as well. --Alexander (talk) 16:02, 14 May 2015 (UTC)

(edit conflict) I would also venture that your single string is not capable of encoding my above example of Tu-Th 11AM-3PM and 6PM-11PM; Fr, Su 11AM-3PM and 6PM-1AM; Sa and holidays 11AM-1AM, closed Mondays. And that example is not extreme in any way - loads of restaurant have stuff like this. It's not just some 0.1% or even 1%. Texugo (talk) 16:04, 14 May 2015 (UTC)

With a bit of creativity you will easily understand how to encode these working hours into a single string. Several time slots per day are abolutely no problem if your interpreter (Listing editor) takes this possibility into account. --Alexander (talk) 16:28, 14 May 2015 (UTC)

I know it's easily possible to fit the information in a single string, although it would need be at least 3 times as long as yours to include the necessary minimum of possibilities for even single-entity restaurants. But the structure of the storage codification is not really what I was concerned about - the challenge would be to craft:

• an interface that makes that complex code easily editable without learning a complex syntax and without precluding common possibilities, but also without forcing someone to enter 8:00-6:00 PM seven times just to get a simple Mo-Sa and holidays 8AM-6PM; and
• a template that can take such a code and turn it back into the succinct, non-redundant form we customarily present that information in. Texugo (talk) 16:37, 14 May 2015 (UTC)

Your text can be coded by a sequence of {{hours}} templates. Tu-Th "11AM-3PM and 6PM-11PM" becomes "{{hours|Tu|Th|11|AM|3|PM}} and {{hours|||6|PM|11|PM}}" Do I have to explain how to convert this sequence into the numerical string and back? --Alexander (talk) 17:35, 14 May 2015 (UTC)

Notwithstanding the fact that your proposed "Hours" template doesn't seem to have an appropriate way to group together non-continuous days of the week (e.g. Fr and Su, etc.), that still doesn't even begin to get us there. That just gets us to the point where, in order to say

Tu-Th 11AM-3PM and 6PM-11PM; Fr, Su 11AM-3PM and 6PM-1AM; Sa and holidays 11AM-1AM, closed Mondays

we have to type

{{hours|Tu|Th|11|AM|3|PM}} and {{hours|||6|PM|11|PM}}; {{hours|Fr, Sa||11|AM|3|PM}} and {{hours|||6|PM|1|AM}}; {{hours|Sa and holidays|11|AM|1|AM}}, closed Mondays

There has to be a way to enter and edit this information that doesn't require a traveller to directly mess with all that code, and to get it stored properly in WD there would have to be further syntax to connect all that together the right way (commas, semicolons, "and", etc.), and it has to be adaptable and responsive to all the various levels of complexity common to our listings. I still think you're being a bit idealistic about this. Texugo (talk) 18:04, 14 May 2015 (UTC)

I am not an expert in programming, but I did write the codes that support the whole flow of Russian WLM and WLE competitions and sort photos in a better way than any other country does. And I can seamlessly write "further syntax to connect all that together the right way (commas, semicolons, "and", etc.)", although I can't do it with Java/Lua for the Listing editor, but the algorithm behind this (and any other) change in syntax is absolutely trivial. Regarding the input, editors must use some type of markup, one or another. They can't write whatever they want, and a magic script that converts nonsense into formatted text is hard to craft indeed.

If you prefer writing 9:00-17:00 instead of 9|00|17|00, this is certainly doable. If you are an expert in Java and Lua, I would probably trust your opinion, but if you are not, I suggest that we stop this discussion now. An algorithm for changing syntax is very simple, and any simple algorithm can be turned into a code. --Alexander (talk) 18:21, 14 May 2015 (UTC)

I am primarily suggesting that, pipes or colons, any arrangement where a user has to type that much markup every time is unacceptable. There would at the very least have to be a listing editor interface component which is both intuitive for a new user and flexible enough to handle the normal range of complexity our listings require. If you can do it, I'll be happy to see it and to be a part of the development process to the degree possible, but what I don't want to see is something that requires a significant learning curve, nor some partial solution which fails to adequately handle the full range of complexity possible. It's simply that what you have suggested so far does not to me seem to encompass all that is needed. It looks too complicated in terms of what it asks of the casual user, and too simple in terms of what kinds of hourly schedule it expects to encounter. Texugo (talk) 18:40, 14 May 2015 (UTC)

Yeah, the worst thing would be to make it complicated for people to just type hours. I hope that whatever is done doesn't make it hard to do that and ignore any codes. Ikan Kekek (talk) 18:47, 14 May 2015 (UTC)

I would like to reiterate that the easy-to-share and reusable information does not come for free. You will have to make sure that opening hours follow one and the same format wherever this format can be applied. If you do not accept this restriction, you have to accept that certain features will never be available here and, in particular, Wikivoyage will be inferior to Foursquare, Tripadvisor and other websites where opening hours are fully machine-readable, which does not prevent regular users from modifying them. --Alexander (talk) 12:11, 15 May 2015 (UTC)

Actually, on Wikidata this information will be likely stored as the (still to be proposed) property Opening Hours and the qualifiers which dnote opening/closing, day of the week and some other standartized information.--Ymblanter (talk) 10:41, 17 May 2015 (UTC)

No problem. In cases when the hours description is so complex that it can not be expressed easily under the standard format, it can be left on English Wikivoyage as human text. For properties that exist as wikicode we should just use it and not load the value from Wikidata. No need to express everything in the standard format. If Wikidata can help hours collaboration on 90% of all listings, then it is already wonderful :-) Syced (talk) 02:41, 15 May 2015 (UTC)

There is the problem of updating. If the hours stay the same, but somebody notices a weird exception, this somebody should be able to do the correction in an obvious way, which should not involve reopening the old version of the page and manually copying the entry as previously autoformatted. --LPfi (talk) 11:32, 15 May 2015 (UTC)

Weird exceptions lead to weird results. I don't understand your comment. Editors will always see something human-readable, so they can edit it and add some more human-readable text if appropriate. When the format is wrong, the information will not go to Wikidata. That's all about it. --Alexander (talk) 12:11, 15 May 2015 (UTC)

I meant "weird" as in not well supported by the user interface, i.e. something that should be entered as free text (at least by the non-savvy).

The question is about what I see when I click "edit". Do I see the plain text version, the parseable format or a reference to Wikidata? If I get the first, then OK, but an edit will easily destroy the Wikidata entry or the Wikidata coupling (as there is no hint about what formats will be parseable or correctly parsed). If I get the second (e.g. the {{hours}} template or the "simple" string discussed above), I will have to hunt for some manual page. If I get a reference to Wikidata ("wikidata=Q19675"), then there is nothing obvious to edit. If I land on Wikidata, then I am confused, as this is another site.

As usual, the problem is to come up with a robust user interface, which does not scare away casual editors. There might be some "obvious" solution I cannot think of just now, but the templates and strings suggested require understanding we cannot presume.

--LPfi (talk) 13:47, 15 May 2015 (UTC)

My idea would be wikidata properties for Opening time and Closing time each with qualifier applies to. The qualifier could link to items for 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun', 'bank holidays', 'weekdays', 'Ramadan', etc. Each item can have multiple opening and closing times each with a different qualifier.

Opening time:9.30(applies to:weekdays)

Opening time:10.00(applies to:Sunday)(applies to:Saturday)

Closing time:17.00(applies to:weekdays)(applies to:Saturday)(applies to:Sunday)

This can record all the info needed. The info isn't in the french wikivoyage format because it is data. Formatting is something for the wikivoyage template to do. —The preceding comment was added by Filceolaire (talk • contribs)

That would indeed store the info, though it would not be a concise as some previous suggestions. What we really need to establish is that we can create a template that will read it and convert it to the simplified format we want. For example, using your example, the template would have to take

OT:6.30(M,T,W,Th,F)

OT:7.00(Sa,Su,h)

CT:10.00(M,T,W,Th,F,Sa,Su,h)

OT:12.00(M,T,W,Th,F,Sa,Su,h)

CT:3.00(M,T,W,Th,F)

OT:6.00(M,T,W,Th,F)

CT:10.30(M,T,W,Th)

CT:12.00(F,Sa,h)

CT:9.00(Su)

and turn it into:

M-Th 6:30AM-10AM, 12PM-3PM, 6PM-10:30PM; F 6:30AM-10AM, 12PM-3PM, 6PM-12PM; Sa and holidays, 7AM-10AM, 12PM-12AM; Su 7AM-10AM, 12PM-9PM.

This a rather complex conversion, logically speaking, and would definitely have to be done in lua because it would require the use of variables. Texugo (talk) 11:23, 26 May 2015 (UTC)

ease of understanding and use

Although from a purely database point of view I can see the logic of a central store of information that can be accessed by multiple wiki projects, I however am concerned that for the non expert this could become too complicated and totally unclear how data is added and edited in an article. This would not encourage new contributors. --Traveler100 (talk) 11:07, 17 May 2015 (UTC)

Available now

Hey folks :) Arbitrary access has now been enabled for you. I hope you'll do awesome things with it that make your work here easier. Let me know if you encounter any issues please. --Lydia Pintscher (WMDE) (talk) 10:42, 19 May 2015 (UTC)

Great! I have put it at use without loosing time, so now Wikidata arbitrary access is being used (experimentally) at Tokyo/Roppongi#See for the National Art Center listing. It works great! Syced (talk) 03:58, 20 May 2015 (UTC)

Do we have an exhibition page for this on Wikivoyage?

This would be to discuss scenarios where we would leverage this new functionality. --Andrewssi2 (talk) 04:53, 20 May 2015 (UTC)

Yes, it works great, and the image is not displayed because Joachim's code reads it directly from the Wikivoyage page, not from Wikidata. At the moment we can't take coordinates and images from Wikidata. Perhaps we can't do this at all. --Alexander (talk) 07:14, 20 May 2015 (UTC)

It is interesting to see the National Art Center listing in Roppongi. It does raise the question of when it is appropriate to have the same details in multiple languages - the URL is now of the Japanese page when it used to be that for the English page. However this is a good start - we should pick a few smaller city pages to try this to see what happens. AlasdairW (talk) 22:49, 20 May 2015 (UTC)

Yes I hesitated a lot before moving the URL, but since it is a single proof-of-concept on a single listing, I decided to use it for demonstration purposes. By the way, I proposed a new property on Wikidata to address the lack of localized official website info in Wikidata. In the future, how about showing the official URL if the listing and the wikicode don't have a more specifically English-language URL? Syced (talk) 05:12, 21 May 2015 (UTC)

Syced, I would like to emphasize that neither name= nor image= fields can be read from Wikidata by the map script. Therefore, your example on the Tokyo page creates a "NoName" object without any thumbnail image. --Alexander (talk) 19:12, 21 May 2015 (UTC)

I currently do not see any way to retrieve the wiki source text, including the imported data from Wikidata. Does anyone know of such an API call? - Joachim Mey2008 (talk) 12:41, 22 May 2015 (UTC)

Well, Wikidata has its API, so you can retrieve everything you want by making this type of call. However, I am not sure that this is going to work on a larger scale, because you will have to make tens or even hundreds of calls to Wikidata in addition to loading the Wikivoyage page, so things will slow down dramatically. --Alexander (talk) 13:06, 22 May 2015 (UTC)

I asked about performance at the Wikidata DEV page. Syced (talk) 04:43, 25 May 2015 (UTC)

Is there something like &wikidata=expand, which would expand the Wikidata variables? I believe such a thing exists for templates. That would probably be more efficient than making a request for each listing, as the requests would be made on the Wikivoyage server side, and probably cached. Syced (talk) 09:55, 25 May 2015 (UTC)

I just asked for &wikidata=expand at https://phabricator.wikimedia.org/T100399 Syced (talk) 07:31, 26 May 2015 (UTC)

Phabricator reply: "Resolving this as declines, since the requested functionality can be covered otherwise" Syced (talk) 07:18, 29 May 2015 (UTC)

---

• More musings: @ Syced, Alexander, Mey2008:

I took the plunge and took a closer look at the issue at hand. In doing so, I wrote a Module with

perhaps the messiest code ever in Lua. I also texted with Syced a few times and spent quite a few long

hours getting familiar with Wikidata, Scribunto (Lua) and maps. (not an expert in either).

• To make things short and sweet: The issue is basically one of parsing and having the Scribunto (Lua) Module get there first with the mostest.

1. One can retrieve the decimal coordinates from Wikidata. They already appear to be in decimal format.
2. One can retrieve the name= (Wikidata title or if no title its label from the Qnnn ID)
3. One should be able to get an image from Wikidata and make it work as well. (Don't know if you are trying to get the image from (property) P18 or not?)
4. Map script(s) are able to read the name and coordinates that are provided from Wikidata to the template.
   • NoName on the map icon will also show the correct name when clicked on.
   • Template:Marker and Template:See (etc.) appear to work for me correctly.

Proof of this can be found here at : Futzing with Wikidata

Have a great day and GO HAVE FUN! ;) -- Matroc (talk) 06:10, 20 June 2015 (UTC)

• p.s. Happy Father's Day...

---

Matroc, that's great, but could you explain how you solved the problem? How does the map script know Wikidata values without making multiple calls to Wikidata from the script itself? Unfortunately, I don't know Lua well, so I can't immediately understand this from your code. --Alexander (talk) 11:10, 20 June 2015 (UTC)

--- Alexander I was trying to see if this was possible and prove that it could be done. It is a bit ugly code wise but could be improved upon greatly. Yes, there are multiple calls to Wikidata for each piece of information - I would like to see as few calls as possible to avoid computer load as well and hopefully achieve a faster outcome.

• (I think one call to Wikidata to get the main Wikidata entity (record) and retrieve multiple parameters once; rather than calling Wikidata a number of times and only retrieve one piece at a time, would definitely be preferrable.)
• At this time I am calling a Lua module to get the data for a parameter from Wikidata multiple times - ie. once for name, url, lat and long etc.
• Then using safesubst to substitute (replace or fill in) the parameter in the listing. (Actually replacing the listing in the long run!)

Why do it that way? - This insures that the parameters in question are updated prior to any parsing that normally occurs for a listing. (Map icon and numbering were not working because parsing occurred before the information from Wikidata was actually available for map processing.). By using safesubst, that information becomes available before (map) parsing occurs.

One would end up with a completed listing with parameters filled in. - No more calling Wikidata for that listing as the information is now present and filled in

and can be edited by a user.

• If it becomes necessary to reprocess and rebuild - Some kind of trigger may be needed to make that happen. One case would be what if Wikidata has changed some data for a particular entity.

Listing creation might also be possible using just one argument or parameter - the Qnnn (ID)...

These are just ideas and not all the answers or necessarily the full solution. This has been iterative programming at its worst :) - (матрос) -- Matroc (talk) 20:04, 20 June 2015 (UTC)

Added note: To make this user/editor friendly it would be best to be able to use templates otherwise it would not really be a viable solution...

Convert coordinates: DMS to decimal

Swept in from the pub

Hi all,

Do we have tools to convert coordinates from DMS to decimal? I copied Module:Coordinates from the English Wikipedia but I haven't managed to make it work...

Specifically, I would like to try converting Wikidata coordinates like

35°39'55.01"N, 139°43'34.82"E

to something like

lat=35.66483 | long=139.72685

.

Any idea what is the best way to do that? Cheers! Syced (talk) 04:20, 20 May 2015 (UTC)

I believe {{#invoke:Coordinates|coord}} outputs both dms and dec separated by a slash. ie. 29°37′N 79°40′E / 29.62°N 79.67°E - things change a lot as I originally thought there was a format parameter or call or a template but that is just guessing at this time - Matroc (talk) 07:10, 20 May 2015 (UTC)

Converting the coordinates from the wikidata format is tricky, so much so that it is probably just worth making an template for it. There are two steps to this. First separate the degrees, minutes and seconds using Module:String - e.g. {{#invoke:String|match|s= 35°39'55.01"N, 139°43'34.82"E |pattern=%d+°|match= 1 }} (results in 35°). Then use Module:Coordinates to format the coordinates into dec format like so: {{#invoke:Coordinates| dms2dec | N | 35 | 39 | 55.01 }} (results in 35.6652806) and {{#invoke:Coordinates| dms2dec | E | 139 | 43 | 34.82 }} (results in 139.7263389). If you can not understand what I just wrote, then I'll happily just write an Lua module that does all of that.--Snaevar (talk) 19:53, 20 May 2015 (UTC)

Maybe This... can help? -- DerFussi 04:17, 21 May 2015 (UTC)

Thank you all for the answers! Matroc: I don't see any DMS in your example? Snaevar: That would call Wikidata 8 times right? I guess I need to learn how to code templates with variables. Fussi: I don't see dms2deg at that page unfortunately :-/ Cheers! Syced (talk) 10:21, 21 May 2015 (UTC)

Syced to use that function the extension must be previously installed. Those functions are quite useful. For example I've used #deg2dd in it:Template:GeoData and #dd2dms in it:Template:Geo. --Andyrom75 (talk) 13:24, 21 May 2015 (UTC)

Syced - {{#invoke:Coordinates|coord}} results 29°37′N 79°40′E (DMS) / 29.62°N 79.67°E (DECIMAL) - just have to clean up the last group after the "/" to get 29.62 - 79.67 (appears to be rounded up to a specific precision... 29.61667 - 79.66667 - this may change

To retrieve latitude/longitude info:

• The new access to Wikidata {{#property:P265|from=Q????}} doesn't work for P265 yet and exact status is unknown .. might need a conversion as well when available
• {{#invoke:wikibase|latitude}} and {{#invoke:wikibase|longitude}} used to work but apparently doesn't at this time - again a conversion would be needed
• dms2deg and deg2dms are functions within the module Coordinates - {{#invoke:Coordinates| dms2dec | N | 35 | 39 | 55.01 }}
• Module Wikidata - not implemented at en:wikivoyage

- Formula from ancient school days (correct me if incorrect): dms to decimal = degrees + minutes/60 + seconds/3600

- would need some data validation/checks plus Math and String functionality if you are going to write something in the meantime be it templates or modules (Parser and String functions - Math module and String module etc.) Mediawiki is like Perl - more than one way to do the same thing! - LOL

• I think that this will all be ironed out in the long run... Best wishes...Matroc (talk) 04:57, 22 May 2015 (UTC)

The whole point of Wikidata is that it is meant to be format independent. We should be able to get the coordinates from wikidata in either format. As wikidata does not do this I think is probably worth raising a bug on phabricator. That won't help you solve the problem today however. Sorry. Filceolaire (talk) 03:53, 26 May 2015 (UTC)

Pagebanner extension for Wikivoyage

Swept in from the pub

Hi all, I'm Sumit, and I had posted a proposal for a pagebanner extension for Wikivoyage sometime back, which is now moving ahead under the guidance of User:Jdlrobson and User:Syced. As of now only a basic setup of the extension has been developed which adds a default specified banner on all main namespace pages, and replaces it with a custom banner, if a construct like {{PAGEBANNER:File.jpg}} is used. As it is being developed, all its live changes can be tried out at this test wiki. Your comments and/or views and/or feature additions shall be very helpful during the development process. The development shall follow the lines of the proposal much of which has been taken from Template:Pagebanner and its discussion page and will be modified depending upon the feedback.
For giving feedback, one can view the pagebanner workboard which has a few open tasks to be achieved in the coming time. If a task you wish to comment on already exists, simply go to that task and leave your comment. If it does not exist, you can create a new one from here(both require a phabricator account). While creating a new task, remember to add WikidataPageBanner to the Projects list so that it appears on the pagebanner workboard. Example of a task thats already open for discussion is this.
Whenever I'll add any significant feature, I'll leave a comment here, for everyone to see on the test wiki. For all other purposes, the progress can be monitored any time by looking at the tasks on the pagebanner workboard.
Looking forward to your cooperation. Feel free to comment and discuss.--Sumit.iitp (talk) 04:59, 20 May 2015 (UTC)

Pywikibot compat will no longer be supported - Please migrate to pywikibot core

Swept in from the pub

Sorry for English, I hope someone translates this.
Pywikibot (then "Pywikipediabot") was started back in 2002. In 2007 a new branch (formerly known as "rewrite", now called "core") was started from scratch using the MediaWiki API. The developers of Pywikibot have decided to stop supporting the compat version of Pywikibot due to bad performance and architectural errors that make it hard to update, compared to core. If you are using pywikibot compat it is likely your code will break due to upcoming MediaWiki API changes (e.g. T101524). It is highly recommended you migrate to the core framework. There is a migration guide, and please contact us if you have any problem.

There is an upcoming MediaWiki API breaking change that compat will not be updated for. If your bot's name is in this list, your bot will most likely break.

Thank you,
The Pywikibot development team, 19:30, 5 June 2015 (UTC)

Please test the new banners

Swept in from the pub

Hi all!

Sumit is implementing banners into Mediawiki itself. It will be rolled out to Wikivoyage when finished, so your early feedback would be appreciated :-) Here is a test page: http://pagebanner.wmflabs.org/wiki/Spain

• Done: Notice the breadcrumb and badges (star/unesco/otbp/dotm/ftt). Wikidata integration also works.
• In progress: The index is being developed right now, with drop-downs, and not visible yet. Mobile banners (which is one of the main benefits of implementing banners inside Mediawiki) are not implemented yet.

Thanks for your feedback! Syced (talk) 03:05, 12 June 2015 (UTC)

What are we expected to provide feedback on? In the example shown there doesn't appear to have even Wikidata integration yet. Andrewssi2 (talk) 04:06, 12 June 2015 (UTC)

Cool, it looks like progress is being made. It's hard to test it much though without a ToC and, like Andrewssi2 said, there doesn't appear to be Wikidata integration yet. One thing I noticed in a test edit [8] is the standard Wikimedia ToC appears if sections are added -- I assume the standard ToC will be turned off once the horizontal ToC is developed?

Another thing I noticed was the banner doesn't display properly when previewing an edit: it's broken down into it parts (i.e., the pagename appears first, then the banner and then the badges). It's not a biggie since it displays properly once the page is saved but it looks odd in the preview. Cheers -Shaundd (talk) 04:23, 12 June 2015 (UTC)

Hi all, a few clarifications from my side, regarding the pagebanner extension:

• Wikidata integration is enabled, but since wikidata cannot be linked to a test wiki, the test wiki has its own wikibase repository. If you see New York it is fetching a banner from item page Q2, a wikidata item on the test wiki itself. The item Q2 about New York is having a Wikivoyage Banner property P2 with a value set to a valid banner on commons Manhattan Wikivoyage Banner.jpg, just like on the real wikidata wiki, to mock the entire setup.
• "No banners on preview" is still a task to be achieved and is being tracked in the bug T100983.
• The TOC development is in progress, and yes the default TOC will be disabled once the drop-down TOCs are enabled.
• Pages that do not have {{PAGEBANNER}} or an associated wikidata item with a banner statement, automatically get a default banner. Thanks! --Sumit.iitp (talk) 08:42, 12 June 2015 (UTC)

Note: - There is no single default default banner in use on en.wikivoyage - believe there are 10+. Would only a single default banner (perhaps Pagebanner default.jpg) be used in the future -- Matroc (talk) 16:47, 12 June 2015 (UTC)

UPDATE: Banners now have a table of content, with sub-items (hovering Eat shows a sub-menu with Budget, Mid-range, Splurge). Live example: http://pagebanner.wmflabs.org/wiki/Roppongi Syced (talk) 09:10, 17 June 2015 (UTC)

Wow, that looks smart! Great job :) When can we implement them? Danapit (talk) 09:19, 17 June 2015 (UTC)

The dropdown menus made me smile. Powers ^(talk) 15:13, 17 June 2015 (UTC)

Agreed, the functionality seems to be coming along nicely. What additional feedback would be useful? Or would it be best to just keep an eye on things and then report any issues when it's in a more complete state? -- Ryan • (talk) • 15:29, 17 June 2015 (UTC)

Great to have the subheadings accessible from the TOC again! ϒpsilon (talk) 15:47, 17 June 2015 (UTC)

Has anyone tried this on the 'droids, tablets, assorted Apple toys or whatever other mobile gadget the kids use these days? K7L (talk) 18:40, 17 June 2015 (UTC)

Seems to work with Android tablets. ϒpsilon (talk) 05:17, 18 June 2015 (UTC)

I was trying with a smartphone, it's Samsung S_something (don't laugh at me, I don't even know what type I have) with Andoid system. Sadly, I didn't find a way to switch it to mobile version and in the desktop version the banner was really microscopic - I could somehow get the drop-down menu, but I didn't have enough fine motorics to select some particular submenu, however I could successfuly open a random submenu. That's good! Danapit (talk) 12:06, 18 June 2015 (UTC)

Mobile is the next task, actually! :-) You can follow Sumit's progress and next tasks on the workboard. Syced (talk) 10:23, 19 June 2015 (UTC)

Syced, btw, we still have another problem with the page banners. The bot that was run from time to time to transfer wikivoyage banners to wikidata is not available any more (the operator probably retired). Is there a chance to somehow add this task to this project as anoter work package? Danapit (talk) 18:22, 22 June 2015 (UTC)

You are very right, it is quite a big problem. We should prepare a very clear description of the task, and post it to a place where bot developers hang out. Syced (talk) 03:03, 23 June 2015 (UTC)

I'll try to write it down. Once finished, we can discuss where to put it. Danapit (talk) 18:51, 23 June 2015 (UTC)

VisualEditor News #3—2015

Swept in from the pub

Did you know?

When you click on a link to an article, you now see more information:

The link tool has been re-designed:

There are separate tabs for linking to internal and external pages. The user guide has more information about how to use VisualEditor.

Since the last newsletter, the Editing Team has created new interfaces for the link and citation tools and fixed many bugs and changed some elements of the design. Some of these bugs affected users of VisualEditor on mobile devices. Status reports are posted on mediawiki.org. The worklist for April through June is available in Phabricator.

A test of VisualEditor's effect on new editors at the English Wikipedia has just completed the first phase. During this test, half of newly registered editors had VisualEditor automatically enabled, and half did not. The main goal of the study is to learn which group was more likely to save an edit and to make productive, unreverted edits. Initial results will be posted at Meta later this month.

Recent improvements

Auto-fill features for citations are available at a few Wikipedias through the citoid service. Citoid takes a URL or DOI for a reliable source, and returns a pre-filled, pre-formatted bibliographic citation. If Citoid is enabled on your wiki, then the design of the citation workflow changed during May. All citations are now created inside a single tool. Inside that tool, choose the tab you want (⧼citoid-citeFromIDDialog-mode-auto⧽, ⧼citoid-citeFromIDDialog-mode-manual⧽, or ⧼citoid-citeFromIDDialog-mode-reuse⧽). The cite button is now labeled with the word "⧼visualeditor-toolbar-cite-label⧽" rather than a book icon, and the autofill citation dialog now has a more meaningful label, "⧼Citoid-citeFromIDDialog-lookup-button⧽", for the submit button.

The link tool has been redesigned based on feedback from Wikipedia editors and user testing. It now has two separate sections: one for links to articles and one for external links. When you select a link, its pop-up context menu shows the name of the linked page, a thumbnail image from the linked page, Wikidata's description, and appropriate icons for disambiguation pages, redirect pages and empty pages (where applicable). Search results have been reduced to the first five pages. Several bugs were fixed, including a dark highlight that appeared over the first match in the link inspector. (T98085)

The special character inserter in VisualEditor now uses the same special character list as the wikitext editor. Admins at each wiki can also create a custom section for frequently used characters at the top of the list. Please read the instructions for customizing the list at mediawiki.org. Also, there is now a tooltip to describing each character in the special character inserter. (T70425)

Several improvements have been made to templates. When you search for a template to insert, the list of results now contains descriptions of the templates. The parameter list inside the template dialog now remains open after inserting a parameter from the list, so that users don’t need to click on "⧼visualeditor-dialog-transclusion-add-param⧽" each time they want to add another parameter. (T95696) The team added a new property for TemplateData, "Example", for template parameters. This optional, translatable property will show up when there is text describing how to use that parameter. (T53049)

The design of the main toolbar and several other elements have changed slightly, to be consistent with the MediaWiki theme. In the Vector skin, individual items in the menu are separated visually by pale gray bars. Buttons and menus on the toolbar can now contain both an icon and a text label, rather than just one or the other. This new design feature is being used for the cite button on wikis where the Citoid service is enabled.

The team has released a long-desired improvement to the handling of non-existent images. If a non-existent image is linked in an article, then it is now visible in VisualEditor and can be selected, edited, replaced, or removed.

Let's work together

• Share your ideas and ask questions at mw:VisualEditor/Feedback.
• The weekly task triage meetings continue to be open to volunteers, usually on Wednesday at 12:00 (noon) PDT (19:00 UTC). Learn how to join the meetings and how to nominate bugs at mw:VisualEditor/Weekly triage meetings. You do not need to attend the meeting to nominate a bug for consideration as a Q4 blocker, though. Instead, go to Phabricator and "associate" the VisualEditor Q4 blocker project with the bug.
• If your Wikivoyage, Wikibooks, Wikiversity, or other community wants to have VisualEditor made available by default to contributors, then please contact James Forrester.
• If you would like to request the Citoid automatic reference feature for your wiki, please post a request in the Citoid project on Phabricator. Include links to the TemplateData for the most important citation templates on your wiki.
• The team is planning the second VisualEditor-related "translathon" for July. Please follow this task on Phabricator for details and updates! Announcements will follow in due course.

Subscribe, unsubscribe or change the page where this newsletter is delivered at Meta. If you aren't reading this in your favorite language, then please help us with translations! Subscribe to the Translators mailing list or contact us directly, so that we can notify you when the next issue is ready. Thank you!

— Elitre (WMF)

10:44, 13 June 2015 (UTC)

HTTPS

Swept in from the pub

Hi everyone.

Over the last few years, the Wikimedia Foundation has been working towards enabling HTTPS by default for all users, including unregistered ones, for better privacy and security for both readers and editors. This has taken a long time, as there were different aspects to take into account. Our servers haven't been ready to handle it. The Wikimedia Foundation has had to balance sometimes conflicting goals.

Forced HTTPS has just been implemented on all Wikimedia projects. Some of you might already be aware of this, as a few Wikipedia language versions were converted to HTTPS last week and the then affected communities were notified.

Most of Wikimedia editors shouldn't be affected at all. If you edit as registered user, you've probably already had to log in through HTTPS. We'll keep an eye on this to make sure everything is working as it should. Do get in touch with us if you have any problems after this change or contact me if you have any other questions.

/Johan (WMF) 22:00, 19 June 2015 (UTC)

Hovercards

Swept in from the pub

Is the beta feature Hovercards no longer available? -- Matroc (talk) 01:52, 17 December 2015 (UTC)

It is currently broken - see phab:T121777. --AKlapper (WMF) (talk) 17:50, 20 December 2015 (UTC)

Thank you for that information! - It is very useful -- Matroc (talk) 21:36, 20 December 2015 (UTC)

Noticed that Hovercards is back - Thank You! Thank You! Thank You! - Matroc (talk) 05:15, 22 December 2015 (UTC)

Question

Swept in from the pub

Is there a way to know immediately which users were the biggest contributes to specific articles (from the time the articles were created up till the present)? I am quite certain that this is possible (at least in Wikipedia), but can't remember how. ויקיג'אנקי (talk) 18:50, 14 February 2016 (UTC)

Here is Paris : https://tools.wmflabs.org/xtools-articleinfo/index.php?article=paris&project=en.wikivoyage.org --Andrewssi2 (talk) 19:44, 14 February 2016 (UTC)

Thanks! surprisingly over the years there weren't that many individuals whom made a significant contribution, when only looking at the top contributors by the size of the bytes they added in total (for example, top contributors to articles like Israel and Jerusalem - I could probably fit them all in one small room). This makes me wonder how would these articles look like if we managed to get a lot more active editors involved in expanding and improving our articles. ויקיג'אנקי (talk) 22:52, 14 February 2016 (UTC)