Talk:Andy Legg

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Andy Legg. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20120309041008/http://www.glanafan.baglanit.org.uk/Spring-09-News.html to http://www.glanafan.baglanit.org.uk/Spring-09-News.html
• Corrected formatting/usage for http://www.swanseacity.net/page/PastPlayers/0%2C%2C10354~1251445%2C00.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 19:08, 5 July 2017 (UTC)

I Inserted an Empty Row

This describes one of the changes I made to the table showing Andy's Career Statistics.

I inserted an empty row between the last two rows, the final subtotal and the overall total.

Without this change, the table was not rendered correctly in my browsers and with my Wikipedia layout configuration.. See the subsequent section for a description of the other changes I made to the same table at the same time.

The Problem Without this Change

The penultimate row is the Llanelli Subtotal and represents row 7 of that subsection. Without this change, that row starts in Column 1 instead of Column 2. As a result, every number in that row appeared under the wrong header label and there was a conspicuous unshaded cell at the end of the row.

Attempted Workarounds

This WAS NOT fixed by several attempted workarounds described below ... EXCEPT, that is, for the last one.

The final subsection of the table contains Andy's six seasons with Llanelli AFTER his stint at Hucknall Town. There is also a Subtotal row associated with those six seasons, so the final subsection of the table SHOULD HAVE a rowspan of 7

(a) I tried decreasing the rowspan from 7 (correct) to 6 (not enough). It didn't help.

(b) I tried increasing the rowspan to 8 with no additional row inserted (too much), It didn't help.

(c) I tried a rowspan of 8 to include an additional artificial penultimate row just labelled TEST.

Surprisingly, attempt (c) worked and the table was rendered correctly. It was also rendered correctly if I restored the correct rowspan of 7, and retained the artificial TEST row. I then tried several ways of removing the surplus row, mostly without success.

I will use terminology that is associated with wiktable source editing. If you are only familiar with the visual editor, please note that in my descriptions below,

| pipe character box lines are used for normal rows in the table

! bang character box lines are used to highlight special rows such as the Subtotals

I considered it an immutable requirement that the last row (the overall totals) be highlighted using ! bang character box lines. With that requirement firmly and unwaveringly in place, I discovered that the following condition determined whether the table was rendered correctly:

It rendered OK ONLY IF the penultimate row used the normal | (pipe-character) box lines

BUT NOT OK IF the penultimate row was rendered using ! (bang-character) box lines.

As there were several other places in the table that correctly rendered a Subtotal row with ! bang box lines, I concluded that there is a problem with rendering two consecutive highlighted rows with ! box lines. After trying several workarounds for this, I settled on the INSERTED-EMPTY-ROW as the least intrusive (both visually and in the editable table source).

On a couple of occasions in the past, I have added different workarounds to different tables in different articles to fix similar rendering issues. Some of these were reverted with the comment that there wasn't a problem in the first place. I concluded that this wikitable issue is dependent upon the layout configuration.

It could theoretically also depend upon a less common app or browser version and platform etc. But I have excluded those as a cause because I see this issue with two major browsers on a mainstream platform. I therefore request that this change NOT be reverted because the table renders Ok for you without it. But by all means revert it if this wikitable rendering issue is fixed externally.

For completeness, I see this issue with the following setup:

The latest version of the Microsoft Edge browser and the latest version of the Google Chrome browser running under Microsoft Windows 10 Pro 64-bit, on a desktop PC with Intel x64 CPUs.

ChrisJBenson (talk) 02:44, 5 November 2023 (UTC)

It Just Doesn't Add Up

This section refers to a set of numerical changes I made to the table of Andy Legg's Career Statistics. See the previous section for another unrelated change made to the same table at the same time.

I noticed that some of the individual numbers didn't add up to their respective subtotals Here is one such example:

Andy scored two goals in each of his two seasons with Hucknall Town. Yet his two-season total for that club was just 2 goals.

I corrected a small number of similar arithmetical errors. Most notably, this increased his career goal tally by three goals. I did NOT research or obtain the actual values in every category for every season at every club from a reliable independent source. Wherever the sum of a set of individual numbers didn't add up to the cited subtotal, I assumed that the individual numbers were correct and so I changed the corresponding subtotal to match. If that assumption is incorrect, and a reliable source indicates that the subtotal was previously correct, then at least one of the contributory individual numbers must be in error. So if you revert a subtotal, you will need to make at least one corresponding change to the individual numbers. I checked my own arithmetic by using the Florentine double entry bookkeeping system in an Excel spreadsheet.

But to reiterate, I did NOT verify any of the individual numbers from any source (reliable or otherwise). I just corrected the arithmetic where necessary.

ChrisJBenson (talk) 02:50, 5 November 2023 (UTC)