This template is within the scope of WikiProject Categories, a collaborative effort to improve the coverage of categories on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CategoriesWikipedia:WikiProject CategoriesTemplate:WikiProject CategoriesCategories
There is no discussion here to change the parameter from a-z to aejot. Was there a Tfd session? The change makes it more difficult to get to the articles in Category:Biography articles without listas parameter that have diacritics in the first or second position. I was sorely tempted to undo the change but I did not want to upset anyone. JimCubb (talk) 21:04, 17 January 2011 (UTC)[reply]
Hi Jim. I answered you on my Talk page, and I'll bring my rationale here for anyone else to "hit me over the head with" if I have been very wrong...
My sole intent when I converted LCTOC to the same alpha choices as LCTOC2 was to decrease the load time of cats that use LCTOC. My IE8 would take forever to load even your main-concern cat. Also, I felt that using the combination of first letters with each and every letter as a second letter, Aa Ab Ac, etc. was extreme overkill, as there are so many of those combinations that (I felt) are never used. So, for most considerations I think I'm correct. I did not want to take any further action until I received input, such as yours above. The difference is the number of combinations that have to be generated for each application. When /aejot is used, then there are 26 x 5 combinations. When /a-z is used, then there are 26 x 26 combinations that must be loaded each time the page is loaded into a browser. So /aejot loads a great deal faster than /a-z.
If your particular application absolutely requires the need for /a-z, then feel free to revert my edit. I have changed over to LCTOC2 for the cats that concern me. Again, my sole purpose was to "fix" LCTOC. If I have broken it for your or anyone else's app, then please accept my apology.
On my browser, this template has a horizontal scroll bar that is 13 screen widths wide. Does this show differently for some people, in some way that is better than the display of {{Large category TOC 2}}? For me, {{Large category TOC 2}} displays as a wrapped list.
This template predates the TOC 2 template, and was applied to a large number of categories almost immediately after it was implemented. The TOC 2 form came later, and presumably only some of the categories using the original were converted to use TOC 2. The original form is more compact (2 lines rather than 5 in the browser and screen width I'm using) - I suppose whether you consider this an advantage is a matter of taste. -- Rick Block (talk) 16:12, 19 September 2015 (UTC)[reply]
After encountering this obnoxious UI again in the wild, I have boldly changed this template to remove horizontal scrolling, which is unfriendly to readers. Feel free to revert me if there really is an advantage to this template that outweighs the unfriendly horizontal scrolling. – Jonesey95 (talk) 02:02, 21 January 2018 (UTC)[reply]
Agree, especially since they are now both exactly the same. They both call the same Lua module with {{#invoke:Large category TOC|aejot}}, and if that is what editors want, then there is nothing that should stop us from redirecting "LC TOC 2" to "LC TOC", which has been done. Paine Ellsworthput'r there15:56, 17 February 2018 (UTC)[reply]
I first raised this issue in the Surnames talk page and I've been told to say it here. Some of the sections for the template have become things like "Aj/At", "Bj/Bt" when they should've been "Ai/Au" and such, and I wonder how that happened. I was told that the template was changed months ago so I'm wonder if this can be fixed? Thanks. --BrydoF1989 (talk) 15:58, 5 June 2018 (UTC)[reply]
I changed this template in January 2018 from the previous version, which was a single scrolling horizontal line that was very user-unfriendly. Feel free to link to the discussion you are talking about, and I can contribute there. – Jonesey95 (talk) 00:36, 6 June 2018 (UTC)[reply]
And yes, I remembered of how it looked then and, I had no issue with it. Of course it would be for those on mobile. Hope you can sort it out the best you can. --BrydoF1989 (talk) 08:33, 7 June 2018 (UTC)[reply]
Please make the sandboxed edit. The module currently produces double spaces between many of the links. On Safari (Mac and iOS in desktop view), this causes the table of contents to exceed the width of the the div and to overflow off the right side of the window (or into the Tools sidebar). The edit fixes this by having a space at the beginning of each concatenated string, not also at the end.
On Chrome and Firefox, both versions look identical (which is the correct behavior, since HTML treats double spaces like a single space). You can see both versions at Template:Large category TOC/testcases. To speculate about why this odd glitch occurs, I suppose Safari thinks the double spaces will be twice as long as a single space but displays them as a single space. SilverLocust💬02:04, 29 February 2024 (UTC)[reply]