Wikivoyage talk:Cooperating with Wikidata

From Wikivoyage
Jump to navigation Jump to search


Swept in from the pub

Has anyone here looked into this Wikidata project and how it might be useful for Wikivoyage? They're concentrating on getting it set up for Wikipedia to start with, but after that it might be very useful for the lists that Wikivoyage uses. So someone updating a phone number on the English Wikivoyage would automatically be updating that phone number for all languages. Might be a good idea for people to start getting involved in figuring out what would need to be done, if that's not being done already. 22:53, 16 February 2013 (UTC)

I'm an admin here and on Wikidata, so I'm pretty familiar with both projects :) It's probably good to start thinking about, but it will be a while before it's deployed to non-Wikipedia sites, considering that we don't even have it working on 280 of the Wikipedia sites yet at all. --Rschen7754 23:25, 16 February 2013 (UTC)
I think someone will come up with a usefull way to make use of the data on wikidata in wikivoyage. Wikidata is more powerfull then most users realise. Carsrac (talk) 22:23, 17 February 2013 (UTC)
Can we start with basic stuff like population? That seems like the most primitive use-case for us, and will give us an opportunity to play. It is also something likely to be updates by our friends over at WP, so we can just forget about it, thus saving us time/effort. --Inas (talk) 23:18, 17 February 2013 (UTC)
quite extensive moves are now occurring at WP en of wikilinks - I think it is worth waiting and watching as to how that works. sats (talk) 23:59, 17 February 2013 (UTC)
Wikidata has a large enough volume of work to perform with just basic info on the large Wikipedia language versions, let alone extending Wikidata's capability to other projects and more extensive uses. Maybe we can set up a page like Wikivoyage:Working with Wikidata or Wikivoyage:Wikivoyage and Wikidata where we can collect ideas and, when the time comes, have a place where all ideas and proposals can be found for Wikidata users to view (and start working on) and for us to communicate with them. Since this is a cross-project and cross-language issue, where is the proper location to keep such discussion? Maybe we can discuss this here and when the time comes, start a page on Meta to formally discuss this with other WV projects. AHeneen (talk) 02:17, 18 February 2013 (UTC)
Someone has started a page for Wiktionary at Wikidata. Might be a good idea to get one set up for Wikivoyage. 09:29, 18 February 2013 (UTC)
Please, let's use Wikivoyage:Wikidata to brainstorm and coordinate what we might do on Wikivoyage with Wikidata, and possibly, following above Wikidata:Wiktionary example (but I've no other data on how Wikidata is organized) d:Wikidata:Wikivoyage (or d:Wikivoyage?) for what folks might do at Wikidata for or with Wikivoyage. I love names that are so short and obvious that I can type them without looking them up. --Rogerhc (talk) 05:27, 19 February 2013 (UTC)
Here's one nice application that has already been build on top of Wikidata. Not particularly useful for WV, but it show what can eventually be done. —Ruud 10:37, 18 February 2013 (UTC)

I have started a very basic Wikivoyage:Working with Wikidata. --Peter Talk 23:30, 20 February 2013 (UTC)

"In the coming year, the [Wikidata] team will be working on the further development and maintenance of Wikidata. This includes, among other things: [...] the possibility of deploying Wikidata in further Wikimedia projects, e.g. Wikimedia Commons or Wikivoyage." ( —Ruud 12:42, 28 February 2013 (UTC)

Wikidata is coming! ... eventually[edit]

Swept in from the pub

According to m:Wikidata/Status updates/2013 06 07, the developers worked on "First steps towards being able to add sitelinks for the first sister-project (WikiVoyage)". --Rschen7754 19:56, 7 June 2013 (UTC)

Get geographical coordinates for listing items[edit]

One thing that would be fantastic: be able to have access to the geographical coordinates of any Wikidata item, not only the item related to the current page. For example, for a museum, we would be able to put in the page its coordinates (and Wikipedia link, and official URL…) automatically by giving its Wikidata ID. Unfortunately, this ability is not available (I don't know why, maybe performance). - Fabimaru (talk) 20:53, 20 March 2015 (UTC)

On May 19th we will receive the ability to do this :-) Syced (talk) 04:19, 14 May 2015 (UTC)
Fantastic! Thanks a lot to anybody made that possible. In the French Wikivoyage, we added a parameter "wikidata" to the listings (there is also a parameter "wikipédia"), though it is not used much yet as the current value it provides is quite limited. - Fabimaru (talk) 11:55, 15 May 2015 (UTC)
If you have the Wikipédia link, would there be any way for a robot script to look at la page de Wikipédia, find out which Wikidata item it links, and populate the "wikidata" field? K7L (talk) 14:44, 15 May 2015 (UTC)
It is possible and not really difficult, but it would have to be developed :-) (I don't have time now to do it) - Fabimaru (talk) 21:30, 16 May 2015 (UTC)

Wikivoyage pages connected to (possible) wrong Wikidata items[edit]

Swept in from the pub

Hi, there are these article pages which are connected to disambiguation pages on Wikidata:

Would you please deal with these apparent wrong connections? Thanks in advance :) --Superchilum (talk) 19:24, 12 April 2015 (UTC)

