Hacker News Reader

Comment by londons_explore | Hacker News Reader

This is because "Trash" is just a label. The "Send to trash" button simply is a shortcut to add the trash label.

If you called that the "bin" label in England, then functionality could break when the user switches languages... Now they have a bin and a trash, with different things in!

Or you could write the code to relabel all the users emails when they changed language... But what if they had already manually created a label called "bin" then the auto-re-labeler will cause loss of data...

There is no perfect solution here... Any solution has unexpected behaviour for some things a user might want to do. Considering that, I think what is there is one of the least bad solutions...

View on HN

If you called that the "bin" label in England, then functionality could break when the user switches languages

Not if you designed the system with localization in mind from the beginning.

I agree, localization is hard. I have to do it for the web sites I build. But I build them with this kind of abstraction in mind, and am able to convert the mechanics of a web site to another language in just a week or so working with a translator. Then they do the content, and I add that in, and it's done and good.

I've added up to five languages to some of the sites so far, and the language audits have turned up no problems, and no complaints from the users. (We do actual human testing with actual humans. No bogus "telemetry.")

Admittedly, my sites don't serve nearly as many people as GMail, but they have to be as close to perfect as possible because I'm in healthcare, and conveying important information.

At the same time I'm able to do it with just me, while Google has a trillion dollars to throw at the problem.

The professional translators I work with say that to them, it looks like Google translates its web sites with Google Translate, rather than with a native-speaking human being.

So what do you do when a en_GB user creates a folder named Trash and switches to en_US and her “bin” folder now needs to be displayed as Trash? How do you resolve her saved searches and labeled items in a way such that the user can also tell them apart?

Maybe use reserved words? This doesn't seem like an impossible obstacle to surmount.

Labels should reference GUIDs behind the scenes. If a user does this, they will just be unsure which one is the actual Trash label. When searching, Gmail should give results from both labels.

or more generally, user-provided names should never be the canonical identifier for any resource.

for example, don't (canonically) identify accounts with usernames. that way when "joesmith" becomes "josephbarnes", the user can just change their username and everything keeps working (because it's really all user ID 19829).

any "name" you get from a user should always be considered nothing more than a non-canonical label for a resource with some other persistent and canonical identifier.

As another poster points out, this won't work for e.g. IMAP usage.

Yes, although to be fair, JMAP is a thing and Google has had a decade and a half to improve IMAP if they cared.

So how do you deal with IMAP? The protocol doesn't support i12n. There's more to GMail than the web front-end.

I have several bookmarked filters along the line of "label:inbox label:2-youtube".

Should they all break just because I change the language settings?

"inbox", "trash", "drafts" are labels and localization shouldn't pretend that they are something else.

It is nice if the UI presents us a named shortcut displayed in our chosen language setting, which applies a certain filter on labels when clicked.

