Localisation is too hard for Gmail(shkspr.mobi)
shkspr.mobi
Localisation is too hard for Gmail
https://shkspr.mobi/blog/2020/10/localisation-is-too-hard-for-gmail/
193 comments
Do you expect that gmail supports querying for "في: سلة المهملات"?
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.
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'm definitely not a German speaker, but I don't think it should be "in" in "in:papierkorb".
'in' is the same word in German, though I'm not 100% certain either, because my German is basic. "Ich spreche ein bisschen Deutsch".
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).
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.
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.
Despite the advances in AI, computers still need humans to meet them in the middle in their own language quite a bit.
That's really useful for my German learning. I knew that "im" was "in the" I didn't realise it was a contraction. Very slowly learning the language.
In https://mail.google.com/mail/u/0/#settings/general it has settings for both Arabic and Farsi. So, yes.
Or do you expect users in language A to also know language B in order to work with the interface?
Or do you expect users in language A to also know language B in order to work with the interface?
Yes. It's effing gmail. It's a search engine with email functionality.
> Google don’t respond to user complaints or feedback.
Another difference with of british people. “Doesn’t” is the correct word here, to me.
Another difference with of british people. “Doesn’t” is the correct word here, to me.
“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?
Depends if you mean "Google" the corporate entity, or "Google" the collective of its people.
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...
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...
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.
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 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.
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.
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.
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.
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.
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.
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?
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
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.
I use Swedish Windows, and here "C:\Program\" (the localization) and "C:\Program Files\" both work fine and go to the same place.
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...]
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.
This isn't a new concept in computer science.
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...
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? 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...
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.)
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.
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%.
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?
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..
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.
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...
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.
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...
> 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.
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?
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.
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.
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.
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.
There is no perfect solution here.
No one is suggesting that there is, but there are definitely better solutions than what GMail is doing.
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).
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.
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.
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.
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.
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”.
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.
Google has the resources to find an answer to your question. It's embarrassing to all of us that they refuse to do so.
[deleted]
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.
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.
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.
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.
Better than the simple HTML Gmail?
That sounds like it could make me switch.
[deleted]
I like ProtonMail's fine, but I think Google's is slightly better. That being said, there is no way I'm going back to gmail.
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.
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.
The Hungarian translator must have been a fan of Oscar the Grouch.
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.
> 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.
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.
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.
When my work did it, we added another coloumn with "context/explanation" and had devs fluent in that language review the translation.
still a few phrases came out awkward
still a few phrases came out awkward
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.
Google in general is terrible at localization. The worst of the current big players.
This is the same organization that lets you search in Elmer Fudd, Hacker, and Klingon.
I think this is a bug of some sort, not an outright abandonment of localization, because gmail labels definitely are localized. See [1], for instance.
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 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'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.
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 ;-)
You might enjoy this article on if PHP were British. https://aloneonahill.com/blog/if-php-were-british/
You might enjoy this article on if PHP were British. https://aloneonahill.com/blog/if-php-were-british/
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".
Single items of information are still data, not datum.
Among many things in HTTP/HTML/etc that bug me is "referer".
> "referer"
At least that’s equally wrong for everyone.
At least that’s equally wrong for everyone.
the webster in me thinks that's how the word ought to be spelled, maybe web developers will be the vanguard.
what's unfortunate is that http is self-consciously inconsistent about the spelling: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re...
what's unfortunate is that http is self-consciously inconsistent about the spelling: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re...
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.
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.
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 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.
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.
File is called Fichier? :)
As I said, actual text is nice to be translated, and translated right... but not the menus and stuff like that.
As I said, actual text is nice to be translated, and translated right... but not the menus and stuff like that.
"Mouse", "trash" has good native words in all languages I know. It sounds quote silly mixing in english when you speak.
From my non native point of view, "mouse" is the computer peripheral while a "șoarece" will steal your cheese.
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.
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.
And yet, in at least 2 Asian languages, they get over it
(English, Simplified United States)
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?
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?
Truly first world problems.
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?
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.
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.
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.
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.
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.
Oh, and it's spelled "americanization" :)
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" :)
>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 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.
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.
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.
tele-phone... tele, greek for "far", phone, from the greek for "voice".
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.
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.
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.
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.
das Telefon is much more common than Fernsprecher in my non-native experience
Most people would probably not even understand "Fernsprecher" at this point. It's really old-fashioned.
Finnish puhelin ‘telephone’ is not ‘speaking box’ but ‘speaking device’, and it is derived by morphology, not compounding.
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
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?
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.
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.
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.
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.
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.
> 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
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
English is always changing you just don’t like the current changes.
Go read medieval english and see how you like it. I’m sure as it became popular Latin speakers despised it.
Go read medieval english and see how you like it. I’m sure as it became popular Latin speakers despised it.
[deleted]
[deleted]
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 didn’t consider the possibility of the translated name having a space in 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”
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”
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.
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.
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.
Comma or dot separators caught me out once.
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.
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.
Yeah, Excel idea that .csv parsing behavior should depend on regional settings is just crazy. "c" in csv stands for comma, not semicolon!
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.
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.
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.
> Yes and we in Europe use DD-MM-YYYY not MM-DD-YYYY.
While you should be using YYYY-MM-DD. Please at least use a different separator if you don't.
While you should be using YYYY-MM-DD. Please at least use a different separator if you don't.
There is absolutely too much localisation?
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...
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...
Sure, but Gmail isn't a programming language used by professional software developers. It is a low-barrier-to-entry method for accessing email.
In that context, I think it is wrong to expect people to know multiple languages in order to interact with it.
In that context, I think it is wrong to expect people to know multiple languages in order to interact with it.
The advanced search filters are a programming language.
I can sympatize.
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.
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.
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.
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.
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.
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
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.
The UI should absolutely be localized and clicking the "filter messages in the bin" button should add "in:trash" into the search bar.
Would you be OK with "filter messages in the bin" adding "في: سلة المهملات" to the search bar?
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.
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.
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.
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!
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!
>APIs should be as unambiguous as possible.
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.
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.
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.
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.
> Why not? Does anyone actually want to share filters? Is it even possible to share filters?
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.
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.
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.
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.
lot of things are to Hard for Google, like kids being able to play music on google made devices via family link on YouTube Music
I'm pretty sure this is because very few users actually use any of the search qualifiers (eg all they ever do is type in the words they want). And they certainly have the data to verify this.
I bet someone decided to the L10N (it was not there at launch) for the label display name (as you observe), and certainly knew they were not addressing the search bar (that would be a much harder change), but figured it's ok since so few people use it.
It sort of makes sense to do the relatively small amount of work needed for the daily use of 99% of your users rather then get stuck on the really hard part for the last 1%.
I bet someone decided to the L10N (it was not there at launch) for the label display name (as you observe), and certainly knew they were not addressing the search bar (that would be a much harder change), but figured it's ok since so few people use it.
It sort of makes sense to do the relatively small amount of work needed for the daily use of 99% of your users rather then get stuck on the really hard part for the last 1%.
Slack does this really well - it remaps things like @here to @ici in French, both to read and write them.
I've been having a localization issue in Gmail that's even more frustrating and unacceptable than this one.
I speak English but regularly correspond with people who speak Hebrew. Hebrew is written from right to left, so "john doe" is written "eod nhoj." This is normal. But when Gmail writes Hebrew names in English, it often transposes the letters only and not the first/last fields, so you end up with "Doe John." The problem is that this happens inconsistently, so you never know if it's going to occur.
I can't tell you how many times I've mixed up people's first and last names, which is embarrassing! Because I don't speak Hebrew, I don't have a natural sense for which names are first names vs which names are last names, so sometimes it's impossible for me to decipher which is which.
Very frustrating.
I speak English but regularly correspond with people who speak Hebrew. Hebrew is written from right to left, so "john doe" is written "eod nhoj." This is normal. But when Gmail writes Hebrew names in English, it often transposes the letters only and not the first/last fields, so you end up with "Doe John." The problem is that this happens inconsistently, so you never know if it's going to occur.
I can't tell you how many times I've mixed up people's first and last names, which is embarrassing! Because I don't speak Hebrew, I don't have a natural sense for which names are first names vs which names are last names, so sometimes it's impossible for me to decipher which is which.
Very frustrating.
If it's any consolation, Israeli names (presumably the names you're encountering in Hebrew) are often ambiguous with respect to both first/last and gender. The latter might be a nice thing from a progressive standpoint, but is particularly challenging in a language that is strictly gendered - you can't say "you" in Hebrew without decided if the subject should be addressed in masculine or feminine.
Example from a quick DDG search for the name "Arnon" which was the first thing that came to mind. Both Yigal Arnon and Arnon Segev are names of attorneys, so Arnon is definitely ambiguous. The latter's law firm employs an associate named Chen Moshe, where Moshe is a common biblical first name (Moses) and Chen could be a man or a woman.
https://segevlaw.com/
Example from a quick DDG search for the name "Arnon" which was the first thing that came to mind. Both Yigal Arnon and Arnon Segev are names of attorneys, so Arnon is definitely ambiguous. The latter's law firm employs an associate named Chen Moshe, where Moshe is a common biblical first name (Moses) and Chen could be a man or a woman.
https://segevlaw.com/
> 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.
Localization is hard. This is one of the big reasons why Europe is not able to re-create Silicon Valley. If a startup in Silicon Valley creates a US only version of a service, they have access to a massive, wealthy market without having to do any localization. While the EU as a whole is larger than the US market, it is split into a lot of different localities with different languages.
Localization is hard. This is one of the big reasons why Europe is not able to re-create Silicon Valley. If a startup in Silicon Valley creates a US only version of a service, they have access to a massive, wealthy market without having to do any localization. While the EU as a whole is larger than the US market, it is split into a lot of different localities with different languages.
The problem here is that the system exposes localized aliases in one context ("Bin" in the "folder" list) but only supports underlying identifiers in another context ("trash" in search). The author is too harsh though:
- Probably only a tiny fraction of users actually know about the "in:folder" search syntax.
- A simpler UX pattern for users who don't use a keyboard for everything is to click on the folder first and then add to the search string to limit search to that folder.
- Folder names must be normalized in some way before being added to the search string, otherwise it would be impossible to search for folders with for example spaces in the name. This normalization could happen in many ways, but if it reduces the character set in any way (such as replacing spaces with hyphens) it's trivial to create "duplicate" folders for search purposes ("foo bar" and "foo-bar", for example). This problem gets worse if they introduce aliases into the mix.
- What about the "in" part of "in:bin"? Surely localizing only part of the API is more confusing than localizing all of it? I've never seen an API framework which encourages this though, probably because it's a shedload of extra complexity for very little gain.
- Probably only a tiny fraction of users actually know about the "in:folder" search syntax.
- A simpler UX pattern for users who don't use a keyboard for everything is to click on the folder first and then add to the search string to limit search to that folder.
- Folder names must be normalized in some way before being added to the search string, otherwise it would be impossible to search for folders with for example spaces in the name. This normalization could happen in many ways, but if it reduces the character set in any way (such as replacing spaces with hyphens) it's trivial to create "duplicate" folders for search purposes ("foo bar" and "foo-bar", for example). This problem gets worse if they introduce aliases into the mix.
- What about the "in" part of "in:bin"? Surely localizing only part of the API is more confusing than localizing all of it? I've never seen an API framework which encourages this though, probably because it's a shedload of extra complexity for very little gain.
Quit complaining, at least they have an en-gb culture.
I know it’s easier to give advice and hindsight is 20/20, but IMO sticking with technical terms in APIs has an added benefit of preventing API from “spilling into” the end GUI (at least without a proper translation layer), in case someone later decides to cut some corners by exposing it as is to the user.
Here in particular, since “trash” is not just a technically imprecise word but also a highly idiomatic one (to North America in particular).
Here in particular, since “trash” is not just a technically imprecise word but also a highly idiomatic one (to North America in particular).
Being mainly a Linux CLI user(ie. no `undo') I'm perfectly fine with not searching the trash.