Jump to content

Template talk:Sort/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2

No wikilinking in Sortname

I created Template:Sortname-nolink (backlinks edit) in an attempt to be able to sort names without wikilinking, because sometimes it links to non-existing articles or the wrong article. Something's wrong with it though, because it won't display anything if it is used in a sorttable. Help! -- Matthew | talk | Contribs 18:31, 11 March 2008 (UTC)

All your template does is creates the non-displaying sort key (inside the span tags). After the /span you need to explicitly display params 1 and 2. I think I've changed it to do this, though you'd better check. cheers, Struway2 (talk) 14:04, 20 March 2008 (UTC)
I have updated Template:Sortname to do exactly the same thing when parameter nolink=1 (or any other non-blank value). — CharlotteWebb 14:16, 21 March 2008 (UTC)

nts not sorting values above 10million properly

(Example: List of acquisitions by Cisco Systems). When values above 10 million are involved, the invisible part uses E notation (e.g. 1.23E07). As far as I can tell, this is result of how #expr returns such numbers.
I carried out a quick check, and the expressions below seem to result in either E notation or all the digits, randomly flicking between the two. Tompw (talk) (review) 22:55, 4 May 2008 (UTC)

  • 1000000
  • 22000000
  • 333000000
  • 4444000000
Further explanation... I came back to this page just now, and all the above were in E notation. I edit the page, click "preview", and the first three are 'spelled out' and the last is in E notation. Tompw (talk) (review) 17:57, 5 May 2008 (UTC)
This is a known problem, see also m:Help:Calculation. I fixed Template:nts (backlinks edit) to force it to use non-scientific notation.--Patrick (talk) 07:52, 11 May 2008 (UTC)

Default right-align for numbers?

I think that {{Nts}} and friends should [default to] align="right"; with left-alignment, the readability, especially for large tables, is really bad; see e.g. Union for the Mediterranean#Members—even when unsorted, the numbers are easily comparable if right-aligned, but in this way...

I was afraid to mess something with {{Nts}}, so if a kind soul would fix it... (or offer counterarguments) 82.117.194.34 (talk) 12:23, 15 July 2008 (UTC)

Negative number fix for template:nts

I've developed a proposed fix for the handling of negative numbers in {{nts}} using the technique suggested by -Random832 (talk · contribs) and Van helsing (talk · contribs) last year in the [[##.7B.7Bnts.7D.7D|{{nts}}]] section above. The candidate is cin Template:Tcncv/nts and can be assessed (for now) as {{Tcncv/nts}}.

The approach I used was to:

  1. take the absolute value of the supplied value,
  2. break it into three parts (upper 8 digits, lower 8 digits, and 6 fractional digits),
  3. apply a 9's compliment inversion if the original value was negative,
  4. pad the intermediate results with leading zeros, and
  5. combine the parts together along with either an "N" or "P" prefix.

The "N" prefix causes negative numbers to sort below positive numbers which have a "P" prefix. For negative numbers, the 9's compliment causes more negative numbers to sort below less negative numbers. As a simplified example, the numbers

-34, -5.6, -5.5, -0.1, 0, 0.1, 5.5, 5.6, and 10

would be mapped and sorted as

"N65.9" < "N94.3" < "N94.4" < "N99.8" < "P00.0" < "P00.1" < "P05.5" < "P05.6" < P10.0"

.

Note that using a 9's complement (999...999 - value) instead of a 10's complement (1000...000 - value) avoids a carry condition that I think might have caused problems with a previous implementation attempt.

The following table demonstrates the sort results under the current and proposed template. The current and debug columns represent the current implementation of {{nts}}. The fix and fix debug show the results of the proposed change from {{Tcncv/nts}}. Click "[show]" to expand it, and then click the sort icon in the "fix" column to see the results of the sort.

Notes:
1. These values exceed the supported range (need to document supported range as +/- 9,999,999,999,999,998).
2. These values are too close to distinguish in their internal representation.
3. The difference between these values and their adjacent value is less that documented 0.000001 minimum, but they still sort correctly after rounding to six decimals.

I have been careful to design the calculation that separates the three parts to minimize the prospect of a boundary condition problems, but I intend to test this further to make sure that values such as 1111111111.999999 doesn't process as 1111111112.999999 or 1111111111.000000. A result of 1111111112.000000 would be considered acceptable and possibly unavoidable due to the the initial rounding by #expr as it converts the initial text value to an internal representation.

Please take a look.

-- Tcncv (talk) 06:51, 2 September 2008 (UTC)

Scientific notation is produced for numbers with large absolute value, usually for Wikimedia: greater than or equal to 1E+12; however, even within Wikimedia there is no uniformity, larger numbers in non-scientific notation and smaller numbers in scientific notation have been observed as output; the format of the same number can vary from preview to view, and by refreshing the page, see also m:Help:Calculation#Numbers_as_output. Therefore I made edit [1] to avoid padding the output of a computation, and compute every digit separately. This may be useful here too.--Patrick (talk) 10:01, 2 September 2008 (UTC)
I see what you mean. I've encountered something similar to this before (might have been the C %g format code, but I'm not sure). The #expr function must use a library function that attempts to use the shorter representation o either fixed or loating point. If the fixed point is shorter, that representation is used. If the floating point representation is equal to or shorter than the fixed point, the shorter exponential notation may (but not always) be used. For exaple, If the number of characters is equal (such as for "100000" vs "1.0E+5"), the result may go either way, but since "90000" is shorter tahn "9.0E+4", "90000" will always be chosen.
Since scientific notation form always uses at least 6 characters "m.mE+x", integers of five or fewer characters should never result in scientific notation. Accordingly, I have modified me template to use digit groups of four or less (4+4+4+4 seemed cleaner than 1+5+5+5 digits). This has eliminated the problem. I also restructured the code to separate it into separate positive and negative sections. The math trick used in the prior version was just too hard to read. I left in code to do the initial round-6 on all references to the input parameter to ensure numeric consistency between the different calculated parts, but I did switch to using the mod operator.
The updated algorithm is as follows:
  1. Take the absolute value of the supplied value.
  2. Round the value to 6 decimal places. (This avoids potential inconsistent rounding later.)
  3. Break the value into its integer and fractional parts.
  4. Break the integer portion into four parts of four digits each.
  5. Promote the fractional part to a six digit integer and break it into two 3-digit parts.
  6. If the original value was negative, apply a 9's compliment inversion to each part.
  7. Pad the intermediate results with leading zeros.
  8. Combine the parts together along with either an "N" (negative) or a "P" (positive) prefix.
The above table reflects the changes to the proposed templete. Note that even for positive values, it fixes some cases that cause problems with the current implementation.
Resubmitted for your review. Thank you. -- Tcncv (talk) 04:10, 3 September 2008 (UTC)
Thanks, seems fine.--Patrick (talk) 07:41, 3 September 2008 (UTC)

Sorting by game score

I have a column that lists the score of baseball games at List of Washington Nationals Opening Day starting pitchers. How would I use the sort template to handle sorting this field? Alansohn (talk) 20:51, 10 October 2008 (UTC)

Superfluous space

{{editprotected}}

The template, as it currently stands, has a tendency to put extra spaces before the text it outputs; see some of the entries preceded by "The" at List of downloadable songs for the Rock Band series. Is there any way to fix that? --fuzzy510 (talk) 19:22, 14 May 2009 (UTC)

That's HTMLTidy's fault, it pulls the space outside he display:none span, which makes it visible. Let's centralize this discussion at Template talk:Coord#Superfluous space. Amalthea 10:34, 15 May 2009 (UTC)
 Done Amalthea 12:45, 15 May 2009 (UTC)

Blank parameter for nts: trap

If {{nts}} is left with its parameter blank, the template tries to evaluate an expression such as this:

