Template talk:Bicolor

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Category:Pages with too many expensive parser function calls[edit]

Pages using this template dominate in Category:Pages with too many expensive parser function calls. Can someone rewrite it to reduce number of {{#ifexist}}. --Jarekt (talk) 14:58, 11 January 2016 (UTC)[reply]

When I added some color combinations to this and other such by-color templates I was worried it can get quickly out of hand. The “unexpensive” alternative is to have a complete color-vs-color grid and allow for red links to exist, which can be made to look not so bad by using image links, as done in {{TramColors}}. -- Tuválkin ✉ ✇ 17:30, 11 January 2016 (UTC)[reply]
I think that would be much more sane approach. --Jarekt (talk) 19:52, 11 January 2016 (UTC)[reply]
@Jarekt and Tuvalkin: I made a Lua request on en:Wikipedia talk:Lua#Overload Template:Bicolor (Commons) -- User: Perhelion 11:16, 5 October 2018 (UTC)[reply]
I've done some preliminary work in Module:Sandbox/Bicolor Module:Bicolor. Making a table of all colour combinations is rather bulky as there are 34 colours named - that's around 1,000 bi-coloured squares to cram into a template if we allow all combinations. You can get an idea from looking at a simple demo in User:RexxS/sandbox that uses 14px squares. Because combinations such as "red and yellow" and "yellow and red" both exist, I can't get the number any smaller.
I'll have a look later at only having the 520 currently defined combinations. Writing that will be easy enough. I'm trying to make it so that adding a new combination, or even a new colour should be a simple task.
However, if we want to minimise the number of items, then I think we'll have to go back to expensive calls because Lua works under the same restrictions – the test for existence of a page with a given title is expensive. --RexxS (talk) 19:13, 5 October 2018 (UTC)[reply]
You are the man, looks good! 1000 potentially ifexists is indeed way to much. If we could get the names of the sub-cats with Lua we could easily solve this problem!? But I found only a command to get the number of sub-cats (.pagesInCategory.subcats, if we know sub-cats are only bicolor cats then we could limit the check in this loop number). -- User: Perhelion 20:07, 5 October 2018 (UTC)[reply]
I have the solution !! We can parse <categorytree>Bicolor bikinis</categorytree> or {{#categorytree:Bicolor bikinis|depth=1|hideroot|namespaces=14}}! -- User: Perhelion 21:16, 5 October 2018 (UTC)[reply]

@RexxS: Using ifexist is required because the output varies depending on the page. For example, see Category:Black and white police vehicles + Category:Black and white automobiles + Category:Black and white sheep. For some reason Category:Black and white flags uses {{Bicolor0}}. I developed something similar for Template:Countries of Europe. If interested, the easiest list of all the related pages is available on my user page but there is a lot of complexity there that is not needed here. I don't have any ideas at the moment. Johnuniq (talk) 00:41, 6 October 2018 (UTC)[reply]

@Johnuniq: Thanks for comment, but as I said, we can simply use categorytree without any ifexist. -- User: Perhelion 04:10, 6 October 2018 (UTC)[reply]
I didn't comment about categorytree because I've never seen Lua do something like that and I was going to leave that idea for others. However, I just tried it and much to my astonishment, it works. The result is a string of lines, each line being a piped link to a category. The list seems to be in alpha order. Later I might get a chance to think about how to use that for an efficient solution. Johnuniq (talk) 05:52, 6 October 2018 (UTC)[reply]
Bad news: I just tried again with nowiki applied to the text to see exactly what was returned. All I got was a strip marker and I do not see any way to expand it. I think I've heard that Lua has no way of getting the members of a category. That sort-of makes sense because such a list could be monumentally long and Scribunto is designed to avoid overloading the servers, and there is no state (no way to continue getting a list broken into small chunks). Johnuniq (talk) 07:31, 6 October 2018 (UTC)[reply]
  • Not sure why I’m being pinged here. This discussion started because there were too many #ifexist calls, threatening to grow quadratically with each new color added. I offered an alternative solution that avoids that issue by linking to all possible combination cats, including red ones. (As done in {{TramColors}}, meanwhile expanded to cover also {{RailVehicleColor}} and {{VehicleColors}}.) Almost three years later you seem to have decided to go on with expensive calls, this time using LUA instead of pedestrian template functions — meaning the problem will still exist but less people will be able to tackle it. Congratulations? -- Tuválkin ✉ ✇ 07:25, 6 October 2018 (UTC)[reply]
Sorry for pinging you. Your solution would be indeed not adequate for this. Because we would have 500-1000 color squares with approximately 90% dead text links on average on every category. Except we would disallow red links per CSS hidden, if we have a template CSS (I never tried this, but should be possible), which can exclude dead links. -- User: Perhelion 08:34, 6 October 2018 (UTC)[reply]
  • If 90% of the possible color combo cats do not exist, then a “sideways” cat nav panel listing them all is not in dire need: One can simply click to the parent cat and down again to another of those dew color combo cats. -- Tuválkin ✉ ✇ 18:49, 6 October 2018 (UTC)[reply]

@Jarekt, Perhelion, and Johnuniq: I have a possible first draft of a solution, using Module:Bicolor, Template:Bicolor4 and Template:Bicolor4/styles.css.

{{Bicolor4 | dogs }} →

Bicolor dogs
 blue, tan  blue, white  lilac, white  red, white  yellow, white

{{Bicolor4|flags}} →

Bicolor flags
 beige, green  black, blue  black, brown  black, gold  black, gray  black, green  black, maroon  black, orange  black, pink  black, purple  black, red  black, white  black, yellow  blue, brown  blue, cyan  blue, gold  blue, gray  blue, green  blue, maroon  blue, orange  blue, pink  blue, purple  blue, red  blue, white  blue, yellow  brown, gray  brown, green  brown, orange  brown, pink  brown, purple  brown, red  brown, white  brown, yellow  cyan, pink  cyan, white  cyan, yellow  gold, green  gold, maroon  gold, purple  gold, white  gray, green  gray, maroon  gray, purple  gray, red  gray, white  gray, yellow  green, gray  green, maroon  green, orange  green, pink  green, purple  green, red  green, white  green, yellow  grey, white  maroon, white  maroon, yellow  orange, black  orange, pink  orange, purple  orange, red  orange, white  orange, yellow  pink, purple  pink, red  pink, white  pink, yellow  purple, red  purple, white  purple, yellow  red, black  red, blue  red, white  red, yellow  white, black  white, blue  white, green  white, red  white, yellow  yellow, black  yellow, red  yellow, white
  • Expensive parser function count 0/500
  • Lua time usage 0.010/10.000 seconds

I can change the output to use {{Hlist}} if that is preferred. Would anybody be willing to do a little testing for difficult cases? I can add the navbox outer stuff to Template:Bicolor4 if it looks like this solution is worthwhile, unless somebody wants to do that anyway. Thoughts? --RexxS (talk) 23:12, 6 October 2018 (UTC)[reply]

OMG that is amazing! The dog example has 100K bytes of HTML for red links that are hidden by the css. Later I might fiddle with the code a tiny bit but assuming it works with piped links that is a sensational result. I'm itching to do something with the color tables but maybe it wouldn't be an improvement. The only downside is that I should think about doing a bunch of work to implement this in Module:Countries! Johnuniq (talk) 01:45, 7 October 2018 (UTC)[reply]
Good job man! =b(the categorytree thing indeed seems not to work) So we are ready for replacement!? Simply put the color squares inside the links (with shorten text). yes -- User: Perhelion 06:02, 7 October 2018 (UTC)[reply]
@Johnuniq: the odd thing is that {{Bicolor|dogs}} already uses 22K of wikitext for the four list items because the no-wrap spans are created outside of the #ifexist tests and we get 520 of them anyway. I've made an alternate version in Template:Bicolor/sandbox that does things a little better IMHO. It reduces {{Bicolor/sandbox|dogs}} to 1.5K of list items in wikitext and employs {{Hlist}} for accessibility improvements.
@Perhelion: I'm going to try out a fuller version of {{Bicolor4}} in its sandbox first as I'm worried that the extra code to make the coloured squares and the piped display text will make the size huge. I'll report back on what I find. --RexxS (talk) 21:08, 7 October 2018 (UTC)[reply]
@Perhelion: Almost there. I have a demo in Template talk:Bicolor4 and I just need to track down the dangling last category.
@Johnuniq: The size of the rendered html shot up to 220K after I added the coloured squares and piped links. I was able to bring it down to 175K by using templatestyles, but that's still rather excessive. I'll think some more about it. I moved the colour definitions into Module:Bicolor/data for ease of maintenance and that seems more satisfactory whatever scheme we end up with. I need some way of circumventing the #ifexist test that's not expensive. The documentation implies that titleObject:getContent isn't expensive, but I don't trust the documentation, which is generally poor. --RexxS (talk) 23:33, 7 October 2018 (UTC)[reply]
I wouldn't be concerned about the size of the hidden HTML. I only mentioned it as an indication of what was happening. The way these navboxes are used means that excess baggage is not a problem, and is much better than having 500 expensive parser calls. I'm worrying about how you can insert bullets between items—can the superfluous bullets be hidden? On reflection, I guess your comment is referring to navboxes involving more than two colors where the combinations would produce a gigantic size. Such a size might be unacceptable but I'm pretty sure the alternatives would be worse. I would expect getContent for another page to be expensive but even if it isn't there would be far too much overhead in attempting to get the content of a thousand pages just to see if they exist. The only solution available with current MediaWiki is probably for a bot to periodically work out what pages exist and write information somewhere that a module could use to know which links should be displayed. Johnuniq (talk) 23:50, 7 October 2018 (UTC)[reply]
I would keep the layout as the old was (only color names as link text), but I would replace this spans with this nowrap thing, as we only need to replace the spaces with "nbsp" (single sign not entity). That would reduce the size enough. -- User: Perhelion 10:59, 8 October 2018 (UTC)[reply]
@Johnuniq: I've experimented with {{Hlist}} (which hides empty list items), but it caused problems with not hiding everything, so maybe I'll leave that as an exercise for the future. Nobody seems to want list styling for the navbox anyway, because the current implementation {{Bicolor}}}} doesn't use it. Templatestyles makes it pretty easy to have whatever bullets or separators you want by tweaking a class locally to override things like the hlist class. --RexxS (talk) 16:51, 8 October 2018 (UTC)[reply]
@Perhelion: I can't use the old layout. It's the links that are hidden by the css when they are redlinks. If I don't include the boxes inside the links, we'll see 520 of them. I'm really not keen on embedding non-breaking-space characters inside text for two reasons: (1) presentation should be in the CSS, not the HTML; and (2) it makes maintenance a nightmare if some spaces are non-breaking and others are normal. I'll make a test anyway and see if it's any better. --RexxS (talk) 16:51, 8 October 2018 (UTC)[reply]
@RexxS: The traditional way of circumventing #ifexist for cases like this is to build a bot and have it update a data page somewhere that can be parsed from Lua. Is that a feasible strategy here? — Mr. Stradivarius ♪ talk ♪ 14:54, 8 October 2018 (UTC)[reply]
Thanks, Mr. Stradivarius. It certainly is feasible, but we'd need a page (part of one) for each possible "thing" in Category:Firstcolour and secondcolour "thing". The number of colour combinations is finite (currently 520), as is the number of bicoloured things, but of course, both are unbounded. We'd need the bot to regularly crawl the relevant part of the category tree to keep up with changes. It might have the bonus of being able to automatically update Module:Bicolor/data at the same time, perhaps. --RexxS (talk) 16:51, 8 October 2018 (UTC)[reply]
Bot would not have to crawl. It would only have to look at categories that transclude the {{Bicolor}} template. We could write SQL query to generate such list (or use AWB) and a spreadsheet command to convert it into a code for Lua table with entries for each "thing" which would list all existing categories. --Jarekt (talk) 03:52, 10 October 2018 (UTC)[reply]
Finally (after some subside of effort) I putted now the sandbox version to life from RexxS. As I additional removed the span with the nowrap class (which reduced the output code 100 kB for the "flag" example) and added the a point sign as separation (like the {{Hlist}} introduced in the second Template:Bicolor/sandbox by RexxS).
Big thanks to RexxS again and other for help comments and feedback.
Performance compared (example Category:Bicolor clothing):
old
CPU time usage: 0.340 seconds
Real time usage: 0.554 seconds
Preprocessor visited node count: 4505/1000000
Highest expansion depth: 5/40
Expensive parser function count: 519/500
new
CPU time usage: 0.244 seconds
Real time usage: 0.263 seconds
Preprocessor visited node count: 1053/1000000
Highest expansion depth: 3/40
Expensive parser function count: 0/500
-- User: Perhelion 18:14, 27 October 2018 (UTC)[reply]
  1. Template:Bcolor Y
  2. Template:Bicolor X
  3. Template:Bicolor0
  4. Template:Bicolor2
  5. Template:Bicolor3
  6. Template:Bicolor4
  7. Template:Bicolor9
  8. Template:Bicolor churches (by Pitke 2018-05-31)
I've created a first version with 2 additional parameter (conj, con) for display and Cat naming: Template:Bicolor4/sandbox
-- User: Perhelion 13:23, 28 October 2018 (UTC)[reply]
There's no solution if you want to test the existance of categories, than just allowing the displayed list of colors to be restricted, by specifying 1 or 2 colors to be listed, excluding all other pairs that do not contain one of these. Using a template to do that would be very tricky, a small module can do that in a much simpler way (the module would just assume that all bicolors categories are named using alphabetic order for the two colors in English; if this is not the case, rename these categories or pages to use a consistant ordering).
(Note that the general category for all bicolors do not need to list all pairs, they can just list subcategories for bicolors containing 1 given color...; the main category would have just a nav box for only one color name (as there would be no colors given in parameter to restrict the list), only the subcategories would have a navbox citing 1 color to list all possible pairs, then each category for a sepcific pair would have two color parameters, and would then list combinations with one of these two colors or both) that solution is extensible easily for tricolors without risking to exchaust the 500 tested pairs.
For bicolors, as long as we don't have 250 color names or more, it will just work ! And the navboxes will be much easier to read to locate a color pair (or color triplet for tricolors).
I'll do that and solve this problem, not solvable with any one of the proposals above. verdy_p (talk) 23:13, 9 May 2020 (UTC)[reply]

Collapsable[edit]

Can this box be made collapsible? -- Tuválkin ✉ ✇ 01:19, 16 August 2023 (UTC)[reply]

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Template_talk:Bicolor&oldid=793343665"