American Computing Assumption

Date format

02/03/2000 in the USA is e.g. 03/02/2000 in the UK or 03.02.2000 in Germany. There is an ISO standard for date formats: 2000-02-03.

Man... Are you talking about 2nd of March or the 3rd of February? (lol) -- AlexVanDenBergh

All of the above examples refer to the 3rd of February. IMO, the European notation makes more sense than the American (in that it maintains a consistent order from specific to general), but the ISO format is more sensible than either of them (in that it maintains a consistent order from most general to most specific), though I guess one could consider this a religious "endian-ness" issue. -- MikeSmith (little-endian)

There's a bigger religious issue in the year. -- EricHodges

The huge advantage of the ISO form is that it makes sorting by date much easier than any other form (also by time if you're that way inclined).

It is a good way to apply unique names to objects or files. as in Document.200205151942.alldone.doc Useful in the DottedPrefixExtension? method of handling files.

I learned early on not to use numeric months, so I can write 3-Feb-2002 or Feb 3 2002 freely. However, this obviously works only if you can agree on a language for the month names. I have also seen Roman numerals used on the month so you would have 3 II 2002, and the World-War-I Armistice is 11 XI 1918. But some people would regard Roman numerals as a DateFormatSmell?.

Internet domains used by American companies

Did anyone EVER see anything like www.mycompany.co.us ? Or www.whitehouse.gov.us?

Yes, http://del.icio.us/ -- or is that the exception that proves the rule? More seriously, http://www.state.ok.us/ and http://oslis.k12.or.us/ .

Or .edu being used for a university outside the USA? (OK, www.oxford.edu, but that actually redirects to www.ox.ac.uk) -- AalbertTorsius

Yes, there are. There are conditions, but the institution needs not be located in the USA to get an .edu. Also, a number of domains given without any precondition were grandfathered, and still exist to this day

Phone numbers, addresses, states and zip codes

I buy a lot of stuff on the web. Much of it from the USA. I'd probably buy more if it wasn't for all the AmericanCulturalAssumptions. Could this be the reason for America's trade deficit ?

I can not call your "800" number from outside the USA, and you haven't given me an alternative.

: I do believe you can call it by dialing 801 instead. At least this was possible from Brazil some time ago. They are not free, however. BrazilianCulturalAssumption??
: Answer: To dial an American toll-free number, replace "800" with "880", "888" with "881", or "877" with "882".

Most of our phones have no letters on them (or worse, have them in different positions) so I can not call you on 415-BUY-MORE.

: Answer: ABC=2 DEF=3 GHI=4 JKL=5 MNO=6 PRS=7 TUV=8 WXY=9 (The letters "Q" and "Z" do not appear on the phone. 1 and 0 have no letters.)
: actually, Q and Z appear on my (European) phone (on 7 and 9 respectively)...
: In many countries, like Brazil, most phones are imported from Taiwan, China, etc... They usually follow american positions. ThirdWorldCulturalAssumption??
: Though I've never understood why they didn't put I on 1 and O on 0...
: Because 1 and 0 can be confused with I and O?
: That's the point. If "I" was on "1", then if someone got them confused, he would still dial the correct number.
: At least in the beginning, 0 (zero) was for Operator.

I can not enter my phone number into your mandatory field because of your 999-999-9999 validation

: This is quite stupid, really. Most countries have numbers varying from 6 to 8. Brazil have numbers with 6,7 and 8 numbers. France uses 8.
: more precisely, France _used_ 8. 2 digits (telco prefix and region prefix) have been added since. But the telco digit is to be omitted when calling from outside the country. So, you could say it uses 9 or 10 digits, depending on the locale :-)
: But it's not really a problem: simply fill it up with any digits you like. They will be ignored, because that is how it works - the later digits are passed on to the next extension (e.g. your telephone, which ignores them (or interprets them as answering machine codes etc.)).
: Where do you put the 2 or 3 country digits?