New York and New England use "town" the way other jurisdictions use "municipal township" - as a container municipality for rural areas, unincorporated suburbs and tiny unincorporated villages which would otherwise have no municipal government. If given a choice between a "town" and a "village", or a "town" and a "city", skip the town and take the village as the main community. K7L (talk) 01:09, 13 April 2015 (UTC)
There are also a few pages in Category:Pages linked to a data item for a disambiguation, where the WP page linked is identified on WD with a "disambiguation" attribute. Texugo (talk) 02:52, 13 April 2015 (UTC)
Goring and Streatley: I recommend creating a Wikidata page rather than using the Wikidata page of either Goring or Streatley. Syced (talk) 06:15, 13 April 2015 (UTC)
Unfortunately, the "other projects" links in the sidebar only give space for one Wikipedia link from the Wikivoyage article, which doesn't work out well if a large rural area has a single page here and multiple articles on WP. K7L (talk) 17:19, 13 April 2015 (UTC)
Which is an issue, that I fear cannot be fixed, can it? Because while Wikipedia might deem a hamlet of 500 people "notable", this here is a site dedicated to travel and unless the hamlet happens to have a big airport right next to it or is of importance for travel by itself it won't (and shouldn't) get an article any time soon, but its (the hamlet's) existence might be worth a word or two in a "go next" section or region article... Hobbitschuster (talk) 21:37, 13 April 2015 (UTC)
If it has a town hall, as an incorporated municipality it's a notable, distinct entity for a WP article. If it's on the US Census, it gets an article. There was an infamously-huge spam incident in which a w:user:Rambot dumped pretty much the entire (now-outdated) US 2000 census, hamlet by hamlet, into WP as a series of village-level stub articles. That spam seems to have stopped by 2005, but the damage has been done. If back in 2000, 0.34% of the 588 people in w:La Fargeville, New York were of Asian descent, Wikipedia has archived that crucial fact for posterity. That's what, two people? K7L (talk) 22:00, 13 April 2015 (UTC)
And at the same time the German Wikipedia deleted articles on subjects such as Darth Vader... Which of course generated a lot of bad press and Internet backlash... But enough of this. How (if at all) can the issue at hand be solved? Hobbitschuster (talk) 22:08, 13 April 2015 (UTC)

Which could be the solution for the articles dealing with pair of destinations? And regarding Hepu, which is the correct item on Wikidata (does it exist?)? --Superchilum (talk) 09:43, 24 April 2015 (UTC)

Page banners and Wikidata[edit]

Swept in from the pub

So, I just discovered that Western Finger Lakes has a banner image. Yay! But why didn't I see it added in my watchlist? Oh, because when it was added back in September 2014, it was added to Wikidata. The wikicode in our article still shows the default banner. Now, I do have Wikidata changes on in my watchlist, but I can't tell edits that add or change a banner from edits that add a language link or change the Korean spelling or adjust the geolocation, not without viewing the diff of every single edit. Does anyone else see this as a problem? (Potentially, this loophole could be used to perpetrate undetected image vandalism.) Should we consider a moratorium on Wikidata banners? Powers (talk) 01:50, 25 May 2015 (UTC)

I actually stopped using WikiData for banners for this reason. I think the more realistic problem would be someone updating banners with mediocre images rather than vandalism.
Still as we contemplate more integration with WikiData for other things (temperature readings, currency exchange rates, geo-locations etc) then it would be highly desirable to track all WikiData changes related to an article. --Andrewssi2 (talk) 02:02, 25 May 2015 (UTC)
Wikidata is no worse than Commons for this. Do you get a notification when anyone uploads a new (possibly worse) version a banner stored on Commons? Are non-important changes (categories, spelling in the Korean description - no offence to Koreans) filtered out from the notification feed? Syced (talk) 05:14, 25 May 2015 (UTC)
Property-specific Wikidata notifications would be great indeed. This is very feasible (at least as an RSS feed), and I suspect some might have implemented that already, I will have a look. Meanwhile, I don't think there have been many tragic incidents so far, and to me it does not sound like a good reason to abandon the huge benefits of sharing banners between languages. Creating banners is hard-work. Multiplying this work by 17 would be a huge pity (17 languages). Syced (talk) 05:14, 25 May 2015 (UTC)
I agree with Syced on this subject. -- Ryan • (talk) • 05:34, 25 May 2015 (UTC)
This is going to become even harder to monitor if we start using Wikidata to fill fields in individual {{listing}}s. Paris/1st arrondissement is d:Q161741, one Wikidata item to watch if changing it affects the article, but if individual venues with {{listing}}s have corresponding Wikidata items, changing d:Q19675 (musée du Louvre) or other individual-venue records could affect the article in some manner. d:P969 (located at street address) should be the address on "rue de Rivoli" (au moins que je sache) but one stray edit on Wikidata could send the traveller somewhere else (hopefully not to the loo instead of the Louvre?). That sort of thing is hard to catch, as it runs cross-wiki. Indeed, the same issues exist with Commons - blindly tag {{listing|image=museum.jpg}} onto something and expect to wonder why the result becomes nonsensical if someone on Commons replaces the photo of the museum you wanted with some other museum in some other faraway land. I think Wikipedia was taking images that appeared in promotions for featured articles on its front pages, copying them to the local wiki and protecting them as "insurance" against this sort of mishap, but on a limited scale.
It's not a major issue at this point, but any proposals for a technical solution to the problem will need to recognise that a page could be pulling "shared resources" from multiple places, and not just the one matching Wikidata entry. K7L (talk) 13:01, 25 May 2015 (UTC)
Instead of doing the work 17 times, using Wikidata means that 18 communities (each Wikivoyage plus Wikidata) are watching the changes. However, it would be nice to have a feed that shows the changes we're (individually and collectively) interested in. WhatamIdoing (talk) 18:20, 25 May 2015 (UTC)
I agree with wikidata being a huge benefit for the banner effort, but since the implementation I've had concerns about the patrolling of new page banners, mainly regarding the correct size, but also quality. It's really hard to spot wrongly sized banners added locally, but impossible if wikidata item is used. Then it can only be found by a matter of chance. I'd welcome any technical possibility to be able to track newly added wikivoyage banners at wikidata. Danapit (talk) 21:48, 25 May 2015 (UTC)
There is a genuine need to get a watchlist notification whenever something from Commons/Wikidata is modified that actually impacts one of the pages you watch. I think it is time we raise a Phabricator issue about this, I am pretty sure Wikimedia developers will agree it is important. Meanwhile, anyone willing to try and code an RSS-based temporary solution? I a quite busy rigt now with other open source software, but that sounds like a fun project to create :-) Syced (talk) 04:38, 26 May 2015 (UTC)
Phabricator issue for adding relevant Wikidata events to an article's watchlist Very Wikipedia-focussed at the moment so I added a comment to expose our point of vue.
Phabricator issue for adding relevant Commons events to an article's watchlist This issue is marked as solved, so please test it and add a comment asking for reopen if it does not actually work.
Please subscribe to these issues and bring your ideas (diplomatically) thanks! Syced (talk) 06:45, 26 May 2015 (UTC)
I do not understand how to add Commons events to my watchlist. The topic on phabricator does not say anything about that, and I never heard of such a possibility. --Alexander (talk) 16:52, 26 May 2015 (UTC)

A minor note on Commons: images there are not supposed to be replaced with completely different images that fit the same name. There are issues with maps and graphs, where there sometimes are edit wars regarding a file with a generic name (Map_of_Kosovo.jpg & similar), but museum.jpg should not be replaced. It could be moved, with a bot changing the reference on affected projects (and thus insuring we thereafter do not depend on the generic name). I do not know how well images are watched over there, but I have seen only a couple of cases where an image has been replaced in a problematic way. --LPfi (talk) 09:11, 26 May 2015 (UTC)

Certainly, it happens. Image:Santa.jpg used to be a picture of Satan Claus, now it redirects to a team photo of a soccer (football) squad at Image:Santa Eufemia team.jpg - which looks weird if one looks at an old version of a page like (as originally created) which expected the other image at that name. The same issues arise if someone monkeys with the template designs. K7L (talk) 12:29, 26 May 2015 (UTC)
That file was deleted as copyvio and later replaced by another, also deleted as copyvio, at least five times. With such a generic name this is hardly very exceptional. The reference to the file should however be removed by a bot quite quickly after deletion. Sure, it is confusing in the history, but it does not affect the current version of pages. (And good images should tend to have good names, avoiding the issue.)
For the current pages the more common problem is probably when an image is overwritten (not deleted) with a similar one, while the caption mentions something specific for the original image. This should not happen for photographs (according to policy), and does not happen too often in my experience.
--LPfi (talk) 15:24, 26 May 2015 (UTC)
Huh? Santa.jpg used to be a picture of "Satan Claus"? XD ϒpsilon (talk) 16:21, 26 May 2015 (UTC)
Yes, and what happens very often is that good images eligible to be used on Wikivoyage under fair use are removed from Commons without any notifications. This is horrible. --Alexander (talk) 16:52, 26 May 2015 (UTC)
While non-free images can be used here under free use provisions, they cannot be stored on Commons. They can be temporarily restored to allow for transferring them to projects allowing fair use images. If you see the bot removing the reference to a deleted image, you can ask for this procedure (Commons:Undeletion requests). --LPfi (talk) 09:42, 27 May 2015 (UTC)
Grat point, LPfi. Back to wikidata, I am quite helpless with it. Is there a way to watch changes in a certain property (wikivoyage banner) for any item, not just those one has on a watchlist? Danapit (talk) 11:28, 27 May 2015 (UTC)
Yes, I can, and nobody will respond because these images are such terrible copyvios, and most of the Commons users consider their obliteration as the most important task of their life. Fortunately, we have one Commons admin in our ruvoy team, so all issues are easily solved on the personal level, but those images that we don't take care of are simply lost for the community. --Alexander (talk) 13:38, 28 May 2015 (UTC)
My request for a way to watch individual Wikidata properties got a reply: "for the watchlist, this should already work exactly as you described. If it does not, please file a separate ticket about that." Syced (talk) 09:03, 28 May 2015 (UTC)

Link articles with Wikidata[edit]

Swept in from the pub

Most articles in this Category:Banner missing from Wikidata are not linked properly with Wikidata. Could someone do it? I can't import those banners into Wikidata until this get fixed. See more => [1] Thanks. --Kizar (talk) 18:03, 9 January 2016 (UTC)

Wikidata again[edit]

Swept in from the pub

Working with Wikidata is an idea that's been kicked around since 2013, but never quite caught on. So far, it's used widely for pagebanners and interwiki links, but not much else. Retrieving info for individual {{listing}}s or {{quickbar}} fields has been proposed but not implemented; a couple of languages (de, fr) provide a d= or wikidata= field in their listings (which might display a clickable link) but don't seem to use it to run database lookups.

