Francis Schonken (talk | contribs) |
→Implementation of RfC: Reply |
||
Line 276: | Line 276: | ||
****The RfC requires a revert to the previous version. What you propose is the opposite, you want to simply rename the template to /Wikidata and be done with it (oh, you also suggest that others can copy the Wikidata data locally, as if the Wikidata data is infallible. You seem to haven't grasped what this RfC was about). I guess simply moving all instances to the UNESCO version of the template manually will be the best solution then? [[User:Fram|Fram]] ([[User talk:Fram|talk]]) 08:25, 3 November 2017 (UTC) |
****The RfC requires a revert to the previous version. What you propose is the opposite, you want to simply rename the template to /Wikidata and be done with it (oh, you also suggest that others can copy the Wikidata data locally, as if the Wikidata data is infallible. You seem to haven't grasped what this RfC was about). I guess simply moving all instances to the UNESCO version of the template manually will be the best solution then? [[User:Fram|Fram]] ([[User talk:Fram|talk]]) 08:25, 3 November 2017 (UTC) |
||
***** You might want to read what I said again, and try to take it in this time. There was nothing above about not having a separate Wikidata version. I was suggesting we move things over to there *for now* so this version of the template can be changed to a non-Wikidata one, and then the current cases can be migrated back by whoever wants to do so (I suggested one way, you're welcome to suggest others). Again, *I checked through the Wikidata info for the ones I migrated*, and what is on Wikidata for those is at least as good as what was here before, at least for the core parameters (WHS ID, criteria, years), so I see no benefit to undoing those. We can remove things like area if you'd like, which weren't included in the template before anyway. Thanks. [[User:Mike Peel|Mike Peel]] ([[User talk:Mike Peel|talk]]) 08:42, 3 November 2017 (UTC) |
***** You might want to read what I said again, and try to take it in this time. There was nothing above about not having a separate Wikidata version. I was suggesting we move things over to there *for now* so this version of the template can be changed to a non-Wikidata one, and then the current cases can be migrated back by whoever wants to do so (I suggested one way, you're welcome to suggest others). Again, *I checked through the Wikidata info for the ones I migrated*, and what is on Wikidata for those is at least as good as what was here before, at least for the core parameters (WHS ID, criteria, years), so I see no benefit to undoing those. We can remove things like area if you'd like, which weren't included in the template before anyway. Thanks. [[User:Mike Peel|Mike Peel]] ([[User talk:Mike Peel|talk]]) 08:42, 3 November 2017 (UTC) |
||
******"There was nothing above about not having a separate Wikidata version." apart from "as things currently stand, the Wikidata-based template is not suitable for use in en.wiki" you mean? You checked through the Wikidata info when you migrated them, and you didn't notice any of the problems that caused the RfC and its end results, or you didn't think them important? I think we can handle this without more help from you. [[User:Fram|Fram]] ([[User talk:Fram|talk]]) 10:41, 3 November 2017 (UTC) |
|||
****{{edit conflict}} A few additional considerations: |
****{{edit conflict}} A few additional considerations: |
||
****#[[Wikipedia:There is no deadline|There is no deadline]], meaning: it is better to do this conscientiously than in a rush. No time-table has been set on ''when'' to re-introduce the local-parameters-only code into this template yet. Doesn't mean we have to be lethargic, or that we couldn't set ourselves some goals on when the operation should be complete, but rather aim at good work than overhasty bot operations and the like. |
****#[[Wikipedia:There is no deadline|There is no deadline]], meaning: it is better to do this conscientiously than in a rush. No time-table has been set on ''when'' to re-introduce the local-parameters-only code into this template yet. Doesn't mean we have to be lethargic, or that we couldn't set ourselves some goals on when the operation should be complete, but rather aim at good work than overhasty bot operations and the like. |
Revision as of 10:41, 3 November 2017
World Heritage Sites NA‑class (inactive) | |||||||
|
More errors
Something in this template is causing Roman Theatre of Orange and Triumphal Arch of Orange to report links to the disambiguation page, Orange. Please fix. bd2412 T 13:18, 6 August 2017 (UTC)
- @BD2412: Is this a live error, or a cached one? I can't spot the links in the article or the infobox. Either way, I think this should be solved by the replacement for {{Wikidata location}} that's under development by @RexxS:, also see Wikipedia:Village_pump_(technical)/Archive_158#Wikidata_problem. Thanks. Mike Peel (talk) 14:24, 6 August 2017 (UTC)
- @BD2412: I've migrated those two infoboxes completely to Wikidata. Can you see if the problem is still continuing after the caches have refreshed, please? Thanks. Mike Peel (talk) 15:02, 6 August 2017 (UTC)
- As of now, the what links here page for articles linked to "Orange" still shows these two as having links. bd2412 T 16:17, 6 August 2017 (UTC)
- @BD2412: OK, I've isolated the problem. If you include {{#ifexist:Orange | 1 | 2}} in the page, then it will appear in Orange's WhatLinksHere. This appears to be a feature rather than a bug, as it's documented in paragraph 4 of mw:Help:Extension:ParserFunctions#.23ifexist. It's not so much of an issue with this template, as an issue with mediawiki itself. I think RexxS's new module will avoid this happening, so let's wait until that's ready. Thanks. Mike Peel (talk) 16:53, 6 August 2017 (UTC)
- As of now, the what links here page for articles linked to "Orange" still shows these two as having links. bd2412 T 16:17, 6 August 2017 (UTC)
Citation problems
In the article Copán the citation returned by this template appears as a raw url. This is contrary to guidance in WP:CITE#Avoid embedded links.
If a fuller link is included this can cause problems of inconsistency in the citations, if for example this is formatted as a inline long citation on a page of inline short citations. I suggest that the citation is formatted as belonging to a group (eg lower-alpha) and that the citation appears in its own notes section at the bottom of the template. -- PBS (talk) 12:40, 15 August 2017 (UTC)
- @PBS: The reference appears as a raw URL as that is the only piece of information about the reference in the current Wikidata entry - the easiest way to fix this is to expand the reference on Wikidata to include the title/publisher/accessdate/etc. Inconsistent referencing styles is an issue (since we don't have a standard referencing system here), and there's not much I can do about that right now (except for bugging the developers of Module:Wd and Module:Wikidata to expand support for different referencing systems). Note that references can be turned off in individual infoboxes if needed (set refs=no). References should be kept in a references section, and not in the infobox! Thanks. Mike Peel (talk) 17:47, 15 August 2017 (UTC)
Alarming increase in disambiguation link false positives.
Use of this template to import Wikidata content is beginning to cause an alarming number of false positives, which are highly disruptive to the work of disambiguators.
- Melbourne Observatory, Great Melbourne Telescope, and Carlton Gardens have false links to "Victoria"
- Church of San Francisco, Castro, Church of Nercón, Church of Chelín, and Church of Rilán have false links to "Castro"
- Place Stanislas has a false link to "Nancy"
Something needs to be done to prevent these false positives from cropping up, before they come to overwhelm the disambiguation project. bd2412 T 17:53, 14 September 2017 (UTC)
- I think @RexxS's new module will fix these, although I'm not sure when that will be ready. Thanks. Mike Peel (talk) 23:51, 15 September 2017 (UTC)
- Can we desist in doing whatever is causing the problem until this module is ready? bd2412 T 23:54, 15 September 2017 (UTC)
Please allow local website
Hortobágy National Park has a few problems at the moment:
- The website is sourced to the Italian Wikivoyage, not a reliable source at all
- The website given is the generic Hungarian one, but they have an English page as well, here
- I have no (obvious) way to override the Wikidata value here with a local value
- The value at Wikidata should not be overwritten, as it is correct there (international) but not here (English Wikipedia)
- I don't see an option to get a non-Wikidata version of the template (instead of just the field) either
Please change this template to allow the addition of a website on enwiki if the Wikidata one is not the right one (please change this for all parameters which don't have this option yet). Fram (talk) 10:08, 26 September 2017 (UTC)
- "website=" should work. I'll check through the documentation later today. There should also be a way of marking the language of the website on wikidata and fetching the correct language version, but I'm not sure what it is - I'll investigate that too. Thanks. Mike Peel (talk) 10:56, 26 September 2017 (UTC)
- I've expanded the documentation now (sorry for the delay). I think it's possible to store language-specific URLs in Wikidata like this, but I'm not sure how to fetch them (@RexxS: any ideas?). Thanks. Mike Peel (talk) 17:47, 30 September 2017 (UTC)
- I'd have to write a new call based on the code in getQualifierValue. Something like getValueByQualifier which would return the all the values of the property that had a particular value for a qualifier. In your case you could then fetch all the values of official website (P856) where the qualifier (P2439) was equal to English (Q1860). You'd have to decide how to deal with multiple values because there's nothing to stop an editor adding other official English websites. It is theoretically a "single-value" property, but there are 9645 violations (including yours). Unfortunately, the sandbox where we're working on capping the maximum number of values returned is now desynchronised by changes to the main module, and I'm disinclined to struggle with sorting out another new call under those circumstances. --RexxS (talk) 22:32, 30 September 2017 (UTC)
RfC: revert back to non-Wikidata version?
- The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
In light of the issue of unintentional canvassing, the later set of oppose(s) (barrying Andy's) have been assigned very negligible weightage.
That being said, the concensus is both supported by a head-count and weighing of arguments.
Numerous examples of botched cases have been provided which very clearly point to the fact that as things currently stand, the Wikidata-based template is not suitable for use in en.wiki.Winged Blades of GodricOn leave 10:07, 2 November 2017 (UTC) Consider this an administrator endorsing the above non-admin closure, in case it's needed. GoldenRing (talk) 13:20, 2 November 2017 (UTC)
In May 2017, this infobox was converted to a Wikidata-based one. Should it remain as such or should we revert to the local version? Fram (talk) 13:56, 2 October 2017 (UTC)
Survey
- Support reversal to non-Wikidata based version per reasoning and many examples below (more available on request!). Local version simply has much less issues and is much more stable. Fram (talk) 14:48, 2 October 2017 (UTC)
- Oppose There are nearly 1,000 instances of this that are using Wikidata information entirely. Another 500 or so need local checking/adding to Wikidata to make sure they are working correctly, but the answer is to fix those not to break the others. Mike Peel (talk) 21:20, 3 October 2017 (UTC)
- Support reversal to use infoboxes that do not draw information from wikidata as there are too much off site information, usually in a format that does not match wiki article in question. Keith D (talk) 23:35, 4 October 2017 (UTC)
- The apparent inability to add intermediate administrative districts is a big problem Taking a look at an arbitrary example in my area of expertise, Eastern Qing tombs (using the Wikidata-driven infobox) is described as being located in Zunhua, China. Which skips over two layers of administrative regions: Tangshan (which may not be particularly useful to most readers) and Hebei. This is a bit like describing something as being located in Carmangay, Canada (ignoring Vulcan County, Alberta), or Staffordshire, Earth. Editing the
Location
parameter in the infobox unintuitively does nothing directly. I made a couple edits to the relevant Wikidata entry, first adding "Hebei" to the "located in the administrative territorial entity" statement, then when that did nothing manually adding another "located in the administrative territorial entity" statement with the value "Hebei", which just merged the statements together. "Zunhua" is then selected to display instead of – rather than prior to – "Hebei". If we're going to draw data for this infobox from Wikidata, each field (possibly excepting coordinates and catalogue code) should have a local override to deal with cases like this. Snuge purveyor (talk) 02:16, 5 October 2017 (UTC)- I note that Eastern Qing tombs now displays "Zunhua, Hebei", PRC in the infobox like I suggested. I just added a provincial-level designation to Dujiangyan at Wikidata as well, but the template output seems to ignore it, which makes it unclear to me what behaviour has changed. I will also note here that the
Location
parameter is already locally overrideable provided one changes it tolocation
. I missed this case sensitivity in the documentation previously. Snuge purveyor (talk) 14:00, 5 October 2017 (UTC)- Thanks @Snuge purveyor: - both the cases you give seem to be working now, so there seems to be a short delay between editing the info on wikidata and it appearing here. Maybe try purging the cache after you've made the edit (add ?action=purge onto the end of the URL). I've tweaked the code so that Location= is now supported (I keep forgetting that this template has used upper-case labels, as I've always used lower-case only, but it's easy enough to support both). Thanks. Mike Peel (talk) 17:03, 5 October 2017 (UTC)
- I note that Eastern Qing tombs now displays "Zunhua, Hebei", PRC in the infobox like I suggested. I just added a provincial-level designation to Dujiangyan at Wikidata as well, but the template output seems to ignore it, which makes it unclear to me what behaviour has changed. I will also note here that the
- support. The effort to migrate these infoboxes is causing far too many problems. I just noticed new reports on Mike Peel’s talk page, a page only on my watchlist due to previous problems, some of the many reported. Even if working reliably it presents editors with a far worse experience when they hit 'edit' to edit a page or section and see not the fact they want to correct but nothing that matches the article content. The last RfC on this was clear: infoboxes should only pull information from wikidata when there is no data on Wikipedia. Many of the editors then raised concerns about sourcing and [ease of] editing, and four years on these have not been addressed.--JohnBlackburnewordsdeeds 04:26, 6 October 2017 (UTC)
- Support - I respect the effort that's gone in here, but drawing on data from outside the Wiki in this way makes it much harder for editors to edit and maintain articles. Hchc2009 (talk) 17:51, 6 October 2017 (UTC)
- Support per abundant reasons cited above. I furthermore caution Mike Peel that sanctions may be warranted if you continue making edits while discussion is underway which are solely and blatantly disruptive if consensus goes against you.[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19] I apologize if any bad-example diffs slipped in there. There are so many potentially disruptive edits that it's tedious to double check them all. I can see no credible justification for stripping information out of countless infoboxes when you know dang well that discussion is underway and your edits disruptively increase the work of converting back to a non-wikidata infobox. Alsee (talk) 00:31, 7 October 2017 (UTC)
- Note that those edits were before my comment below, after which I have not made any more such edits (although Fram has not done the same). Thanks. Mike Peel (talk) 14:55, 7 October 2017 (UTC)
- Oppose any reversions done simply because some editors don't like Wikidata. The decision to use wikidata in any particular article needs to be in the hands of the editors who curate that article, not the zealots who are determined to stop any progress in building sensible central repositories for all the Wikimedia projects. --RexxS (talk) 16:03, 7 October 2017 (UTC)
- but it wasn’t put it the hands of the editors who curate these articles. That would be if e.g. the template were created and then publicised, with editors able to use it as they see fit. Instead it was mass-inserted into those articles by one editor with as far as I can see no prior discussion at any of them. The first other editors knew about it was when they noticed the problems it was creating.--JohnBlackburnewordsdeeds 16:22, 7 October 2017 (UTC)
- Support per Hchc2009. For the record, I also support Johnbod's efforts in the past to reduce much of the clutter on this infobox. Ealdgyth - Talk 16:18, 7 October 2017 (UTC)
- Support. I have been dealing with Wikidata recently over infoboxes generating incorrect links (particularly links to disambiguation pages); the response that I have gotten is that these issues are not fixable there, and that our infoboxes need to be adjusted to not use the Wikidata information in those cases. In that case, that is exactly what we should do. bd2412 T 03:19, 11 October 2017 (UTC)
- Support. It is clearly preferable that the text of Wikipedia articles is held on Wikipedia, and not outsourced. (Is anyone actually checking each item of information that is imported automatically from Wikidata?) It is also preferable that editorial decisions about article content are made on Wikipedia, not buried in automated templates a way that that is difficult for regular editors to change. Keep experimenting, by all means; but the level of problems identified above and elsewhere clearly demonstrates that this implementation is not good enough to be the default at this time. (And {{Infobox artwork/wikidata}} is even more problematic than this one.) Theramin (talk) 23:48, 14 October 2017 (UTC)
- Support - (Summoned by bot) The change did not improve the template; it actually made it worse. That is an easy line to draw to determine whether it should stay or not. Nihlus 05:12, 25 October 2017 (UTC)
- NOTE: all !votes below here followed canvassing by Mike Peel at WikidataCon (thoug he didn't realise that what he did was canvassing), and a subsequent discussion of this at Wikipedia:Administrators' noticeboard#How to deal with this?. Fram (talk) 08:22, 2 November 2017 (UTC)
- Oppose per Mike Peel and RexxS, it's working just fine in many articles. WP:IDONTLIKEIT is not a valid reason to roll back improvements. Gamaliel (talk) 16:03, 28 October 2017 (UTC)
- Hi Gamaliel. It's working just fine in many articles is not a reason to support keeping a template which is definitely not working fine in many other articles, and where we have an alternative which works fine in all articles. This has nothing to do with "idontlikeit", but "ifontlikeyou" is not a valid reason to oppose things of course. Fram (talk) 11:07, 29 October 2017 (UTC)
- @Fram: Since you apparaently object to others doing so, please fix your broken markup. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:59, 1 November 2017 (UTC)
- Hi Gamaliel. It's working just fine in many articles is not a reason to support keeping a template which is definitely not working fine in many other articles, and where we have an alternative which works fine in all articles. This has nothing to do with "idontlikeit", but "ifontlikeyou" is not a valid reason to oppose things of course. Fram (talk) 11:07, 29 October 2017 (UTC)
- Oppose as per reasons already given. Battleofalma (talk) 18:33, 28 October 2017 (UTC)
- Oppose Working on fixing the issues would have been more productive and long term effective than starting this vote.
I am happy to work on improvements with people and encourage others to oppose this backwards step. Leela0808 (talk) 19:37, 28 October 2017 (UTC)
- Leela, many of those calling for reverting the template to its former version have noted that they do not wish to have to follow and engage on two Wiki systems (the English language Wikipedia, and Wikidata) to maintain articles on the English Wikipedia. It's a pain and takes more time. I can't really see this issue can be "fixed" without reverting to the former version - what were you proposing doing? Hchc2009 (talk) 13:00, 29 October 2017 (UTC)
- Maintaining articles already involves using two wikis, except for articles where there are no associated images. Richard Nevell (talk) 14:49, 29 October 2017 (UTC)***Keeping an eye on images on the Commons is irritating, but at least we don’t need to worry about tracking vandalism and OR etc there... forcing editors to track a third site where vandalism etc is an issue feels simply unnecessary... Hchc2009 (talk) 14:56, 29 October 2017 (UTC)
- Leela, many of those calling for reverting the template to its former version have noted that they do not wish to have to follow and engage on two Wiki systems (the English language Wikipedia, and Wikidata) to maintain articles on the English Wikipedia. It's a pain and takes more time. I can't really see this issue can be "fixed" without reverting to the former version - what were you proposing doing? Hchc2009 (talk) 13:00, 29 October 2017 (UTC)
- Oppose. The world heritage sites are worldwide and therefore the local information about them is mostly not in English. To use Wikidata as a language-independent database for information about them is IMO very good to have. It can help dramatically when creating a new wikipedia site and keeping the information on existing ones up-to-date with the help of more local persons. How the existing boxes should be transformed can be discussed. Moreover, it is still possible to overwrite the Wikidata values with local ones. --Zuphilip (talk) 09:32, 29 October 2017 (UTC)
- Zuphilip - you can already cite non-English sources on the Wikipedia, provided they meet WP:VERIFIABILITY - I cite French ones all the time, for example. No-one is suggesting deleting Wikidata, so if anyone wishes to create a new Wikipedia site (e.g. in a new language etc.) they can draw on that data if they wish to. As above, though, many of us don't wish to have to work on several Wiki sites in order to maintain articles on the English Wikipedia. Hchc2009 (talk) 13:04, 29 October 2017 (UTC)
- Can I just ask where this was mentioned to suddenly get 4 oppose votes in a row after weeks with little or no opposes? This is strange... Fram (talk) 11:00, 29 October 2017 (UTC)
- It's certainly unusual, I'd agree. Some of the additional contributors are relatively "new" to the Wiki (Zuphilip has made only 72 edits over the last ten years, for example; Leela, 462 edits over the last five) and don't seem to have any previous connections to this topic. While you don't need to be a wiki-addict to make valuable contributions to a debate (!) - it's the quality of your contribution, not your "time served" that matters - I'd be inclined to agree that the pattern is odd unless the debate has been highlighted elsewhere. Hchc2009 (talk) 13:12, 29 October 2017 (UTC)
- I included a mention of this template and the RfC in commons:File:Wikidatacon 2017. Wikidata-powered infoboxes.pdf (slide 20) as part of a review of Wikidata infoboxes on enwp at Wikidatacon2017. Note that I did not WP:CANVAS for votes. BTW, note that many people that have participated earlier in this discussion do not have previous connections to this topic that I'm aware of. Thanks. Mike Peel (talk) 13:33, 29 October 2017 (UTC)
- Canvassing isn't just asking to support or oppose one position. Simply asking people with one specific interest (e.g. like here, people more likely to support the use of Wikidata in as much places as possible) is also canvassing, and not allowed. Thanks for being open about it though. Fram (talk) 16:25, 29 October 2017 (UTC)
- NB: It looks as though an ANI debate has been started on the canvassing question by Fram - the link is WP:AN#How to deal with this?. Hchc2009 (talk) 20:40, 31 October 2017 (UTC)
- Canvassing isn't just asking to support or oppose one position. Simply asking people with one specific interest (e.g. like here, people more likely to support the use of Wikidata in as much places as possible) is also canvassing, and not allowed. Thanks for being open about it though. Fram (talk) 16:25, 29 October 2017 (UTC)
- I included a mention of this template and the RfC in commons:File:Wikidatacon 2017. Wikidata-powered infoboxes.pdf (slide 20) as part of a review of Wikidata infoboxes on enwp at Wikidatacon2017. Note that I did not WP:CANVAS for votes. BTW, note that many people that have participated earlier in this discussion do not have previous connections to this topic that I'm aware of. Thanks. Mike Peel (talk) 13:33, 29 October 2017 (UTC)
- It's certainly unusual, I'd agree. Some of the additional contributors are relatively "new" to the Wiki (Zuphilip has made only 72 edits over the last ten years, for example; Leela, 462 edits over the last five) and don't seem to have any previous connections to this topic. While you don't need to be a wiki-addict to make valuable contributions to a debate (!) - it's the quality of your contribution, not your "time served" that matters - I'd be inclined to agree that the pattern is odd unless the debate has been highlighted elsewhere. Hchc2009 (talk) 13:12, 29 October 2017 (UTC)
- Oppose Given that fields can be overridden if necessary, I'm not seeing there would be much to gain by rolling out the changes. Mike has been responsive to suggestions and has actively been improving the infobox so perhaps this could be viewed as an opportunity to suggest further improvements. Richard Nevell (talk) 18:44, 31 October 2017 (UTC)
- With Wikidata infoboxes, one only knows that a field needs to be overridden (long) after the fact, as they don't show up in page history and on most people's watchlists (and don't get me started on recent changes). One can hardly preactively override all fields where someone on Wikidata may make a change which is unwanted on enwiki (well, one can easily do that, by using a non-Wikidata infobox, but that's not what you want). If in reality way too many of these infoboxes contain errors (which Mike Peel introduced in many cases in the first place by replacing local override values with the central "everything from Wikidata" version), then the nice theories about what is possible should be abandoned, and this should be seen as an opportunity to use a local, working, improved version instead. Fram (talk) 08:22, 2 November 2017 (UTC)
- Oppose per all of the above opposes. Also, while I was at WikidataCon, I only became aware of this discussion after seeing it mentioned on WP:ANI. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 07:41, 1 November 2017 (UTC)
- Support Having read through the arguments, one point that has not been, and probably cannot be, eliminated is that it is a vandalism vector that is not under the control of this project. The suggested changes are attempts to restrict that vector but cannot remove it. No matter how righteous the majority of Wikidata's user base may be, it is smaller and less active and provides longer correction times. To make an analogy: I live in a semi-rural area with a very low crime rate and yet I lock my doors at night. Leaving this template open to Wikidata leaves at least one door to this project unlocked. This is neither overly-cautious nor paranoid nor a refutation of the sister project. Eggishorn (talk) (contrib) 17:12, 1 November 2017 (UTC)
"it is smaller and less active"
It has more items than en.Wikipedia has articles; and more edits per week than en.Wikipedia. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:58, 1 November 2017 (UTC)- An item on Wikidata is not comparable to an article on enwiki in nearly all cases, and the number of edits is mostly due to two factors, the massive number of bot edits and the need for humans to make many very small edits to get a result, where here one can do a lot more in one edit usually. Plus of course many so-called Wikidata edits are not edits on Wikidata at all, but things like page moves on some wiki which automatically get copied on Wikidata with a false attribution to the page mover. Fram (talk) 08:22, 2 November 2017 (UTC)
- Comment: Note that people are finding this infobox useful and are adding the Wikidata version, e.g. at [20] and Ancient City of Damascus where the Wikidata version of the infobox was added/converted from a child template in the last few days. I guess pinging those editors here would count as canvassing though... Thanks. Mike Peel (talk) 09:16, 2 November 2017 (UTC)
Threaded discussion
Extended discussion.Winged Blades of GodricOn leave 10:07, 2 November 2017 (UTC)
|
---|
In May 2017, this was converted to a Wikidata-based infobox. Nothing wrong with that, doing this is allowed. However, it seems to be that the end result is at best the same we had with the previous infobox, and at worst (and usual) we have a worse infobox now than before, which can't be the intention. Of course, many issues can be fixed, but the problem is that new issues arise constantly, while the local infobox was stable and had few if any problems. For example, Mike Peel (who did the hard work in this conversion) stated "As an example, I've converted Kathmandu Valley (the main example used for this template) to use the Wikidata version." Comparing the old version with the current one[21] shows
Now, this is the actual testing example, so presumably the best. I have tried to improve the template at Hortobágy National Park, where I had to come here to get the possibility to add a website overriding the Wikidata one (which wasn't a problem in the old version), where I then had to override a few other Wikidata values as well, and where I can't find how to layout the name of the Heritage Site (with italics for "puszta"), which was again not a problem in the old version[22] On Mexico City, we have now an infobox claiming
No idea why square klometers gets converted to square feet, but anyway: the area is totally wrong, and the location is ... just weird. The area is wrong on all(?) instances where you get the infobox included in an article on a city where part is also a heritage site (e.g. Kyoto. Location is also often an issue, e.g. the mountain range the Dolomites is apparently located only in Cortina d'Ampezzo, even though the Unseco itself simply gives Italy[23] as the much more correct location. Basically, the template worked better as a local template than as a Wikidata-driven one, and less unexpected problems arose. Fram (talk) 14:21, 2 October 2017 (UTC)
See e.g. also Quito, which has the location "Ecuador, Ecuador" (once is enough, thank you), and doesn't have an "Area" of "290 km2 (3.1×109 sq ft)", but of 320 ha. Semmering railway has as Wikidata-driven sources things like this, which is of course an unacceptable source. And it doesn't have this once, it has it seven times in a row: Location Gloggnitz, Prigglitz, Payerbach, Breitenstein, Semmering, Spital am Semmering, Mürzzuschlag[1][2][3][4][5][6][7], Austria[1] Edit this at Wikidata". Not only that, it also "Includes Q801311, Q32607493 Edit this on Wikidata". Wow, it includes two Q-numbers (without even a link), what encyclopedic information! Perhaps the official location of "Between Gloggnitz, State of Lower Austria and Simmering, State of Styria" would have been more useful, and with the official Unesco site as simple reference? Basically, a template on important monuments which creates this as the reference list is not really acceptable: "https://tools.wmflabs.org/heritage/api/api.php?action=search&format=json&srcountry=at&srlanguage=de&srid=24736; Monuments database; publication date: 18 August 2017. https://tools.wmflabs.org/heritage/api/api.php?action=search&format=json&srcountry=at&srlanguage=de&srid=24740; Monuments database; publication date: 18 August 2017. https://tools.wmflabs.org/heritage/api/api.php?action=search&format=json&srcountry=at&srlanguage=de&srid=24743; Monuments database; publication date: 18 August 2017. https://tools.wmflabs.org/heritage/api/api.php?action=search&format=json&srcountry=at&srlanguage=de&srid=24772; Monuments database; publication date: 18 August 2017. https://tools.wmflabs.org/heritage/api/api.php?action=search&format=json&srcountry=at&srlanguage=de&srid=24773; Monuments database; publication date: 18 August 2017. https://tools.wmflabs.org/heritage/api/api.php?action=search&format=json&srcountry=at&srlanguage=de&srid=24867; Monuments database; publication date: 18 August 2017. https://tools.wmflabs.org/heritage/api/api.php?action=search&format=json&srcountry=at&srlanguage=de&srid=9703; Monuments database; publication date: 18 August 2017." Now, all of this can probably be corrected at Wikidata and/or in the template, but it shouldn't be necessary, and we had much less of this shit with the local template instead. Fram (talk) 14:34, 2 October 2017 (UTC) I try to look at different types of World Heritage Sites. Something like Burgundy wine for example: it has "Coordinates 50°N 0°E". Which is weird, because the value is not given locally, the Wikidata item has "53°N, 0°E", and the Unesco site has "N47 3 29 E4 51 52". Then the location is "Location Yonne, Saône-et-Loire, Côte d'Or, France Edit this at Wikidata" but the official location is either "France" or "the slopes of the Côte de Nuits and the Côte de Beaune south of the city of Dijon"[24], which at first sight are all located in the Cote d'Or, not in the other two regions. Fram (talk) 14:47, 2 October 2017 (UTC)
To be more precise, I have given X examples:
Only in Kathmandu Valley, which was the example given by you at the conversion of this template, were there are also issues caused by local parameters ("citation needed"). So can we now please put the "but it's local parameters that cause this" to rest and focus on the actual issue (not solving some examples), whether this Wikidata-driven template is more stable and less prone to cause errors than the purely local template? Fram (talk) 04:41, 3 October 2017 (UTC)
Seeing how this is the way this has to be played apparently, I have now created Template:Infobox UNESCO World Heritage Site (which will be improved and expanded upon in the near future), as a better, more stable, fully local alternative for the Wikidata version. No more sudden, unexpected and unwatched influxes of disambiguations, fields with a reference but no value, wmflabs queries as sources, images not matching the caption without anyone making an error (human error can never be excluded, but an infobox shouldn't have wrong information because people did the right thing on another site), and so on and so on. Please, wherever you insert it, make sure that it works correctly before saving, and leave all feedback on the template talk page. All improvements (except getting info from Wikidata, we already have a template for that bad idea) are welcome. Fram (talk) 08:08, 4 October 2017 (UTC) I have now converted 5 articles to the "new" (the improved "old") infobox: two articles which had been discussed here, and the first three I encountered when I did "what links here" from this template. Conclusions, apart from the fact that the new infobox provides some extra fields and the logical things (takes more place in the editing screen, can be corrected directly in the editing screen, removes the Wikidata link and pencil icons in view mode, ...):
Basically, the new template can do everything the Wikidata one does, and more (so far, the parameters "Area", "Buffer Zone" and "Part of" have been added). It provides direct control of the data the same way all other content of the article is provided, allows layouting, tagging and referencing, ... It won't be perfect yet (created today), but it works both in full and child modus. It avoids most unpleasant surprises (like the issues the current template had) and is fully integrated in the watchlist, recent changes, ... Editors need to do a bit more work than just add the lazy Wikidata link, but as can be seen above, this considerably increases the chance of a better end result (as seen above, where 3 of the 5 templates now are better wrt the same parameters). Any reason not to use Template:Infobox UNESCO World Heritage Site? Fram (talk) 13:44, 4 October 2017 (UTC)
I have now added the new template to Bauhaus to demonstrate the ability to have a map with multiple clickable locations (data is now up-to-date as well). Fram (talk) 11:12, 5 October 2017 (UTC)
Primefac (talk) 17:54, 6 October 2017 (UTC) I still think this needs more discussion, but replying to the proposed steps that were raised here:
Thanks. Mike Peel (talk) 17:15, 7 October 2017 (UTC)
Arbitrary break 1Quedlinburg, location generated from Wikidata: "Harz, Quedlinburg, Kreis Quedlinburg, Quedlinburg, Germany". Before this template was converted, the article didn't show a location in the WHS template because it already had a location in the general template. At the conversion, this was automatically added (though not wanted), and filled rather dreadfully. Another clear example of where changing this template to the Wikidata template made the article worse (see also the incorrect area, and fields which aren't wrong but unnecessary like the website, already listed previously in another infobox). Fram (talk) 13:30, 9 October 2017 (UTC)
See also Wikipedia talk:Wikidata/2017 RfC draft#Systemic issue that has serious implications for increased use of Wikidata: thanks to the use of Wikidata in infoboxes and the display of the changes in watchlists and recent changes, according to a WMF database administrator, "we are close of running out of space on several main database servers, breaking all of Wikipedia". Wikidata in infoboxes has already had serious performance implications in Commons, rowiki, itwiki, and dawiki, where such uses are more common. While this single infobox specifically won't make a huge difference, it is good to remember that these things come at a cost which is sometimes surprisingly high and impacts many editors. Fram (talk) 07:50, 10 October 2017 (UTC) Note that I've submitted a preparatory Wikipedia:Bots/Requests for approval/Pi bot 2 (with functional code) to split this template into separate 'wikidata' and 'non-wikidata' versions. Running this code is subject to the outcome of this RfC. Mike Peel (talk) 23:50, 14 October 2017 (UTC) Yesterday, the Wikidata item for the country Romania (not really an obscure topic I would think, one that is used in thousands of other Wikidata items) was moved (english label changed) to Moldavia, with vandalism to the description and alias as well. This was only reverted nearly three hours later[26]. This is pretty quick by Wikidata standards, e.g. yesterday as well Fernando Alonso (another high profile article) was vandal-moved in English, Spanish and Catalan for more than two hours[27], while more obscure articles take about 8 hours to be reverted (labeling a living person a "fascist" seems like a quite obvious case of vandalism[28]), if they get spotted at all. Anyway, back to the issue at hand: the Romania vandalism was reflected in quite a few enwiki articles, including the UNESCO world heritage sites but basically every infobox that fetches information from Wikidata and includes the field "Romania" (biographies, location of artworks, observatories, ...). The end result was similar to what you can see in the images; in these cases, the country name was changed, but also the wrong map was shown, and the red dot location indicator was somewhere in the middle of the page instead of in the infobox. Basically, using Wikidata makes vandalism on many articles much easier, and is almost guaranteed to remain in the articles for a lot longer as well. Coupled with the recent changes delay (so even if you have Wikidata in recent changes enabled, chances are you wouldn't see this happening) and the problem that these don't appear in the page history, and you end up with a situation which is beneficial to vandals and negative for recent changes patrollers. Fram (talk) 07:52, 18 October 2017 (UTC) 25 May 2024
24 May 2024
Twenty-five examples of vandalism directly on English Wikipedia
|
I have posted a request at Wikipedia:Administrators'_noticeboard/Requests_for_closure#Template_talk:Infobox_World_Heritage_Site.23RfC:_revert_back_to_non-Wikidata_version.3F to ask that someone neutral have a look at this and potentially close it. Thanks. Mike Peel (talk) 08:56, 2 November 2017 (UTC)
Implementation of RfC
Any ideas on how to proceed with the implementation of the RfC result? I mean, several options on how to proceed after the closure of the RfC were proposed in its discussion area: I propose to work towards a consensus ASAP on which one to pick (or ASAP propose another one which may find consensus). --Francis Schonken (talk) 10:58, 2 November 2017 (UTC)
Wikipedia:Bots/Requests for approval/Pi bot 2
(After edit conflict) OK, so we now have a result from the RfC, so now we need to implement it. My suggestion is as follows:
- I have written code and put together a bot request to separate out the uses that are currently entirely using Wikidata to {{Infobox World Heritage Site/Wikidata}} - unless there are any objections I will copy the current version of the template to that page and then run the bot. We can then manually check for cases that are only using a few local parameters and move them over as well.
- We can then merge {{Infobox UNESCO World Heritage Site}} into this template, and entries with locally defined values can then use that. Or it can remain as a separate template, but that doesn't make sense to me.
- That is, at least, a preliminary solution. It's up to others about whether that's then the status quo or whether the Wikidata info is then locally copied. I can put together some code that will substitute the Wikidata information here if desired. But you all need to figure out what you want to do here/how you want to do it.
I am happy to continue maintaining a separate Wikidata version of this template if desired, but otherwise I'll walk away from working on this template after the implementation of this is complete. Thanks. Mike Peel (talk) 11:00, 2 November 2017 (UTC)
- Queries @Mike Peel:
- I think you should first revert all instances where you removed the local parameters back to the old situation. This will help in reverting to the old version (whether the actual old version or the new version I created is a separate issue). Cases like this or this. Fram (talk) 12:25, 2 November 2017 (UTC)
- Added a ping to Mike Peel: seems a pertinent question – can you commit to (help) recover en.Wikipedia mainspace deletions of local parameters for this template? --Francis Schonken (talk) 06:59, 3 November 2017 (UTC)
- I have described what I am willing to do above. I see no point in simply reverting the changes I made before, as that will re-introduce a lot of bad data that I've already cleaned up - and the RfC above does not require this as opposed to the solutions I've mentioned above. Thanks. Mike Peel (talk) 08:11, 3 November 2017 (UTC)
- The RfC requires a revert to the previous version. What you propose is the opposite, you want to simply rename the template to /Wikidata and be done with it (oh, you also suggest that others can copy the Wikidata data locally, as if the Wikidata data is infallible. You seem to haven't grasped what this RfC was about). I guess simply moving all instances to the UNESCO version of the template manually will be the best solution then? Fram (talk) 08:25, 3 November 2017 (UTC)
- You might want to read what I said again, and try to take it in this time. There was nothing above about not having a separate Wikidata version. I was suggesting we move things over to there *for now* so this version of the template can be changed to a non-Wikidata one, and then the current cases can be migrated back by whoever wants to do so (I suggested one way, you're welcome to suggest others). Again, *I checked through the Wikidata info for the ones I migrated*, and what is on Wikidata for those is at least as good as what was here before, at least for the core parameters (WHS ID, criteria, years), so I see no benefit to undoing those. We can remove things like area if you'd like, which weren't included in the template before anyway. Thanks. Mike Peel (talk) 08:42, 3 November 2017 (UTC)
- "There was nothing above about not having a separate Wikidata version." apart from "as things currently stand, the Wikidata-based template is not suitable for use in en.wiki" you mean? You checked through the Wikidata info when you migrated them, and you didn't notice any of the problems that caused the RfC and its end results, or you didn't think them important? I think we can handle this without more help from you. Fram (talk) 10:41, 3 November 2017 (UTC)
- You might want to read what I said again, and try to take it in this time. There was nothing above about not having a separate Wikidata version. I was suggesting we move things over to there *for now* so this version of the template can be changed to a non-Wikidata one, and then the current cases can be migrated back by whoever wants to do so (I suggested one way, you're welcome to suggest others). Again, *I checked through the Wikidata info for the ones I migrated*, and what is on Wikidata for those is at least as good as what was here before, at least for the core parameters (WHS ID, criteria, years), so I see no benefit to undoing those. We can remove things like area if you'd like, which weren't included in the template before anyway. Thanks. Mike Peel (talk) 08:42, 3 November 2017 (UTC)
- (edit conflict) A few additional considerations:
- There is no deadline, meaning: it is better to do this conscientiously than in a rush. No time-table has been set on when to re-introduce the local-parameters-only code into this template yet. Doesn't mean we have to be lethargic, or that we couldn't set ourselves some goals on when the operation should be complete, but rather aim at good work than overhasty bot operations and the like.
- For clarity, I don't think a two-template or three-template solution to cover all World Heritage Sites would be agreeable to the editing community in the long run: co-existing templates for actually the same infobox can only be temporary/intermediate solutions, as aids to get things sorted into a more permanent solution, and the direction of that permanent solution (no Wikidata) has been decided by the RfC.
- Re. "... otherwise I'll walk away from working on this template <i.e., unless the Wikidata implementation gets precedence>" (emphasis added, and last part paraphrased from "after the implementation of this is complete"): I'd like to extend that, for example in view of what an arbitrator posted yesterday at WP:ARBREQ: "I think the policy is clear that we run our own project at enWP just as much as they do atWikidata" – I don't say that all conscientious reverts-with-appropriate-updates should be up to one person, but if the person responsible for over 900 deletes of local parameter sets does not help in repairing the damage they are responsible for, and which makes the implementation of the clear RfC outcome a very tangled issue, then I suggest it would be better that this editor would walk away from all templates that call Wikidata claims. Your allegiance should be to en.WP in the first place when editing here: creating a mess affecting hundreds of pages, and then walk away for being only interested in Wikidata seems out of the remit of this talk page discussion. So, I'd suggest a change of heart here, otherwise it seems only logical to add the editor as an involved party to WP:ARBREQ#Crosswiki issues, and let arbitrators decide.
- Pinging Mike Peel. --Francis Schonken (talk) 09:35, 3 November 2017 (UTC)
- The RfC requires a revert to the previous version. What you propose is the opposite, you want to simply rename the template to /Wikidata and be done with it (oh, you also suggest that others can copy the Wikidata data locally, as if the Wikidata data is infallible. You seem to haven't grasped what this RfC was about). I guess simply moving all instances to the UNESCO version of the template manually will be the best solution then? Fram (talk) 08:25, 3 November 2017 (UTC)
- I have described what I am willing to do above. I see no point in simply reverting the changes I made before, as that will re-introduce a lot of bad data that I've already cleaned up - and the RfC above does not require this as opposed to the solutions I've mentioned above. Thanks. Mike Peel (talk) 08:11, 3 November 2017 (UTC)
Discussion (Wikipedia:Bots/Requests for approval/Pi bot 2)
- I suppose Wikipedia:Bots/Requests for approval/Pi bot 2 would need a consensus *before* running it – what do others think? --Francis Schonken (talk) 11:11, 2 November 2017 (UTC)
Step by step
(step 1) I'm about to create Category:Articles with WHS infoboxes completely from Wikidata as a subcategory of Category:Articles with infoboxes completely from Wikidata, and adapt the code of the template so that articles using this infobox would rather go to that subcategory instead of the general category. I figured this might help to sort issues. --Francis Schonken (talk) 10:31, 3 November 2017 (UTC)