Module talk:Wikidata table

Looking good
This template seems to be working well and the performance statistics look like they will be suitable for use in long list articles. And I like the approach of using a wrapper template (e.g. Template:Wdtable row/lighthouse) &mdash; Martin (MSGJ · talk) 13:14, 11 February 2021 (UTC)
 * Deployed on List of lighthouses in England and looking very good. Currently up to 3.8s of Lua time and I'm well over halfway through converting so 10 seconds will not be approached. &mdash; Martin (MSGJ · talk) 21:53, 16 February 2021 (UTC)

Wish list
I hope you don't mind but I thought I would start making a wish list for features &mdash; Martin (MSGJ · talk) 13:14, 11 February 2021 (UTC)
 * I'm grateful that you have. Much of the time I'm writing code, I have to guess what functionality and behaviour editors want, and having good feedback from someone actively using modules that I create is incedibly helpful.
 * I must admit I only created the original function (makerows) to see how fast it could run, not as a basis for a replacement, so it was optimised for speed with little thought of how I could !bolt-on! extra functionality. But I accept that the row-based function looks too useful not to develop further, so I'm content to do so. What I need is guidance on how you would want any extra functionality to be accessed. For example, I could split the parameter  into   (for column replace 1) and   (for column append 1), where the first would replace the Wikidata value and the second would append to it. Do you have any any thoughts on that sort of scheme, or did you have something else in mind?
 * References can be done, but I can't match the existing 'citation style', only supply what is available on Wikidata (often a bare url). That may be a limiting factor for deployment.
 * I have all the code to display qualifiers in WikidataIB, so it can be adapted quite quickly. Is the convention  adequate to request property P123 and its qualifiers P580 and P582? Do you want the qualifiers to display their labels like start date:? or is there a short list of common qualifiers where you want a custom label? It's faster to use a lookup table than to read the label.
 * The Editonwikidata is easy to add, as I have a function in WikidataIB that I can adapt.
 * I think the code should already display only the best value. Somebody has to mark one of the coordinates as 'preferred' on Wikidata, though. Please let me know if that doesn't work.
 * Falling back to alternative property is not difficult, but how do you want to do it? Do you want to write something like  or is there a short list of common fallbacks that would be applied automatically?
 * I'll make a start on some of those when I get a chance. --RexxS (talk) 15:44, 11 February 2021 (UTC)
 * [Update:] several items from the wish list are done, but more input would be welcome. I'm testing display of coordinates in DMS format rather than decimal; any preferences? --RexxS (talk) 21:28, 11 February 2021 (UTC)
 * Thanks. More input will certainly be on the way shortly, but I've had a busy couple of days! &mdash; Martin (MSGJ · talk) 16:18, 12 February 2021 (UTC)
 * Qualifiers implemented, I think. Probably needs more testing, but it works with the lighthouses anyway. It doesn't make the rendering any slower (less than 2 sec for 95 rows). I've re-jigged the separators for the pids so that all whitespace is ignored, a  separates each cell contents, a   separates multiple properties in the same cell, a   separates the qualifiers from each property they belong to, and   separates multiple qualifiers (although anything will do for the last one, except you just can't re-use   obviously). If you want to change those, let me know while we're still in the drafting stage. --RexxS (talk) 01:10, 13 February 2021 (UTC)
 * Thanks. More input will certainly be on the way shortly, but I've had a busy couple of days! &mdash; Martin (MSGJ · talk) 16:18, 12 February 2021 (UTC)
 * Qualifiers implemented, I think. Probably needs more testing, but it works with the lighthouses anyway. It doesn't make the rendering any slower (less than 2 sec for 95 rows). I've re-jigged the separators for the pids so that all whitespace is ignored, a  separates each cell contents, a   separates multiple properties in the same cell, a   separates the qualifiers from each property they belong to, and   separates multiple qualifiers (although anything will do for the last one, except you just can't re-use   obviously). If you want to change those, let me know while we're still in the drafting stage. --RexxS (talk) 01:10, 13 February 2021 (UTC)

This is all looking very good indeed. I was using unnumbered parameters like on list item and I was thinking about using  to add to column 1. If you prefer named parameters like then how about  to add to column 1? I can't find any errors yet, but I will continue testing. Great work! &mdash; Martin (MSGJ · talk) 22:11, 13 February 2021 (UTC)
 * I much prefer using named parameters in an invoke as I'm assured that the incoming parameter will have whitespace trimmed from it, and that there's never any confusion about which parameter is which when editing the module. Of course, if you use a wrapper template, you're free to use positional (unnamed) parameters by simply setting  in the wrapper definition.
 * I'm currently using cr1, etc. for cell/column replacement and ca1, etc. for cell/column addition because its trivial to extract the number from those by matching "ca%d+" and "cr%d+", but with a little more effort I can match "^c%d+$" and "^c%d+%+$" to use your naming scheme. You can see the ca4 and ca5 adding "FN1" and "FN2" to the Anvil Point Lighthouse row in Module talk:Wikidata table. I'll switch to your scheme tomorrow. Cheers --RexxS (talk) 23:42, 13 February 2021 (UTC)

Moved to main module space
I've moved the sandbox module page Module:Sandbox/RexxS/Wikidata table to main module space at Module:Wikidata table. If it is likely to be used in articles, it's better not to use sandbox code. --RexxS (talk) 17:49, 11 February 2021 (UTC)

Testing/Examples are currently at Module talk:Wikidata table. --RexxS (talk) 17:57, 11 February 2021 (UTC)
 * Lighthouse tests moved to Template talk:Wdtable row/lighthouse &mdash; Martin (MSGJ · talk) 13:06, 14 February 2021 (UTC)

Editonwikidata

 * Having a link on the name works perfectly from my point of view. Would it worth adding functionality which would allow these links on other columns too? (I personally think that would be excessive but other editors might disagree.) I've thought of something. What if the name is not the first column - I've seen that on for example List of airports in North Dakota - how would that be specified? &mdash; Martin (MSGJ · talk) 22:18, 13 February 2021 (UTC)
 * The List of airports in North Dakota doesn't conform with MOS:ACCESS (specifically MOS:DTAB) because it has no row headers, nor any scopes. It manages to get by with that layout because in that list, there is only one airport per city, i.e. they have a one-to-one correspondence. Elsewhere, that may not be the case and a city may be served by multiple airports, i.e. a one-to-many correspondence. In those cases, the row is uniquely identified by the airport, not the city and it shows that the row header should be the airport name. The airport would be have to be the Wikidata entity (hence the qid) for that row because none of the other columns in the table contain properties of the city, rather they are properties of the airport.
 * In any case, I coded the first column to be the label associated with the qid, not any of the properties, and made it the row-header with proper scope, so that it conforms to MOS:DTAB. I'm not really interested in enabling non-accessible tables on Wikipedia, so I will respectfully decline to allow other columns to be used as the row-header.
 * The Editonwikidata icon could easily be added to any or every column, but I see no good reason for it, and I'd rather not go down that road until there is a demand for it. --RexxS (talk) 00:38, 14 February 2021 (UTC)
 * Okay I understand your point about row headers. No, let's leave things as they are for now. &mdash; Martin (MSGJ · talk) 12:34, 14 February 2021 (UTC)
 * Okay I understand your point about row headers. No, let's leave things as they are for now. &mdash; Martin (MSGJ · talk) 12:34, 14 February 2021 (UTC)

Fallback properties

 * I know I added this to the wish list, but are we sure this is a good idea, or might it lead to confusion? I'll explain why I did this on Template:List item/location. Some editor on Wikidata was going round deleting when it was the same as . Although I couldn't fault the logic of avoiding redundancy, this left some gaps in my tables, and that was how I fixed it. &mdash; Martin (MSGJ · talk) 22:24, 13 February 2021 (UTC)
 * What syntax did you decide to use for this, so then I can go and test it? &mdash; Martin (MSGJ · talk) 22:25, 13 February 2021 (UTC)
 * Another fallback I was using was for  because sometimes they are used interchangeably. &mdash; Martin (MSGJ · talk) 22:26, 13 February 2021 (UTC)
 * I went for automatic fallbacks for a first test. The fallbacks are stored in a simple Lua table around line 49 in Module:Wikidata table. I set it up to try falling back from to . That already filled in some of the gaps in the Module talk:Wikidata table, but you might not have noticed. I've just added a fallback from 'inception' to 'date of official opening' in this diff as a demonstration. Perhaps you might find a chance to test it out? --RexxS (talk) 00:20, 14 February 2021 (UTC)
 * I think being able to specify fallback properties in the wrapper template would be very useful, as some fallbacks would make sense in certain contexts only. The bracket notation would work well, e.g. P729(P571,P1619) where it would look in the other properties in turn until it found some data? &mdash; Martin (MSGJ · talk) 08:45, 24 February 2021 (UTC)

Qualifiers

 * I think the current arrangement is working well. I like the way the words "until" and "from" are inserted for dates. In some cases the output does not need linking, e.g. white, but not sure the best way of specifying that. Module:Wikidata displays the qualifiers in a smaller font, which I think looks quite nice. Is that possible, or is that some kind accessibility issue? &mdash; Martin (MSGJ · talk) 13:12, 14 February 2021 (UTC)
 * I'm loathe to make text smaller without good reason because folks have an annoying habit of setting entire tables at 95% or 90% font-size (and 90% of 90% is 81%, which is below the "bright-line" 85% minimum from MOS:TEXTSIZE). They usually do that because they can cram more rows in on the screen they are editing on. I'll set the qualifiers at 90% as a test so you can see how it looks (at least they could set 95% for the entire table without breaking the 85% minimum), I could simply set all qualifiers to be unlinked, but I'm not sure I can come with a sensible algorithm to only unlink some of them. Let's try it and see. --RexxS (talk) 18:44, 14 February 2021 (UTC)
 * I've rendered the qualifiers as plain text for now, and cleaned up a lot of the logic. The font size for qualifiers is set in line 186, so feel free to play with that setting. --RexxS (talk) 21:14, 14 February 2021 (UTC)
 * I think the current size works well. What do you think about using small text for coordinates too (like is used at List of crossings of the River Thames? &mdash; Martin (MSGJ · talk) 11:34, 17 February 2021 (UTC)
 * I've rendered the qualifiers as plain text for now, and cleaned up a lot of the logic. The font size for qualifiers is set in line 186, so feel free to play with that setting. --RexxS (talk) 21:14, 14 February 2021 (UTC)
 * I think the current size works well. What do you think about using small text for coordinates too (like is used at List of crossings of the River Thames? &mdash; Martin (MSGJ · talk) 11:34, 17 February 2021 (UTC)

Could coordinates be linked please - even when they are qualifiers? &mdash; Martin (MSGJ · talk) 21:03, 17 February 2021 (UTC)
 * Bearing in mind that the code that renders properties is separate from the code that renders qualifiers, there are two issues:
 * Linking qualifiers can be done simply but then you get (white). Presumably you want to check just for coordinates when processing qualifiers and link those. I've done that.
 * I don't like small text, but I've made coordinates smaller (90%) when they are properties. The font size is set in line 247.
 * Let me know if you want those tweaked. --RexxS (talk) 23:00, 17 February 2021 (UTC)
 * That's great, thank you. Ideally I would like to be able to select which properties and qualifiers get linked and which do not. (It could be a problem when certain values are repeated a lot on articles. For example there is some overlinking on List of crossings of the River Thames now.) But for now, I think linking coordinates and not other qualifiers is working well. &mdash; Martin (MSGJ · talk) 13:24, 18 February 2021 (UTC)
 * Overlinking of items in tables is one of the exceptions to MOS:OVERLINK because tables may be sorted, and hence it's impossible to predict which is the first occurrence of an item to link. Extra links cost nothing and can be a big benefit to the reader, especially in large tables. I can arrange for certain properties not to be linked, but it would need a lookup table as usual to enumerate them. See Module:WikidataIB/nolinks where I moved a list of specific items (rather than properties) that should not be linked out of the main module to ease internationalisation. --RexxS (talk) 17:26, 18 February 2021 (UTC)

Locally defined column
It's possible to set up a column which has all of its values supplied locally by using a dummy property like P1 which never has any values. For example: None of the properties P1 to P5 are in use. --RexxS (talk) 22:09, 14 February 2021 (UTC)
 * Yep, P1 works well &mdash; Martin (MSGJ · talk) 22:25, 16 February 2021 (UTC)

Can we allow the overrides to work if no PID is specified? (I know there is no point using this module in that case, but it would allow consistent syntax for each row of the table, even when wikidata items are not present.) Thank you &mdash; Martin (MSGJ · talk) 12:45, 18 February 2021 (UTC)
 * Example, I just had to do this to display some rows that didn't have wikidata items. Usually I would just create the items, but in these cases I couldn't because I had no information on them at all. &mdash; Martin (MSGJ · talk) 13:38, 18 February 2021 (UTC)
 * I can do it, but it will need a value for qid to indicate no wikidata. For now, I've simply used an invalid qid (e.g. blank) to trigger that. I've reverted your last edit to List of castles in Ireland and it looks okay. If you have any other bits of data (in c2, c3, etc.), they should still display properly. Perhaps you can check further? --RexxS (talk) 17:08, 18 February 2021 (UTC)

Comma separator
Please can a comma be used as a separator when multiple values for a property of qualifier are fetched? This might be better than adding a line break &mdash; Martin (MSGJ · talk) 22:22, 16 February 2021 (UTC)


 * Sure. I've made it into a variable that you can set in line 10. Please feel free to play with it to see what's best. Let me know if you want different separators for properties and qualifiers. --RexxS (talk) 00:02, 17 February 2021 (UTC)
 * Thanks. Any easy way to get an uppercase "R" and a lowercase "s"? I note that when there is a site link, it will be capitalised. When there is no site link then the label is used which is usually not capitalised. &mdash; Martin (MSGJ · talk) 11:28, 17 February 2021 (UTC)
 * I've put it back to  when it is using values from different properties &mdash; Martin (MSGJ · talk) 11:42, 17 February 2021 (UTC)
 * I've put it back to  when it is using values from different properties &mdash; Martin (MSGJ · talk) 11:42, 17 February 2021 (UTC)

Capitalisation

 * Any easy way to get an uppercase "R" and a lowercase "s"? I note that when there is a site link, it will be capitalised. When there is no site link then the label is used which is usually not capitalised. &mdash; Martin (MSGJ · talk) 11:28, 17 February 2021 (UTC)
 * Capitalisation is always a problem. Site links will be in sentence case because of Wikipedia's policy on article titles, while labels are prose case because of Wikidata's policy.
 * I should have matched the initial capitalisation for each sitelink to the initial capitalisation of the label (so that proper nouns keep their initial capital). I've done that now.
 * It's possible to capitalise the first character of each table cell, or to capitalise the first character of each different property value in the table cell. I've tried the latter for now, but it's easy enough to change. It will go wrong if we have values like "iPhone", "eBay", etc. --RexxS (talk) 15:05, 17 February 2021 (UTC)
 * I can't help thinking it would be easier just to use the label itself! &mdash; Martin (MSGJ · talk) 18:53, 17 February 2021 (UTC)
 * Unfortunately, Enwiki articles are very often titled differently from the label on Wikidata. If the label were "Newport", making a link to Newport would not be very helpful to the reader. --RexxS (talk) 20:21, 17 February 2021 (UTC)
 * Yes I know that. I meant piping to the label. &mdash; Martin (MSGJ · talk) 20:50, 17 February 2021 (UTC)
 * Right. But if the article title had other capital letters not present in the Wikidata label, we'd get a redlink. I've had that happen in the past. Also, linking to the sitelink goes a long way to catching vandalism because it's easy to vandalise a Wikidata label, but near impossible to vandalise the sitelink. That makes it simple to spot what the label should be when fixing it.--RexxS (talk) 23:12, 17 February 2021 (UTC)
 * I think we must be talking cross-purposes here. I got used to how Module:Wd handles these which is linking to the site link but piping to the label. This works perfectly in every case, in my opinion. I haven't actually experienced label vandalism (I'll take your word it happens) but in my opinion it's just as bad but no worse than vandalism on any number of fields that can be changed on wikidata (e.g. date of birth) and we don't have any extra measures to protect against that. &mdash; Martin (MSGJ · talk) 13:45, 18 February 2021 (UTC)
 * I agree we are talking at cross purposes. Linking to the sitelink and displaying the label is exactly how it's done here when both exist, and I've done that since the first version of Module:Wikidata from 2013. However, I have been moaned at for using piped links when the display was the same as the link; see Template talk:Cite Q/Archive 3 for the sort of criticism I get.
 * Module:WikidataIB takes the sitelink and cleans off any namespace and disambiguation to produce the display for the pipe, so avoids using the label, but that's slower, although it's much more vandal proof.
 * I don't understand how you think  →   "works perfectly" when the first item isn't capitalised as you asked for. — Preceding unsigned comment added by RexxS (talk • contribs)
 * Yes I see this module is following that principle (piping to "Wooden bridge" rather than "Timber bridge" below), so I don't know fully understand what the difference is now, it just seems a lot more convoluted somehow! &mdash; Martin (MSGJ · talk) 09:10, 19 February 2021 (UTC)
 * The code is all in the  function on lines 180-202. If anyone can suggest a simpler algorithm that does the same job, I'm all ears. --RexxS (talk) 23:42, 19 February 2021 (UTC)

Why is "Wooden" capitalised below but "railway" is not? &mdash; Martin (MSGJ · talk) 13:48, 18 February 2021 (UTC)
 * It's because I dealt with piped links and unlinked values, but forgot about unpiped links in the ucf function. Should be fixed now. --RexxS (talk) 18:52, 18 February 2021 (UTC)

Please could the "s" in "second" be capitalised? (I know the label is lowercase!) &mdash; Martin (MSGJ · talk) 09:53, 19 February 2021 (UTC)
 * That one was easy - I forgot to capitalise the row header (which is processed separately). --RexxS (talk) 23:42, 19 February 2021 (UTC)
 * That one was easy - I forgot to capitalise the row header (which is processed separately). --RexxS (talk) 23:42, 19 February 2021 (UTC)

External identifiers
Could identifiers with be automatically be linked in the table? &mdash; Martin (MSGJ · talk) 18:36, 17 February 2021 (UTC)
 * For example the NGA number below could be linked to 112-30608 &mdash; Martin (MSGJ · talk) 18:38, 17 February 2021 (UTC)

Let's :

I can't extract the fact that a formatter url is available from that. We will need to construct a list of external-ids that we are interested in. We could retrieve the for the external identifier, e.g.

That sends the following to a tool-forge handler to create an external url:

msi.nga.mil/queryResults?publications/ngalol/lights-buoys?volume=%1&featureNumber=%2&includeRemovals=false&output=html -- exp=(\d{3})-(.*)&id=$1

Unfortunately the encoding of the formatter-url above isn't directly compatible with Scribunto's URI library (it's set up to be processed by php).

My preference would be to hard-code each formatter url into the list to avoid making the same extra Wikidata lookup many times more. Do you have any thoughts on how might we go about constructing such a list for all of the external identifiers? --RexxS (talk) 21:26, 17 February 2021 (UTC)
 * At Template:List item/NGA number I was using Formatter link but I am imagine this is quite resource-heavy and so to be avoided? &mdash; Martin (MSGJ · talk) 22:17, 17 February 2021 (UTC)
 * Yes, I seem to think I wrote Formatter link, so I was intending to replicate its functionality directly without having to call the toolforge link. But following that link isn't part of the page rendering, so it won't be much of a burden. I've implemented the functionality and added to the table at line 63. Please feel free to add other formatter urls that you want to be linked. --RexxS (talk) 00:10, 18 February 2021 (UTC)
 * Ah, so you did! I am bit worried about hard-coding these formatter URLs in the module, because they do change from time to time. The property on wikidata would probably be updated quite quickly, but unless you or I happened to be around, no one would know to update the module. Anyway, working well for now ... &mdash; Martin (MSGJ · talk) 13:30, 18 February 2021 (UTC)
 * Wikipedia has 6,252,110 articles and 148,305 active users. That represents 42 articles per user. Wikidata has 92,632,749 articles and 26,719 active users. That represents 3,466 articles per user. My experience is that when something changes, it gets noticed a hundred times quicker on Wikipedia. My recommendation is to leave an html hidden comment in the article or template next to the line that defines  with a link to the Wikidata item that defines the formatter url, like this: https://www.wikidata.org/wiki/Property:P3563#P1630 for the . It is a real performance loss to read the same fixed Wikidata value on every line of a table when that value changes rarely. --RexxS (talk) 17:49, 18 February 2021 (UTC)

Link error
The link to State Road 108 (Serbia) has not resolved properly &mdash; Martin (MSGJ · talk) 09:06, 19 February 2021 (UTC)
 * I would appreciate if you could fix this error, thanks! &mdash; Martin (MSGJ · talk) 21:39, 19 February 2021 (UTC)
 * Multiple piped values for a property weren't being handled properly because there was more than one pipe character. I've improved the logic in the ucf function. --RexxS (talk) 23:11, 19 February 2021 (UTC)
 * Multiple piped values for a property weren't being handled properly because there was more than one pipe character. I've improved the logic in the ucf function. --RexxS (talk) 23:11, 19 February 2021 (UTC)

Coordinates
We are now using two different icons for coordinates, dependent on whether they are main property or qualifier. I think I prefer the second one. The globe is not really identifiable at that size anyway. &mdash; Martin (MSGJ · talk) 09:21, 19 February 2021 (UTC)
 * Okay, the property was being rendered by passing through coord to obtain the full functionality (decimal or dms, etc,), but if you're happy with the default output from the built-in mw.wikibase.formatValue function, that will improve performance. --RexxS (talk) 00:19, 20 February 2021 (UTC)
 * After I asked for qualifiers to be on the same line, I find myself wishing that in some cases (like the one above) the qualifier go on a new line and unbracketed. I don't know how to formulate what looks best in each case. Perhaps if I use the "+" notation instead of the "/" notation it would know to use a new line and no brackets? But then it would be looking for a main property rather than qualifier. &mdash; Martin (MSGJ · talk) 17:51, 20 February 2021 (UTC)
 * You can't use  as the code looks for them and splits the list of pids at those points. Fortuitously, the quals separator can be anything else (well, not P, | or a digit), and I just suggested   as a counterpart to  .  So you can pick two unused symbols, then I'll code one for the "space and brackets" separator and the other for the "new line and no brackets" separator. Take your pick: (  and lots more). --RexxS (talk) 20:08, 20 February 2021 (UTC)
 * did you get a chance to think about what you want for these cases? --RexxS (talk) 01:12, 23 February 2021 (UTC)
 * Not really but I will give it some thought! Are these punctuation marks really the best syntax for this? &mdash; Martin (MSGJ · talk) 08:37, 24 February 2021 (UTC)
 * Not really but I will give it some thought! Are these punctuation marks really the best syntax for this? &mdash; Martin (MSGJ · talk) 08:37, 24 February 2021 (UTC)

Dates
I notice that all dates are currently being rounded to the year, so the following shows 2008 instead of the exact date 30 September 2008. I found the setting to change the date format in the module, but when I changed it to dmy all the dates with only years specified were then displayed as 1 Jan. It would be good to display them to the accuracy that is available (but I don't know how to tackle the mdy vs dmy problem.) &mdash; Martin (MSGJ · talk) 09:26, 19 February 2021 (UTC)
 * I've amended the code to read the date precision (if set) on Wikidata, which will switch between (year only), (month and year), or (day month year).
 * The module accepts an optional parameter mdy that will set (month day, year) format. It defaults to dmy.


 * I'm using three-character abbreviations for month names as space can be tight in a table. If you would prefer full month names, amend line 246 to read:
 * --RexxS (talk) 01:01, 20 February 2021 (UTC)
 * Thanks. Abbreviations are good &mdash; Martin (MSGJ · talk) 17:46, 20 February 2021 (UTC)
 * Thanks. Abbreviations are good &mdash; Martin (MSGJ · talk) 17:46, 20 February 2021 (UTC)

Could the date (December 1832) below be abbreviated? Also I think the default accuracy of month+year would be sufficient for qualifiers. Thanks &mdash; Martin (MSGJ · talk) 16:24, 22 February 2021 (UTC)

And one more request. The date below is recorded as 2nd century on Wikidata, but displayed here as 200 (which is the first year in the 3rd century). Could the precision be shown appropriately? &mdash; Martin (MSGJ · talk) 16:27, 22 February 2021 (UTC)


 * Bleh. Wikidata renders it as "2. century" by default. Who uses that? I've rewritten the date handling completely. The parameter df now only differentiates between dmy and mdy formats, as it's global for the row and you don't want to fix "year" or "month year" across the entire row. The date format depends on the precision stored on Wikidata, except for qualifiers which no longer display day. --RexxS (talk) 00:48, 23 February 2021 (UTC)
 * Thanks &mdash; Martin (MSGJ · talk) 08:39, 24 February 2021 (UTC)
 * Thanks &mdash; Martin (MSGJ · talk) 08:39, 24 February 2021 (UTC)

Template:List item
I have now orphaned Template:List item by converting all articles to use this module instead. I'm a bit sad to see it go because I liked that template. Pity the performance wasn't good enough. &mdash; Martin (MSGJ · talk) 17:54, 20 February 2021 (UTC)

makerows
I am just wondering if all this added functionality would be available to the makerows function too? There are quite a lot of articles which don't have any row customisation (e.g. List of lighthouses in Madagascar which I did yesterday) which might be able to use that function more efficiently. &mdash; Martin (MSGJ · talk) 08:39, 24 February 2021 (UTC)
 * Unfortunately, I'm going to be distracted by an ArCom case for the foreseeable future. I'll get back to these issues if and when I'm able to. --RexxS (talk) 19:26, 24 February 2021 (UTC)
 * Sorry about that &mdash; Martin (MSGJ · talk) 21:10, 24 February 2021 (UTC)
 * Sorry about that &mdash; Martin (MSGJ · talk) 21:10, 24 February 2021 (UTC)

New script errors
New script errors have appeared at multiple template pages, including Template:Wdtable row/lighthouse9. They may be related to recent changes to this module. – Jonesey95 (talk) 13:53, 3 May 2022 (UTC)
 * Also see multiple sections above, on this talk page. Pinging . – Jonesey95 (talk) 13:54, 3 May 2022 (UTC)
 * Apologies and that is now fixed &mdash; Martin (MSGJ · talk) 13:56, 3 May 2022 (UTC)
 * Thanks, and no worries. Bugs happen. – Jonesey95 (talk) 14:41, 3 May 2022 (UTC)

List of crossings of the River Thames
List of crossings of the River Thames seems to be the only article currently using this template directly, and it's adding a comma to the end of the URL in some reference, breaking the reference link and showing as a  in the reference section. There have been no recent changes to the code. Could someone please take a look? Thanks. Storchy (talk) 09:14, 25 September 2022 (UTC)
 * This is my fault, sorry. * Pppery * it has begun... 16:02, 25 September 2022 (UTC)
 * Thanks for the quick turnaround! Storchy (talk) 16:05, 25 September 2022 (UTC)

This is a very problematic module
I just happened upon this module being used in some standalone lists. While this may have some niche uses, I think it is very problematic for general use in lists. It makes editing lists by someone without an intense knowledge of Wikidata next to impossible. Some policy ought to be added to discourage its use for accessibility sake. IronGargoyle (talk) 01:47, 20 August 2023 (UTC)


 * Thanks for your comments. This template/module was designed to try and make it easier for editors to include data tables, so if you have any suggestions on how it can be improved then please let me know, particularly if it relates to accessibility. You may be significantly overestimating the difficulty of using Wikidata while underestimating how hard it can be for newcomers to produce tables using wikicode. &mdash; Martin (MSGJ · talk) 14:41, 4 October 2023 (UTC)
 * Note for the record: Village pump (proposals)/Archive 197. This is a perpetual frozen conflict. * Pppery * it has begun... 23:16, 4 October 2023 (UTC)