Template talk:Sort/Archive 1

Archive 1

Archive 2

Sort keys in general

Starting the discussion here since there seem to be a number of attempts to create sortkeys for the sortable wikitable:

• {{Sortname}}
• {{Sortablename}}
• {{Sortable date}}

More? We should find a common system before we roll these out. ~ trialsanderrors 20:44, 2 April 2007 (UTC)

Agreed. I didn't even know about "sortname" when I wrote "sortablename", and of course, they are awfully similar (order of parameters is swapped). A common naming scheme ought to be adopted — "sortable name" might be the best bet, corresponding to "sortable date" and any others that make sense. Links from m:Help:Sorting might be a good idea. Andrwsc 20:59, 2 April 2007 (UTC)

I would recommend Template:Sortable foo as the name for the template, with a redirect from Template:Sortfoo so that the entry in the table can be kept as short as possible. Also, we should add a third variable article name for the cases where Firstname Lastname doesn't link to the actual article. ~ trialsanderrors 21:43, 2 April 2007 (UTC)

That was one enhancement I had considered but not yet added to sortablename, so I would certainly agree with that idea. Andrwsc 21:56, 2 April 2007 (UTC)

We should also add these to the list of templates to be consolidated/refined/etc.:

• {{Sort}}
• {{Sortkey}}
• {{Hiddenkey}}

Fortunately, none of these six (or more) templates is used by more than a small handful of pages, so it should be easy to sort this out (pardon the pun) before things get too confusing to fix. Andrwsc 22:08, 2 April 2007 (UTC)

Found one more: {{dts}}. ~ trialsanderrors 22:28, 2 April 2007 (UTC)

So looking over the ones we found they essentially seem to be doing the same thing:

1. hidden text (sortable)
2. displayed text
3. link to article

3 should default to 2, and 2 should default to 1. So a command {{sort|1757-05-25}} should sort properly by year-month-day and display in the preferred date format. On the other hand a link to David Lee (physicist) would have to be encoded {{sort|Lee David|David Lee|David Lee (physicist)}}. This would make different templates for different types of sortkeys unnecessary. ~ trialsanderrors 23:34, 2 April 2007 (UTC)

Perhaps it is unnecessary to have a seperate template to handle names, but it is less awkward. The idea that I had with this template (and that Smartskaft had with sortname about a week earlier) is that you should only have to include the first and last names only once each in the template call (or twice, if a dab page is involved) instead of 2 (or 3) times as in your example. Andrwsc 00:01, 3 April 2007 (UTC)

I realize there is a trade-off between simplicity of template and number of templates. One way to solve this might be to use {{sortname}} to call on {{sort}}: {{sortname|First|Last}} = {{sort|Last First|First Last}}. ~ trialsanderrors 00:34, 3 April 2007 (UTC)

I've updated this template so that you would use {{sortablename|Lee|David|David Lee (physicist)}}, which is a bit better. Andrwsc 23:31, 3 April 2007 (UTC)

Sort

I know I made it, but... i'd like to suggest that any other of these use {{sort}} as a meta-template so that if a more refined way of doing sorting emerges in the future it can be changed and the rest will automatically be updated. --Random832 19:33, 3 April 2007 (UTC)

Note also that this template was not intended to handle linking automatically, only the display of hidden text and visible text, which visible text may contain links. That change was made later by someone else. --Random832 19:35, 3 April 2007 (UTC)

I think it is a good idea to use "sort" as a meta-template so that the hidden CSS stuff is only present in a single spot. however, as you point out, the link additions made by trialsanderrors needs to be reverted so that "sortable name" etc. can be structured as intended. Andrwsc 19:51, 3 April 2007 (UTC)

Feel free to revert. In essence I see two possible formats: {{sort|hiddentext|displayedtext}}, with displayedtext in wikibrackets if it links to an article (incl. possible pipe), or {{sort|hiddentext|displayedtext|linktoarticle}}, where linktoarticle can be set to a placeholder, say #, if there should be no link. The various versions of sortdate are more problematic in my opinion, since {{sort|2007-04-03}} is far simpler to code and does the job. ~ trialsanderrors 20:31, 3 April 2007 (UTC)

In looking at the handful of pages that use these templates, I noticed a few things:

• I think the correct template to use as a meta-template to render the hidden CSS is probably {{sortkey}} instead of {{sort}}. The most "atomic" operation here is to render a sortkey — the wikilinks are different in each case. On List of Oklahoma numbered highways, the required sort key is quite different from what is actually rendered in each row, which includes images in most instances. On List of U.S. states by population, the population column needs a sort key to handle the comma separators, but those figures are not wikilinked, so it doesn't make sense to fold the wikilink rendering into the "root template".
• In parallel with {{dts}}, I also found {{nts}}, which I used on the US states table to replace "sort". This template is also used from a redirect name of {{commas}}.
• With respect to the date templates, you can't use the "default pipe trick" that you have in the most recent version of {{sort}} before I reverted, as the extra pipe link in the expanded template causes the user-preference for dates not to work. Also, it forces users to conform to a specific date style when writing wikicode, contrary to MOS:DATE.

