The UI should absolutely be localized and clicking the "filter messages in the bin" button should add "in:trash" into the search bar.
It means all other groups become second class citizens, and you might not even understand who will be your real primary group at the time of coding the service.
In practice, I'm not sure how that's possible. I18N is hard, really, really hard, to the point that only very large teams can really get things even close to right. Really, you almost need as many people working on the issue as there are written languages, or at least some people are going to be second-class users, right?
But let's says we stick with EFIGS, since that covers most of the western world and supporting Arabic and several different Asian character sets is well outside the expertise of the majority of people reading this page. That's still really, really complex.
Maybe most of all for Americans, who can easily live our entire lives without encountering anything other than American culture.
I mean, I've spent a lot of time trying to tease Traditional Chinese subtitles apart from Simplified Chinese subtitles, and then watching how the resulting Chinese subtitles handle large numbers, to know that I'm not the person for the job!
As a counter example, why aren't URLs in arabic too, for example? "https://news.ycombinator.com/login" doesn't make sense to an arabic speaker. Should we also force service providers to alias "/login" to "/تسجيل الدخول" as well?(forgive me, I just googled 'login in arabic' and picked the first result)
You could make the same argument about every programming language in use today. I don't see a mainstream programming language that doesn't use english based reserved words; for better or worse, the legacy of ASCII and english lives on.
What's the API? The search string?
>localization of en_UK tries to share a filter with a user with en_US and suddenly it doesn't work is not an acceptable outcome IMO.
Why not? Does anyone actually want to share filters? Is it even possible to share filters?
>The UI should absolutely be localized and clicking the "filter messages in the bin" button should add "in:trash" into the search bar.
What if you have a 'trash' folder? If anything, they should just use an internal identifier with no semantics attached.
Why wouldn’t you as a user expect that the search strings be portable across accounts? It would be surprising, especially if the changes across locales was small such as the one in this article. I have copied and pasted filters from blogs on the web for example to get some more complex queries. It’s not like you get a lot of feedback from gmail if you get it “wrong”.
Your comments on naming are on target and that’s why we end up with ugly guids across Windows, for example. I mean who wouldn’t know that your trash folder is really {4f342ebb-d392-4a7d-8db8-3f718c1bcd71}. But that would make for an entirely unusable experience for 100% of users. I would assume that, just like a programming language, “trash” is a reserved word and you can’t use it for the name of your own tags. I have not tried it though.
This is ultimately a subjective decision to make. I’ve done this hundreds of times when designing APIs. Balance usability across multiple user bases and maintain compatibility with decisions that I’m sure were made decades ago when gmail was a beta project in the early 2000s. It’s a problem with no “right” answer, so I think having a guiding principle - such as prioritizing consistency - can make those decisions easier and result in a more sane api.
I admin a few g suite users. A common question I get is "I can't find that email" Which is easily resolved by sending them a search query.
It'd be weird if search worked differently based on localisation.