{{#expr:((/1e15-.5) round 0) mod 10}}

This fails because there is no numeric value between the second opening round bracket and the slash, and so the article is placed in hidden Category:ParserFunction errors. It's impractical to go through articles looking for the instances of {{nts|}} and correcting or removing them; the template is used by other templates such as {{WDL}}. Would it be possible to trap for a blank parameter, sort that as zero but still display the blank? --Redrose64 (talk) 16:57, 1 February 2010 (UTC)

No response. Am now unwatching this page because my watchlist is clogged up with trivial changes to #Incorrect sort and proposed solution (override in wikibits.js) - see {{subst:uw-preview}}. --Redrose64 (talk) 18:47, 3 July 2010 (UTC)

{{nts}}

This doesn't currently work with negative numbers. I have an idea how to make it workable, it would involve a sort of tens-complement, e.g. having positive numbers show up as (say) 1234 is P0000000001234, and -1234 is N9999999998766 (N and P are arbitrary, but the negative prefix has to sort before the positive one and they have to force alphabetic sorting) --Random832 19:05, 5 April 2007 (UTC) One issue is that the simple solution (using expr to subtract) limits us to 12 digits. so we'd have to do negative numbers in pieces. --Random832 19:11, 5 April 2007 (UTC)

Working on it (positive and negative real numbers mixed in one column). Two problems I encountered are:
  • Padleft doesn’t seem to work on a zero, this would be needed for the range 0 to 0.9999etc.
{{padleft:0|16|&}} gives: &&&&&&&&&&&&&&&0, instead of &&&&&&&&&&&&&&&0
  • Negative and positive numbers are sorted on their absolute value and therefore the negative and positive “sections” in a column are sorted in opposite/wrong directions.
value negative/positive sort key good sort key
1234 P0000000001234 P0001234
234 P0000000000234 P0000234
34 P0000000000034 P0000034
-1234 N9999999991234 N9998766
-234 N9999999999234 N9999766
-34.000002 N9999999999965.999992 N9999965.999998
-34.000001 N9999999999965.999991 N9999965.999999
-34.2 N9999999999965.2 N9999965.8
-34.1 N9999999999965.1 N9999965.9
A solution good be to take the Reciprocal (mathematics) (1/x) for the negative absolute values (and keeping them apart from the positive values by the “N”). I admit, a lot of thinking/work to get some thousand separators in. well... that's solved...the things you can learn --Van helsing 20:51, 5 April 2007 (UTC)
Solved how? The example values are still wrong. numbers of the same magnitude still sort wrong - you need to really subtract it from some 10^x number, not cheaply pad left with 9. - there's no way around having to do it in pieces to be able to handle more than 12 digits--Random832 23:04, 5 April 2007 (UTC)
Do we actually have cases with more than 12 digits? Worst case scenario, if someone wants to have 13+ digits and thousands separators they can handcode it using {{sort}} or {{sortkey}}. If {{sortnum}} covers 99% of the usues that should be good enough. ~ trialsanderrors 05:05, 6 April 2007 (UTC)
Yup, not solved, realized that later. --Van helsing 11:30, 6 April 2007 (UTC)
My suggested version (though it's only to eight digits and typed manually in the example table) works perfectly, at this point what's needed is to write code that will convert numbers to it. I can try some this weekend --Random832 08:04, 7 April 2007 (UTC)

It looks like this template doesn't work properly even for positive numbers. If I try to sort table List of social networking websites by Registered users, it doeesn't sort well. In the HTML source there is for example 

<span style="display: none;">&&&&&&&&&01.0E+5.<strong class="error">Expression error: Unrecognised word "e"</strong></span>100,000

Svick (talk) 17:23, 25 January 2008 (UTC)

I probably found out where the problem is. #expr acts differently when running on 64-bit or 32-bit server and WP runs on both types. If you regenerate that page few times, it will sometimes sort well, sometimes not. --Svick (talk) 18:41, 25 January 2008 (UTC)

I am trying to translate this template for an Indian language that uses the Indian numbering system. Anyone has an idea how to modify this template for that? Abhijit Sathe (talk) 21:45, 13 July 2009 (UTC)

Note also that using "P" and "N" will disable the possibility of importing numeric data in a spreadsheet, directly by selecting the displayed table. The extra zeroes do not have this problem (the numeric values will be correctly interpreted).
Note also that "+" naturally sorts before "-". Using "P" and "N" instead of simply "+" and "-" is then ill, please avoid using "P" and "N". Example:
value negative/positive sort key good sort key More compact key
1234 +0000000001234 +001234 3 003 1234
234 +0000000000234 +000234 3 002 234
34 +0000000000034 +000034 3 001 34
10 +0000000000010 +000010 3 001 1
9.99 +0000000000009.99 +000009.99 3 000 999
9.9 +0000000000009.9 +000009.9 3 000 99
9 +0000000000009 +000009 3 000 9
8 +0000000000008 +000008 3 000 8
5 +0000000000005 +000005 3 000 5
2 +0000000000002 +000002 3 000 2
1 +0000000000001 +000001 3 000 1
0.9 +0000000000000.9 +000000.9 2 999 1
0.8 +0000000000000.8 +000000.8 2 999 2
0.5 +0000000000000.5 +000000.5 2 999 5
0.2 +0000000000000.2 +000000.2 2 999 8
0.1 +0000000000000.1 +000000.1 2 999 9
0.00002 +0000000000000.00002 +000000.00002 2 995 8
0.000002 +0000000000000.000002 +000000.000002 2 994 8
10ɛ +0000000000000.0000000...10 +000000.0000000...10 2 000 1
ɛ +0000000000000.0000000...01 +000000.0000000...01 2 000 1
0 +0000000000000 +000000 2 000
-ɛ -9999999999999.9999999...99 -999999.9999999...99 1 999 1
-10ɛ -9999999999999.9999999...90 -999999.9999999...90 1 998 1
-0.000002 -9999999999999.999998 -999999.999998 1 006 8
-0.00002 -9999999999999.99998 -999999.99998 1 005 8
-0.1 -9999999999999.9 -999999.9 1 001 9
-0.2 -9999999999999.8 -999999.8 1 001 8
-0.5 -9999999999999.5 -999999.5 1 001 5
-0.8 -9999999999999.2 -999999.2 1 001 2
-0.9 -9999999999999.1 -999999.1 1 001 1
-1 -9999999999999 -999999 1 000 9
-2 -9999999999998 -999998 1 000 8
-5 -9999999999995 -999995 1 000 5
-8 -9999999999992 -999992 1 000 2
-9 -9999999999991 -999991 1 000 1
-9.1 -9999999999990.9 -999990.9 1 000 09
-9.5 -9999999999990.5 -999990.5 1 000 05
-9.9 -9999999999990.1 -999990.1 1 000 01
-9.99 -9999999999990.01 -999990.01 1 000 001
-10 -9999999999990 -999990 0 999 9
-11 -9999999999989 -999989 0 999 89
-34 -9999999999966 -999966 0 999 66
-34.000001 -9999999999965.999991 -999965.999998 0 999 65999999
-34.000002 -9999999999965.999992 -999965.999998 0 999 65999998
-34.1 -9999999999965.1 -999965.9 0 999 659
-34.2 -9999999999965.2 -999965.8 0 999 658
-234 -9999999999766 -999766 0 998 766
-1234 -9999999998766 -998766 0 997 8766
NaN(999) +Nan(999) +NaN(999) 4 999
NaN(0) +NaN(000) +NaN(000) 4 000
Infinite +Infinite +Infinite 4
-Infinite -Infinite -Infinite 0 000
-NaN - NaN - NaN 0 0
I also develop above a more compact sortable format, made of three groups of digits : the first group is only 1 digit between 0 and 3, the second one has a fixed width (depends only on the representable order of magnitude), here 3 (for representing positive or negative exponents with 3 digits), the third one is unrestricted and contain the same number of precision digits as the original. The space separators are just here for clarity, they are actually not needed. The third group normally cannot start by a zero (if there are zeros appended, it's just for explicitly noting an additional low order digit of precision, this does not change the value)
This format is directly based on the scientific notation where the second group represents the absolute value of the exponent, and the digit in the first group represents the signs of the number and of its exponent.
Note that you may need to insert a <nowiki/> before the minus-hyphen or plus, if ever there's no space between the last "|" starting a new cell and the formatted sort key (otherwise it could initiate a table caption or new table row.
verdy_p (talk) 21:20, 3 July 2010 (UTC)
Note anyway that there's a serious bug of sort stability in the current javascript implementation : it tries to autodetect the type of the column to know if it needs to sort numbers, or dates, or text. But it does that only from the cell of the first row found that is sortable.
Then when the sort is performed, the cell that will be on the top row may be of different "type". So the next click to sort the same column may alternate between numeric sort, date sort and text sort.
The autodetection will likely fail, and there should exist a way to specify (as a class attribute added to the heading cell that will be clicked) which type of sort to perform (this would disable completely the attempt to guess the type of sort, and apply the same type for sorting all cells of the column). E.g. :
{|class="wikitable sortable"
|-
!class="sort-text"| Item
!class="sort-number"| Quantity
!class="sort-number"| Unit Price
!class="sort-number"| Total
!class="sort-date"| Date
|-
| Welcome || — || — || 1.00 || 2009
|-
| Water || — || 0.50 || 0.50 || 2009-11-31
|-
| Bread || 2 || 1.65 || 3.00 || 2009-12-31
|-
| 666 || 1 || 2.00 || ''offered'' || —
|-
| Free delivery || — || — || — || 2010-01-01
|}
Item Quantity Unit Price Total Date
Welcome — — 1.00 2009
Water — 0.50 0.50 2009-11-31
Bread 2 1.65 3.00 2009-12-31
666 1 2.00 offered —
Free delivery — — — 2010-01-01
See how the clicks on the first column are currently alternating between text sort and number sort (4 clicks to cycle the options). The same occurs on other columns after having sorted the data on another column of distinct type (the first click may perform the wrong guess ans sort as text, then there will be ascending/descending sorts by number or date). This is clearly inconsistant.
Another problem is that when clicking to sort a column then another, then back to the first column, it still records the last order used in that column, so the two first clicks will present ascending sorts by default, but the third click will present a descending sort. The sort direction should not be reset and not kept as attributes in all columns that are not the currently sorted one. verdy_p (talk) 00:42, 4 July 2010 (UTC)

Chinese names

While using {{sortname}}, if say I want to sort Sun Yat-sen in a table. But, Sun is his Last Name and Yat-sen is his First Name. Can the template {{sortname}} sort by the last name "Sun" but appears as "Sun Yat-sen" while viewing the table?? Thanks - impactF= 00:52, 13 June 2009 (UTC)

Just use "Sun&#x32;!Yat-sen" as the sort key (i.e. with an exclamation mark after the space separation, so that it will sort before "Sun Yat-sen !Chang" where "Sun Yat-sen" is the last name and "Chang" the first name.
Note that using a comma separator will not work as expected: "Sun, Yat-sen" would unexpectedly sort after "Sun'yi, Li".
Note also that the sequence " !" where the space is not preserved as "&#32" or as " <nowiki/>" (before a punctuation like an exclamation mark, or colon, or semi-colon) would be transformed by MadiaWiki into a non-breaking space, and would sort incorrectly.
The separator between primary and secundary keys needs to be lower than any sequence that would typically be found in usual strings (and the usually found ", " sequence of comma and space, does not work as expected in many cases (notably when names contain apostrophes, ampersands or double quotes). The space alone (or a TAB or newline, treated like regular space), or several spaces (that are automatically treated as if it was a single space) also does not work as well (because many texts to sort contain multiple words, separated by a space, or may contain an exclamation mark possibly followed by a space if the sentence continues). The lowest possible sequence that is not a space alone is space+exclamation mark. See the section about it below. verdy_p (talk) 10:36, 5 July 2010 (UTC)

display:none is evil

These templates really shouldn’t be using a span hidden by CSS, because logically the (ugly) sort key is still there. Instead they should add a (custom) attribute to table cells, e.g. data-sort="…". (Attributes beginning with ‘data-’ are reserved for private use in HTML5.) The sort JS script would have to be altered accordingly, of course. — Christoph Päper 17:13, 1 July 2010 (UTC)

It's not so evil. Yes the sort key is still in the plain-text value of table cells. But custom attributes are not supported everywhere. I do agree however that it would be much simpler, but there would also be caveats, if the sort key contains quotes or apostrophes. But the jascript would have to be modified to look for the sort key of data cells within such attribute, if there's one. verdy_p (talk) 10:42, 5 July 2010 (UTC)

Incorrect sort and proposed solution (override in wikibits.js)

The characters chosens as the separator between the sort key and the text is wrong. It should be one that sorts natively as lower than any other string which may be appended to the string to sort. Idealy, it should be a NUL control, but it's impossible to generate in HTML controls (outside TAB, CR, LF which are all converted to SPACE, outside of a preformated text, and compressed).

You chose a SPACE followed by a nearly maximum character (such as U+FFFD), which gives ill sorts.

Actually this template uses U+FEFF which is even worse ! The theoretical valid maximum character is U+10FFFD, it would be correctly transported in the HTML, but in the Javascript's sort function it would appear as two surrogates '\uDBFF\uDFFD' which would be worse (Unfortunately, Javascript compare strings using the UTF-16 binary ordering instead of UTF-32, and offers no native support for comparing strings at the codepoint level).

So let's see what are the first lowest strings:

  • the empty string : it will not work when comparing "À" (with a sort key "A" prepended) and "AA" (without any sort key prepended)
  • a single SPACE: it does not qualify well because it is extremely common to sort items whose one is a word and another is two words where the first one is equal to the second one. for example it will not sort correctly "A" and "A A" ; additionally, this space occuring at end of the invisible sort key will move outside of the invisible span (due to HTMLTidy), so it may become visible.
  • a SPACE followed by an EXCLAMATION MARK: it works very well (see below), because this sequence is typically not used in english, or if it is used it is occuring only at end of a string, or followed by a space., and because the strings to sort do not begin with a space.

To help you see the effects, I made this table where the sort keys is made visible and separated by the candidate separators. Only sorting on the second column really works. For strings that don't need a sort key, because they are only using lowercase ASCII letters, two rows are used : they should sort in the same group (their relative order does not matter)

To make things even more precise, the sort key used here is a compound of two substrings with the same separator, for correctly sorting uppercase and lowercase letters. The compound sort key uses two substrings:

  • The first substrings is the filtered string mapped to lowercase only (this is the only substring actually used in the current template).
  • The second substring keeps the case differences of filtered letters, but the case is swapped for correct binary ordering, according to the traditional dictionnary order which sorts lowercase before uppercase). This adds another level of collation (before the last level which contains all the differences of accents and ignorable characters from the original string which will be visible).
Original string
to sort		 Sort key separated by
<space,U+FFFD>		 Sort key separated by
<space,exclamation>
ZZ zz �zz �ZZ zz !zz !ZZ
Z z �z �Z z !z !Z
zz zz �ZZ �zz zz !ZZ !zz
z z �Z �z z !Z !z
a9 a9�A9 �!a9 a9 !A9 !a9
A9 a9�a9 �!A9 a9 !a9 !A9
a0 a0�A0 �!a0 a0 !A0 !a0
A0 a0�a0 �!A0 a0 !a0 !A0
AA aa �aa �AA aa !aa !AA
Aa aa �aA �Aa aa !aA !Aa
aA aa �Aa �aA aa !Aa !aA
A a �a �A a !a !A
a a �A �a a !A !a
(a) a �A �(a) a !A !(a)
() � �() ! !()
( � �( ! !(
'a' a �A �'a' a !A !'a'
'' � �'' ! !''
' � �' ! !'
À a �a �À a !a !À
à a �A �à a !A !à
Àà aa �aA �Àà aa !aA !Àà
àÀ aa �Aa �àÀ aa !Aa !àÀ
aa aa �AA �aa aa !AA !aa
a a aa �AA �a a a a !A A !a a
a(a) a a �A A �a(a) a a !A A !a(a)
a. a �A �a. a !A !a.
a.a aa �AA �a.a aa !AA !a.a
a-a aa �AA �a-a aa !AA !a-a
a! a �A �a! a !A !a!
a!! a �A �a!! a !A !a!!
+ � �!+ ! !+
- � �!- ! !-
! � �!! ! !!
� � ! !
pierre pierre �PIERRE �pierre pierre !PIERRE !pierre
pierres pierres �PIERRES �pierres pierres !PIERRES !pierres
Pierre pierre �pIERRE �Pierre pierre !pIERRE !Pierre
Pierre Henri pierre henri �pIERRE hENRI �Pierre Henri pierre henri !pIERRE hENRI !Pierre Henri
Pierre Henri-Martin pierre henrimartin �pIERRE hENRImARTIN �Pierre Henri-Martin pierre henrimartin !pIERRE hENRImARTIN !Pierre Henri-Martin
Pierre, Henri-Martin pierre henrimartin �pIERRE hENRImARTIN �Pierre, Henri-Martin pierre henrimartin !pIERRE hENRImARTIN !Pierre, Henri-Martin
Pierre, Henri pierre henri �pIERRE hENRI �Pierre, Henri pierre henri !pIERRE hENRI !Pierre, Henri
Pierre-Henri pierrehenri �pIERREhENRI �Pierre-Henri pierrehenri !pIERREhENRI !Pierre-Henri
Pierre-Henri Martin pierrehenri martin �pIERREhENRI mARTIN �Pierre-Henri Martin pierrehenri martin !pIERREhENRI mARTIN !Pierre-Henri Martin
Pierre-Henri, Martin pierrehenri martin �pIERREhENRI mARTIN �Pierre-Henri, Martin pierrehenri martin !pIERREhENRI mARTIN !Pierre-Henri, Martin
antilibéral antiliberal �ANTILIBERAL �antilibéral antiliberal !ANTILIBERAL !antilibéral
anti-libéral antiliberal �ANTILIBERAL �anti-libéral antiliberal !ANTILIBERAL !anti-libéral
délègue delegue �DELEGUE �délègue delegue !DELEGUE !délègue
délègues delegue �DELEGUES �délègues delegues !DELEGUES !délègues
délèguent deleguent �DELEGUENT �délèguent deleguent !DELEGUENT !délèguent
déléguer delegue �DELEGUER �déléguer deleguer !DELEGUER !déléguer
déléguer plus tard deleguer plus tard �DELEGUER PLUS TARD �déléguer deleguer plus tard !DELEGUER PLUS TARD !déléguer plus tard
délégué delegue �DELEGUE �délégué delegue !DELEGUE !délégué
déléguée deleguee �DELEGUEE �déléguée deleguee !DELEGUEE !déléguée
délégué-adjoint delegueadjoint �DELEGUEADJOINT �délégué-adjoint delegueadjoint !DELEGUEADJOINT !délégué-adjoint
délégués-adjoints deleguesadjoints �DELEGUESADJOINTS �délégués-adjoints deleguesadjoints !DELEGUESADJOINTS !délégués-adjoints
déléguée-adjointe delegueeadjointe �DELEGUEEADJOINTE �déléguée-adjointe delegueeadjointe !DELEGUEEADJOINTE !déléguée-adjointe
déléguées-adjointes delegueseadjointes �DELEGUEESADJOINTES �déléguées-adjointes delegueesadjointes !DELEGUEESADJOINTES !déléguées-adjointes
délégués delegues �DELEGUES �délégués delegues !DELEGUES !délégués
déléguées deleguees �DELEGUEES �délégués deleguees !DELEGUEES !déléguées

The correct sort key can be computed in fact automatically from the javascript in wikibits, for sorting tables. I've demonstrated this in a Javascript that I have in my user page, which overrides the default sort key used for text cells : load this User:Verdy_p/tablesort.js in your monobook, and then try sorting the table above on the first column. Currently it does not contain a full map for letters precombined with diacritics, but it does contain a full list of diacritics to drop.

Note that if this replacement function ts_textToKey(string) is used to override the incomplete ts_toLowerCase(string) (part of "wikibits.js"), it will no longer be necessary to include sort keys in the Wiki code of tables used in articles !!! Note also that this javascript function uses a tabulation control as the separator, and this solves almost all problems.

This function does not actually compute true UCA keys (because it does not implement a true NFD decomposition and does not use any grouping and reordering of base characters, but it is simple enough to manage almost all practical cases, at least for Latin (it does not solve the case of Hangul which requires a true decomposition and then mappings for jamos).

verdy_p (talk) 04:52, 3 July 2010 (UTC)

I get "aa !" before "a !". Looking at the html source, the cause seems to be that the server replaces a regular space before "!" by a non-breaking space &#160; --Patrick (talk) 08:50, 3 July 2010 (UTC)
Oh, I forgort to specify the space in hex (to avoid this server tweak in the text actually displayed in the table). But really this does not change what I said.
I have corrected the table above to make sure that the server would not replace this space, and to exhibit why the choice of U+FEFF in this template was really bad, and why the exclamation mark is far better (this is what I chose on French Wiktionary for computing sort keys in categories, and it works now extremely well since about 2 years).
Did you note my magical javascript User:Verdy_p/monobook.js ? It is in fact computing more precise keys, and I've tuned it better (by separating characters to ignore completely from characters to treat as word-separating blank). another change I made in this script was to covert the filtered string to uppercase instead of lowercase, to get consistant sorts of uppercase letters before lowercase, because the final compare will be using the binary order of UTF-16.
If we want to have lowercase letters before uppercase, the filtered key (preserving case differences at the secondary level) would need to have its case swapped, and then the casefolded key (at the primary level) would be converted to lowercase. I may change this in my script, because this is traditionally what we use in dictionnaries.
Note that the third level contains all the original characters, unfiltered (an actual UCA implementation would need a fourth level for this original string, and a more complex mapping for a new third level). This third level of collation (containing differences of diacritics) is reversed when the content language is French.
Another change I did was to treat the regular hyphen (used in compound words) and the middle dot (used in Catalan in the middle of words like a diacritic modifying a letter L in some pairs like 'il·l' which notes a geminated /il:/ distinct from 'ill' which would be read as /j/) as fully ignorable (just like apostrophes) in the primary and secondary level, unlike most other punctuation treated as blanks (because they are word separations). This is consistant with dictionnaries.
verdy_p (talk) 17:30, 3 July 2010 (UTC)
Note that on French Wiktionnary, the secondary key is actually not swapping the letter case, even though it is preserving it. Sort keys added for categories are passed to a template that leave it unchanged in the secondary level, and then converts it to lowercase as here, for the first level. And the collation level separator used is already space+exclamation (because MediaWiki does not want us to use a single TAB in category sort keys).
MediaWiki will truncate the too long category sort keys itself, appending a unique identifier after it, for sort stability. Unfortunately, MediaWiki sort keys for categories are extremely short, and the separator used for the appended unique identifier is "__UNIQ__", which is overlong and starts by an underscore that does not sort correctly (this should have been simply a single TAB character taking 1 byte, instead of "__UNIQ__" taking 8 bytes (before the numeric value) because MediaWiki stores and sorts category sort keys as UTF-8). And the unique identifier was not even needed if the specified category sort key matched exactly the page name and was not too long (i.e. when there was no need to truncate it).
verdy_p (talk) 19:46, 3 July 2010 (UTC)
Conclusion change the code of this template to use the correct:
<span style="display:none" class="sortkey">{{{1}}}&#32;!</span>...
instead of the misbehaving:
<span style="display:none" class="sortkey">{{{1}}} &#xfeff;</span>...
Also I wonder why you force the display of the specified sort key as a link, when there's no parameter 2 specified. The need for a link should be left to the caller (that will specify it anyway in parameter 2 when needed). The second span is not even needed, so this should just be:
...<span class="sorttext">{{{2|}}}</span><noinclude>...</noinclude>
instead of:
...<span class="sorttext">{{{2|[[{{{1}}}]]}}}</span><noinclude>...</noinclude>
verdy_p (talk) 20:38, 3 July 2010 (UTC)
I made the change to &#32;! The second change seems odd, perhaps you mean {{{2|{{{1}}}}}}, but even then, since this template is already in use, it would seem more suitable to create another version of this template, allowing users the choice.
You can test the change yourself as I did. Load my monobook.js in your monobook.js, and see it by yourself. There's a comment at end saying which function of wikibits gets replaced. If you have Chrome, you can use the console also to change the value of the sort to apply (lowercase only, or UCA-like with my function), by copy-pasting the javascript code in the Chrome debug Console when the page is loaded.
You'll be easily convinced that it solves text sorts much more cleanly (it does not alter date sorts or number sorts which remain unchanged, despite they also have their own bugs).
verdy_p (talk) 00:48, 4 July 2010 (UTC)
With regard the change of wikibits.js, this may give complications if codes are used in a sortkey, as e.g. in m:Help:Sorting#General_case.--Patrick (talk) 00:14, 4 July 2010 (UTC)
Apparently the one-parameter call is used when sorting lists of people names (with a link to their article) : only one parameter is given, and it is exactly the same text for the sort key and for the target of the link and for the displayed text. In other words, using this templateis completely superfluous in that case, when a direct link could be used without invoking it at all.
Yes this is odd, but what is odd is using the template for this purpose, when in addition you can't even specify both the displayed text and the target of the link.
In my opinion, the second span is completely unneeded, there shoud just be one, and the text to display should be outside. This would simplify pages, by just adding sort keys where they are really needed.
This won't be used for columns of dates or columns of numbers, as they really don't want any link, even though they could need their own sort key (see the bug discussed above in wikibits.js about incorrect guesses of column types and the side effect to sort stability). verdy_p (talk) 00:58, 4 July 2010 (UTC)
Also the "general case" document is really evil and impossible to understand, and it requires overlong and complex sort keys. See above for the other solution, which is extra small and consistant (it even preserves the number of digits of precision, adding a for example fixed 4 characters prefix for the signs and the exponent, followed by ony the significant digits, without needing more). verdy_p (talk) 01:03, 4 July 2010 (UTC)
Also the numeric sort in wikibits.js is definitely broken and unstable see the demonstration in the long table above where I give an example: the numeric sort will be used if the current display puts the cell with content "0" at top, when all the other columns contains spaces between groups of digits ; in that case it is attempting to sort all the column as if it was numeric in the usual format, and it fails miserably, creating havoc order because almost all cells are text, whcih will finally be in random order! verdy_p (talk) 01:03, 4 July 2010 (UTC)
Yes, it seems better if wikibits.js is changed such that text is sorted as usually desired.
Also, I agree that being able to specify the desired sort mode in the header would be better.
If the template is changed to no longer display anything if there is no second parameter, thousands of pages using this template have to be edited, so that would not be practical.--Patrick (talk) 09:12, 4 July 2010 (UTC)
EDIT: I separated the table sort javascript in my user page, it is now to be found in User:Verdy_p/tablesort.js, where I will maintain it (I added a much more complete mapping for Latin, I'll add Cyrillic and Greek later, and I may later implement there a full UCA collation, with 3 collation levels plus the last level for binary order of code points in the original text ; there will be a first version based only on the Unicode DUCET, and I may later also implement locale-specific tailorings, including the French "backwards" ordering of diacritics with level 2 differences, using a word-breaker for correctness and performance).
Also, the concept of precomputing all sort keys at once in a table is already slow within large tables, notably if multilevel collation is used. We can and should sort rows by comparing pairs only, caching only the pertinent collation levels that are needed in specific pairs. verdy_p (talk) 03:40, 15 July 2010 (UTC)

City State Sort

I would like there to be a Template that does the following (I'll try to create it if it doesn't exist....) {{citystatesort|Jacksonville|Florida}} would generate a link to [[Jacksonville, Florida]] but would sort by State and then City, so I guess the invisible sort key would be something like FloridabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbJacksonville where the b's are spaces. (Is that how nts and dts do it?). I'm not crazy about citystatesort as the name of the template, but css would be misleading. What are the opinions on this?Naraht (talk) 00:58, 7 May 2011 (UTC)

I guess I can use namesort {{namesort|Jacksonville,|Florida}}, but that looks wierd in the wikicode.

Sortname blanks

Michael Hayes isn't sorted correctly here:

Wikicode Displayed as
{{sortname |Michael |Hayes|Michael Hayes (politician) }} Michael Hayes
{{sortname |Richard |Hayes |Richard Hayes (Irish politician) }} Richard Hayes
{{sortname |William |Hayes|William Hayes (Irish politician) }} William Hayes
{{sortname |Seán |Hayes |Seán Hayes (Cork politician) |Hayes, Sean}} Seán Hayes

It's because of the inconsistency in presence or absence of a blank between the lastname and the pipe, as this fix proves:

Wikicode Displayed as
{{sortname |Michael |Hayes |Michael Hayes (politician) }} Michael Hayes
{{sortname |Richard |Hayes |Richard Hayes (Irish politician) }} Richard Hayes
{{sortname |William |Hayes |William Hayes (Irish politician) }} William Hayes
{{sortname |Seán |Hayes |Seán Hayes (Cork politician) |Hayes , Sean}} Seán Hayes

Note that in the second version I had to add a blank before the comma in "Hayes , Sean" as well.

I think that's a bug. All leading and trailing blanks should be ignored unless in quotes. jnestorius(talk) 20:30, 23 April 2011 (UTC)

This is a known wiki bug (involving unnamed parameters) that isn't going to be fix due to backwards compatibility issues.  The solution is to use the {{ Trim }} (or {{ StripWhitespace }}) template (which didn't work for me in certain situations), or just use the actual code replacing {{{1|}}} with {{#if:1|{{{1|}}}}} (i.e. just add {{#if:1| … }} around whatever parameters are effected) which forces the extension to process the parameter and thereby strips the whitespace.  Now you just need to figure out which template(s) and which parameter(s) need to be fixed. — Who R you? Talk 05:28, 4 November 2011 (UTC)

Sortname Text-Wrapping

Currently the {{ Sortname }} template does not {{ nowrap }} the name so that the longest names can split to multiple lines within a table (this was happening at 2006–07 Washington Capitals season [which I worked around by hard-coding a few {{nowrap}}s] and is no doubt happening elsewhere).  The fix simply involves wrapping the entire displayed parameter logic in a {{nowrap}} template (as in): 

…&lt;</noinclude>/span>{{nowrap|{{#if:{{{nolink|}}}
  ···
}}}}{{#ifeq:{{NAMESPACE}}|{{…

which I'll do myself, unless someone else want's to BOLD it, but I'd just like to make sure that no one forsees any problems that all 11,761 tables which currently transclude this template, where names might currently wrap, will stop wrapping (arguably that should always have been the standard case for the template but that doesn't mean someone somewhere hasn't designed their table with the expectation that the name will wrap).
Does anyone have any objections to the change?  Thanks for your input. — Who R you? Talk 06:10, 4 November 2011 (UTC)

{{Sortname}} and Mixture of Chinese names and Western names

I'm working on a list right now and this template is driving me crazy. I need the Chinese names to display family name first, while the Western(ised) names need to display given name first. Is there a way to change how this template displays the text? Right now I've got Teng Chun The where I should have The Teng Chun. — Crisco 1492 (talk) 13:15, 22 July 2012 (UTC)

First and last name in Template:sortname

Hello, in many sport results the athletes last name comes before the athletes' first name. It's time consuming to copy all the last name behind the first name. Is it maybe possible to make in the template {{Template:sortname}} an output as follows because it will save (me) time:

<span style="display:none;">first, last</span>[[last first]] (in stead of <span style="display:none;">last, first</span>[[first last]]) .

Sander.v.Ginkel (talk) 15:35, 2 September 2013 (UTC)

{Sort} and {hs} not working as advertised

The purpose of {sort} is to restrict sorting to the key, ignoring refs and notes which may be appended. This doesn't seem to work when the table column mostly contains keys that are the same, such as small enumerations like Yes/No, or Retired/Operational/Development. A sample:

Primary Secondary
A Yes
B No[1]
C Yes[2]
D No
E Yes
F No
  1. ^ A note which should be ignored for sorting purposes.
  2. ^ A note which should be ignored for sorting purposes.

In this case, the if you sort first on "Primary" and then on "Secondary", the latter sort should be stable on Yes/No only, leaving the first columns in order, but instead it always puts the entries with notes at the bottom. Is this a known issue, or is this a bug in my browser (Safari)? --IanOsgood (talk) 16:12, 27 September 2011 (UTC)

I've got it in Opera as well.Naraht (talk) 17:35, 27 September 2011 (UTC)
It's not a browser issue. {sort} wasn't designed to solve this problem, but it's a good example of an additional problem that {sort} could be extended to solve. (Or maybe it can't...)
{sort} was designed so that names could be displayed "firstname surname" but sorted as if they were "surname, firstname". {sort} works by adding an invisible "surname, firstname" before the visible "firstname surname". {sort} doesn't know if it's in a table, and tables don't know if they contain a {sort}. {sort} just adds some invisible text which should, usually result in tables sorting things correctly. I've no suggestions right now for how to address your issue. Gronky (talk) 19:18, 23 August 2014 (UTC)

Sort showing in-line

@He7d3r: Can you please undo your previous edit to this template? While it makes no difference in tables, it certainly makes a difference when descending icons are used in prose. See how the sort is now visible on articles such as July 2012 in sports. We need to consider in-line uses before we make this change wholesale (especially as the effect on table uses is not bad for users). SFB 14:08, 2 November 2014 (UTC)

Requested any admin to revert as He7d3r may not log in regularly and this issue with in-line usage is extant on probably hundreds of pages. SFB 18:44, 2 November 2014 (UTC)
Quite so; Done --Redrose64 (talk) 19:14, 2 November 2014 (UTC)
Can someone please just remove the table sort functionality from the medal templates then ? You shouldn't be using something for tables OUTSIDE of tables. —TheDJ (talk • contribs) 22:49, 2 November 2014 (UTC)
The problem is that the template is actually intended as a table element with a sort functionality, and is widely used in that format, but it is frequently misused as an in-line icon on the articles within the {{Events in sports by month links}} set. It's a bit of a rogue topic area presentation-wise. What are the knock-on effects of not implementing this change for the time being? It appears to be a technical change, hence my request to revert given the actual degradation of reader experience as a result. Ultimately, I'd like to replace all the 1/2/3 icon usages on the "DATE in sports" articles with 1st/2nd/3rd instead before implementing the change. SFB 23:25, 2 November 2014 (UTC)
Hm... sorry for the disruption. Now I see TheDJ have tried this before and reverted him-self due to the same problems . Helder 12:56, 3 November 2014 (UTC)

Too much code, this one

This article had 2500 transclusions of {{sort}}. It became unacceptable slow loading ('performance doesn't matter until ...'). Luckily I could throw out {{sort}} without problem. I don't see why the code has to be this large (classifying the show text?). And the space-! trick looks like a hack. Comparethis one. I'd expect that after years of sorting changes, the templates would have converged to a more single & simple version. -DePiep (talk) 11:19, 5 November 2014 (UTC)

@DePiep: The source doesn't seem overly large to me. The issue I think is that the software calls the template on every instance, rather than caching it and reusing it, which would speed up load times. Same goes for citation templates. Does anyone know if using Lua would speed up loading times? I agree that these things matter, but I don't think removal of the functionality is a good choice of solution. SFB 20:52, 5 November 2014 (UTC)
Still, you have a good point that using hidden sort key, which doesn't needlessly parameterise the given text, seems a more elegant solution to the problem that this template here. Can anyone think of drawbacks of the hidden template? SFB 20:58, 5 November 2014 (UTC)
(ec) It is all functionality? Is that checked?
{{sort|10}}
<span style="display:none;" class="sortkey">10 !</span><span class="sorttext">[[10]]</span>

{{hidden sort key|10}}
<span class="sortkey">10</span>

{{hid|10}}
<span style="" class="sortkey">10</span>

A class "sorttext"? Why do other sorttemplates not have that? I'll evade {{sort}} as much as I can. -DePiep (talk) 21:02, 5 November 2014 (UTC)

Updating Template:Sort/doc on non-text sorting

Template:Sort/doc has, under Example:

Note: You should always have the same number of characters in the sortkeys for a given table if you intend to sort them by numeric values (some other templates are formating the numeric sort key as needed). E.g., if the wikitable will be sorting the numbers 56 (foo), 94 (bar), and 103 (baz), then your templates within that wikitable should be:
    {{sort|056|foo}}
    {{sort|094|bar}}
    {{sort|103|baz}}

This is needlessly complicated now that we have data-sort-type. I'm replacing it with a reference to Help:Sorting#Numerical sorting problems, and for full detail meta:Help:Sorting#Sort modes.

To discuss this with me, please {{Ping}} me. Thnidu (talk) 19:03, 28 December 2014 (UTC)

Ntss

Just an FYI, that I created a new sort template {{Ntss}}, for sorting numbers using long and short scales. For example numbers like 4.1 billion and 37 trillion. PaleAqua (talk) 07:40, 19 July 2009 (UTC)

It's been deleted being redundant to {{val}} and far less versatile. Jimp 04:07, 1 May 2015 (UTC)

Sortname

I don't see from the doc of {{sortname}} how I could sort by a name, link to it, but only show the surname when the whole thing is too long. --Gerda Arendt (talk) 09:16, 3 June 2015 (UTC)

Please give an example of where you are trying to do this. --Redrose64 (talk) 15:15, 3 June 2015 (UTC)
Like this: 
{{Sortname|[[User:Gerda Arendt|Arendt]]||sort=Gerda Arendt|nolink=1}}
Arendt . Alakzi (talk) 22:43, 4 June 2015 (UTC)
Like in St. Martin, Idstein#Choral concerts, I want to see "Bach", not "Johann Sebastian Bach", but not use a redirect, - or should I. --Gerda Arendt (talk) 05:25, 5 June 2015 (UTC)
Thank for solving that, Alakzi, --Gerda Arendt (talk) 11:57, 20 June 2015 (UTC)

Deprecation notice removed

A deprecation notice was added to the documentation page for this template ({{sort}}), but there does not appear to be a discussion on this page. I have removed that notice. If this template is to be deprecated, there should be a discussion somewhere (or a link to a prior discussion), and there should be clear instructions to editors explaining how to modify articles that transclude the template. – Jonesey95 (talk) 17:52, 9 October 2015 (UTC)

@Jonesey95: Maybe Alakzi can give link to discussion. --Edgars2007 (talk/contribs) 16:36, 30 October 2015 (UTC)
@Jonesey95 and Edgars2007: This template uses sortkey, which has been deprecated. The new sorting syntax is not backwards-compatible; therefore, it would seem sensible to simply deprecate the template as well. Alakzi (talk) 21:38, 10 November 2015 (UTC)
Thanks for the link. I have read the documentation at that link, including the documentation for data-sort-value, but it is not clear to me how someone should replace the template with supported code. In other places, we explain in detail how to replace a deprecated parameter. If we deprecate this template, we should explain in the documentation how to replace it.
But I have a different idea. Right now, it looks like the template generates the following (deprecated) code:
<span style="display:none;" class="sortkey">{{{1}}} !</span><span class="sorttext">{{{2|[[{{{1}}}]]}}}</span>
Could we rewrite the template so that it uses data-sort-value instead? Something like:
data-sort-value="{{{1}}}"!{{{2}}}
I'm sure that's not right, but would something like that work? Then we wouldn't need to deprecate the template. – Jonesey95 (talk) 03:48, 11 November 2015 (UTC)
@Jonesey95: There are two issues with this. First, where both the wikitable attribute notation and {{Sort}} are used, the text of the template will be printed verbatim and sorting will break. Secondly, if the template were to tranclude the exclamation mark separator, that would (a) complicate its use and (b) it would mean that it won't be interoperable with other templates that behave the same way. Alakzi (talk) 12:04, 11 November 2015 (UTC)
data-sort-value is much safer and it much better positioned to deal with the complexities that people ask of in table sorting. The problem is just that wikitable-syntax in general is simply too complex. People find it easier to use this template, since they can't remember how to add attributes to a table cell. In my opinion, that would be something to fix in VE however (see T99890). But making this template emit attributes seems like asking for trouble and is itself a deprecated thing, because it's terrible for the parser to have to deal with unbalanced (partial) wikicode. —TheDJ (talk • contribs) 12:34, 11 November 2015 (UTC)
What about when this is used as a parameter value for another template like {{Classical composition row}}? So now, instead of an editor using something like |text={{sortname|Peter Maxwell|Davies}} , we will recode the template and they will have to use two parameters for each sortable name field: |text-first=Peter Maxwell and |text-last=Davies ? And we could no longer decide on whether there's a link or not unless we have a |text-link=Peter Maxwell Davies? And we loose the option to put Anon or the name of the source material instead of the librettist? I'm not exactly convinced that's a step forward. --RexxS (talk) 10:16, 19 March 2016 (UTC)
{{Table cell templates}} is designed to emit templates for creating table cells with attributes (and most of Category:Unified table cell templates is filled with them). These all contain what you have deemed "unbalanced (partial) wikicode". Some even already contain the ability to add sort keys (e.g., {{n/a}}; unfortunately it currently uses {{hs}} which uses class sortkey but it could probably be easily modified to switch to using attribute data-sort-value). I agree converting all the table sorting templates in Category:Sorting templates will probably be a daunting task as there are many usages of those templates that assume they emit only text used for table cell contents and not entire table cell (wiki) markup (e.g., the usage already adds attributes before the template instantiation and/or assumes text after the template instantiation will be part of the table cell). I also agree the wikitable-syntax is in general simply too complex and why I also advocate templates that are targeted at generating tables avoid such and directly use HTML markup when possible. That said, we probably still need wikitable syntax helper templates to help users craft/simplify the wikitable markup they are already using directly in pages/articles. 50.53.1.33 (talk) 19:43, 29 August 2016 (UTC)
If this template is deprecated, how would you suggest we implement correct sorting in the lists at UEFA Euro 2016 squads? – PeeJay 18:02, 30 June 2016 (UTC)
Use |sortname= added to {{nat fs g player}} on July 1, 2016. Those templates probably could use to have |first= and |last= added to emulate {{sortname}} and avoid having to enter the data twice. See discussion at Wikipedia talk:WikiProject Football/Archive 101#Standard Wikipedia table layout for national football teams. They could probably also due with a conversion to HTML markup (provided no one is using them with wikitable markup someplace). 50.53.1.33 (talk) 19:43, 29 August 2016 (UTC)

In Southern Rocky Mountains#Mountain ranges, the sortkey rather than the text is showing up for the entries with external links. What's going on? — Preceding unsigned comment added by NE2 (talk • contribs) 18:36, 23 May 2008 (UTC)

@NE2: Consider this entry:
{{sort|03|→ Southern [[Sawatch Range]] [http://www.peakbagger.com/range.aspx?rid=14653 PB]}}
it displays as
03
because there is no second positional parameter. The presence of the equals sign causes what is intended as that parameter to be seen as a named parameter, with the name → Southern [[Sawatch Range]] [http://www.peakbagger.com/range.aspx?rid and the value 14653 PB]. To fix this, you merely need to explicitly number the parameter:
{{sort|03|2=→ Southern [[Sawatch Range]] [http://www.peakbagger.com/range.aspx?rid=14653 PB]}}
which displays as
→ Southern Sawatch Range PB
A bit late, but it went unanswered until now. --Redrose64 (talk) 20:01, 20 October 2016 (UTC)

Sortname?

What happened to the {{Sortname}} template?

I can see an entry in the edit history to say that a deprecation template was added, but there's no explanation https://wiki.riteme.site/w/index.php?title=Template:Sortname/doc&direction=next&oldid=640211664 edited by Izkala (talk | contribs) at 12:44, 9 June 2015 (Deprecation warning).

If I search for Sortname in https://wiki.riteme.site/wiki/Wikipedia:Templates_for_discussion there are no matches. https://wiki.riteme.site/w/index.php?search=Sortname+prefix%3AWikipedia%3ATemplates+for+d&title=Special:Search&profile=default&fulltext=1&searchToken=4wq7eic3dcfe8x18phv7k1mud

The calling interface to {{Sortname}} was clean, concise and logical. The suggested replacement user interface is none of these. Why was the original template not converted to a wrapper that accessed the new interface transparently?

Compare: 

{{Sortname|The|Opera of How Ivan Ivanovich Quarrelled with Ivan Nikiforovich}}

with 

data-sort-value="Opera of How Ivan Ivanovich Quarrelled with Ivan Nikiforovich, The"|The Opera of How Ivan Ivanovich Quarrelled with Ivan Nikiforovich|

Back in 2007 and 2008 (archive 1 and 2), the people working on Sortname and its predecessors correctly decided that repeating the name or noun phrase twice (once as a display string and once reordered as a sort key) was a waste of time and editor effort, and that the parameter order for the sort should be as close as possible to the unsorted string, eg to sort "Tony Blair" by surname the function should be as simple as {{Sortname|Tony|Blair}}. As I said, 'clean, concise and logical'... Scarabocchio (talk) 09:53, 6 March 2017 (UTC)

@Scarabocchio: Nothing has "happened" to it. The functionality is exactly the same as it was when CharlotteWebb (talk · contribs) rewrote it almost nine years ago. The only edits in the meantime that were not reverted have been to remove an interlanguage link, add some classes, and add a tracking category. --Redrose64 🌹 (talk) 10:48, 6 March 2017 (UTC)

Reverting deprecation note

I've reverted the deprecation note as seen here, instead making it an informational template linking to WP:SORT. I'm not sure why this note was added, as I use this and have seen other editors use it. Please ping me if you comment. Erik (talk | contrib) (ping me) 18:34, 9 June 2017 (UTC)

See Template talk:Sort/Archive 2 for previous discussions in the same vein. – Jonesey95 (talk) 19:39, 9 June 2017 (UTC)

Sortname honorific prefix (Sir etc)

Can sortname be given an option to add displayed titles like Sir, Rev, Dr etc which are neither linked to nor sorted on? Greenshed (talk) 00:35, 19 April 2018 (UTC)

The second parameter is ordinary wikitext, so {{Sort|Wales James|Sir [[Jimmy Wales]]}} (Sir Jimmy Wales) will do that. -- Michael Bednarek (talk) 01:54, 19 April 2018 (UTC)
Thanks but I was hoping for something like {{sortname|James|Wales|ttl=Sir|dab=British Army officer}} which would display Sir James Wales, link to James Wales (British Army officer) and sort on Wales, James. Greenshed (talk) 00:26, 20 April 2018 (UTC)
You are in the wrong place. This template doesn't have a parameter |dab= – {{Sortname}} does. Still, what you want to do can be done with
{{Sort|Wales James|Sir [[Jimmy Wales (British Army officer|Jimmy Wales]]}}: Sir Jimmy Wales.
Good luck. -- Michael Bednarek (talk) 05:04, 20 April 2018 (UTC)
Oh bugger, I just realised that Template talk:Sortname redirects here, so you are not in the wrong place. Still:
Sir {{Sortname|James|Wales|dab=British Army officer}} gives: Sir James Wales
-- Michael Bednarek (talk) 05:32, 20 April 2018 (UTC)
Thanks again. Just to check, wouldn't "Sir {{Sortname|James|Wales|dab=British Army officer}}" sort on "Sir Wales, James" though? Greenshed (talk) 05:53, 20 April 2018 (UTC)
I think you're right. That leaves the 1st suggestion above, or omitting "Sir" per MOS:HON ("honorific titles Sir ... are included in the initial reference ... for the subject of a biographical article, but are optional after that."), or prepending "Sir" to the first name field in {{Sortname}}, or extending that template as you suggested – which is above my pay grade. Sorry. I've always used the simpler but more laborious combination of {{hs}} and ordinary text + wikilinks, very similar to the {{Sort}} example above. -- Michael Bednarek (talk) 06:34, 20 April 2018 (UTC)

Template-protected edit request on 8 December 2019

This template is marked as deprecated. Please see below a suggestion to undeprecate it:

data-sort-value="{{{2|{{{last}}}}}}, {{{1|{{{first}}}}}}"|{{#if:{{{nolink|{{#ifeq:{{{1|{{{first|}}}}}}{{{2|{{{last|}}}}}}{{{dab|}}}|-|1}}}}}
      |{{{1|{{{first}}}}}} {{{2|{{{last}}}}}}
      |[[{{{3|{{{link|{{{1|{{{first}}}}}} {{{2|{{{last}}}}}} {{#if:{{{dab|}}}|({{{dab}}})}}}}}}}}|{{{1|{{{first}}}}}} {{{2|{{{last}}}}}}]]
}}<noinclude>{{documentation}}</noinclude>

Guarapiranga (talk) 12:08, 8 December 2019 (UTC)

Can you provide a sandbox and testcases that show the code above is suitable? -- Michael Bednarek (talk) 12:58, 8 December 2019 (UTC)
Sure can, Michael Bednarek: Template:Sortname/sandbox, Template:Sortname/testcases (not sure why Template talk:Sortname is redirected here to Template talk:Sort, though). Guarapiranga (talk) 13:05, 8 December 2019 (UTC)
The sandbox version does not display correctly in the "Interactions between dab and param4" table. – Jonesey95 (talk) 15:34, 8 December 2019 (UTC)
Deactivating request while sandbox & testcasing continues. Reactivate the request when it's ready. Cabayi (talk) 08:27, 10 December 2019 (UTC)

sortname produces garbage output if the “optional link target” contains an Interlanguage wiki link or the {{ill}} template, e.g.

{{sortname|Marie de|Hennezel | :fr:Marie de Hennezel }}

outputs

Marie de Hennezel


and

{{sortname|Marie de|Hennezel | {{ill|Marie de Hennezel|fr}} }}

outputs

[[Marie de Hennezel|Marie de Hennezel]]

Jim Craigie (talk) 13:42, 19 July 2020 (UTC)

It's not a fault of {{sort}}, but a feature of templates in general - ignoring whitespace, if a parameter begins with one of the four characters used for list markup, the parameter is processed as a list. See H:T#Problems and workarounds. --Redrose64 🌹 (talk) 15:13, 19 July 2020 (UTC)
Thanks. I added an example to template:Sortname/doc#Note having found it works here:
Hanning Schröder Marie de Hennezel
— but now I find these give no output anywhere else — I don’t understand that! Jim Craigie (talk) 07:24, 20 July 2020 (UTC)
That's because the literal colon (:) is normally required. // I would caution against using direct interlanguage links like de:Hanning Schröder or fr:Marie de Hennezel. The functionality of {{ill}} is much superior. I think in these rare cases a more elaborate construct is called for: <span data-sort-value="Hennezel, Marie de">{{ill|Marie de Hennezel|fr}}</span> : Marie de Hennezel. -- Michael Bednarek (talk) 10:37, 20 July 2020 (UTC)

Questioning the deprecation of sortname

 You are invited to join the discussion at Wikipedia:Village pump (technical)/Archive 183#Sorting list of names by last name. {{u|Sdkb}} talk 19:28, 24 August 2020 (UTC)

Template-protected edit request on 30 July 2021

Please upgrade template to the sandbox version, which includes the |noredlink= option for when it's not clear a page will ever be created for the person (and automatically becomes a link if it is). — Guarapiranga ☎ 08:15, 30 July 2021 (UTC)

 Not done This seems to break the "Interactions between dab and param4" table in the test cases. Also, I would prefer to minimize the number of unrelated changes in the sandbox; your sandboxed code does a lot of refactoring of the code that seems to have nothing to do with adding the new parameter, making it harder for me to understand what you are actually changing. * Pppery * it has begun... 23:27, 12 August 2021 (UTC)

Template-protected edit request on 28 May 2022

Add id tag for indexing and redirecting (to people who don't have an article, but are mentioned elsewhere, for instance), as exemplified in the sortname/sandbox. — Guarapiranga ☎ 22:12, 28 May 2022 (UTC)

If the template is used twice on the same page with identical pairs of values for |first=/|last=, the effect will be to have two <span> tags with identical values for the id= attribute, which is forbidden by the HTML spec. --Redrose64 🌹 (talk) 22:37, 28 May 2022 (UTC)
Is that also a problem with duplicate subheadings? — Guarapiranga ☎ 00:28, 29 May 2022 (UTC)
Yes. --Redrose64 🌹 (talk) 18:49, 29 May 2022 (UTC)
Right. So I'm not proposing to break a protocol WP doesn't already. The benefit is indexing all the people who are notable enough to be part of a notable list (e.g. supercentenarians), but not notable enough to have an article of their own. — Guarapiranga ☎ 05:47, 30 May 2022 (UTC)
a) I don't think duplicate headings in articles result in duplicate <span>id=… occurrences; MediaWiki will generate distinct spans. b) If an anchor for a list entry is needed, the template {{anchor}} is the obvious answer, and I've come across many lists doing so. -- Michael Bednarek (talk) 09:22, 30 May 2022 (UTC)
Please don't shove more and more functionality into a one issue technical template. Template sorting is very delicate and we should keep templates like these as simple as possible. —TheDJ (talk • contribs) 10:57, 30 May 2022 (UTC)
 Not done for now: looks like a consensus needs to be established for this alteration. Please garner the needed consensus before using the {{edit template-protected}} template again. P.I. Ellsworth , ed. put'r there 16:04, 30 May 2022 (UTC)

Prefixes, suffixes and hCards

How are prefixes and suffixes handled by the hCard in {{sortname}}? I know {{sortname}} can accommodate names with prefixes and suffixes by simply using optional targets, but can the hCard pick up the honorific-prefix and honorific-suffix classes from that? Perhaps it'd be interesting to have |prefix= and |suffix= parameters for those. — Guarapiranga ☎ 02:25, 7 June 2022 (UTC)

"This template should be avoided" notice

Is this notice still correct? After some digging I found this village pump discussion from 2020, which resulted in the removal of a similar notice from {{Sortname}}. Olivaw-Daneel (talk) 03:30, 5 August 2022 (UTC)

No its still a bad idea to use this. With sortname at least you know all your data is textual. With this template you have no clue. Table sorting is really sensitive when it comes to types and especially type detection. This template is so 'generic' it is asking for problems. People really should use the proper method, or at least a more targeted sorting template like nts, dts or sortname —TheDJ (talk • contribs) 09:05, 5 August 2022 (UTC)

I followed the instructions on this page, but trying to put in an interlanguage inline link didn't work at all. The template just output nothing at all, not even the name. 2604:3D08:7481:AF00:B46F:F39B:F1E1:2013 (talk) 11:26, 27 September 2022 (UTC)

What page are you attempting to do this on? Examples are essential in situations like this. --Redrose64 🌹 (talk) 11:37, 27 September 2022 (UTC)
Multiple international versions of The Amazing Race, such as The Amazing Race 1 (China). There is a contestant list on the page wherein we use Sortname. On the given example one of the contestants, Jin Dachuan, needs a link to "金大川" on zh-yue Wikipedia. But when I put in {{sortname|Jin|Dachuan|:zh-yue:金大川}} it just outputs nothing. I also tried putting in the example given on the instructions page, {{Sortname|Hanning|Schröder|:de:Hanning Schröder}} and that didn't work either, just output nothing. (I'm using the "& # 5 8 ;" for the first colon, but I don't know how to get that to display on this talk page. View the source to see what I've typed) 2604:3D08:7481:AF00:4C3D:B7B6:DAEE:DAA7 (talk) 20:50, 27 September 2022 (UTC)
Ah, so you're using {{sortname}}, not {{sort}}. You should have said so at the start. Anyway, {{sortname|Jin|Dachuan|&#58;zh-yue:金大川}} → Jin Dachuan and {{Sortname|Hanning|Schröder|&#58;de:Hanning Schröder}} → Hanning Schröder so I don't see what the problem is. --Redrose64 🌹 (talk) 21:32, 27 September 2022 (UTC)
Forgive me, I clicked on the "Talk" button at the top of "sortname" and it took me here. I didn't even notice I was on an entirely different template's talk page, and I don't know why it took me there. Anyway, the directions on the page told me to type {{Sortname|Hanning|Schröder|:de:Hanning Schröder}}, not {{Sortname|Hanning|Schröder|&#58;de:Hanning Schröder}}, so that's one issue that should probably be fixed. But besides that, you can see here when I try to implement it, the link points to the Ampersand page, instead of the correct destination. It might be more helpful if you or somebody could go to the The Amazing Race 1 (China) page an implement the link on Jin's name for me, and then I'll just use that as a base so I know what to do and can fix the other pages. 2604:3D08:7481:AF00:E40D:3AC3:9A59:570 (talk) 03:17, 28 September 2022 (UTC)
Do exactly as I did above, the link works, so copy that code. --Redrose64 🌹 (talk) 19:34, 28 September 2022 (UTC)
I did that, and I told you already that I tried it here and it just links to the Ampersand page. I don't know why you have this attitude, but you're being really unhelpful. Please just take two seconds out of your day to add it to The Amazing Race 1 (China) and I will spend the hours doing the rest of the work, because I can't figure out what I'm doing wrong and apparently neither can you. 2604:3D08:7481:AF00:404B:12DF:DC21:971F (talk) 23:11, 28 September 2022 (UTC)
Except that you didn't. This is what I did: Jin Dachuan; and this is what you did: Jin Dachuan. Do you see the difference? --Redrose64 🌹 (talk) 20:32, 29 September 2022 (UTC)
Yes, and now look where we are. We're right back where we started with the interlink not working at all. Click here and see. I have asked you three times now to Just. Put. The. Link. Onto. The Amazing Race 1 (China). Page. And yet for some reason you won't do this. Your condescending attitude is really sickening and extremely unhelpful. I don't know why you feel the need to be so rude to someone who's having trouble using the template that this talk page is all about. I'm just gonna go ahead and drop a 'Help Me' below and someone else besides you can help, because I'm done dealing with you.

See above. Template isn't working, have provided examples of the template not working, user Redrose64 is being condescending and unhelpful. 2604:3D08:7481:AF00:C571:1D0C:7B73:CCA5 (talk) 23:39, 29 September 2022 (UTC)

Try {{sortname|Jin|Dachuan|:zh-yue:金大川}} instead of {{sortname|Jin|Dachuan|&#58;zh-yue:金大川|Jin Dachuan}}, as Redrose64 above has suggested. I dream of horses (Contribs) (Talk) 00:31, 30 September 2022 (UTC)
That doesn't work either. I really don't understand why someone with more knowledge can't take a minute to try and add this template themselves to The Amazing Race 1 (China) instead of wasting time telling me to try things that I've already tried before that don't work. 2604:3D08:7481:AF00:C571:1D0C:7B73:CCA5 (talk) 00:57, 30 September 2022 (UTC)
I've looked at this just a bit and find that the behavior is not consistent. Working with the example on the doc page Template:Sortname/doc#Note using Hanning Schröder as an example, I can, with various codings, get a) nothing b) a link to the de-wiki article, but it previews here as ampersand, and c) a link to the en-wiki article. And it seems to be somewhat context-dependent, since Redrose's formulation above gets the nothing result when used verbatim on the template doc page (I'm just looking at the preview) even though it clearly works on this page. One additional wrinkle is that {{sortname}} is intended to only be used in a table cell. I'm not seeing anything explanatory in the source code for sortname, either.
I've run into difficulties arguably caused by sortname before, but never got around to resolving that one, either.
Indeed (for the record) I am intending to use sortname in a table cell. 2604:3D08:7481:AF00:C571:1D0C:7B73:CCA5 (talk) 03:29, 30 September 2022 (UTC)
My impression so far is that the problem stems from this property of the template language, outlined here. I'm still no further along at understanding the observed inconsistencies. — jmcgnh(talk) (contribs) 04:33, 30 September 2022 (UTC)

 Done I found that using URL encoding %3A for the initial colon works in all the contexts where I tested it. So I updated the doc page for the template and updated the entry you were having trouble with on The Amazing Race 1 (China). — jmcgnh(talk) (contribs) 04:58, 30 September 2022 (UTC)

At last. Thank you very much. 2604:3D08:7481:AF00:C571:1D0C:7B73:CCA5 (talk) 05:18, 30 September 2022 (UTC)

Why can't the template sort negative numbers properly?

While experimenting in my userpage, I noticed that when the sort template is given a parameter that is a negative number with commas, it correctly sorts negative numbers first, but the numbers aren't arranged correctly (with the negative numbers descending and the positive numbers ascending). Instead, it ignores the negative signs and lists the negative numbers in ascending order, treating the commas as characters, meaning numbers with commas are listed first. When the commas are removed, negative and positive numbers are listed separately, sorted in ascending order according to their absolute value. However, when the numbers are entered plainly into a sortable wikitable, it correctly follows the numerical order. Why is this, and can the sort template be fixed so that it follows numerical order? Atlantis536 (talk) 03:07, 21 October 2022 (UTC)

Number With sort template Sort template without commas Sort with type number
-1,234,567,890 -1,234,567,890 -1234567890 -1,234,567,890
-1,123,456,789 -1,123,456,789 -1123456789 -1,123,456,789
-123,456,789 -123,456,789 -123456789 -123,456,789
-112,345,678 -112,345,678 -112345678 -112,345,678
-12,345,678 -12,345,678 -12345678 -12,345,678
-11,234,567 -11,234,567 -11234567 -11,234,567
11,234,567 11,234,567 11234567 11,234,567
12,345,678 12,345,678 12345678 12,345,678
112,345,678 112,345,678 112345678 112,345,678
123,456,789 123,456,789 123456789 123,456,789
Have you tried to follow the advice in the top message overleaf ("This template should be avoided. …") and use data-sort-value= instead? What happens then? -- Michael Bednarek (talk) 03:36, 21 October 2022 (UTC)
Numbers are sorted properly now. Thanks. Atlantis536 (talk) 04:31, 21 October 2022 (UTC)
Because the sort template causes an alphabetic sort. "when the numbers are entered plainly [..] it correctly follows the numerical order". This is because of autodetection, which checks the first five cells to determine a likely datatype and then selects the appropriate sorting algorightm to go with that. However the sort template disables this autodetection and causes alphanumberical sort. The best way is to coerce a sort algorithme, by using the data-sort-type on the column in question, as advised on Help:Sorting#Forcing_a_column_to_have_a_particular_data_type and to use data-sort-value to override the sort value of a cell. There is also template {{nts}}, which does it's own number formatting to an alphanumerica value that has numeric sorting capabilities, which you should just not use at all. —TheDJ (talk • contribs) 08:16, 21 October 2022 (UTC)

Why does Template:Sortname not have its own talk page?

Why does Template talk:Sortname redirect to here? As I understand it, {{Sortname}} and {{Sort}} are two different templates – so why doesn't {{Sortname}} have a separate talk page? --IJBall (contribs • talk) 22:40, 4 April 2023 (UTC)

If Trialsanderrors (who was last active a month ago) has a remarkable memory they may be able to tell you why it was thought to be a good idea 16 years ago! 213.18.145.207 (talk) 22:55, 4 April 2023 (UTC)
@IJBall: The two templates are closely related. Both set up a <span>...</span> element having a data-sort-value= attribute to hold the actual sortkey, which is yielded by Module:Sortkey. --Redrose64 🌹 (talk) 23:13, 4 April 2023 (UTC)
But they've had separate unique problems. Sortname was deprecated, until it wasn't (and which I'm still unclear whether that was a good call or not). I just saw a recent post in the archives with someone was saying Sortname might be OK to use in a table but Sort (number) still shouldn't be.
They may be related, but it sounds to me like have separate unique problems, which implies to me that each should have its own Talk page. --IJBall (contribs • talk) 23:46, 4 April 2023 (UTC)

Handling Jr. and Sr.

I see I did wrong a while back in edits such as this one, where I was mainly targeting ref entries, and wasn't aware of the sortname template behavior. The documentation, if the template is not deprecated as suggested above, should at least say something about how Jr. and Sr. are handled. Dicklyon (talk) 05:24, 13 September 2023 (UTC)

It's easy to use {{ill}} to turn

[[Seán Ó Cuirreáin]]

into

{{ill|Seán Ó Cuirreáin|ga}}

But for the equivalent {{sortname}}

{{sortname|Seán|Ó Cuirreáin||Ocuirreain}}

I had to hack it to

<span data-sort-value="Ocuirreain">{{ill|Seán Ó Cuirreáin|ga}}</span>

It should be simple to add optional parameter ill thus:

{{sortname|Seán|Ó Cuirreáin||Ocuirreain|ill=ga}}

jnestorius(talk) 15:39, 14 October 2023 (UTC)

There are a dozen other functionalities that are rarely used that can also be merged into the template. But that will just create more problems. This template in its basis isn't really needed, nor is ill. They are just a shorthand for very common situations.
As a matter of fact, the ill template itself shows why combining too many functionalities makes things harder to work with. Because there is always even more functionality that is missing too be added, some of which might be incompatible with what was defined before.
I suggest to just use template sort, or the data-sort-value attribute directly as you showed. That is a simple and fine solution. Alternatively, create a new meta template, that combines the effects of the two templates. Then at least each template keeps having a well defined purpose. —TheDJ (talk • contribs) 17:31, 14 October 2023 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Sort/Archive_2&oldid=1218592077"