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.
I've previously removed the genus infobox as it has no relevance to an eating establishment, which is the more common use of the word (other than to selected biologists perhaps). It would be appropriate on Category:Cafeteria (bicosoecid). Finavon (talk) 16:28, 5 July 2018 (UTC)[reply]
@Jheald: With monument categories now I do four passes with different scripts: (1) try to add sitelinks by matching the ID with the property on Commons where there isn't already a sitelink, (2) where there is a sitelink but no ID on Wikidata, add it to Wikidata, (3) add the infobox (having added the property display + the tracking categories to the infobox), (4) trim the now-duplicated monument ID template so that the remainder are obvious for manual checking. It works particularly well when the whole monument database has been imported to Wikidata (as NHLE has), less so when it's only partially there (as is the case for most it seems). Thanks. Mike Peel (talk) 11:17, 9 July 2018 (UTC)[reply]
Impressive and very valuable -- makes sense now why there are so few actual buildings short of infoboxes; and of course finding and putting in the sitelinks is such a prize. Jheald (talk) 11:29, 9 July 2018 (UTC)[reply]
Makes sense. Some are clearly taxa, that might benefit more from a taxonavigation template; and some are wiki-internal things, but I don't see any problem with those having an infobox to translate what they're about into everybody's languages. Suspect the '096 query may be away for some time. Jheald (talk) 11:46, 9 July 2018 (UTC)[reply]
Hello Mike,
There has been a change of CSS and now taxons list are badly displayed.
* {{Taxa|superfamiliae|Families of Lepidoptera|source=LepIndex}}
now displays:
@Liné1: It looks straightforward enough to do (simple string replacement), the main issue would be to get the bot task approved. However, it might be simpler to modify the formatting used in the taxa template so that it displays as before. Does it need to use the dl/dt/dd formatting rather than just being wrapped in a div? Thanks. Mike Peel (talk) 16:03, 14 July 2018 (UTC)[reply]
Too much practice at fixing my code, I guess. ;-) I'm going offline for a bit now (heading to Wikimania), but if there's any more issues with it then let me know and I'll have a look when I can. Thanks. Mike Peel (talk) 16:50, 14 July 2018 (UTC)[reply]
@DanTD: Your first edit on Wikidata was right, but instead of the second you then needed to do [5]. Wikidata does not automatically import the new coordinate from a Wikipedia - that has to be done manually or by a bot - so when you undid your edit you just added the old coordinates back. To add the new ones, I clicked on 'add statement', then in the property box I typed 'coord' and clicked on the 'coordinate location' option in the drop-down menu. Then in the input box that appears in the right I just copy-pasted the coordinates as you gave them above, then clicked 'publish' on the right. Hope that makes sense / helps? Thanks. Mike Peel (talk) 06:48, 17 July 2018 (UTC)[reply]
I just saved a copy of your edit in an image, so I can use it more often. I tried to edit it with the correct coordinates, but it didn't work, Hopefully your suggestion will work for any future errors. Thanks. ----DanTD (talk) 14:30, 17 July 2018 (UTC)[reply]
Pi bot seems to be placing this after the last template call. This includes DEFAULTSORT, which isn't strictly a template, and also any {{En}} / {{De}} etc. which are very common.
@Andy Dingley: The code looks for the last "}}", and adds the infobox below that. The problem is that there are many templates here that *insist* on having the full width of the page, such as {{Object location}}, and if the infobox is placed above those then you end up with a huge white space at the top of the category page. I started trying to put together a list of these to avoid them individually, but as well as the common ones there are also rarer ones (such as some monument templates) that do the same. So for the bot run it was safest to always put it at the bottom. It can be moved further up the page, though, particularly as we deprecate other templates whose functionality is now in the infobox. Thanks. Mike Peel (talk) 06:24, 21 July 2018 (UTC)[reply]
So could it do it the other way? A set of templates which it knew were safe to push past? That would probably improve placement for most pages, and safely for the others.
Also, {{Object location}} would seem to be broken in such a case (there is no need for it to require full width), and it's that template which needs fixing. All templates need to be more cooperative about this sort of placement, it's becoming an issue with the wider range of viewing hardware. Presumably Commons has been able to lag WP over this as there's less large body text around. If a template really does need full width though, it should code in a CSS clear for itself. Andy Dingley (talk) 09:00, 21 July 2018 (UTC)[reply]
@Andy Dingley: It could do it that way, but as it's now coming to the end of the initial deployment I'm not sure it's worth doing that now. The best thing now is probably to start trimming the uses of the other templates/text where they have been replaced by the infobox. Thanks. Mike Peel (talk) 09:03, 21 July 2018 (UTC)[reply]
@Tacsipacsi: Sorry for missing the notification. I think that having the infobox on that page does actually make sense though, as it is inherently multilingual. It appears to actually be the *only* thing on that page that displays information in a language other than English? Thanks. Mike Peel (talk) 10:27, 22 July 2018 (UTC)[reply]
I've expanded the Wikidata entry a bit, so the infobox now explains what the category is about, which works in French (try changing your language setting at the top next to your username), but ironically, it doesn't work with Indonesian yet! Hopefully someone will add the translations onto Wikidata at some point. Thanks. Mike Peel (talk) 10:34, 22 July 2018 (UTC)[reply]
I wouldn’t understand that infobox if I didn’t know this information already. category combines topics (P971) may be useful for software, but it’s hardly understandable for outsiders. The label is not useful here (only when adding statements on Wikidata), instance of (P31) is also trivial information, the bottom links (Wikidata and Toolforge ones) are useless. There is already a link to the language in the description, although it currently points to enwiki, but it would be better to internationalize {{UsersSpeak}}. (Side note: Why does the bot put the infobox below everything else? Infoboxes are normally at the top of the page.) —Tacsipacsi (talk) 11:25, 22 July 2018 (UTC)[reply]
Sorry, I haven’t read through your talk page. I think nothing should be included in the infobox. I don’t think an infobox is useful for a such category at all. (P.S. You don’t have to ping me for each message, your talk page is on my watchlist.) —Tacsipacsi (talk) 12:22, 22 July 2018 (UTC)[reply]
OK, it sounds like a third opinion is needed here then. :-) What I can do quite easily is bot-remove (and exclude from future bot runs) categories that use {{UsersSpeak}}. Maybe you could raise this for discussion at Template talk:Wikidata Infobox or another suitable venue for other people's views - or maybe someone else watching this page might want to comment. Thanks. Mike Peel (talk) 18:14, 22 July 2018 (UTC)[reply]
I took the tool "wp-world/googlproxy.php" down, as there was a XSS-Security problem in it[7]. If somebody is willing to help and have knowledge for it, the code is here and we could bring it back. If not it's perhaps better to take the tool out of the template. --Kolossos (talk) 20:40, 22 July 2018 (UTC)[reply]
@Kolossos: OK. I can't access the phabricator bug, but then I probably can't help with fixing it either. I've disabled the link in the infobox for now - once it's working again then it can be easily re-enabled. I'm not sure how to disable it in {{Object location}}, maybe @Jarekt: can help there? Thanks. Mike Peel (talk) 23:44, 23 July 2018 (UTC)[reply]
Done I disabled GoogleMaps link for now. I hope we can fix this again. I like satellite images instead of vector data. --Jarekt (talk) 03:50, 24 July 2018 (UTC)[reply]
Though, that change appears to introduce 4 new prettyCss issues — the page's status is now having warnings. Note that invalid or ambiguous code often has unwanted side effects like breaking other tools for you. If you cannot find out how to fix it, I suggest blanking the page for now.
To help you understanding where the issues are, I have aggregated a report here and now. If you have questions, don't hesitate to ask users experienced in css writing for help. But do not ask the bot's operators (chronically overwrought) unless you suspect an error of mine. If you prefer not getting spammed by me, you can opt-out reports by adding {{ValidationOptOut|type=all}} to your user page or cmb-opt-out anywhere on your your global user page on Meta. Good luck at Wikimedia Commons and happy hacking!
WARNING: unknown-property:-webkit-column-count: line 4 char number 2 - Evidence: -webkit-column-count
WARNING: unknown-property:-ms-column-count: line 5 char number 2 - Evidence: -ms-column-count
WARNING: unknown-property:-moz-column-count: line 6 char number 5 - Evidence: -moz-column-count
WARNING: unknown-property:column-count: line 7 char number 5 - Evidence: column-count
Perhaps somebody ought to mention to the bot operators that MediaWiki software demonstrably supports column count. It should say that the property is deprecated in favour of setting column widths (use the column-width property with a value in ems), which makes the layout responsive to display resolutions. Cheers --RexxS (talk) 12:42, 23 July 2018 (UTC)[reply]
@Rillke: Some tweaking of the bot in this case would be good, see RexxS's comment. Also, the bot shouldn't really post the notice more than once. Thanks. Mike Peel (talk) 22:44, 23 July 2018 (UTC)[reply]
Hello Mike, you may want to take interwiki information from property P373 rather than "Other sites" section. In the latter case you may stumble in a wikidata entry without that value because it's reserved for the correspondent category in the other projects (hope it makes sense), whereas property p373 is always present. -- SERGIO(aka the Blackcat)17:43, 25 July 2018 (UTC)[reply]
@Blackcat: That's not possible. The sitelink is how we can access information about the category from Wikidata, which is why I've been working a lot on adding commons sitelinks on Wikidata recently. There's no way to search from the category for a corresponding P373 value and then use information from that - if you don't want to use the sitelink then you have to hard-code a QID. It should always be possible to add the sitelink, although if there is a gallery page then you have to also have a separate category-specific item on Wikidata. Another good thing with the sitelink is that there's always only 1 sitelink to a category - but there can be multiple Wikidata items using the same P373 value (mostly incorrectly). Thanks. Mike Peel (talk) 17:51, 25 July 2018 (UTC)[reply]
Hm yes but think to such sitiation: you have for example Juventus F.C. Its wikidata entry has only the property p373 filled (with the Commons category). The correspondent category has instead the link to the commons category in "Other sites". How to deal with that? -- SERGIO(aka the Blackcat)17:59, 25 July 2018 (UTC)[reply]
Hi Mike. I think it's a good idea to keep the existing geocoords at the top of categories even though they are replicated in the Wikidata infobox. The reason is that when adding new images you can copy and paste them without having to (a) go to Wikidata and copy them from there (which is tricky because there they are not in the correct format for Commons) or (b) go back to gridreferencefinder.com and get them from there- that way, the risk of inconsistency lies. Thoughts? Rodhullandemu (talk) 08:06, 5 August 2018 (UTC)[reply]
@Rodhullandemu: You can also do {{Object location|wikidata=Q26504972}}, which produces:
Would that work instead? It's a bit messy, since you still have to get the Wikidata QID, but that's something that structured data on commons should sort out in the longer run. Thanks. Mike Peel (talk) 10:54, 5 August 2018 (UTC)[reply]
Hello Mike,
I have a new problem ;-)
Look at [10]:
The note's asterisk is badly displayed (.
The new version of the category (Category:Amaurocichla bocagii) has a better display.
The better display is due to the carriage return between {{VN}} and * {{Single.
I don't know how to correct {{VN}}.
Best regards Liné1 (talk) 15:46, 6 August 2018 (UTC)[reply]
@Liné1: Mediawiki seems to be connecting the two together, which is odd. One option would be to do [11] - which works in the original case, but adds extra whitespace in the new version. I'll have a think if there's a better way of doing it... Thanks. Mike Peel (talk) 17:21, 6 August 2018 (UTC)[reply]
@Liné1: I thought of a more elegant solution, see [12] - please try that in a few places to make sure it works before copying it over to the main version. Thanks. Mike Peel (talk) 22:12, 6 August 2018 (UTC)[reply]
Hello Mike, is it possible to make it horizontal (like ie institution: or creator: ) rather than vertical and also collapsible (but the latter is not a fundamental matter)? On pages like this it becomes... huh.. can we say bulky? regards. -- SERGIO(aka the Blackcat)
I've been getting a lot of notifications from your bot User:Pi bot when it links categories I've made in the past to Wikidata items. I don't actually want to be notified about this. I've blacklisted Pi Bot for notifications, but those seem to only apply to e-mail notifications. Have others also remarked about this? Is there another way to turn this off? --Vera(talk)10:47, 10 August 2018 (UTC)[reply]
@1Veertje: I think this is a new feature - it's something I've only come across in the last week or so. I think you can disable it in Preferences -> Notifications -> "Connection with Wikidata", untick the box in the 'Web' column (and the 'Email' column too if you want). Thanks. Mike Peel (talk) 13:59, 10 August 2018 (UTC)[reply]
I think I was blind to that setting in the panel for so long because my brain assumed the new list of settings would be listed to the right of the pre-existing e-mail setting. Is it weird that I find it weird that the columns are the other way around? :S --Vera(talk)17:04, 10 August 2018 (UTC)[reply]
Inspiration for file description
Hi Mike, I admire your effort and your work on Wikidata infobox, interproject links etc. As we have an infobox for category pages now, shouldn't we think how to improve file description pages to be more practical, using some principles and algorithms from your infobox template?
The current standard for the "description" field of {{Information}} template is a fully separated description for every language. Only some special templates (e.g. monument ID templates or coordinates templates) are used outside the language templates and are internationalized.
My vision is to enable some structured and internationalized description similar to infoboxes – smart, but friendly and simple for users. If the uploader links the name of the place, subjects, persons etc., some function can call a basic description of them from Wikidata. In the first phase, it can be implementable by some way compatible with the current system of file pages and {{Information}} template and similar file page templates. For the future, it can be converted to some other form of structured data. This structure can be integrated with {{Location}} and {{Object location}} templates, annotations (what is where in the image) etc. What do you think about it? Have you some idea what can be the first steps now? --ŠJů (talk) 04:26, 18 August 2018 (UTC)[reply]
@ŠJů: That's basically Commons:Structured data. :-) Hopefully it'll start becoming available here early next year. There are things we can do before then - for example, if you give a Wikidata QID to {{Artwork}} then it fetches most of the information from Wikidata, and I was playing around with something more general at User:Mike Peel/Depicts. However, it's not very user-friendly - you have to use QID codes manually, and the more complexity you want the more QIDs you have to use. Plus it's not very efficient for the servers. When we have structured data on commons, then that will be a lot easier to do.
That won't apply to categories, though, and they link in with Wikidata through sitelinks, which is why I've been focusing on those rather than files. When we have structured data on commons then it'll make populating the 'depicts' parameter a lot easier based on which categories the files are in and which Wikidata item is associated with the category. So for now, I'd suggest focusing on adding more links between categories and wikidata items. Thanks. Mike Peel (talk) 13:05, 18 August 2018 (UTC)[reply]
@T Cannes I You: I re-copied the coordinates for the first from frwp, see [14]. For the second, is there an area for the bay that could be added to Wikidata? The map will display with a wider zoom then. Thanks. Mike Peel (talk) 20:49, 19 August 2018 (UTC)[reply]
Thanks for La Croix-des-Gardes. The coordinates for the bay of Cannes
seem good but I don't understand why the zoom is so wide: the map shows only the sea. We should be able to have a view of the coast (from La Napoule Théoule-sur-Mer to the Pointe Croisette) and Lerins Islands. Sorry for my bad English. --T Cannes I You (talk) 01:56, 20 August 2018 (UTC)[reply]
@T Cannes I You: Désolé pour mon pauvre français - your English is much better than my French! The zoom level is set by the area of the object - if no area is defined, as is the case here, then it assumes that the zoom should show the most amount of detail in the map. So if area (P2046) for Bay of Cannes (Q2879601) can be added to Wikidata, then the map zoom should automatically adjust based on it. Merci. Mike Peel (talk) 10:41, 20 August 2018 (UTC)[reply]
Oh yes ! Now I understand. But I don't know where the area of the bay can be found. I'm also looking with Golfe de La Napoule, another name for the Baie de Cannes, but I'm not sure that the area of a gulf, of a bay, etc. is a relevant data. See Category:Gulf of Lion, Category:Golfe du Morbihan: same problem. However with Category:Gulf of Maine there is some hope :) --T Cannes I You (talk) 17:14, 20 August 2018 (UTC) Google is a very good translator thanks to him :)[reply]
@T Cannes I You: The areas must be available somewhere ... maybe oceanic surveys around France? Maybe it's a question worth asking on frwp's project chat? Or else they could be calculated, I guess, but that would be less accurate/reference-able... Thanks. Mike Peel (talk) 21:44, 20 August 2018 (UTC)[reply]
Hi Mike, Good work indeed. Question: I see still some connections are missing between commons and wikidata. Many times the commonscategory has a interwiki in the form en:xxxxxx. Can you to add this connections in a automatic way? I can also try to deliver a CSV file as input. Currently I don't have a working script do edit wikidata automatically, so for me it's not possible to add these connections. Rudolphous (talk) 08:43, 18 August 2018 (UTC)[reply]
@Rudolphous: That sounds like a good idea, and if you can provide a CSV file of them then that would help a lot, as I can use that as an input for one of my existing wikidata-editing scripts. The main question is how reliable the matches are. Thanks. Mike Peel (talk) 12:55, 18 August 2018 (UTC)[reply]
@Rudolphous: Mostly done - en:Hythe End no longer exists, so I've skipped that (and any other that don't exist). Otherwise they're all there now. Code at [16]. Category:Massingham, Norfolk was an interesting one, as it's a disambig page on Wikidata, and also was a pseudo-disambig category here - but without any subcategories. It was bot-created in 2009; I've now redirected it.
Do you have an estimate of how many like this there might be? If it's a large number then I probably need to put in a new bot request on Wikidata (unless @Ymblanter: thinks that this might be covered by one of the existing approvals). Thanks. Mike Peel (talk) 21:32, 20 August 2018 (UTC)[reply]
@Rudolphous: Done. A number of the interwikis point to pages that already have another commons category attached to them, so it would be worth re-generating the list and looking through those manually at some point. Thanks. Mike Peel (talk) 18:14, 22 August 2018 (UTC)[reply]
I removed the ones which are done from the lists and made a 3rd list. Removed also the entries on the 3rd list that are not on list1 and 2. Rudolphous (talk) 03:55, 23 August 2018 (UTC)[reply]
Commons categories with an en-interwiki, but no WD sitelink
Here's a query report that might be of interest: [19] -- Commons categories that have an en-wiki interwiki, but no Wikidata sitelink. I've also traced from the en-wiki article to Wikidata, and then seen whether that sitelinks to anything on Commons. The query takes a few minutes to run (maybe the joins could be better directed), but it gets there eventually, and seems to find quite a few sitelink suggestions (7332) that could maybe be added (especially where the names of the en-wiki article and Commons category are identical, or within a few characters of each other); though there are also quite a cases where the interwiki appears to be a convenience link from a more specific Commons category to a more general Wiki article. Anyhow, see what you think. Jheald (talk) 13:56, 27 August 2018 (UTC)[reply]
@Jheald: Interesting. See the discussion above with @Rudolphous: - we've already been working through some lists of interwikis to add them. My concern is with the number of false positives that will be here, although there haven't been too many reverts from the bot's past edits here... Thanks. Mike Peel (talk) 14:39, 27 August 2018 (UTC)[reply]
Interesting query. Can you strip also articles with the templates: "artwork", "wikidata person", "creator", "instituation", "institution", "category definition", "disambig", "disambiguation", "razločitev", "begriffsklärung", "dab", "aimai", "taxonavigation", "Category definition", "lepidoptera", "coleoptera", "taxonavigation", "species", "species2" and "wikispecies? Rudolphous (talk) 15:23, 27 August 2018 (UTC)[reply]
The equivalent query for interwikis to de-wiki: quarry:query/29367 (subject to a requirement that the Wikidata item has an English label).
@Rudolphous: I tried tacking on more and more LEFT JOINs, but the query timed out. (quarry:query/29369). It may be possible to write it more efficiently. Alternatively, it would be straightforward to take the result from the existing query as a first proposal, and then simply write a script to load the wikitext of those pages and look for the templates you want to exclude, as a filter. As it happens, I'm not quite sure why you want to exclude some of these templates -- just because a category page transcludes a {{Creator}} template, should it not still have a sitelink to Wikidata? Jheald (talk) 20:37, 27 August 2018 (UTC)[reply]
@Rudolphous: What may be possible, however, is this query quarry:query/29383 which includes a column for all templates used on the Commons cat page. The results would then be easily filtered to exclude any pages with templates you don't want. As I write, I have tested it with LIMIT 10 and it completes, so I am hoping that it also works for the full set.
I hope this is close to what you may find useful.
For myself, a different tack that I think I'm going to try is queries like quarry:query/29373, looking for category pages in a particular hierarchy that don't have Wikidata links, with a view to then running the names through OpenRefine, to either match or create new items for them on Wikidata. There are some types of creators and types of works and types of places that I am particularly interested in, to help with some other projects, and this may be a useful approach for them. Jheald (talk) 10:15, 28 August 2018 (UTC)[reply]
Dakar Rally editions from 1979 to 2001
Hi, i have noticed that the property "Country" doesn't work after (i think) your recent changes to template "Wikidata infobox". The parameter "Location" in the related commons categories (i.e. see Paris Dakar 1979) appears empty! All my work vanished with (i think) your edit... Can you migrate (with a bot) all the items under the property "country" into the property "Location" in wikidata or, if you thinks appropriate, solve this situation? The Dakar Rally editions are from 1979 to 2001 (included). Thanks. Write to me if i wrote not so clear.. i'm italian. Greetings--Louis.attene (talk) 13:32, 30 August 2018 (UTC)[reply]
Ah, that's a bug with the new code. @RexxS: is it possible to modify the location function to return the country values where the other location properties aren't available? Or I can write an if statement in the infobox to handle this otherwise. Thanks. Mike Peel (talk) 13:35, 30 August 2018 (UTC)[reply]
That's spot-on, Mike. In my experience, it's usually better to keep the granularity of module functions the same and cater for these sort of options within the template by separate calls. That way the "tools" in the module work in the same predictable way and the template designer can create the flexibility they want by combining module calls as needed. Nice work. --RexxS (talk) 14:57, 30 August 2018 (UTC)[reply]
@Mike Peel: Oddly enough, I hadn't implemented the code for decades. It has never shown up until now! Anyway, I've patched something in that works for English, but I have no idea how other languages want their decades to display. I suppose we'll have to wait until somebody tells us.
@Rudolphous: This is now running. Any chance you can have a look at those queries that JHeald was mentioning and see if you can extract a list of ones suitable for adding sitelinks to, or should I modify my code to use the query output (which is easy enough, I'm just not sure if you're doing any extra filtering here). Thanks. Mike Peel (talk) 15:23, 5 September 2018 (UTC)[reply]
Thanks! Almost all infobox are added now of this page. Today the number of articles in [21] grew faster than what we add normally in a day. Do you have an idea where they come from? Rudolphous (talk) 19:41, 8 September 2018 (UTC)[reply]
Père Igor just noticed the dates in qualifier in {{Wikidata Infobox}} are not translated. If you look at Category:Belvès in French or in German, you'll see that the direct property "Dissolved, abolished or demolished" is correctly transated but not the end and start date in qualifier of "Instance of". Could you take a look and correct that ?
{{#invoke:WikidataIB/sandbox |getValue |qid=Q273562 |P576 |fwd=ALL |osd=no |linkprefix=":" |qual=ALL}} → 31 December 2015 ← Use this one for main dates
{{#invoke:WikidataIB |getValue |qid=Q273562 |P31 |fwd=ALL |osd=no |linkprefix=":" |qual=ALL}} → commune of France (–2015), delegated commune (2016–)
{{#invoke:WikidataIB/sandbox |getValue |qid=Q273562 |P31 |fwd=ALL |osd=no |linkprefix=":" |qual=ALL}} → commune of France (–2015), delegated commune (2016–) ← Use this one for qualifier dates
{{#invoke:WikidataIB/sandbox |getValue |qid=Q273562 |P31 |fwd=ALL |osd=no |linkprefix=":" |qual=ALL |lang=fr}} → commune française (–2015), commune déléguée (2016–)
Have a look at the above in different languages. Obviously, the ones we want are the second and fifth lines It seems fine in French and German to me. --RexxS (talk) 22:12, 5 September 2018 (UTC)[reply]
@RexxS: @Joalpe: has spotted a bug when displaying years: {{#invoke:WikidataIB |getValue |qid=Q1850416 |P571 |fwd=ALL |osd=no |linkprefix=":" |qual=ALL}} → 6 June 1818 , but {{#invoke:WikidataIB/sandbox |getValue |qid=Q1850416 |P571 |fwd=ALL |osd=no |linkprefix=":" |qual=ALL}} → 1 January 1818. '1 January' shouldn't be there. Thanks. Mike Peel (talk) 15:50, 6 September 2018 (UTC)[reply]
@Mike Peel: I suspected that might be the case, as the code in Module:Wikidata date went to the trouble of altering the format of the date string passed according to the precision. It seems that Module:Complex date doesn't actually change the format of the numbers depending on the precision supplied. I've re-written the code to use complex_date properly now (I think):
My biggest problem is not having examples of Wikidata entities that have different date precisions to run tests on. I can check using these formats, but it would be nice to know the same worked when we fetch from Wikidata:
{{complex date |date1=1810 |precision1=decade}} → 1810s
date QS:P,+1810-00-00T00:00:00Z/8
{{complex date |date1=18 |precision1=century}} → 18th century
date QS:P,+1750-00-00T00:00:00Z/7
{{complex date |date1=3 |precision1=millennium |era=BC}} → 3rd millennium BC
date QS:P,-2500-00-00T00:00:00Z/6
Those superscripts are horrible. More testing needed, I think. I also need to re-instate the code that does 'circa', but I haven't yet worked out how to internationalise that. --RexxS (talk) 17:57, 6 September 2018 (UTC)[reply]
I've just come to update en:Module:WikidataIB/sandbox only to find that en:Module:Complex date was deleted last year, so I don't have its functionality available on en-wp. As I want to keep a single version of the module on as many sites as possible to ease maintenance, it looks like importing an external module is a dead end and I'm going to have to do a major re-write of WikidataIB to include all of the date-handling functionality internally. It's a pity folks can't just leave well-enough alone. --RexxS (talk) 15:26, 7 September 2018 (UTC)[reply]
@RexxS: Looks like it was speedily deleted for housekeeping reasons, so I've copied the latest version over from commons to there. It looks like it has a few dependencies that also need copying over, though, will work on those now. Thanks. Mike Peel (talk) 15:32, 7 September 2018 (UTC)[reply]
You missed Module:I18n/date, but I've added that now. A bigger problem is that en:Module:Date isn't the same as Module:Date. I've had to create a new module on enwp called en:Module:DateI18n and rename the calls to Module:Date in the other modules. The whole thing is cumbersome as anybody wanting to implement WikidataIB on a new wiki will need to also copy over not just Module:Complex date, but also Module:i18n/complex date, Module:ISOdate, Module:DateI18n, Module:Formatnum, Module:I18n/date, Module:Yesno, Module:Linguistic, and Module:Calendar (at least). I'm really not happy with that, so I'll look at consolidating the code used into a single module. That will be a big job. --RexxS (talk) 13:23, 8 September 2018 (UTC)[reply]
@RexxS: I agree that not having dependencies for so many different modules would be much better, but also agree that it's a big job, sorry... As an aside/hopefully smaller job, I don't suppose it would be possible to have a small function that checks to see if a set of values returned from Wikidata contains a given QID? I currently do {{#ifeq:{{#property:P31|from={{getQID|qid={{{qid|}}}}}}}|{{#invoke:WikidataIB |getLabel |Q5}}|stuff}} to check for humans, which is cumbersome, and only works if P31 only has Q5 - if a second QID is there then this breaks down. Thanks. Mike Peel (talk) 13:30, 8 September 2018 (UTC)[reply]
@RexxS: Looks good! One oddity - adding [[Category:{{#invoke:WikidataIB/sandbox|getValue|rank=best|P569|name=birth|qid={{getQID|qid={{{qid|}}}}}|spf={{{suppressfields|}}}|fwd=ALL|osd=no|noicon=yes|df=y}} births]] to Category:Alfredo Pérez Rubalcaba should add the category (and does without the "/sandbox"), but instead it's displaying as text, any idea why? Thanks. Mike Peel (talk) 18:42, 8 September 2018 (UTC)[reply]
When you look at the html, you'll see that the sandbox version wraps the date in a bunch of extra stuff: <span style="white-space:nowrap"><time class="dtstart" datetime="1951">1951</time></span>, which is going to screw up any use of the date within a compound item. There's no mention of it in the documentation. I'm wasting a lot of time trying to use external modules that I could have used internationalising the previous code. --RexxS (talk) 19:03, 8 September 2018 (UTC)[reply]
That's fixed it, thanks! How do you want to proceed from here - more testing/coding needed, or move the sandboxes to the live versions and see how it goes? Thanks. Mike Peel (talk) 20:05, 8 September 2018 (UTC)[reply]
I think I've got a handle on the complex date module now, and I doubt that it's got many more surprises for us, so it's probably time to go live. It's not difficult to revert (or fix) if some edge cases come up. I'd like to hear from non-English users whether it's doing the job now, but don't know how to solicit that sort of testing. I still need to implement a list of qualifiers passed in the qual parameter, and deal with items of type "math", and internationalise number formatting, and ... a few other things. I might need to return the default to BCE instead of BC if somebody complains, but I'll see if I can get away with that. --RexxS (talk) 20:35, 8 September 2018 (UTC)[reply]
-- checkvalue looks for 'val' as a wikibase-item value of a property (the unnamed parameter or pid)
-- from the item given by the parameter 'qid'
-- or from the Wikidata item associated with the current page if qid is not supplied.
-- If property is not supplied, then P31 (instance of) is assumed.
-- It returns val if found or nothing if not found.
-- e.g. {{#invoke:WikidataIB/sandbox |checkvalue |val=Q5 |pid=P31 |qid=Q42}}
-- or {{#invoke:WikidataIB/sandbox |checkvalue |val=Q5 |P31 |qid=Q42}}
-- or {{#invoke:WikidataIB/sandbox |checkvalue |val=Q5 |qid=Q42}}
-- or {{#invoke:WikidataIB/sandbox |checkvalue |val=Q5 |P31}} for the current page.
Done I disabled GoogleMaps link for now. I hope we can fix this again. I like satellite images instead of vector data. --Jarekt (talk) 03:50, 24 July 2018 (UTC)
Therefore I grant you this barnstar! Ymnes (talk) 17:00, 4 August 2018 (UTC)
