If you develop software to sell, then perhaps there might be market beyond shores of USA. Have you considered making multiple language versions of your software available? Perhaps you’ve given it a fleeting thought but dismissed idea as too expensive or too difficult. Take away jargon and buzzwords, not to mention expectation that it is difficult; and many software products can relatively simply be produced for different language speakers. Especially so if developers have followed reasonable development standards.

And lets face it, extra revenue and customer base can be very very lucrative.Nor should you under estimate number of people in USA who don’t have English as their first language. Another benefit of providing your software product in multiple languages is that it also gives an impression that your company is far larger than it is. When I see a web site or software product available in multiple languages I tend to assume that company must be large.

So let’s take a look at process and examine what’s involved. We concentrate in this article on taking an existing software product and making it available in multiple languages. The ideas presented here are general and assume a relatively simple product, but concepts and approach are same for even a sophisticated application.

First rule: to keep things simple. There are many different languages being used around world and you have a wide choice. In English we read sentences written left-to-right and from top, down page or screen. This isn’t case for all languages. We also use an alphabet (script) referred to as Latin, and in technical speak it uses single byte characters. So it’s a good idea to restrict your first multiple language projects to languages that also share these characteristics with English.

The list is extensive and includes; Spanish, German, Italian, Portuguese, French, Dutch among others. Even restricting your project to these languages widens your market by about 1 billion people. Eastern Europe uses a script called Cyrillic (Russian) which is very similar to Latin and prices for translation into Eastern European languages tend to be very competitive. Asian and Middle Eastern languages offer some unique challenges but they are manageable. But early in process, you need to decide exactly what languages you want your software to be available in.

There are a variety of methods to developing multiple language versions of software. One approach favoured is to separate out all of text presented to user into a file or database table. This text must include everything that a user will see when using software. It includes screen display text, printed report text, constants, prompt, error and warning messages, and help displays. Your product will likely include a user guide, version notes and licence agreement, and of course these also need to be included in localization project.

The file or database table where all text will exist has to be accessible by programs and so some sort of simple key process and update function must be developed. Again, keep it simple. We’ve found that having a simple key system based on screen or report name and then a unique text item number works fine for most applications. For large a application you may need several text files, perhaps based on text type. You’re probably thinking that application’s performance will be reduced due to extra input/output needed to access all text. There will be some reduction but in practice it is minimal. And there are some benefits to compensate. For instance if screen text needs to be altered then no program change needs be made to effect change.

There has been a lot of press about this new feature. It's been all over web - some positive comments, some negative (and, of course, usual "it's just a Microsoft plot" type postings and articles.)

Personally, I like new privacy tab as it eliminates need for third party cookie handling products (if you are using Internet Explorer, of course). I found controls very simple and straightforward, and within a short time cookies have ceased to be a concern.

This is part first significant implementation of a new internet standard called P3P (Platform for Privacy Preferences). P3P is intended to give surfers more complete control of how their privacy is handled whenever they surf. In theory, at least, P3P should automate privacy, eliminating need for surfers to read complex privacy notices every time they visit a site and want to enter some information.

The controls actually control much more than you might think. There is quite a bit of technology behind those simple radio buttons. You see, webmasters are being asked to supply a special XML document which defines how their site handles cookies and other privacy matters. Browsers which understand P3P (Internet Explorer for one) read this document and compare it to settings you entered on "privacy" tab. This allows browser to automatically handle your privacy needs for sites which fulfill your privacy needs.

This became an issue because, quite frankly, many companies (both on and off web) horribly abuse privacy of their customers. It's very common for a company to record your name and other personal data, then resell it dozens or even hundreds of times. Information is very valuable, and information which is gathered from internet is even more so.