When you bookmark a filter, shouldn't it bookmark the parsed version of the filter, not your string? If you rename one of those folders manually, it would suck if the filter didn't update (and other mail systems like Zimbra do this correctly... are you sure Google doesn't?).

> The professional translators I work with say that to them, it looks like Google translates its web sites with Google Translate, rather than with a native-speaking human being.

Or worse yet, outsource to a low cost firm whose translators add their own semi-illiterate or colloquial flourishes to Google Translator output.

Google translators are outsourced to a company which doesn't have access to the product - they are literally given a spreadsheet of strings and told to "translate these". No wonder the translations are sub-par.

I love Apple's solution when it comes to localization, they will search both the non-localized name and the localized name. So if you're looking for Image Capture, you can find it with Transfert d'Image and with Image Capture.

In the case of Gmail, it would mean that you could search both for in:Bin and in:Trash. The only issue would be if someone creates an additional Bin label in a US locale, then in UK, when searching for that label it would also show items in the trash but that's a better trade of I think.

This is also how localized special folder names (Documents, Pictures etc) work in Windows. And I think it's also the same in KDE and Gnome?

Only in the search index... If you try to install your application in "C:\Program Files\" on a non-english version of windows, you'll have a bad time...

I use Swedish Windows, and here "C:\Program\" (the localization) and "C:\Program Files\" both work fine and go to the same place.

Not since Vista. These days, you'll always have "Program Files", and if you have the OS configured for a different locale, it'll create a hard link for the localized name. The Windows shell (including the standard file picker dialogs etc) will also use the localized name preferentially whenever it has to display a path that contains one of those folders, but still allows verbatim paths to be used wherever text input is allowed.

well, gnome creates folders in whatever language you installed with, tho it can translate the file manager's sidebar items, I think... so a change of locale means you'd still have the old dir left, and show as old name everywhere except the special shortcuts

AppleScript, for all its faults, handled localization quite impressively. It parsed the whole script into an abstract representation, and could then could display it in another language as needed.

Sadly this feature never got used for making a better frontend to it :(

But none of those languages was a sane programming language.

The vocabulary doesn't matter when the grammar is an incomprehensible pidgin.

Apple script is the quintessential Jobsian "form, not function"

I think this is a good solution, but gmail also lets you create a filter based on a search. So if search is sensitive to the current locale, your filters could break changing the language. [Maybe filters made from searches against a localized label could be converted to language-neutral at storage time...]

Each folder has a unique ID. The label in the UI is merely a pointer to that ID. So all Gmail has to do when it sees `in:$foo` is map `$foo` to the right internal ID based on the interface language.

This isn't a new concept in computer science.

I guess the limitation there would be that you would have mayhem on stackoverflow, with Brits not understanding why a formula posted by an american doesn't work for them :)

But this can happen in plenty of other ways. For example sorting character vectors is dependent on locale. Arithmetic on times too.

I especially hate the way gnu utils treat character groups like [:alnum:] which, if you have utf8 version of a locale, matches characters in ANY unicode language set... so if you, say, grep for numbers in /dev/urandom with a shell script, you can end up with, say, some characters that are technically numbers but in a totally different language, say, arabic, or hebrew...

Essentially, you just need a simple mapping system to the actual data. Have labels point to a map that points to the correct data.

Probably an oversight or a low priority bug for the Gmail team.

Could also be something complicated in the underlying infrastructure that makes it difficult but I see no reason why it couldn't be abstracted and managed in the frontend as part of localization. Its always easier to talk about things and handwave without understanding problems that may cause with other underlying architecture.

You can call them low priority bugs all you want, but Gmail has been around for over a decade and I'm betting their team employs at least 50 developers... Surely one of them could fix it?

It's likely not getting fixed because the opportunity costs are higher than the reward of fixing it:

https://erikbern.com/2020/03/10/never-attribute-to-stupidity...

"Opportunity costs" are very often, as in this case, just an excuse for being too lazy to do the right thing.

When people have pride in their work and want to put out a quality product, instead of "optimizing" for pennies, then things get fixed.

You haven't thought this one all the way through... Imagine a user names a folder "Bin", which maps to ID 123, and the internal trash folder maps to ID 7, and the user sees as "Trash", because that's their interface language.

The user now changes their interface language to England, and suddenly they have two "Bin" labels that map to different sets of things. They behave inconsistently and frustrate anyone who gets into that state. Some messages might even be in "Bin" and "Bin" at the same time! Searching for "in:Bin" returns just one set, or the other, or both.

Doesn't really sound like a good solution...

This depends on who you want to prioritise.

How many people use Gmail in a language other than US English? How many people change their UI language and rename folders such that there is a clash?

Optimise for where it will have the most impact, and develop a work-around for the minority of users where this causes a problem.

> How many people use Gmail in a language other than US English?

You'd be surprised. There are only about 400 million native English speakers [0], and Gmail has 1.5 billion users [1].

If we assumed that all native English speakers use Gmail, they'd represent not even a third of the users. Of course, there are many non-native English speakers, but I'd assume a significant fraction of them would prefer to use Gmail in their language.

I'd argue i18n has a huge impact, but Google really doesn't optimize for it.

[0]: https://en.wikipedia.org/wiki/English_language [1]: https://www.cnbc.com/2019/10/26/gmail-dominates-consumer-ema...

But how many of those "users" are actually unique?

I, personally, have 3 "GMail" accounts: one @gmail.com, one @ my own domain, and one for work. So if I were the average English-speaking user of GMail, having every English speaker be a user would pretty much cover the 1.5 billion.

(I do not, in any way, think I am the average—I merely seek to point out that it's significantly more complicated to calculate than your post suggests.)

The real question is how many people use advanced searching. I would guess the answer is < 1%.

I think the person you're responding to is agreeing with you that you should optimize for languages other than English rather than for people naming a label "Bin" and then switching to the UK locale.

> There are only about 400 million native English speakers [0], and Gmail has 1.5 billion users [1].

Don't assume that only native English speakers (want to) use things in English.

Wouldn't it make more sense to, when the user switches languages, check for label/folder name collisions and deal with it then? Alternatively save all the built-in labels (Trash, Bin, etc) as reserved words so users can't create custom folders with those names?

> check for label/folder name collisions and deal with it then?

How?

> Alternatively save all the built-in labels (Trash, Bin, etc) as reserved

So now all localizations are reserved words? And ultimately, this may be a reasonable approach from the beginning, but how many people's accounts are you willing to break to institute this change now?

If there's a collision? Pop an error and offer to rename the custom folder..

> This is because "Trash" is just a label. The "Send to trash" button simply is a shortcut to add the trash label.

this basically boils down to "because they didn't consider internationalization or localization when coding it."

It is NOT a valid excuse for this not working from what was already a multinational company when GMail was introduced.

> Now they have a bin and a trash, with different things in!

translation: "but there's tech debt"

Not an excuse. Especially from a company with enough money to fix it without even noticing the effect on their bottom line. It didn't have to be coded to have the concept have a 1:1 correspondence to the name. "spam" and "trash" could have been conceptual objects with multiple localized interfaces for humans.

Then what happens when you create a custom label "bin" and relocalize to british?

prefix the localized bin for users with an existing bin

What? We're taking about tags, so if I create a custom "bin" label and move to england, what do I type to see my trash?

Reserve a system label prefix e.g. '_' and forbid users to create labels with that prefix. Then the labels '_Trash' and '_Bin' are exact aliases, and users can't accidentally collide with them.

Ah so now I have to search in _Trash instead of in Trash which makes label discovery and use worse and confusing for all users.

No. The point is that the search language has to be localized. When you type in:bin in en_GB or in:trash in en_US, the system has to work out that you mean _Trash. Doesn't seem that hard.

But what if you have a custom label bin or trash?

In en_US 'Trash' is an alias for '_Trash' but 'bin' is not.

But yes, it's getting complicated. I can see why they just stopped with changing the GUI labels and left the workings in canonical US mode.

Who knows, and why do you care?

That's something that the highly paid engineers at Google should figure out, not something that random Internet people on HN should have to figure out when replying to your comment.

My point is that we've had 5 people suggest different mutually incompatible, and all subtly broken, solutions to this "simple" problem. Perhaps the solution Gmail settled on wasn't done so out of naïveté.

Five people just throwing ideas off the top of their head in their free time. That only makes Google not having any solution with years and billions look all the worse.

There is no perfect solution here.

No one is suggesting that there is, but there are definitely better solutions than what GMail is doing.

> This is because "Trash" is just a label.

Typical "smart" solution, that completely fails when meeting the real world.

I wonder how many horrible software issues we've created trying to force smart/elegant solutions and then having either to: completely rebuild the feature, create horrible workarounds, or just let users deal with it however they can (which seems it's the Gmail way).

Using a surrogate key for labels would help a lot. That still leads to complications when user defined labels match localized names of built-in labels, but you could skip localization in those cases, use disambiguation (e.g. show it as "bin (built in)", reserve those names, etc.

Disambiguation strategies are hard... Imagine you call it "Bin", unless that name is ambiguous, in which case you call it "Bin (built in)".

Now, when the user does a search, they need to search for "In:'Bin (built in)'". Except when they delete the label called Bin, now the search terms they must use changes... All their saved searches and bookmarks with search terms in the URL would break too.

Reserving the names in all locales might work, although I could imagine quite a few users being frustrated they can't name something without realising that the word they are trying to use means something in some language they don't even speak.

Then what happens when you add a new locale?

I think to solve this 100% you need namespaces.

What about a 'did you mean "in:trash"' if it detects the localised variant?

Couldn't they just disassociate "Trash" with the label concept? On the backend, implement special logic for the "trash" function instead of tying it to a label, and you can solve the problem.

This is probably what would happen if gmail was a corporate solution: one customer executive would shout about it, and there would be this type of disgusting hack. Fast forward 5 years, and people then wonder "why are all our internal tools so crappy compared to free cloud stuff?"...

They already treat Trash/Bin as a special concept internally. They have since launch. You cannot have 'Trash' and other tags/labels, like 'Inbox' set at the same time, for instance.

So it might be a disgusting hack, but it's been whatever it is since launch, although incompletely.

Not to mention they actually correspond with different IMAP folders too, so you could change that and suddenly the IMAP folders in your mail account will sync differently.

This does not sound like a hard problem at all. Just check the query for localizable keywords ( :{KEYWORD} ), and replace that with the word it represents.

So if the query is "in:bin" just convert that to "in:trash" and use that for searching, without the user knowing. Then you also have no problem with switching languages.

Namespaced system labels (e.g. gmail:trash, gmail:bin) with one canonical representation which is actually stored in the database, these can be aliased in the backend to all of the localized labels.

Custom user labels can be arbitrary, non-namespaced free text using any string except “gmail”.

Google didn't ask me if I put my trash in a can or my litter in a bin; I just have a folder where my deleted emails go.

Google has the resources to find an answer to your question. It's embarrassing to all of us that they refuse to do so.

Best solution is to use all labels for the trash in all languages as an alias for the same trash folder. The problem here is the tight coupling between the name and the functionality.

You reserve the various names so that users can't create labels that conflict. I think most UK (and us Aussie) users would be quite happy not to be able to create a folder called Trash in exchange for having a folder that represents what we think it should be called.

Reply on news.ycombinator.com