Pity. Ultimately, the idea was that Wikidata could be used to look up listing fields (lat, long, name, address, image...) by some automated means (maybe a 'bot script or a listing editor function; they also might be of use on dynamic maps).

I've made an attempt to update the list at d:Wikidata:Wikivoyage/Resources#Properties for listings to match Wikidata properties to individual {{listing}} fields in various languages. (Some have extra fields we don't use here, like star ratings 'estrellas' in Spanish or wi-fi availability in French. I haven't looked at any of the languages with non-Western character sets. Certainly, now that these are templates instead of WT-style tags, new fields are popping up in many individual-language editions and they don't always match across languages.)

Many of the most common fields already have a corresponding Wikidata property. The rest have been proposed for creation and are stranded at various points in the process. Our hotel/motel/B&B checkin/checkout times are stranded at d:Wikidata:Property proposal/Pending#Awaiting time type with precision second, seemingly for want of a Wikidata data type for a standalone "time of day" with no date attached. Many of the other fields (hours, pricerange...) are languishing at d:Wikidata:Property_proposal/Sister projects#Wikivoyage either for lack of examples or because someone wants to force a structure on an item where the underlying data is widely variable (such as hours= which are different every day of the week, vary seasonally and are different for different pieces of the same establishment (hotel with restaurant and bar might keep pouring drinks long after the kitchen closes for the night).

These need feedback while they're still open for discussion. Could you look at d:Wikidata:Property proposal/Sister projects#Wikivoyage and d:Wikidata:Property proposal/Pending to comment or add any information that's missing from the proposals? K7L (talk) 20:10, 16 May 2016 (UTC)

Migrating quickbars to Wikidata doesn't seem to be that complicated. One of the reasons for the lack of progress is the out-dated Module:Wikibase. I think we should import w:Module:Wikidata and all its dependencies. Does anybody have experiences with mass-importing lua modules? -- T.seppelt (talk) 20:32, 16 May 2016 (UTC)
Some notes:
wikidata= as a field in Template listing - already exists
The interworkings of a Lua Module either standalone or with templates etc. can be very tricky - Lua Modules generally get processed after a page has been processed... In many cases it is necessary to use "safesubst:" which forces the Lua Module to do its work and finalize results before the page gets processed. (The #invoke for the Module essentially no longer exists - just the results)
It is generally possible to build initial template codes we all know and love which in turn would require being edited further by hand.
Lua Modules have been used to create "geo" templates - retrieving lat/long coordinates etc.
Agree that Lua Modules have not been used or implemented in wikivoyage to a great extent.
Wikidata itself is incomplete and its properties wanting -- ie. description property for an article in Wikidata for example is "a city" - hardly enough for a listing or quick box - Larger content descriptions for listings would not exist - many properties one might desire for a quickbox are also missing such as electricity.
Who (bot?) is going to find and add the Wikidata identifier (Qnnn) for each listing's "wikidata=" field.
Lua Modules do have machine processing limits - something else be aware of.
Though many things could probably be accomplished with Lua Modules and Wikidata, I would suggest achieving one goal at a time. Matroc (talk) 17:01, 17 May 2016 (UTC)
The list of Wikidata fields to match the most common WV templates (listing, marker, quickbar, fr:Info Ville, Info Parc, Info Region, geo and mapframe) is d:Wikidata:Wikivoyage/Resources#Properties for listings. Many already exist; fr:'s version of quickbar (Info Pays) already defaults a few fields to the Wikidata record if they're not specified locally. Electricity (as a quickbar field) is missing but has been proposed at d:Wikidata:Property proposal/Sister projects#Wikivoyage, along with many of the other "missing" fields. That still leaves the issue of how to populate all of these fields, if and when they're created; "hours" and "price" are likely to be the problem children as they're currently unstructured free-form text which won't translate easily. Much of the information currently in Wikidata was copied there by 'bots, usually harvesting it from template fields in the corresponding Wikipedia article's info box. Certainly {{listing}} is going to be more difficult, largely because d:wikidata:arbitrary access is "expensive" in server time and much data in our existing listings is in plain-text fields which would need to be translated before they could be re-used elsewhere. It might be possible to add the Wikidata item with some sort of automated script if there's a unique identifier which could be used to match the entries; for instance, a local telephone number matches a number in a listing in the same city in some other-language Wikivoyage, which has wikipedia= linked from its listings, and from that language's WP we can find a d:Q##### record. Not easy, and most of our listings simply don't have (and won't have) Wikidata entries unless and until they get enough notability to get an article in at least one Wikimedia project (likely the WP for that country's home language). That makes using this for quickbars much easier than getting the listings. Then again, many of the same arguments could have been made to state that getting (lat, long) co-ordinates into individual listings is a mammoth task and we're nowhere near having a locator map for every destination. Indeed, but one must start somewhere. K7L (talk) 15:46, 18 May 2016 (UTC)
I'm working on a Wikidata lookup that could be integrated into the listing editor that would work the same as the search typeahead (type a few letters, suggested results show up). As you've noted there is concern about having too many Wikidata items in use on a page as improper usage could result in excessive lookups and parsing, but I would expect lookup performance to improve as Wikidata is more widely used, and we could do some basic testing to see if something like lat/long lookups using {{#property:P625|from=Q3699364}} was currently feasible. -- Ryan • (talk) • 17:07, 18 May 2016 (UTC)
Wonderful! Really looking forward to that Wikidata lookup field in the listing editor :-) Syced (talk) 07:21, 19 May 2016 (UTC)
Sounds great. It would be great to have some progress here. -- T.seppelt (talk) 17:37, 9 October 2016 (UTC)

Deleted listings on Wikidata[edit]

Swept in from the pub

Some of our listing were recently deleted from Wikidata and our current featured article got broken listings. I dropped a message on Wikidata, but I assume more discussion will be needed to save our listings on Wikidata and keep them alive over there. -- DerFussi 07:04, 1 March 2017 (UTC)

That is concerning. Although we can technically look at related WD changes in 'Recent Changes', in practice it is very hard to spot if someone wants to change a WV relevant item over there. --Andrewssi2 (talk) 08:51, 1 March 2017 (UTC)
So is there anyway to see from the wikidata page if a wikidata reference is used within a listing? I suspect not. On English Wikivoyage if the wikidata parameter has an entry we create an anchor on that page that has the QID number, can be used for hyperlinking between article on the site and between Wikipedia and WIkivoyage, but you cannot use this on Wikidata entries and not sure you would want that effort. --Traveler100 (talk) 09:27, 1 March 2017 (UTC)
It seems, it can be checked ([2])... Fortunately the items are restored meanwhile. We use WD extensively. The mentioned article Nanxun fetches all data directly from Wikidata. Even the hotel's phone numbers comes from Wikidata. You can not find all the information in the article itself. I want to get in touch with the developers to get some tools that help to see article related changes on Wikidata. -- DerFussi 21:15, 1 March 2017 (UTC)

Articles without Wikidata page[edit]

Swept in from the pub

The articles in this Category:Banner missing from Wikidata don't have a page in Wikidata. If anyone has time to fix it will be appreciated. --Kizar (talk) 23:46, 6 January 2017 (UTC)

Hola Kizar, nice to hear from you again! And thanks a lot for running your tool. My answer is late because I was travelling all around Spain :-) Would you mind running your tool again so that I can create the missing Wikidata items? Also, would you mind publishing the source code of your tool? That would allow Wikivoyage to survive even in case you disappear ;-) Thanks a lot! Syced (talk) 10:07, 9 February 2017 (UTC)
I did Syced. About the code, I don't have time now to clean up, but I will publish it soon. --Kizar (talk) 15:05, 5 March 2017 (UTC)
Thanks! :-) I processed one third already. Syced (talk) 14:03, 6 March 2017 (UTC)
Kizar: 100% done :-) Syced (talk) 12:29, 8 March 2017 (UTC)

coordinates ?[edit]