Therefore, I'd propose the following:

1. Leave {{dts}} and {{nts}} alone since they are slightly more widely used. Perhaps use {{sortdate}} and {{sortnum}} as new names for them, with redirects for backward compatibility.
2. Use {{sortname}} as the name for the version that handles names. Use the (now updated) syntax of this template.
3. Use {{sortkey}} as a meta-template for all of the above.

Comments? Andrwsc 23:14, 3 April 2007 (UTC)

OK, quick summary of what I think we're trying to achive:

1. Create a small set of templates that deal with different types of data formats: general, name, date, number, hidden key.
2. Make data input easy, e.g. avoid redundant entry of info: {{sortname|Ames|Lee}} is preferred over {{sort|Lee, Ames|Ames Lee}}.
3. Use one template as meta-template and create variants for individual data types. (The meta-template should work for the "general" data type.)
4. Keep template names short and intuitive.

The {{dts}}/{{nts}}/{{ntsh}} class doesn't strike me as very intuitive, both in name and coding. I don't think it's that hard to change the existing tables with a text editor or Excel spreadheet, so we don't have to keep them because they're rolled out already. The {{sortkey}} template seems to work as a meta-template for {{hiddenkey}}, but it's not very powerful. In its simplest form, {{sort|text}} should produce "text" as sortkey and display text wikilinked. I think {{sort}} is currently closer to achieving this, plus it has the better name. ~ trialsanderrors 23:57, 3 April 2007 (UTC)

I agree with all four goals. As for the specifics, what don't you like about {{dts}} and {{nts}} with respect to their calling conventions? I agree that the names are too terse and somewhat meaningless, but other than a name change, is there anything else you think needs to be done to them?

As for {{sort}}, I just don't see the need for it as you suggest here. The sortable table class already works with arbitrary text strings, so there is no need to put a wrapper around most strings. Only the three "problematic" data types need a template wrapper (namely: dates, numbers that span multiple orders of magnitude and/or have separators, and names that need to be sorted last name first). Therefore, I don't see any need for the {{sort|text}} syntax. If you specify two parameters (e.g. {{sort|key|display}}), I think it is clearer with a template that does the sort key only (e.g. {{sortkey|key}} [[display]]) Or am I missing something? Take a look at how List of Oklahoma numbered highways is written. (This is the one remaining page that uses {{sort}}, by the way.) Table cells are now coded like:

{{sort|001|[[Image:Oklahoma State Highway 1.svg|20px]] [[Oklahoma State Highway 1|OK-1]]}}

In my opinion, there is no need to include the image and wikilink inside the template call. Nothing from that second argument is needed by the template code. That sequence would be more clearly written as:

{{sortkey|001}} [[Image:Oklahoma State Highway 1.svg|20px]] [[Oklahoma State Highway 1|OK-1]]

Of course, if we deprecate the current definition of {{sort}}, we could use that template name for the function I propose here, which is the rendering of the sort key only. Thanks for the feedback, Andrwsc 00:28, 4 April 2007 (UTC)

I haven't looked at {{nts}} yet but {{dts}} is just unnecessary. I just converted the dates in European Council#Current composition of the European Council from dts to sort using ISO date formats. So if all dates are complete there is no need for {{sortdate}} at all. The only reason to implement sortdate, if at all, is for incomplete dates: 1st Quarter 1994; Dec ??, 2003; etc. This is currently done by {{TBA}}. I have to think more about sort vs. sortkey, but I agree about naming conventions:

• sort should be the name of the meta-template and contain the documentation
  • sortname, sortnum, sortdate, sortkey should be the names for specialized templates (sortkey is for hidden keys).

I'll get back to you about sort vs. sortkey. ~ trialsanderrors 01:22, 4 April 2007 (UTC)

I certainly agree that your use of {{sort}} instead of {{dts}} is more elegant, but I'm hesitant to say we should enforce that switch. The big difference between the two templates is that dts allows the editor to write dates in a more readable format (e.g. {{dts|3|April|2007}} instead of {{sort|2007-04-03}}), and it will render the dates as "April 3, 2007" instead of in ISO 8601 format ("2007-04-03") for non-registered users. MOS:DATE suggests that ISO format is useful for tables, but doesn't mandate it. It might be a bad idea to force users to write dates (for sortable tables) in a style they do not want to. Andrwsc 03:54, 4 April 2007 (UTC)

