Wikivoyage talk:Wikidata Expedition

Errors with Wikidata interwiki links

Swept in from the pub

What do we do when a page has been given a separate wikidata item from the others? For example pt:Hachioji should be connected with Hachioji here and on other versions, but instead it has a different wikidata item. When I tried to add it to the correct one, I got the error message:

Site link Hachioji already used by item Q14205680.

but there was no suggestion as to what should be done to fix it. Anyone know? Texugo (talk) 17:34, 7 August 2013 (UTC)

In this particular car, you could just remove it from Q14205680, which I've done. -- WOSlinker (talk) 17:52, 7 August 2013 (UTC)

You can move the item using the Move gadget (turn it on in the Wikidata preferences). Then Request deletion of the empty Q-page noting "merged with Q...". Globe-trotter (talk) 17:56, 7 August 2013 (UTC)

I've brought the issue of confusing error messages up at Wikidata here. Hopefully we can find a way of making error messages more helpful by linking to relevant pages. Del_♉sion23 (talk) 23:57, 7 August 2013 (UTC)

I've made the English error message more useful by making it provide links to pages on how to merge and delete. Thanks for the feedback :) Great to see Wikivoyage and Wikidata working well together. Del_♉sion23 (talk) 22:01, 8 August 2013 (UTC)

Thanks for the help! Texugo (talk) 23:59, 8 August 2013 (UTC)

Listings on Wikidata

Swept in from the pub

Swept in from the pub

I think it's time to collaborate with Wikidata. If started a request for comments to create a listing/vcard structure on Wikidata. At the end all listings should go to Wikidata to have them available on all language versions here. -- DerFussi 05:26, 10 August 2013 (UTC)

Fantastic idea, Stefan! Way to go!

Obviously some content is common to all languages using a Roman alphabet (or basic Latin subset of ISO/IEC 646: latitude, longitude, name?, etc) but wouldn't we have to develop common standards for other content such as telephone numbers, hours (18:00 v 18h00 or the US version of 6PM)? Or could that be handled automatically by switches?

I presume the "contents" field could never be automatically translated, but would need to have language codes to decide if it were displayed or not? --W. Frank^e-mail_talk 15:54, 10 August 2013 (UTC)

The directions, hours, or price fields also cannot be translated automatically, and the alt field will be particularly problematic, as it is sometimes a translation of the name field, other times the alt field contains the actual name in the local language and the name field is a translation, and still other times the alt field is simply an alternative name which may or may not need to be translated. Texugo (talk) 16:21, 10 August 2013 (UTC)

I'd venture to say that even address fields should be language-specific, particularly for bilingual/multilingual cities, where they have two or more sets of names for streets, roads, and such. Take Helsinki, for example: Swedish-language addresses are undoubtedly useful for sv:, whereas the users at fi: will rightly expect to find the Finnish names for streets, etc. (For en:, I think they decided to use the addresses in Finnish language, but there have been arguments for displaying Swedish-language addresses as well; see the discussion here: Talk:Finland#Bilingualism.)

And on a related note; I'm not sure if things turn out to be in that way as I'm not as much technically-minded as many users on this site are, but I'm afraiding of a future of an uneditable Wikivoyage, where everything is embedded in meaningless Wikidata links of letters and numbers, and you have to cross into another wiki even to edit the slightest slot on a listing. Vidimian (talk) 18:40, 10 August 2013 (UTC)

For Helsinki I think the Finnish language street names would suffice. In ads, on web pages, travel brochures and so on in English, German, Russian, French etc. I can't remember when I've seen the Swedish street names to be used. But there are other places like Brussels or Macau where they do use multiple languages and my proposal for those cases would be to write both street names with a slash between them. ϒpsilon (talk) 19:20, 10 August 2013 (UTC)

Note that it's probably best to make these comments at wikidata:Wikidata:Requests for comment/VCards for Wikivoyage since that's where the main discussion is taking place. -- Ryan • (talk) • 19:31, 10 August 2013 (UTC)

The discussion there is a Wikidata discussion. I understand that project is interested in some of the objective information we have here (addresses, phone numbers, entry fees, etc.) into database form. However, Wikivoyage itself has to discuss if/how to make use of the stored information. Discussing that on Wikidata is inappropriate as its a separate project with different goals. Globe-trotter (talk) 10:29, 18 August 2013 (UTC)

