Wikivoyage talk:Cooperating with Wikidata Voyage Tips and guide

Archived discussions Wikivoyage talk:Cooperating with Wikidata/Archive 2013-2018

Contents

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)Reply

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)Reply

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)Reply

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)Reply

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... -- andree.sk(talk) 20:03, 20 November 2020 (UTC)Reply

@Andree.sk: I didn't quite understand your question. Soshial (talk) 09:46, 21 November 2020 (UTC)Reply

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... -- andree.sk(talk) 12:04, 21 November 2020 (UTC)Reply

@Andree.sk: 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)Reply

@Andree.sk: please, have a look in this section (or at this Template:GEL)! The template returns error. Soshial (talk) 14:33, 8 December 2020 (UTC)Reply

@Soshial: - I have it in my plans, but sadly time is sparse :) I'll try to give it a shot this week! -- andree.sk(talk) 19:58, 8 December 2020 (UTC) ...or before the end of the year, then......................... :-) -- andree.sk(talk) 06:00, 14 December 2020 (UTC)Reply

@Andree.sk: 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)Reply

@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.01319. 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.)... -- andree.sk(talk) 20:16, 4 January 2021 (UTC)Reply

@Andree.sk: 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)Reply

@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.01319 / 0.29849996. Cheers. -- andree.sk(talk) 19:54, 5 January 2021 (UTC)Reply

@Andree.sk: 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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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.

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)Reply

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)Reply

Swept in from the pub

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)Reply

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)Reply

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)Reply

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). :-) Andree.sk (talk) 20:10, 25 May 2018 (UTC)Reply

Swept in from the pub

For hotels, there is now a new tool/form at: https://tools.wmflabs.org/wikidata-todo/cradle/#/subject/hotel

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)Reply

@Jura1: the tool doesn't allow entries to be saved yet, is that correct? ArticCynda (talk) 15:25, 3 August 2018 (UTC)Reply

• One needs to login with "Widar" first. There is a link at the top right corner or here: https://tools.wmflabs.org/widar/index.php?action=authorize Jura1 (talk) 15:29, 3 August 2018 (UTC)Reply

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)Reply

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)Reply

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) Andree.sk (talk) 16:50, 3 August 2018 (UTC)Reply

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)Reply

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)Reply

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)Reply

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... :-) Andree.sk (talk) 06:53, 4 August 2018 (UTC)Reply

• 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 www.wikidata.org ? 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)Reply

Swept in from the pub

Hello Andree.sk, 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.

• It is called Wikidata Extractor
• Overview maps similar to the one for Prague can be created relatively quickly

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)Reply

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 geojson.io), that would be sweet. But even this so far is nice  :) Andree.sk (talk) 10:40, 9 August 2018 (UTC)Reply

For regions, which are completely independent of any official boundaries the GeoJSON has to be created manually (with tools like geojson.io 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)Reply

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 :-) Andree.sk (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)Reply

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. Andree.sk (talk) 11:21, 9 August 2018 (UTC)Reply

@Andree.sk: 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)Reply

Thanks, that's interesting! --Alexander (talk) 11:20, 9 August 2018 (UTC)Reply

Wow, thanks! This tool is much better than manual lookups. MSG17 (talk) 22:14, 27 September 2018 (UTC)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

Hi Ar2332, the geometry type was set to "LineString" instead of "Polygon". I fixed it. --Renek78 (talk) 20:44, 23 October 2018 (UTC)Reply

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)Reply

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)Reply

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)Reply

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)Reply

Longitude (in your case 144) comes first. Then latitude (e.g. -37). You can best understand it by going to geojson.io, 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)Reply

I see. I was confused because Wikivoyage "mapmask" uses the opposite order. Thanks! Ar2332 (talk) 14:30, 25 October 2018 (UTC)Reply

Welcome! Until now I don't know why it is the other way round for Mapmasks... --Renek78 (talk) 19:22, 25 October 2018 (UTC)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

Fixed. You had the same lat+long hardcoded in the marker template (probably copy+pasted?)... -- andree.sk(talk) 06:29, 18 August 2020 (UTC)Reply

Thanks for this, @Andree.sk. From the edit summary, it sounds like Wikidata was the solution, not the problem. WhatamIdoing (talk) 20:27, 18 August 2020 (UTC)Reply

Yup... :) -- andree.sk(talk) 05:38, 19 August 2020 (UTC)Reply

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)Reply

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)Reply

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)Reply

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)Reply