OK, I'm writing this in pseudocode to make this a bit more readable than wikicode. I hope that works. My suggestions:

• sortkey creates the hidden key and nothing else:

sortkey(1) = <hidden>1</hidden>

• sort is the generic form with wikilinks:

sort(1,2,3) = sortkey(1) [[3|2]]

where 3 defaults to 2 and 2 to 1.

• sortnum adds thousands separators to numbers, and possibly an exponent. This is what {{nts}} does now.

sortnum(50000) = sortkey(&&&&50000) 50,000

• sortdate allows for date entries in DD|MMM|YYYY form. This is what {{dts}} does now. {{sortable date}} is far too cumbersome and should be scrapped.

sortdate(DD|MMM|YYYY) = sort(YYYY-MMM-DD)

• sortname switches the order of variables and optionally adds a link target.

sortname(1|2|3) = sortkey(2 1) [[3|1 2]]

where 3 defaults to 1 2.

Technically we don't need sort, but it's nice to have for the ISO date function alone. ~ trialsanderrors 04:36, 4 April 2007 (UTC)

I think you and I are almost in full alignment. I think the only thing I slightly disagree with is the order of parameters of sortname. When I wrote {{sortablename}}, I thought that putting the last name first (e.g. {{sortablename|Blair|Tony}}) helped to reinforce the idea that the sort order would be last name first. Do you feel strongly about keeping the template parameters in "reading order"? Andrwsc 15:48, 4 April 2007 (UTC)

Oh, one more thing. sort as you've defined it above (with the third parameter) won't work on ISO dates. Once you add the pipe in the wikilink, even if both strings are the same, the MediaWiki auto-formatting breaks. For example, [[2007-04-04|2007-04-04]] renders as 2007-04-04. Without the pipe, [[2007-04-04]] renders as 2007-04-04.Andrwsc 15:53, 4 April 2007 (UTC)

Do I feel strongly about it? Not personally, as I will probably not be the person to convert old tables into sortable format. Just for those who do, changing Tony Blair into |Tony|Blair}} is much simpler than |Blair|Tony}}. Like sortdate (dts), |Tony|Blair}} also conforms to the natural way of writing. Good point on the pipe and ISO format. I don't expect the templates actually to be encoded the way I did it above. The pipe vs ISO problem could be solved (I believe) with an #if statement. ~ trialsanderrors 18:33, 4 April 2007 (UTC)

An explanation of {{sort}}

The idea was to have the "hidden string" code defined all in ONE place, so that if mediawiki is in the future altered to allow a way to define sort keys in a way that does _not_ look ugly on browsers that lack CSS support (say, by allowing the content to be in a span with a title attribute), this can be changed. --Random832 03:32, 4 April 2007 (UTC)

Oh, I think we completely understand that! I think the current discussion is about whether or not that specific template should have a second argument or not, and about what form the proposed "root" meta-template should be for the name/date/number specific templates. Or at least, that's what I think we're discussing...  ;) Andrwsc 03:41, 4 April 2007 (UTC)

Well - I'd also been specifically speculating that such a future mechanism might require the visible text to be surrounded in a tag (in which case it would need to be an argument to the template) - and is it so hard to use {{!}}? --Random832 12:39, 4 April 2007 (UTC)

You've got a good point - I hadn't thought of that. My issue was not so much about the difficulty (or lack thereof) of that extra argument, but of the simplicity of not needing it. You're proposing that sortkey as defined above may be insufficient as the root meta-template because it does not span the whole string. That would imply that sort ought to revert to your version without and wikilinking. Andrwsc 18:00, 4 April 2007 (UTC)

I can see sort becoming useful in other ways too. For instance, if we want to avoid redlink deluge and create a template that only creates a wikilink if there is a target. So I wouldn't throw it out just yet. ~ trialsanderrors 18:33, 4 April 2007 (UTC)

One case where {{sort}} could possibly be useful is the Title column in the European Council example. With the hidden key, I set prime minister, chancellor and taoiseach equal to each other since they're equivalent positions. Now if the hidden key is the only sort key the listings should otherwise be sorted by the previous sorting criterion. So I would get Austria/Belgium/Bulgaria rather than Austria/Germany/Belgium (starting from the initial order). I wonder if it's possible to exclude the visible text from the sort key with a tag? ~ trialsanderrors 21:08, 4 April 2007 (UTC)

Template moved

I have replaced all references to sortablename with sortname, as that seems to be the preferred name. I have also merged the template and this talk page under sortname. Andrwsc 00:18, 5 April 2007 (UTC)

OK. I pretty much informed everybody who worked on a sort template about the discussion here but only the three of us seem to have an ongoing interest in it. I'd say if we are in general agreement on naming conventions and basic functionality we should post them on Help talk:Sorting and wait a day or two for feedback before we implement them. ~ trialsanderrors 01:16, 5 April 2007 (UTC)