Access to data from Wikidata coming to Wikivoyage

Swept in from the pub

Last month Wikivoyage was the first sister project that gets their language links from Wikidata. A large part of the language links have been migrated by now from the articles' wiki text to Wikidata.

The next step is enabling access to the actual data on Wikidata for Wikivoyage. We are planning to do this on 26th of August. Once this is enabled you will be able to use data like the currency, country calling code and time zones from Wikidata if you want.

To use data from Wikidata in a Wikivoyage article you have two options:

• parser function. To get the country calling code for the country described by the article for example just use {{#property:country calling code}} or {{#property:P474}}.
• Lua. The details about access to data via Lua is explained at mw:Extension:WikibaseClient/Lua.

Important note: No articles will be changed automatically by the software to make use of Wikidata. Articles and templates will have to be adapted by you to make use of the data. meta:Wikidata/Deployment Questions answers some of the questions you might have. If you have further questions please do let me know. d:Wikidata:Wikivoyage migration has a number of people who are familiar with Wikidata and Wikivoyage who can also help you out in case you run into any issues.

I hope access to the data Wikidata can provide will help you make Wikivoyage rock even more. I travel a lot and Wikivoyage has proven to be extremely useful. Thanks for your work, folks :)

Cheers --Lydia Pintscher (WMDE) (talk) 13:59, 15 August 2013 (UTC)

Great! I am really looking forward to being able to use geolocation and other info from Wikipedia. Let's say I edit the Abadeh article, instead of searching the coordinates myself and entering "31°9'39"N, 52°39'2"E", I would just have to insert {{#property:coordinate location}}? Or do I need to somehow mention which Wikidata entity I am referring too?

As a pre-requisite, we really need to add [[Wikipedia:xyz]] to most of the 8000 articles that don't have one yet.

Also, the coordinates format is different from the one we use here, so we will need to see whether Leaflet and the other tools accept this format too, or in the worst case convert automatically. Nicolas1981 (talk) 07:49, 16 August 2013 (UTC)

For the moment you can only access data from Wikidata that is on the page that is connected to the one you are on. So for example if you are on the Wikivoyage article on Amsterdam then you can only use data that is on the Wikidata item about Amsterdam. There is no need to specify where you want the data to come from because of this. All that is necessary is that the Wikidata item has a link to the Wikivoyage article. We are working on changing it so that you can access data from any item. The bug to track progress on this is bugzilla:47930. --Lydia Pintscher (WMDE) (talk) 10:00, 16 August 2013 (UTC)

Will we be able to have Wikidata automatically handle WP and Commons links the same way it handles our interwiki links? Texugo (talk) 11:15, 16 August 2013 (UTC)

It will once bugzilla:52788 is closed and configured for you. And of course Commons needs to be enabled as a sister project on Wikidata for the Commons part of it. --Lydia Pintscher (WMDE) (talk) 12:21, 16 August 2013 (UTC)

Nice! Looking forward to being able to use Wikidata. Nicolas1981 (talk) 07:02, 19 August 2013 (UTC)

Special:UnconnectedPages

Swept in from the pub

As seen above, phase two of Wikidata implementation is coming soon, so it would be nice if we could get phase one finished up by that time. Special:UnconnectedPages lists pages which still have no connection to wikidata, and currently there appear to be 1551 main namespace articles without connections. Texugo (talk) 18:27, 15 August 2013 (UTC)

Some of these are disambiguation, such as Bangor, where a Wikidata item may make no sense. K7L (talk) 20:19, 18 August 2013 (UTC)

Access to data from Wikidata is now available

Swept in from the pub

Heya folks :)

I just wanted to let you know that from now on you have access to the data that is on Wikidata. To get a feeling for what kind of data we are talking about please have a look at the Wikidata item about Andorra. More is being added constantly. We hope this will be useful for you and help you continue to create great articles.

To make use of the data in an article or template you have two ways:

