Yes absolutely it should. I think you get a pass if you're a tiny startup on some of your i18n and a11y. But not if you're one of the biggest software companies in the world.
Users should not be expected to know a second language if you offer products in their language. I agree that Arabic and Farsi are somewhat outliers here, but this behaviour impacts languages like German 'Papierkorb'
I would expect searching in:papierkorb to work as expected.
Yes, but localization is not just a matter of finding matching words. In this example, "in dem" (in the) already has a very common abbreviation/colloquialism - "im" - so is a much more natural to use that.
Sure, this was less me trying to correctly localize it, since I would never do that with my absolutely rudimentary command of German (I use phrase.com and professional translators for that) and more defending against the person that knew even less German than me and was making like I hadn't considered that side of the ':'.
I am familiar with 'im' and 'am', from a translating them back to English (while learning), but lack the ability to know the correct times to use them (as in this case).
"in" actually happens to mean more or less the same in German :-)
Of course, it's not quite grammatical without the determiner, making it "in dem Papierkorb" which contracts to "im Papierkorb", but then you could say that about English as well, still we don't write "in:the bin", so "in:Papierkorb" should be OK.
If you want a challenge, there are languages that prefer postpositions ("Trash:in"?) or case suffixes ("Trashin"?) or even circumfixes ("iTrashn"??) – and some case suffixes may happen to be formally equal to the nominative for certain words (so "Trash" could be ambiguous between "in:Trash" and "Trash"). Happy localising.
In this case, I'd say the colon is "localized" to the "computer" language, which can stay constant in all human languages as it is equally a foreign language in all human languages. Though the order could be changed as appropriate.
Despite the advances in AI, computers still need humans to meet them in the middle in their own language quite a bit.
“Doesn’t” implies a singular, “don’t” implies plural. Named groups in British English are typically thought of with a focus on the individuals in the set (hence a plurality), whereas in in American English the focus is on the set itself (hence singular).
I did not know this. I thought "Google don't" is actually grammatically incorrect because "Google" is a proper noun, and it is singular. So it is correct?
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...
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.
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...
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.
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...]
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.
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.
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 :)
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?
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.
> 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.
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.)
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.
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?
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.
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.
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?
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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).
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”.
Localisation is too hard in general, we'd have to separate the interface from the command list, and while it would be technically possible, I'm guessing it would be bringing lots of unintended side effects. The author is mentioning the difference between trash and bin, but the keyword `in` is also in english.
Just thinking about the command implementation in french, the inbox is called `boîte de réception`, good luck on having every user writing it with all the correct tildes.
Gmail's choice is not because it's too hard to localise commands, it's because it creates a lot more stability with the product.
It's not an either-or. They can support locale-invariant identifiers like "trash" for power users, and at the same time also allow for localized names for those who'd rather type it out on the rare occasion they want to use it. OSes have figured this out more than a decade ago.
The fact there are spaces in it might cause problems, but I somehow doubt that the native French speakers this would be targeted at are going to have much difficulty typing accented letters in the right place.
I quit Gmail because "Google Evil",
but came back because I struggled to find a client as good as Gmail's basic HTML one.
Does anyone know of a mail service with one as good?
It could be something paid or a generic webmail client too.
I find Fastmail's web interface to be much better that Gmail.
Faster, easier to navigate, more intuitive, less clutter, and can be set up to not open images by default (if you don't want the sender to know whether or not you've opened their email).
I use it for a few years now, and I have zero complaints.
Same. I was worried that the lack of Gmail's search (which is fantastic) would bother me, but so far it hasn't. ProtonMail still searches message metadata just fine and that seems to have been enough for me so far.
Relatedly, there was an unintentionally funny translation of Gmail in Hungarian, where it was supposed to say "You have no conversations in Trash", or something like that. The translation was technically correct, but it sounded very much like "No more talking in the trashcan!", which was hard to read without imagining someone shouting at a trashcan with a person inside it.
It is quite common with Hungarian translators I have been told. Hungarian translations typically do not make sense given the context, especially when that context is anything IT related. It is like they are being given sentences to translate without telling them the context, and you get some funny translations.
Yes, that's exactly how low-end translation works. You get an Excel sheet with two columns, one labeled "English" and the other "Hungarian" (or whatever), and you get paid some laughable rate per word.
> It is like they are being given sentences to translate without telling them the context
This is a pretty common localization problem. Tooling doesn't always make it easy to share context with translators who are often contractors for outside agencies. Unfamiliar developers try to do string math instead of laying out full sentances to translate. People are surprised to find the same original sentence needs different translations on different screens.
Of course, Google has lots of experience with localization, so should really have this down by now.
Outlook's Portuguese translation uses the word "Lixo" (Trash/Garbage) for the "Spam" button. Sometimes people report emails as spam when they're trying to delete them.
This kind of "desired" behavior sounds like it'd lead to the same funny look Excel has had when implementing translated formula function names across localizations.
I'm a software developer on a daily basis, whose native language is not English. In this environment, pretty much all keywords are in English and having this perspective, I automatically treat words like "trash", "spam" as just keywords - it would seem weird to have them localized. I have never thought of these words to be an issue for an English speaker. I do agree though that words in en_US may sound weird for somebody speaking other dialects of en_*.
After many years of HTML development, I still spell `colour` with a "U"!
I suspect it is easier if everything is a foreign language to you. But it's really easy to trip up between eb_GB and en_US because of their similarities.
So are you arguing that CSS should also be localized? (In my opinion that would clearly be a terrible idea, and most of the reasons why apply to Gmail as well)
I mean, it would be lovely if HTML (invented by a British English speaker) used en_GB throughout. I think it's only "dialogue" which is misspelled in HTML5. Although the obsolete "centre" element is also wrong ;-)
Well I much prefer as an Australian to develop programs, not programmes. My analog to digital converters work just as well without vaguely French "ue" extensions.
Single items of information are still data, not datum.
Among many things in HTTP/HTML/etc that bug me is "referer".
Yep, I'll never understand why you should localize IT terms. You only make UIs more confusing.
Do localize english text but not the digital concepts.
But then, my native language uses "mouse" (the english word as-is) for the computer peripheral, not the word we use for the mouse animal. There were some silly nationalists who wanted to translate everything, but they got laughed at so much that all such proposals died.
In Canada, we have laws that penalize our companies for not having "accurate" French translations. At my company, I notice this makes the managers very concerned, so they don't take any chances on translations.
We also get a lot of "french language warriors" who call our call centers and complain about ANY mistake they can find. One that pops up frequently is if we use the incorrect punctuation mark (" as opposed to « and » for French), which happens a lot if a naïve marketing manager is copying and pasting text without regard for the format.
We didn't get to keep speaking our language by silently accepting whatever the Anglos were willing do do (historically not much). Forgive us if we have to be forceful sometimes.
I'm just noting the dichotomy between a non-english speaker saying "just use the english IT terms!" and other non-english speakers essentially saying "don't erase my language!".
It depends on the geopolitical context. Here in Québec we've been under constant threat of losing our language since the annexation of Nouvelle-France by the British in the 1700s. Google "speak white" if you want to know the kind of assault our language has been under even as recently as the 1960s. Even today, there's a growing number of lazy shop owners in Montréal who just don't bother serving customers in French.
I'm guessing the situation is radically different in, say, Latin America. They can probably afford to use english IT terms. We can't, because it won't stop at IT.
Sure it might be nice with new words to have a distinction between animal mice and computer mouse.
I am not dogmatically against using english words if they are commonly used but I am against avoiding native words becouse it sounds abit like corparate speak to me.
Same with localized functions in eg Excel or Google Spreadsheets. I've grown so accustomed to the English terms it hard to remember or guess my local variants.
Why would you open the article with a pot shot at Americans and American English if the goal of the article is to get an American company to cater to your linguistic needs?
Well the example shows it's a problem in German too, which is spoken in parts of Switzerland, and Switzerland is a third world country due to being unaligned in the Cold War, so I think it'll be a problem in any non-US-English-speaking country. In fact, it's a least first world problem due to that.
Funnily it renamed the „folders“, technically labels, in IMAP. So I am using imapfilter to sort emails and had to change Trash -> Bin in my rules when I switched the GMail Interface Language.
I don’t think this would be a good idea, since this is also the syntax used by Gmail filters. Excel localizes formulas, which means any kind of example or documentation in a different language than your version of the program is nearly useless to you. Code-ish things work best when you stick to a single, canonical language.
For the German example in the article, would you expect “im:Papierkorb” to work?
"The Irish writer George Bernard Shaw once said: 'England and America are two countries divided by a common language'"
As a non American english speaking British person, the americanisation of our language continues to irk me. It's a constant situation of scrolling down localisation dropdowns triyng to find out if my locale or language, is 'English (UK)' or 'British' or 'Great Britain' or 'United Kingdom'[1], or simply not even there with just 'English' listed (which of course is US English). Then to add more salt to the wound, I'll find a dropdown that is in Alphabetical order, except for 'United States' which for some reason is pinned to the top.
Because we Brits share a language with the US, and because most software is written by americans, or by people who learnt american english as a second language, our language is being steadily eroded. If it were any other language being abused, there would be campaigns to stop it happening.
---
[1] No, Great Britain, and the United Kingdom are not the same, and are therefore not interchangable.
> No, Great Britain, and the United Kingdom are not the same, and are therefore not interchangable.
My first encounter with this came from "How to be an Alien" by George Mikes:
> "You must understand that when people say ‘England’, they sometimes mean ‘Great Britain’, sometimes ‘the United Kingdom’, sometimes the ‘British Isles’ – but never just England."
Only because you are looking downstream do you complain, but as an American trying to learn Dutch, I now see just how screwed up English is thanks to all the mixing of powers and cultures (and isolated non writers) of England over time.
But let's talk about "bin". That is the second word of "rubbish bin" I assume. So why adopt the general, non rubbish word as your standard trash container name? Because of that odd choice, now you have to explicitly state what kind of non-rubbush bin a bin is else it is confusedly assumed to be the trash.
"Trash" for Americans is short for "trash can," which traces its roots to "ash can."
When my parents grew up, people in cities still burned their trash in their backyards, or in special cans on their balconies. The ashes were put in an "ash can" and put out for the "ash man" to collect.
When burning became illegal, people started throwing garbage in their ash cans, and the word transformed into "trash can."
At least that's the story as related to me by my parents and grandparents. The ones who are still alive still refer to it as an "ash can" for this reason.
>our language is being steadily eroded. If it were any other language being abused, there would be campaigns to stop it happening.
I disagree and vehemently. The strength of the English language is its ability to change and absorb words from other languages. Your proposal to have campaigns restricting change leads to the decay of a language and to oddities like "courriel" instead of email in Quebec French which - mind you - tries to keep itself free of English borrowings. See also the needlessly long compound words in languages like Dutch and German. Even Finnish has "speaking box" instead of telephone.
This is a road you won't like. I think you should accept that English is no longer "your" language. It belongs to everyone now.
I completely agree with your point against the GP that compound words are not at all seen as "needlessly long" by speakers of those languages.
But with regard to Finnish, while Finnish is a Uralic language and not an Indo-European one, the Finnish language today is replete with calques on Swedish and German, because those were the prestige languages in the region when the modern Finnish literary standard was being created and new words coined.
I'm not sure what Finnish word you are referring to. The word for telephone, however, is not a compound word, and it's even quite succinct. You can see the etymology here: https://en.wiktionary.org/wiki/-in#Etymology_6
How is courriel an oddity though? It's just the same thing as email, a shortening of "electronic mail".
Also, many of the "needlessly long" compound words in Dutch and German are just the same as in English and French, except those languages use equally long Greek or Latin compound words instead.
United Kingdom is 4 countries, England, Scotland, Northern Ireland, Wales (and a bunch of minor additions).
Great Britain is the island that contains England, Scotland and Wales.
A citizen of the United Kingdom is British, even if they live in Northern Ireland.
What you're complaining about is basically about spelling, not usage or "language".
Many of the so-called "misspellings" in en_US vs en_GB aren't if you look at the OED, for example, the -ise and -ize. Having "u"s in spelling (eg colour) is a left over of the French influence on English in the UK.
A lot of the changes in spelling are because Noah Webster, when creating the first US dictionary, simplified things, eg axe vs ax. Some of the word usage, eg "gotten" came over to the US but faded out in the UK.
Speaking as a mostly recovered pedant, I heartily recommend giving in and just working in US english (all the time when coding, as needed in emails and discussion threads). It's so much easier just to use "color", "center" etc, and generally stop fretting about it.
Keep speaking and writing proper English at home, of course!
Because we Brits share a language with the US, and because most software is written by americans, or by people who learnt american english as a second language, our language is being steadily eroded.
I'm not sure there's any solution to that, unfortunately... Possibly building new software from scratch, and putting in place a strict style policy that code and comments must be in British English?
Non-native english speaker who has worked on both sides of the pond and which mother language is known for being regulated by an Authority: I prefer the flexible approach of most anglo world. I find anglospeakers much less pedantic.
While I appreciate the importance of formality and precision there's way less time wasted (most times) when people don't get hung up in pedantic ortographic or even (relavitively) common signifiers.
I do insist in britishisms when I write to American colleagues but obviously have to fallback to en-US when coding. The cost is: I have struggled a bit with grey/gray in stylesheets in the past.
the americanisation of our language continues to irk me
It goes both ways. Especially on the internet, a lot of Americans pick up wonky spellings and phrases from your end of the ocean.
It's just a fashion that comes and goes. For example, back in the late 17th/early 18th century, England went through a wave of Francophilia which altered the spellings of a number of common words. By then, the United States was becoming more independent and because of geography wasn't part of that craze, so some of the legacy spellings remained here.
In the early 20th century, American newspaper publishers pushed for simpler spellings of some words ("thru"), in order to save money on newspaper and ink. They became common in the United States, but less so in other English-speaking countries.
Don't let it irk you. It's not worth it. Humans are messy.
This strikes me in particular if you compare it with e.g. the enormous work on localization at Microsoft in the 90s, where they basically introduced local IT terminology for much of the world.
The former Italian team leader (who made various decisions such as maintaining "File" in Italian, but translating Folder to Cartella, and much more) now hosts a wonderful blog on tech translations.
The author did consider that. He tested a folder with a space in it, and found that searching for `whatever in:folder name` works just fine without quoting.
Localisation is hard. Fullstop. It's obviously (technically) hard to create and maintain software in various languages. It's laborious. It's mostly a manual process.
But can't help but think its made harder because there's this sense (among those managing resources) that its a nice to have, not a crucial aspect of product development. Which is funny because software, specially web software aims at a global market (at least implicitly).
In my experience localization is even less prioritized than accessibility (non locale related accessibility). Maybe because there's more awareness around a11y. Likely because unless you're actively working in a specific market (with a specific locale) you don't care about making it readable for that market, and yet you gladly take credit card details from that market.
On the other hannd, and while I'm an ignorant in these matters, I'm really surprised that AI/ML is not helping us more on localization and yet, we can make it make up new'ish text (in en-US), replace people's faces instantly in photos and recognize faces in google photos.
Well, there's also too much localisation (or localization as the Americans call it :) )
Like Excel renaming all its formula names which is a huge problem with cross-language excel sheets. There is a reason we don't translate programming languages and this is the same thing.
I used computers before localisation was a thing (we didn't even have localised keyboards) so I always have everything set to US English (even though I endeavour to speak British English).
However I agree, if you localise it should all work properly.
In many continental European countries and countries like Brazil, the same number is written 3.000,00.
I once generated a CSV in my program which could not be read correctly in Excel in Brazil. I later figured out that I had to use another delimiter than a comma, because the comma was the decimal separator.
Ooooh is that why CSV files never open properly for me.
I always have to do "File -> Open" instead of just doubleclicking because then I get everything in one column. Indeed if I do file -> Open it defaults to semicolon. Grrr.
I never understood why this happened, I thought the developers of Excel were just stupid. Actually now that I understand why, I still think so :P Indeed CSV means Comma Separated Values.
Yes and we in Europe use DD-MM-YYYY not MM-DD-YYYY.
Excel is very dumb in how it deals with this. When it thinks dates should be DD-MM and you paste a bunch of dates in MM-DD format it will parse the 'invalid' combos correctly (like 01-31) but it will leave the others alone. It should just realise "hey this is not the format I expect" and do them all correctly). Because if you don't notice you now have a whole bunch of half correct / half incorrect data and no way to tell which is which. it doesn't even flag the cells with a warning or comment. Or even pop up a warning to the user that something is off.
Also, if I paste a whole load of numbers starting with zeros then YES I want them as text, not for them to be changed to 1.374E+22. Great with stuff like serial numbers or IMEIs.
Microsoft with all their self-proclaimed AI chops should really apply some of that to Office. All these things have worked this way since the 90s.
PS: Part of the issue is also that MS doesn't have an intuitive application for databases, and because nobody groks Access everyone uses Excel as a database which it isn't. Causing a stinking pile un unmaintainable VLOOKUP crap.
Number formatting in C and many languages following the system locale by default? Better remember to disable that for config files or anything shared between computers.
Localised error messages (especially compiler errors)? Have fun searching for a solution.
Websites (hey Google) assuming that you want things to be in some language based on your location.
Command-line utilities printing using localised date formats which are then parsed elsewhere...
I don't think this is a localisation issue. Gmail's search box semantics are unusably bad no matter what language you use.
If I click "Inbox", Gmail takes me to my "primary inbox" where my non-spam emails land. As far as I'm concerned, that's my inbox. It takes another click to "promotions" or "social" to see all the unwanted advertising semi-spam mail that I probably signed up for but don't want to read. Google is really good at this bit.
But to search for unread emails in this inbox, you can't do "in:inbox" because that brings back all the mails from "social" and "promotions", and the interface for search results doesn't have the same 3 tabs, so the relevant emails are buried a hundred pages down. "in:primary" doesn't work either. The magic incantation is "category:primary is:unread", but at various points in the past you've needed instead to use "is" or "in" or "label" instead.
Google supports you searching for messages by content. Type the words or the sender's name and you'll find the email. Advanced search is an afterthought or downright discouraged, in the same way it's been made less powerful on Web searches than it was in 2001.
Also, "in:" in a misnomer as emails aren't "in" a mailbox, GMail uses tags / labels. So technically you can label an email as both sent and inbox (include yourself in the recipient list).
This label rather than mailbox approach is clearly visible if you ever use the IMAP interface to GMail; it breaks assumptions / guidelines / rules in the IMAP protocol.
On top of that GMail sometimes treats some special labels as exclusive to other special labels (i.e. some of the built in always available labels). i.e. something can't have the inbox and trash labels at the same time.
> Also, "in:" in a misnomer as emails aren't "in" a mailbox, GMail uses tags / labels. So technically you can label an email as both sent and inbox (include yourself in the recipient list).
in is fine, just interpret tags as sets of emails.
1. there is a - which is the not command
2. there are multiple inbox types that can default categorize to stay away from the different top tabs of promotion and social, all of which take one click to change
The content matching is a little fuzzy, IIRC. I've searched for an exact string, which matched nothing, but google returned a list of partial matches. I didn't realize they were partial matches, and wasted a few minutes trying to find what I was looking for in those messages, only to realize, it wasn't there. And I couldn't find a way to get gmail to just show that nothing matched what I was looking for.
I’ve come across this many times- mainly during ediscovery exports for IT clients. Best info I could find is that gmail does NOT support exact phrase matching , at all. (ie in the search “cat dog” , the quotes are ignored , so “my cat my dog is green” is returned as a match , unfortunately)
This very much limits ediscovery flexibility and is unbelievable for a company that specializes in search
I'm sorry but I don't agree with the author. APIs should be as unambiguous as possible. Creating a scenario where one user with a localization of en_UK tries to share a filter with a user with en_US and suddenly it doesn't work is not an acceptable outcome IMO.
The UI should absolutely be localized and clicking the "filter messages in the bin" button should add "in:trash" into the search bar.
If I were using software or services created by Arabic-speaking developers or from a company that does business primarily in Arabic, sure. I would expect such things, in fact.
The whole issue is designing software around the assumption that there will be a primary group.
It means all other groups become second class citizens, and you might not even understand who will be your real primary group at the time of coding the service.
In theory, I agree: there should be no second-class users of any software.
In practice, I'm not sure how that's possible. I18N is hard, really, really hard, to the point that only very large teams can really get things even close to right. Really, you almost need as many people working on the issue as there are written languages, or at least some people are going to be second-class users, right?
But let's says we stick with EFIGS, since that covers most of the western world and supporting Arabic and several different Asian character sets is well outside the expertise of the majority of people reading this page. That's still really, really complex.
Maybe most of all for Americans, who can easily live our entire lives without encountering anything other than American culture.
I mean, I've spent a lot of time trying to tease Traditional Chinese subtitles apart from Simplified Chinese subtitles, and then watching how the resulting Chinese subtitles handle large numbers, to know that I'm not the person for the job!
If that string works worldwide, then fine. At some point you're going to tick off someone. IMO it's better to be consistent.
As a counter example, why aren't URLs in arabic too, for example? "https://news.ycombinator.com/login" doesn't make sense to an arabic speaker. Should we also force service providers to alias "/login" to "/تسجيل الدخول" as well?(forgive me, I just googled 'login in arabic' and picked the first result)
You could make the same argument about every programming language in use today. I don't see a mainstream programming language that doesn't use english based reserved words; for better or worse, the legacy of ASCII and english lives on.
Yes I would consider the search string as a kind of api, just like bang sequences in DuckDuckGo. I think of an api as anything where you send input to a service that is validated against a syntax of some sort and affects the execution of the program. It’s a broad definition.
Why wouldn’t you as a user expect that the search strings be portable across accounts? It would be surprising, especially if the changes across locales was small such as the one in this article. I have copied and pasted filters from blogs on the web for example to get some more complex queries. It’s not like you get a lot of feedback from gmail if you get it “wrong”.
Your comments on naming are on target and that’s why we end up with ugly guids across Windows, for example. I mean who wouldn’t know that your trash folder is really {4f342ebb-d392-4a7d-8db8-3f718c1bcd71}. But that would make for an entirely unusable experience for 100% of users. I would assume that, just like a programming language, “trash” is a reserved word and you can’t use it for the name of your own tags. I have not tried it though.
This is ultimately a subjective decision to make. I’ve done this hundreds of times when designing APIs. Balance usability across multiple user bases and maintain compatibility with decisions that I’m sure were made decades ago when gmail was a beta project in the early 2000s. It’s a problem with no “right” answer, so I think having a guiding principle - such as prioritizing consistency - can make those decisions easier and result in a more sane api.
This particular one is IMO not so much a localization issue, but a UX issue; they decided on a text-based interface for search, instead of a more obvious one, like going to the "bin" folder and finding a search box in there (with a help text saying "search in this folder"). As a random example; I'm not a UX expert.
The issue is a text-based search where the keywords and commands are not localized.
It's what Excel has tried as well, renaming functions to localized versions; I cannot imagine how big of a headache that must have been / be for its developers.
Excel's example is a big headache for us developers that sometimes have to interface with this as well. Really hard to search for documentation etc. when the formulas are localized.
193 comments
[ 2.0 ms ] story [ 308 ms ] threadOr do you expect users in language A to also know language B in order to work with the interface?
Users should not be expected to know a second language if you offer products in their language. I agree that Arabic and Farsi are somewhat outliers here, but this behaviour impacts languages like German 'Papierkorb'
I would expect searching in:papierkorb to work as expected.
I am familiar with 'im' and 'am', from a translating them back to English (while learning), but lack the ability to know the correct times to use them (as in this case).
Of course, it's not quite grammatical without the determiner, making it "in dem Papierkorb" which contracts to "im Papierkorb", but then you could say that about English as well, still we don't write "in:the bin", so "in:Papierkorb" should be OK.
If you want a challenge, there are languages that prefer postpositions ("Trash:in"?) or case suffixes ("Trashin"?) or even circumfixes ("iTrashn"??) – and some case suffixes may happen to be formally equal to the nominative for certain words (so "Trash" could be ambiguous between "in:Trash" and "Trash"). Happy localising.
Despite the advances in AI, computers still need humans to meet them in the middle in their own language quite a bit.
Another difference with of british people. “Doesn’t” is the correct word here, to me.
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...
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"
So it might be a disgusting hack, but it's been whatever it is since launch, although incompletely.
This isn't a new concept in computer science.
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.
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 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.
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?
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.
No one is suggesting that there is, but there are definitely better solutions than what GMail is doing.
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.
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.
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.
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.
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.
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.
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.
Google has the resources to find an answer to your question. It's embarrassing to all of us that they refuse to do so.
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).
Custom user labels can be arbitrary, non-namespaced free text using any string except “gmail”.
Just thinking about the command implementation in french, the inbox is called `boîte de réception`, good luck on having every user writing it with all the correct tildes.
Gmail's choice is not because it's too hard to localise commands, it's because it creates a lot more stability with the product.
Faster, easier to navigate, more intuitive, less clutter, and can be set up to not open images by default (if you don't want the sender to know whether or not you've opened their email).
I use it for a few years now, and I have zero complaints.
still a few phrases came out awkward
This is a pretty common localization problem. Tooling doesn't always make it easy to share context with translators who are often contractors for outside agencies. Unfamiliar developers try to do string math instead of laying out full sentances to translate. People are surprised to find the same original sentence needs different translations on different screens.
Of course, Google has lots of experience with localization, so should really have this down by now.
- In the UK, Gmail's "Trash" folder is labelled "Bin"
- "in:folderName" allows you to search for emails in a specific folder in Gmail
- However searching in:Bin does not work
Saved you a click!
I wonder if the user switched languages at some point, or if someone was overly lazy with en-GB and missed this.
[1] https://stackoverflow.com/questions/2185391/localized-gmail-...
I suspect it is easier if everything is a foreign language to you. But it's really easy to trip up between eb_GB and en_US because of their similarities.
You might enjoy this article on if PHP were British. https://aloneonahill.com/blog/if-php-were-british/
Single items of information are still data, not datum.
Among many things in HTTP/HTML/etc that bug me is "referer".
At least that’s equally wrong for everyone.
what's unfortunate is that http is self-consciously inconsistent about the spelling: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re...
Do localize english text but not the digital concepts.
But then, my native language uses "mouse" (the english word as-is) for the computer peripheral, not the word we use for the mouse animal. There were some silly nationalists who wanted to translate everything, but they got laughed at so much that all such proposals died.
We also get a lot of "french language warriors" who call our call centers and complain about ANY mistake they can find. One that pops up frequently is if we use the incorrect punctuation mark (" as opposed to « and » for French), which happens a lot if a naïve marketing manager is copying and pasting text without regard for the format.
As I said, actual text is nice to be translated, and translated right... but not the menus and stuff like that.
I'm guessing the situation is radically different in, say, Latin America. They can probably afford to use english IT terms. We can't, because it won't stop at IT.
I am not dogmatically against using english words if they are commonly used but I am against avoiding native words becouse it sounds abit like corparate speak to me.
Why would you open the article with a pot shot at Americans and American English if the goal of the article is to get an American company to cater to your linguistic needs?
For the German example in the article, would you expect “im:Papierkorb” to work?
As a non American english speaking British person, the americanisation of our language continues to irk me. It's a constant situation of scrolling down localisation dropdowns triyng to find out if my locale or language, is 'English (UK)' or 'British' or 'Great Britain' or 'United Kingdom'[1], or simply not even there with just 'English' listed (which of course is US English). Then to add more salt to the wound, I'll find a dropdown that is in Alphabetical order, except for 'United States' which for some reason is pinned to the top.
Because we Brits share a language with the US, and because most software is written by americans, or by people who learnt american english as a second language, our language is being steadily eroded. If it were any other language being abused, there would be campaigns to stop it happening.
---
[1] No, Great Britain, and the United Kingdom are not the same, and are therefore not interchangable.
My first encounter with this came from "How to be an Alien" by George Mikes:
> "You must understand that when people say ‘England’, they sometimes mean ‘Great Britain’, sometimes ‘the United Kingdom’, sometimes the ‘British Isles’ – but never just England."
:P
But let's talk about "bin". That is the second word of "rubbish bin" I assume. So why adopt the general, non rubbish word as your standard trash container name? Because of that odd choice, now you have to explicitly state what kind of non-rubbush bin a bin is else it is confusedly assumed to be the trash.
When my parents grew up, people in cities still burned their trash in their backyards, or in special cans on their balconies. The ashes were put in an "ash can" and put out for the "ash man" to collect.
When burning became illegal, people started throwing garbage in their ash cans, and the word transformed into "trash can."
At least that's the story as related to me by my parents and grandparents. The ones who are still alive still refer to it as an "ash can" for this reason.
I disagree and vehemently. The strength of the English language is its ability to change and absorb words from other languages. Your proposal to have campaigns restricting change leads to the decay of a language and to oddities like "courriel" instead of email in Quebec French which - mind you - tries to keep itself free of English borrowings. See also the needlessly long compound words in languages like Dutch and German. Even Finnish has "speaking box" instead of telephone.
This is a road you won't like. I think you should accept that English is no longer "your" language. It belongs to everyone now.
German for telephone: Fernsprecher, or "far speaking"
So how is that better or worse than "speaking box".
Finnish is a weird outlier that is similar to Hungarian but different to most other Germanic/Latin/Greek derived European languages.
But with regard to Finnish, while Finnish is a Uralic language and not an Indo-European one, the Finnish language today is replete with calques on Swedish and German, because those were the prestige languages in the region when the modern Finnish literary standard was being created and new words coined.
Also, many of the "needlessly long" compound words in Dutch and German are just the same as in English and French, except those languages use equally long Greek or Latin compound words instead.
Great Britain is the island that contains England, Scotland and Wales.
A citizen of the United Kingdom is British, even if they live in Northern Ireland.
What you're complaining about is basically about spelling, not usage or "language".
Many of the so-called "misspellings" in en_US vs en_GB aren't if you look at the OED, for example, the -ise and -ize. Having "u"s in spelling (eg colour) is a left over of the French influence on English in the UK.
A lot of the changes in spelling are because Noah Webster, when creating the first US dictionary, simplified things, eg axe vs ax. Some of the word usage, eg "gotten" came over to the US but faded out in the UK.
Oh, and it's spelled "americanization" :)
Keep speaking and writing proper English at home, of course!
Because we Brits share a language with the US, and because most software is written by americans, or by people who learnt american english as a second language, our language is being steadily eroded.
I'm not sure there's any solution to that, unfortunately... Possibly building new software from scratch, and putting in place a strict style policy that code and comments must be in British English?
While I appreciate the importance of formality and precision there's way less time wasted (most times) when people don't get hung up in pedantic ortographic or even (relavitively) common signifiers.
I do insist in britishisms when I write to American colleagues but obviously have to fallback to en-US when coding. The cost is: I have struggled a bit with grey/gray in stylesheets in the past.
It goes both ways. Especially on the internet, a lot of Americans pick up wonky spellings and phrases from your end of the ocean.
It's just a fashion that comes and goes. For example, back in the late 17th/early 18th century, England went through a wave of Francophilia which altered the spellings of a number of common words. By then, the United States was becoming more independent and because of geography wasn't part of that craze, so some of the legacy spellings remained here.
In the early 20th century, American newspaper publishers pushed for simpler spellings of some words ("thru"), in order to save money on newspaper and ink. They became common in the United States, but less so in other English-speaking countries.
Don't let it irk you. It's not worth it. Humans are messy.
Go read medieval english and see how you like it. I’m sure as it became popular Latin speakers despised it.
I don’t know of such a language, but I’m sure it exists... At least you shouldn’t assume that it doesn’t exist.
You would have to resort to quoting, maybe? in:”Trash can”
But can't help but think its made harder because there's this sense (among those managing resources) that its a nice to have, not a crucial aspect of product development. Which is funny because software, specially web software aims at a global market (at least implicitly).
In my experience localization is even less prioritized than accessibility (non locale related accessibility). Maybe because there's more awareness around a11y. Likely because unless you're actively working in a specific market (with a specific locale) you don't care about making it readable for that market, and yet you gladly take credit card details from that market.
On the other hannd, and while I'm an ignorant in these matters, I'm really surprised that AI/ML is not helping us more on localization and yet, we can make it make up new'ish text (in en-US), replace people's faces instantly in photos and recognize faces in google photos.
Like Excel renaming all its formula names which is a huge problem with cross-language excel sheets. There is a reason we don't translate programming languages and this is the same thing.
I used computers before localisation was a thing (we didn't even have localised keyboards) so I always have everything set to US English (even though I endeavour to speak British English).
However I agree, if you localise it should all work properly.
In that context, I think it is wrong to expect people to know multiple languages in order to interact with it.
In the Anglo-Saxon world, we write 3,000.00.
In many continental European countries and countries like Brazil, the same number is written 3.000,00.
I once generated a CSV in my program which could not be read correctly in Excel in Brazil. I later figured out that I had to use another delimiter than a comma, because the comma was the decimal separator.
I always have to do "File -> Open" instead of just doubleclicking because then I get everything in one column. Indeed if I do file -> Open it defaults to semicolon. Grrr.
I never understood why this happened, I thought the developers of Excel were just stupid. Actually now that I understand why, I still think so :P Indeed CSV means Comma Separated Values.
Excel is very dumb in how it deals with this. When it thinks dates should be DD-MM and you paste a bunch of dates in MM-DD format it will parse the 'invalid' combos correctly (like 01-31) but it will leave the others alone. It should just realise "hey this is not the format I expect" and do them all correctly). Because if you don't notice you now have a whole bunch of half correct / half incorrect data and no way to tell which is which. it doesn't even flag the cells with a warning or comment. Or even pop up a warning to the user that something is off.
Also, if I paste a whole load of numbers starting with zeros then YES I want them as text, not for them to be changed to 1.374E+22. Great with stuff like serial numbers or IMEIs.
Microsoft with all their self-proclaimed AI chops should really apply some of that to Office. All these things have worked this way since the 90s.
PS: Part of the issue is also that MS doesn't have an intuitive application for databases, and because nobody groks Access everyone uses Excel as a database which it isn't. Causing a stinking pile un unmaintainable VLOOKUP crap.
While you should be using YYYY-MM-DD. Please at least use a different separator if you don't.
Number formatting in C and many languages following the system locale by default? Better remember to disable that for config files or anything shared between computers.
Localised error messages (especially compiler errors)? Have fun searching for a solution.
Websites (hey Google) assuming that you want things to be in some language based on your location.
Command-line utilities printing using localised date formats which are then parsed elsewhere...
I once tried to remove the US language from Windows, in a vain attempt to stop it continually switching from British to American in random places.
Turns out it breaks all sorts of things.
If I click "Inbox", Gmail takes me to my "primary inbox" where my non-spam emails land. As far as I'm concerned, that's my inbox. It takes another click to "promotions" or "social" to see all the unwanted advertising semi-spam mail that I probably signed up for but don't want to read. Google is really good at this bit.
But to search for unread emails in this inbox, you can't do "in:inbox" because that brings back all the mails from "social" and "promotions", and the interface for search results doesn't have the same 3 tabs, so the relevant emails are buried a hundred pages down. "in:primary" doesn't work either. The magic incantation is "category:primary is:unread", but at various points in the past you've needed instead to use "is" or "in" or "label" instead.
Google supports you searching for messages by content. Type the words or the sender's name and you'll find the email. Advanced search is an afterthought or downright discouraged, in the same way it's been made less powerful on Web searches than it was in 2001.
This label rather than mailbox approach is clearly visible if you ever use the IMAP interface to GMail; it breaks assumptions / guidelines / rules in the IMAP protocol.
On top of that GMail sometimes treats some special labels as exclusive to other special labels (i.e. some of the built in always available labels). i.e. something can't have the inbox and trash labels at the same time.
in is fine, just interpret tags as sets of emails.
This very much limits ediscovery flexibility and is unbelievable for a company that specializes in search
The UI should absolutely be localized and clicking the "filter messages in the bin" button should add "in:trash" into the search bar.
It means all other groups become second class citizens, and you might not even understand who will be your real primary group at the time of coding the service.
In practice, I'm not sure how that's possible. I18N is hard, really, really hard, to the point that only very large teams can really get things even close to right. Really, you almost need as many people working on the issue as there are written languages, or at least some people are going to be second-class users, right?
But let's says we stick with EFIGS, since that covers most of the western world and supporting Arabic and several different Asian character sets is well outside the expertise of the majority of people reading this page. That's still really, really complex.
Maybe most of all for Americans, who can easily live our entire lives without encountering anything other than American culture.
I mean, I've spent a lot of time trying to tease Traditional Chinese subtitles apart from Simplified Chinese subtitles, and then watching how the resulting Chinese subtitles handle large numbers, to know that I'm not the person for the job!
As a counter example, why aren't URLs in arabic too, for example? "https://news.ycombinator.com/login" doesn't make sense to an arabic speaker. Should we also force service providers to alias "/login" to "/تسجيل الدخول" as well?(forgive me, I just googled 'login in arabic' and picked the first result)
You could make the same argument about every programming language in use today. I don't see a mainstream programming language that doesn't use english based reserved words; for better or worse, the legacy of ASCII and english lives on.
What's the API? The search string?
>localization of en_UK tries to share a filter with a user with en_US and suddenly it doesn't work is not an acceptable outcome IMO.
Why not? Does anyone actually want to share filters? Is it even possible to share filters?
>The UI should absolutely be localized and clicking the "filter messages in the bin" button should add "in:trash" into the search bar.
What if you have a 'trash' folder? If anything, they should just use an internal identifier with no semantics attached.
Why wouldn’t you as a user expect that the search strings be portable across accounts? It would be surprising, especially if the changes across locales was small such as the one in this article. I have copied and pasted filters from blogs on the web for example to get some more complex queries. It’s not like you get a lot of feedback from gmail if you get it “wrong”.
Your comments on naming are on target and that’s why we end up with ugly guids across Windows, for example. I mean who wouldn’t know that your trash folder is really {4f342ebb-d392-4a7d-8db8-3f718c1bcd71}. But that would make for an entirely unusable experience for 100% of users. I would assume that, just like a programming language, “trash” is a reserved word and you can’t use it for the name of your own tags. I have not tried it though.
This is ultimately a subjective decision to make. I’ve done this hundreds of times when designing APIs. Balance usability across multiple user bases and maintain compatibility with decisions that I’m sure were made decades ago when gmail was a beta project in the early 2000s. It’s a problem with no “right” answer, so I think having a guiding principle - such as prioritizing consistency - can make those decisions easier and result in a more sane api.
I admin a few g suite users. A common question I get is "I can't find that email" Which is easily resolved by sending them a search query.
It'd be weird if search worked differently based on localisation.
The issue is a text-based search where the keywords and commands are not localized.
It's what Excel has tried as well, renaming functions to localized versions; I cannot imagine how big of a headache that must have been / be for its developers.