Sounds good. I's also drop a note on Template talk:dts and Template talk:dts. Andrwsc 02:24, 5 April 2007 (UTC)

Thanks for the note about this discussion trialsanderrors. Good initiative to try and bring some order in the various sort templates. Until now, the discussion didn’t trigger my “I-have-to-state-my-opinion-here” yet (that basically means I think you guys are doing a fine job without my input :D). The only things I could add are:

• Should the sort routine coders be involved? [1][2] Implement some of the template purposes into the sort code. I’m thinking specifically about an extended number format recognition in the routine (à la Excel, void the need of {{nts}})--Van helsing 08:29, 5 April 2007 (UTC)

  Getting the sort routine coders in on this would be great. really, the _best_ solution would be to have some way of sorting other than on text content, like, some attribute of some "magic" element within the table (an empty span with class 'sortkey' and a given title?) --Random832 18:53, 5 April 2007 (UTC)

• The sort templates information should eventually be easily and centralized available for the editors (Help:sorting) (not surprising, purpose of this discussion)

--Van helsing 08:29, 5 April 2007 (UTC)

I moved the talk page only to Template talk:Sort and set redirects or notifications on the other talk pages. I also try to invite everybody who has worked on sortkeys/sortable tables before. This is still pretty disconnected, so whenever you find something please report here or invite them to join. ~ trialsanderrors 09:09, 5 April 2007 (UTC)

I posted to VPT a couple days ago. --Random832 18:51, 5 April 2007 (UTC)

{{sortkey}}

should visible=no by default? (and, can someone explain why visible should even be supported? it might be nice to get .sortkey{display:none} added to common.css at some point) should punctuation be added to force alphabetic sorting and to make it look reasonable in non-css browsers? --Random832 19:00, 5 April 2007 (UTC)

I don't see a use for the visible parameter at all. What's the purpose of the "sortkey" and "sorttext" classes? Are they defined anywhere yet? ~ trialsanderrors 20:03, 5 April 2007 (UTC)

Yeah, agreed. The other sort templates all assume "display:none" all the time. Sortkey was not in use other than on User:TimR's test pages when I found it and added it to this discussion here. I do not think the "visible" argument is needed. Andrwsc 20:10, 5 April 2007 (UTC)

For templates producing a hidden part it is very useful to have a debug mode where the hidden part is made visible. For this purpose they could call sortkey with a parameter visible=yes, or they could, depending on the mode, call sortkey or, say, "Template:Visible sortkey".--Patrick 11:32, 12 April 2007 (UTC)

{{TBA}}

Q1 should sort before dates in april, shouldn't it? Maybe have 2007-Q1 and plain 2007 become 2007-01-00, 2007-Q2 can be 2007-03-00, Q3 can be 2007-06-00, etc --Random832 03:36, 4 April 2007 (UTC)

Hmm, yes. But that would sort "2007" or "2007 Q1" before "January 2, 2007". That might be technically correct, but on lists like List of Wii games, it's just confusing. I'd rather list "2007" at the end of that year, and "2007 Q1" at the end of that quarter. --Conti|✉ 14:56, 4 April 2007 (UTC)

then have it be march 32, june 32, september 32, and december 32. Should Q4 sort before the year? then maybe have one be 33 the other 32. --Random832 19:23, 5 April 2007 (UTC)

Generally Q1, Q2, H1, H2 etc. should be sorted at the end of the term, so it should default to 2007-03-32 etc. A simple way to fold this into sortdate would be change the order of entry: 2007|Jan|21 instead of 21|Jan|2007. That was we could simply default to 2007|Q|1 = 2007-03-32, 2007|H|1 = 2007-06-32, 2007 = 2007-12-32. Not sure if we want to do this though since we want to keep entry format as intuitive as possible. ~ Trialsanderrors 20:09, 5 April 2007 (UTC)

Q1-Q4 should sort properly now. --Conti|✉ 23:52, 5 April 2007 (UTC)

I would expect a year to be sorted at the beginning of the year, and similarly for months, quarters, etc.--Patrick 08:32, 6 April 2007 (UTC)

#time also takes the start of the period: {{#time:c|April 2007}} → 2007-04-01T00:00:00+00:00. --Patrick 10:16, 6 April 2007 (UTC)

Yes. As I said, that's technically correct. But have a look at List of Wii games for example: Games that are expected to come out this year would sort before games that already were released if the template would work as you expected. The whole point of the template is to prevent this, so that our readers first see the games with a precise release date, then the vague ones like "2007". --Conti|✉ 15:31, 6 April 2007 (UTC)

Perhaps we need a parameter, or two versions of the template, to allow both depending on the application.--Patrick 16:54, 6 April 2007 (UTC)