I can't choose a state from your drop-down list. We don't have states. (True story - one bank had me down as living in England, Alaska for a while.) (Another true story - a US post office would not accept a letter I was trying to send because "UK" is not a valid state.)

: Have to say - UK is not the proper way to specify the destination country for international mail - the last line should have the country name spelled out in full, e.g., FRANCE - http://www.pts.pitt.edu/mailserv/internat.htm -- RobertField [also in full and in capitals: UNITED KINGDOM OF GREAT BRITAIN AND NORTHERN IRELAND is thereby mandated by the US postal service! - No, you have your choice of ENGLAND, GREAT BRITAIN, or UNITED KINGDOM. If you just have UK, it might be mistaken for the abbreviation for a U.S. state, either AK for Alaska, or UT for Utah. There really are reasons for most of these rules]
: if you're going to send mail internationally, read http://www.columbia.edu/kermit/postal.html first, it could avoid a lot of delays
: Most countries have some sub-division. At least, you could put "not in USA".

I can't enter a valid 5-digit zip code. I have a post code but it is a mix of letters, digits and spaces.

: Some countries don't even use postcodes at all. To be fair, this is not just an AmericanCulturalAssumption as Irish customers sometimes have problems buying stuff from the UK as the Irish Republic doesn't have postcodes.
: Brazil uses a 8 digit code, much more detailed than 5 digit.
: BTW, I thought ZIP codes were kind of UIT thing.
: The US Post office encourages "ZIP+4" -- meaning that we have nine digit ZIP codes, actually. (Format: '#####-####')

I can't enter my street address. We have street numbers, but after the street's name, not in front of it. And postal service doesn't deliver if the street isn't given where it is supposed to be.

: Blame your postal service here. Mailman in Brazil are proud to deliver anything. My grandmother once receive a letter saying "in the building with a pharmacy".

I have no middle name. I can't enter one.

: I am a European, and when I was in the US, they asked me for my middle name. I don't have one. Once, I remember someone just entering N. in the respective field - for None.
: That's OK, not all United States natives have middle names either.
: Our network people use middle initials to disambiguate user names. When they don't know, they put in X. I made them correct it on my first day.
: I am Mexican, which means I have two first names and two family names. I usually use my second first name as middle name, but sometimes I have to paste my two family names with a hyphen. (Strangely enough, in France I could just use my two family names as-is. Maybe they know how names work in Spain?).

These are just the cases I've come across. I'd hate to deal with US companies from somewhere like Indonesia.

It would probably be just as hard to buy something from a Chinese website and have it shipped to you in California. Or to buy something from a Spanish website and have it shipped to you in Tajikistan. Why is it automatically assumed to be a case of USian parochialism if an ecommerce site isn't 100% internationalized? Internationalization is hard work, and it's very expensive. Companies do it when they think it's worth the money. When they don't think it's worth the money, they don't do it. If you have a problem with that, blame capitalism, not the U.S.

If a company's going to ship something internationally, it should have the necessary changes to do it. It often seems USian parochialism, because European sites don't seem to make the same errors so often. I think there's a difference between fully-internationalizing (doing the right thing for every country - so using the correct terminology for state/province in Spain, for example) - which as you say is a big effort, and being at least international-friendly, which means not imposing your local formats for zip codes, telephone numbers and names on everyone else. The latter isn't a big effort.

Sure, some things are easier than others. The point I'm trying to make, though, is that if a company isn't serving your needs very well, maybe that's not because of some deep-seated prejudice. Maybe that's because they don't think your business is worth their trouble. That's not personal. That's business.

I don't think it's prejudice. I do think it's often a lack of thought. As I said, _if_ you ship internationally, I think that's evidence my business is worth their trouble, and they should to the minimal changes needed not to actively get in the way of me giving them business.''

Or just back off and DoTheSimplestThingThatCouldPossiblyWork. The last time I designed a site which requested addresses, I used a single multi-line text entry box.

Decimal point