Coordinates on wikivoyage sometimes point to the main entrance of a large scale location, whereas Wikidata usually use coordinates of the center of that location. Can there be an option not to use the WD coordinates, or to manually choose whether or not to consolidate WV and WD coordinates? TaBaZzz (talk) 14:45, 10 April 2017 (UTC)

Yes, I agree, while I find the function to update fields from wikidata is really very handy and helps a lot, sometimes I wish there would be way to choose which fields to update. Often also the website linked in wikidata is not the best to use here. Drat70 (talk) 08:25, 11 April 2017 (UTC)
A question on this: When stuff on WD is updated, does it then automatically update on WV? Ceever (talk) 20:16, 11 April 2017 (UTC)
WV pulls data from WD: website, lat/lon, Wiki article, Image. TaBaZzz (talk) 11:55, 12 April 2017 (UTC)
I really don't feel, this is the right way. Meanings and semantics are not always the same, just connecting and inheriting things is dangerous. Who does guarantee, the editors on WD put as much effort into information as editors on WV do. Or who is the one verifying whether the connection is even right. We put too much work into this for it to just being spoiled. I would rather see a soft link here, so whoever wants to see either or both information, can do so with the right tool or script.
Therefore I would not be in favour of this hard connection of WV and WD. Let's rather have a solution like the link to WikiPedia.
Ceever (talk) 18:30, 12 April 2017 (UTC)
Sorry, but I am still a little confused about the simple wipeout of excellent GPS tagging we have done here on WV. Who guarantees the coordinates of WD have undergone the same quality standards?
Is this now consensus that we loose all this valuable work?
Ceever (talk) 20:23, 15 April 2017 (UTC)

Better using Wikidata in the future[edit]

Swept in from the pub

