17 ms·

Localisation is too hard for Gmail

177 points by edent 6y ago

david_draco 6y ago
Do you expect that gmail supports querying for "في: سلة المهملات"?
- edent 6y ago
  In https://mail.google.com/mail/u/0/#settings/general 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?
- pmlnr 6y ago
  Yes. It's effing gmail. It's a search engine with email functionality.
- vertis 6y ago
  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.
  - input_sh 6y ago
    I'm definitely not a German speaker, but I don't think it should be "in" in "in:papierkorb".
    - vertis 6y ago
      'in' is the same word in German, though I'm not 100% certain either, because my German is basic. "Ich spreche ein bisschen Deutsch".
      - account42 6y ago
        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.
        vertis 6y ago
        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).
    - unhammer 6y ago
      "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.
      - jerf 6y ago
        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.
      - vertis 6y ago
        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.
hobby-coder-guy 6y ago
> Google don’t respond to user complaints or feedback. Another difference with of british people. “Doesn’t” is the correct word here, to me.
- robin_reala 6y ago
  “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).
  - johnisgood 6y ago
    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?
    - rswail 6y ago
      Depends if you mean "Google" the corporate entity, or "Google" the collective of its people.
    - nemetroid 6y ago
      See: https://en.wikipedia.org/wiki/American_and_British_English_grammatical_differences#Subject-verb_agreement https://en.wikipedia.org/wiki/American_and_British_English_g...
londons_explore 6y ago
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...
- gommm 6y ago
  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.
  - int_19h 6y ago
    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?
    - londons_explore 6y ago
      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...
      - kryptiskt 6y ago
        I use Swedish Windows, and here "C:\Program\" (the localization) and "C:\Program Files\" both work fine and go to the same place.
rsoto 6y ago
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.
- int_19h 6y ago
  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.
- jon-wood 6y 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.
bofenbref 6y ago
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.
- input_sh 6y ago
  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.
  - bofenbref 6y ago
    Better than the simple HTML Gmail? That sounds like it could make me switch.
- deleted 6y ago
  [deleted]
- Shared404 6y ago
  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.
  - moduspol 6y ago
    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.
lkozma 6y ago
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.
- smnrchrds 6y ago
  The Hungarian translator must have been a fan of Oscar the Grouch.
  - johnisgood 6y ago
    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.
    - howlgarnish 6y ago
      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.
      - BunsanSpace 6y ago
        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
    - toast0 6y ago
      > 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.
360walk 6y ago
A ranty blog post about the following bug in order to try and get Google to fix it: - 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!
ntauthority 6y ago
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.
praestigiare 6y ago
Google in general is terrible at localization. The worst of the current big players.
- rswail 6y ago
  This is the same organization that lets you search in Elmer Fudd, Hacker, and Klingon.
magicalist 6y ago
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-imap-folders/2185548 https://stackoverflow.com/questions/2185391/localized-gmail-...
pewu 6y ago
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_*.
- edent 6y ago
  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.
  - tobr 6y ago
    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)
    - edent 6y ago
      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/ https://aloneonahill.com/blog/if-php-were-british/
      - rswail 6y ago
        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".