Yes, I've been told it can be done, particularly with Lua modules. NMaia (talk) 02:01, 22 September 2020 (UTC)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

See Wikivoyage talk:Time and date formats#Expanded short names for days of the week. WhatamIdoing (talk) 15:46, 23 September 2020 (UTC)Reply

(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)Reply

Because formatting content is faster that looking up content plus formatting it. WhatamIdoing (talk) 15:49, 23 September 2020 (UTC)Reply

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)Reply

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)Reply

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)Reply

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)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ 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)Reply

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)Reply

Swept in from the pub

Apologies if this has been asked before.

I've been experimenting with Wikidata imports for attractions in Wikivoyage articles. When I use the listing editor to add a new listing and insert the Wikidata value into the proper field, I see the option to sync fields from Wikidata. Unfortunately this doesn't seem to work consistently. For example with this POI: Q104213978. The Wikidata record contains information for address, opening hours, phone number, and even entrance fee, but none of these are "found" by the listing editor. No matter what I try, the listing editor only seems to be able to retrieve values for website URL, email address, and coordinate location.

Am I doing something wrong? Is anyone else also having trouble automatically retrieving other data fields from Wikidata? Or are these features not implemented yet? —The preceding comment was added by 87.74.129.131 (talk • contribs)

Sadly the listing editor here at en-wv is only able to fetch data from Wikidata for a few values, but not all. I don't know whether that was a deliberate community decision or just something the volunteers who do the coding have not gotten around to yet. Hobbitschuster (talk) 19:41, 16 December 2020 (UTC)Reply

In that case I'd much rather spend time on updating/developing the listings editor than on manually copy-pasting data over from Wikidata to Wikivoyage listings -- which would then go out of date pretty quickly anyway. Would you happen to know where the code for the listings editor "lives"? Is this a public repo that accepts pull requests? 87.74.129.131 14:20, 17 December 2020 (UTC)Reply

Some of the WD fields which are mentioned are fairly new. For example the opening time field was only created on 21 September 2020, and so I doubt that many listings would return useful data. So in this case I would suggesting waiting a few months to let the listing editor catch up. AlasdairW (talk) 22:27, 17 December 2020 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ The main problem is that several (new) properties are not simple string values, or they are using additional qualifiers. These values cannot be fetched with simple template parser functions. Both the import to the listing template and the listing editor require huge efforts in programming these scripts. Maybe, a complete reprogramming is necessary.

I think that the import of Wikidata data to the listing template should be avoided because the listing template should fetch them directly from Wikidata. Only the data on Wikidata should be updated so they can be used in other Wikivoyage branches, too.

At the German Wikivoyage we made the reprogramming which is now basically finished. The listing/marker package is huge -- really huge, and its programming took four years. Now we are able to fetch almost all useful data from Wikidata (more than 50 properties including their qualifiers) among them opening hours, hotel/restaurant facilities and features, booking.com urls and so on. Some of these parameters like booking.com urls cannot be entered to the listing template at all because they are exclusively fetched from Wikidata.

So, the listing template call can be really short similar like this:

• {{listing | name = Alchimistenklause | type = restaurant | wikidata = Q98116402 | auto = y | content = ... }}, or shorter
• {{listing | wikidata = Q98116402 | auto = y | content = ... }}

At the moment we are testing the usage at the Esperanto Wikivoyage and looking for problems and additional features needed. Within the next weeks we will add the fetching of more Wikidata values and the support of parameter aliases in the listing editor. Then, the listing editor will be able to import all Wikidata values available. Because of the complexity of the Wikidata properties we will not add support to export listing data to Wikidata within the listing editor.

After the addition of some new features to the listing editor we can answer which features are necessary for the listing editor and how to implement them. After this, a reprogramming of the listing editor is necessary: to remove jQuery UI and to add Mediawiki's OOUI (user interfaces), to make the editor available on mobile devices, too. It will take much time. --RolandUnger (talk) 08:00, 18 December 2020 (UTC)Reply

For some examples of current opportunities, see the examples at de:Module:VCard/Doku. --RolandUnger (talk) 08:15, 18 December 2020 (UTC)Reply

Wow I'm very impressed by the technical capabilities of the VCard module on de-wv, RolandUnger! I only have limited experience, but what you say makes sense to me: rather than synchronising/importing data fields, dynamically retrieving them from Wikidata ensures they're always up-to-date. It seems logical that business owners would much rather update their information centrally (on Wikidata) once rather than updating every Wikivoyage language article individually. And it makes articles less cluttered by reducing the length of listings, too.