That would be possible of course. Do you have an example of a sortable table where such dates should be sorted in the technically correct way? --Conti|✉ 18:51, 6 April 2007 (UTC)

It seems more natural in a column of birthdates and dates of past events, where sometimes only a year or a year and a month are given because the exact date is not known. One tends to associate a date in e.g. 2005 with a fraction being added to the number 2005, so just 2005 is less. An example on Ontoworld is [3], on Wikipedia there are also such lists.--Patrick 00:00, 7 April 2007 (UTC)

Yep, that makes sense. I'm going to add a parameter that makes this possible. If the template is used for lists like these, it should probably be moved to a more appropriate name, too. --Conti|✉ 18:38, 7 April 2007 (UTC)

What does everyone think of this proposed method for date keys

{{#time:YmdHis|{{{1}}}}} would automatically parse whatever is passed to it in any date format and make a YYYYMMDDHHMMSS key.

Very elegant way to create the sort key for {{sortdate}}, but I still think we need to separate the year so that we can create the wikilink as per MediaWiki syntax. I've used your idea to start on sortdate, and it works nicely with three different input argument styles, and follows the user's preferences nicely. I have "turned on" the sort key at the moment so you can see it below:

• {{sortdate|5 April|2007}} →
• {{sortdate|April 5|2007}} →
• {{sortdate|2007-04-05}} → April 5, 2007

It looks like the hours/minutes/seconds are not needed, or do you have additional syntax in mind? Andrwsc 00:06, 6 April 2007 (UTC)

This is excellent. Any chance to incorporate the {{TBA}} functionality? If I read this correctly we can redirect {{dts}} to {{sortdate}} without disruption now. ~ trialsanderrors 03:51, 6 April 2007 (UTC)

For the hours, minutes, seconds, there's no real reason not to since it's hidden, and this way tables with times can be sorted with the same key. --Random832 04:28, 6 April 2007 (UTC)

Also, the year doesn't have to be separated for the magic to work. {{#time:Ymd|{{{1}}}}}{{#time:[[j F]] [[Y]]|{{{1}}}}} results in 2024112424 November 2024. The point of this is to make it so that a freeform argument can be used and it will automatically create the timestamp in both sortable and human-readable format (the latter which i left out of the example). What I'm not sure about is how to add Q1 etc functionality to it. I'll consider this some more, for now i suppose we can continue to use TBA. --Random832 04:33, 6 April 2007 (UTC)

Anyway, the point is there is no additional syntax necessary (note that for dts compatibility it supports arbitrarily breaking up the time into three arguments)

• {{sortdate|31 January|2007}}
• {{sortdate|January|31|2007}}
• {{sortdate|2007-01-31}} January 31, 2007
• {{sortdate|yesterday}}
• {{sortdate|2007-04-05 01:00}}
• {{sortdate|2007-04-05 01:00 -0400}}

Comments

To be honest, I'm not entirely pleased with the recent changes to sortdate. One thing I really liked about the original version I had up today was the way it worked when the "No preference" selection was made on the Date and time user preferences. Of course, this is also the default mode for non-registered users too. In the earlier version, the output "followed" the author's original intent. With the current version, the output defaults to one specific format (of the four options available):

Template call	Current output	"Old" output
{{sortdate|6 April|2007}}	6 April 2007	6 April 2007
{{sortdate|April 6|2007}}	6 April 2007	April 6, 2007
{{sortdate|2007-04-06}}	6 April 2007	2007-04-06

(Of course, both versions do the same thing (the right thing) when a registered user has set one of the other four date & time preferences.)

I don't like the idea of "forcing" a default output. I'd much rather have this set of templates adopt a similar syntax to the basic wikicode that they replace, and produce the same output (plus the invisible sort key). This is what we did with {{sortname}}:

• {{sortname|Jimmy|Wales}} instead of [[Jimmy Wales]]
• {{sortname|John|Smith|John Smith (footballer)}} instead of [[John Smith|John Smith (footballer)]]

so therefore,

• {{sortdate|6 April|2007}} instead of [[6 April]] [[2007]]
• {{sortdate|April 6|2007}} instead of [[April 6]], [[2007]]
• {{sortdate|2007-04-06}} instead of [[2007-04-06]]

Does anyone concur with this? Andrwsc 06:04, 6 April 2007 (UTC)

• I didn't notice the change but I agree that the output style should default to the input style but be wikilinked to allow for individual preferences to override it. ~ trialsanderrors 06:17, 6 April 2007 (UTC)

A serious limitation of #time is that it only works for dates from 1970:

• {{sortdate|5 April|1967}} → 5 April 1967
• {{sortdate|5 April|1867}} → 5 April 1867

Patrick 09:34, 6 April 2007 (UTC)

The 1970 thing is a dealbreaker, and if I'd realized this I'd never have suggested this. But do you seriously think there's a benefit to non-logged-in users seeing a hodgepodge of different date formats in a single table? Cite templates require ISO input for the access date for, one assumes, this very reason. (also I don't understand how, without #time which we now know is unworkable, "5 April" is supposed to translate to 04-05 for the sort key, can someone explain it to me?) --Random832 15:20, 6 April 2007 (UTC)

Well, I'm obviously a fully-registered user, and I purposefully have my preference for date & time set to "No preference". I want to see what the original authors used. Regardless, I think the larger issue is on the editing side, not the display side. We shouldn't be over-riding editors' personal authoring preferences with one specific style if we don't have to. The MediaWiki software is clever enough to allow authors to write dates in several different styles, not just to display them with your personal preference, and we shouldn't drop that capability.

And yeah, we obviously need this to work for pre-1970, so back to a dts-style implementation, I guess. Andrwsc 15:32, 6 April 2007 (UTC)

Hmm, I wonder where the restriction to 1970 and later comes from with #time, and whether it's fixable on the coding side. ~ trialsanderrors 17:39, 6 April 2007 (UTC)

It's obviously a Unix/POSIX thing, since the time epoch for those systems is 1970. Unless the implementation is changed to use something other than the C standard library routines for time_t, I think we're more likely to solve it in the template code. Andrwsc 17:43, 6 April 2007 (UTC)

Status?

Are we ready to merge/redirect the templates, and to create a (central) documentation? ~ trialsanderrors 23:41, 9 April 2007 (UTC)

Dates

I expanded Template:dts (backlinks edit) (works now for years BC too, and provides leading zeros for years). Template:TBA (backlinks edit) should be kept too, because it allows quarters, and allows sorting of time periods by end date. I have no plans to merge the two, to make it not too complicated, but that could be done. Template:sortdate (backlinks edit) seems no longer needed.--Patrick 10:06, 14 April 2007 (UTC)

I noticed that {{dts}} has a leading 0 whereas {{sortdate}} doesn't. These should be brought inline with each other so they can at least be used interchangeably in the same table. I ran into this while converting YYYY-MM-DD to sortdate, but had some dates with missing days or months, and I couldn't use 2008-05-?? so I used dts, but then it didn't sort properly and I had to change it all to dts. —Wikibarista 23:00, 18 April 2007 (UTC)

I added a zero in Template:sortdate.--Patrick 19:45, 30 April 2007 (UTC)

Numbers

I fixed the sorting of numbers with thousands separators in numeric sorting mode [4] . Therefore the workaround with alphabetic sorting mode with Template:nts (backlinks edit) is no longer needed, except for special cases.--Patrick 10:31, 14 April 2007 (UTC)

{{nts}} not sorting correctly for values less than 1

We are using {{nts}} in a sortable table with land areas. Some of the land areas are less than one square mile and do not sort correctly. The table is for municipalities in Lycoming County, Pennsylvania at User:Dincher/Woodchuck. There are also areas in square kilometers following the square miles. We do not use nts on the metric units, but we have used nts on just the english units (and not the metric) in List of Pennsylvania state parks and that worked fine. Any suggestions or help would be appreciated. Thanks in advance, Ruhrfisch _><>°^° 00:19, 23 May 2007 (UTC)

In World's largest software companies I've added class="sortable" to the table. The standard version then has a problem sorting the profits column, where it sorts 2.88 before 13.06. When I added {{nts}} to the values, the result was even worse. In particular, values like 279.02 had sortkeys like <span style="display:none">&&&&&&&&&&&&&279.&20000</span>, that is "&" instead of "0" after the decimal point, or 0.96 had <span style="display:none">0.960000</span>, that is no formatting at all. This was with Firefox 2.0.3 under Windows, if it makes any difference (which seems unlikely for the {{nts}} problems). --S.K. 11:37, 24 May 2007 (UTC)

I fixed Template:nts (backlinks edit), creating a workaround for a bug in the leftpad function. It should work now for positive numbers. In a column using nts negative numbers can be fixed by directly putting a suitable sort key instead of caling nts.

In the case of plain numbers, sorting without the need of the template has the problem that with a negative number at the top sorting mode is alphabetic. This can be fixed by copying m:MediaWiki:Common.js to Wikipedia. --Patrick 19:48, 26 May 2007 (UTC)

Thanks very much - that fixed the problem and it sorts correctly now. We appreciate the help very much, Ruhrfisch _><>°^° 02:36, 27 May 2007 (UTC)

I have found (trying to sort 0.21 and 0.02) that the problem was not really in the leftpad function - there is some strange behaviour of #expr. Please see my test page and look at last round gone rows - values seem to be correct only for some input values. I have committed a workaround using #ifexpr - it's certainly not perfect but fixes the zero problem without breaking numbers less than one.  « Saper // @talk »  22:47, 15 July 2007 (UTC)

I fixed that: a blank space is needed, otherwise with a negative number |- is interpreted as table code.--Patrick 10:58, 9 November 2007 (UTC)

Sortname without link?

I'm working on a table with 400+ names of which approximately 115 have articles on wikipedia. Is it possible to remove the redlink but still using the table? What I mean is; Is it necessary that the template links to an article or can I add a parameter that removes the link? --Krm500 02:03, 5 June 2007 (UTC)

I'm also trying to do this. How can I make it sort without wikilinking the name? —Noetic Sage 16:40, 13 October 2007 (UTC)

Use Template:sort and specify the second parameter.--Patrick 10:41, 9 November 2007 (UTC)

{{sortname}} Last, First

What if I want that it shows me Last, First? Is there a |parameter}} or something like? --necronudist 19:16, 17 August 2007 (UTC)

