[HN Gopher] When I say "alphabetical order", I mean "alphabetica...
___________________________________________________________________
When I say "alphabetical order", I mean "alphabetical order"
Author : sebtron
Score : 299 points
Date : 2025-09-28 13:00 UTC (9 hours ago)
(HTM) web link (sebastiano.tronto.net)
(TXT) w3m dump (sebastiano.tronto.net)
| Someone wrote:
| https://www.unicode.org/reports/tr10/#Contextual_Sensitivity:
|
| "There are additional complications in certain languages, where
| the comparison is context sensitive and depends on more than just
| single characters compared directly against one another,
|
| [...]
|
| Numbers. A customization may be desired to allow sorting numbers
| in numeric order. If strings including numbers are merely sorted
| alphabetically, the string "A-10" comes before the string "A-2",
| which is often not desired. This behavior can be customized, but
| it is complicated by ambiguities in recognizing numbers within
| strings (because they may be formatted according to different
| language conventions). Once each number is recognized, it can be
| preprocessed to convert it into a format that allows for correct
| numeric sorting, such as a textual version of the IEEE numeric
| format."*
|
| I think those file browsers made the right choice, even given
| that they don't (as in this example) always do the right thing.
| afrisch wrote:
| But -10 is smaller than -2, right?
| JoshTriplett wrote:
| Filenames rarely have negative numbers in them, and it'd
| usually be ambiguous whether they were negative or dash-
| separated positive.
| JoshTriplett wrote:
| I almost always want the version-sorting that's being presented
| in this article, rather than an "alphabetical" sort. But on the
| other hand, it absolutely seems like a valid bug that this is
| presented as an "alphabetical" sort, rather than something like
| "alphabetic/numeric" or similar. In other words, a problem of
| labeling rather than one of sorting.
| lisper wrote:
| Yeah, exactly. The behavior described is actually very useful.
| The problem is imposing it on the user with no warning or
| option to turn it off.
| sebtron wrote:
| Author here - I Agree both with you and with the parent's
| comment. Having two options in the "sort by menu" - like
| "Name (natural)" and "Name (strict)" or something - would
| have solved everything.
| parineum wrote:
| > The problem is imposing it on the user with no warning or
| option to turn it off.
|
| You can say that about every single design decision made
| about every product.
|
| The gripe about this particular feature seems misplaced
| because almost all users will want the sort that's offered
| and the actual alphabetical sort is likely the desire of a
| more advanced user who, in fact, is offered a choice through
| registry editing and/or using a more advanced cli option for
| the occasion they might need an alternative sort.
|
| This is a sensible default.
| lisper wrote:
| > You can say that about every single design decision made
| about every product.
|
| No, that's not true. Many aspects of my computer's UI are
| user-configurable.
| mtoner23 wrote:
| Yes but not every single one of them
| lisper wrote:
| Obviously. All I'm saying is that this particular
| decision ought not to have been taken from the user. Real
| alphabetical order is not an unreasonable thing to want.
| hchdifnfbgbf wrote:
| "Real alphabetical ordering" is incredibly nonspecific.
| It's underspecified even for ASCII-US, but essentially
| meaningless for those of us in 2025 who need to handle
| Unicode.
|
| How do capital letters sort relative to lowercase
| letters? How do letters sort relative to digits? How do
| you consider code points that can correspond to different
| letters in different lettering systems with different
| ordering? How do you handle diacritics? Do you want the
| behaviour to be stable through Unicode normalization?
| Should it differ based on the character encoding? Should
| different representations of the same character, such as
| blackboard lettering or circled numbers, be sorted with
| other representations of the same character or grouped
| separately?
|
| You can come up answers for these questions, but there's
| no unambiguously correct option. The least subjective
| option is sorting based on encoded byte representation
| (if that is even specified), but that is not
| "alphabetical" and would not be intuitive to most users.
| lisper wrote:
| The issue at hand is how _numbers_ are sorted. That has
| nothing to do with unicode.
| hchdifnfbgbf wrote:
| Unicode has many different representations of digits, and
| I would dispute using the term "alphabetical" to refer to
| digit ordering in any case.
| plorkyeran wrote:
| It's not being presented as an alphabetical sort, though. The
| author assumed that sorting by name meant an alphabetical sort,
| but that's not how it's labeled.
| lsaferite wrote:
| In fairness, sorting by name has, for many years, been an
| alphabetic sort. Doing a mixed alpha/numeric sort is a
| relatively new thing.
| xerox13ster wrote:
| The term for the sort in the article is called lexical, but the
| problem is the people are stupid.
|
| The average user does not know the difference between lexical
| and alphabetic sort
| bee_rider wrote:
| Notably, some versions of "sort" on Linux have version sort
| nowadays. sort -V
|
| I actually don't know exactly how it works internally and it is
| a little bit magical, but I use it all the time when looking
| through my files because it just sorta works in most cases. Of
| course a nice thing about it is easy to turn on or off.
| jmclnx wrote:
| If I understand the article, the author wants magic :)
|
| I take it to mean they want the system to know file_9.txt is less
| then file_10.txt.
|
| I never saw that happen in any OS, so I do not know what he is
| referring to. Maybe whatever that old system was, it sorted by
| create time as opposed to file name.
|
| So, the author can try and create "aisort" that will look at all
| file names and add leading zeros to the file numeric portion,
| sort, then remove the zeros added. That will probably as slow as
| s***t and use gobs pf memory, depending on the number of files.
| anopenben wrote:
| No the author is saying the opposite. They expect file9.txt to
| be after file10.txt, but it many modern operating systems, it
| isn't!
| jmclnx wrote:
| Really, I do not know how I missed that :) I read it a couple
| of times to and I still thought he wanted it the other way.
|
| So my original comment kind of stands but in a opposite way.
|
| I have never see file_9.txt sorted before file_10.txt, I just
| tested it on OpenBSD and I got this, which I have always
| seen:
|
| $ ls|sort
|
| file_1.txt
|
| file_10.txt
|
| file_12.txt
|
| file_2.txt
|
| file_20.txt
|
| file_3.txt
|
| file_9.txt
| sebtron wrote:
| Author here - My surprise stems exactly from the fact that
| for the last few years I have exclusively managed my files
| via a the UNIX shell, which behaves in the classical way.
| zahlman wrote:
| When I started using Linux as my daily driver after many
| years of Windows (but with familiarity with UNIX systems
| going way back), I knew it would be like that in the
| terminal, but it still took some adjustment. But
| actually, Nemo does the same "natural sort" thing, and
| also sorts case-insensitively.
| mackeye wrote:
| i think it's the opposite, that they _want_ file_10.txt to come
| before file_9.txt by default, but that file explorers fail at
| this. it's rare that i want true alphabetical sort, but it's
| convenient for cases like tfa where alphabetical sort is more
| predictable if i have filenames that look like
| <letters>_<numbers-of-same-length>.txt.
| uqers wrote:
| That's not what the author says- they said that file managers
| actually are somehow sorting file-9.txt before file-10.txt, and
| it's breaking real alphabetical ordering.
| HeavyStorm wrote:
| Nope, you got it completely reversed.
| meindnoch wrote:
| >I take it to mean they want the system to know file_9.txt is
| less then file_10.txt.
|
| The polar opposite, actually.
| nebezb wrote:
| It's not magic. It's called natural sort and it doesn't require
| gobs of memory. Most (all?) modern OS file managers will
| natural sort on file names.
| 1970-01-01 wrote:
| Digits and any other characters that are not A-Z and a-z should
| not get sorted. That's the true result of doing what you asked
| and not what you meant. Pedantic, but that's why we are here.
| orphea wrote:
| > Digits and any other characters that are not A-Z and a-z
| should not get sorted.
|
| Do you suggest that sorting in any language other than English
| should be broken?
| 1970-01-01 wrote:
| No.
| pbw wrote:
| "I created the Alphanum Algorithm to solve this problem. The
| Alphanum Algorithm sorts strings containing a mix of letters and
| numbers. Given strings of mixed characters and numbers, it sorts
| the numbers in value order, while sorting the non-numbers in
| ASCII order. The end result is a natural sorting order."
|
| https://web.archive.org/web/20210207124255/http://www.daveko...
| JoshTriplett wrote:
| There are many older instances of that, such as "versionsort"
| from various Linux tools and libraries. I think this has likely
| been independently recreated several times, with various subtle
| differences.
| HeavyStorm wrote:
| When you get a bunch of files (let's say 1000+) without leading
| zeroes, this is a blessing. But I get the author's frustration,
| the expected behavior is not there, instead, he gets magical
| sorting that is wrong for his use case. I'm not sure what the ux
| should be, and maybe the algorithm here could be smarter, but
| it's a trade-off.
| nebezb wrote:
| > the expected behavior is not there
|
| The expected behaviour is ambiguous (and thus subjective).
| Older versions of windows shipped with alpha sort. New versions
| ship with natural alpha sort. According to the UX designers
| over at Microsoft (and surely the user feedback), natural sort
| _is_ the expected behaviour.
|
| I certainly agree with natural sort being the expected
| behaviour too.
| dfxm12 wrote:
| I get it, but if all these major operating systems are handling
| this same ambiguous [0] situation in the same way, perhaps one
| needs to reevaluate their mental model or expectations.
|
| _Am I out of touch? No, it 's the operating systems who are
| wrong_
|
| 0 - numbers are not part of the alphabet.
| vachina wrote:
| That's why I don't even bother with the file name for photos.
|
| 1. Sync all equipments to the same clock.
|
| 2. Sort by Date Taken, if unavailable, sort by Date Created.
| alain94040 wrote:
| Yes, sounds to me like the user really wanted to sort by time
| created. And got used to sorting alphabetically as a poor proxy
| for that.
| sverhagen wrote:
| When copying files from a device and then between systems,
| too often the dates get lost (shouldn't, but still...)
| shaan7 wrote:
| That only happens for the datetime metadata of the files
| (modified, created, access etc). The EXIF metadata will
| still remain the same.
| meindnoch wrote:
| I thought this was pretty well known. E.g. the macOS Foundation
| library even exposes NSString.localizedStandardCompare() [1]
| which implements the sorting algorithm used by Finder, and should
| be used by any well-behaved macOS application. Windows uses
| StrCompareLogical [2].
|
| [1]
| https://developer.apple.com/documentation/foundation/nsstrin...:)
|
| [2] https://learn.microsoft.com/en-
| us/windows/win32/api/shlwapi/...
| freetime2 wrote:
| I would have assumed it worked the same as ls, so I found the
| article interesting. But now that I know, I think this way is
| better.
|
| I can't think of any case where I would _need_ purely
| alphabetical sort. In most photo browsing apps, photos will be
| sorted by timestamp rather than filename. If I really needed it
| to sort properly in file explorer, I would try sorting on
| created date. And failing that I would probably just normalize
| the file names.
| nenenejej wrote:
| Sort by the time the photo was a taken in the metadata?
| furyofantares wrote:
| Numbers aren't in the alphabet. So no, you don't mean
| alphabetical order.
| furyofantares wrote:
| I felt a little bad about this snark but actually, author
| barely understands their own use case (says they want
| alphabetical order but they actually want something more) and
| barely understands the UI they're using (says they asked for
| alphabetical order but none of the file managers they used says
| it has any such setting) and then they go on to claim this is
| to satisfy dumb users:
|
| > Well, apparently all these operating systems have decided
| that no, users are too dumb and they cannot possibly understand
| what alphabetical order means.
| crazygringo wrote:
| It really is world-class irony. Impressive.
| xerox13ster wrote:
| this is an ID-10T PEBKAC ERR.
|
| Not this keyboard not this chair, but the problem is with idiots
| between keyboards and chairs.
|
| The author is not the ID10T it's the other general users.
|
| The author is intelligent enough to recognize that this is not
| alphabetical sort, but the term that they are looking for to
| describe the sort that they see in dolphin windows, google etc.
| is * _lexical*_ sort, not alphabetical.
|
| The engineering problem is ID10Tic not technical. How do you
| educate an illiterate public on what the difference between
| alphabetical and lexical sort is in practice?
|
| You can't, so you engineer around it and call lexical sort
| alphabetical.
| armchairhacker wrote:
| I agree with Microsoft/Google/KDE's order. The author's situation
| is extremely rare, and the situation where someone wants "10" to
| be before "9" is far more common. Moreover, desktops don't label
| this sorting "alphabetical" (E: and it would really be
| "lexicographic"*), they label it "by name" (an informal
| criteria), so technically they're not lying.
|
| > I miss the time when computers did what you told them to,
| instead of trying to read your mind.
|
| You may be looking at that time through rose-tinted glasses. I
| don't like when computers _lie_ to me either, but "mind-reading"
| is really helpful in ways we take for granted, like autosave.
| Desktops can have an option to sort files truly alphabetically,
| but the more common case should always be the default; that's the
| definition of "intuitive".
|
| * https://news.ycombinator.com/item?id=45404022#45405279
| zweifuss wrote:
| You mean file9 before file10?
|
| I have some beef with microsoft, that you can only change this
| at the Computer level, not per user (see registry key below).
| Also they call it natural sorting for users, but logical
| sorting internaly. Unify your termini!
|
| [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\P
| olicies\Explorer] "NoStrCmpLogical"=dword:00000001
| nerdile wrote:
| To change it per user, set it in the user's hive instead of
| in the local machine hive (e.g. HKEY_CURRENT_USER instead of
| HKEY_LOCAL_MACHINE)
| yegle wrote:
| TIL they are called "hives". Windows Registry is an
| interesting thing. Even casual users have to interactive
| with it once or twice w/o fully understand it.
|
| https://learn.microsoft.com/en-
| us/windows/win32/sysinfo/regi...
| kens wrote:
| Raymond Chen explained why a registry file is called a
| "hive":
|
| Because one of the original developers of Windows NT
| hated bees. So the developer who was responsible for the
| registry snuck in as many bee references as he could. A
| registry file is called a "hive", and registry data are
| stored in "cells", which is what honeycombs are made of.
|
| https://devblogs.microsoft.com/oldnewthing/20030808-00/?p
| =42...
| williamjackson wrote:
| https://devblogs.microsoft.com/oldnewthing/20030808-00/?p
| =42...
| kens wrote:
| Thanks for fixing the link!
| whycome wrote:
| The file sorting isn't something relegated to niche users
| because of the prevalence of tv episode file name sorting (eg
| S01e01) and it has necessitated the leading zeroes to make it
| work properly with "alphabetical sorting".
| queenkjuul wrote:
| And that would sort correctly with both methods, though,
| especially when each "field" is delineated (e.g.
| Show.S0XE0Y.Episode.Name.HEVC.1080p.mkv)
| derriz wrote:
| I'm not sure I agree. I think I could be convinced if there was
| a unique and universal representation for numeric values using
| characters.
|
| But we have so many textual representations of numeric values
| that I'm assuming the "mind-reading" goodness only works for a
| small subset. And the subset will be somewhat intuitive for
| developers but unlikely to be so for non-technical people.
|
| For example, does the order handle numbers with fractions
| (decimal points)? If yes, does it require a at least one
| leading digit (zero)? Does a.12345 come before or after a.345?
|
| Does it handle thousand separators? What about international
| thousand and decimal separators (e.g. Euro-style . for thousand
| separation and , for decimal separation).
|
| Does it handle scientific notation?
|
| If the answer is no to any of these questions, it's likely to
| lead to surprise/confusion.
|
| It's like a feature request that initially sounds reasonable
| and useful but once you explore the requirements in detail you
| realize there are too many edge cases to be able to meet the
| request in a non-brittle way.
| queenkjuul wrote:
| Are filenames likely to include those representations? I feel
| like probably not (can you even include commas in Windows
| filenames?)
|
| More to the point of the article--if you want things sorted
| by date, sort by date. I think most laypeople aren't looking
| at long CHAR1234_5678 filenames anyway, they're looking at
| thumbnails and dates.
| mulmen wrote:
| > can you even include commas in Windows filenames?
|
| Yes.
|
| > Use any character in the current code page for a name,
| including Unicode characters and characters in the extended
| character set (128-255), except for the following: The
| following reserved characters:
|
| < (less than)
|
| > (greater than)
|
| : (colon)
|
| " (double quote)
|
| / (forward slash)
|
| \ (backslash)
|
| | (vertical bar or pipe)
|
| ? (question mark)
|
| * (asterisk)
|
| https://learn.microsoft.com/en-
| us/windows/win32/fileio/namin...
| derriz wrote:
| The most common date format used in Europe uses period
| separators so can often appear in filenames. Commas are
| probably more rare. Things like versions are often
| fractional like v1.3 or v1.11 and can appear embedded in
| filenames.
| crazygringo wrote:
| > _if you want things sorted by date, sort by date_
|
| Unfortunately it doesn't work. When I copy the files, they
| all get new dates in whatever random order they happened to
| be copied in.
| coldtea wrote:
| Ah, the classic filenames with decimal points and scientific
| notation in them, so common...
| II2II wrote:
| Here's a different scenario: filenames with dates in them.
| Consider _September Budget_ and _October Budget_. September
| is the equivalent of 9, October of 10. Which comes first
| for natural sorting? Remember, the file modify date may not
| be useful here since you may have wrapped up the September
| budget on October 1st while the prior edit to the October
| budget may have been on September 20th.
|
| The problem is that there is no such thing as natural, and
| it is quite hard to determine what is more common. (Quite
| often more common is culturally dependent or, worse, contex
| dependent).
| arccy wrote:
| the one true way: budget_09.csv, budget_10.csv
| NekkoDroid wrote:
| Then `budget_100.csv` comes by and now you need to rename
| 99 files.
| xigoi wrote:
| It's been about two thousand years since the number of
| months in a year has been increased. I don't think we're
| getting 88 new ones anytime soon.
| thaumasiotes wrote:
| > It's been about two thousand years since the number of
| months in a year has been increased.
|
| What? What are you thinking of? The number of months in a
| year is always 12 or 13 in any calendar system because
| they start by reflecting the moon. If you mean the
| Christian calendar, it was fixed at 12 months to the year
| well over 2000 years ago. If you mean _any_ calendar, it
| 's probably been more like one year since the number of
| months in a year has been increased. 12 lunar months
| falls short of a solar year by about 11 days, so any
| given lunar calendar will generate an extra month about
| every three years, and there are lots of different lunar
| calendars.
|
| (For example, the Chinese calendar occasionally repeats
| full months in order to keep the month of the year lined
| up with the season. Whenever this happens, there will be
| 13 months in the year, of which two share the same name.)
| coldtea wrote:
| Given that 09 and 10 refer to months, that wont ever
| gonna be a problem. And if you want to differentiate them
| years too, you can prefix with 2025- or put them in a
| 2025/, 2026/ etc folder.
| coldtea wrote:
| Even better, I'd prefer to have more semantic meaning,
| and for budget-2025-09.csv, buget-2025-10.csv to work
| everywhere...
| Certhas wrote:
| So the argument is that because this doesn't solve the
| challenge of ordering all possible strings by semantic
| meaning it should not be used?
|
| Even though it increases the match between semantic
| meaning and string sorting in many important cases and is
| a simple and consistent rule?
| coldtea wrote:
| > _September is the equivalent of 9, October of 10. Which
| comes first for natural sorting? Remember, the file
| modify date may not be useful here since you may have
| wrapped up the September budget on October 1st while the
| prior edit to the October budget may have been on
| September 20th. The problem is that there is no such
| thing as natural_
|
| Yeah, but there _is_ such a thing as "give a predictable
| and consistent way I can name the files so that they sort
| as I want everywhere" which (if different OSes don't try
| to be "smart") would have been to prefix them with the
| numeric date zero padded.
| SAI_Peregrinus wrote:
| Date is already in the metadata, it doesn't need to be in
| the filename.
| crazygringo wrote:
| Have you ever copied a file?
| Certhas wrote:
| The sort rules are simple (1). Treat any consecutive sequence
| of digits as a number when sorting. So for example version
| numbers (which must be massively more common than decimals in
| filenames) work correctly, and 5.9 is indeed smaller than
| 5.10 and the latter is not identical to 5.1 .
|
| Given that this idea goes back more than two decades, has
| been the default behaviour of the most used OSes for many
| years, with no major outcry, I think empirically we can be
| fairly certain that it does not routinely lead to a lot of
| surprises and confusion.
|
| (1) https://en.m.wikipedia.org/wiki/Natural_sort_order
| xigoi wrote:
| > Treat any consecutive sequence of digits as a number when
| sorting.
|
| Based on this description, I have no idea how the following
| would be sorted:
|
| * photo.jpg
|
| * photo1.jpg
|
| * photo01.jpg
|
| * photos.jpg
| crazygringo wrote:
| Does it matter?
|
| There's a user expectation that photo20.jpg comes after
| photo3.jpg.
|
| There's no user expectation around whether photo1.jpg or
| photo01.jpg comes first. Just like there's no user
| expectation around whether photo1.jpg or Photo1.jpg comes
| first. Users also don't have the slightest idea about
| what order punctuation gets sorted in.
|
| Just sort the things that matter in the way users expect
| (natural sort order) and come up with something
| reasonably consistent for the rest.
| kiitos wrote:
| > There's a user expectation that photo20.jpg comes after
| photo3.jpg.
|
| my user expectation is the opposite
|
| i get what you're saying but it's not achievable in
| practice, at least not consistently
| zaptheimpaler wrote:
| I just tried it on Mac, its sorted in the order you
| listed. Extending it a bit, the order is:
|
| photo1 photo01 photo001 photo0001 photo2
|
| So the shorter representation of the same number comes
| first. It does make intuitive sense to me.
| Avshalom wrote:
| 1 and 0 aren't even in the alphabet so in "alphabetical
| order" I still wouldn't know a prior how that's sorted.
|
| I guess? photo.jpg photo[nine].jpg
| photos.jpg photos[zero][one].jpg
| derriz wrote:
| > The sort rules are simple
|
| In considering the simplicity of the rule, I think you're
| using a developers perspective here where we automatically
| classify numbers and have a clear mental model of the
| separation between value and representation.
|
| But I'm not sure how simple it would be to explain to a
| non-technical user why size_5, size_10 and size_15 are in
| order but size_0.25, size_0.5 and size_0.75 are out-of-
| order.
|
| > with no major outcry
|
| I'm regularly amazed at how little non-developer/technical
| users complain about strange and confusing behavior.
| mcny wrote:
| > I'm regularly amazed at how little non-
| developer/technical users complain about strange and
| confusing behavior.
|
| It reminds me of the recent article here titled something
| like "Altoids by the mouthful". We just get used to
| eating cat poop and we never realize it is not a good
| idea to eat cat poop, not that we should make it more
| palatable by chasing the cat poop by chewing Altoids by
| the mouthful.
|
| Edit: for today's lucky ten thousand
|
| https://news.ycombinator.com/item?id=45343449
| quacked wrote:
| > I'm regularly amazed at how little non-
| developer/technical users complain about strange and
| confusing behavior.
|
| I am a highly technical user that works with a lot of
| people with traditional engineering degrees but little to
| no software experience (except as frequent users). The
| answer here is that they've learned that all computer
| software is arcane and mysterious, and so they just
| accept that there will be strange patterns they have to
| pick up on, and that's their role as a user. They don't
| complain about strange and confusing behavior because
| they treat all the behavior as strange and confusing.
| systoll wrote:
| The entire idea that numbers would be treated on a character
| by character basis rather than as numbers is somewhat
| intuitive for developers and not for non-technical people.
|
| The answer to _all_ of those questions is no for
| lexicographic ordering. Lexicographic ordering leads to
| surprise and confusion as a result.
|
| > It's like a feature request that initially sounds
| reasonable and useful but once you explore the requirements
| in detail you realize there are too many edge cases to be
| able to meet the request in a non-brittle way.
|
| It's been on windows and macOS for coming up on 25 years, and
| is in practically every modern UI. It's reasonable.
| raincole wrote:
| Both should be supported.
|
| Perhaps put the uncommon (true alphanumerical order) behind a
| nested menu or something. But the mind-reading-less option
| should be there.
| Denvercoder9 wrote:
| > Both should be supported.
|
| At least in KDE they are, and you can pick whether you want
| natural or alphabetical sorting (which has a case sensitive
| and insensitive variant).
| SkiFire13 wrote:
| > and the situation where someone wants "10" to be before "9"
| is far more common.
|
| I guess you mean "after"? Otherwise it seems to me you're
| agreeing with OP.
|
| > desktops don't label this sorting "alphabetical" (E: and it
| would really be "lexicographic"*), they label it "by name" (an
| informal criteria), so technically they're not lying.
|
| FYI the more formal name for the "by name" order is "natural
| sort order".
| messe wrote:
| > I guess you mean "after"? Otherwise it seems to me you're
| agreeing with OP.
|
| Depends on which direction you're sorting in, no?
| DrammBA wrote:
| > Depends on which direction you're sorting in, no?
|
| In a vacuum: yes. In this particular case: no, because we
| have the article's context clarifying that we're talking
| about ascending order.
| mbreese wrote:
| It's more confusing. I thought the article was correct
| when they said -10 coming before -9. Why? Because they
| were talking about the strict alphabetical sort. They are
| already prepending zeroes to force the comparison to be
| 10 vs 09. So, yes, they were talking about ascending
| order, but not natural ascending order, but ascii sorting
| order where 10 is before 9 because the comparison isn't 9
| vs 10, but 1 vs 9.
|
| It was only clear to me because I could guess where they
| were going. They were complaining about natural sort vs
| alphabetical sort, which is a case I've run into many
| times, so I could see the argument coming.
|
| The irony to me was that they were already altering how
| they named files to fit what they thought the computer
| wanted by prepending a zero to get a proper alphabetic
| sort. And even after that, some computers didn't follow
| their idea of what it should be doing.
| coldtea wrote:
| > _You may be looking at that time through rose-tinted
| glasses._
|
| Nope, regarding what he talks about, the time was rose-tinted
| itself.
| Certhas wrote:
| Agreed.What's more, the idea that people learn to put leading
| zeros is wrong and impractical, unless you know in advance how
| many digits you need. When you go from version 5.9.17 to 5.10.0
| you don't go back and relabel every existing folder as 5.09.17.
|
| The today standard way of sorting is well defined, unambiguous,
| and natural. Lexographic has its place, but user facing
| interfaces ain't it.
| worik wrote:
| No
|
| Just no
|
| User interfaces that try to be cleaver are a pita.
|
| Keep it simple, and avoid the confusion with corner cases
| that otherwise will baffle users. Like this
| TuringTest wrote:
| Lexicographic order is great when you need an unambiguous
| criterion that will work the same in every implementation;
| but you only need that for automated processing, i.e. for
| coding.
|
| For user-facing presentation, having 5.9.xxx before
| 5.10.xxx _is_ simpler; the corner case that baffles users
| is having 5.1 and 5.10 before 5.2.
| rs186 wrote:
| LOL I can tell you don't have the experience of designing
| UI and shipping product to end users
|
| > Keep it simple
|
| What's simple? Good defaults make things simple, which
| means putting 9 before 10 in case, for the reason explained
| by parent.
| whatevertrevor wrote:
| Had this in the Beat Saber mod manager recently. The game
| released 1.40.10 and my mod manager suddenly thought that
| game went backwards from 1.40.9
| ploxiln wrote:
| I think the only problem is that it's a surprise and mystery,
| particularly because "dumb" alphabetical sort has existed
| forever. When they "fixed this" for the 99% of regular users
| cases, they should have made it as separate "smart natural
| sort" option separate from the "strict alphabetical sort"
| option (next to date, size, etc). Simple and obvious, rather
| than surprisingly different from the decades of experience that
| even non-technical users already have.
| wvenable wrote:
| It's not just the one decision though; there are literally
| thousands, maybe tens of thousands, of these decisions in
| most software. You want every single one of them to have an
| option? You want it to support every single combination? At
| some point, it is ridiculous. Sometimes you just have to
| decide how your software is going to work and not leave every
| single decision to the user.
| oneeyedpigeon wrote:
| It may be one of thousands of decisions, but it's one of a
| handful that are exposed in the user interface as a
| fundamental action.
| scrollaway wrote:
| In a file manager? Any more than the displayed
| thumbnails, icon size, whether folders are separated from
| files, whether images are separated from videos, what
| video types are supported, what file types are opened
| inline, what the click and double click behaviours are,
| etc?
|
| And yeah kde has settings for all these but kde is also
| known for being too configurable.
| mcdonje wrote:
| How the files sort seems kinda important. It gets at the
| core behavior of the program. It's not something
| superficial like a default icon, which the user probably
| can change.
| eviks wrote:
| You don't let every decision to the user, you make good
| defaults, but leave the option to override to the user! And
| thousands isn't scary as long as groups/tags/search work,
| so what's ridiculous about empowering the user?
| hchdifnfbgbf wrote:
| Increasing the number of different possible combinations
| of settings your software can be running with by a factor
| of one nonillion is not a choice I'd make if I wanted to
| have any confidence in its reliability and security.
| armchairhacker wrote:
| But the alternative would be a surprise to people who assume
| "by name" will order numbers, including those who are new to
| technology (and I think most non-technical people who sort
| things manually unknowingly order numbers).
|
| We want to minimize surprises and mysteries, but computers
| have so much hidden complexity it's impossible to eliminate
| them. If users were shown a full description of how every
| feature on their computer worked before using it, they'd
| quickly start ignoring the descriptions. There should
| probably be a tooltip or "manual entry" for "by name" for
| those who are curious, and it should never be labeled
| "alphabetical" because it's not. But cases like the author's,
| where he assumes a feature works differently than most people
| (including the designers) assume, can't be helped.
| lstamour wrote:
| I might be wrong on this, but I vaguely recall that on macOS
| back when you could commonly option-click to reveal advanced
| options, if you held option when clicking a sort it would
| change how it sorted from alphabetical to lexical or vice
| versa. I'm not a thousand percent sure of it, though, I think
| when I needed it I was able to set a directory preference via
| terminal to change how a specific directory was sorted and it
| was an option there. MacOS had (or has) a lot of buried
| options which I presume date back to its origins as a Unix as
| well as a convenience to its developers. A lot of the command
| line utilities were hacked calls to graphical settings code
| though, so it wasn't very stable version to version as the UI
| calls changed and nobody prioritized non-UI bug fixes or
| breaking changes. These days CLI is nearly forgotten or
| assumed to be an exploit vector - see Screen Time data for
| example.
| yndoendo wrote:
| What is the reason to append a textual file name with a number?
| User Experience?
|
| They are magic numbers. Maybe a serial ID, date stamp with more
| magic, revision, release, ...
|
| Magic Number land has 10 > 9 in the above.
|
| 9 > 10 is only possible when removing the Magic Number and
| morph into mealiness text.
|
| At the moment I cannot think of any magic number where 9 > 10.
| gtowey wrote:
| > I agree with Microsoft/Google/KDE's order. The author's
| situation is extremely rare...
|
| Even if that were a valid reason for making it the default
| behavior, the real issue is they don't even give you the option
| to have the lexically correct sort order. They just decided to
| give you something that's not accurate and that's all you get.
|
| A trend which is frustratingly, increasingly common.
|
| It's trivial to allow customization behind menus. But we rarely
| get that anymore. Especially for sandboxes devices like phones.
|
| It's a giant middle finger to users who want to actually use
| their devices as a tool, instead of simply a portal for more
| sales and marketing.
| lukan wrote:
| "The author's situation is extremely rare"
|
| People sorting their files for alphabetical order is extremely
| rare?
|
| And right now I fail to see even one 'case where someone wants
| "10" to be before "9"'
| Spivak wrote:
| People sorting their files in alphabetical order but who want
| numerical values in their files to be sorted digit by digit
| instead of as numbers is the rare case.
|
| I might go further in my ideal sorting algo which would be
| normalize capitalization and ignore all alphanumeric
| characters and treat them all as separators.
| Wowfunhappy wrote:
| I will add that I'm plenty "smart" enough to understand that
| "10" comes before "9" in a strictly alphabetical sense, and I
| _still_ want my file managers to sort "9" before "10".
|
| I don't want to put leading 0s before every single digit number
| in my file names. (And then potentially go back later and add
| additional leading zeros once the maximum number gets too big
| and requires more digits.)
|
| ---
|
| I split all of my audiobooks into chapters. I use the format
| "Chapter 01.mp3" (or "Chapter 001.mp3" when there are > 99
| chapters) because some (all?) MP3 players are too stupid to
| sort numbers properly and I want my audiobooks to work
| everywhere.
|
| This works, but it's annoying and looks ugly, and I'd love if I
| didn't have to do it.
| ineedasername wrote:
| Well, lots of interfaces don't say "alphabetical" anymore, they
| say "name" or some variant, and then they can define it however
| they want, regardless or because of the frustration it causes
| users but not some other users which will now be inverted for
| long term-frustration averaged user experience.
| nebezb wrote:
| > But 1 is smaller than 9, so file-10.txt should be first in
| alphabetical order. Everyone understands that, and soon people
| learn to put enough leading zeros if they want their files to
| stay sorted the way they like.
|
| No. Not "everyone understands that". Natural sort happens in real
| life and everyone understands that. Only those who understand
| ASCII -- not the average user of graphical file managers -- will
| deduce the reason for your definition of "alphabetical order".
|
| > Now that I know what the issue is, I can solve it by renaming
| the files with a consistent scheme.
|
| Intensely ironic given the previous suggestion.
| zahlman wrote:
| > Well, apparently all these operating systems have decided that
| no, users are too dumb and they cannot possibly understand what
| alphabetical order means. So when you ask them to sort your files
| alphabetically, they don't. Instead, they decide that if some
| piece of the file name is a number, the real numerical value must
| be used.
|
| Well, no. You _don 't actually_ ask them to sort in alphabetical
| order. You ask them to sort _" by name"_, and that is up to their
| interpretation. And they choose the interpretation that (per
| their reasoning, and possibly some actual data) seems most likely
| to correspond to what the user wants.
|
| Maybe future versions of those OSes will add a rule that says
| that if any of the number groups have leading zeros then it
| reverts back to actual alphabetic order. Or maybe they'll give
| you configurable options. (Maybe some of them already do.)
| sebtron wrote:
| > And they choose the interpretation that (per their reasoning,
| and possibly some actual data) seems most likely to correspond
| to what the user wants.
|
| Yes, that make sense, but the problem is that this
| interpretation changed in the last 10 (15? 20?) years. It used
| to be that "by name" meant "by name, il alphabetical /
| lexicographical order" in pretty much every file manager.
| KuSpa wrote:
| Reminds me of https://xkcd.com/1172/
| jameshart wrote:
| Clearly a leading zero means the number is in octal (but only
| if all the subsequent digits are between 0 and 7). I think that
| would lead to the most intuitive results.
| shawnz wrote:
| > Of course, the user who named those files probably wants
| file-9.txt to come before file-10.txt. But 1 is smaller than 9,
| so file-10.txt should be first in alphabetical order. Everyone
| understands that, and soon people learn to put enough leading
| zeros if they want their files to stay sorted the way they like.
| Well, apparently all these operating systems have decided that
| no, users are too dumb and they cannot possibly understand what
| alphabetical order means. So when you ask them to sort your files
| alphabetically, they don't. Instead, they decide that if some
| piece of the file name is a number, the real numerical value must
| be used.
|
| I think there are many things wrong with your assessment of the
| situation.
|
| First, where does it say in these file managers that they're
| sorting by alphabetical order? I see that you've specified that
| you want the files sorted by name, but I don't see that you've
| specified you want them sorted by name alphabetically. And what
| does "alphabetical sort" even mean when you're sorting characters
| which are not letters? What you mean is probably "lexicographical
| sort".
|
| Second, you admit yourself that users probably want natural sort.
| Why would you expect these products to do the thing which they
| know users usually don't want by default? That just seems like
| bad design to me. They know users usually want natural sort, and
| you know users usually want natural sort, so why would you expect
| the default behaviour to be a lexicographical sort?
|
| Third, just like how you've learned to work around the lack of
| natural sort in poorly designed products of years past by adding
| leading zeroes, you can just add trailing zeroes to get the
| lexicographical ordering that you want. Why do you seem to be
| implying that the latter is more user-hostile than the former? It
| doesn't make sense to me. A decision had to be made about what
| sort to use and they picked the one that most people want. Isn't
| that what we should be expecting in a product that caters to its
| users?
|
| I see in other comments you've suggested that there should be a
| separate option for choosing between lexicographical sort and
| natural sort. But in the past, when lexicographical sort was the
| only option, why weren't you complaining about it being user-
| hostile to only have one option then? Why is it only when the
| default is something you're personally not used to that it
| warrants complaint? And where do we stop, do we have separate
| controls for every single sortable string field to determine
| whether it should be sorted lexicographically or naturally? Or
| just the name field? Don't you think that is going to lead to
| interface bloat?
| wrs wrote:
| To answer the question in the article, I'm pretty sure Windows
| Explorer (and probably File Manager before that) has sorted
| filenames this way for at least 30 years.
| rozab wrote:
| I can confirm that this does not happen in Windows 98, but does
| happen in Windows XP.
| epistasis wrote:
| This is reminding me of the whole "Worse is better" essay and
| debate:
|
| https://news.ycombinator.com/item?id=27916370
|
| The author wants the "worse" sort, one based on ASCII/Unicode
| codepoints, without any intelligence for numbers that 99% of GUI
| users want.
|
| For their purposes, they've assumed something about the
| implementation, to the point that a convenience feature is
| actually a misfeature for them. But the author here is probably a
| developer, or close to one, so they do not represent the needs of
| most people using computers.
|
| Understanding the target audience for your product results in
| very different design decisions. Better is better might be great
| for products, but worse is better is probably better for systems
| that need to grow and evolve.
| BeFlatXIII wrote:
| > The author wants the "worse" sort, one based on ASCII/Unicode
| codepoints, without any intelligence for numbers that 99% of
| GUI users want.
|
| I want the author's opinion on how caplital and lowercase
| letters should be sorted. Do they follow strict ASCII/Unicode
| codepoints, or do they normalize into actual alphabetical order
| and sort upper/lower within each letter?
| jowea wrote:
| Asciibetical sorting
| GLdRH wrote:
| And where do you sort the letter a? (After a is correct in
| German, but I think Swedish does it differently.)
| dvdkon wrote:
| This feels like the right moment to mention "ch", which is
| considered a letter in orthodox Czech, sorted between "h"
| and "i". The problem is, you can't reliably distinguish
| between "ch"-the-letter and "ch" as just "c" and "h"
| combined, which are present in loan words but also some
| original Czech compound words.
|
| So if you're doing it "properly", sorting strings in Czech
| involves understanding the etymology of every word.
| jcynix wrote:
| That's why we have all this LC_* stuff in Linux, which you
| can configure to your needs: export
| LC_MEASUREMENT="de_DE" export LC_MONETARY="de_DE"
| export LC_PAPER="de_DE"
| export LC_CTYPE=de_DE.UTF-8 export
| LC_MESSAGES="en_US.UTF-8" export
| LC_RESPONSE="en_US.UTF-8" export
| LC_TIME=en_US.UTF-8
|
| Mix in your Swedish or Swaheli, maybe even the Vatican
| State: e.g. de_DE, sw_TZ, it_VA (not
| guaranteed ;-).
| sebtron wrote:
| > I want the author's opinion on how caplital and lowercase
| letters should be sorted. Do they follow strict ASCII/Unicode
| codepoints, or do they normalize into actual alphabetical
| order and sort upper/lower within each letter?
|
| I prefer the strict ASCII / Unicode sorting (all capitals
| first, then all lowercase).
| wvenable wrote:
| It's an issue of mental models. As a developer, his mental
| model is one of how naive software would sort items with mixed
| numbers in them. Most people, of course, naturally sort 10
| after 9 -- their mental model doesn't contain software
| developer assumptions.
| AlienRobot wrote:
| >Understanding the target audience for your product results in
| very different design decisions
|
| This is an excuse. Just add an option to sort both ways. It
| isn't hard.
|
| There is no target audience in this planet that benefits from
| less options or less features. Even if you had the features
| under an "advanced mode" UI that's still a better software than
| not having the feature in first place.
|
| Have people forgotten the 80/20 rule? Most features will be
| used by only a small slice of users, that doesn't mean they're
| out of scope.
|
| Sorry, I'm just kind of exhausted of software not being able to
| do the most obvious things because it didn't align to some
| perfect vision of how the user should be.
| dcomp wrote:
| I think the algorithm is probably incorrect. A number starting
| with 0 should be treated lexically not numerically. Otherwise you
| have a situation where img_1_01.jpg and img_01_1.jpg does not
| have a complete ordering.
| gregates wrote:
| It wouldn't be the first time widely-used software sorted
| numbers by a function that does not produce a total ordering.
| For example, Excel: https://gregat.es/excel-numeric-order-
| transitivity/
| re wrote:
| > Otherwise you have a situation where img_1_01.jpg and
| img_01_1.jpg does not have a complete ordering.
|
| (Good) "natural sort" implementations generally have ways of
| handling ties like this. It's similar to the problem of case-
| insensitive sort over case sensitive sets.
| crazygringo wrote:
| That's not the issue.
|
| The issue here is that one camera appends milliseconds to the
| seconds without a separator, and the other uses a separator.
|
| So of course the ones that include milliseconds look like
| bigger numbers and get sorted last.
|
| Leading zeros aren't the issue here.
| ano-ther wrote:
| "The Tyranny of the Marginal User" strikes again:
| https://nothinghuman.substack.com/p/the-tyranny-of-the-margi...
| skwee357 wrote:
| I got used to naming files/folders with leading zeros when I want
| them to be sorted alphabetically (for example payslips/invoices,
| etc).
|
| But I'm a tech guy, I know what does "alphabetically" mean in the
| tech world. And it probably is not what common folks mean when
| they think "alphabetically" outside the tech world.
|
| Edit: in fact, if I recall correctly, the proper term for this
| kind of sort (the one OP wants) is alphanumeric sort.
| vslira wrote:
| shameless plug (though I don't get a cent out of this, of
| course): https://blog.vslira.net/2025/03/a-neat-approach-for-
| sortable...
| lblume wrote:
| I also got used to it, but especially when writing short
| scripts that generate numbered files it gets annoying to have
| to pad with zeroes every time, and also precommit to a specific
| amount of digits you want to allow (finding a compromise
| between adding a ridiculous amount, like 20, and using only 4
| despite knowing the script might one day surpass 105 files).
|
| The natural numbers are ordered. Let me use its ordering
| instead of having to rely on an ad-hoc lexicographic fixed-
| length tuple representation of decimal digits, without any
| padding. My position is that numbers in filenames should always
| be considered atomically unless explicitly instructed
| otherwise.
|
| If there were no issues of backwards compatibility, I would
| thus advocate for changing ls. Eza (maintained fork of Exa,
| Rust-based ls alternative) actually does sort this way by
| default, much to my delight.
| tonytamps wrote:
| When I say Afferbeck Lauder [1] I mean "alphabetical order"
|
| [1] https://en.m.wikipedia.org/wiki/Afferbeck_Lauder
| adolph wrote:
| Those are beautiful, thank you for posting them
| donalhunt wrote:
| I've encountered a tangential problem to this with package
| versioning on Linux distros. Thankfully it was not too hard to
| write an algorithm to compare versions (thanks AI!).
| perching_aix wrote:
| TLDR: the author found out about natural ordering [0], i.e.
| treating a sequence of digits as a number while sorting.
|
| Usually preferable, except when not. Just like distinguishing
| between upper- and lowercase letters, and other misery.
|
| [0] https://en.wikipedia.org/wiki/Natural_sort_order
| cesarb wrote:
| > But nope, this is not it, because the good old ls sorts my
| files correctly
|
| Did the author try "ls -v"? It would probably give the exact same
| order these file managers used.
| echohack5 wrote:
| This was a fun thing to realize in my early days of programming
| in Delphi. I guess the author will soon realize why old systems
| name things ticket "00001" and so on.
| vslira wrote:
| Ha! I had the exact same realization on MacOS. Extremely annoying
| behavior.
| cubefox wrote:
| By the way, there seems to be a "standard" way to sort strings:
|
| > Unicode Technical Report #10 also specifies the Default Unicode
| Collation Element Table (DUCET). This data file specifies a
| default collation ordering.
|
| https://en.wikipedia.org/wiki/Unicode_collation_algorithm
|
| I assume this mainly aims at giving a reasonable compromise
| between the different dictionary and phone book sorting rules of
| various languages (and even locales), which should give
| reasonable results for most languages. I assume this also puts
| "Alice2" before "Alice10".
| t-3 wrote:
| > I assume this also puts "Alice2" before "Alice10".
|
| It doesn't (per https://www.unicode.org/reports/tr10/#Non-
| Goals): > 1.9.2 Non-Goals > > The
| Default Unicode Collation Element Table (DUCET) explicitly does
| not provide for the following features: > [ ... ] >
| Numeric formatting: numbers composed of a string of digits or
| other numerics will not necessarily sort in numerical order.
| cubefox wrote:
| Oh, that surprises me.
| zarzavat wrote:
| Even if you are a file naming Einstein and you always zero pad
| your integers to exactly right length, we have this thing called
| the internet, where you can download _other people 's files_.
|
| Your OCD is not my OCD.
| mcswell wrote:
| Be glad you don't have to deal with non-ASCII characters:
| acute/grave/tilde/umlaut/diaresis/etc. accented characters,
| dotted vs. dotless 'i' (Turkish), barred i (an 'i' with a sort of
| dash through the middle, used in some languages for a sort of
| schwa-like vowel), thorn, not to mention non-Roman characters.
| And different languages sort the same characters differently, so
| you can't just pay attention to their Unicode values. (@cubefox
| has a post here pointing to the Unicode Consortium's doc about
| sorting)
| t-3 wrote:
| Renaming things to make them queue correctly (I usually couldn't
| care less about visual sorting, I use a terminal) is by far my #1
| task by LoC and frequency of occurence, and by far the most
| annoying. Metadata can be very helpful to obviate this issue, but
| it usually just leads to another problem where you now need
| metadata editors and readers in addition to the "user-visible"
| name metadata. It's frustrating.
| kens wrote:
| Sorting so "foo9" is before "foo10" is called _natural sort_. I
| found out about natural sort a week ago and I am thrilled that my
| programs now print their output in a sensible order. Give natural
| sort a try and see if it improves your life too :-)
|
| I found the magic two lines of Python to do a natural sort here,
| by the way: https://stackoverflow.com/questions/11150239/natural-
| sorting...
| jcynix wrote:
| Natural sort is an Option in sort(1): for i in
| $(seq 2 10) ; do touch img_$i-hn.txt done
| ls img_* | sort -V img_2-hn.txt img_3-hn.txt
| img_4-hn.txt img_5-hn.txt img_6-hn.txt
| img_7-hn.txt img_8-hn.txt img_9-hn.txt
| img_10-hn.txt
|
| And we have "sort -h" to sort the output of e.g. "du -sh *"
| properly.
|
| Edit: formatting and add sort -h
| Marha01 wrote:
| Why is the author so perplexed by it?
|
| https://en.wikipedia.org/wiki/Natural_sort_order
|
| It's simply natural sorting. I don't see what is so controversial
| about it.
| lblume wrote:
| I find the term "natural" to be inadequate here, there is
| nothing natural about sorting strings in this particular
| fashion compared to another. It should be given a more
| descriptive name, like "Number-aware alphabetic" or something
| like that as to actually give a hint about what it does.
| DonHopkins wrote:
| Sorting by name (collation) is waaay tricker than simply figuring
| out how to parse the numbers.
|
| The International Components for Unicode library implements the
| Unicode Collation Algorithm, which depends on the language code
| and region of the locale, and looks up the quirks for each locale
| in the Common Locale Data Repository.
|
| It's a much better idea to just use the standard ICU library or
| platform specific libraries (which are often build on ICU like
| JavaScript's Intl.Collator), instead of trying to hot dog it by
| rolling your own.
|
| International Components for Unicode
|
| https://en.wikipedia.org/wiki/International_Components_for_U...
|
| >ICU provides the following services: Unicode text handling, full
| character properties, and character set conversions; Unicode
| regular expressions; full Unicode sets; character, word, and line
| boundaries; language-sensitive collation and searching;
| normalization, upper and lowercase conversion, and script
| transliterations; comprehensive locale data and resource bundle
| architecture via the Common Locale Data Repository (CLDR);
| multiple calendars and time zones; and rule-based formatting and
| parsing of dates, times, numbers, currencies, and messages.
|
| Unicode Collation Algorithm
|
| https://en.wikipedia.org/wiki/Unicode_collation_algorithm
|
| >The Unicode collation algorithm (UCA) is an algorithm defined in
| Unicode Technical Report #10, which is a customizable method to
| produce binary keys from strings representing text in any writing
| system and language that can be represented with Unicode. These
| keys can then be efficiently compared byte by byte in order to
| collate or sort them according to the rules of the language, with
| options for ignoring case, accents, etc.[1]
|
| >Unicode Technical Report #10 also specifies the Default Unicode
| Collation Element Table (DUCET). This data file specifies a
| default collation ordering. The DUCET is customizable for
| different languages,[1][2] and some such customizations can be
| found in the Unicode Common Locale Data Repository (CLDR).[3]
|
| Common Locale Data Repository
|
| https://en.wikipedia.org/wiki/Common_Locale_Data_Repository
|
| >The Common Locale Data Repository (CLDR) is a project of the
| Unicode Consortium to provide locale data in XML format for use
| in computer applications. CLDR contains locale-specific
| information that an operating system will typically provide to
| applications. CLDR is written in the Locale Data Markup Language
| (LDML).
|
| >Among the types of data that CLDR includes are the following:
| Translations for language names Translations for territory
| and country names Translations for currency names,
| including singular/plural modifications Translations for
| weekday, month, era, period of day, in full and abbreviated forms
| Translations for time zones and example cities (or similar) for
| time zones Translations for calendar fields Patterns
| for formatting/parsing dates or times of day Exemplar sets
| of characters used for writing the language Patterns for
| formatting/parsing numbers Rules for language-adapted
| collation Rules for spelling out numbers as words
| Rules for formatting numbers in traditional numeral systems (such
| as Roman and Armenian numerals) Rules for transliteration
| between scripts, much of it based on BGN/PCGN romanization
|
| Tricky collation examples:
|
| sv-SE (Swedish): a, a, o are separate letters at the end of the
| alphabet, not variants of a or o.
|
| de-DE (German): a, o, u may sort as ae, oe, ue in some contexts,
| or as distinct letters. ss sometimes sorts as ss.
|
| tr-TR (Turkish): dotted i (i) and dotless i are different
| letters; I sorts with i, not with i.
|
| es-ES (Spanish): traditionally ch and ll were treated as single
| letters with their own place in the alphabet.
|
| cs-CZ (Czech): ch still counts as a unique letter, sorted after
| h.
|
| da-DK / no-NO (Danish/Norwegian): o comes after z.
|
| is-IS (Icelandic): th ("thorn") is part of the alphabet, after z.
|
| fr-FR (French): accents usually ignored in sorting, so e = e, but
| not always depending on collation settings.
|
| el-GR (Modern Greek): tonos accents, final sigma s vs. s, etc.
|
| nl-NL (Dutch): the digraph "ij" is often treated as a single
| letter, and capitalized as "IJ". In dictionaries and phone books
| it often sorts as a single letter under "I", but sometimes is
| listed after "X" depending on tradition.
|
| Then you get into non-Latin languages like, Chinese, Japanese,
| and Korean collation, which gets hairy with radicals, kana order,
| and stroke count.
|
| Also different locales have different ways of representing
| numbers, like switching between "," and "." as separators and
| decimal points.
|
| ICU supports integer only "natural" numeric collation, so
| anything more complicated like versions, floating point, negative
| numbers, hex, thousands separators, fractions, roman numerals,
| etc, you'd have to build on top of ICU.
|
| ICU doesn't support incomprehensible dead languages like Latin or
| Ancient Greek (it does however support French ;). It does support
| Roman numeral formatting, but not collation, which would be
| pretty tricky and ambiguous.
|
| https://www.youtube.com/watch?v=sKWvTlLMB-Y
|
| A nuanced but common example that ICU/UCA/CLDR helps with is a
| menu to select the current locale: you have to translate each
| language's name into the current locale, and also sort them in
| the current locale. On top of different collations they can also
| have totally different spellings, like "United States of America"
| is "Verenigde Staten van Amerika" in Dutch. This makes it
| challenging for users to find their own language when the locale
| is set wrong! You just can't win.
|
| Not to mention emojis! Which comes first: The chicken or the egg?
| The taco or the poop?
|
| Also, the Mac Finder switches ":" and "/" for historical reasons
| (HFS used to use ":" as a directory separator instead of "/"), so
| you can create a file name like "9/11 Attack" in the Finder,
| which actually gets the underlying Unix filename "9:11 Attack".
| Don't believe me? Rename a file in the Finder to include a slash,
| which you know is impossible to represent as a Unix file name.
| Then go "ls" the directory in the shell.
|
| The Mac Finder weirdly collates "/" after "9" because under the
| hood it's really storing it as ":", which sorts before "0". But
| it also has other punctuation collating inconsistencies, sorting
| "," and ";" and others after "0" too. Definitely not ASCII order
| -- I'm not sure what rules it uses, but it's different than "ls".
|
| However, while it's generally true you can't have "/" in Unix
| file names, NFS used to trustingly let clients rename Unix files
| to include a "/" in their name, which the Gator Box
| AppleTalk/Ethernet gateway let you do with the Mac Finder (pre
| OS/X), which would silently corrupt your "dump" backups on the
| Unix NFS server, so you would not learn about it until you tried
| to retrieve your files and "restore" crashed.
|
| https://news.ycombinator.com/item?id=31821646
|
| >Another reason that NFS sucks: Anyone remember the Gator Box? It
| enabled you to trick NFS into putting slashes into the names of
| files and directories, which seemed to work at the time, but came
| back to totally fuck you later when you tried to restore a dump
| of your file system.
|
| >The NFS protocol itself didn't disallow slashes in file names,
| so the NFS server would accept them without question from any
| client, silently corrupting the file system without any warning.
| Thanks, NFS!
| nilslindemann wrote:
| In Total Commander, there is a function in the options to sort
| strict by numerical char code. It will sort those files
| correctly. Unfortunately, it will also sort "10.txt" before
| "2.txt".
|
| ---
|
| In all file managers, I miss an API point where one can give a
| userdefined sorting function for the file and folder list.
| lblume wrote:
| What do you mean by "Unfortunately"? This appears to be the
| only correct conclusion from the algorithm you selected, you
| can't eat the cake and have it too.
|
| Regarding your second point, that's not really what a graphical
| file manager is for, I think. At this point (likely even
| earlier) you would be better off just writing a simple script
| in the scripting language of your choice. (If going for
| something fancy, you could also implement a FUSE based on
| symlinks for the original files, where the filename is
| prepended by a sort key. This would work for every major file
| manager and you could manipulate the files in mostly the same
| way as before.)
| nilslindemann wrote:
| Paragraph 1: I speak of a sorting method which splits the
| filename at the boundaries between numbers and non-numbers,
| and sorts by the parts of the resulting tuple, the numbers
| naturally (10 comes after 2) and the rest by numerical char
| code.
|
| Paragraph 2: I am not sure what you mean here with writing a
| script. The graphical file manager shall sort its file list
| using the sorting function I hand over to it.
|
| "That's not really what a graphical file manager is for".
| Says who? Every software which has a plugin system does that,
| why should a file manager not?
| magicalhippo wrote:
| Plex team, are you reading this?
|
| For some inexplicable reason, Plex just throws its hand up on
| non-ASCII characters and puts them first.
|
| In Norway we have three extra letters, aeoa, and they're at the
| end of the alphabet after z. But in Plex, I have Oystein Sunde[1]
| placed before any other in my music library.
|
| Now in the 1990s I would forgive US software for such a thing,
| but it's 2025...
|
| [1]: https://en.wikipedia.org/wiki/%C3%98ystein_Sunde
| ryukoposting wrote:
| Por que no los dos?
|
| Call lexicographic order "sort by name" as it's called now, and
| call dumb character-by-character sort "plain" or something like
| that. I'm not a designer, maybe there are more intuitive names,
| but come on. This isn't an intractable problem.
| yujzgzc wrote:
| I thought this was going to be a deep dive into what
| "alphabetical" means and how that's itself not a universal term
| between locales, what with so many different collation
| preferences.
| lblume wrote:
| That would likely have been a more useful article for the
| average developer. It is extremely hard to be aware of all the
| ways strings of different locales can defy our intuitions.
| dusted wrote:
| This got me riled up to the point where I blew a gasket and just
| can't..
|
| I agree with the article.
|
| I liked computers better when everyone hated them, and for the
| reasons they hated them..
| lblume wrote:
| I agree that the base functionality of just sorting character
| by character can be occasionally useful. However I would really
| be interested in seeing why you believe this to be the correct
| choice for user-facing graphical file managers, as its evident
| problems with typical usage seem more salient compared to the
| edge cases as illustrated in the article.
| Taek wrote:
| This is one of the big ways that LLMs are going to change the
| game for UX. Your operating system is going to have some sort of
| 'butler', which knows all of your preferences, and the butler
| will go through the APIs and man files and informational dialogs
| of every app you use and auto-configure them.
|
| Then if you want something to change, just ask the butler. If the
| app is open source and doesn't support the requested feature, the
| butler might even be able to code it up.
| bapak wrote:
| Maybe it's just me but I don't miss this at all:
| Image-1.jpg Image-11.jpg Image-2.jpg
|
| The only time natural sort bit me was with nonsensical names like
| <md5>.jpg
| RHSeeger wrote:
| I think it depends on the person. That order is exactly what I
| expect and want.
| sneak wrote:
| More importantly, it is _how computers work_ , and _how
| computers have worked for many decades_.
|
| Anyone with experience expects them to work this way. Trying
| to be clever to cater to the inexperienced only harms both
| groups.
| crazygringo wrote:
| Computers have been sorting with _natural_ sort for
| decades. By now, it _is_ "how computers work".
|
| Were you under the impression this was something new?
| f33d5173 wrote:
| I was very surprised by it when I noticed it a year or so
| ago. What's interesting is that when it works, eg you
| have a directory with numbers from 1-10, you don't really
| notice it. It isn't until it bites you in the ass, eg
| your downloads folder with a bunch long numeric strings,
| some in hex, where you want to find one and suddely it's
| not where you expect.
|
| I used a gui software some years ago that distinguished
| between version sort and alphabetic sort. It would be
| handy to have a toggle.
| crazygringo wrote:
| You prefer looking at photos in that weirdly particular
| shuffled order that isn't the order they were taken in?
| ziml77 wrote:
| Nah that's not just you. That is an unnatural way to sort
| things because that's not how numbers are ordered. I remember
| when Windows changed to sorting numbers by their value and,
| despite my programmer brain finding it strange in a way, I was
| super happy to have files display in an order that actually
| made sense.
| AlienRobot wrote:
| I have the same problem on Nemo. More specifically, I had made a
| small app that displayed files of a directory in alphabetical
| order, and then when I look at it in Nemo it isn't the same order
| because I didn't implement their smart algorithm.
| lblume wrote:
| I fail to see how this is a "problem"? You implemented a
| sorting mechanism that was useful to your application, while
| Nemo implemented another which as this thread demonstrates
| seems to be much more useful and intuitive for the average
| user. This is also of course not specific to Nemo, as no
| 'modern' file manager on Linux sorts filenames like it's 1980
| and all you are able to feasibly do is step through the bytes.
| AlienRobot wrote:
| Nemo isn't some random app a teenager made. It's the default
| file manager of a desktop OS. I expect it to cover more use
| cases.
|
| I expect the same for other file managers on Linux. Although
| I must say I'm generally let down by Linux software.
| notatoad wrote:
| >Well, apparently all these operating systems have decided that
| no, users are too dumb and they cannot possibly understand what
| alphabetical order means.
|
| i really really hate this framing, and i see it far too often.
| no, the operating system developers did not make a value
| judgement about their users. they observed their users to find
| out what behaviour was expected, and they designed the behaviour
| of the system to match the behaviour that the majority of users
| expect.
|
| and then you made an incorrect assumption about how the system
| works, and decided that your incorrect assumption means everybody
| else is dumb and you're the only smart person in this situation?
| paholg wrote:
| I think the real issue here is that two Android phones take
| photos with incompatible naming schemes.
|
| I am sure that at some point someone thought the milliseconds
| should or should not be separated from the seconds and made that
| change without thinking through the consequences.
| JoBrad wrote:
| I rename all of my photos upon import using the created date,
| formatted as `YYYY-MM-DD kk:mm:ss`.
|
| But it would frankly be great if most file browsers just let me
| sort photos based on metadata. But then I just end up in a
| dedicated photo browser, instead.
| andriamanitra wrote:
| The so-called "natural" sort makes sense for version numbers and
| enumeration (without zero-padding) but I'm more often dealing
| with file names with a datetime (like in the article), a
| hexadecimal hash, or just randomized string of characters that
| includes numbers. In those cases "natural" sort makes it harder
| to find the file you're looking for.
|
| Even when files are enumerated it's pretty rare to have more than
| 9 parts and no zero-padding, whereas there are almost always
| multiple consecutive digits in the use cases for which "natural"
| sort is not a good fit for. It just feels like a bad default, at
| least for a programmer's workload.
| brimstedt wrote:
| Isnt the author confusing "alphabetical sorting" with "ASCII
| sorting"?
|
| Afaik there is no universal way to handle numbers in alphabetical
| lists. Sometimes numbers some before letters, sometimes after,
| etc.
|
| A digit is not a part of the alphabet, right?
| phendrenad2 wrote:
| I think if we (in our industry in general) had REAL agile, and
| not pseudo-waterfall "the designers design it, the engineers
| implement it, QA QA's it, and then we lay everyone off because
| they're no longer needed" (but, loophole alert! We did daily
| standups and used Jira, so it was "agile" the whole time!), then
| we'd have a snowball's chance in hell of actually having a
| reasonable solution to this. Off the top of my head, this seems
| like something that should be a setting in control panel. But,
| because everyone assumes (contra to agile) that the designers
| "got it right the first time", this kind of improvement can't
| happen.
| jeroenhd wrote:
| If you don't like the default natural sorting order, you can just
| change it in Dolphin. Settings > Configure Dolphin > View >
| Content Display > select anything other than "natural". You can
| even pick if you want case sensitivity or not.
|
| The OS doesn't think you're too stupid to understand sorting, it
| relies on you being smart enough to figure out where the setting
| is located. In this case, four levels deep is probably too much
| to ask from users if they will write an entire blog post like
| this before finding the toggle.
| bloak wrote:
| The correct sorting algorithm is described here:
| https://manpages.debian.org/stretch/dpkg-dev/deb-version.5.e...
|
| I was joking. Really I would sort file names lexicographically.
| But the way Debian sorts version numbers is interesting and seems
| like a good way of handling that particular situation.
| userbinator wrote:
| The most irritating circumstance for this is looking for files
| named with a hash: 3ea4f... ...
| 97dce... ... 126b9...
|
| This is one of the settings I immediately turn off on Windows via
| the registry key mentioned in the other comments here.
|
| _I miss the time when computers did what you told them to,
| instead of trying to read your mind._
|
| These days, it's more like "trying to _change_ your mind ". I
| absolutely hate the "the user is wrong" authoritarian mentality
| that unfortunately has infected a ton of software, even open-
| source.
| krick wrote:
| Exactly. This is even more annoying when it isn't _exactly_ a
| hash, but some gibberish you cannot really make sense of, which
| does have a numeric section in them: like a user ID, or unix
| time, or who knows what else it could be, but you are trying to
| visually find a file abcd89764237 somewhere after
| abcd683426834, and it isn 't evident why you cannot, unit you
| notice that the latter has more digits in its "ID" for some
| reason.
| amelius wrote:
| Another problem which annoys me to no end is that most file
| managers and file selection boxes put directories before files.
|
| This makes it hard to find the file that was most recently
| changed, for example. Which is an action that is extremely
| common. (In fact, why does my file manager not have a most-
| recently-used shortcut?)
| ivanjermakov wrote:
| Have you tried sorting by created date instead? What is the point
| of relying on filename if that's not what you want.
| mzmzmzm wrote:
| There's a Group Policy setting in Windows: Computer
| Configuration\Administrative Templates\Windows Components\File
| Explorer\Turn off numerical sorting in File Explorer Group Policy
| has so many essential settings I hurry to change with every
| isntall. I wish Windows would expose more of them to the user in
| ordinary settings.
| pif wrote:
| Bro forgot that _ls_ has an option to obtain the same sorting as
| the one he doesn 't like.
|
| _ls_ has it because it solves a real user need.
| kiitos wrote:
| ls sorts filenames strictly lexicographically, comparing
| character by character, so e.g. "055436307" is compared as the
| characters "0", "5", "5", etc. so it sorts before "121134"
| because "0" is less than "1". if all compared characters match
| and one string ends, the shorter one comes first. Symbols like _
| are just more characters, and their position relative to digits
| depends on the locale's collation table.
|
| Google Drive uses ICU collation with the numeric option enabled,
| which treats each consecutive sequence of digits inside the
| filename as an integer. so "055436307" is parsed as the number
| 55,436,307, while "121134" is parsed as 121,134. and since
| 121,134 < 55,436,307 then "121134..." comes before "055436307..."
| even though lexicographic order would suggest the opposite. and i
| think when two digit runs have the same numeric value, the
| shorter run comes first; if runs are equal and the string
| continues, then normal character comparison resumes, including
| any underscores or suffixes
| IshKebab wrote:
| It feels like this algorithm could be improved though. If a
| number has leading zeros you _probably_ don 't want to sort it
| numerically.
|
| That said the author's situation where it's numerical _and
| different lengths_ seems likely rare enough that it probably
| isn 't worth complicating things.
| themafia wrote:
| I'm often yelling at the software on my computer: "STOP TRYING TO
| HELP ME!"
|
| It's like having a toddler help you make a meal. It wants to be
| involved and recognized so badly. Meanwhile I'm starving and just
| want to get the food done as quickly as is possible and I'm
| constantly tripping over this little ball of misguided efforts.
|
| Please. Stop trying to be smarter than me. You often can't, and
| when you get it wrong, you make it measurably worse. If you
| insist on doing this please give me the "Expert Mode" setting
| back so I can flatly disable ALL OF IT with one click.
| ggm wrote:
| If only we could represent sort order by some structural form of
| decision logic which also embeds encoding a regular .. well..
| expression matching a pattern..
| benoau wrote:
| Earlier this year I submitted a bug to VSCode about sorting
| Playwright tests in the alphabetical-and-numerical order that
| VSCode favours, after Playwright told me it was a VSCode issue.
|
| Some people rushed to fix this as I'd done some diving into the
| issue and presented the relevant information and code, so now
| VSCode's Playwright test list uses the same sorting mechanism as
| the rest of VSCode.
|
| Sadly, the underlying Playwright does not receive that order from
| VSCode so it still actually runs sequentially-numbered tests in
| strict alphabetical order. :(
| cyberax wrote:
| Heh. One of the bugs that once caused me to bang my head against
| the wall was caused by the Estonian language. Its alphabet has Z
| following S and S. So the "foolproof" regexp to match the letters
| '[a-za-Z]' was misfiring for some entries.
| avodonosov wrote:
| Dumb tools are more robust.
| makeitdouble wrote:
| Many commentors are positing the "clever" sort is what 99% of the
| user's want, but I really doubt it has been properly checked
| beyond the original PO's hunch and at most some user panel with
| pre-sampled data.
|
| Most of these decisions are early default behaviors that stay
| there as long as users aren't clamoring for change, and TBH I
| can't imagine most users to have a self emerging strong opinion
| on how alphabetical sort should be working.
| SigmundA wrote:
| Our users loved when we added "natural" sort, which was pain in
| the ass in the db, but ultimately no big deal.
|
| They absolutely do not care or understand the difference between
| alphabetical and numerical and natural, what they care about is
| 10 should not come before 9 in "Item 10" vs "Item 9".
|
| Whatever pedantic argument you have that natural is not
| alphabetic will lose you sales, your users do not care and want
| numbers to make sense in sorting.
| seriocomic wrote:
| More fascinating for me is this discussion thread, where there's
| legitimate debate around the need/expectation for alphabetical
| sorting to match/include lexical sorting.
|
| I'm personally in the "want lexical as part of alphabetical" - as
| 'photo19' should come after 'photo2' in my expectations, but the
| number of cases cited where this doesn't/shouldn't work is enough
| to justify a degree of contextual or situation awareness that
| most systems and interfaces simply aren't designed to cater for
| (file-systems vs photo-storage applications).
___________________________________________________________________
(page generated 2025-09-28 23:00 UTC)