What's the philosophy behind the "sync" button in the listing editor? With the above in mind, this now feels counterproductive rather than an asset to the project. 87.74.129.131 11:56, 18 December 2020 (UTC)Reply

sadly de-wv and en-wv have not always cooperated well, owing in part to the history of the fork... For example, en-wv has decided to not link to aggregators such as booking.com As for the decision regarding the "sync" functionality, I think this is to enable easily copying values to wikidata that were input locally as well as choosing deliberately to have certain values different for wd and wv (e.g. Coordinates for the center of a park on wd but the main entrance on wv; the native link on wd but the English language link on en-wv). There may also be aesthetic preferences regarding "clutter" and the fact that the source text of Wikipedia pages can look daunting to first time editors leading to a desire to reduce templates to a minimum. Whether this is a wise decision or was one but no longer is one is a different question. Hobbitschuster (talk) 13:53, 18 December 2020 (UTC)Reply

Thanks for elaborating on that, I wasn't aware of those subtleties. Looking at the VCard documentation page, de-wv doesn't seem to mind clutter all that much, as evidenced by padding links for Twitter, Youtube and the likes to listings. That seems undesirable to keep articles "clean". However if so much development time and effort has already been invested by our German friends, then it would be silly to not at least try to re-use their work on en-wv as well (instead of developing similar functionality from scratch again). 87.74.129.131 18:50, 18 December 2020 (UTC)Reply

There are similar rules at Wikivoyage/de as on Wikivoyage/en. We do not make links to booking.com or other aggregators in the article itself. The ids of the aggregators are noted only in data-fields of the wrapping span/div container to get them without an access to Wikidata. But there is another rule for us: The traveler comes first. We like to give all information which is useful to travelers. That's why we added an additional Javascript tool named listing info which shows information for taxi drivers and passerbys to help the traveler. This dialogue can display different information including the aggregators links to a location, too.

I am not really sure of the real functionality of "sync". But the data at Wikidata are to complex, and sync can handle only strings so it will fail in many cases like hours or phone numbers with comments. That's why the listing editor at Wikivoyage/de will only fetch data from Wikidata to display (usually not to import to the source code) but it will not export data to Wikidata.

And I do not like to hide an information: if you are fetching data from Wikidata then they do not appear in the original source code. So people who use information from Wikivoyage should not use the simple source code to parse but the expanded source or html code. --RolandUnger (talk) 09:45, 21 December 2020 (UTC)Reply

It is true, that there is no cooperation between Wikivoyage/de and Wikivoyage/en. But this is not caused by Wikivoyage/de. Our admins and authors helped and help Wikivoyage/en, for instance user:Mey2008 in case of map development, and I gave support at the beginning of Wikimedia-based Wikivoyage, I am helping to administrate English Wikivoyage and I am giving information to the local community. Normally, all that information is ignored. Otherwise I've got a notion that the English community is not interested in ideas developed in other communities and they think only the decisions made the English community is the real deal.

It is correct that social media services are shown at the German Wikivoyage. But the same is done at the English Wikivoyage using the url parameter. The main difference is that social media are marked as social media at the German Wikivoyage but not at the English one. Our scripts are divided into code and localization modules and it is easy to configure local implementations. So, social media can be excluded easily. --RolandUnger (talk) 10:26, 21 December 2020 (UTC)Reply

I would certainly like to coordinate more closely between different Wikivoyages. I'm not very technical, though. Should we have a different thread that enumerates the differences between the Wikivoyages and discusses what we could do to make them more directly compatible with one another? Ikan Kekek (talk) 16:05, 21 December 2020 (UTC)Reply

I think it is not mainly a problem of compatibility. We at German Wikivoyage try to remain downward compatible with other Wikivoyages. Of course we can discuss/explain the developments at least at the German and Italian Wikivoyages. But it takes time which we should use to improve Wikivoyage. While we at the German Wikivoyage hurrying ahead and making decisions as fast as possible, people at the English Wikivoyage seem not to be interested in or hinder further developments. Programmers at the English Wikivoyage are not really supported by the community, many of them left Wikivoyage or stopped working as a programmer (for instance Mey2008, Ryan/Wrh2). Now, only Andyrom75 from the Italian community is working on scripts. Maybe the English community should discuss first what it really wants to achieve now and in future.

I was also really surprised on the (missing) reaction of the English community when user NMaia announced the establishment of the Wikidata hours property. He made a good job at Wikidata and now at the Esperanto Wikivoyage. And he thought that he would get support by the English community in that case (only I supported him). But this community was indifferent towards his announcement. --RolandUnger (talk) 15:29, 22 December 2020 (UTC)Reply