You don't need a template if the required sorting order is simply alphabetic.--Patrick 11:02, 9 November 2007 (UTC)

Problem using {{dts}} - request for help

Is there a limit to how many {{dts}} can be used on one article? I'm working on a draft article in my userspace here and midway through the article, the dts template functionality breaks - it just displays Template:Dts and won't thereafter sort properly. However, if you click to edit one of the affected sections, the templates and dates all work perfectly in the preview, suggesting that the problem lies somewhere else. Any help or suggestions would be very gratefully received. Thanks, Bencherlite^Talk 00:28, 5 November 2007 (UTC)

See Wikipedia:Template limits and Template:Dts#Pre-expand_include_size. One workaround is to substitute the template. Alternatively a simplified version could be made, or separate versions for separate cases.--Patrick 11:24, 9 November 2007 (UTC)

Thanks, I suspected that there was some limit like that in operation, but couldn't find the info about it. I've solved the problem using Special:ExpandTemplates to replace the {{dts}} uses. Bencherlite^Talk 15:22, 9 November 2007 (UTC)

Is it possible to sort referenced numbers?

#
1.1
3.5
10.9
252.4

This doesn't sort properly, and using {{sort}} doesn't work because it simply prepends the first argument, keeping the reference there. --NE2 03:42, 7 February 2008 (UTC)

