Wikivoyage talk:Cooperating with Wikidata/Archive 2019-2020

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

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