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.

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.

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

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.

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.

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

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

This isn't a new concept in computer science.

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

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?

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.

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

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

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.

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

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

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.

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.

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.

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

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

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.

I think to solve this 100% you need namespaces.

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

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.

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

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