This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.Wikipedia HelpWikipedia:Help ProjectTemplate:Wikipedia Help ProjectHelp
Material from Help:Table was split out into Help:Tables and locations on 9 December 2023 from this version. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted so long as the latter page exists. Please leave this template in place to link the article histories and preserve this attribution.
I can't tell from this what your question is, but if you want a scrolling table, it is just a matter of setting height (or max-height) and overflow. Ditto width. See WP:PNT, top right just above the ToC; it uses {{PNT table}} and maxes out at around ten rows, and then scrolls. Is that what you are asking about? Mathglot (talk) 20:04, 16 August 2025 (UTC)[reply]
Column operations, like row operations, are a fundamental part of tables. There used to be a top-level (H2) section for column operations, until it was removed in this edit. Why was this done? Mathglot (talk) 19:43, 16 August 2025 (UTC)[reply]
All of that info was about width so I put that info in its own overall section called "Width" on the same page.
Just now I created a new overall section about "Column operations". With a link to the large section on Width (on the same page), and a link to the section on column alignment here: Help:Table/Advanced#Column alignment. That section is part of a much larger overall section: Help:Table/Advanced#Horizontal alignment in cells. That covers alignment in individual cells too.
I remember moving a lot of stuff off the Help:Table page in order to shorten it. Also to get rid of all 2-level subsections. Now you have only one level of subsections. Much easier to navigate.
I think the Width section should not be a subsection of Column operations. Because Width covers full table width too. And it links to another width page covering yet more intricacies of table and column width: Help:Table/Width.
Hello, is there a tool to help move around columns of a table? It is for this one [1], it is long and many columns are combined at certain parts, so it is sort of complicated. It would be very convenient to have a tool to move around the columns because the order of the featured parties does not reflect anymore their real relevance (for example, the third bloc is completely banned now), so I was wondering if such a tool exists. With the visual editor I can uniquely delete a couple of columns (not most), but I can't move around any. Thanks, SuperΨDro14:02, 20 August 2025 (UTC)[reply]
Hi, in the end I managed to alter the table with the visual editor after some experimenting. I was going to remove this thread but I forgot, so apologies. The issue is now resolved, but appreciate the help anyway. SuperΨDro17:38, 23 August 2025 (UTC)[reply]
I agree it is helpful. I suggest pinging the user at the thread you started at the article's talk page and explaining this to them. SuperΨDro23:09, 23 August 2025 (UTC)[reply]
This is because at the top of those search results it says:
Only searching in pages whose title starts with "Help talk:Table/"
So any table help page starting with Help:Table/ will have their talk page (Help talk:Table/...) or talk archives (Help talk:Table/.../Archive) to possibly show up in results for talk archive searches at Help talk:Table. I saw it happen once with that page's talk page showing up in the search results, and so that is why I changed its page title.
So the problem has been fixed by removing the slash from the page titles. Those old talk pages are redirects or blank now. So there is nothing to search for. The red linked talk pages weren't yet a problem since there was nothing there. See:
All of the italicized subpage names are redirects. There are 2 pages with content. There is a CSS page. The content pages do not have talk pages yet. It would be a problem if they got talk pages. If that happened, then the talk pages could be redirected to Help talk:Table to fix the problem. --Timeshifter (talk) 17:47, 23 September 2025 (UTC)[reply]
Whew. The only thing I am sure of at this point, is that the styles page should not be moved to Template space, separating it from where it logically belongs. I would not have moved any of those pages away from subpages. If it were up to me, I would put everything back the way it was, move all of the old subpage conversations into the appropriate Help talk:Table/Archive_*, any active subpage conversations to Help talk:Table, and redirect all the subpage Talk pages to Help talk:Table. There is no particular reason for the subpages to have their own Talk pages. Given where things are now, I don't know if it worth undoing it all, so I don't know what to advise, other than keeping the styles page local. I guess I don't really understand even within the current scheme why you would want to move it at all; what is the issue with leaving it at Help:Table/styles.css? Also, a styles page does not need a dedicated Talk page, it can just be redirected to Help talk:Table. But what about all those no-longer-subpages? Are you planning to have dedicated Talk pages for each one? I think they should all be redirected as well; anyone looking to discuss anything about Help:Table, including any of the menagerie of articles that belong to it, whether they are organized as subpages or not, should only have to look in one place, namely, here. Mathglot (talk) 23:24, 23 September 2025 (UTC)[reply]
See Wikipedia:Subpages. Subpages are not used for article names. But nothing forbids use in help pages. I just think it is a bad idea for the same reason that they stopped being used for articles in mainspace. It creates a confusing hierarchic structure where it is not needed.
Also, apparently, there are problems with the visual editor and help page names having slashes in them. See:
And if editors of other help page topics are encouraged to use subpages, then they will have the same problem with talk pages. And what if their hierarchy is not so focused on one topic? They may not want to redirect talk pages when the topics are too divergent.
As for table help talk pages all redirecting to here, I have no objection. They all have to do with tables.
I can see where styles.css makes sense as a subpage on the main table help page. So let's leave it there. I liked having all the CSS discussion in one place since it is so technical. That is why I wanted to move the CSS page elsewhere. To avoid the search problem. But I can live with moving the CSS talk to the talk archive here.
I kind of like having separate talk pages for each table help page. It keeps things focused. On the other hand I am realizing I am probably the only person with all the table help pages on my watchlist. Most people were coming to Help talk:Table anyway with their questions. There isn't much discussion, if any, on most of the separate talk pages. So it wasn't a problem I was concerned about.
But I now see that moving all past discussion to the archives of Help talk:Table does have its advantages. One can search in one place.
I do understand your point about having separate talk pages for each table help page, and that may be a plus for helpers, but it would depend on the people who need help going to the right Talk page to post their question—what are the chances of that? So, yes, there is perhaps some lack of focus or some sight inconvenience to the helpers of having it all in one place, but it simplifies everything for helpees, and imho that is a cost worth paying. It's kind of like my philosophy for template writing: it's all about making it easier for editors to use the template, even if that makes it harder for me (or other template writers) to write, but that is a worthy cost to pay, because users come first, not template writers. Same deal, imho, with Help page maintainers: we should make the design as clear and simple as possible for those readers coming here to read the pages, and ask for help, even if there is some cost or inconvenience to us as Help page maintainers. I don't know that this principle is enshrined anywhere in a guideline, but it is one I try to follow, and encourage others to follow; you may see it differently.
You have pointed out some reasons why subpages may not be advantageous, and made some good points on how it affects editors who maintain suites of pages like the Help pages. In some cases, I have a different view, but that's okay; to some extent, it's user choice or a judgment call. But I don't think that visual editor and ... page names having slashes is one of the criteria that should influence the choice at all. Yes, VE may have problems with subpages, but that is their problem to fix; Wikipedia should not be making decisions on how to do things all around the project based on broken, poorly designed, or incomplete software. VE has a history of problems and a very long list of bugs to fix, including things that are very basic and important. A lot of them even affect mainspace, like VE's very annoying use of numeric ref names, detailed at WP:VENAMEDREFS. That's just one; there are many such. The point being, we should not avoid best practices just because somebody else's software doesn't work right. (I seem to remember that VE couldn't be used on Talk pages at all; not sure if that is still the case, but the solution was not to get rid of Talk pages.) I suppose you hit a nerve, as I see occasions all over the place where editors in good faith twist themselves into a pretzel in their project, trying to do everything they can to work around VE's failings, rather than just create the best design they can for their project, and follow or comment on VE bugs in Phabricator so they will get some attention. Whatever design you come up with here, regardless whether it is my favorite or something very different, I would just hope you pick what seems like the best one for the Help table pages, and don't let VE's problems stand in your way of doing it the right way. Cheers, Mathglot (talk) 19:33, 26 September 2025 (UTC)[reply]
So we agree on moving all the table help talk pages (via redirects and consolidating the archives here). So unless there is an objection we can start doing that. --Timeshifter (talk) 02:29, 27 September 2025 (UTC)[reply]
Yes. One thing to think about wrt the archives, is how much do we (or anybody) care about whether all the discussions are in the "right" archive, and all in chronological order? Given that there are multiple talk pages all running concurrently, to get them absolutely in the right order would be a lot of work. But I don't think that matters too much, as long as it's very roughly in order by archive (higher numbered archives should have more recent discussions) even if the order of discussions inside an archive are not strictly in order.
One way to do this without a lot of effort on our part, is to archive the archives: that is, if we set up MiszaBot configs on pages which are already archives, and all pointing to the one Talk page here, then I am pretty sure that Cluebot will just archive discussions out of the old archives into the single one, until the old ones are empty. The trick for getting it mostly chronological, is to set the |algo= param very old, like 12 years, or whatever the oldest discussion is in any of the (ex-)subpage archives; when it is done, then set it to 10 years, then 8, and incrementally move it up, letting the bot do the oldest ones in all the pages, then slowing decreasing the algo until it gets whereever we want it; I'd say a year or two. That way, we don't actually have to move any discussions anywhere, just tell the bot how to do it. What do you think? Mathglot (talk) 03:04, 27 September 2025 (UTC)[reply]
Too complicated. I am going to just move them manually. It is not that difficult.
Plus many of the talk pages do not have archives, but have very old discussions.
It would take a lot of work to keep changing the algo date on a lot of talk pages and archives.
I don't really care if the archives are in order. Search will find what is desired.
Need to pick an archive size though. 150K seems like a standard size.
150KB is around 26,000 plain-text words according to this:
Given that people don't read archives, they search them for something they are interested in, and then just read that, the total size of the other discussions in that archive that they are not interested in doesn't really matter. And yes, 150K seems pretty standard, but I doubt anyone would notice if you made it bigger, so pick whatever number you want.
You don't have to google word counters; there is a tool that counts them. It's probably on toolforge, but you don't even have to dig it up, as {{section sizes}} incorporates it, so you can just use that. If you look at the headers at the top of this page, and open the Section sizes banner, you will see the result. Mathglot (talk) 04:33, 27 September 2025 (UTC)[reply]
But numbers seem way off; I count 2,233 words in this section (before this comment), so off by an order of magnitude. Bak to looking online. (My text editor gives a good count.) Mathglot (talk) 07:40, 27 September 2025 (UTC)[reply]
A talk page comment of mine from Aug 10, 2025 that I just added a couple word counter links to:
I just "select all" to get the whole page since I will be dealing with talk archives, and perfection is not needed. Speed is more important.
I will start archiving and see how things go. Feel free to consolidate more archives. Anything older than 9 months can go in the archives here.
--Timeshifter (talk) 20:14, 27 September 2025 (UTC)[reply]
I usually select almost-all, that is, minus the Appendixes like References, See also, Further reading; none of that is relevant to whether a page is too long and should be split or not. Also, since my text editor supports a powerful regex engine, it is very easy to eliminate all the superscript bracketed footnote numbers in the body with a very simple regex, so you don't get an inflated count just due to footnotes inline. Mathglot (talk) 20:38, 27 September 2025 (UTC)[reply]
Since they are talk archives there are no appendixes, long reference lists, and further reading.
I have redirected a few talk pages, and moved their old threads to the archives here. It has been fast and easy so far. I check the current number of words in the archive in preview before saving. When I reach around 26,000 I will start a new archive and reset the talk archiving bot counter.
Some table help talk pages have a long history, a larger number of participants, and many threads. Sometimes with archives. I see a net negative effect from redirecting their talk pages. I would not want those talk pages redirected without discussion. For example:
As previously mentioned, I don't think this is the way to go. Long history, large number of participants, many threads—none of that matters or is even relevant. What matters, is a user being able to search for and find old threads conveniently and efficiently. Having to remember or guess which subpage (or parallel page) was the one where something is likely to have been posted, so you can go look there first, is none of those. Keeping these legacy Talk pages will just slow things down, and make it harder to find old threads, and many editors won't bother. The fact that you even need an info notice that they might be in the wrong place is a yellow flag indicating that there might be something wrong here. I have nothing against more discussion to get a consensus for moving the discussions, but I see no advantages and only disadvantages from doing it this way. Mathglot (talk) 22:36, 27 September 2025 (UTC)[reply]
Someone with a question about sortable tables is going to read that help page first. I have worked on that help page and its talk page for years. I don't think people have a problem at all about asking questions there. Most people don't bother searching the archives first. They skim the talk page, and then ask their question. Problems in the sortable table archive have already been solved usually. If not, then a new thread is the way to go.
Same is true for collapsing tables and conditional tables. They are very particular types of tables, and people will read their help pages first. Since we have the {{table help}} template at the top of all table help pages people have little problem finding the specific table help page. And thus its talk page. It's really not broke. Questions get answered.
Those talk pages have more watchers. Enable the XTools gadget in the appearance section here:
8rz, would you like to link or explain whatever it is you are talking about, and not the Wikipedia article 'Discussion', so that other interested parties might be able to take part? Thanks, Mathglot (talk) 20:32, 27 September 2025 (UTC)[reply]
@Mathglot:, this and thus. I attempted to move to Help:Table/styles.css to Template/Help table/styles.css but rollbacked immediately by Timeshifter citing it was already discussed. I want to challenge the revert by claiming it is a more appropriate lication for a template's css styles on its corresponding subpage rather than some illogically placed albeit related help page. 8rz (talk) 20:44, 27 September 2025 (UTC)[reply]
At one point. I know it was there as well. I've been following this particular template during my hiatus ever since its creation. This header was my idea, afterall. Timeshifter check my user page. I am sure you'll recognize me ; Anyway proposing to it get moved back to the template's subpage as a logical intuitive location. For example, I am on the css page, want to go back to the template I need to go from help to the template namespace. Counter-intuitive. 8rz (talk) 21:05, 27 September 2025 (UTC)[reply]
See the old red-linked linkbox just below and to the right of {{table help}} in that thread. You said you "Barely found it." The template, I mean. I see the problem better now. That only links to the CSS page, and it does not currently link to the {{table help}} template.
The problem with the styles.css page is that it effects both table help pages, and the template. I think I will separate out the CSS only having to do with the template. --Timeshifter (talk) 23:48, 27 September 2025 (UTC)[reply]