Gabriel Sechan wrote: >> From: Christopher Smith <[EMAIL PROTECTED]> >> Gabriel Sechan wrote: >> > In 99% of apps, internationalization is overkill. Unless a human is >> > meant to be editing the file (such as a config file), its just a waste >> > of CPU power and time. >> >> Okay, that part I'd disagree with. Anytime you have strings as your data >> type, there is a distinct possibility you will need some kind of >> internationalization. It's not a given, but it applies to far more than >> 1% of the cases, and unfortunately people tend not to realize that. > > Most of the time, you're writing program either for yourself, or your > company. Internal apps (at least those I work on) rarely to never go > overseas.
Yeah, that is becoming decreasingly true these days. Even apps that never go overseas have to deal with companies and products from overseas, and often representing them in ASCII is highly error prone (as indicated by the Tchaikovsky example). Basically, once you are dealing with an interchange format where you are considering XML, the probabilities really start to skew towards i18n issues (l10n issues might not show up unless you specifically have non-local users). > I speak only English. So worrying about internationalization > is a waste of my time. I speak French and English, but I can assure you the stuff where I need to deal with i18n is generally not French. ;-) Basically, if what you are doing is tied to the Internet, there is a distinct risk of i18n issues. > If it comes out it needs to be added later, its cheaper to do so then > on the average. For the most part I agree with you. The problem is when it needs to be there from the get go, and one fails to recognize this, then all hell breaks loose. Also, certain languages (C in particular) can make it much harder for you to refactor to a different string representation without introducing a lot of difficult to identify bugs. So, while going all out on i18n might be a lot of wasted effort. Making sure you have the right abstractions so that you can handle it later is important. > Now if your job is writing software thats going to be shrink wrapped > and sent off around the world, you'll need it. But thats a minority > of software. Sure, I can't think of a single line of code I've written that went in to a shrink wrapped package, but the vast majority of code I've written has needed to at least address i18n issues. > If you need it, you need it. If you think there's a good chance of > needing it down the road, it might be worth designign it in now. But > otherwise its smarter to avoid headaches. Of course, the type of > software you're writing probably highly influences this. I think we're really in agreement on this. I think the issue is mandating the use of Unicode in all cases, as opposed to making sure you have support for it in standard tools and APIs. --Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