I thought I remembered a number of us being interested. I was. Ikan Kekek (talk) 20:50, 22 December 2020 (UTC)Reply

Yep. Roland, what interest were we supposed to show other than thanking Nmaia, asking questions, and raising concerns (which is what happened)? When and where has English Wikivoyage hindered developments by other language versions of WV?--ThunderingTyphoons! (talk) 23:30, 22 December 2020 (UTC)Reply

I commented at Wikidata:Property talk:P8626, but didn't get an feedback on how this works if different days have different opening times. AlasdairW (talk) 23:48, 22 December 2020 (UTC)Reply

Swept in from the pub

Why would anyone (who doesn't edit) want to click it on. An example of one can be found here (Bhandra Fort) Tai123.123 (talk) 05:44, 2 November 2021 (UTC)Reply

It's mainly for doing a quick fetch of data available. SHB2000 (talk | contribs | meta.wikimedia) 06:40, 2 November 2021 (UTC)Reply

I think that's fine to do, but what about a Wikidata infobox? I say no, no way, and I will revert that edit. Ikan Kekek (talk) 07:58, 2 November 2021 (UTC)Reply

Ditto as well. No Wikidata infoboxes please. That template doesn't even work properly. SHB2000 (talk | contribs | meta.wikimedia) 08:04, 2 November 2021 (UTC)Reply

The Wikidata page itself is probably just confusing for most users, but in addition to automatically add e.g. coordinates and the Wikipedia link as soon as an article is written (and that article is useful for many), some readers may use it to find a Wikipedia article in some other language when there is none in English. For editors the icon avoids the need to manually copy use the id to construct the address (and not all editors would do that routinely). –LPfi (talk) 09:12, 2 November 2021 (UTC)Reply

Ok thank you, I didn’t realize it automatically added the Wikipedia page (I thought they had to be added in the wikipedia section). I will probably stick to manually adding coords and Wikipedia as I don’t feel the Wikidata button is useful. Tai123.123 (talk) 14:37, 2 November 2021 (UTC)Reply

If you add coords, and a Wikidata item, then you can send your coords to Wikidata, which helps all the other Wikivoyages that might link to that location. WhatamIdoing (talk) 16:27, 2 November 2021 (UTC)Reply

It might also be useful for WP articles too, although I'm not too sure on how that works. SHB2000 (talk | contribs | meta.wikimedia) 05:43, 10 November 2021 (UTC)Reply

That kind of information will be used automagically by some Wikipedias, including Russian and Spanish (assuming there is an article for the attraction), but not by the English Wikipedia. WhatamIdoing (talk) 17:05, 10 November 2021 (UTC)Reply

Top of the page has notice: This page is an incubator for ideas on how to work with Wikidata. This is not a policy document....and I wonder if there are policy documents that are fixed and should be linked here? --Zblace (talk) 09:00, 21 January 2022 (UTC)Reply

{{}}

Danny Benjafield (WMDE), thanks for this note. This site still uses the old Vector skin. There are currently two links in the sidebar:

1. "Tools": Wikidata item to d:Special:EntityPage/Q16503
2. "In other projects": Wikidata to d:Wikidata:Project chat

Will both of those links now be in the same section, or is the plan to remove one of those links? WhatamIdoing (talk) 19:49, 27 September 2024 (UTC)Reply

There hasn't been any link to the wikidata item in "in other projects" on most pages. Project pages are special in that there may be an equivalent on Wikidata, in addition to the item page.

I think "in other projects" for this page should link to the Wikidata project chat, but according to Wikidata policies (cf Commons categories), I assume it will link to the item, unless we get two Wikidata entries in that section.

–LPfi (talk) 09:40, 28 September 2024 (UTC)Reply

I think there should be two links on nearly all pages in the mainspace, as well as many templates and help pages. WhatamIdoing (talk) 19:40, 28 September 2024 (UTC)Reply

Hello @WhatamIdoing, both of those links will move into the new section (In Other Projects). A ticket on this topic can be found on our workboard (Phabricator: T372566) and we will be investigating if any further work to differentiate those 2 links is required. -Danny Benjafield (WMDE) (talk) 12:46, 30 September 2024 (UTC)Reply

That sounds okay to me. As long as we've got both links available, I think we'll learn which one does the thing we need. WhatamIdoing (talk) 16:35, 30 September 2024 (UTC)Reply