I know you can hide the sort value, and exclude everything else from the sort. If you look in the article you can find it. --Krm500 (talk) 03:47, 7 February 2008 (UTC)

Which article? --NE2 04:07, 7 February 2008 (UTC)

Well, I solved it, though in a pretty dumb way, by adding a suitably large number to every field: {{sort|{{#expr:{{{1}}}+10000}}|{{{1}}}{{{3|}}}}} In particular, the length column of List of state highways in California sorts properly. --NE2 00:41, 10 February 2008 (UTC)

#expr: & sci notation

I am getting output from formatnum that is in scientific notation - but it is not consistent. Padright does not seem to help, nor nts. The following sometimes displays with commas & sometimes Exponentially. Is this related to which server handles it?

• {{formatnum:{{#expr: 33200000 + 200000 round -4 }} }} ==> 33,400,000
• {{padright:{{formatnum:{{#expr: 33200000 + 200000 round -4 }} }} }} ==> 33,400,000
• {{nts|{{formatnum:{{#expr: 33200000 + 200000 round -4 }} }} }} ==> 33,400,000 which sometimes appears as 33,400,000 and sometimes as 3.34E+7

--JimWae (talk) 00:56, 6 March 2008 (UTC)

Yes, strange behaviour of #expr (formatnum does not seem related, it only adds commas).--Patrick (talk) 11:55, 6 March 2008 (UTC)

The uses are in population updates:

• { {formatnum:{ {#expr: 1321480000 + 21041 * { {Age in days|2008|1|1} }round -4 } } } } ==>1,451,350,000
• { {formatnum:{ {#expr: 1006360500 + 42197.260273969 * { {Age in days|2000|3|1} } round -4} } } } ==> 1,387,570,000
• { {formatnum:{ {#expr: 32976026 + 329810/366 * { {Age in days|2007|7|1} } round -3} } } } ==> 38,704,000

--JimWae (talk) 05:49, 6 March 2008 (UTC)

There's nothing very unusual about an output being in sci notation - Excel does it lots of times, until the cell is formatted It is strange that one second it gives zeros & the next give Es It seems to be a problem depending on how it is rounded

Sometimes the output is in Sci notation & sometimes it is not. Is it the time of day? the server that processes the code?

Below are roundings of constants 6,655,046,294.9 and of 33,200,000

• rounded to nearest billion: 7000000000 || 0
• rounded to nearest 100-million: 6700000000 || 0
• rounded to nearest 10-million: 6660000000 || 30000000
• rounded to nearest million: 6655000000 || 33000000
• rounded to nearest 100-thousand: 6655000000 || 33200000
• rounded to nearest 10-thousand: 6655050000 || 33200000
• rounded to nearest thousand: 6655046000 || 33200000
• rounded to nearest hundred: 6655046300 || 33200000
• rounded to nearest ten: 6655046290 || 33200000
• rounded to nearest integer: 6655046295 || 33200000
• NOT rounded at all: 6655046294.9 || 33200000

HERE is the output I got one time

• rounded to nearest billion: 7.0E+9 || 0
• rounded to nearest 100-million: 6.7E+9 || 0
• rounded to nearest 10-million: 6.66E+9 || 3.0E+7
• rounded to nearest million: 6.655E+9 || 3.3E+7
• rounded to nearest 100-thousand: 6.655E+9 || 3.32E+7
• rounded to nearest 10-thousand: 6655050000 || 3.32E+7
• rounded to nearest thousand: 6655046000 || 3.32E+7
• rounded to nearest hundred: 6655046300 || 3.32E+7
• rounded to nearest ten: 6655046290 || 3.32E+7
• rounded to nearest integer: 6655046295 || 3.32E+7
• NOT rounded at all: 6655046294.9 || 3.32E+7

HERE is the output less than a minute later

• rounded to nearest billion: 7000000000 || 0
• rounded to nearest 100-million: 6700000000 || 0
• rounded to nearest 10-million: 6660000000 || 30000000
• rounded to nearest million: 6655000000 || 33000000
• rounded to nearest 100-thousand: 6655000000 || 33200000
• rounded to nearest 10-thousand: 6655050000 || 33200000
• rounded to nearest thousand: 6655046000 || 33200000
• rounded to nearest hundred: 6655046300 || 33200000
• rounded to nearest ten: 6655046290 || 33200000
• rounded to nearest integer: 6655046295 || 33200000
• NOT rounded at all: 6655046294.9 || 33200000

I am thinking now it has to do more with how ROUND works - and like I say, whether an E appears is erratic - depending PERHPAS on TIME or what server processes it?? --JimWae (talk) 06:14, 7 March 2008 (UTC)

• I have taken issue to MetaWiki ParserFunctions m:ParserFunctions --JimWae (talk) 06:53, 7 March 2008 (UTC)
• It's NOT ROUND, last row does not use ROUND and its results are unpredictable
• NOT rounded at all: { {#expr: 6655046294.9 } } || { {#expr: 33200000 } }

A Hint: ending with 5 or more 0s

The issue with scientific notation crops up when expr# outputs a number with 5 or more zeroes at the end It does not ALWAYS happen then - apparently depending oon which server renders the output. --JimWae (talk) 07:14, 9 April 2008 (UTC)

Evalint

Evalint is worse - has problems with 4 zeroes at end (expr seems OK with that) Csn outputs junk like 0,0,0

• rounded to nearest X... { {formatnum:{ {evalint| 1234500000.9 round -X}} }} || { {formatnum:{ {evalint| 123450000 round -X}} }}

• rounded to nearest billion: 1,000,000,000 || 0
• rounded to nearest 100-million: 1,200,000,000 || 100,000,000
• rounded to nearest 10-million: 1,230,000,000 || 120,000,000
• rounded to nearest million: 1,235,000,000 || 123,000,000
• rounded to nearest 100-thousand: 1,234,500,000 || 123,500,000
• rounded to nearest 10-thousand: 1,234,500,000 || 123,450,000
• rounded to nearest thousand: 1,234,500,000 || 123,450,000
• rounded to nearest hundred: 1,234,500,000 || 123,450,000
• rounded to nearest ten: 1,234,500,000 || 123,450,000
• rounded to nearest integer: 1,234,500,001 || 123,450,000
• NOT rounded at all: 1,234,500,000.9 || 123,450,000

OUTPUT SOMETIMES

• rounded to nearest billion: 1.0E+9 || 0
• rounded to nearest 100-million: 1.2E+9 || 1.0E+8
• rounded to nearest 10-million: 1.23E+9 || 1.2E+8
• rounded to nearest million: 1.235E+9 || 1.23E+8
• rounded to nearest 100-thousand: 1.2345E+9 || 1.235E+8
• rounded to nearest 10-thousand: 1.2345E+9 || 123,450,000
• rounded to nearest thousand: 1.2345E+9 || 123,450,000
• rounded to nearest hundred: 1.2345E+9 || 123,450,000
• rounded to nearest ten: 1.2345E+9 || 123,450,000
• rounded to nearest integer: 1,234,500,001 || 123,450,000
• NOT rounded at all: 1,234,500,000.9 || 123,450,000