Hacker News Reader

Comment by edent | Hacker News Reader

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.

View on HN

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...

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 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...

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.

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.)

> 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.

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

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.

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...

Reply on news.ycombinator.com