Causality1 6y ago
(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?
kwanbix 6y ago
Truly first world problems.
- eythian 6y ago
  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.
leipert 6y ago
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.
tobr 6y ago
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?
mattowen_uk 6y ago
"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.
- deleted 6y ago
  [deleted]
- the_af 6y ago
  > 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
- blunte 6y ago
  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.
  - 6y ago
butokai 6y ago
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.
jannes 6y ago
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”
- edent 6y ago
  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.
627467 6y ago
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.
GekkePrutser 6y ago
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.
- edent 6y ago
  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.
  - account42 6y ago
    The advanced search filters are a programming language.
- wenc 6y ago
  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.
  - garaetjjte 6y ago
    Yeah, Excel idea that .csv parsing behavior should depend on regional settings is just crazy. "c" in csv stands for comma, not semicolon!
    - GekkePrutser 6y ago
gertrunde 6y ago
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.
dmurray 6y ago
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.
- tankenmate 6y ago
  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.
  - masukomi 6y ago
    also "in" is english.
  - account42 6y ago
    > 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.
ipython 6y ago
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.
- nemetroid 6y ago
  Would you be OK with "filter messages in the bin" adding "في: سلة المهملات" to the search bar?
  - pwinnski 6y ago
    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.
    - hrktb 6y ago
      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.
      - pwinnski 6y ago
        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!
Cthulhu_ 6y ago
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.
- djxfade 6y ago
  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.
bingobob 6y ago
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
lokar 6y ago
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%.
frabcus 6y ago
Slack does this really well - it remaps things like @here to @ici in French, both to read and write them.
panda888888 6y ago
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.
- names_are_hard 6y ago
  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/ https://segevlaw.com/
RcouF1uZ4gsC 6y ago
> 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.
UhDev 6y ago
Quit complaining, at least they have an en-gb culture.
l0b0 6y ago
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.
strogonoff 6y ago
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).
olkid 6y ago
Being mainly a Linux CLI user(ie. no `undo') I'm perfectly fine with not searching the trash.

177 points by edent 6y ago

david_draco 6y ago

Do you expect that gmail supports querying for "في: سلة المهملات"?

edent 6y ago
In https://mail.google.com/mail/u/0/#settings/general 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?
pmlnr 6y ago
Yes. It's effing gmail. It's a search engine with email functionality.
vertis 6y ago
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.
- input_sh 6y ago
  I'm definitely not a German speaker, but I don't think it should be "in" in "in:papierkorb".
  - vertis 6y ago
    'in' is the same word in German, though I'm not 100% certain either, because my German is basic. "Ich spreche ein bisschen Deutsch".
    - account42 6y ago
      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.
      - vertis 6y ago
        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).
  - unhammer 6y ago
    "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.
    - jerf 6y ago
      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.
    - vertis 6y ago
      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.

hobby-coder-guy 6y ago

> Google don’t respond to user complaints or feedback. Another difference with of british people. “Doesn’t” is the correct word here, to me.

robin_reala 6y ago
“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).
- johnisgood 6y ago
  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?
  - rswail 6y ago
    Depends if you mean "Google" the corporate entity, or "Google" the collective of its people.
  - nemetroid 6y ago
    See: https://en.wikipedia.org/wiki/American_and_British_English_grammatical_differences#Subject-verb_agreement https://en.wikipedia.org/wiki/American_and_British_English_g...

londons_explore 6y ago

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

gommm 6y ago
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.
- int_19h 6y ago
  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?
  - londons_explore 6y ago
    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...
    - kryptiskt 6y ago
      I use Swedish Windows, and here "C:\Program\" (the localization) and "C:\Program Files\" both work fine and go to the same place.

rsoto 6y ago

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.

int_19h 6y ago
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.
jon-wood 6y 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.

bofenbref 6y ago

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.

input_sh 6y ago
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.
- bofenbref 6y ago
  Better than the simple HTML Gmail? That sounds like it could make me switch.
deleted 6y ago
[deleted]
Shared404 6y ago
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.
- moduspol 6y ago
  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.

lkozma 6y ago

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.

smnrchrds 6y ago
The Hungarian translator must have been a fan of Oscar the Grouch.
- johnisgood 6y ago
  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.
  - howlgarnish 6y ago
    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.
    - BunsanSpace 6y ago
      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
  - toast0 6y ago
    > 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.

360walk 6y ago

A ranty blog post about the following bug in order to try and get Google to fix it: - 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!

ntauthority 6y ago

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.

praestigiare 6y ago

Google in general is terrible at localization. The worst of the current big players.

rswail 6y ago
This is the same organization that lets you search in Elmer Fudd, Hacker, and Klingon.

magicalist 6y ago

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-imap-folders/2185548 https://stackoverflow.com/questions/2185391/localized-gmail-...

pewu 6y ago

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

edent 6y ago
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.
- tobr 6y ago
  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)
  - edent 6y ago
    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/ https://aloneonahill.com/blog/if-php-were-british/
    - rswail 6y ago
      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".

Causality1 6y ago

(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?

kwanbix 6y ago

Truly first world problems.

eythian 6y ago
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.

leipert 6y ago

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.

tobr 6y ago

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?

mattowen_uk 6y ago

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

deleted 6y ago
[deleted]
the_af 6y ago
> 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
blunte 6y ago
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.
- 6y ago

butokai 6y ago

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.

jannes 6y ago

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”

edent 6y ago
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.

627467 6y ago

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.

GekkePrutser 6y ago

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.

edent 6y ago
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.
- account42 6y ago
  The advanced search filters are a programming language.
wenc 6y ago
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.
- garaetjjte 6y ago
  Yeah, Excel idea that .csv parsing behavior should depend on regional settings is just crazy. "c" in csv stands for comma, not semicolon!
  - GekkePrutser 6y ago

gertrunde 6y ago

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.

dmurray 6y ago

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.

tankenmate 6y ago
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.
- masukomi 6y ago
  also "in" is english.
- account42 6y ago
  > 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.

ipython 6y ago

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.

nemetroid 6y ago
Would you be OK with "filter messages in the bin" adding "في: سلة المهملات" to the search bar?
- pwinnski 6y ago
  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.
  - hrktb 6y ago
    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.
    - pwinnski 6y ago
      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!

Cthulhu_ 6y ago

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.

djxfade 6y ago
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.

bingobob 6y ago

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

lokar 6y ago

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

frabcus 6y ago

Slack does this really well - it remaps things like @here to @ici in French, both to read and write them.

panda888888 6y ago

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.

names_are_hard 6y ago
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/ https://segevlaw.com/

RcouF1uZ4gsC 6y ago

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

UhDev 6y ago

Quit complaining, at least they have an en-gb culture.

l0b0 6y ago

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.

strogonoff 6y ago

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

olkid 6y ago

Being mainly a Linux CLI user(ie. no `undo') I'm perfectly fine with not searching the trash.