Wikipedia talk:WikiProject Templates

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Templates
WikiProject icon This page is within the scope of WikiProject Templates, a group dedicated to improving the maintenance of Wikipedia's templates. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.

Does the current text of WP:BIDIRECTIONAL have broad consensus[edit]

Pls see Wikipedia talk:Categories, lists, and navigation templates#WP:BIDIRECTIONAL navbox requirements. -- Moxy (talk) —Preceding undated comment added 19:01, 19 November 2015

List of cities by temperature[edit]


Hi! I am creating a page similar to List of cities by sunshine duration, but with the average temperature variable instead of hours of sunlight. It is located in my userspace at the moment. Like the sunshine duration page, it is kind of slow to load, even though I have only filled in tables for two continents (Europe and North America).

I created a template for the table itself, {{Avg temp table}}, and two templates, {{Avg temp row C}} and {{Avg temp row F}}, to create table rows. I initially used {{convert}} to convert from Fahrenheit to Celsius or Celsius to Fahrenheit, but then I made the simple template {{Avg temp row F/FtoC}} to hopefully reduce processing time. I assume a simple template processes faster than Module:convert. (I need to make {{Avg temp row C/CtoF}}.)

Both table row templates use {{weather box/colt}} to set background and text colors in CSS based on temperature. In order to set temperature colors for the cities in the US, whose temperature data is in Fahrenheit, I have to convert to Celsius.

The page is slow to load, and I am afraid that when I fill in more cities, it will be more than twice as slow. I would appreciate input or template or module coding help to shorten the processing time. I'm not much of a programmer; about the maximum I can do is the four templates mentioned above. I couldn't figure out how {{weather box/colt}} works, so I have no idea if it could be simplified, or how to create a separate template for Fahrenheit temperature colors, much less create a module to make the whole table generate faster. — Eru·tuon 20:45, 31 August 2016 (UTC)

Pinging @Johnuniq and JohnBlackburne:, since they were working on improving List of cities by sunshine duration. — Eru·tuon 17:45, 1 September 2016 (UTC)
Using templates is not going to work. Examining the html source of your test page shows it spends 4.5 seconds executing {{Hexadecimal}} alone. I can look at fixing it, but not for a few days. See Module:Biglist (search for "weatherboxcols") for what I did for the hours of sunshine. Johnuniq (talk) 05:04, 2 September 2016 (UTC)
Whenever you can get to it, I will greatly appreciate it. It occurs to me that {{Weather box}} uses Module:WeatherBoxColors to create its colors. Perhaps you could either use that module, or base the module on it. — Eru·tuon 20:45, 2 September 2016 (UTC)
@Erutuon: Thanks for editing Module:Biglist/doc. I had a very quick look at the module before posting above and wondered why the code mentioned "temperature" when it appears to be hours of sunlight! I obviously mixed it up, probably with something else I had seen at that time. I'll clean the code later. Johnuniq (talk) 07:50, 2 September 2016 (UTC)

@Erutuon: I started working on some module code to replace {{Avg temp row C}} and {{Avg temp row F}} with something much more efficient. However, I see there were some recent edits by Frietjes. Do you have some other plan? That is, I'm wondering whether you still want me to implement a module fix. My current plan (if it's wanted) would be to keep the two templates I linked, but change them as outlined below.

