Software development and regional testing.

[Ed Dyreen]

'
Greetings,

I've been working on a very small program, only 10.000 lines
Now I want to do regional testing, I want to see how it behaves like in US, germany, france etc..
I guess changing the language won't be enough, don't tell me I need to have a windows copy for every region do I ?
I am afraid the answer is going to be yes, I know for example the time is formatted differently sometimes, with me is like

Code: Select all

vr 03/02/2012 20:37:56,62

And then what are these codepages for and how does it helps ?

Code: Select all

chcp 850 %= codepage 850 =%

How does we make things work for everybody ?


Thanks

[aGerman]

Perhaps it would help to change the locale settings of your System for testings. But the most important thing is to program as language independent as possible. If we're talking about batch this would mean to work with errorlevel logic instead of parsing the output of a command. I'm virtually certain that you will never completely language independent with batch programming, but I guess Alan could tell you something about his efforts because I know he is very concernd...
Codepages are good for supporting language-depending characters.

Regards
aGerman

[Liviu]

In addition to aGerman's good advice...

'Now I want to do regional testing, I want to see how it behaves like in US, germany, france etc..

It depends a lot on the type of project and implementation language. Up to some point you can get by with just toying with your own Windows' regional settings. That would cover, for example, different decimal point, currency, date/time variations. But "natively localized" installations may have different directory structures and other subtle deviations, too. Those cannot be fully realistically tested except within the respective installation. If yours is more than a hobby project then I'd recommend you look at a MS subscription like Technet or MSDN which gives you access to a number of platforms to use for evaluation/testing, usually done in virtual machines of your choice.

And, it always helps to have good friends in your target markets to do some beta testing since it's not only about the machine itself, but also their usage habits, for example switching languages often, using odd (for others) characters etc.

And then what are these codepages for and how does it helps?

Outside batch world, codepages become obsolete quickly. Where internationalization matters at all, the way is Unicode. At the command prompt, however, codepages still matter at the input/output boundaries - everything in between is internally handled in UTF-16 but the conversion between wide/narrow character sets depends on the given codepage. Such conversions happen for example when a batch file is read in (since there is no support for UTF encoding, yet, neither for .cmd's nor for external "for /f" files), or when the output is piped/redirected (unless "cmd /u").

Liviu

[orange_batch]

I've been working on a piece of software too Ed, for almost 2 years on and off. A little over 1000 lines of code though, much of it space and commenting, but highly complex/optimized/modular.

You do need a regional copy of Windows for the differences between languages with DOS tools. Changing locale won't help. However, you can retrieve any information you need using vbscript and WMI in conjunction, except in the case of chcp codepage for example. But you can still retrieve any necessary data by filtering based on the structure of data returned. For example:

chcp on Japanese Windows returns a string with this type of format (romanized):

Code: Select all

XXnoko-do pe-ji: 932

Where as English Windows returns:

Code: Select all

Active code page: 850

We can't be sure that every language separates using the colon character :, but the space character before the codepage number is likely hard-coded, so with for /f it becomes a matter of filtering for the last token (non-specific) using spaces.

PS: Started writing this way earlier before Liviu:

But "natively localized" installations may have different directory structures and other subtle deviations, too.

Yes, so try to retrieve subjective information from a reliable source such as WMI or the registry.

As for DOS's unicode support, it has partial support due to Windows but it's technical and I think I've explained elsewhere. Suffice to say, unicode can be passed from Windows (shell for example), and different codepages will not change the operation of your batch script*. Batch can write UTF-16LE with cmd /u, but it's not possible to properly read unicode from files (or at least, process the output using for /f to store data into a variable).

*All a codepage is, is the representative character for ASCII #0 to 255. You could make your coding look like gobbledygook and it will be read by the computer the same.

I'd like to think myself a leading expert in this area, so ask away.