• Parser function. To get the country calling code for the country described by the article for example just use {{#property:country calling code}} or {{#property:P474}}. (There are still issues with properties related to coordinates and time when using the parser function. bugzilla:48937 and bugzilla:50277 are tracking these.)
• Lua. The details about access to data via Lua is explained at mw:Extension:WikibaseClient/Lua.

A few things to keep in mind:

• No article or template is edited automatically by the software behind Wikidata. You will have to adapt them by hand or using a bot to make use of it.
• Right now it is only possible to access data from the specific Wikidata item that the Wikivoyage article is linked to. We are working on making it possible to access data from other items as well. bugzilla:47930 is tracking the progress on this.

Please do let me know if you see any issues or run into problems.

Cheers --Lydia Pintscher (WMDE) (talk) 22:02, 26 August 2013 (UTC)

Great! I changed Andorra's hard-coded currency in the infobox to: {{#property:currency}}

and... it does not seem to work. I guess the result is empty, because the currency line of the infobox gets hidden. It let it in this state for anyone to check it. Do I have a syntax error or something? Nicolas1981 (talk) 05:18, 27 August 2013 (UTC)

Using the label of the property (currency) is supposed to work... I did switch it to P38 and it works, however. The best implementation though would be to edit the template itself and ask it to call Wikidata if there is no info already there. --Rschen7754 05:45, 27 August 2013 (UTC)

Thanks! I wikidatafied the currency, capital, tld, call code, timezone. As Rschen says, in the future templates should do this, but for now how about we concentrate on the Andorra article, and check whether it looks OK? Some properties do not fit the current Manual Of Style, I am in favour of modifying the MOS. One of the goal of the MOS was to standardize information representation (avoiding inconsistencies between articles by arbitrarily choosing one format ), but now I guess this goal can be transfered upstream, so that we use whatever format the Wikidata community agreed on. What do you think about it, should the MOS be modified to reflect this already? Nicolas1981 (talk) 06:09, 27 August 2013 (UTC)

Is capitalization the main issue? --Rschen7754 06:19, 27 August 2013 (UTC)

Also, for whatever reason the tld and call code are not showing up. --Rschen7754 06:59, 27 August 2013 (UTC)

{{#property:country calling code}} doesn't work in wy/uk site too, so it is general bug. --Voll (talk) 09:44, 27 August 2013 (UTC)

I've seen several reports about this now. I've filed bugzilla:53395. Sorry for the bug. We'll investigate and fix. --Lydia Pintscher (WMDE) (talk) 09:56, 27 August 2013 (UTC)

This should be fixed now. I'm closing the bug. If anyone still sees the issue somewhere please let me know and provide a link. --Lydia Pintscher (WMDE) (talk) 13:04, 11 September 2013 (UTC)

Nick, please be specific about what you want to modify in the MOS to account for Wikidata's display format. =) But I don't think you'll find much support for leaving "euro" lowercased; is there any way to adjust the capitalization of a string programmatically? LtPowers (talk) 14:45, 27 August 2013 (UTC)

LtPowers: Yes like you say "euro" is a point that differs. I guess our MOS has arbitrarily opted for a particular currency format, which might or might not be easy to convert to. How about we use the same formatting rule as the English Wikipedia? That would allow us to piggyback on their hard work in terms of specification and implementation of the potential transformations. By the way: There is another Nick here who is different from me ;-) Cheers! Nicolas1981 (talk) 05:44, 28 August 2013 (UTC)

It would have to be in Lua, if it could be done at all. --Rschen7754 06:50, 28 August 2013 (UTC)

euro can be uppercased with a parser function. {{ucfirst:euro}} - Euro -- WOSlinker (talk) 13:09, 28 August 2013 (UTC)

Ah, so there is... thanks! --Rschen7754 18:12, 28 August 2013 (UTC)

Case 1: Wikivoyage is more granular than Wikipedia

I disagree with the proposed solution in this case. What point is served by having Wikidata pages on travel regions that are set up only for our own organizational convenience, and which may not have equivalents on any other Wikivoyage, let alone any other Wiki? I also disagree with copying Wikipedia links from higher to lower levels of the hierarchy, as one link should be enough. LtPowers (talk) 17:49, 30 August 2013 (UTC)

Indeed, we might as well choose to not create Wikidata pages for entities that have no equivalent on any Wikipedia. Any piece of advice from Wikidata maintainers? About the second point: I strongly believe that viewers of the Eastern Finger Lakes article benefit from an hyperlink to the Wikipedia article Finger Lakes. Nicolas1981 (talk) 07:41, 2 September 2013 (UTC)

Why? If the reader wants to know about the Finger Lakes, he or she will read our Finger Lakes article and be able to link to Wikipedia from here. Besides, linking WV to WP many-to-one is conceptually a little weird. LtPowers (talk) 14:21, 2 September 2013 (UTC)

What happens when WP is more granular than WV?

I don't know how often this will come up, but what happens when WP is more granular than WV? For instance, there is a City of Langley and a Township of Langley in WP, but for WV purposes, they're all part of one Langley (British Columbia) article. We could have separate WV articles, but it doesn't make sense from a traveller's perspective (it's all considered "Langley" for getting around, addresses, transit, etc). -Shaundd (talk) 22:31, 4 September 2013 (UTC)

Pretty common on U.S. articles, where a village has the same name as the surrounding township. In the case of Palmyra (New York), I linked the village's WP article because that's where most of the action is -- but even then that technically omits several of the most important sites, which are actually outside the village (and some in a neighboring town). LtPowers (talk) 13:21, 5 September 2013 (UTC)

Integration of Wikidata in Listings

Swept in from the pub

I created phab:T141345. It would be great if you could comment on it. Thanks, -- T.seppelt (talk) 08:43, 26 July 2016 (UTC)

Isn't one of the problems that Listings on de-WV work and look differently from those on en-WV? I think you have "vcards" or something of the sort. Hobbitschuster (talk) 15:29, 26 July 2016 (UTC)

No no no. Totally against this idea. We have enough trouble already trying to grow our community and convert casual readers to editors; we should be making it as easy as possible for newbies to contribute, not forcing them to navigate the arcane labyrinth of Wikidata (I've been a regular editor for almost five years and I still have trouble with WD). T.seppelt, before taking this issue to Phrabricator, you really should have brought this up at the Pub first and figured out whether our community even wanted to cede this very important piece of functionality over to Wikidata. -- AndreCarrotflower (talk) 15:45, 26 July 2016 (UTC)

This is an open process and the ticket is for brainstorming and comparing ideas with technical possibilities. Nothing big is going to change in the next weeks and your input is very welcome. And I think forcing people to use Wikidata is in this case not a good idea. But we should find a solution to combine the forces of the different Wikivoyage language versions and create a better experience for the readers and users. --T.seppelt (talk) 15:50, 26 July 2016 (UTC)

@AndreCarrotflower: Sharing data via Wikidata would undoubtedly be a good thing, although you are correct that it will be important to get the implementation correct so that it makes things easier for users rather than harder. I've done some work recently on using Wikidata in listings (see Wikivoyage talk:External links#Listing editor changes) and I think there are a handful of others who might also be able to provide firsthand feedback. Unfortunately I don't have time to provide a detailed response right now, but there is definitely benefit to the idea and it would be counter-productive to have efforts to put better tools & infrastructure in place summarily shut down since we can't make better use of Wikidata here until the tools available from Wikidata have been improved. -- Ryan • (talk) • 16:26, 26 July 2016 (UTC)

Although I can see some advantages with getting data from Wikidata I agree with AndreCarrotflower, this is again alienating casual users. All this moving of activities and discussions to phabricator and editing to wikidata is great if you are computer programmer and active in the wikimedia sphere but for most people on the web this is an alien world and is totally undiscoverable. Until there is an easy and clear way to edit wikidata from Wikivoyage or Wikipedia then we should move carefully in this direction. --Traveler100 (talk) 20:14, 26 July 2016 (UTC)

I think there is some misunderstanding. Wikidata offers the potential of being able to build easy-to-use tools for editors that opens up a huge amount of valuable shared data for use in the travel guides on this site. HOWEVER, there is work that must first be done to ensure data can be stored in Wikidata, that it can be easily accessed, etc. These sorts of phabricator tickets lay the groundwork for future tools that offer the potential of very easy, very useful Wikidata integration that Wikivoyage could then either take advantage of or ignore. Opposition now is essentially telling willing developers not to do the groundwork necessary to make potentially valuable features available in the future. -- Ryan • (talk) • 21:18, 26 July 2016 (UTC)

I am not against developing new functionality, just saying the functionality should be aimed at causal users of the site. After the way the map changes went I am a little sceptical, changing the reading facing UI with a regression in functions. --Traveler100 (talk) 05:31, 27 July 2016 (UTC)

I worked it on a first implementation. Module:Listing is the result. It should have exactly the same functionality as Template:Listing, but additionally and only in case nothing can by found locally data is loaded from Wikidata. Please have a look at Template:Listing/test. You can test how it works be going e.g. to Template:See, changing the first line to {{listing/test... and use the preview form to display any page with the new template. What do you think? There is a known issue regarding the CSS of links which I still try to solve and not all parameters are matched with Wikidata properties. -- T.seppelt (talk) 15:58, 27 July 2016 (UTC)

These sorts of experiments are useful in determining how to better implement integration with Wikidata and to improve the underlying pathways, and I would encourage more of them. That said, you're viewing this updated listing template as a proof-of-concept rather than something that is proposed for actual implementation, right? As noted above, Wikidata implementation needs to be transparent to most editors, so while I very much support the idea of making better Wikidata integration possible, that integration needs to be transparently added to existing templates and tools in easy-to-use ways - a solution that forces users to go to Wikidata to edit a listing would not be viable. -- Ryan • (talk) • 17:48, 27 July 2016 (UTC)

I agree with Ryan. From a technical perspective, it’s cool that the integration can work and there can be local overrides. But from a usability perspective, it reinforces my belief that integration with Wikidata should be invisible to users (those Wikidata pages are not user friendly). -Shaundd (talk) 18:05, 27 July 2016 (UTC)

I'm not going to pretend to understand all that programming language in Module:Listing, or its effects on how Wikidata-integrated listings would operate in practice. But Ryan hit on my exact concern in his above comment. Encouraging casual readers to get over their intimidation and self-doubt and understand that their contributions are welcome and in fact essential, and that they don't have to be any kind of expert or have any kind of credentials as a writer or whatnot - that's already a pretty formidable hurdle that we haven't quite figured out how to clear. I might be talked into supporting Wikidata-integrated listings if the process is straightforward and user-friendly, but any scenario wherein the editing of Wikivoyage takes the end user to a site other than wikivoyage.org is, I think, a nonstarter. To newbies, Wikidata is the darkest and most obscure corner of the WMF network - unlike Wikipedia which is an encyclopedia, Wikivoyage which is a travel guide, etc., Wikidata has no utility to casual users; its only purpose is to facilitate integration between different WMF sites. As such, I can imagine very few editors who aren't already familiar with the behind-the-scenes inner workings of the WMF would know what to make of Wikidata, or to be motivated to bother decoding how to use it as a Wikivoyage editor-by-proxy. Furthermore, as Shaundd said, the Wikidata interface is also hideously user-unfriendly. -- AndreCarrotflower (talk) 19:35, 27 July 2016 (UTC)

I think one of the several reasons for the crisis Wikipedia has been experiencing for quite some time now is that it has gotten too complicated for the "non-initiated" to contribute. A Wikivoyage article with its scant amount of templates and tables and other fancy programming shebang (sorry for the wording) is way easier to write for someone who knows the topic and how to write but not programming. I hope we can keep it that way. Hobbitschuster (talk) 22:26, 27 July 2016 (UTC)

It is from my perspective that the casual user/editor be kept from being alienated from contributing simply by keeping the old motto: "KISS (Keep It Simple Stupid)". Coding that allows some event to occur should in most cases be simply hidden as it is within the listing editor, visual editor, templates, gadgets, extensions, .js, .css etc. in order to shield one from coding creep and overload. Users come from many different levels of expertise. I come from a background where it was an absolute necessity to know wiki code markup, javascript, css, python, a definite understanding of templates and how they work, working with an api and how to write and use extensions. A knowledge of the mediawiki file structure and mediawiki's inner workings were also a must. I also have a database, typesetting and text processing background. I find that the casual user/editor does not need to be an expert in all of these areas, but should be encouraged to contribute information (content) for various articles which may be lacking. These contributors IMHO provide an essential portion of the bread and butter for Wikivoyage and should not be alienated.

I have a tendency to write my own tools that I use in sandboxes mostly for doing some basic analytical/editorial work such as comparing TOCs from different articles, creating a basic list of words found in an article, checking an article for red linked images in articles or those found in listings etc., conversion of markers and listings to maplinks, grabbing pieces of information from wikidata such as latitude and longitude, creating basic markers and listings for sister cities and other entities, build tables and find various url (wiki links) for an article among other things. These are not something the casual user would have use of. The basic point I think is that there are tools and there are tools; from the simplistic to the complicated; (some of which are not for the faint hearted) - each with some purpose in mind and useful for users of different degrees. We as a community collectively have to settle down and discuss Who, What, Where, How and Why as well as user impact. Perhaps these discussions could be pursued more appropriately on Wikivoyage Request/Suggestion page(s). -- Matroc (talk) 01:35, 28 July 2016 (UTC)

Thank you for your input. I think the main finding of this discussion is that we need better tools to make editing of listings as simple as possible. I imagine that the difference between editing listings locally and on Wikidata for example with the listing editor can be made almost not existing (see phab:T141345 again). Next steps could be to integrate Wikidata in the listing editor and in the visual editor plugin which is going to arrive to Wikivoyage. Matroc, can you help with the coding work? -- T.seppelt (talk) 06:07, 28 July 2016 (UTC)

T.seppelt - If I was 45 or more years younger I would be glad to assist in a coding effort; however, for business and personal reasons I am going to have to decline. -- Matroc (talk) 01:16, 29 July 2016 (UTC)

I think that a few important things were missing in this discussion:

• First, the main goal of using Wikidata is the synchronization of information between different language versions, but there is no way to synchronize individual listings without assigning them unique identifiers, such as Wikidata IDs. This job will not be done by these precious casual editors who are "completely unfamiliar with Wikidata". It has to be done by someone who is familiar (on a very basic level, though), but so far there was little interest in doing such a work, and, to the best of my knowledge, Wikidata field is not even available in the listing editor. According to Syced, English Wikivoyage has as many as 46 listings with the Wikidata identifier, and at this point our only hope is to synchronize the data between French and Russian Wikivoyages, where this number is about 50 times higher.
• Second, each listing should have a separate Wikidata item, which is easy for major attractions already having their own Wikipedia articles, but I am not sure that Wikidata allows to create listings for all the cafes and hotels, including those that may have ceased to exist. If there was a discussion with the Wikidata community, could anyone give me a link? Wikidata requires that all information is verified, bust most of the data from Wikivoyage is not verified because it is based on the original research and lacks proper sources (in Wikipedia sense).
• Third, we have discussed which information could be potentially shared, and arrived at the conclusion that only geographical coordinates and phone numbers/e-mails/URLs can be shared easily. Addresses may be language specific, whereas opening hours and prices are always language-specific. While it may be possible to overcome these difficulties, a lot of work and discussion on Wikidata will be required in order to agree on the format that they can accept. If anything, I would start such a discussion on Wikidata and not here.

After thinking it all over once again, I am not even sure that this whole story is worth the effort, given the current understanding by the community and their (lack of) interest in this project. --Alexander (talk) 08:09, 28 July 2016 (UTC)

Glad to see this discussion happening :-) My views:

• I believe that an easy-to-use editor would make everyone happy. For that, some of us need to take time to get familiar with the technologies involved, and implement it. Not easy but a necessary step.
• We can't switch overnight to storing everything in Wikidata. As a goal for the new 3 years, we should probably restrict ourselves to items that are already present in Wikidata. The listing editor should check whether a Wikidata property is present or not, and accordingly use the right backend.

Cheers! Syced (talk) 09:17, 28 July 2016 (UTC)

The French Wikipedia has 6090 listings with a Wikipedia attribute, I checked just now. These Wikipedia attributes can easily be translated to a Wikidata identifier. These were entered manually by the French editors. Once the listing editor gets a gadget allowing easy search and selection of the relevant Wikidata item (via its label), I am sure the English Wikipedia can reach 10,000 items in no time. That would mean 10,000 less latitude/longitude to care about. Syced (talk) 08:29, 29 July 2016 (UTC)

I'm in favor of having 10,000 fewer latitude/longitude pairs to care about.

What's the most useful thing non-technical people could do at this stage? For example, should we be adding the (undocumented but apparently extant) |wikipedia= items to listings for major attractions? (I'm assuming that a bot could easily translate from a Wikipedia article to a Wikidata number.) WhatamIdoing (talk) 08:37, 1 August 2016 (UTC)

The discussion about the implementation and rollout of the "wikipedia" and "wikidata" fields for listings has been going on for a few months at Wikivoyage talk:External links#Listing editor changes and provides more detail about changes to the listing editor for these fields, support in listing templates, etc. The fields were just enabled two days ago, so at this point patience is probably necessary as feedback is solicited and support is improved. If you want to add "wikipedia" and "wikidata" attributes to listings by all means go ahead, but it will be much easier to do so, and to then use the "wikidata" field to lookup lat/long and other shared data, once the listing editor has been updated. -- Ryan • (talk) • 15:22, 1 August 2016 (UTC)

I like the W and Wikidata icon appearing at the end of the listings by the way. -- Matroc (talk) 02:33, 2 August 2016 (UTC)

Updating Wikidata items when moving pages

Swept in from the pub

I've been inactive for a while, so maybe I missed explanations given before. I must confess I haven't put the least bit of effort into working with Wikidata, and to be quite honest, I don't intend to. I understand why it's very useful, but that part of the wiki is just not my cup of tea at all. I like travel-prose, not technical lists. When I write a new article, I just don't do anything about it, and someone else will :) So far so good. When moving a page however, I'm not sure if it's visible for others that the wikidata item is now incorrect? Should I attach any kind of tag, or is there a simple correction I can make that will put it on the radar? For example, we have articles on rural municipalities that cover a number of small villages and hamlets. It wouldn't make sense to have articles for all of them, but wikidata has entries for even tiny places. Should the redirects have the relevant wikidata entries? I moved Leek (Netherlands) today. When moving a page, users get a warning to also fix the wikidata entry, but I don't think we should expect all users to know how to. JuliasTravels (talk) 10:23, 8 August 2016 (UTC)

Having the wikidata item point to the redirect is the right thing, but there is some magic involved, such that the item might get (semi?)automatically changed according to page moves or redirects. --LPfi (talk) 18:11, 8 August 2016 (UTC)

I see... That doesn't really give me (or other non-wikidata users) any pointers to what to do in case of a move, though :) JuliasTravels (talk) 10:11, 10 August 2016 (UTC)

Wish there was some MAGIC - Need to change enwikivoyage link in Wikidata to Westerkwartier -- which I just found has been corrected by Julius. I will go ahead and check the Wikipedia inline reference to wikivoyage and change that... - Matroc (talk) 19:40, 12 August 2016 (UTC)

On sv-wp they said you need to connect an item to Wikidata while it is not a redirect to avoid Wikidata using the target article instead of the redirect. Thus creating redirects you need to create the page, connect it to Wikidata and then make it a redirect. Moving a page should not destroy the connection. In the case with many tiny places one should probably assure the real article has a Wikidata item before starting to create redirects, or create them with the three-step approach.

When our article is about a non-administrative region we have the problem it usually does not match any existing Wikidata item, but should get its own before it gets connected to something badly wrong – having it connected to the main town it tells about or an approximately matching administrative entity is probably not a big problem, but having it accidentally connected to one of the hamlets is not good.

--LPfi (talk) 05:27, 15 August 2016 (UTC)

Fetch coordinates from Wikidata

Swept in from the pub

Hello, I just listingyfied all the stops of the Amtrak Cascades. Is there some way to tell it to get the Wikidata items from the associated WP links and from thence the coordinates for a dynamic map to be less work? Hobbitschuster (talk) 22:44, 13 July 2017 (UTC)

You could try the code for coordinates from Template:Listing/test. Maybe a bot could add "wikidata=" based on "wikipedia=". Jura1 (talk) 22:59, 13 July 2017 (UTC)

Is there any easier way to do this? I don't want to write a bot tbh (and I don't know how to do that either) Hobbitschuster (talk) 18:43, 14 July 2017 (UTC)

Yes it is not a long list of locations, click on each article, edit and read the coordinates from the geo tap at the bottom of the article, then copy paste. —The preceding comment was added by Traveler100 (talk • contribs)

Well, it could solve it for every listing in Wikivoyage. d:Wikidata:Bot requests might find someone who can do it. Jura1 (talk) 19:30, 14 July 2017 (UTC)

Update

Page was a little out of date, have updated some sections but could do with a little more work. --Traveler100 (talk) 09:13, 2 June 2018 (UTC)