Example of current usage:
{{Avg temp row C

That would be replaced with:
{{Avg temp row C
|4.4 4.2 7.0 12.9 18.5 23.5 26.4 26.3 22.5 16.6 11.2 7.3 15.1

Template:Avg temp row C
| style="text-align:left;" | {{{1|}}}
| style="text-align:left;" | {{{2|}}}
| style="{{weather box/colt|{{{3|}}}}}" | {{{3|}}}<br>({{Avg temp row C/CtoF|{{{3|}}}}})
| style="{{weather box/colt|{{{4|}}}}}" | {{{4|}}}<br>({{Avg temp row C/CtoF|{{{4|}}}}})
| style="{{weather box/colt|{{{5|}}}}}" | {{{5|}}}<br>({{Avg temp row C/CtoF|{{{5|}}}}})
| style="{{weather box/colt|{{{6|}}}}}" | {{{6|}}}<br>({{Avg temp row C/CtoF|{{{6|}}}}})
| style="{{weather box/colt|{{{7|}}}}}" | {{{7|}}}<br>({{Avg temp row C/CtoF|{{{7|}}}}})
| style="{{weather box/colt|{{{8|}}}}}" | {{{8|}}}<br>({{Avg temp row C/CtoF|{{{8|}}}}})
| style="{{weather box/colt|{{{9|}}}}}" | {{{9|}}}<br>({{Avg temp row C/CtoF|{{{9|}}}}})
| style="{{weather box/colt|{{{10|}}}}}" | {{{10|}}}<br>({{Avg temp row C/CtoF|{{{10|}}}}})
| style="{{weather box/colt|{{{11|}}}}}" | {{{11|}}}<br>({{Avg temp row C/CtoF|{{{11|}}}}})
| style="{{weather box/colt|{{{12|}}}}}" | {{{12|}}}<br>({{Avg temp row C/CtoF|{{{12|}}}}})
| style="{{weather box/colt|{{{13|}}}}}" | {{{13|}}}<br>({{Avg temp row C/CtoF|{{{13|}}}}})
| style="{{weather box/colt|{{{14|}}}}}" | {{{14|}}}<br>({{Avg temp row C/CtoF|{{{14|}}}}})
| style="{{weather box/colt|{{{15|}}}}}" | {{{15|}}}<br>({{Avg temp row C/CtoF|{{{15|}}}}})

That would be replaced with (MODULE name to be determined):
| style="text-align:left;" | {{{1|}}}
| style="text-align:left;" | {{{2|}}}

The module would split the temperatures into columns and output the styling and values. It would do everything itself and would be very fast. Are columns ever blank/unknown? If so, we would need a convention such as a hyphen to mean "missing", or go back to pipe-separated values. Johnuniq (talk) 05:32, 8 September 2016 (UTC)

The edits by Frietjes were on her own initiative. Nothing has changed; I still need a module solution from you. I've just been sidetracked by plant-related editing.
That looks very neat. I like having a single parameter for all the temperatures; in fact, I was sort of hoping it could be done that way.
Up till now, I have simply omitted a location if it has missing data for any month, but it would be good to have a fallback. It might never be used, but then again, it wouldn't hurt. A hyphen would be potentially ambiguous, when a location has temperatures below zero. M might be a better option; I think that's what the NOAA uses in their tables.
I am considering how a template and module like this would have to be modified to make it usable in pages like Climate of California, where the table gives highs and lows. Might need to have the capability of inputting highs, lows, and averages, and then choosing what to do with them (for instance, not displaying the average, but using it to select the color for the cell, displaying it in a tooltip, and using it as a sortkey, as in my sandbox). But that is probably not relevant to the immediate task of fixing the slow processing speed of the list of cities. — Eru·tuon 07:03, 8 September 2016 (UTC)
@Johnuniq and Erutuon: my edits were to make the templates usable in Missouri#Climate. I was initially thinking that we could modify {{weather box}} to allow it to output only the rows, without the enclosing <table>...</table>. but, it would be a real win if we could make the invoking syntax less verbose than what we have with {{weather box}}. pipe separators or space separators are the same amount of typing for me, so either one would work for me. separating the row labels and references column from the core module is also a great idea since it would allow me to use rowspans for the repeated row labels in Missouri#Climate. now, if we could extend the compact syntax to {{weather box}} we could save hours of typing out 'Xyz avg record high F =' for every month and every statistic. Frietjes (talk) 13:18, 8 September 2016 (UTC)

@Erutuon: For the Albuquerque entry at User:Erutuon/List of cities by temperature, the Year cell shows "14 (57.2)". Why is that "14" and not "14.0"? My current code is generating 14.0 (the same as would be shown by convert). I don't really want the "why" question answered—I'm wondering what is wanted. That is, was the suppression of the .0 intentional? The previous row (Saint-Pierre) has "2.0 (35.6)" for the April temperature. Johnuniq (talk) 05:55, 9 September 2016 (UTC)

@Johnuniq: It's not intentional. It ought to be displaying the correct number of decimals. For some reason the round function in {{Avg temp row F/FtoC}} is inappropriately removing the zero in the tenths place. — Eru·tuon 06:08, 9 September 2016 (UTC)

@Erutuon and Frietjes: Please have a look at the following.

The module provides the following functions. Input "C" means the values should be °C, and Output "C/F" means it shows °C and °F, in that order.

Function   Input     Output
CtoF        C         C/F
CfromF      F         C/F
FtoC        F         F/C
FfromC      C         F/C

The only difference I can see in the rendered result of my sandbox with respect to the original is the fact that the sandbox has many ".0" which are omitted in the original. The colors appear to be correct. More testing is needed, and I need to check the code again. Johnuniq (talk) 03:07, 10 September 2016 (UTC)

It looks good. No errors as far as I can see, and it loads much, much faster.
I wish the colors for the hot part of the temperature scale peaked at 40 °C (104 °F) instead of 50 °C (122 °F) (i.e., the color for 50 in the Celsius table here was instead on 40, with other values interpolated so that 4 degrees was still white.), because that's about the limit for average monthly temperatures on earth. (There would have to be a different scale for highs, which have reached 56 °C, 133 °F or higher.) But I don't understand the math that determines the colors. — Eru·tuon 06:12, 10 September 2016 (UTC)
I just added some brief documentation with some important usage notes—view the module page now. I was going to ask you to check function temperature_style in the module (it's at the top). That code is implementing the logic (I hope!) at Template:Weather box/colt. Where did it come from? If we can't find someone who understands it, I could probably force myself to study due course. The large number of references and {{cite web}} now appear to be a significant limiting factor if you want to put a massive number of tables in a page. Johnuniq (talk) 07:33, 10 September 2016 (UTC)
I looked at the history of {{Weather box/colt}} and then came to Template talk:Weather box/Archive 3. It seems that, at first, particular colors were applied to ranges of temperatures, then 117Avenue figured out a function that would interpolate and make every temperature have a slightly different color. He's still active; perhaps he can help explain? — Eru·tuon 08:08, 10 September 2016 (UTC)


I synced Module:Weather/sandbox with the main module and then created a modified version. I renamed and restructured the functions; no actual changes in what the functions do. My goals are to make the code more understandable, to make it easier for the style function to be called by a template or another module, and to provide for expansion (the addition of style functions for other weather variables).

I'm not sure if my version is faster or slower than the main module; you can see the test page on my sandbox. I should create a replica of the sandbox using the main module and compare. It's probably at least a little slower. And I haven't tested to make sure the show function still works. — Eru·tuon 08:56, 20 September 2016 (UTC)

I saw your changes to the sandbox. Stuff like adjusting the functions won't influence performance in any significant way—calling a couple of extra functions is very low cost. I have only superficially looked at the changes and don't know what benefit there may be from splitting things up. A couple of points. There are now two mentions of font-size: 85% and duplicating stuff like that should be avoided. It is best to avoid global variables because they mask typos and are hard to follow. There are four at the moment, possibly unintentional: background_color + color + font_size + text_color.
The original code emulated the old template and only set a text color when needed, that is, when white is required. It assumed the default text color would be close to black. I suppose always specifying it as black as done in the new code is better, but it does bloat the output. That probably does not matter—no one else seems to worry about that kind of thing.
If you are preparing to handle more than temperatures, my approach would be to copy the original temperature_style function, then modify it for the new property (rainfall or whatever), then carefully inspect the two functions and refactor them to make one function that generalizes both of them. The clever way to generalize code is to make it extract what it needs from a table of data. That's quite painful but useful in the long run. I can show you what I mean if you provide an example. Johnuniq (talk) 10:26, 20 September 2016 (UTC)
Oops, thanks for pointing out the duplication of font-size; 85%;; that was a mistake. Most of the global variables were also mistakes, except for font_size, which I was thinking should be selectable somehow, but it should probably just be a local variable for now. I fixed that, and removed color: #000;, which is probably unnecessary as you say. I assume most people have color set to black. I'll respond to the rest of your comment later today. — Eru·tuon 19:57, 20 September 2016 (UTC)
function w._precipitation_color( val )
    local item, background, text_color;
    if val == nil then
        return format_line( "FFFFFF", "000000" );
    item = hex( range_pos( val, 165.6, 0 )*255 );
    background = item .. item;
    item = hex( range_pos( val, 300, 165.61 )*207 + 48 );
    background = background .. item;
    if val > 90 then
        text_color = "FFFFFF";
        text_color = "000000";

    return format_line( background, text_color );
I am not sure if this is what you mean by an example, but the new property I am most interested in adding is rainfall, because it could immediately be used in Climate of Minnesota. Would you be able to help me to figure out how to modify the precipitation color function from Module:WeatherBoxColors so that it uses a table? It would be ideal if it could be integrated as another palette. (Sunshine hours would also be a good addition, because then the List of cities by sunshine duration could be greatly simplified.) — Eru·tuon 02:00, 21 September 2016 (UTC)
The restructuring allowed me to create a function to generate style attributes in Climate of California. It is much faster than the previous version according to the timing profile, and has much simpler template syntax. — Eru·tuon 05:48, 21 September 2016 (UTC)
I tweaked the code—see if you can live with it. I'm also inclined to restore the lack of blank lines in my original—IMHO it's better to get used to the indents to tell the brain when a new section of the code starts. I'm working on something complex and don't want to do a lot of investigating. I can certainly add something for rainfall but I would need an outline of what is wanted. Say an example of what input would be provided, and the output for a typical cell. Presumably you would sort out the palette. Before saving my edit to Module:Weather/sandbox, I checked what it did to Climate of California#Temperature range. It totally changed the colors! Then I purged the article (?action=purge) and noted that the purge totally changed the colors, and the new colors agree exactly with my version of the module. You might want to check if the colors are in fact ok. Johnuniq (talk) 06:19, 21 September 2016 (UTC)
Ohh, I think the colors changed because I switched to the average temperature palette! It must have been right when you were editing the module. Hmm, no, it wasn't. Huh. Perhaps you had loaded a previous revision or something. Well, whatever it was, the colors are as intended. Death Valley is supposed to have an almost black July and August, since it has the hottest average monthly temperatures on Earth (as far as I know). — Eru·tuon 06:42, 21 September 2016 (UTC)

I made a function at Module:Sandbox/Erutuon/Temperature arrays that takes average, high, and low and makes a table that displays high and low and uses average to set the color. Not quite all it needs to do, but it's a start. — Eru·tuon 01:28, 24 September 2016 (UTC)

Now the module is pretty sophisticated and can output several different results depending on how many sets of values are given to the template, and which parameters are chosen in the module. Still have to figure out how to make the output selectable by a template parameter or parameters, though. — Eru·tuon 02:41, 25 September 2016 (UTC)
I think Module:Sandbox/Erutuon/Temperature arrays is just about ready! It allows you to select how to display the values (whether to round to an integer, add color, make it sortable, and so on), and it can create the tables in Climate of Minnesota and Climate of California. See those two examples lower down on the documentation page. It would also be usable in the List of cities by temperature, but I would guess it's slower than Module:Weather. It adds the official minus sign using string.gsub rather than the complex way used by Module:Weather. — Eru·tuon 02:54, 29 September 2016 (UTC)
I tested Module:Weather, Module:Weather/sandbox, and Module:Sandbox/Erutuon/Temperature arrays (which uses Module:Weather/sandbox to generate CSS properties) by creating copies of the same table at User:Erutuon/List of cities by temperature/sandbox, User:Erutuon/List of cities by temperature/sandbox2, and User:Erutuon/List of cities by temperature/sandbox3. The timing varies, but it seems that my new module is faster than the other two. Very pleased. I will merge it with Module:Weather/sandbox soon. — Eru·tuon 05:29, 29 September 2016 (UTC)
Actually, now the source page says it's not faster. I keep reloading and it gives a different number each time. Very weird. — Eru·tuon 19:11, 29 September 2016 (UTC)


@Johnuniq and Erutuon: nice work! it would be great if the 13th column could be automatically generated if it's not specified. basically, for a list of average temperatures, the year average can be computed using the weighted average of the months. if this module is going to be used for record highs and lows, then the 13th entry is just the max and min of the months. so, I could see having, say, an optional 'type=avg', 'type=min', and 'type=max' trigger the auto calculation of the 13th entry if it's missing. this is how {{weather box}} works. Frietjes (talk) 13:13, 10 September 2016 (UTC)
That's do-able, if I can understand it! What is a "weighted" average in this context? Hmm, would it involve multiplying the Feb avg by 28 and similar for other months, adding the results, and dividing by 365 (365.25?). I suppose I could cheat and look in the other module. Johnuniq (talk) 03:53, 11 September 2016 (UTC)

I've done a little thought on what parameters and functionality the module needs to have if it is going to also be usable in the climate comparison tables in pages such as Climate of Oregon, Climate of California, Climate of Minnesota, and the List of cities by temperature. The Oregon and California tables display monthly average highs and lows (no annual high and low), but in different formats: Oregon has highs and lows in separate cells; California has highs and lows separated by slashes. The Minnesota table displays monthly and annual averages in the same way as the List of cities by temperature.

It would be neat if the same module could take several sets of values and then you could choose what type of output to create from them. This would allow Climate of California to have colors, sortkey, and tooltip based on average temperature, while still displaying the highs and lows. See my sandbox.

I think that would be possible if there were a parameter for unit (C or F, or mm or in if precipitation is added) and a parameter for order of values (13A for 13 averages; 12H12L for 12 highs, and 12 lows). Then the module could create an array or set of arrays with a name based on the type of value and unit (13A would yield an array AF; 12H12L would yield HF, LF). And it would convert the units to the other unit, creating a second array in the other unit (AC; HC, LC).

Then the module could take these arrays and generate output using a format type: for instance, HF/LF<br />(HC/LC) for the California table; | HF<br />HC || LF<br />LC\n for the Oregon table.

To add color, I think there should be separate temperature_color and text_color variables (or functions?) that only contain the CSS properties background: #xxxxxx; color:#xxxxxx; and font-size: XX%;, and the style="" attribute and the containing pipes | | would be part of the output format. That way, temperature color and text size can be selected independently. If that were true, than the Climate of Minnesota would use the format | style="temperature_color(AC) font_size;" | AF<br />(AC)\n and the List of cities by temperature would use | style="temperature_color(AC) font_size" | AC<br />(AF)\n.

And, if values in F with the order 12A12H12L were given as input, the module could use the output format \n| data-sort-value="AF" title="average temperature: AF" style="temperature_color(AC)" | HF/LF<br/>(HC/LC) to create the version of the California table in my sandbox.

I don't know too much about template coding, so you'll have to tell me if this idea is doable. I'm not sure how to create arrays from a list of values. I guess the output formats have to be modified into Lua code using .. for concatenation and ' ' for strings as opposed to variables, and adding indices for values in the arrays... — Eru·tuon 02:40, 11 September 2016 (UTC)

I'll contemplate that over the next few days. I'm caught up elsewhere and won't be doing much on-wiki for a while, but if there is a problem with the current system I can see what might be done. Johnuniq (talk) 03:53, 11 September 2016 (UTC)
I've been working on a module that handles the values in the way I suggested. It's slow work, and at the moment all it can do is take a set of values in one unit (C and F), make an array of the other type of unit, and print out both arrays in a simple fashion. — Eru·tuon 05:23, 16 September 2016 (UTC)
So far, I haven't figured out how to create and handle three arrays of values. Hopefully I'll have a lightbulb moment. Probably it would be easier if they were entered into three different parameters. — Eru·tuon 03:22, 20 September 2016 (UTC)

Gabès and Tel Aviv have sea temperature tables only with monthly values. Ideally there should be a parameter to specify the number of temperature values: 12 or 13 would be the most common numbers, but it's conceivable that a table would include 4 values for the average temperatures of the four seasons. I used the module for Gabès, and it generates an extra cell at the end. — Eru·tuon 20:54, 14 September 2016 (UTC)

I also wish the CtoF, FfromC, CfromF, and FtoC functions were replaced by a single function temperature and two parameters |inputunit=F and |outputunits=FC or |outputunits=CF (or, indeed, |outputunits=F or |outputunits=C). That would make it much more intuitive. The complexity of changing units and deciding which one goes into the output could be left to the module.

It would also be nice to have a parameter selecting whether to display the names of the units: |displayunits=no for the output Cvalue<br>(Fvalue) and |displayunits=yes for the output Cvalue°C<br>(Fvalue°F). The sea temperature tables look better (in my opinion) when unit names are displayed. — Eru·tuon 21:01, 14 September 2016 (UTC)

And it would be nice to be able to turn off and on the line break: outputting Fvalue (Cvalue) instead of Fvalue<br>(Cvalue), for instance. The table in Climate of Minnesota (permalink) omits the line breaks, and I think it is a better choice in this particular case, since decimals are omitted and displaying both numbers on one line does not result in an overly wide table. — Eru·tuon 00:24, 15 September 2016 (UTC)

Temperature coloring algorithm[edit]

See my sandbox2 (permalink) for the results of an investigation into how the algorithm to calculate a background color from a temperature works. Converting some of the values in the algorithm to °F shows that it is likely the original procedure was devised for Fahrenheit—the strange fractional values are the result of converting the rounded Fahrenheit numbers to Celsius (with some peculiarities thrown in). At any rate, the basic idea is pretty simple once it is visualized in a graph. By the way, the graphs are shown as almost black, but if you edit the sandbox and show preview, they are nicely colored. Another mystery. The docs at Template:Graph:Chart mention the saved pages shows png images...but why are they broken in my sandbox? Erutuon might like to ponder the sandbox and think about what change would help for the "I wish the colors..." comment above. Johnuniq (talk) 11:20, 11 September 2016 (UTC)

The graphs are very helpful, though I actually figured out how the algorithm works by looking at Module:WeatherBoxColors, which is much clearer than {{Weather box/colt}}. I created a version of the module at Module:Weather/sandbox, using the code from WeatherBoxColors with some modifications. Test cases are currently at my sandbox. I will experiment with modifying the colors for the average temperature table. — Eru·tuon 19:19, 11 September 2016 (UTC)
Okay, I created the option of a color scheme in which black is reached at 40 °C (104 °F), which is appropriate for averages, since it's just a little higher than the average July temperature in Death Valley, which is likely the highest on earth. It can now be seen in my sandbox, linked in my last comment. — Eru·tuon 19:42, 11 September 2016 (UTC)
Experimenting is good but I was thinking of adding a feature to allow specification of a palette by name ("cool" or "pastel" or whatever) or by entering some numbers that provide the corners of the graphs—that would be four values (°C) for each of red/green/blue, making a total of 12 values. It should be quite fast. It doesn't matter for experimenting, but as a matter of interest the hex function you are using is undesirable as it has a very large overhead for a trivial operation. Johnuniq (talk) 01:53, 12 September 2016 (UTC)
So, string.format('%02X%02X%02X', red, green, blue) is a faster way of converting to hex, then? — Eru·tuon 03:06, 12 September 2016 (UTC)
I used the string.format trick and it works just fine. I don't know how to determine the processing speed of the code. I tested my new color scheme using Module:Weather/sandbox at User:Erutuon/List_of_cities_by_temperature/sandbox, and I'm fairly pleased with the result, though it may need more tweaking. — Eru·tuon 08:59, 12 September 2016 (UTC)
Lua, like many other languages, borrows ideas from C. The %X is a formatting specifier for printf (%02X displays at least two uppercase hex digits, padded on the left with a zero if necessary). I put your palettes as options in Module:Weather. We can work out what parameters should be used to invoke them later, but |palette=cool2avg can be added to the #invoke to use your "average" palette. Search for "palettes" (with "s") in the module. Johnuniq (talk) 10:40, 12 September 2016 (UTC)
Re timing, in many browsers, pressing Ctrl+U when viewing a page will show the html source for the page. At the bottom of that source is a section starting with "wgPageParseReport". It is largely mumbo-jumbo, but, for example, the "scribunto" (Lua) section for my sandbox2 shows that the module required 0.268 seconds to generate the graphs and tables on the page. It is likely that a new release of MediaWiki (in a few weeks) will display the data in a slightly more digestible form in the "Page information" link in the tools box. Johnuniq (talk) 10:52, 12 September 2016 (UTC)

I have uploaded a new version of Module:Weather with a demonstration of the new show function in my sandbox2 (permalink). The new version uses tables of numbers to define built-in palettes, so it is easy to add a paletter or change an existing one without needing to fiddle with code. The palettes are cool (default, based on Template:Weather box/colt), and cool2 and cool2avg (devised by Erutuon in Module:Weather/sandbox). See the updated documentation on the module page. Johnuniq (talk) 10:40, 12 September 2016 (UTC)

Very nice! Palettes and the show make it much easier to change and view the color scheme. I just synced cool2avg with the latest color scheme in Module:Weather/sandbox, so that I can use the show function to test it. — Eru·tuon 03:47, 13 September 2016 (UTC)
+39 °C (102 °F) and −68 °C (−90 °F) are the boundaries for average monthly temperature on Earth (the average July temperature in Death Valley and average August temperature at Vostok Station: i.e., the hottest and coldest known monthly averages, as far as I can tell), so I'm aiming to make each end of the color spectrum generated by cool2avg reach black by those points. — Eru·tuon 03:54, 13 September 2016 (UTC)
By the way, it is possible to experiment with different palette settings without needing to save anything. For example, you could edit Module:Weather to change some values. Do not save the changes. At the bottom of the edit page, paste User:Erutuon/List of cities by temperature into "Page title" under "Preview page with this module", then click "Show preview". That will show how the list of cities page would look if you were to save the changes to the module. That process can be repeated: make more changes, click "Show preview". If wanted, save the changes, or close the browser window to discard them. Johnuniq (talk) 07:34, 13 September 2016 (UTC)

I put some minor changes in Module:Weather.

  • Function show outputs Unicode minus for negative temperatures.
  • Optionally, the first and last temperatures for show can be specified, for example:

Johnuniq (talk) 10:28, 13 September 2016 (UTC)

Template:List of killings by law enforcement officers in the United States, NavBox[edit]

RE: Template:List of killings by law enforcement officers in the United States, NavBox

Could someone please help me figure out what's going on with this template?


  • It displays a "click-to-refresh", which is unconventional and also unnecessary considering we don't need up-to-the-minute figures.
  • In articles, there is no V*T*E top left for people to click and edit, so it is unmodifiable to inexperienced (most) editors.
  • There is a nested template within which looks exactly the same as the template in question.
  • Finally, the page was moved: Template:List of killings by law enforcement officers in the United States, NavBox --> Template:List of killings by law enforcement officers in the United States 2012, NavBox

Convenience links:

Couldn't this all just be, you know, simple? Thanks. :) Anna Frodesiak (talk) 01:22, 20 September 2016 (UTC)

@Anna Frodesiak: Primefac removed the refresh. I updated to show the V*T*E links and simplified {{List of killings by law enforcement officers in the United States, List}} to just have the part that was being transcluded. — JJMC89(T·C) 02:13, 20 September 2016 (UTC)
Yeah, that was all I felt comfortable with on a quick-and-dirty pass. I'll take another look when I'm more awake. Might not be worth keeping... Primefac (talk) 02:24, 20 September 2016 (UTC)
Ooft. Kept or not, it needs some serious cleanup. There are (I think) six different templates all based around the same thing? Primefac (talk) 02:44, 20 September 2016 (UTC)

Thanks all. I'll leave it in your hands. I still do not understand why one template is inside another and one is called navbox and another list. But I am not too bright when it comes to such things. Best, Anna Frodesiak (talk) 02:21, 21 September 2016 (UTC)

There are eleven "List of killings" templates, and two "Number of killings" templates (plus one "Estimates" template). I think the killings prior to '09 could probably be deleted, and the "List of" templates definitely need to be condensed. Also, pretty sure the Description template and the Estimates template violate WP:TMPG. Primefac (talk) 03:30, 21 September 2016 (UTC)
As a courtesy, I'm pinging LUOF and ProtectorServant, who seem to have created the majority of these templates. Primefac (talk) 03:31, 21 September 2016 (UTC)
Thanks, Primefac. I should have done that. Sorry LUOF and ProtectorServant! Anna Frodesiak (talk) 04:05, 21 September 2016 (UTC)


For some reason, {{GRIN}} (a reference template used in plant articles) displays a plus sign instead of a space in certain cases: when it is used without parameters, or when the parameter |taxon= is used instead of |name=. Thus, {{GRIN}} and {{GRIN|id=8780|taxon=Campanula rotundifolia}} both display as

I'm not sure how to fix this, since I can't figure out the syntax of the template. Can anyone help? — Eru·tuon 03:19, 20 September 2016 (UTC)

It looks like there is a {{replace}} call which (for some reason) is replacing spaces with +s in the pagename. It was added in this diff back in February. Pinging MCEllis (the user who made the edit) to ask why they added that template in there. Primefac (talk) 04:13, 20 September 2016 (UTC)
I have seen templates replacing spaces with plus for external links. I think it was for Google/Bing searches and possibly more. Assuming it's not needed in this template, the explanation may just be that the code was copied from somewhere where it was necessary. Johnuniq (talk) 10:31, 20 September 2016 (UTC)
Eru & Primefac, it should be fixed now. Thanks for pining me. This was caused by copying code that was meant to handle urls. I hadn't seen the problem in my testcases. MCEllis (talk) 12:33, 20 September 2016 (UTC)
@MCEllis: Thanks! Glad that it's working at last. — Eru·tuon 02:34, 21 September 2016 (UTC)


After a recent TFD, various GENUKI-related templates were merged into what is now {{Genuki}}. Originally meant to be an elink template (see Section 8 here), I found that Genuki is being used quite often as a reference. I've put a {{cite web}} version in the template's sandbox, but I'm not overly convinced about the end result. I think it might be best to leave this purely as an elink template and let people properly reference Genuki in the articles, but I figured I'd ping the project for other thoughts.

As a side note, there are a bunch of subpages for parishes that the template simply can't handle at the moment (see Rufforth#cite_note-3 and ref #9). Around about the time I start adding |fullurl= it really does seem like they'd just be better off using {{cite web}}. Primefac (talk) 02:49, 21 September 2016 (UTC)

  • As an EL Genuki is a useful collection of info about a place and links to further resources. When used as a ref it's usually just the platform where a particular piece of text is made available, usually with a source included but sometimes as a collection of snippets described as "18th-century descriptions" etc. Editors using it as a ref should be giving detailed refs not amenable to any template (the Rufforth examples seem pretty poorly cited). Perhaps add something to that effect to the template documentation and then keep well clear of references? PamD 06:36, 21 September 2016 (UTC)

Continents from countries[edit]

Following on from my previous question, is there an equivalent to {{Football demonyms}} that will return the continent when fed a country name? So Algeria maps to Africa, Argentina -> South America etc? And is there a reverse version of {{Football demonyms}} or {{Demonym country}} that returns a country when fed a demonym (ie Albanian -> Albania etc)? I know I could write my own but it seems sensible to have a single version for updating purposes (and it saves me a bit of work... <g>) Le Deluge (talk) 19:58, 21 September 2016 (UTC)

To answer your questions: I am not aware of either of those templates existing. I have to wonder, however, why you would need either of those. I can understand football because it's used in some infoboxes to automatically generate previous/next season wikilinks. I'm genuinely curious, mind you, and knowing where these templates would be used might also help in figuring out the best way to code them. Primefac (talk) 23:48, 25 September 2016 (UTC)
@Primefac:By way of background, I've been doing a lot of clearing of red-linked categories lately, and one type of category that I often find myself creating are the (2015-16 in X) type sport categories of which we produce about 500 per year. Even if one can clone the contents from a previous year, they're still a bit fiddly to do - just adapting a Catpair navigation to the previous and succeeding seasons means changing four different years, plus several annual categories. I also find myself creating a lot of categories that use {{Category U.S. State elections by year}} which is intelligent enough not to need any parameters as it gets all it needs from PAGENAME - it makes it soooo much quicker as you can just throw a list of categories at AWB without manually tweaking each one for every mention of a year. Phase I resulted in {{Navseasoncats}}, a navigation bar for these kinds of categories as seen in eg Category:2001–02 in Indian football. I now want to go to Phase II and have a parameter-free template that includes all the appropriate categories as well as {{Navseasoncats}}. As you'll see from that example, categories include Category:2001 in Asian football, Category:2002 in Asian football and 2001–02 in Asian football by country so I need the template to figure out that "Indian" in the PAGENAME translates to "Asian" categories. Other categories need to take that demonym in PAGENAME and translate it into a country, for instance Category:2016–17 in German football cups is in Category:Football cup competitions in Germany by season. I'm not sure I'll accommodate all the variations, but getting (season in demonym sport/football/basketball/soccer/futsal/ice hockey) would be a really useful start,it would apply to hundreds of categories a year. Does that clarify things? Le Deluge (talk) 22:06, 3 October 2016 (UTC)
Okay, I've read over what you've written three times, and I think you're trying way too hard to make this way too complicated. That being said...
  • as far as linking to previous/next seasons - I think it's completely possible to have one parameter-free template that will look at a the cat name and be able to figure out how to add the appropriate links. Granted, it will be a pain in the arse to code and most likely involve Lua, but it's doable.
  • your cat idea is quite grand, and you would most definitely have to make a few demonym templates in order to accomplish that. The simplest, obviously, would be small tweaks on the method used by {{year by category}}, since clearly Category:2001 in Asian football belongs in Category:Years in Asian football (replace the date with "Years" and sort by the date; easy). You're definitely going to have issues finding every cat something could fall into (per your German example).
All in all, it would be a ton of work, but not impossible. I know categorization is super-important, but I'm honestly not sure how much categorization is required. I'm going to ask for some input from WP:CATP on this thread (and of course we at WT:WPT are always happy to provide input/assistance). Primefac (talk) 02:51, 4 October 2016 (UTC)
I think you're trying way too hard to make this way too complicated Quite possibly.<g> But looking at it from the other end, I really appreciate how a "complicated"/intelligent template makes things so much easier from a user point of view, so I'm prepared for some pain in the template design stage in order to make it as user-friendly as possible. {{Navseasoncats}} was Phase I, a template that does all the cats for the "easy" ones ie (season in demonym sport/football/basketball/soccer/futsal/ice hockey) is Phase II and possibly phase III, then things like the German example above are very optional or Phase IV. Season in demonyn sport or season in demonym football/soccer are relatively "tight" in their categorisation, it's the leagues which may spiral out of control but I'm not absolute about doing them. So it comes back to the original question - are there any country->continent or demonym->country functions already out there? Le Deluge (talk) 22:12, 11 October 2016 (UTC)

A set of clock templates[edit]

Could I please get a second/third/fourth opinion on {{analog clock 2}}, {{analog clock 3}}, and {{analog clock 4}}? On the surface they seem like reasonable clocks, but looking at the code makes me want to burn it with fire. Am I just being overly critical? Primefac (talk) 18:20, 25 September 2016 (UTC)

@Primefac: I can't understand the code, but all these complex templates seem like they should be converted to a module... for instance, it would allow all the complex code in {{Analog_clock_2/Working}} to be generated rather simply. It's somewhat admirable, but quite crazy, to do it with template code. — Eru·tuon 05:14, 3 October 2016 (UTC)
Erutuon, the long and the short is that /Working creates a bunch of circles in specific spots to make the hands of the clock. In the case of clock 3, it draws every pixel of the clock hands, which is something like 120 pixels between the two hands. I'm not sure what a module would do other than move the code itself off the template page (which is sorta what /Working does for 2 and 4). Primefac (talk) 05:30, 3 October 2016 (UTC)
@Primefac: Well, what I was thinking was that a module could cut down the repetitiveness and make it easier to change things. But the way the templates generate the hands is kind of silly, and I wonder if there's not a better way to do it... I made a clock using JavaScript and an HTML canvas (starting from an example online, since I'm not great at programming), but that may not be possible (at least the JS part) on Wikipedia. — Eru·tuon 05:44, 3 October 2016 (UTC)
Making a clock template doesn't make much sense, even from a module, in my opinion. The reason is that the clock wouldn't show the current time - it would show the time that the page was last rendered, which might be months ago. Even if you managed to disable caching to make the clock display the time the page was viewed, the clock hands wouldn't move - it would get less and less accurate the longer you viewed the page. A clock gadget written in JavaScript wouldn't suffer from these problems, but it would have to be a default-on gadget for all users to be able to see it, and I'm not sure that would be approved by the community. There is already an opt-in digital clock gadget on the gadgets page in preferences, though, which works very well. — Mr. Stradivarius ♪ talk ♪ 23:29, 3 October 2016 (UTC)
By the way, it's actually the HTML part that isn't possible on Wikipedia - you can't load HTML documents onto Wikipedia pages (at least not directly), but you can add extra JavaScript and CSS. If you make a clock gadget in JavaScript/CSS that doesn't use HTML directly, then it should work. — Mr. Stradivarius ♪ talk ♪ 23:42, 3 October 2016 (UTC)
I've just nominated them all for deletion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:30, 12 October 2016 (UTC)

Problem with Module:eFloras[edit]

I created Module:eFloras to generate values for {{citation}}, which is used in the reference template {{eFloras}}. It takes family names and generates volume numbers, and I am trying to get it to take flora_ids and generate flora names. Anyway, I'm running into a weird problem, which can be seen in Template:EFloras/sandbox/testcases. The flora_ids that are actually in the module are not being recognized. It must be some kind of basic error, and maybe I'll figure it out, but I'm concerned that maybe it's a problem related to the modules that {{citation}} uses, in which case I won't be able to fix it. — Eru·tuon 23:46, 1 October 2016 (UTC)

Oh, humph. It's probably just because of whitespace being handed to the template through numbered parameters. Never mind. — Eru·tuon 23:48, 1 October 2016 (UTC)
Yep. Problem solved. — Eru·tuon 23:51, 1 October 2016 (UTC)

Template display discussion[edit]

This is a cross-post to inform the project that there is a template discussion occurring at WT:AST regarding a set of templates in their purview. Input there would be appreciated. Primefac (talk) 03:44, 3 October 2016 (UTC)

Adding page protection notification to templates[edit]

There is a discussion at the WP Banner Shell template talk page about adding page protection notifications (the little lock) into the template. Your input is requested. Primefac (talk) 16:30, 8 October 2016 (UTC)

Failure of templates applying NOINDEX and probably other __magicwords__[edit]

Several templates attempt to apply __NOINDEX__ to hide problem-pages from search engines. It has just been discovered that this doesn't work. The pages don't actually get NOINDEXed. It seems likely that all __magicwords__ are being dropped from transclusion. A WMF staffer is currently looking into this. It will likely get fixed.

I have also posted this to WP:Village_pump_(technical)#Failure_of_templates_applying_NOINDEX_and_probably_other_magicwords. If anyone wants to discuss this, I suggest doing so on that page, to keep discussion centralized to one location. Alsee (talk) 21:25, 11 October 2016 (UTC)

It turns out the issue was unrelated to templates. NOINDEX is currently disabled in article space. Alsee (talk) 12:52, 12 October 2016 (UTC)

Making warning templates visible on mobile[edit]

I raised this as a village pump proposal last month: changing some warning templates - like {{hoax}} and {{afd}} - so that they become visible on mobile. (At the moment, all problem templates are condensed to an ignorable grey-text "Page issues" on the mobile view, even for something as ominous as an AfD'd medical advice hoax.) The templates would have to be cut down for size, perhaps only displaying the "issue=" field of the amboxes.

The proposal received unanimous support for {{hoax}} and broad support for some other templates, so I'm bringing it here to see how technically possible this would be. Is this something that can be implemented at the template level? --McGeddon (talk) 10:08, 14 October 2016 (UTC)

Need to bounce around some thoughts[edit]

Okay, so I'm getting sucked into merging {{}} and {{runeberg}} with the intention of having some sort of {{cite book}} wrapper at the end of it all. The latter was dead easy to convert (almost making me wonder why we keep it), but the former is a bit more of pain. I'm seeing somewhere in the order of 300 different possibilities for what the template could chuck out. So... I'm thinking there are a few different options:

  1. Go through the 38 transclusions of the template and manually add in the author/book/year information that's coded into the gigantic #switch statement, turning them all completely into {{runeberg}}-compatible pages.
  2. Convert each line of the #switch into its own {{cite book}} wrapper
  3. Stick the relevant information from each #switch line (author/title/date/etc) into a subpage, where those parameters would be called based on what was passed through {{{1}}}. For example, instead of having | svcohrs = [1] in Edvard Cohrs, Cohrs' atlas över Sverige (1928) I would pass "svcohrs" to the subpage and get back |origdate=1928|last=Cohrs|first=Edvard|title=Cohrs' atlas över Sverige|chapter={{{2}}}. This would be plugged directly into {{cite book}}. It will also make the main template code a lot cleaner.
  4. Nominate both templates for deletion (nuke 'em all) per this comment about its uselessness.

Options 2 and 3 are pretty much the same, it's just a question of where the information is kept, so I'm a bit torn on the best/easiest way to proceed. #3 avoids redundancy (no need to type out "cite book" 300 times), but #2 is a bit easier to see everything at once. #1 seems like a bit of a copout (besides, having a {{cite web}} wrapper with one unique parameter is hardly worth keeping), as does #4. Thoughts? Primefac (talk) 03:14, 19 October 2016 (UTC)

I would go with #1. Citation data shouldn't be stored in templates – various citations templates, including {{cite doi}}, {{cite pmid}}, and {{cite isbn}}, were deprecated for that reason. — JJMC89(T·C) 04:15, 19 October 2016 (UTC)