Localisation is too hard for Gmail
By @edent
· gmail google i18n rant · 10 comments · 300 words · read ~8,054 times.
/ləʊk(ə)lʌɪˈzeɪʃ(ə)n/ The ability to adjust a user-interface to the user's local language or dialect
Because I live in the UK, I speak en_GB (English, Great Britain) rather than en_US (English, Simplified United States).
Mostly, all dialects of English are mutually intelligible. Sure, the Brits love the letter U and the Americans stick a Z in every possible word. But we get along reasonably well. Except in Gmail.
Here's my en_GB localised Gmail interface. Note how there is a folder called "Bin".
Everyone using Gmail in en_GB will know that deleted emails go into the "Bin".
Gmail has a handy search feature to allow you to find emails in a specific folder. For example "Bob in:spam" finds all email containing the word "Bob" in your spam folder. "Proposal in:sent" gets everything you've sent with the word proposal.
But it is impossible to search the "Bin" folder.
Why? Because you have to search the Trash folder. Because that's the names used by Americans.
/hɪˈdʒɛməni/
The same is true even if you've chosen a non-English language. 
Sadly, Google don't respond to user complaints or feedback. The best you can do is hope a ranty blog post gets high enough traction on social media. Then, maybe, something will change.
If you're building a service - remember that localisation is about much more than the GUI. All aspects of the interface need to be considered.
Best of: What I blogged about in 2020
See also Welsh ☹
Localisation is too hard for Gmail Link: shkspr.mobi/blog/2020/10/l… Comments: news.ycombinator.com/item?id=248466…
Jan Ciger (@janoc200) says:
Frankly, I am not sure this is so bad idea. E.g. Excel took the opposite approach - and localized all function names too. So a SUM() became SOMME() in French.
Writing Excel macros is now a horrific mess because one macro that works on your PC doesn't work on colleague's who happens to have a French version! Oh and don't ever try to follow some online tutorial - you would need a dictionary at hand and translate all the function names first.
Given that GMail's filters and search are on a similar level as the Excel macros, I would argue that it does make sense to keep those identifiers non-localized. Or accept both variants (which would likely be a huge mess to deal with internally).
I can understand that reluctance when you don't know the environment you'll be operating in.
But Gmail controls the UI and the logic of Gmail. Are there hordes of people writing complex search queries and sharing them online? Or is it a daily annoyance that you need to remember the syntax and spelling of a foreign language just to find the email you accidentally deleted?
Sven says:
Actually, one could consider allowing SOMME() and SUM(), but why not then also the german SUMME()? In the end, this will result in a lot of reserved keywords for functions, or gmail labels, respectively.
There's a reason why the vast majority of programming languages sticks to english.
Sure - but Gmail isn't a programming environment for professional software developers. It's a low-barrier-to-entry email UI for the whole world.
Ryan says:
I agree with this. I don’t think solving this is actually hard either. Just “translate” the index from the GUI localization to the localization the server understands before sending the query. It’s not like the GUI doesn’t know what locale its configured to.
rcron says:
Excel stores formulas in the format of the US English version, regardless of the language or locale of the end-user's version of Excel
John says:
I mean, this is where things like ids are useful, keep the id, change the descriptive name, look it up on descriptive name or id, then you can write backend things using the id's so it works everywhere, and gui used things have to use the descriptive name lookup to get the id to pass to the backend....
Dvd says:
Also for Canadians, we use UK English, mostly, but have some US influences. Bin is understood here, but believe Trash would be more natural.