4 ms·

I think this blog post REALLY overlooks the fact that interface localization isn't easy; even with a simple web forms. The interface for a search engine is a s

by Timmy_C 17y ago

I think this blog post REALLY overlooks the fact that interface localization isn't easy; even with a simple web forms. The interface for a search engine is a single input field with dynamic suggestions and people were in an uproar when Bing didn't give suggestions that were localized to the user's country or language. That's to say, if one of the biggest software companies in the world can't get it right, then what hope does the average web developer have?

gn 17y ago
Not every aspect of this is easy, true, but that's no reason not to tackle the ones that are. It's trivial to simply not require a state or a postcode or try to verify a phone no if the user selects a country other than the US. There should be a library for this. We have libraries that can handle the insanely capricious details of DST for all countries and subnational entities on the planet; we should have no problem providing one list of states and two regular expressions per nation. (I know it's more or less impossible to reliably catch (e.g.) invalid UK postcodes, but we wouldn't have to. We'd mainly want to catch obvious typos without making things needlessly hard for customers overseas.)
- Timmy_C 17y ago
  Wufoo is pretty good for pre-made forms. And they advertise that they can do US and International phone, mail and currency fields.
jwr 17y ago
If I wanted to write a blog post which elaborated on all possible internationalization issues, it would become a PhD dissertation and take a year to write. And then it wouldn't even touch on all the issues. You have to start somewhere — and let's face it, dealing with the two silly problems I mentioned would get us 80% of the way there.
- jasonlotito 17y ago
  I had to deal with International phone numbers before. Obviously, I had to deal with other issues, too, but the phone number was the important piece. Early on, before PayPal or other services caught on, we created a system to verify credit card users with their telephone. They would enter their telephone number and we'd call them. It was simple. The problem was with international users. The system was simple: it would call the exact phone number the user entered. This meant we really wanted to get it right the first time. The other problem was that we had a single call center setup out in New York. This meant international callers needed to be called with special country codes and what not. Now, I feel it's safe to say if you ask someone in Europe to give their phone number, they are going to give their phone number like they would to any of their friends. They aren't going to enter in the country code, and they aren't going to know to prefix it with a special code so that an automated system from the US can call them. The thing is, it's not fair for me to simply provide them with the requirement "Give us your phone number so we can call you from New York, USA." It really isn't professional. So, I spent some time (lots of time) reading up and learning about international phone numbers, and coding together a system that went a long way toward fixing this problem. A user could enter in their phone number, and if they didn't enter in a country code, we'd be intelligent about it and add it for them. How did we know where they lived? Two sources: CC Info and the IP address. We could be intelligent and assume the two should mostly match up. Obviously, if the CC address was the US, and the IP was somewhere off in Asia, red flags beyond just the errors for phone numbers would popup (but, even then, you had to be careful!). I spent a lot of time fine tuning the system, working hard to make sure that a phone number would get through however the user entered it, and we could call. We had a really good success rate with numbers outside the North American norm. Enough that the cases that did fail I couldn't even figure out manually. I was a bit saddened that it was all for nothing when we eventually removed the 'feature.' and the requirement for a phone number. I understand the reasons, but from a problem solving point of view, it was a lot of fun.
  - chronomex 17y ago
    That sounds like a really awesome bit of code to look at. Can you share it?
  - jwr 17y ago
- tghw 17y ago
  I gave it a shot of my own. I didn't do all the permutations, and surely left out big swaths that I've never even thought of, but it's a start... http://hicks-wright.net/blog/stupid-american-website-owners/ http://hicks-wright.net/blog/stupid-american-website-owners/
  - jasonlotito 17y ago
    I wrote about Credit Card forms a while back as well. http://www.jasonlotito.com/programming/what-i-know-about-designing-credit-card-forms/ http://www.jasonlotito.com/programming/what-i-know-about-des... Anyways, you mention in your post: "Making something a simple form that is fully internationalized and has useful validation is no where near as easy as they would like us to believe." It's not easy, but it's not as time consuming and as difficult as you think it is. Getting the phone numbers right doesn't take years. A week is all you need from design to testing, and you are done. Postal Codes are easy as well, considering their are numerous services that allow you to verify the Postal Code to the address. However, even taking something as simple as the common case, a user from the US entering a 6 digit code has probably made an error, and that solves a common problem. House numbers and other addresses never presented a significant problem. I've seen more problems with not accepting different encodings then with the actual input. And why is this important, even if you just want to serve an American audience? Because not every American lives in the US. Consider just the Armed Services, stationed all over the world. No. If you don't want to do it, that's fine. But don't complain that it's too much work or not worth it.
    - tghw 17y ago
      Of course I exaggerate in the post, you're right that it'll probably take just a week to get coded up. (Which means three weeks, the way development often goes.) The question is whether or not that time is well spent, or if I would be better off using that time to improve whatever product/service the form is attached to. Especially when you're on a lean (i.e. startup) budget, the decision becomes pretty clear.
      - jasonlotito 17y ago

by Timmy_C 17y ago

gn 17y ago

Not every aspect of this is easy, true, but that's no reason not to tackle the ones that are. It's trivial to simply not require a state or a postcode or try to verify a phone no if the user selects a country other than the US. There should be a library for this. We have libraries that can handle the insanely capricious details of DST for all countries and subnational entities on the planet; we should have no problem providing one list of states and two regular expressions per nation. (I know it's more or less impossible to reliably catch (e.g.) invalid UK postcodes, but we wouldn't have to. We'd mainly want to catch obvious typos without making things needlessly hard for customers overseas.)

Timmy_C 17y ago
Wufoo is pretty good for pre-made forms. And they advertise that they can do US and International phone, mail and currency fields.

jwr 17y ago

If I wanted to write a blog post which elaborated on all possible internationalization issues, it would become a PhD dissertation and take a year to write. And then it wouldn't even touch on all the issues. You have to start somewhere — and let's face it, dealing with the two silly problems I mentioned would get us 80% of the way there.

jasonlotito 17y ago
I had to deal with International phone numbers before. Obviously, I had to deal with other issues, too, but the phone number was the important piece. Early on, before PayPal or other services caught on, we created a system to verify credit card users with their telephone. They would enter their telephone number and we'd call them. It was simple. The problem was with international users. The system was simple: it would call the exact phone number the user entered. This meant we really wanted to get it right the first time. The other problem was that we had a single call center setup out in New York. This meant international callers needed to be called with special country codes and what not. Now, I feel it's safe to say if you ask someone in Europe to give their phone number, they are going to give their phone number like they would to any of their friends. They aren't going to enter in the country code, and they aren't going to know to prefix it with a special code so that an automated system from the US can call them. The thing is, it's not fair for me to simply provide them with the requirement "Give us your phone number so we can call you from New York, USA." It really isn't professional. So, I spent some time (lots of time) reading up and learning about international phone numbers, and coding together a system that went a long way toward fixing this problem. A user could enter in their phone number, and if they didn't enter in a country code, we'd be intelligent about it and add it for them. How did we know where they lived? Two sources: CC Info and the IP address. We could be intelligent and assume the two should mostly match up. Obviously, if the CC address was the US, and the IP was somewhere off in Asia, red flags beyond just the errors for phone numbers would popup (but, even then, you had to be careful!). I spent a lot of time fine tuning the system, working hard to make sure that a phone number would get through however the user entered it, and we could call. We had a really good success rate with numbers outside the North American norm. Enough that the cases that did fail I couldn't even figure out manually. I was a bit saddened that it was all for nothing when we eventually removed the 'feature.' and the requirement for a phone number. I understand the reasons, but from a problem solving point of view, it was a lot of fun.
- chronomex 17y ago
  That sounds like a really awesome bit of code to look at. Can you share it?
- jwr 17y ago
tghw 17y ago
I gave it a shot of my own. I didn't do all the permutations, and surely left out big swaths that I've never even thought of, but it's a start... http://hicks-wright.net/blog/stupid-american-website-owners/ http://hicks-wright.net/blog/stupid-american-website-owners/
- jasonlotito 17y ago
  I wrote about Credit Card forms a while back as well. http://www.jasonlotito.com/programming/what-i-know-about-designing-credit-card-forms/ http://www.jasonlotito.com/programming/what-i-know-about-des... Anyways, you mention in your post: "Making something a simple form that is fully internationalized and has useful validation is no where near as easy as they would like us to believe." It's not easy, but it's not as time consuming and as difficult as you think it is. Getting the phone numbers right doesn't take years. A week is all you need from design to testing, and you are done. Postal Codes are easy as well, considering their are numerous services that allow you to verify the Postal Code to the address. However, even taking something as simple as the common case, a user from the US entering a 6 digit code has probably made an error, and that solves a common problem. House numbers and other addresses never presented a significant problem. I've seen more problems with not accepting different encodings then with the actual input. And why is this important, even if you just want to serve an American audience? Because not every American lives in the US. Consider just the Armed Services, stationed all over the world. No. If you don't want to do it, that's fine. But don't complain that it's too much work or not worth it.
  - tghw 17y ago
    Of course I exaggerate in the post, you're right that it'll probably take just a week to get coded up. (Which means three weeks, the way development often goes.) The question is whether or not that time is well spent, or if I would be better off using that time to improve whatever product/service the form is attached to. Especially when you're on a lean (i.e. startup) budget, the decision becomes pretty clear.
    - jasonlotito 17y ago