In Brazil, France and Germany, it's a comma: "le 9,25" is French for "9.25". Huh, no, it's French for "the 9,25". BTW, I just can't fathom why Americans insist to prefix any French word (including feminine ones!) by "le"... It's what makes it French!

It gets even more confusing since in Portuguese, French and German the point is used for separating groups of three digits, just like the comma is used in English: 1000000 = 1.000.000,0 (fr/de) = 1,000,000.0 (en). This gets even more problematic if the mantissa contains exactly 3 digits: "The process ran 123,456 seconds" (or was it 123.456 seconds?) the recommended method - from the metric FAQ at http://www.cl.cam.ac.uk/~mgk25/metric-system-faq.txt - is to use a space for separating groups of digits, which disambiguates the following comma or point. My opinion is that we should standardize on dot, but I'm a programmer and every computer language already uses the dot as decimal separator, hence I'm probably biased

And here in Russia we use decimal comma and insert half a space (no space or a space in ascii) between groups of three digits: 123456,789 or 123 456,789

Should we apply the microsoft solution and make it 123.,465?

File formats'

Share data with someone outside the US and you'll often get files that are like CommaSeparatedValues except for using decimal comma, and then a semicolon for the field delimiter. Often, an American-grown CSV parser will not make sense of these files.

Isn't it a shame that everybody doesn't do things the same! To do business in or with a culture, you must learn the culture, manners, and practices and conventions, or not do business! To complain about something you can not change, rather than accommodate and adjust, indicates you do not intend to do business!

I actually have a lot of fun learning the little differences between my culture and others'. I'm still learning when to bow (for Japanese or Koreans) and how much. -- EdPoor

You missed the point of this page. It isn't complaining about having to adjust, it is complaining about American-origin programs sometimes not leaving any room to adjust, because the programmers assumed the AmericanComputingAssumption, namely, that everything that is true and appropriate for their American users would be true and appropriate for all their users. Or, equally insulting, that their non-American users are just not that important.

Perhaps the true origination of the assumption was that the program would not be marketed globally, and the rush to be first to market a solution for US users who would be envisioned as the largest user base, necessitates such Assumptions. Those who early adopt it for use in the global arena should take this into account, and change requests and product support requests should have come from such users. If the product does become a global product, and demand is expected to be sufficiently high, such changes would be forthcoming. Currently Programs developed for the International marketplace are written to take into account the region, language and culture of the various software markets, including all of the predominant languages and regional usage patterns. Not only that, but provisions are made for those requiring physical considerations, such as sight, hearing and physical dexterity.

You must realize that adaptations such as these cost labor, material and time. Some developers therefore develop toward a single Assumed Userbase, this is in line with the ExtremeProgramming Maxim of doing the simplest thing that will work. If after initial release, significant demand and possibility of profit from extensions beyond the initial audience develops, such accommodations might be economically viable. Since software development in the US is not normally subsidized in the way it is in some other regions of the world, practical economic forces must be taken into consideration when preparing for other than the major product consumers.

Assumptions are important, even the so-called AmericanComputingAssumption.

Cost reduction and time to market alone cannot explain AmericanComputingAssumption features that actually costs more to do and longer to test, e.g., street address, phone number format and zip code checking mentioned above. Only 1-800 numbers and state drop-down box can be explained by cost reduction.

It's not the developer's cost here, it's the client's. If the client's customer misenters an unusable address in their order, it costs the client money (time, wages) to track it down and correct it. In response to client demand for good data, the developer inserts explicit prompts and form validation in an attempt to force input to be correct the first time.

Replying to the complaint continued (in addition to that just above) ... Where did you see the term cost reduction in my foregoing example?

