Ryoku

Thanks for the useful guide. But I don't believe it's a requirement, I believe it is widely constrained not only by the location but also by the intended user and market for the application. A good example of what I mean is Adobe Flash. This program uses many terms that are particularly hard to translate to, for example, Spanish in an industry dominated by anglicisms (Or words commonly spoken in English even though you are communicating in another language). What happens is the following: You learn how to use the terms or how to use an application in one language, but you have use it in another; and I'm not talking about little changes here, most of this words and their meanings change dramatically when you translate them. In this case you can think of the words frame to "fotograma" and tween to "Iteración automática de movimiento". This is a huge problem. Not only users have trouble adapting to the translated software, but it also creates great incompatibilities when we're working with a team from another country. Not a technical incompatibility of course, but a human one. What I'm trying to point out is just that localization should not simply be "A requirement" that may cause you to even lose users. If you are going to give optional languages, try giving your users the option to set it, instead of forcing it into them.

Now there's a lot more to localization than just language managing, what about dynamic content based on location? Google implemented it and it's a non-opt-out pain in the ass. Each time it's harder to find the results I need because their localization forces mexican results into the front page instead of whatever international search I'm trying to do.

Bottom line, there is a lot to localization but you have to be very careful when and how you apply it. Our systems should give us more tools to customize our experience to our needs, not the needs someone else thinks we have. As developers we need to work to give our users this customization options.

That's really impressive, I've been trying to get a service running like this. But so far I've just got single-man developed free websites. One of the problems I've encountered is how to actually drag users to the service/s. Do you have any advice on that?

Well, your privacy is simply limited to whatever permissions you give to the web app you're logging in to (And all your public information as well), on one side. And on the other side, facebook records all the websites you visit who have a connection with them, when you do and for how long, etc. If you're comfortable with that, then... Well, you've got half the problem down.

I think what would really be worrying is the amount of power you are giving to a single authentication method. You are putting "All your eggs in one basket" As soon as someone is able to compromise your facebook account, either by facebook's or your own fault, all your other facebook connected accounts will be compromised; and the attacker can simply check your security app settings to know who have you logged in to.

And then again... What will happen when Facebook is not around anymore? Will all the websites you logged in to have a nice easy fallback option? Or will some/all of your related accounts be lost?

Well yes, I completely agree with you. That is what we should do. But each time I see more developers that leave production level apps like this. And not even small websites like http://absolutmexico.com (Has a fallback to other browsers but the developer consciously decided to not offer the same functionality for browsers other than Chrome, even after been pointed to a few plug ins that would do it for him); but also huge Frameworks, like Appian, which forces you to use IE for administration.

And there's another side of the story, in both of the above scenarios, the product/site where developed by Engineers and Web Developers. But each time, plug ins make it easier for "non-code-savy" people to implement (for example) effects on their websites that would be really complicated any other way; which is cool until the moment you notice most of those plug ins are poorly coded. The problem grows as this people sell themselves as web developers and usually charge (as freelancers) much less than the full implementation of the job would be worth. I know this happens a lot, and by a lot I mean that 85% of the independent projects I had this year were about fixing this websites or making them bigger.

I think the problem might be that, in general, we talk about all the marvels of the internet and our work with it that it just makes people want to jump in. We give tutorials, plug ins, API's, and any other tool that makes the job easier, without really pointing out all that should be needed to actually deploy to production.