5 ms·

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

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!
- ipython 6y ago
  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 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.
macspoofing 6y ago
>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.
- ipython 6y ago
  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.
  - Alphaeus 6y ago
    What if you don't know English? Should you be forced to learn English to search your mailbox that is otherwise in your native language?

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

macspoofing 6y ago

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

ipython 6y ago
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.
- Alphaeus 6y ago
  What if you don't know English? Should you be forced to learn English to search your mailbox that is otherwise in your native language?