I spoke of additional costs, not reduced costs! It almost always costs more to produce a product if you add features, options, modes, conversions, languages, functions and operations. The handling of the special circumstances, to make a program work properly in another set of conditions and means of expression, is an addition of cost to the domestic product, even in the simple example of an Internet transaction mentioned above. It is a simple, inexpensive and straightforward transaction within the US, outside the US has the additional consequences of higher cost (international long distance charges paid by the seller), currency conversion, duties and taxes, and governmental regulations which complicate the application and transaction and increases the cost of goods sold and thereby reducing the profit, (if any remains) and incentive to occur such complications.

It would not however be much more cost to provide:

A number as an alternative where an order could be made (where you paid the toll).
A check box which would indicate that you wish to place a non-automated order as in:
- An order by mail.
- An order via fax, where you could write down the appropriate name, address and postal codes and any other delivery information.
- An order via a text box where you could type in just enough how to determine what you want, how you propose to pay and the manner of delivery you would prefer.
- An order which you could send to an email address.
The order would not be as fast, but would not rule out the possibility of completion of the transaction.
The order confirmation would not be instant, and would rely on non-automated handling with the delays, and problems such transactions incur.

Suggest these or others you might think of to the places, sites and businesses where you would like to be able to place orders, I am sure you'll receive a reply.

[You're still missing the point - the input validation provided is a convenience for the company, because unclear or incorrect data costs (lots) of money. One of the major benefits of e-commerce is the automation benefits, if each and every order needs to be manually reviewed and processed by a person (as in all your options above), your costs soar with no corresponding benefit. Therefore, input is restricted in an attempt to make it as valid as possible. That restriction, however, is often biased toward American addresses, phone numbers, etc. This is for a variety of reasons, but especially because correct, globalized validation is incredibly difficult. SimplestThingThatCanPossiblyWork?, right?]

I think you are missing the point. If your internet company ships to fooland, but it is impossible to correctly enter a shipping address for fooland, then your website is broken. The point you are making is valid though, it may be cheaper to not ship to fooland rather than to fix the website. -- JamesKeogh

[If you can't enter a shipping address for fooland, that's a pretty de facto implementation of not shipping to fooland, isn't it? Now, if you intended to be able to ship to fooland, that's something else. I think that places that actively advertise as shipping to, say, the UK but don't have the ability to enter valid UK addresses are relatively rare, and generally small stores in general. Obviously, if a site claims it can ship to a location/country/whatever and it actually can't, you should point that out to them. But assuming that anywhere you do business with will ship internationally is unreasonable.]

By the way, I hear Fooland declared war on Barland :-) Who'd bomb a bar? Fools.

So you think that companies that don't "actively advertise" as shipping to the UK don't want to sell to the UK?

Lots of people seem to agree with you. These people try to order something through a web site, but when it rejects their shipping address, they give up. They think "I guess they don't want to ship to a foreign country". People at the company are blissfully unaware of those frustrated potential customers. When finally a foreign potential customer attempts to clue them in to the fact that their web site is not internationalized, they take his order manually and ship the product. It doesn't make sense to internationalize the web site when it is much cheaper to manually handle one or two international orders a year.

Sounds like a ChickenAndEggProblem:

"If my web site were internationalized, I would get more international customers" <--> "if I had more international customers, then I would internationalize my web site")

Or is it a SelfFulfillingProphecy ?

"For international orders, contact us..." isn't really all that hard to add to the form template, even if you don't expect many foreign orders (and if you get enough that they become a nuisance, it might be worth adding suitable handling to your form, but that's usually a good kind of problem to have).

While editing this page to correct a typo, I thought of what seems to be a simplifying solution to the addressing problem: If I'm using my CreditCard? for a purchase, have a check box on the form that instructs them to ship the order to the address my CreditCard? company will provide. Is that a crazy idea? -- ChrisGarrod

According to my last 3 banks, they are prohibited from giving out that address by Regulation P. However, if I was an online business, I'd trust PayPal to provide me with the correct address. So the theory is good, even if the specifics fail. The address entered as the "billing address" is used as a verification that you are actually the cardholder.

The American Standard Code for Information Interchange (ASCII) is all you really need. Really. >;->