I think there are quite some things we might want to use Wikidata for. Unfortunately, I know next to nothing about how wikidata works, but here are three ideas that pop to my head.

  1. Currency conversions - up to date exchange rates for currencies; if there is a reason why wikidata can't/doesn't store them we will have to continue doing this locally and manually
  2. Climate data - I think there is no reason for our climate data not to be synchronized with what WP and WD know.
  3. Visa policy - articles like this one are much more detailed and up to date than our country get in sections - the basic information they contain is visa y/n and sometimes visa under a,b or c conditions and can be displayed as a fairly readable map - having this in one place (and I think that's what WD is for) enables us to benefit from more up to date lists instead of the probably outdated handwritten lists from 2012.

What do you think? Are there other things we could and should ask the people at Wikidata to integrate and implement so we can use them? Hobbitschuster (talk) 21:55, 9 March 2017 (UTC)

@Hobbitschuster: Filling in infoboxes. For what it's worth, I posted to the Project Chat about currency conversion but it went nowhere. —Justin (koavf)TCM 22:17, 9 March 2017 (UTC)
I'm in favour. I haven't been here long enough to know why we don't do this already. Ground Zero (talk) 22:51, 9 March 2017 (UTC)
@Ground Zero: The bottlenecks are mostly time and expertise. And to some extent, creativity. —Justin (koavf)TCM 23:00, 9 March 2017 (UTC)
As well as whether the information to be mined from WD is accurate, complete, up-to-date and properly linked which unfortunately it is not in all cases from my observations. -- Matroc (talk) 03:54, 10 March 2017 (UTC)
If you'd like to know more about Wikidata (with practical examples), then Asaf's recorded workshop is a good place to start. WhatamIdoing (talk) 07:01, 10 March 2017 (UTC)

Currency conversions[edit]

As it turns out, Wikidata supports storing rates for currencies. Here's how I implemented a template {{GEL}}, that shows rates for Georgian lari: 12.5 lari. @Hobbitschuster, koavf, Ground_Zero: what do you think about such approach, guys? Soshial (talk) 15:14, 19 November 2020 (UTC)

This looks like a great idea. Thank you, Sohial. I have two questions:
1. Does this mean that the currency conversion rates are automatically updated when the rates are changed in wikidata?
2. In the currency template, we show the date that the rates were updated. How will we change this if the rates are being updated automatically?
Ground Zero (talk) 18:36, 19 November 2020 (UTC)
Answering your questions:
  1. Yes, values that are shown in the tooltip refresh, whenever values in Wikidata are updated.
  2. We can take the date of latest currency rate from Wikidata and show it in the template. But, there is one downside: I haven't figured out how to take only the latest available currency rate; that is, it throws error if there are several rates for the same currency.
Soshial (talk) 05:41, 20 November 2020 (UTC)
I don't have the technical skills to help here, but I'm going to put a notice in the pub to see if we can get others to look at it. It would be great to be able to make this work. Ground Zero (talk) 13:29, 20 November 2020 (UTC)
Could you (Soshial) post example of some multiple-rate wikidata? In the end, you may use lua to create a custom tool, it's not that hard... but maybe there will be some way to use {{wikidata}} still... -- 20:03, 20 November 2020 (UTC) I didn't quite understand your question. Soshial (talk) 09:46, 21 November 2020 (UTC)
Soshial : "it throws error if there are several rates for the same currency." ... if you could share example an wikidata entry where the problem shows... -- 12:04, 21 November 2020 (UTC) I need {{wikidata}} to fetch the latest rate for a specific currency. If, for example Russian ruble contains 2 rates values for US dollar for year 2017 and year 2020, then my template takes both, unfortunately. Do you know any parameter to return only 1 value using some sorting maybe? Soshial (talk) 12:33, 21 November 2020 (UTC) please, have a look in this section (or at this Template:GEL)! The template returns error. Soshial (talk) 14:33, 8 December 2020 (UTC)
@Soshial: - I have it in my plans, but sadly time is sparse :) I'll try to give it a shot this week! -- 19:58, 8 December 2020 (UTC) ...or before the end of the year, then......................... :-) -- 06:00, 14 December 2020 (UTC) any luck or progress? :) BTW, did you plan on editing the original {{wikidata}} template? (Just to be sure: we need to be able to get a single entry, which has the latest Property:P585.) Soshial (talk) 05:31, 4 January 2021 (UTC)
@Soshial:, if I understood the docs correctly, you just need to replace "normal" with "best|single" in the invocation of {{wikidata}}. E.g. for RUB it seems to work - 0.01322. However I suggest you remove {{GEL}} and instead use something more generic (a template where'd you e.g. specify the source and requested target currency/ies via WD IDs). Otherwise there will be 50 templates with very minor differences... It'd be great if we could use a qualifier like P498="RUB", to automagically figure out the wikidata IDs from currency ISO code, but I think that would be too expensive (for the servers). So instead we'd probably need to implement private conversion table ("RUB" -> Q41044 etc.)... -- 20:16, 4 January 2021 (UTC) yes, RUB works, but GEL does not with identical parameters. Have a look at my comparison of RUB vs GEL. I can't figure out why RUB works and GEL doesn't. Soshial (talk) 06:14, 5 January 2021 (UTC)
@Soshial: okay, so finally, properties|single -> property (I'd say property|best|raw is the best combination). That way, it seems to work for both: 0.01322 / 0.222711. Cheers. -- 19:54, 5 January 2021 (UTC) this one works! Thank you a lot! BTW, is it possible to filter by units? (Since, property values can specify their units). Concerning unified template for all currencies, I completely agree and your approach seems the most reasonable to me. {{GEL}}, {{EUR}} etc would link to some unified template that stores a list of wikidata currency entities and then shows a popup in a similar way. Soshial (talk) 12:24, 8 January 2021 (UTC)

WikiData wiping out excellent GPS tags and no one cares?[edit]

Swept in from the pub

Hi there again
I mentioned this topic already in the WikiData section, and I would really like to have some input and opinions from others here.
I am not OK with the straight forward usage of WikiData connections to WikiVoyage listing when this wipes out the excellent work that users put into the GPS-tagging of WikiVoyage listings. There is no consensus on which data is better quality- and travelling-wise, and also there have certainly been some mess ups due to the flighty referencing of WikiData contents, like for Mt. Hermon and Wadi Daliyot.
Who guarantees that WikiData users put the same amount of effort into their data creation? Who guarantees the WD and WV listings are even referring to the same? Who guarantees the usefulness of the WD GPS-tags for the travellers?
So, can we please stop with the WikiData tagging of WikiVoyage listings as long as we have no agreement regarding this topic?
Ceever (talk) 18:56, 17 April 2017 (UTC)

There is nothing wrong with placing a wikidata tag into a listing. This issue is about being selective on which values to copy over. In fact I have a number of times corrected wikidata to what is at Wikivoyage, particularly web url and sometimes coordinates. Agree however it would be useful to have some form of compare or selective copy option when transferring information. --Traveler100 (talk) 20:16, 17 April 2017 (UTC)
This is precisely why I've urged caution regarding ceding too much control over the site to Wikidata. -- AndreCarrotflower (talk) 22:58, 17 April 2017 (UTC)
I agree that this is an issue. One problem I encounter is that when clicking link to take data over from wikidata (usually to get the Wikipedia page and the website), there is no way I can do this without copying over the coordinates as well. It would be great if that could be done only for selected field, so that we can take advantage of the benefits of having the wikipedia page and other information from wikidata but not wipe out coordinates which have been previously added. Maybe a way of getting around this would be to give priority to already present coordinates when data is copied over. Drat70 (talk) 05:53, 18 April 2017 (UTC)
This is precisely why we need better integration with Wikidata. I know I am asking a lot, but here is what I think we should have ideally: I would click "Merge values with Wikidata", and if there is a conflict (Wikidata and Wikivoyage both have a value, and the value is different), the dialog should show me both and ask me which one to use (overwriting either Wikidata or Wikivoyage), or whether to let them as-is, while giving me all of the info I need to decide. In case of an image I would be shown both images side-by-side in high resolution. In case of coordinates I would be show the two points on a map. Would that be difficult to implement? That would eliminate the present problem, and indeed benefit both Wikivoyage and Wikidata. Cheers! Syced (talk) 03:51, 21 April 2017 (UTC)

New notification when a page is connected to Wikidata[edit]

Swept in from the pub

Hello all,

The Wikidata development team is about to deploy a new feature on all Wikivoyages. It is a new type of notification (via Echo, the notification system you see at the top right of your wiki when you are logged in), that will inform the creator of a page, when this page is connected to a Wikidata item.

You may know that Wikidata provides a centralized system for all the interwikilinks. When a new page is created, it should be connected to the corresponding Wikidata item, by modifying this Wikidata item. With this new notification, editors creating pages will be informed when another editor connects this page to Wikidata.

Screenshot Echo Wikibase notification.png

This feature will be deployed on May 9th on all the Wikivoyages. This feature will be disable by default for existing editors, and enabled by default for new editors. This is the first step of the deployments, the Wikipedias and other Wikimedia projects will follow in the next months.

If you have any question, suggestion, please let me know by pinging me. You can also follow and leave a comment on the Phabricator ticket.

Thanks go to Matěj Suchánek who suggested and developed this feature! Cheers, Lea Lacroix (WMDE) (talk)


Swept in from the pub

Hello. On Wikidata we are debating about the creation of a new property that would allow one to mention what are the lodgings around a tourist attraction. We need your input on this one. Can you possibly check Wikidata:Property proposal/lodging? Thierry Caro (talk) 14:14, 13 November 2017 (UTC)

What is meant by "around"? Some fixed distance? Some fixed travel time (by which mode?). I think there is a huge difference between an attraction in downtown Venice and one in rural Wyoming... Hobbitschuster (talk) 16:32, 19 November 2017 (UTC)

Wikidata request for comment on the ideal data import proccess[edit]

Swept in from the pub
Community Noun project 26481.svg

Dear all

We are currently running a discussion on Wikidata about what the ideal data import process looks like. We want to get the thoughts of people who work on different Wikimedia projects who have different needs and knowledge of different kinds of data to make it our roadmap as inclusive as possible, please take a look.

Many thanks

John Cummings (talk) 01:15, 25 December 2017 (UTC)

Restaurants on Wikidata[edit]

Swept in from the pub

Wikidata has 2500 famous restaurants.

Check the map (press "▷") and make sure the restaurants in your pet areas exist and are linked to Wikidata... if they are worth being on Wikivoyage, obviously :-)

This is a first step towards maybe sharing attributes like coordinates/website/phone/email between various languages of Wikivoyage. Cheers! Syced (talk) 07:44, 25 May 2018 (UTC)

About one and a half year ago we started to add hotels to Wikidata (restaurants are similar) like the Steigenberger Hotel El Tahrir Cairo. It is very important to use this data immediately by adding a Commons link or to use it in a listing template to prevent deletion. Transferring data to Wikidata can be very helpful for our smaller communities. But we must not do all by ourselves. Many landmark hotels and restaurants are already available but with missing data like phone numbers (for instance Mena House). --RolandUnger (talk) 08:29, 25 May 2018 (UTC)
I of course appreciate the effort, but still - too bad those data aren't synced with the OSM data. Like in the example, the OSM building doesn't even have name/type=hotel, not to mention wikidata reference. But I can always hope that once, some hero will come and somehow (re)unite both databases (and I'll get the wikidata into my mobile phone/navigation/whatever). :-) (talk) 20:10, 25 May 2018 (UTC)

Creating a new Wikidata item[edit]

Swept in from the pub

For hotels, there is now a new tool/form at:

Sample creation: d:Q55932902 for this month's Höfn.

The tool is still being improved, but it can make it easier to create a new item. Jura1 (talk) 09:55, 3 August 2018 (UTC)

@Jura1: the tool doesn't allow entries to be saved yet, is that correct? ArticCynda (talk) 15:25, 3 August 2018 (UTC)
Thanks for the clarification, logging in indeed unlocks the "create new item" button, but even with a completely filled in form, nothing happens. How/where is the Wikidata item for the newly created hotel revealed? ArticCynda (talk) 15:45, 3 August 2018 (UTC)
Once clicked, it adds a link below the button to the new item. From d:Special:Contributions/ArticCynda, it looks like nothing was created. There are still a few bugs with tool (d:Wikidata_talk:Cradle). Jura1 (talk) 19:11, 3 August 2018 (UTC)
What's the motivation of this? I mean, you could as well just import=copy hotels from arguably much more complete OSM, and perhaps add wikidata refs while at it... That way you could even somehow re-sync the two occasionally (compared to above "start from scratch" approach) (talk) 16:50, 3 August 2018 (UTC)
These concerns aside, I'm also not entirely sure that any and all hostels or B&Bs meet the WikiData notability requirements. ArticCynda (talk) 16:56, 3 August 2018 (UTC)
The idea is to allow to share the information about the ones used in Wikivoyage listings across various language editions and other WMF sites. I think notably is here if the item is used in a Wikivoyage listing. Jura1 (talk) 19:11, 3 August 2018 (UTC)
The idea is good: to share information across various language editions. But not the solution. We need considerably more information as shown for instance for Steigenberger Hotel El Tahrir Cairo. And of restaurants and so on. We are using such data at the German Wikivoyage since about two years. It seems that information for sleep (hotels, but also campsites) are now fully accepted. The information should not only be entered but used. We start usually with a photograph at Commons and a category which is specific to this location. Then we create a Wikidata item and link it with commons. If there is no photograph you should immediately use this Wikidata item in a Wikivoyage article. There were a few problems at the beginning when Wikidata authors forgot to check the page information to got informed about data usage.
Now we are thinking about how to transfer these data from the listing templates or from the listing editor at Wikivoyage to Wikidata.
But there are some unsolved problems till now. One is that of opening hours (as discussed recently). The system used now is difficult to handle by software and it is not compatible with that of OpenStreetMap. Other ones are how to store hotel/restaurant features (in P527 ?), the types of cuisine and to expand properties for booking companies. --RolandUnger (talk) 06:34, 4 August 2018 (UTC)
I guess many people already discussed this in depth... But I'm really not convinced that essentially duplicating OSM work to wikidata is a good thing to do. It sounds like it would be better to e.g. extend wikidata with another namespace (like the [recent lexeme stuff]) that would somehow refer to OSM. Sure, OSM has unstable IDs yadayada. But I would say some man-weeks of developer discussions/implementation would be better than thousands of hours of copying stuff. Especially when the hotels come and go daily, and hotel aggregators get the listings+updates for free from the hotel/restaurant operators (whereas we have to maintain that manually here and in OSM). But if there are people willing to spend time on this, who am I to stop them... My 2c... :-) (talk) 06:53, 4 August 2018 (UTC)
  • Maybe I should have mentioned: please use it here if you create an item.
    — In some aspects, it seems to me that Wikivoyage was light-years ahead of other MW projects. Wikidata slowly follows up, but I don't think it can provide all required fields for listings yet and might not be able for some time. At d:Wikidata:Wikivoyage/Resources#Properties_for_listings there is the result of the last iteration (2 years ago). I think infoboxes for places were set up back then.
    — @RolandUnger: I don't think the thing with opening hours got anywhere last time. If there is a standard format we could use, please propose it. Unless the data is used and maintained, I'm not sure if Wikidata is the best place for that though. Unfortunately, development is absorbed by other things, so we can't even enter time-values in date properties. has facility should work for some of the aspects you mention.
    — There are some types of listings that I think work better in Wikidata than others, at least based on current update frequency and the number of users doing that. Items for many "see" and "do" listings are already available and basic "sleep" listings might not require that much maintenance.
    — BTW, for demo purposes, would it be possible to add the listing template and tool on ? It might be more readily present in the minds of Wikidata editors even if it's not the English version. I asked a Wikidata admin to look into that.
    I do think that Wikivoyage is a good usecase for Wikidata items, allowing local reviews, descriptions, and comments on shared basic structured data. Jura1 (talk) 13:29, 5 August 2018 (UTC)

Website to extract Wikidata ID's from OpenStreetMap[edit]

Swept in from the pub

Hello, CKoerner (WMF), Matroc, Shaundd, Alexander, Yurik, Andrewssi2, RolandUnger, Mey2008, Traveler100, ϒpsilon, Whatamidoing (WMF), Selfie City and everyone else interested in dynamic maps. I have created a little website, which helps to gather all the Wikidata ID's of a certain region.

Of course once this overview map is created there is still a lot of work to be done: All the Wikidata ID's for a Wikivoyage sub-district have to be manually copied and pasted into a separate Mapshape in order to color the map.

I have quite a few ideas on how to automate this further. Imagine a map of e.g. Prague with all districts is shown and you simply have to lasso/brush select all the districts, which should be used for a certain color and the tool would automatically output a Mapshape with all needed Wikidata ID's. Unfortunately my JavaScript knowledge is not (yet) up to the task.

Hope you guys find Wikidata Extractor useful.--Renek78 (talk) 10:27, 9 August 2018 (UTC)

Hi, great stuff! I'm not sure on general usefulness on WV, since many areas here don't match the official counties/municipalities. It'd be great if Kartographer could be convinced to do some logical operations with areas - e.g. subtract a region (group) and a json area (to be able to draw Interior_(Iceland) and North_Iceland). I didn't find such feature though :-(
If we can figure out a way to easily query for some administrative regions (also on lower levels, than just 'counties' - also city boundaries etc.) within a geoJSON area (e.g. from, that would be sweet. But even this so far is nice :) (talk) 10:40, 9 August 2018 (UTC)
For regions, which are completely independent of any official boundaries the GeoJSON has to be created manually (with tools like or JOSM) and then uploaded to commons. Plenty of articles with such maps can be found here already (check my user page for some examples). This would also be possible for your Iceland example. Wikidata/OSM is only for official districts/municipalities. Hope I didn't misunderstand you.--Renek78 (talk) 10:53, 9 August 2018 (UTC)
You understood correctly, and I know about the "commons maps"... But I don't have the will+time to do that, not to mention maintain it (it's almost like the negative properties of static and dynamic maps combined :-D). E.g. in Slovakia, most of the regions match the official region split - and I only would need to adjust a few on the south-west (though I think in the end, I'll just redefine the split and be done with it). I'd much rather maintain the "minus masks", than completely new mapshapes... A man can always dream :-) (talk) 11:13, 9 August 2018
It's often possible to "approximate" the region/district map you have in mind by combining sub-region or sub-district polygons from OSM, although many are not yet linked to Wikidata. This allows you to compose pretty much arbitrary districts for cities by combining individual neighborhoods, for example. If neighborhoods are not defined, then a custom map on Commons, like Renek78 suggested, is probably the preferred option. Brussels is a good example, with its map hosted here. Note that these custom maps, although necessary for some articles, should be the exception rather than the rule because they're much harder to maintain than OSM polygons. This should be only considered for regions and districts which already have a clear overview of the distribution of their POIs so that frequent changes to these maps can be avoided. ArticCynda (talk) 11:16, 9 August 2018 (UTC)(UTC)
Yup, the missing wiki-osm linking for the small regions (like municipality/city/town/village boundaries) is the biggest issue for that approach... It's a lot of work either way, though I think the linking of Wikidata to OSM is a bit more future-proof and valuable for other projects too, in this case. (talk) 11:21, 9 August 2018 (UTC) drawing custom maps is fairly quick if you use JOSM to draw polygons of regions, then export them as GPX and convert them into GeoJSON. The .map file can be linked directly, with few manual edits necessary. Distilling mapshapes for individual districts from that is another story, though... I haven't found a way to automate that yet. ArticCynda (talk) 11:25, 9 August 2018 (UTC)
Thanks, that's interesting! --Alexander (talk) 11:20, 9 August 2018 (UTC)
Wow, thanks! This tool is much better than manual lookups. MSG17 (talk) 22:14, 27 September 2018 (UTC)
Some minor thoughts
  • This should assist in getting coordinates which can be very useful in doing any manual coding.
  • Building mapframes and maplinks is a very simple task with the several methods that currently exist (templates, modules and static data files)
  • Wikidata, Wikipedia and Wikivoyage names/labels do not necessarily match but should not present any major issues.
  • Putting appropriate OSM links into Wikidata needs to be accomplished as wikidata is supposed to be a base point for many of the map tasks. Prague has some 91? pieces of which only 7-9 have OSM links and just as few WV matching articles. The opposite is also needs to be examined and a lot of OSM entries need to be addressed and matched up or created as well.
  • Insuring Wikidata has all the administrative units entered into Wikidata appropriately as well as insuring that each unit has its own Wikidata record etc. This would make life easier to do module lookups etc.
  • Wikidata records that have NO NAME should be looked at and corrected. (Prague has 2 I believe)
  • Using Data records from Commons is fine to do; however, how does one determine whether they are to be used or not and which ones exist. Can read a Commons entry in a Wikidata record to see if it begins with Data I suppose is one way.
  • Building artificial or arbitrary regions/districts by combining a group of other admin units. Can be done easily enough if matching OSM entries exist. Just a matter of determining what to combine and a little bit of extra coding.
  • Some of what you are doing, I believe can be done using a module directly from Wikivoyage rather than externally though in the opposite direction. In either case, keep up with the ideas. -- Best wishes -- Matroc (talk) 04:01, 10 August 2018 (UTC)
I wouldn't count on "combining admin units" as a way to generate the boundaries for a Wikivoyage article, as often the boundaries do not align. One runs into silliness like w:Cloyne, Ontario – a tiny speck-on-the-map hamlet where the main street is the county line. Wikivoyage avoids the issue by moving the boundaries to force the entire unincorporated village into Addington Highlands instead of chopping it in half with all the wisdom of Solomon. A boundary generated based on administrative units would not handle something like this gracefully, nor will it handle the case where the city sprawls that little bit across the county line into rural countryside. We include the suburb with the adjacent city, not with some more distant city which happens to be on the same side of the admin boundary. K7L (talk) 04:49, 10 August 2018 (UTC)
I agree when OSM is off and does not meet requirements; the need for creativity arises, one may have to experiment and resort to other methods/avenues (There will always be exceptions). The use of wikidata admin units is but one suggestion as an approach for gathering information to use or not. -- Matroc (talk) 09:18, 10 August 2018 (UTC)

Locations on Wikidata[edit]

Swept in from the pub

I cannot get this map to give info on the marked places. Looking for the wikidata number for the location as the article Platanias is currently pointing to the wrong one. --Traveler100 (talk) 10:35, 4 September 2018 (UTC)

Link in Wikidata for Platanias is for Platanias Municiplaity located in Crete. I didn't find another Platanias to match. Not sure if you need to remove the WV link from that Wikidata record and create a new Wikidata entry - apologize if that is not helpful. -- Matroc (talk) 16:01, 4 September 2018 (UTC)

Wikidata map problem[edit]

Swept in from the pub

Hi, I am trying to make a Wikimedia map page as part of Melbourne districting. Can anyone tell me why the colored fill is not working? Thanks Ar2332 (talk) 20:16, 23 October 2018 (UTC)

Hi Ar2332, the geometry type was set to "LineString" instead of "Polygon". I fixed it. --Renek78 (talk) 20:44, 23 October 2018 (UTC)
Thanks! Would you be able to take a look at several more maps I have created but which show up as empty? I don't understand why, as I just copied and pasted the valid one and replaced the coordinates. 1 2 3 4 Ar2332 (talk) 15:06, 24 October 2018 (UTC)
Ar2332, the problem this time is that latitudes and longitudes are swapped. So instead of [144.90,-37.68] your GeoJSON has the invalid value of [-37.68,144.90]. Maybe you need to play around with the export functionality a bit (on your first polygon yesterday it was correct). But the syntax of your GeoJSON is - except for the coordinate swap - perfectly fine now! --Renek78 (talk) 17:52, 24 October 2018 (UTC)
You can remember that the positioning north/south (latitude) always comes first in coordinates, and then the east/west position (longitude). --Comment by Selfie City (talk | contributions) 01:39, 25 October 2018 (UTC)
I'm confused - these locations are in Australia, so isn't latitude -37 longitude 144, with latitude coming first, correct? Ar2332 (talk) 06:26, 25 October 2018 (UTC)
Longitude (in your case 144) comes first. Then latitude (e.g. -37). You can best understand it by going to, draw a simple polygon around Melbourne area and check the GeoJSON, which is shown on the right. --Renek78 (talk) 09:24, 25 October 2018 (UTC)
I see. I was confused because Wikivoyage "mapmask" uses the opposite order. Thanks! Ar2332 (talk) 14:30, 25 October 2018 (UTC)
Welcome! Until now I don't know why it is the other way round for Mapmasks... --Renek78 (talk) 19:22, 25 October 2018 (UTC)

Article Geo different to Wikidata[edit]

Swept in from the pub

What are the guidelines to solve Wikivoyage/Wikidata inconsistencies? Here is my procedure, I would appreciate your feedback about it:

  1. Open in a new tab the "Geohack" link of the "Wikidata" line.
  2. On the page that appears, check on the map to make sure it is the correct place (if not, unlink the Wikivoyage page from the Wikidata item and link it to the correct item or even to a new item).
  3. In the upper right, copy the value at the "Decimal" line.
  4. Paste that value into the "{{geo" template of the Wikivoyage article.

Is that correct? Is this duplication really needed? Could not we retrieve the location from Wikidata if it is not specified in the geo template?

Thanks! Syced (talk) 07:43, 7 December 2018 (UTC)

One of the uses of the article Geo is to display article's locations on a map, as for example on Destinations. This works best when every article has a different lat/long, preferably sufficiently different that you don't have to zoom all the way in for the orange crosses to disappear. This is probably a unique requirement for WV, and for other uses it does not matter if the capital city, county, region and country all have the same lat/long. I would prefer that the inconsistencies were simply ignored, with the possible exception of differences of more than 500km (50km for cities). AlasdairW (talk) 08:40, 7 December 2018 (UTC)
I tend to open both map options from the ErrorHighlighter gadget to check which one is correct. There are a good number of wikidata entries that are incorrect. For regions and countries there can be a different. Wikipedia tends to weight the population center of a region while wikivoyage has geometric center. Key is also to look at the zoom factor. What I tend to do is edit the numbers in the map window until the position and zoom looks good then edit the geo in wikivoyage and sometimes also edit the wikidata coordinates. Suggestion of a recommend method is a good idea, should document at Category:Articles Geo different to Wikidata. --Traveler100 (talk) 14:47, 9 December 2018 (UTC)
Thanks for the input! Is there a way to mark an article as "yes wd/wv coordinates are different but we are happy with this"? Syced (talk) 03:43, 10 December 2018 (UTC)

Correcting "Banner to WD" Errors[edit]

Swept in from the pub

What is the official way to clear up the "Banner to WD" errors?

I've been playing around with cleaning up the Maintenance Category of "Banner to WD" errors which currently has 612 pages that need fixes. Some of the errors are being caused by there being two Wikidata entries that are substantially the same. For instance White Sulphur Springs has at least two entries for a city in West Virginia. I added the banner to both, but the city still shows up on the error list. Out of 40 test fixes so far, only 14 have taken, so I'm guessing that there is another component that needs to be fixed besides the Wikidata entry.

If you would like to look at another example, try Waukegan. There's only one city with this name, I've added the banner and a reference in Wikidata, but Waukegan still persists on the error list. Any suggestions as to what else needs to be looked at to correct these errors would be appreciated. Zcarstvnz (talk) 21:42, 3 January 2019 (UTC)

Looking at the Waukegan page, with the "show hidden categories" preference set (in the preferences appearance tab), it is not showing the "Banner missing from Wikidata" category, although it still appears on the category list. It may be worth waiting a few hours for the list to refresh. AlasdairW (talk) 22:45, 3 January 2019 (UTC)
If you edit a Wikidata entry it will not update the category on Wikivoyage until you re-save the article on Wikivoyage (go to edit and press Publish, do not need to make a change). Otherwise you have to wait until the server does a re-sync of categories which could be soon after or a few days later.--Traveler100 (talk) 07:11, 4 January 2019 (UTC)
Re-saving the article as you suggested worked. Thanks Traveler100 for your suggestion!
Follow Up. In addition to adding the banner on Wikidata and then re-saving the page on Wikivoyage, there is one more item that may need to be added on Wikidata: the Wikivoyage link must be added as shown in the photo below (in this case the entry for the city of Waukegan).
Wikidata Waukegan link.jpg
Below all of the Wikidata Statements and Identifiers is a list of links to Wikipedia and other sister sites. If the Wikivoyage statement is blank the Wikivoyage page is not removed from the "Banner to WD" error page. The combination of the page banner and link is the complete Wikidata entry.Most of the remaining "Banner to WD" errors are pages that have not been created in Wikidata which I am in the process of creating.
There are a couple of sandbox pages in the "Banner to WD" list, and a few other entries that are likely not going to be able to be removed. I hope this explanation helps to better document the process of fixing these entries. Zcarstvnz (talk) 09:33, 17 January 2019 (UTC)

How to get correct coordinate location?[edit]

Swept in from the pub

Hi. I'm trying to correctly place the site of the ancient Sumerian city of Uruk in the Mesopotamian Valley of southern Iraq, but it keeps wanting to put the pin exactly where the pin for another site (the Sumerian city of Ur) is located. Uruk is east of As Samawah, and Ur is southwest of Nasilyah, a distance of like 85 km away. I used the correct Wikidata identifier for Uruk and even modified the coordinates a little to make it precise, but it still places the pin on Ur. If you do a search for them on Google maps, you'll see what I mean. Could someone please tell me how to fix this or fix it for me? I am not sure what to do. Much obliged. Lazarus1255 (talk) 04:30, 18 August 2020 (UTC)

At Wikivoyage the traveller comes first, not whatever purpose is served by listings being integrated with Wikidata. The traveller obviously needs points of interest to be placed accurately on a map, and if you have to remove the Wikidata identifier to accomplish that, so be it. -- AndreCarrotflower (talk) 04:36, 18 August 2020 (UTC)
Fixed. You had the same lat+long hardcoded in the marker template (probably copy+pasted?)... -- 06:29, 18 August 2020 (UTC)
Thanks for this, From the edit summary, it sounds like Wikidata was the solution, not the problem. WhatamIdoing (talk) 20:27, 18 August 2020 (UTC)
Yup... :) -- 05:38, 19 August 2020 (UTC)
Wow, thanks guys, I appreciate it, and I'll try to learn from that. Grateful for all the help.Lazarus1255 (talk) 05:48, 19 August 2020 (UTC)

New opening hours properties on Wikidata[edit]

Swept in from the pub

There are two new properties on Wikidata that might be useful for Wikivoyagers, too: opening time (P8626) and closing time (P8627). These properties can centralize and allow for adding references to opening hours information across Wikivoyage language editions. It also exposes the data to a large userbase of Wikidatans, who can help keep the information up-to-date. NMaia (talk) 10:26, 21 September 2020 (UTC)

Hi @NMaia: Thank you for letting us know about this news; hopefully the new feature can be mutually beneficial.
There is a point of consideration which you and your fellow Wikidatans may not be aware of: on Wikivoyage, we have standardised formats for opening hours, including specific abbreviations for days of the week and month, and we use day ranges rather than daily opening hours (e.g. "M-F 9AM-5PM, Sa Su 10AM-6PM", not "Mon 9AM-5PM, Tue 9AM-5PM, Wed 9AM-5PM,..."). We also use a mixture of 24-hour and 12-hour clocks, depending on the most prevalent system in the geographical location concerned. For example, listings in the USA use the 12-hour clock, while listings in France use the 24-hour clock. Full details of the policy can be found at WV:TDF.
Will you be able to ensure that this policy is adhered to? Regardless of the format Wikidatans will use to input the data, we will need the hours to display on Wikivoyage in the required format, and as stated already this varies across our articles.
I think it's a good thing to collaborate across projects, but in this case there has to be regulatory alignment of some description in order for this to work. There may be appetite in the Wikivoyage community to update our TDF policy, or maybe Wikidata will adopt our policy, or perhaps there is some sort of software to convert WD inputs into the required WV format. But however it's done, there needs to be interwiki standardisation.ThunderingTyphoons! (talk) 11:54, 21 September 2020 (UTC)
I think it is possible for code to give the relevant outputs based on machine readable data on WD. Hobbitschuster (talk) 12:45, 21 September 2020 (UTC)
Yes, I've been told it can be done, particularly with Lua modules. NMaia (talk) 02:01, 22 September 2020 (UTC)
Even if it weren't, it's not terribly important. We can import the data into the listing template, and manually correct the format. I've tried importing some Wikidata records to pre-populate the listing, and it can be a significant time- (and hassle-) saver.
I don't think that Wikidata should ever be held responsible for following our formatting style. Besides, what if a different community had a different style? We should feel free to use the information, and to share information with them, but turn it into something that works for us here. WhatamIdoing (talk) 15:44, 22 September 2020 (UTC)
I doubt it is worth the trouble. WV formats are not sacred. This might be a good time to improve them. Pashley (talk) 12:15, 22 September 2020 (UTC)
The format of the property seems to be quite flexible, as shown by examples at Wikidata:Property proposal/opening hours, but there might be important special cases where the Wikidata format is more convoluted than the Wikivoyage one. In any case, we need code to get the info we want and format it in some way. Perhaps the result of a well written database query is suitable for us, but I'd try to write that query/code first and look at how more complicated entries get to look like before we deem a Luo module is unnecessary. –LPfi (talk) 12:44, 22 September 2020 (UTC)
Nobody said they were sacred, I even said that we might be willing to change them. But this will need to happen across the whole site as a new standard, not be done piecemeal so that we have a bunch of different formats in use.--ThunderingTyphoons! (talk) 12:51, 22 September 2020 (UTC)
We kind of already do have a bunch of different formats in use. There's 12 vs 24 hour, and sometimes Saturday is "Sa" and sometimes "Sat". That's four "legal" formats right there. Then there are the complicated situations. I once gave up on reporting the closing hours for one attraction because the hours varied significantly not just by the day of the week, but also by the month. Their website dedicated a whole page to their opening hours. WhatamIdoing (talk) 15:52, 22 September 2020 (UTC)
No, that's not true. "Sa" should never be "Sat"; when you see that, please correct it.
We have two standardised systems in use here, for the 24-hour clock and the 12-hour clock, though these are really just variations of the same system: aside from the times, everything else is the same. The more complicated situations I grant you, but these are a tiny minority.--ThunderingTyphoons! (talk) 16:53, 22 September 2020 (UTC)
See Wikivoyage talk:Time and date formats#Expanded short names for days of the week. WhatamIdoing (talk) 15:46, 23 September 2020 (UTC)
(response to WAID?, 15:44) If I have to correct all the formatting by hand as soon as imported, why would I bother doing that rather than looking up the hours myself online? The idea is to share data seamlessly across the wikis, and presumably Wikidata would also benefit by importing opening hours from Wikivoyage. If we both use the same system(s), this is made easier for everyone involved.--ThunderingTyphoons! (talk) 16:59, 22 September 2020 (UTC)
Because formatting content is faster that looking up content plus formatting it. WhatamIdoing (talk) 15:49, 23 September 2020 (UTC)
Thanks NMaia for making this happen! It would be great if the listing editor could be updated to do the matching like it does for other Wikidata fields (it will be a bit more complex, so maybe just the simple cases?) Syced (talk) 00:28, 23 September 2020 (UTC)
NMaia, if I want to specify "Mon 12:00-14:00 and 19:00-21:00" I suppose that I have to add two different values (one for 12:00-14:00 and one for 19:00-21:00), correct? Or there's a possibility to add both time range under the same value (i.e. Monday)?
Regarding the timing won't be better to strictly store the time as HH:MM (24h)? This will make it easier to elaborate the output according to any specific need. --Andyrom75 (talk) 09:41, 23 September 2020 (UTC)
In the proposal, I originally intended to keep them under the same statement, like you mentioned, but someone asked me to change it, so I did. Either way, I think it won't cause many problems for Wikivoyage. NMaia (talk) 11:09, 25 September 2020 (UTC)
NMaia, it's not a problem but I think it's more complicated to manage the stored information. Having 7 values for the 7 days, each one of them having their own time range I think it would be easier, because that's how generally we show such kind of data.
What about time syntax? --Andyrom75 (talk) 21:34, 25 September 2020 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── After the addition of P8626 and P8627 I wrote the Lua module Hours (Q99600452) which makes opening hours, stored at Wikidata, available for establishment listings at the German Wikivoyage. The stand-alone module can be used both with other Lua modules or with an invoke call in a template and can be easily translated. The module produces a compact output with short or abbreviated names and clustered time periods as far as possible which can be learned form the documentation of the module mentioned.

The module is already for productive purposes. There are some maintenance categories to watch the module's operation. A special feature is used which we already added to other Wikidata data-fetching modules in a similar manner: For common ids we are using a table to prevent fetching from Wikidata which is time consuming. --RolandUnger (talk) 08:04, 27 September 2020 (UTC)

New checkin and checkout properties on Wikidata[edit]

Swept in from the pub

Now check-in and check-out times (P8745, P8746) can be entered to Wikidata. For instance {{#property:P8745|from=Q56506795}} will return 14:00, the check-in time of the Nile Ritz-Carlton in Cairo.

The times are stored as an entity id. 2PM (14:00) is stored as Q55811610, and 14:00 is its label. With simple Lua scripts, formatting can be made. Now all listing parameters excluding alt and content can be stored to Wikidata (and displayed at the German Wikivoyage, too). --RolandUnger (talk) 11:30, 24 October 2020 (UTC)