The problem here is that the system exposes localized aliases in one context ("Bin" in the "folder" list) but only supports underlying identifiers in another co

The problem here is that the system exposes localized aliases in one context ("Bin" in the "folder" list) but only supports underlying identifiers in another context ("trash" in search). The author is too harsh though: - Probably only a tiny fraction of users actually know about the "in:folder" search syntax. - A simpler UX pattern for users who don't use a keyboard for everything is to click on the folder first and then add to the search string to limit search to that folder. - Folder names must be normalized in some way before being added to the search string, otherwise it would be impossible to search for folders with for example spaces in the name. This normalization could happen in many ways, but if it reduces the character set in any way (such as replacing spaces with hyphens) it's trivial to create "duplicate" folders for search purposes ("foo bar" and "foo-bar", for example). This problem gets worse if they introduce aliases into the mix. - What about the "in" part of "in:bin"? Surely localizing only part of the API is more confusing than localizing all of it? I've never seen an API framework which encourages this though, probably because it's a shedload of extra complexity for very little gain.