Michael Thompson schrieb:
I hear you, but this issue is so much wider than separators. I know one software package that will only successfully export data to excel if the system regional is one of the "English (xxx)" variations (Australian guaranteed to work, not really played with the rest...). In this case, the client (in Denmark) has one PC in a corner, set to Australian settings, just for exports...
This may be a relict from the time, where Microsoft found it a good idea to nationalize VBA (VB, Word, Excel...). I appreciated that in so far, as no English macro virus could become active in my German Word (with only German keywords). The same language barrier may prevent proper data export, maybe starting with slightly different keyword spellings like for color/colour.
Similar problems exist(ed) in RTF export, so that MS had to ship another WinHelp compiler (HC) for every new WinWord version, that worked around the new errors in the RTF sources exported from Word, even after VBA was reverted to unique English-only keywords and function names.
As an Australian developer, this is just embarrassing...
I never felt a need or reason for considering Microsoft products as anything but buggy toys, hardly usable outside the USA :-(
To come back to the current discussions, the introduction of Unicode (as UCS-2 and UTF-16) was a similar (typically American) mistake, totally ignoring e.g. any Chinese character set (in favor of Klingon?). Apple, as another US company, invented the decomposed Unicode filenames - for lack of oversight, or to establish artificial platform barriers?
The step from strictly national Ansi applications to Unicode is a very tiny one, compared to the leaps that have to be taken afterwards, in order to make the program really work in foreign countries. I wonder how e.g. Belgian, Canadian or Swiss software has been written in such multi-lingual countries before, and how it is written nowadays.
DoDi _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
