Thanks a lot for contributing to the Wikimedia Commons! Here's a tip to make your uploads more useful: Why not add some categories to describe them? This will help more people to find and use them.
Here's how:
1) If you're using the UploadWizard, you can add categories to each file when you describe it. Just click "more options" for the file and add the categories which make sense:
2) You can also pick the file from your list of uploads, edit the file description page, and manually add the category code at the end of the page.
[[Category:Category name]]
For example, if you are uploading a diagram showing the orbits of comets, you add the following code:
When picking categories, try to choose a specific category ("Astronomical diagrams") over a generic one ("Illustrations").
Thanks again for your uploads! More information about categorization can be found in Commons:Categories, and don't hesitate to leave a note on the help desk.
If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.
Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!
Thanks for pointing that out, TDA. I don't think it alters my point that VM was shopping at 'Shonen's page over the "(Germans) know a thing or two about crematoriums" comment. I know he'd already shopped at Drmies' and El C's talk pages about the explicit video, but surely James J. Lambden was in error by trying to claim that all three shopping trips were over the same edit? --RexxS (talk) 00:43, 29 May 2017 (UTC)[reply]
Seems more accurate to say VM was trying to get Bishonen to reconsider not blocking or taking some action against Dolet and trotted out past incidents such as that one to convince her.--The Devil's Advocate (talk) 00:50, 29 May 2017 (UTC)[reply]
That's perfectly possible, even if unprovable. Nevertheless, it's irrelevant to the point that James J. Lambden was peddling an untruth when claiming that all three urgings were for the same edit. --RexxS (talk) 01:52, 29 May 2017 (UTC)[reply]
I would note the statement right at the open of VM's message to Bishonen where he says "this is the latest incident" and then says "Just a few days prior to the incident with the video" and the header of his message to Bishonen contains the same "nearly blocked you" phrase as the header of Bishonen's message to Dolet. He was responding to Bishonen's statement to Dolet about not blocking that editor over the video and VM was arguing why she should have blocked him, or otherwise taken action.--The Devil's Advocate (talk) 03:36, 29 May 2017 (UTC)[reply]
Yes, I'm sure he was referencing 'Shonen's message to Dolet. But that doesn't alter the point that James J. Lambden assessment of "for the same edit" was completely inaccurate. --RexxS (talk) 12:45, 29 May 2017 (UTC)[reply]
Hi RexxS. Trying {{#invoke:WikidataIB|getValue|P735|name=forename|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}}} at Category:Sarah Stierch returns nothing, but change P735 to P734 and it works fine. Any ideas? Thanks. Mike Peel (talk) 21:04, 4 April 2018 (UTC)[reply]
It is odd, Mike, but in one sense, it's expected. If I look at d:Q5060734 (Sarah Stierch on Wikidata) her family name (Q35682629) shows as "Q35682629" to me, as if there were no label (Stierch) in my language for that wikidata-item. WikidataIB returns nothing by default if there's no article or label for a QID like Q35682629.
The strange part is that fetching the label directly for Q35682629 gives "Stierch"; asking for the local sitelink shows there isn't one (as expected):
{{#invoke:WikidataIB |getLink |Q35682629}} →
{{#invoke:WikidataIB |getLabel |Q35682629}} →
{{#invoke:WikidataIB |getAT |Q35682629}} →
But enabling the "wikidata-link" in getValue() still returns nothing:
I've been looking at P734 as if it were P735. All of the above work if invoked on en-wiki - you get Sarah, Alexandra linked to the articles for those names. Let's try again:
{{#invoke:WikidataIB |getLabel |Q18201513}} → Sarah
{{#invoke:WikidataIB |getAT |Q18201513}} →
{{#invoke:WikidataIB/sandbox |labelorid |Q18201513}} → Sarah
On en-wp we want the wikibase items to be linked to their articles where they exist, but that's where the code gives blank on Commons. Should I make sandbox version without the attempt at linking? Do we use links anywhere here? --RexxS (talk) 02:08, 5 April 2018 (UTC)[reply]
Ah, that's the problem - it's adding the page to the category (see the bottom of the page) rather than displaying the link. Which is particularly ironic here, since I'm trying to use this to check if a category should be added, as most cases don't have the sitelinks so the code checks if "Category:<name> (surname)" exists before adding it! So what I'm after is just something that returns "Sarah" when given the sitelink + property number, which I guess is 'getRawValue' from Module:Wikidata, is there an equivalent to that here? Or maybe I should investigate systematically adding sitelinks for forenames/surnames on Wikidata and switching over to using those... (The Q-number for the surname was a caching issue, since I only added the label in English last night). Thanks. Mike Peel (talk) 11:06, 5 April 2018 (UTC)[reply]
@Mike: I think it's better to give you tools to decide what you want. I've added switch called 'linked' to the sandbox code that enables or disables the site-linking. It's enabled by default, but can be turned off by setting |linked=no (or 'false' or '0' for JavaScript addicts) like this:
{{#invoke:WikidataIB/sandbox |getValue |P735 |qid=Q5060734 |fetchwikidata=ALL |onlysourced=no |linked=no}} → Sarah, Alexandra
Shall I just update the main module from the sandbox? It looks like the switch plays nicely with the current code. --RexxS (talk) 14:29, 5 April 2018 (UTC)[reply]
Hi RexxS. There's an issue with how long it takes to generate the infobox at Category:Poland, which goes away if the qid is manually specified, so it looks like {{GetQID}} is taking up a lot of processing time (mostly due to how many times it's called in the infobox now). I suspect that's due to {{#invoke:wd|property|raw|P301}}, which returns the QID of the value for category's main topic (P301). That module's quite complex, so I was wondering if you might be able to write a small Lua function that would do the job more efficiently here? Thanks. Mike Peel (talk) 18:16, 23 May 2018 (UTC)[reply]
@Mike: I've done my best to make the getQid() function in Module:WikidataIB/sandbox as fast as I can. You call it like this:
Thanks! I've created {{GetQID/sandbox}} and switched {{Wikidata Infobox/sandbox}} to using that, and it's sped up dramatically (from >10s of Lua runtime to around 1.5s). Could that function be moved to the main version of WikidataIB, or a separate module, so I can make that code live? (I don't want to transclude a sandbox on ~380,000 categories!) Thanks. Mike Peel (talk) 20:58, 23 May 2018 (UTC)[reply]
Sure, Mike. The function's now added in Module:WikidataIB. It's self-contained, so can be re-used anywhere. I should say that the code in Module:WikidataIB/sandbox is far more efficient in almost every function, so you ought to consider updating the main module from the sandbox sometime (which would also sync it with the en-wiki version). I don't really have much time to test here on Commons, so I'll have to rely on you to tell me when we can do the update here. --RexxS (talk) 21:22, 23 May 2018 (UTC)[reply]
Great, that's now live. Sorry I haven't had chance to test out the sandbox version of the main module yet - will do so soon. Thanks. Mike Peel (talk) 21:26, 23 May 2018 (UTC)[reply]
correctly returns just 52. It looks like it's the same for the latitude. You can see it live at Category:Poland (below the map). More soon! Thanks. Mike Peel (talk)
Hi Mike. I forgot to mention that Ederportomodified the getCoords() function in Module:WikidataIB, which makes it incompatible with the en-wiki version (hence what we have in the sandbox). The enwiki version uses 'display' for "title / inline" and 'format' for "decimal / dms" in both getValue and getCoords so that it can use Template:Coord for the getCoords function (I didn't want parameters doing different things in different calls). Unfortunately the commons version now uses 'display' for "decimal /dms" and 'format' for "latlong / lat / long" in getValue, but 'display' for "title / inline" in getCoords. The enwiki versions don't yet have any code to return just latitude or longitude, and I really need to sort out with Ederporto if we can get the parameter names consistent before I try to add another parameter to switch between "latlong / lat / long" in the newer versions. The reason the bug you found exists is that the functionality you are looking for is only found in the commons Module:WikidataIB at present.
Aah, OK. The ability to display just the long and the lat in degrees is quite important for various map tools that take those as separate parameters rather than as a combined string, so it would be good if they could be added to the new version. I'll have a look at the documentation later today. Thanks. Mike Peel (talk) 13:30, 26 May 2018 (UTC)[reply]
Thanks! Those work well in the infobox, but there seems to be an issue with the map code at Template:Mapframe/Wikidata/sandbox as that requires {{#invoke:WikidataIB|getValue|P625|qid=Q155|fetchwikidata=ALL|onlysourced={{{onlysourced|no}}}|noicon=yes|display=decimal|format=longlat|{{{coordinates|}}}}} -> 14°S 53°W. Could you add the equivalent of that to the new version, please? Thanks. Mike Peel (talk) 18:40, 26 May 2018 (UTC)[reply]
@Mike Peel: One call is better: {{#invoke:WikidataIB/sandbox|getPreferredValue|P625|qid=Q155|fetchwikidata=ALL|maxvals=1|onlysourced=no|noicon=yes|format=decimal|show=longlat}} → -53, -14
Thanks, I've switched the code to use that now. I haven't spotted any other issues apart from the date handling - I'll let you know if any come up. Thanks. Mike Peel (talk) 20:03, 26 May 2018 (UTC)[reply]
OK, most things are looking good. The only remaining issue I can spot is that the dates for the qualifiers aren't multilingual - I don't suppose it's possible to run them through Module:Wikidata date, or incorporate that code's date handling into WikidataIB? Thanks. Mike Peel (talk) 19:02, 26 May 2018 (UTC)[reply]
@Mike Peel: In the sandbox I've implemented a parameter |collapse= which sets the maximum number of items that can be returned before the content is collapsed. It works like |maxvals=: omitted or zero means no collapse. How does this look for Claire Danes (Q867813) and award received (P166):
Golden Globe Award for Best Actress – Television Series Drama, Primetime Emmy Award for Outstanding Lead Actress in a Miniseries or a Movie, Satellite Award for Best Actress – Miniseries or Television Film, Golden Globe Award for Best Actress – Miniseries or Television Film, Screen Actors Guild Award for Outstanding Performance by a Female Actor in a Miniseries or Television Movie, Satellite Award for Best Actress – Television Series Drama, Satellite Award for Best Actress – Television Series Drama, Satellite Award for Best Actress – Television Series Drama, Golden Globe Award for Best Actress – Television Series Drama, Golden Globe Award for Best Actress – Television Series Drama, Critics' Choice Television Award for Best Drama Actress, TCA Award for Individual Achievement in Drama, Screen Actors Guild Award for Outstanding Performance by a Female Actor in a Drama Series, London Film Critics Circle Award for Actress of the Year, MTV Movie Award for Best Female Performance, Young Artist Awards, Young Artist Awards, Primetime Emmy Award for Outstanding Lead Actress in a Drama Series, Primetime Emmy Award for Outstanding Lead Actress in a Drama Series, star on Hollywood Walk of Fame, Hasty Pudding Woman of the Year
{{Wikidata Infobox/sandbox|qid=Q192724}} throws "Lua error in Module:WikidataIB/sandbox at line 558: attempt to index local 'artitle' (a nil value).", otherwise it looks good to me. If you can sort that bug out, then I suggest that we make the sandbox versions live today, and come back to the multilingual date issue a bit later, if that's OK with you? Thanks. Mike Peel (talk) 11:44, 28 May 2018 (UTC)[reply]
@Mike Peel: I could have sworn I fixed that once already. On Commons you may not be able to create a title corresponding to a given label, but we don't want to link to non-existent articles anyway. That should be fixed now. --RexxS (talk) 11:55, 28 May 2018 (UTC)[reply]
Maybe that was in the main version but not in the sandbox? I'm afraid I just spotted another issue - qualifiers probably need to apply the same 'linkprefix' as the main value, otherwise qualifiers that sitelink to categories end up transcluding the page in that category rather than displaying the name. Same example as before, look at the part of the series (P179) line. Thanks. Mike Peel (talk) 12:19, 28 May 2018 (UTC)[reply]
@Mike Peel: That's relatively easy to implement, as the code that governs the output for the qualifiers is the same as that for the main property value – I had merely set the link/pre/postfixes to "" for qualifiers, as I din't think they would be needed. I think that having them the same as the property link/pre/postfixes is too inflexible and I anticipate problems if there ever is a need to have them different, so I've created qprefix, qpostfix, qlinkprefix, qlinkpostfix as new parameters. Of course you can always pass the same infobox parameter to the two module parameters if your application works with that: |linkprefix={{{linkprefix|}}} |qlinkprefix={{{linkprefix|}}}, etc. I can't figure out what example you mean, but does the change allow you to fix the problem now? --RexxS (talk) 13:48, 28 May 2018 (UTC)[reply]
The more general approach sounds good. However, testing:
That's great, thanks! I'm not sure where it gets the link for "1" from, as that's supposed to be a numerical value not an item link, but that's just a cosmetic issue. Thanks. Mike Peel (talk) 19:59, 28 May 2018 (UTC)[reply]
(Edit conflict) @Mike Peel: Unfortunately, the series ordinal (P1545) has a datatype of "string", which it is not. The "Integer datatype" is not yet implemented. Because it's currently a string, applying the qlinkprefix parameter triggers the linking (if you remember we needed to process urls) and there is a Category:1 for it to link to. I could disable linking for strings and retain it for urls, but I'm not sure what knock-on effects that would have. The other possibility would be to specify just the qualifier you want like this:
It can probably stay as it is for now, it's not a big issue (and I might actually just disable qualifiers from being shown with this property). Up to you if you want to try suppressing linking of strings, but that does sound like it could have side-effects... Thanks. Mike Peel (talk) 21:36, 28 May 2018 (UTC)[reply]
Hey, I'm really sorry. I'm getting used with new job schedules and didn't had really much time to interact with the module or its functionalities and sync with others. I got the notifications, but didn't had time to see deep the codes, but whatever you guys do, I'm on board. I need to look at the module at ptwiki to see if there is anything out of date to sync (unfortunately, as I said some time ago, any synchronization has to be done with care, because some changes to meet local demands are not (and should not be, perhaps) implemented in enwiki), but looking over, this update on the mapframe code due to wikidataIB functionalities is awesome and cleans up a dirty code I made. Soon enough I'll be in my normal rate again, i hope. Good contributions, Ederporto (talk) 03:13, 30 May 2018 (UTC)[reply]
Another oddity: {{#invoke:WikidataIB|getValue|rank=best|P1477|name=birthname|linkprefix=":"|qlinkprefix=":"|qid=Q16185856|spf={{{suppressfields|}}}|fwd=ALL|osd=no|noicon=yes|qual=ALL}} shows "Bleta Rexha" rather than "Bleta Rexha" at Category:Bebe Rexha (spotted after I reverted the removal of the infobox by a new-ish editor, I guess that was why). Thanks. Mike Peel (talk) 20:07, 30 May 2018 (UTC)[reply]
@Mike Peel: Not actually an oddity. Because the new code only reads properties as needed, it doesn't have access to the entire entity and we can't specify entity:formatPropertyValues(propertyID).value to deal with the cases of datatypes that the code doesn't yet have a handler for (as we used to do). If we go back to the using that, we have to load the whole Wikidata entity and we lose all the the advantages of lowering the load on the server as well as speed, and the ability to get specific watchlist notifications, etc.
The property birth name (P1477) has a datatype of "Monolingual text", so I've now written a handler for it in the sandbox.
As we come across new datatypes, I'll have to write handlers for them. I can't do that until I see an example, because there is absolutely no documentation that I can find that gives the structure of the different data types. I have to dump the property and examine it each time :(
I've made further changes to the enwiki sandbox module to try to minimise the issue of spurious "What links here". That means the synchronised code in Module:WikidataIB/sandbox is effectively untested again (although it's working fine in en:Module talk:WikidataIB/sandbox/testing), so if you intend to update the main module from the sandbox, do it at a time when you can catch any problems that turn up. Sorry we don't seem to have anything stable lately, but it's worth it to increase functionality while we are getting such good feedback. --RexxS (talk) 21:55, 30 May 2018 (UTC)[reply]
It's not late for me, of course, as I'm not at work in the morning – or the morning after, or ... [grinning from ear to ear]. Ok, though, the morning is fine. --RexxS (talk) 22:12, 30 May 2018 (UTC)[reply]
Category:Maria Goeppert-Mayer is showing "Lua error in Module:WikidataIB at line 735: attempt to index local 'lang' (a nil value)." Code to reproduce it: {{#invoke:WikidataIB/sandbox |getValue |P166 |qid=Q57100 |fwd=ALL |osd=no|qual=ALL}}. Thanks. Mike Peel (talk) 22:35, 1 June 2018 (UTC)[reply]
I hadn't set the language for qualifiers. Done now in both main and sandbox.
Thanks! Here's an odd one: Category:Old St Margaret's church tower, Lee is very close to longitude=0, and it looks like the scientific notation that the longitude is being returned in isn't compatible with Kartographer. I'm not sure if this is something that needs to be fixed with the Lua code or reported as a bug to the maps team... Thanks. Mike Peel (talk) 13:42, 2 June 2018 (UTC)[reply]
That was a tough one, Mike. First of all, {{Mapframe/Wikidata}} is very fragile. I often get a blank map when I preview for a second or subsequent time. This ought to work for Paris (Q90), but often doesn't:
Another one, sorry! Category:How I Met Your Mother is returning "Too many Wikidata entities accessed." It looks like it has a huge list of cast members on Wikidata. Is there a way of cutting off the list before that happens? Also, will you be at Wikimania this year? Thanks. Mike Peel (talk) 22:31, 4 June 2018 (UTC)[reply]
@Mike Peel: What would one expect with 482 statements for cast member (P161). I would suggest using maxvals in the template to limit the number of items returned to something palatable until such time as the servers can cope with those big numbers. I can't edit the template to help you, I'm sorry. I'm not going to Wikimania this year. --RexxS (talk) 22:48, 4 June 2018 (UTC)[reply]
I'd forgotten about maxvals - that seems to work nicely, thanks! Sad to hear that you won't be at Wikimania, hope to catch up in-person at Christmas then! Thanks. Mike Peel (talk) 23:10, 4 June 2018 (UTC)[reply]
Another one: {{#invoke:WikidataIB/sandbox |getValue |P31 |qid=Q2472824 |fwd=ALL |osd=no|qual=ALL}} -> "Lua error in Module:WikidataIB/sandbox at line 588: attempt to index local 'insval' (a nil value)." Thanks. Mike Peel (talk) 00:08, 7 June 2018 (UTC)[reply]
An odd one, Mike. The error wasn't showing up for me. However, I've removed the code that explicitly tests for a link to a dab page, as it's not helpful.
Another, but this one's more subtle: at Category:Presença Feminina, "Category:Santo António, Madeira" is being shown for the headquarters location, but it's not clear where "Category:" is coming from. Is this connected to the discussion of showing the sitelinks rather than the label? Code to reproduce: {{#invoke:WikidataIB/sandbox |getValue |P159 |qid=Q54859736 |fwd=ALL |osd=no|qual=ALL|linkprefix=:}} Thanks. Mike Peel (talk) 03:16, 9 June 2018 (UTC)[reply]
@Mike Peel: Yes, that's exactly what it is. On Commons, we often use "Category:" as part of the sitelink. I've added the code to strip the namespace.
That allows sitelinks to be used where possible, on the assumption that they are more difficult to vandalise (I wish!). --RexxS (talk) 09:52, 9 June 2018 (UTC)[reply]
Thanks, that looks good now. It might be nice to have a switch to disable that in certain cases if needed, although it seems to be working well so far. On another topic, there's a Wikidata event here this weekend, so I might try to to test out the new version on ptwp. I think most of the changes there were just localisation, but there may be a few others that need figuring out. Thanks. Mike Peel (talk) 11:40, 9 June 2018 (UTC)[reply]
Thinking about this some more, it's best if the sitelink-rather-than-label feature is disabled here, if possible - see Category:Cape Town for an example of where it goes wrong (since South Africa - Ningizimu Afrika - Suid-Afrika - Afrika Borwa exists), plus it's English-only here since that's the default for the category names. Maybe a parameter like "usesitelinks=no" could be added that could be used to disable this here? Thanks. Mike Peel (talk) 01:11, 13 June 2018 (UTC)[reply]
Well, Mike, that's a bloody clever title for a page. Okay, rather than force anybody to add even more parameters, and because I'd like to keep this module sync'd with the enwiki one, I've simply detected whether the module is on Commons and, if it is, disabled the code that substitutes the sitelink for the label. Category:Cape Town seems to be behaving itself now. Cheers --RexxS (talk) 16:23, 13 June 2018 (UTC)[reply]
@Mike Peel: Module:Taxontree is already live, of course. I've made a copy of the test cases for WikidataIB at Module talk:WikidataIB/testing, so we can see if the functionality remains after the sync. I suppose I ought to make a test cases page for the sandbox as well, but I'll do that later. I think the changes don't disturb the main logic of WikidataIB, so I don't expect problems with the previous functionality. Obviously we'll need to be alert to any issues arising from the new functionality, but I doubt that it will have much unexpected impact. I'd say go ahead and do the sync if you're okay with that. --RexxS (talk) 16:57, 24 September 2018 (UTC)[reply]
That's fine, Mike. I keep the master copy on my local PC anyway, so there's never anything lost. Today's version has had a good cleanup and a few bugs ironed out, so it's a good one to keep as the stable version for a while. You may find en:Module:WikidataIB #Helper_templates to be candidates for importing here, as all of them should reduce the load of an infobox by reducing the number of Wikidata calls. I'll try to find the time to have a look at a new function to de-dupe aliases and short names for you, maybe tomorrow. Cheers --RexxS (talk) 21:46, 15 November 2018 (UTC)[reply]
Although hard-coding it into the line by passing it as an extra parameter to the line template would take less Wikidata calls, but be a little more work in setting up. You could use:
and pass e.g. |formatterurl=http://www.whocc.no/atc_ddd_index/?code=$1 to the line that displays ATC code, etc. Does that make sense? --RexxS (talk) 22:14, 15 November 2018 (UTC)[reply]
I'm trying to avoid hard-coding anything, so that if things are updated on Wikidata then they are updated everywhere else too. Trying the first call on enwp doesn't seem to work - the link doesn't seem to work and the code appears after the link. Thanks. Mike Peel (talk) 22:22, 15 November 2018 (UTC)[reply]
@Mike Peel: Bleh, I meant to suppress the pen icon in the call for the formatter url:
Hi RexxS. Would it be possible to modify the WikidataIB getQID function so that it can follow through more properties than just category's main topic (P301)? Over on en.Wikisource, @Billinghurst: is asking if we can do things like follow main subject (P921), and it might also be useful here to be able to follow category combines topics (P971). I guess the complication is where there are multiple values for the property, in which case having the option of being able to either use maxvals=1 or for it to loop through all of the values would be useful, but just using the first value would be OK for now. Thanks. Mike Peel (talk) 07:50, 8 October 2018 (UTC)[reply]
As a general comment with regard to the Wikisources, there is so much following relationships to get to a primary Wikidata item/Wikipedia article, or further to another Wikidata item
attaching an article to its subject matter, hoping that there are not multiple subjects, or at least not subjects of equal value
So we often have numbers of scenarios of needing to follow properties to connect to an interwiki rather than something neat. d:Wikidata:WikiProject Books shows the book <-> relationship, though won't cover articles. — billinghurstsDrewth 11:39, 8 October 2018 (UTC)
@Mike Peel and Billinghurst: I've knocked up something that sort-of extends getQid as a first try. Here's the rough documentation:
Note that {{wdib|P921|qid=Q1079|fwd=ALL|osd=n}} → drug trafficking, dysfunctional family , but followQid just returns the QID of the first one it finds.
Thoughts? --RexxS (talk) 21:27, 8 October 2018 (UTC)
Displaying "has part" or nearby coordinates in maps[edit]
Fancy a challenge? It would be good if we could include the coordinates from the Wikidata items linked through has part(s) (P527) in the infobox maps - or, if there aren't any, then the nearby items. Mapframe supports this, the trick is to feed in the coordinates and labels appropriately. There's an example of the mapframe code at Category:Haderslevbanen (but that's not properly on Wikidata yet). A useful test case might be Category:Teide Observatory - the telescopes that are part of the observatory mostly have locations on Wikidata. Is this possible with the existing Lua functions that you can tap into? If not, then I'd be tempted to request it through the community wishlist process. Thanks. Mike Peel (talk) 22:22, 31 October 2018 (UTC)[reply]
@Mike Peel: As I'm mentoring for Google Code-in for another six weeks, another challenge is definitely not high on my current wish-list. I don't know how to access d:Special:Nearby#/page/Q2013047 from the Wikibase client in Lua, so I'd have to find out if it's possible. In the meantime, the community wishlist looks like your best bet. --RexxS (talk) 23:17, 31 October 2018 (UTC)[reply]
@Mike Peel: I've updated the sandbox to the latest version from en-wiki which implements the extended location function and getValueByRefSource. They should be working properly, so there's no reason not to catch up on the latest changes. --RexxS (talk) 23:27, 1 November 2018 (UTC)[reply]
@Mike Peel: Getting access to the entire set of labels for an item as a simple wikibase client call is something I've been wanting for some time. The same goes for the complete set of sitelinks. I suppose it would also apply to the set of descriptions and the set of aliases. I could easily write a function to fetch any of those sets, but it would require fetching the entire entity object and extracting the relevant set. That is an expensive call if we're using arbitrary access. There is also then the problem that it then marks all of the item's Wikidata properties as being used by the calling page, which causes watchlist notifications to show so many irrelevant notifications that editors tend to turn those off. I'll write one or two of the functions for you to try out, so you can evaluate its effects for yourself. I suppose it might not be as bad as I think. --RexxS (talk) 23:07, 4 November 2018 (UTC)[reply]
Aah, OK. Is that how Module:Interwiki does things to get the complete list of sitelinks? Maybe it's something else that could go to the community wishlist. But if you can write something now, then we can see how much extra loading it puts on things as-is... Thanks. Mike Peel (talk) 23:43, 4 November 2018 (UTC)[reply]
@Mike Peel: Module:Interwiki does just that but wraps it up in a more foolproof container to deal with redirects, etc. Anyway, here we go for Norway (Q20):
Descriptions: {{#invoke:WikidataIB/sandbox |getAllDescriptions |qid=Q20}} → país del norte de Europa (es); land í Norður-Evrópu og eitt Norðurlandanna (is); مُلُک (ks); ma lon ma Elopa (tok); negara di utara Eropah (ms); country in Northern Europe (en-gb); country wey dey 4 di northern part of Europe (pcm); stat în Europa de Nord (ro); 北歐國家 (zh-hk); štát v severnej Európe (sk); держава у Північній Європі, в західній частині Скандинавського півострова (uk); 北歐國家 (zh-hant); 北欧国家 (zh-cn); 북유럽의 국가 (ko); lando en Nordeŭropo, bordanta Nordan Maron, Atlantikon, kaj Arktan Oceanon, apud Svedio, Finnlando, kaj Rusio (eo); stát v severní Evropě (cs); Pais den Oropa (pap); ꠁꠃꠞꠥꠙꠞ ꠄꠉꠥ ꠖꠦꠡ (syl); ইউরোপের রাষ্ট্র (bn); pays d'Europe du Nord (fr); nagara ing Eropa Lor (jv); država u sjevernoj Europi (hr); 北欧国家 (zh-my); мастор Пелевеёнкс Европасо (myv); उत्तर युरोपातील एक उत्तरी देश (mr); stat w sewjernej Europje (hsb); ଉତ୍ତର ଇଉରୋପରେ ଥିବା ଏକ ଦେଶ (or); suverēna valsts Ziemeļeiropā (lv); pagilian idiay Amianan nga Europa (ilo); држава у северној Европи (sr); χώρα της βόρειας Ευρώπης (el); país no norte da Europa (pt-br); 北欧国家 (zh-sg); Staat op der skandinavescher Hallefinsel (lb); land i Nord-Europa (nn); land i Nord-Europa (nb); Şimali Avropada ,Skandinaviya yarımadasının qərb hissəsində və ona yaxın adalarda yerləşən dövlət (az); 北欧国家 (zh-hans); उत्तरी युरोपको देश (ne); ಜಪಾನ್ನ ಪ್ಯ್ಹುಯುಕೋಕಾ ಪ್ರಿಫೆಕ್ಚರ್ನಲ್ಲಿರುವ ನಗರ (kn); وڵاتێک لە باکووری ئەورووپا (ckb); country in Northern Europe (en); إحدى الدول الإسكندنافية الواقعة في شمال أوروبا (ar); država u sjevernoj Evropi (bs); ਉੱਤਰੀ ਯੂਰਪ ਵਿੱਚ ਦੇਸ਼ (pa); pàize de l'Eoröpa (lij); país no norte da Europa (pt); állam Észak-Európában (hu); Kuzey Avrupa'da bir ülke (tr); 北歐國家 (zh-tw); നോർവേ (ഔദ്യോഗികമായി കിങ്ഡം ഓഫ് നോർവേ) വടക്കൻ യൂറോപ്പിലെ ഒരു രാജ്യമാണ് (ml); państwo w Europie Północnej (pl); estáu d'Europa (ast); государство в Северной Европе (ru); Staat in Nordeuropa (de-ch); Staat in Nordeuropa (de); negara di Eropa Utara (id); краіна ў Паўночнай Еўропе (be); کشوری در شمال قارهٔ اروپا (fa); 北歐國家 (zh); Dewletekî Ewropayê (ku); სახელმწიფო ჩრდილოეთ ევროპაში, სკანდინავიის ნახევარკუნძულზე (ka); 北ヨーロッパの国 (ja); Staat in Nordeuropa (de-at); պետություն Հյուսիսային Եվրոպայում՝ Սկանդինավյան թերակղզու արևմտյան մասում (hy); land in Noord-Europa (nl); Un Land in Europa (ie); מדינה בצפון אירופה (he); civitas Europae (la); வட ஐரோப்பாவின் அரசியலமைப்பு முடியாட்சி நாடு (ta); them andi Eropa (rmy); ఉత్తర ఐరోపాలోని ఒక దేశం (te); valtio Pohjois-Euroopassa (fi); land i Nordeuropa (da); un pais en Europa (lfn); jiõččnaž valdia tâʹvv-Eurooppâst (sms); بلاد فشمال ؤروپا (ary); Stato dell'Europa settentrionale (it); држава во Северна Европа (mk); jiečânâs staatâ tave-Euroopâst (smn); држава у северној Европи (sr-ec); краіна ў Паўночнай Эўропе (be-tarask); cȳnerīce ofer norþenam Europan (ang); кеферпатан Европада (lez); ایک یورپی ملک (ur); kintra in Scandinavie, Northren Europe (sco); gonagasriika Davvi-Eurohpás (se); paìsi nta l'Europa dû Nord (scn); država u severnoj Evropi (sr-el); pajjiż fit-Tramuntana tal-Ewropa (mt); país d'Europa (ca); Põhja-Euroopa kuningriik (et); gwlad ar ochr ddwyreiniol Môr y Gogledd sy'n un o wledydd Llychlyn (cy); država v Evropi (sl); bansa sa Hilagang Europa (tl); country in Northern Europe (en-ca); konstitutionell monarki i Nordeuropa (sv); ราชอาณาจักรในยุโรปเหนือ (th); nchi katika Ulaya Kaskazini (sw); dùthaich ann an Lochlainn anns an Roinn-Eòrpa (gd); tamurt n Turuft Ugafa (kab); държава в Северна Европа (bg); tír in iarthuaisceart na hEorpa (ga); اتر يورپ جو ھڪ ملڪ (sd); 北歐國家 (zh-mo); país nórdico (gl); उत्तरी यूरोप में एगो संबैधानिक राजतंत्र (bho); country in Northern Europe (en-us); Quốc gia quân chủ lập hiến tại Bắc Âu (vi)
Aliases: {{#invoke:WikidataIB/sandbox |getAllAliases |qid=Q20}} → Reino de Noruega, NO, NOR, 🇳🇴 (es); Noruega (nah); Кралство Норвегия (bg); Regatul Norvegiei, 🇳🇴 (ro); 挪威王國 (zh-hk); Konungariket Norge, Noreg (sv); Королівство Норвегія (uk); 挪威王國 (zh-hant); Оцязорксшись Норвегия (mdf); Nuuka (ik); Norvegujo, Reĝlando Norvegio, NO, NOR (eo); नॉर्वे, आधी रात के सुरुज के देस (bho); নরওয়ে কিংডম, নরওয়ে রাজ্য, 🇳🇴 (bn); Royaume de Norvège, 🇳🇴, NO, NOR, le Royaume de Norvège, Norv. (fr); NO, NOR, no, Norveško kraljevstvo (hr); 挪威王国 (zh-my); Kralestwo Norwegska (hsb); Na uy (vi); Norvegėjė (sgs); Краљевина Норвешка, Норге, Норвеге, NO, NOR, no, Noreg, 🇳🇴, Норвеген, Норвешко Краљевство (sr); Norway (rn); Reino da Noruega (pt-br); Norrowey, Kinrick o Norawa, Kinrick o Norrowey (sco); Kongeriket Noreg, Norge (nn); Kongeriket Norge, Noreg, Kongeriket Norge/Noreg (nb); Norveç krallığı (az); นอร์เวย์, Norway, ราชอาณาจักรนอร์เวย์, Kingdom of Norway (th); Noruvetia (ty); 挪威王國 (lzh); Taažâ kunâgâskodde (smn); Kingdom of Norway, NO, NOR, 🇳🇴 (en); Норвегин Нутуг (xal); 挪威王国 (zh-hans); 挪威王國 (zh-tw); Noruwega (ceb); Norge, Kongeriket Noreg, Kongeriket Norge, Kingdom of Norway, Noreg, 挪威王國, Norway (yue); Norvég Királyság (hu); Norway, Nô͘-ui, Norge, Ná-ui (nan); مملكة النرويج (ar); Nöörjen gånkarijhke (sma); Norra Kuningriik (et); Reinu de Noruega (ast); Regne de Noruega, Norvègia, Norveja (ca); Königreich Norwegen (de-ch); Teyrnas Norwy, no (cy); 挪威王國 (zh-mo); Nórske kráľovstvo (sk); Նորվեգիայի Թագավորություն (hy); Noorweagen, Noorweeg, Noorweagn (nds-nl); Kongeriget Norge (da); ნორვეგიის სამეფო (ka); ノルウェー王国, ノルウェイ (ja); Königreich Norwegen (de-at); ناروی (fa); ꠘꠞꠅꠦ ꠞꠣꠁꠎ꠆ꠎ (syl); Noorwey (om); ממלכת נורבגיה, נורבגיה, ממלכת נורווגיה (he); Kerajaan Norwegia (id); 挪威王国 (zh); ន័រវែស (km); نۆرویژ, نەرویج (ckb); Norge, Noreg (fi); Royaume de Norvège, 🇳🇴 (frc); Noreg, Norge, Королевство Норвегия, Norway, Kongeriket Norge, Kongeriket Noreg (ru); Taar koonǥõskåʹdd (sms); நோர்வே, ஐரோப்பா, நார்வே, நோர்வே பேரரசு (ta); Regno di Norvegia, Noreg, Kongeriket Norge, Kongeriket Noreg (it); Renju tan-Norveġja (mt); Norgga gonagasriika (se); Nowei (bi); Каралеўства Нарвэгіі, Каралеўства Нарвэгія (be-tarask); Norvège (frp); Vuona gånågisrijkka (smj); Norþweg, Norþƿeg, Norþweȝ (ang); ನಾರ್ವೇ (kn); Noowe (lg); Norveggia (scn); Norwegen (pfl); Норуегиэ (kbd); Norveç Krallığı, 🇳🇴 (tr); ਨਾਰਵੇ (pa); noreg (jbo); Nouei (sm); Нурвеж (tg); Königreich Norwegen (de); Norwegen (gsw); Nɔwei (tw); Królestwo Norwegii (pl); നോർവേ, കിങ്ഡം ഓഫ് നോർവേ (ml); NO, NOR (nl); Norvexa (vec); 挪威王国 (zh-cn); Norveggia, Nòrvexa (lij); 挪威, 挪威王國 (cdo); Βασίλειο της Νορβηγίας (el); Noreg, Kongeriket Norge, Kongeriket Noreg (no); Kingdom of Norway (en-us); 挪威王国 (zh-sg)
Others items may be smaller. Just leave the |qid= as blank if you want to use it on the current page as that's cheaper. Cheers --RexxS (talk) 00:59, 5 November 2018 (UTC)[reply]
Thanks! Unless I'm missing something, that doesn't look too expensive for the servers according to the parser profiling data, so it's now in the infobox sandbox for testing. Thanks. Mike Peel (talk) 10:06, 5 November 2018 (UTC)[reply]
I have an (too me) interesting task. It is on a stack of other interesting tasks, some of which I am good at. There is one that you might be interested in or perhaps know of an interested participant. This is the task:
At wikisource there is a beautiful old document which is unfortunately a cludge of journals and without an easy to navigate table of contents.
The module there has allowed me to very, very easily create an article to article navigation. The TOC creation requires using different data entities which that module is not robust enough to accomplish.
For a sensible TOC, (these articles are taxonomy based, one set of "family" with its own navigation and another set of species, with a separate navigation. And at this point, I am beginning to articulate ideas that will show how much this hat does not fit me now.
At wikidata, d:Q56760778 is almost a complete TOC for Part 1. This particular document (iirc) uses the word "Part" in (at least) two different ways, so beware....
@RaboKarbakian: My usual role in these sort of cases is to provide the tools to do a job, principally because I rarely understand what is actually required as the finished product. Let me offer you a selection of what there is already:
I assume that you would want these sorted by series ordinal? At present they are sorted according to their position on Wikidata. The last one isn't part of the series and has no series ordinal, so is it okay at the end?
If you want to see what a particular Wikidata entry looks like in detail for a given property, I wrote a little function to display it:
You might find that useful in looking at what the Wikidata entry actually contains.
Anyway, I'd encourage you to try to make use of what is already available, and then let me know if you can't find something to do a particular job, or if you get stuck. Cheers --RexxS (talk) 22:58, 10 December 2018 (UTC)[reply]
WOW! I spent my day thinking about ways to call wikidata for each of the has parters. You had it already here. Sir, or Ma'am. Dude. I am pleasantly stunned.--RaboKarbakian (talk) 01:32, 11 December 2018 (UTC)[reply]
Almost everything is protected so I won't bother with it -- trying to determine the logic for the categorization is going to bother me, however. I won't bother you again. Or Mike Peel.--04:43, 11 December 2018 (UTC)
Hi RexxS, happy new year! I'm trying to put together some code that would auto-categorise by occupation. It's sort of working at User:Mike Peel/Occupation, e.g. {{User:Mike Peel/Occupation|qid=Q7356166}} -> User:Mike Peel/Occupation. However, ideally it would go through astronomer (Q11063) to get the commons sitelink from Category:Astronomers (Q6562) to display 'Astronomers' instead of 'astronomer' (or use P373 for now if needed). Would that be straightforward to add? I can't use the getCommonsLink function as I need the prefix/postfix options from getValue (doing nested calls to WikidataIB again). Thanks. Mike Peel (talk) 07:47, 2 January 2019 (UTC)[reply]
{{#invoke:WikidataIB |getValue |rank=best |P106 |qid=Q7356166 | name=occupation |fwd=ALL |osd=no |noicon=yes | linked=n |postfix=" from somewhere"}} → astronomer from somewhere
{{#invoke:WikidataIB |getPropOfProp |rank=best |prop1=P106 |prop2=P373 |qid=Q7356166 | name=occupation |fwd=ALL |osd=no |noicon=yes | linked=n |postfix=" from somewhere"}} → Astronomers from somewhere
Will that do the job for you? In general, getPropOfProp should be able to fetch a property one step removed in almost any case, and should be a "drop-in" replacement by changing |Pxxx to |prop1=Pxxx |prop2=Pyyy --RexxS (talk) 10:52, 2 January 2019 (UTC)[reply]
Thanks RexxS, I think that should do it, so I'll give it a go. I'm hoping that we can stop using P373 at some point, as the sitelinks should be able to do the job instead now (and are more likely to be correct), but that can be something for the future. Thanks. Mike Peel (talk) 10:55, 2 January 2019 (UTC)[reply]
Re [2], I'm not sure if that's going to go ahead or not (it probably needs some consensus / someone driving it that isn't me), but it might be a useful function to have anyway. There is a major complication of matching country names on Wikidata to those used here, so it would probably need some sort of manually-defined lookup table to match them, as I've done using the switch statements in User:Mike Peel/Occupation (or at least, that was the best solution I could come up with). Thanks. Mike Peel (talk) 10:17, 4 January 2019 (UTC)[reply]
@Mike Peel: It has been an interesting exercise so far. Without any country substitutions, Franz Kafka (Q905) generates a lot of categories:
If you take out the |lp=":" link prefix and preview it, you'll see the page gains 33 categories. Kafka has 3 citizenships and 13 occupations on Wikidata; fortunately the topic's main category (P910) for "poet lawyer" has no English label yet, and "claims adjuster" has no topic's main category (P910) at all. I suppose it's only a matter of time until that gets "fixed". I mean we really fucking needCategory:Claims adjusters. I'll do some country substitutions like "Czech Republic" → "Czechoslovakia" and the ones in your template and leave it at that as a proof-of-concept. The whole thing looks like a can of worms, and even I don't have the stomach for another fight about what-looks-nice-and-what-doesn't™. Cheers --RexxS (talk) 00:13, 5 January 2019 (UTC)[reply]
I agree with 'can of worms'... One possibility might be to just use the categories that exist, which would cut down on the weird ones - or I could use the existing functions to populate "<occupation> by name" categories where they exist. Not sure beyond that TBH. Thanks. Mike Peel (talk) 17:10, 5 January 2019 (UTC)[reply]
I did somethings at wikidata. If a tale was originally published in Norway, and Norway source had a copy and a link on it, I pasted the title (a newer property, i think) from no.source and opted for the dialect which my Norwegian friend spoke. Sorry about that last choice and the reason I made it. Specifically fuzzy.
The title property has changed at wikidata. It no longer allows more than one title, if I remember correctly. And that might be a deltabot toggle.
Also, I am looking at getLang as a way to get past the title lang toggle that I might have. It might be something simple like that I stopped making titles because it left a warning. Where before I discovered deltabot I just left the warnings because I thought they were wrong.
And it wasn't even a warning. I spice it up or sugar it down depending on my mood. It is just stupid tracking software that looks at caution toggles. (unpee here)
It took me a while to figure that out with the infoboxes. I wanted to use the title as the media legend.
in your user css, data retrieved from WD are colored (just to see what is happening). For the purpose of this, we add a property like WD-Item = Q45735532 to our template de:Vorlage:Bauwerk Tabellenzeile, where this is used to do fancy things like
and similar. We use de:Modul:Wikidata for that purpose, but this should be quite similar to the English version. To make this work, we need the QID (e.g. Q45735532 in the example above). We want to retrieve it the easierst way, so if we can double click on a word, copy / paste, it is ok for us. For that reason it would be nice to have the QID in readable form beside the icon.
On the other hand we can manage to do some extra clicks to get the QID. It was the proposal of @Thomas Ledl: to improve mainly his processes and it might be useful to others.
There was a plan that Wikidata will allow to dynamically create such lists, but I don't see the realization at the horizon. I think I could manage to create such lists as a skeleton using sparql. But I don't see a) a way to automatically re-generate these lists when wikidata changes (adding / removing entries matched by the sparql query) and b) a way to merge data from wikidata with localized data (e.g. German descriptions). My ideal solution would be to just add the sparql script only to a page (e.g. retrieve all buildings planned by a given architect), have the result merged with localized descriptions retrieved from somewhere else (some magic missing) in the proper language (description might be long and wiki-syntax rich), rendered as the usual lists on access, but still allowing to change / enter descriptions through the list entries (table rows). I won't get that.
Both your templates Template:Qid and Template:GetQID do not exist on the German WP. I looked at the description of both here on commons, Template:Qid allows to retrieve a QID, either for the calling page, or for a given QID (and access properties thereof), I'm not sure about Template:GetQID. Nevertheless, they operate on well known QIDs or the page QID. This will not help to retrieve the QIDs identifying the object displayed in a single table row of our well-structured lists. I fear we have to copy them manually.
#all buildings by architectSELECT?object?objectLabelWHERE{?objectwdt:P31/wdt:P279*wd:Q41176.?objectwdt:P84wd:Q694854.SERVICEwikibase:label{bd:serviceParamwikibase:language"[AUTO_LANGUAGE],en,fr".}}
Feel free to move this stuff to a better place (I just wrote here for a friend to get a more user friendly possibility to copy the id). ListeriaBot just allows to create a one-time skeleton not in the main namespace. It does not support merging with user content. The main problem is that we have the complete data in WP, not in wikidata. Data in wikidata is not QA'ed. IMHO the ListeriaBot only works if the data is completely available in Wikidata. best --Herzi Pinki (talk) 18:29, 5 February 2019 (UTC)[reply]
Hi Liné1. Thanks for your offer. It's not necessarily a bug, but I'm investigating what is returned on a taxon page when there is no vernacular name. I was hoping it would be an empty string, but it seems to be something that forces {{#if:{{VNNoDisplay|useWikidata={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} }} | value-if-nonblank | value-if-blank }} to always return value-if-nonblank. The discussion is at Template talk:Wikidata Infobox #Error handling: power line/taxon mixture. I think I've almost cracked it now. --RexxS (talk) 17:03, 18 February 2019 (UTC)[reply]
{{#ifeq:{{#invoke:String |sub |{{VNNoDisplay|useWikidata=1}}| 3 | 10 }}|Category|| (code here for when result starts with [[Category) ...
If characters 3 to 10 of the result from VNNodisplay are 'Category' then I know it's effectively an empty result and I can suppress the row in the infobox.
Thank you once more for your kind offer to help, and thank you for all the work you do in maintaining the VN modules and templates! Cheers --RexxS (talk) 22:55, 19 February 2019 (UTC)[reply]
I noticed that you tried out depicts on Test-Commons. Please take a moment to let the developers know what you think, whether it's answering their direct questions, leaving your own feedback, or even noting if you don't have any feedback to give at this time. It would be much appreciated. Thanks. Keegan (WMF) (talk) 19:23, 27 March 2019 (UTC)[reply]
Thanks for the heads-up Keegan. I've done that now. Please feel free to ping me again if there is any more specific testing you'd like me to do. --RexxS (talk) 21:40, 27 March 2019 (UTC)[reply]
It doesn't happen when rank=best, only when rank=normal. So in practice here it's not an issue, but perhaps it should be fixed. Thanks. Mike Peel (talk) 20:18, 29 March 2019 (UTC)[reply]
Hi Mike. It seems that the code that decides whether to fetch qualifiers wasn't respecting the value of rank, so I've fixed that in the sandbox:
I'm sorry, User:Bengt Nyman. I have no idea what you're talking about. The category is a duplicate of an older one and should be merged into it. I've done half the work, so it just needs some housekeeping to tidy up the empty category. The problem came to light as a result of the discussion at d:Wikidata:Project chat #Barry Barish and I don't think anybody there felt they were being patronised. If you've got a problem with any of my edits, please be kind enough to explain in a little more detail. I assume you're familiar with the concept of AGF? --RexxS (talk) 18:45, 19 April 2019 (UTC)[reply]
[[Category:{{#invoke:WikidataIB | getValue | rank=best | P570 | name=death | qid=Q8797| fwd=ALL | osd=no | noicon=yes | df=y | pd=adj | lang=en}} deaths]] doesn't currently work as it includes a link to en:Ante_Christum_Natum - could you investigate and fix please? Thanks. Mike Peel (talk) 17:50, 26 July 2019 (UTC)[reply]
Padding or not padding years earlier than 1000 is always a tough choice. {{ISOdate}} that does it has a parameter "trim_year" that allows you to control that behavior. Padding is needed to make dates like "10 May 19" less ambiguous. Is it "May 19, 2010", "May 10, 2019", "May 10, 19 AD" or "May 19, 10 AD". --Jarekt (talk) 19:45, 27 July 2019 (UTC)[reply]
September 2019: it's Wiki Loves Monuments time again![edit]
Hi
You're receiving this message because you've previously contributed to the annual Wiki Loves Monuments contest in the UK. We'd be delighted if you would do so again this year and help record our local built environment for future generations.
@RexxS: Why should you be able to get to that category from the other? Category:Stone, Staffordshire is not a city. However, in our county structure, all churches are, or will eventually, be sorted per that consensus, against which nobody else objected, least of all the person who kept applying the taxonomically incorrect sorting. Accusations of edit edit-warring against an editor of 11 years standing and Admin of five years here are unconstructive and will only end in one way. I'd remind you this is Commons, where we act to professional standards in a mellow manner and care about what we do. This is not Wikipedia. They can make all the mistakes they want, we don't care. We strive to get things right here. If you want to look at how it should work, see Category:Churches in Cheshire. If you still think that's wrong, (a) tough or (b) try to overturn the consensus, but you will need not just a good, but a great, argument based on long-standing practice in Commons. And support. Rodhullandemu (talk) 18:54, 23 October 2019 (UTC)[reply]
@Rodhullandemu: there's no need to ping me on my own talk page. I already get the notification, thanks.
It was a central argument in that discussion you pointed me to that you could get to any church category from Category:Churches in the United Kingdom by city and I don't believe that to be a valid argument. It seems you agree with me.
In our category structure, all churches are not sorted according to name; they are sorted according to location, and that is the consensus that needs to be respected. I've pointed at a clear example and you are obviously aware of many others.
Please don't attempt to patronise me. I'm also an editor of 11+ years standing, a admin on enwiki and a well-respected Wikimedian across many projects. I don't appreciate being called "unconstructive" when you haven't even bothered to address the issue on the talk page. If you continue to abuse your admin powers here by threatening to use them in a content dispute, it will end the same way as it did for you on enwiki.
I remind you that this a Wikimedia project and you are subject to the same terms and conditions as any other editor on our projects, including the behavioural ones.
Belittling editors on another project is not a good argument to excuse your edit-warring. BRD is just as much the collegial way of editing here as it is on any other project. You make an edit; it gets reverted; you go to the talk page and reason it out. You do not simply re=do the edit which has been challenged. You've been around long enough to know that.
I've looked at Category:Churches in Cheshire. That's one way of doing it, but it's inferior to the way it's done in Category:Anglican churches in Worcestershire. That is the long-standing practice on Commons - to have good number of subcategories that take the searcher quickly to the files they want.
It's appalling that you should address a fellow editor the way you have above. Your dismissive attitude is a stain on the fine collaborative editing environment we have here on Commons, and you should be ashamed of behaving in the way you have. --RexxS (talk) 01:18, 24 October 2019 (UTC)[reply]
Look again at the consensus decision. One editor said "we already have Category:Churches in the United Kingdom by city which makes it possible to find what you are looking for if you only know the city." While true, that is irrelevant to the argument, so even discarding his support still leaves three in favour and (here's the rub) none opposing. It perhaps not the best consensus, but it is a consensus nevertheless and deserves to be respected until changed. I meant to type, of course, Category:Anglican churches in Cheshire for a fair comparison. Which way is superior/inferior should be obvious, but if you ask the simple question "In an alphabetical list, where would you expect to find St Mary's church, Stone?" it becomes blindingly obvious. Nobody in the real world would sort it under "S", so we don't on Commons. I point out again that Commons is not Wikipedia, neither is en:WP some sort of "Master Project" whose customs and consensuses should be followed everywhere else. If it is, try telling that to editors of any other Wikipedia and their answer, I think you will find, will be short and pithy. So please seek to overturn the existing consensus, or comply with it. As for my block on Wikipedia, anyone with a tad of depth of understanding knows that it's indefensible so that's not a card worth playing. Thanks. Rodhullandemu (talk) 08:13, 24 October 2019 (UTC)[reply]
You look again at the arguments presented there. I don't believe any of them stand up to scrutiny, and are certainly not strong enough to justify a complete reversal of what has been the previous current practice, so I'm challenging it now. The argument "we already have Category:Churches in the United Kingdom by city which makes it possible to find what you are looking for if you only know the city." is obviously not only untrue, but misleading - as if all churches were in cities. What nonsense!
As you're now engaging in discussion on the issue, I'll address your question "In an alphabetical list, where would you expect to find St Mary's church, Stone?" - the answer is either under "Stone" or "Mary" and the choice between them would depend on the purpose of the list. Categories work through a tree structure where each category belongs to a parent, and where each member has some distinct, useful relationship to its peers. So I'll ask you "What is the most useful parent category for St Mary's Church, Stone?" - if we follow your concept of organising churches by name, then you would want something like "category:Churches dedicated to St Mary", an almost worthless category because the members would have nothing more than a coincidental relationship. If we organise churches by location, the we would have parents like "category:Churches in Stone" -> "category:Churches in Staffordshire" -> "category:Churches in England", and so on (with the possibility of further sub-categorisation by denomination, of course). Surely you can see that organisation by location produces a grouping of churches near to each other, a sensible and useful relationship. That's what ought to be blindingly obvious to you, and that's why the default sort ought to be "Stone".
Everybody in the real world sorts building by location, not name, no matter how many time you try to claim the opposite.
Despite your fear of the English Wikipedia – which you raised, not me – you are subject to the terms and conditions the the WMF impose on all editors of all projects. I have made no claim or reference to a "master project", and anybody who knows my work with Wikimedia Medicine and with Lua modules already knows my strong commitment to collaboration across all wikis, so I reject your strawman argument as yet another absurdity. The conventions of collegial editing are the same, or similar, no matter what site an editor is on. If you are not capable of editing in a collaborative fashion – and your track record on at least one sister project is not good – then you will sooner or later fall foul of the procedures that are in place to protect the safety of all editors. Please take my warning seriously, for your own good and for the good of Commons. --RexxS (talk) 14:47, 24 October 2019 (UTC)[reply]
The moment you "tl;dr", it's a sign that you've lost the argument, so I see no point in discussing this further with you. Your "consensus" runs contrary to established practice here and is not relevant to the issue. --RexxS (talk) 16:02, 24 October 2019 (UTC)[reply]
Two things that are currently at the top of my wishlist: being able to get the MediaID from the file page in the same way as the sitelink (may already be available via a Lua function?), and being able to go MID -> depicts (P180) -> <list of QIDs> so that I can then loop over each QID to pass it back into WikidataIB to get that item information. Not sure how difficult those would be? Thanks. Mike Peel (talk) 10:34, 25 October 2019 (UTC)[reply]
Google Code-In 2019 is coming - please mentor some documentation tasks![edit]
Hello,
Google Code-In, Google-organized contest in which the Wikimedia Foundation participates, starts in a few weeks. This contest is about taking high school students into the world of opensource. I'm sending you this message because you recently edited a documentation page at Wikimedia Commons.
I would like to ask you to take part in Google Code-In as a mentor. That would mean to prepare at least one task (it can be documentation related, or something else - the other categories are Code, Design, Quality Assurance and Outreach) for the participants, and help the student to complete it. Please sign up at the contest page and send us your Google account address to google-code-in-admins@lists.wikimedia.org, so we can invite you in!
From my own experience, Google Code-In can be fun, you can make several new friends, attract new people to your wiki and make them part of your community.
If you have any questions, please let us know at google-code-in-admins@lists.wikimedia.org.
Hi RexxS. I've been trying to get {{Wikidata Infobox/sandbox}} to call itself to embed information about category combines topics (P971), for example via {{Wikidata Infobox/sandbox|qid=Q83645464}}. It's using p.getCombinedWikidataTemplates in Module:Wikidata Infobox/sandbox. I think it works in principle, however it throws an error "Lua error: expandTemplate: template loop detected." Do you know if there's a way around this, other than copy-pasting the infobox to a second template name? Thanks. Mike Peel (talk) 11:01, 26 January 2020 (UTC)[reply]
@Mike: I've never had much success in trying to get recursion in templates. I think that the designers deliberately stop a template calling itself because it might generate an infinite loop and eat up loads of resources until it's cleaned up. Generally, you should avoid expandTemplate as far as possible, and certainly not call it multiple times inside a tight loop as you're doing there. I don't think that making a duplicate template with a different name will help, because as soon as the second template hits the invoke:Wikidata Infobox/sandbox|getCombinedWikidataTemplates line, it will complain about the loop again.
I suggest you should specifically read the info you want through Lua code, rather than calling a template. Perhaps if you give me more of an idea of what you're looking to do? I can see that you're trying to use something like Category:Iranian architects (Q3290) which has a property category combines topics (P971) to get architect, Iran. Did you mean those to just be categories added to the page? You could simply call {{wdib|ps=1|P971|qid=Q3290}} from the template, or require("Module:WikidataIB") and call p.getValue with a table that mimics the frame arguments from Lua code directly. --RexxS (talk) 00:11, 28 January 2020 (UTC)[reply]
Sorry for the slow follow-up. I ended up copying the template to a second place, at least to demo what I want to do. See Category:Enköping (ship, 1868), where it's sort of working, although I need to do some tidying up. The aim is to display the information about the ship in a 'category combines' category. Can you think of a neater way to do that? Pinging @Esquilo: for info since he was interested in this on Wikidata. Thanks. Mike Peel (talk) 19:04, 8 February 2020 (UTC)[reply]
is there a way to use Module:WikidataIB instead of Module:Wikidata2 to pull P7482/P7384, P275/P2093 or P275/P1476 qualifiers from M87630025? I tried {{#invoke:WikidataIB |getQualifierValue |P275 |pval=Q19068220 |qual=P1476 |name=xyz |fetchwikidata=ALL|qid=M87630025 }} but got "".
Is there a way to avoid errors if qualifier is missing?
If you're writing fresh code, you may find it useful to dump a property from SDC, for example, source of file (P7482) from M87630025 (the order of parameters doesn't matter):
RexxS, Thank you, I was just messing with a wrong function. "GetValue" seems to be exactly what I need. I did discover {{#invoke:Wikidata2|Dump|id=M87630025 }} which seems to be the same. --Jarekt (talk) 01:10, 20 March 2020 (UTC)[reply]
I replaced all the Module:Wikidata2 in {{Geograph from structured data}} and it works much better. I do not understand the magical "ps=1" and without it nothing seems to work, I assume it is "paraset" but it does not seem to be documented. I also like your little "edit at Wikidata" icon, I will try to steel it and use it in my modules to indicate fields populated from wikidata or SDC. I think it would be better than the approach I have in my {{Information/sandbox}} at the moment. I could not get it to show up, but with SDC it would not work properly any way due to phabricator:T241338. Thanks again. --Jarekt (talk) 03:49, 20 March 2020 (UTC)[reply]
@Jarekt: you're right that |ps= is just a convenient parameter set, and works as a shortcut for setting the values of several common parameters. I've now updated the documentation at Module:WikidataIB/doc, which hopefully will be more useful for you. A lot of the functionality has examples/test cases at Module talk:WikidataIB/testing that some folk also find helpful. --RexxS (talk) 16:50, 21 March 2020 (UTC)[reply]
Another possible improvement would be to show the prominent statement(s) first (bold or something else to make it stand out) and after that the "normal" statements (or just make these small if a prominent is present?). Multichill (talk) 13:07, 28 March 2020 (UTC)[reply]
@Multichill and Jarekt: I'm looking at what adaptations Module:WikidataIB needs to fully handle SDC. The property depicts (P180) is much the same as any other property as far as I can tell. It's worth just trying the functions (most useful are getValue and getPropOfProp) using qid=Mnnn instead of the usual qid=Qnnn and report any issues. I think most of the code is compatible, but I just can't guarantee it at present. I'll let you know when I make progress, but please carry on testing and keeping me informed. Thanks for all your efforts. --RexxS (talk) 16:35, 28 March 2020 (UTC)[reply]
RexxS, I am adapting my lua codes fetching wikidata to fetch SDC as well. In the past I had issues with some Lua functions but they seem to be converging. Raw entity structure is sometimes an issue, for example I had to do those changes to get Module:Wikidata_date to work with SDC. Phabricator:T238484 caused me a lot of issues but apparently it is happening at Wikidata and SDC, so I adapted. I am starting to use "edit at Wikidata" icon with some of my codes, see Module_talk:Wikidata_art/sandbox/testcases for example, and created Data:I18n/EditAt.tab to be used with Module:TNT to internationalize the message. If you want to do the same see how to use it here. Also your "edit at Wikidata" icon might be wrong if you pull stuff from SDC. --Jarekt (talk) 17:00, 28 March 2020 (UTC)[reply]
That's good work, Jarekt, and I'm glad you've warned me about "edit at Wikidata". I can test whether qid starts with "Q" or "M" to distinguish, but I'll probably just wait a bit because the code that generates the icon will also generate the hook for Wikidata Bridge, and I want to see how that is going to work with SDC before I make big changes. Cheers --RexxS (talk) 18:33, 28 March 2020 (UTC)[reply]
How to look up raw value (item ID) of a property?[edit]
Rex, Is there a way to get value of SDC's location of creation (P1071) returned as a item ID? I am reading and rereading documentation of various modules but can not find it. I can easily write it, but there has to be a way to look it up. --Jarekt (talk) 01:26, 27 April 2020 (UTC)[reply]
@Jarekt: I have a function in WikidataIB that might do the job. This is how it works for for a Wikidata item:
The call actually can do rather more, but you just need the simplest case. This is the documentation:
-- followQid takes three optional parameters: qid, props, and all.
-- If qid is not given, it uses the qid for the connected page
-- or returns nil if there isn't one.
-- props is a list of properties, separated by punctuation.
-- If props is given, the Wikidata item for the qid is examined for each property in turn.
-- If that property contains a value that is another Wikibase-item, that item's qid is returned,
-- and the search terminates, unless |all=y when all of the qids are returned, sparated by spaces.
-- If props is not given, the qid is returned.
I haven't tried it on SDC and you didn't give me a n example to test it on. Please let me know whether it works or not with SDC if you try it. Cheers --RexxS (talk) 01:51, 27 April 2020 (UTC)[reply]
Module to convert tabular data to wiki table[edit]
Hi. I am a member of the ensemble that made the performance, as you can see here; I made the live recording and as the copyright holder I have released it to Commons under a CC license. --Guido Magnano (talk) 01:08, 18 May 2020 (UTC)[reply]
As you seem to be very knowledgeable, please have a look at Category:Kyōko Fukada. Although she is in an actresses cat, she also appears in that same Category:Actors annnnnnd also Category:Film actors. I do not know if that is due to some novelty from the WD guys. I work here (and there) with two fingers and know nothing about bugs, templates etc. --E4024 (talk) 17:25, 14 January 2021 (UTC)[reply]
@E4024: The categories 1982 births, Fukada (surname), Kyoko (given name), Actors, Film actors, and Vocalists have been added automatically because the infobox found those on her entry at Wikidata, Kyoko Fukada (Q253882). According to Wikidata, she started work as an actor in 1997 and as a film actor in 1999, which seems to me to indicate that the two occupations are somehow distinct. If you think those dates/occupations are wrong, you could amend the entries on Wikidata, especially if you have a source for the information. --RexxS (talk) 17:42, 14 January 2021 (UTC)[reply]
...it's not working. I would like for this panoramic shot to sit at the top of my user talk page (right under the push to post bar and above the Awareness notice), but when I try to size it for the page, it's either microscopic or HUUUUGE. Easiest way to make it work is to....???? AtsmeTalk📧20:24, 15 February 2021 (UTC)[reply]
I assume you're talking about your En-wiki talk page at en:User talk:Atsme. I've made a demo of what might be possible, but it's difficult with a panoramic image if it gets resized. For now, I've clipped the right-hand side on windows smaller than HD. --RexxS (talk) 22:23, 15 February 2021 (UTC)[reply]
I couldn't find this posting in your history and wondered if you can share any tips or observations about this matter. My immediate issue is that on some devices and thumbnail sizes, the minus sign before 1/3 on the fifth line in this image vanishes.
Hello RexxS, I've removed your template editor rights as you were inactive for more than a year (policy). If you wish to return and have a need for the tools, don't hesitate to ping me and I'll grant the right again. Thanks. --Minorax«¦talk¦»08:11, 14 August 2022 (UTC)[reply]
Done. --RexxS (talk) 16:08, 19 April 2011 (UTC)
). So:
Atsme Talk 📧 20:24, 15 February 2021 (UTC)
.jpg){kind=link}
